Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36282
RN Tester is currently red as `TraceUpdateOverlay` is not registered in the Fabric Core Component Registry.
Changelog:
[Internal] [Changed] - Add TraceUpdateOverlayComponentDescriptor to CoreComponentsRegistry
Reviewed By: cipolleschi
Differential Revision: D43567915
fbshipit-source-id: ceb4b9b674a969f260caf810eade30ae23ce2ce8
Summary:
We don't support Lambda in OSS yet, Lambdas were introduced as root of a stack of diffs, so we need to revert the whole stack
## Changelog:
[internal] - revert changes that broke CircleCI
Reviewed By: GijsWeterings
Differential Revision: D43566129
fbshipit-source-id: feae3c3065ed83463c9d887d7ff488c29993e0ae
Summary:
We don't support Lambda in OSS yet, Lambdas were introduced as root of a stack of diffs, so we need to revert the whole stack
## Changelog:
[internal] - revert changes that broke CircleCI
Reviewed By: GijsWeterings
Differential Revision: D43566121
fbshipit-source-id: 5c4fe8272ca220d8914eb64b3ab395589c007198
Summary:
We don't support Lambda in OSS yet, Lambdas were introduced as root of a stack of diffs, so we need to revert the whole stack
## Changelog:
[internal] - revert changes that broke CircleCI
Reviewed By: GijsWeterings
Differential Revision: D43566086
fbshipit-source-id: 95b8ed404edd6f711fbbb5ae3913010c653a2c28
Summary:
While looking into android code i noticed a bug removing the incorrect key from a map.
changelog: [internal] internal
Reviewed By: RSNara
Differential Revision: D43544499
fbshipit-source-id: 15224e90cc46af358fb822e85accfae9aa9f7d11
Summary:
We can now use Java 8, this diff i'm replacing old callbacks by lambdas
changelog: [internal] internal
Reviewed By: RSNara
Differential Revision: D43544498
fbshipit-source-id: 4c5ab8473b3d9d512853c02e81652fdce1838a48
Summary:
Changelog:
[Android][Internal] - Fix EventAnimationDriverMatchSpec to match against the view that generated the event for non-bubbling pointer events. This should have no effect if you are not using PointerEvents
Reviewed By: mdvacca
Differential Revision: D43413771
fbshipit-source-id: 31ac751b3d3d55eb44d3a9ab54e5fb387dcaa9b3
Summary:
I've just tested the nightly and the build from source is broken as the `repositories{}` block is missing.
Normally RNGP will take care of setting repositories for everyone, but this is triggered by the app-module.
When building from source, the app module of the user is isolated from the included build of React Native,
therefore the repositories{} definitions are not passed over.
Without this, the build fails with:
```
Cannot resolve external dependency ... because no repositories are defined
```
Changelog:
[Internal] [Changed] - Re-add repositories{} block to allow for build-from-source
Reviewed By: cipolleschi
Differential Revision: D43501011
fbshipit-source-id: b41c56c62839163ad210e7e303940dec0a9001da
Summary: Changelog: [Android][Fixed] Resolved bug with Text components in new arch losing text alignment state.
Reviewed By: mdvacca
Differential Revision: D34108943
fbshipit-source-id: 3992e9406345be919b5e3595fc1f9e61cf67a699
Summary:
Simple optimization to exit before iterating through the hit path if the event name doesn't match.
Changelog:
[Android][Internal] - Optimization for natively-driven Animated PointerEvents to early exit during matching in EventAnimationDriverMatchSpec. This should have no effect if you are not using PointerEvents
Reviewed By: lunaleaps
Differential Revision: D43400457
fbshipit-source-id: fe8d811d371c78622cd4f3f9cd469cff9ccce585
Summary:
Callling `getReactApplicationContextIfActiveOrWarn` from `invalidate` will always warn because the context is deactivated, which is preventing us from cleaning up these listeners.
Changelog: [Internal]
Reviewed By: jehartzog
Differential Revision: D43352929
fbshipit-source-id: f29564a290a6c93b2304865d445829f5e486d84f
Summary:
[Changelog][Internal]
A follow-up, based on javache comments on D43398416 (https://github.com/facebook/react-native/commit/9aac13d4dc95925b57f03e7964fc7add6834e518) (post-land) - just some minor potential improvements for locking efficiency.
Reviewed By: javache
Differential Revision: D43438414
fbshipit-source-id: 0cf807a045a1f132d5481d3f6115a97869e93d65
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36201
[Changelog][Internal]
Guard call to the C++ ReadableNAtiveMap.importValues with a lock.
Note that all the occurrences in this class (together with importTypes) already were protected by a lock, except of this one, which with the very high chance caused crashes in T145271136.
My corresponding comment from the task, for justification:
> If callstack to be trusted, the crash happens on the C++ side, in ReadableNativeMap::importValues().
It throws ArrayIndexOutOfBoundsException, which, looking at the code, seems to be only possible due to a corrupted data or race conditions.
> Now, looking at the Java side of ReadableNativeMap, and the particular call site... it's very dodgy, since all other occurrences of calling to native importTypes/importValues are guarded by locks, but the one crashing isn't.
NOTE: A couple of `importKeys()` instances appears to suffer from the same problem as well.
Reviewed By: javache
Differential Revision: D43398416
fbshipit-source-id: 0402de5dc723a2fba7d0247c8ad4aeff150d8340
Summary:
changelog: [internal]
C++17 has implementation of shared_mutex in standard library. Let's use it instead of folly.
Reviewed By: cipolleschi
Differential Revision: D43275493
fbshipit-source-id: d766251226aa230110011aca94b4e697fe0d31a1
Summary:
Before this change, the only way to update the offline mirror was to run it on a devmachine
(OD won't work either due to network restriction).
Developer's laptop also won't work as they would download AAPT2 for MacOS.
In the offline mirror instead we need AAPT2 for Linux as that's Sandcastle runner type.
This relaxes this requirement so the next time a developer has to update the offline
mirror they will see the message on the diff with the command to execute, and they should
be able to run the command locally (or on their devbox).
Changelog:
[Internal] [Changed] - Allow for Android offline mirrors to be executed on developer's laptops
allow-large-files
Reviewed By: cipolleschi
Differential Revision: D43344651
fbshipit-source-id: 3e91adb2db45cf94d3f947aaab501d98580dc43d
Summary:
This util class was introduced in D42978852 (https://github.com/facebook/react-native/commit/611f9c615ebad7d53c1eb1274fe82e36d915165e), but the Long type was not ported over. Not sure if this was intentional or not, but this is used from return values from DeviceConfig, where number values are encoded as Long types.
Changelog:
[Internal] - internal
Differential Revision: D43323851
fbshipit-source-id: 6a8a27b75b1738f2f87dd56ee814316af323c258
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36160
Changelog:
[Android][Fixed] - Invalid prop values no longer trigger Java exceptions in the legacy renderer
## Context
We are changing React Native to behave more like a browser in the sense that **bad style values are not runtime errors**. (See e.g. D43159284 (https://github.com/facebook/react-native/commit/d6e9891577c81503407adaa85db8f5bf97557db0), D43184380.) The recommended way for developers to ensure they are passing correct style values is to use a typechecker (TypeScript or Flow) in conjunction with E2E tests and manual spot checks.
## This diff
This change is similar to D43184380, but here we target the legacy renderer on Android by (1) replacing exceptions with logging calls, (2) adding fallback values (equivalent to resetting the respective props to `null`) where needed, and (3) replacing `null` checks in `ReactProp` converters with `instanceof` checks.
Leaving the logging call sites in place (as opposed to deleting them) will be helpful if we decide that we want to repurpose these checks for a new, more visible diagnostic (though we would likely only build such a diagnostic in Fabric at this point).
Reviewed By: javache
Differential Revision: D43274525
fbshipit-source-id: 9d1e7ca3b6299dd827e8667e3d542433ec896c0e
Summary:
The `rrc_root` was not exposed via prefab. I'm adding it to make possible for Reanimated to integrate on top of React Native via prefab. Based on https://github.com/facebook/react-native/issues/35643.
## Changelog
[ANDROID] [CHANGED] - Expose `rrc_root` via prefab.
Pull Request resolved: https://github.com/facebook/react-native/pull/36166
Reviewed By: cipolleschi
Differential Revision: D43304302
Pulled By: cortinico
fbshipit-source-id: 1c4a7013a33b48a8a7a445a78430630542420f4d
Summary:
There are two different ways of getting the ReactModuleInfoProvider from LazyReactPackage:
1. static LazyReactPackage.getReactModuleInfoProviderViaReflection(LazyReactPackage)
2. LazyReactPackage.getReactModuleInfoProvider()
The first way calls into codegen that only works within Meta's infra. This code-path is *now* dead. Therefore, this diff deprecates the first path, to make LazyReactPackage less confusing.
This diff simplifies the implementation to return an empty ReactModuleInfoProvider for the v0.72 cut.
In the v0.73 cut, we'll just outright delete this method.
Changelog: [Android][Changed] - Deprecate LazyReactPackage.getReactModuleInfoProviderViaReflection()
Reviewed By: sshic
Differential Revision: D43066800
fbshipit-source-id: 2145c3265ff2bd24e6828b193577ba1f500bce49
Summary:
This diff pays the duty in T126215968 where we should move the util methods to a shareable place. ~~I cannot find a good util namespace so I created on under `com.facebook.react.panelapp`.~~ This lives under `com.facebook.react.bridge` next to the `Arguments` class.
- Create ~~`ReadableDataParser.java`~~ `JSONArguments.java`
- Reuse in multiple places within `react-panellib`
Changelog:
[Internal] - Code refactor on JSON and ReadableMap conversion
Reviewed By: javache
Differential Revision: D42978852
fbshipit-source-id: e00a5c4cefcf6114d9a5d947cb00e3ff7f0dccaa
Summary:
This diff adds `TraceUpdateOverlay` native component to render highlights when trace update is detected from React JS. This allows a highlight border to be rendered outside of the component with re-renders.
- Created `TraceUpdateOverlay` native component and added to the `DebugCorePackage`
- Added to C++ registry so it's compatible with Fabric
- Added to `AppContainer` for all RN apps when global devtools hook is available
Changelog:
[Android][Internal] - Add trace update overlay to show re-render highlights
Reviewed By: javache
Differential Revision: D42831719
fbshipit-source-id: 30c2e24859a316c27700270087a0d7779d7ad8ed
Summary: Changelog: [Internal] - Ensure pointer move tracking is applied to movement while the pointer is pressed
Reviewed By: javache
Differential Revision: D42977052
fbshipit-source-id: 2d48c35a908449d0b2338c33273fb75a430bc393
Summary:
Hi 👋
I'm one of the Expo contributors. When upgrading the Stripe dependency in Expo for SDK48 release on Android, we noticed the following error:
```java.lang.ClassCastException: android.view.ContextThemeWrapper cannot be cast to android.app.Activity```
With Kudo we narrowed it down to an underlying issue in the following cast in `ReactRootView` done during checking for keyboard events:
```((Activity) getContext())```
The `getContext()` is actually a `ContextThemeWrapper` for `ExperienceActivity`, so we should not cast it to an `Activity` directly - instead, we unwrap it using `getBaseContext()`.
Implementing the following fix into the Expo fork fixed the crash for us:
https://github.com/expo/react-native/commit/0e2c9cada120a3709e8285ab4bcdaa1c5c446732
## Changelog
[ANDROID] [FIXED] - Fixed crash occurring in certain native views when handling keyboard events.
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/36121
Test Plan:
Tested manually by comparing two builds before and after this change. The main branch build crashes when the [Stripe 0.23.1](https://github.com/stripe/stripe-react-native) Card Element from the example app is mounted on screen. Applying the change fixed the issue.
Happy to make a more isolated reproduction if necessary.
---
Full stack trace:
```
AndroidRuntime D Shutting down VM
E FATAL EXCEPTION: main
E Process: host.exp.exponent, PID: 8849
E java.lang.ClassCastException: android.view.ContextThemeWrapper cannot be cast to android.app.Activity
E at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.checkForKeyboardEvents(ReactRootView.java:937)
E at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.onGlobalLayout(ReactRootView.java:913)
E at android.view.ViewTreeObserver.dispatchOnGlobalLayout(ViewTreeObserver.java:1061)
E at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3352)
E at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2286)
E at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:8948)
E at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1231)
E at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1239)
E at android.view.Choreographer.doCallbacks(Choreographer.java:899)
E at android.view.Choreographer.doFrame(Choreographer.java:832)
E at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1214)
E at android.os.Handler.handleCallback(Handler.java:942)
E at android.os.Handler.dispatchMessage(Handler.java:99)
E at android.os.Looper.loopOnce(Looper.java:201)
E at android.os.Looper.loop(Looper.java:288)
E at android.app.ActivityThread.main(ActivityThread.java:7898)
E at java.lang.reflect.Method.invoke(Native Method)
E at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
E at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)
```
Reviewed By: cortinico
Differential Revision: D43186530
Pulled By: javache
fbshipit-source-id: 2143495f6b0c71f342eba6d5abb2bfa4a529fbdd
Summary:
This annotation is missing it's retention policy which should be `SOURCE` as it's an IntDef and not used at runtime.
Changelog:
[Internal] [Changed] - Add missing retention policy on EventCategoryDef annotation
Created from CodeHub with https://fburl.com/edit-in-codehub
Reviewed By: cipolleschi
Differential Revision: D43187398
fbshipit-source-id: d00bc3a5cf74d2eb983fa7369905e2260db80142
Summary:
Our first party modules are still using `namespace`. This cleans this up.
The Manifest file for ReactAndroid is also not needed anymore. The one
from hermes-engine can also be removed from facebook/hermes in a separate diff.
Changelog:
[Internal] [Changed] - Use namespace for ReactAndroid and hermes-engine
Reviewed By: cipolleschi
Differential Revision: D43198514
fbshipit-source-id: d988cfa81ecc4484b6b2add4ae2c1d9376febc3e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36128
This commit fixes a problem which is making harder to use the New Architecture in monorepos.
Specifically if a user specifies a `codegenDir` in their app, libraries should honor it.
This is not the case today.
The fix is to register an extension on the root project which will "pass" values from app
to libraries.
I've also cleaned up some of the logic in `readPackageJsonFile` function restricting
the access to those functions only to `.root` which is the only field they're accessing.
Fixes#35495
Changelog:
[Android] [Fixed] - Better Monorepo support for New Architecture
Reviewed By: cipolleschi
Differential Revision: D43186767
fbshipit-source-id: 5c5ca39397306120b6b6622cb728633bd331e021
Summary:
In our build logic we're mixing `plugins{}` and `buildscript{}`
which have unpredictable side-effect on the build classpath.
I'm moving over everything to use `plugins{}`. This is possible now
that we don't use build from source for New Architecture anymore.
Changelog:
[Internal] [Changed] - Do not use a mixture of plugins{} and buildscript{}
allow-large-files
Reviewed By: cipolleschi
Differential Revision: D43186768
fbshipit-source-id: dcd115bd9d7aadf5cb837b3a28598e274a092873
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36107
Having concurrentRoot disabled when Fabric is enabled is not recommended.
This simplifies the setup and makes sure that both are either enabled or disabled.
Changelog:
[Android] [Breaking] - Hardcode concurrentRootEnabled to true when Fabric is enabled
Reviewed By: cipolleschi
Differential Revision: D43127625
fbshipit-source-id: 88e5e800b55d5df228fb072bedf8533b0ab6c20d
Summary:
D42721684 (https://github.com/facebook/react-native/commit/be69c8b5a77ae60cced1b2af64e48b90d9955be5) left a pretty bad bug when using Fabric for Android. I missed that in Fabric specifically, on edit we will cache the Spannable backing the EditText for use in future measurement.
Because we've stripped the sizing spans, Spannable measurement has incorrect font size, and the TextInput size will change (collapsing) after the first edit. This effectively breaks any uncontrolled TextInput which does not have explicit dimensions set.
Changelog:
[Android][Fixed] - Fix measurement of uncontrolled TextInput after edit
Reviewed By: sammy-SC
Differential Revision: D43158407
fbshipit-source-id: 51602eab06c9a50e2b60ef0ed87bdb4df025e51e
Summary:
This mitigates some of the failures we're seeing inside the docker containers
where we're receiving 50x when trying to download native sources.
Changelog:
[Internal] [Changed] - Setup retries on Gradle donwload tasks
Reviewed By: cipolleschi
Differential Revision: D43155926
fbshipit-source-id: fa2266b3f5de48faefad37d6239f54f13481cd5f
Summary:
It's cheaper to pass nullptr over JNI, and allocate an empty folly::dynamic::object on the stack.
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D43117216
fbshipit-source-id: e127cce7a1ccf50395073ca9c1c0469d0faa9f82
Summary:
changelog: [internal]
Passing MountingCoordinator argument by value instead of reference. Using reference does not make sense since we eventually take ownership of shared_ptr anyway. This better communicates the intent.
Reviewed By: christophpurrer
Differential Revision: D43082955
fbshipit-source-id: 29e20abb9824c10a5f0d5e0ba1049ff6d67cee98
Summary:
Convert Bridge-only checks to overridable functions and make Bridgeless override them in ReactSurfaceView so that the checks will work for Bridgeless as well.
Issue fixed:
https://fb.workplace.com/groups/rn.support/permalink/24231137939841493/
Changelog:
[Android][Changed] - Convert Bridge-only calls to overridable functions
Reviewed By: javache
Differential Revision: D43063348
fbshipit-source-id: a1c181d27c1669f6033f3fb783c5a668b7c2585b
Summary:
Changelog:
[internal] - DescriptionSome tooling breaks when the JavascriptException is obfuscated. This change prevents the exception from getting obfuscated, allowing tools to detect them without symbolicating.
Differential Revision: D43091424
fbshipit-source-id: aae4768397bd78433a1d496ecac4a1442422d912
Summary:
Changelog: [internal]
Pass RuntimeScheduler to Binding in Venice.
This is needed for two reasons:
- support "callImmediates". This is a workaround to bridge the gap in scheduling until microtasks in RN are shipped.
- To block paint in case there is a state update in useLayoutEffect. Used later in this diff stack
Reviewed By: sshic
Differential Revision: D43088186
fbshipit-source-id: 8537234db5f72cbf057ad1861ca2c37a5c3dbd8b
Summary:
the current jsc-android is still built based on ndk r21, and react-native is now built based on ndk r23. the unwinder between r21 and r23 is incompatible (libgcc vs libunwind). if there's exceptions throwing from jsc, other react native libraries cannot catch these exceptions and cause runtime crash.
this pr updates jsc-android to 235231.0.0 which is the same webkitgtk version as 235230.2.1 but only built by ndk r23. the jsc-android pr is from https://github.com/react-native-community/jsc-android-buildscripts/pull/179. note that the jsc is based on ndk r23c and react-native is based on ndk r23b. the reason is that i cannot get jsc building successfully on r23b. hopefully r23b and r23c are abi safe.
there is another crash from libjscexecutor when testing the new jsc-android. to fix the issue, i have to explicitly link libunwind.a from libjscexecutor.so. supposedly ndk r23 should help to link libunwind under the hood, i still not figure out why it doesn't. but after linking libunwind.a, i can get new jsc-android work successfully.
```
E/art ( 2669): dlopen("/data/app/com.test-1/lib/x86_64/libjscexecutor.so", RTLD_LAZY) failed: dlopen failed: cannot locate symbol "_Unwind_Resume" referenced by "/data/app/com.test-1/lib/x86_64/libjscexecutor.so"...
W/System.err( 2669): java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "_Unwind_Resume" referenced by "/data/app/com.test-1/lib/x86_64/libjscexecutor.so"...
W/System.err( 2669): at java.lang.Runtime.load(Runtime.java:331)
W/System.err( 2669): at java.lang.System.load(System.java:982)
W/System.err( 2669): at com.facebook.soloader.SoLoader$1.load(SoLoader.java:558)
W/System.err( 2669): at com.facebook.soloader.DirectorySoSource.loadLibraryFrom(DirectorySoSource.java:110)
W/System.err( 2669): at com.facebook.soloader.DirectorySoSource.loadLibrary(DirectorySoSource.java:63)
W/System.err( 2669): at com.facebook.soloader.ApplicationSoSource.loadLibrary(ApplicationSoSource.java:91)
W/System.err( 2669): at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:1067)
W/System.err( 2669): at com.facebook.soloader.SoLoader.loadLibraryBySoNameImpl(SoLoader.java:943)
W/System.err( 2669): at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:855)
W/System.err( 2669): at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:802)
W/System.err( 2669): at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:772)
W/System.err( 2669): at com.facebook.react.jscexecutor.JSCExecutor.loadLibrary(JSCExecutor.java:24)
W/System.err( 2669): at com.facebook.react.jscexecutor.JSCExecutor.<clinit>(JSCExecutor.java:20)
W/System.err( 2669): at com.facebook.react.ReactInstanceManagerBuilder.getDefaultJSExecutorFactory(ReactInstanceManagerBuilder.java:363)
W/System.err( 2669): at com.facebook.react.ReactInstanceManagerBuilder.build(ReactInstanceManagerBuilder.java:316)
W/System.err( 2669): at com.facebook.react.ReactNativeHost.createReactInstanceManager(ReactNativeHost.java:94)
W/System.err( 2669): at com.facebook.react.ReactNativeHost.getReactInstanceManager(ReactNativeHost.java:41)
W/System.err( 2669): at com.test.MainApplication.onCreate(MainApplication.java:60)
W/System.err( 2669): at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1011)
W/System.err( 2669): at androidx.test.runner.MonitoringInstrumentation.callApplicationOnCreate(MonitoringInstrumentation.java:483)
W/System.err( 2669): at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4518)
W/System.err( 2669): at android.app.ActivityThread.access$1500(ActivityThread.java:144)
W/System.err( 2669): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1339)
W/System.err( 2669): at android.os.Handler.dispatchMessage(Handler.java:102)
W/System.err( 2669): at android.os.Looper.loop(Looper.java:135)
W/System.err( 2669): at android.app.ActivityThread.main(ActivityThread.java:5221)
W/System.err( 2669): at java.lang.reflect.Method.invoke(Native Method)
W/System.err( 2669): at java.lang.reflect.Method.invoke(Method.java:372)
W/System.err( 2669): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:899)
W/System.err( 2669): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:694)
```
fixes https://github.com/facebook/react-native/issues/36052
## Changelog
[ANDROID][FIXED] - Fixed jscexecutor crash on Android which is caused from NDK incompatibility
Pull Request resolved: https://github.com/facebook/react-native/pull/36062
Test Plan: tested on [jsc-android instrumented test](https://github.com/react-native-community/jsc-android-buildscripts/tree/2.26.1/test) (based on react-native 0.71.2)
Reviewed By: cipolleschi
Differential Revision: D43040295
Pulled By: cortinico
fbshipit-source-id: e0e5b8fb7faa8ee5654d4cde5f274bef4b517376
Summary:
Both Android and iOS allow you to set application specific user interface style, which is useful for applications that support both light and dark mode.
With the newly added `Appearance.setColorScheme`, you can natively manage the application's user interface style rather than keeping that preference in JavaScript. The benefit is that native dialogs like alert, keyboard, action sheets and more will also be affected by this change.
Implemented using Android X [AppCompatDelegate.setDefaultNightMode](https://developer.android.com/reference/androidx/appcompat/app/AppCompatDelegate#setDefaultNightMode(int)) and iOS 13+ [overrideUserInterfaceStyle](https://developer.apple.com/documentation/uikit/uiview/3238086-overrideuserinterfacestyle?language=objc)
## Changelog
[GENERAL] [ADDED] - Added `setColorScheme` to `Appearance` module
Pull Request resolved: https://github.com/facebook/react-native/pull/35989
Test Plan:
This is a void function so testing is rather limited.
```tsx
// Lets assume a given device is set to **dark** mode.
Appearance.getColorScheme(); // `dark`
// Set the app's user interface to `light`
Appearance.setColorScheme('light');
Appearance.getColorScheme(); // `light`
// Set the app's user interface to `unspecified`
Appearance.setColorScheme(null);
Appearance.getColorScheme() // `dark`
```
Reviewed By: NickGerleman
Differential Revision: D42801094
Pulled By: jacdebug
fbshipit-source-id: ede810fe9ee98f313fd3fbbb16b60c84ef8c7204
Summary:
This is a two step (2/2) fix to a race that could caused a DELETE...CREATE mutations being sent over to the fabric mounting layer. Such combination was assumed not possible from the differ (https://fburl.com/code/kg8z9t4w), yet it happened at least in the existence of layout animation and when certain commits happen while animation is active.
This diff fixes all potential races in the Fabric mounting layer directly. It captures all the `DELETE...CREATE` combinations and stop those from passing down to the native platforms. This should fix all such races should them not captured by the fix in the layout animation.
To help understand other races better, I also logged here to indicate such race so that future crashes will have more context.
Changelog:
[General][Fixed] - Fix edge case when layout animation caused delete and create mutations in the same batch
Reviewed By: javache
Differential Revision: D41900201
fbshipit-source-id: 280502ca32ce87a9e483cd859b11bcd3e5c4a435
Summary:
This is a prototype to add circular dependencies detection on CMake for ReactCommon and ReactAndroid.
It can be enabled per module and works as follows:
```
set(ALLOWED_HEADER_IMPORT_PATHS
react/renderer/graphics
react/debug)
check_for_circular_dependencies("${ALLOWED_HEADER_IMPORT_PATHS}")
```
The allowed header import path must be manually specified as libraries are exposing wrong header search paths (so can't be reused).
The CI will be red till the circular dependency on `graphics` is resolved.
Changelog:
[Internal] [Changed] - Add macro to detect circular dependencies on Cmake
Reviewed By: cipolleschi
Differential Revision: D42927036
fbshipit-source-id: b1393dfd43fd042e2ebf1d5b46b24bd9f5e20d58
Summary:
- Bridgeless is using a deprecated FabricUIManager constructor which bridge doesn't use, and is the only one using it, this diff migrated bridgeless to use the same FabricUIManager constructor as bridge
- Remove static view config check (mShouldDeallocateEventDispatcher), instead use Bridgeless check since SVC is enabled in Bridgeless but not in Bridge.
Changelog:
[Android][Changed] - Align creation of FabricUIManager with bridge
Reviewed By: javache
Differential Revision: D42681489
fbshipit-source-id: b9c7c4a81a98db52e881138cc85be0e85df636d9
Summary:
Changelog: [Internal] Support hovering in/out of root views
Prior to this change, we did not have signal when an input device moved out of the root view and so our internal state would not be aware and we would not trigger enter/leave events.
This diff starts listening to `HOVER_EXIT` events as dispatched from `onInterceptHoverEvent` and assumes that's the right event to signal a cursor has moved out of the root view. We dispatch the relevant leave events for this case and update our internal state to ensure the next `HOVER_MOVE` in our rootview, will properly dispatch the enter events.
## Investigation for creating this diff
Determining the signal for when an inputDevice enters/exits our rootview wasn't straight-forward.
From my understanding Android event dispatching follows a similar capture, bubbling phase as web. With `onIntercept..` handlers to swallow events. See this explanation: https://suragch.medium.com/how-touch-events-are-delivered-in-android-eee3b607b038 and this video talk: https://youtu.be/EZAoJU-nUyI?t=929
However when trying to understand hover enter/exit events on the root view, my understanding of this logic broke down.
Here's what confused me:
* When moving a cursor from inside to outside the root view, I would receive `HOVER_ENTER/EXIT` MotionEvents on `onInterceptHoverEvent` and since we did not swallow them, we'd receive those same events on the bubble up in `onHover`. That makes sense.
* However, when I hovered from the rootview into a child view, I would receive MotionEvents of `HOVER_ENTER/HOVER_EXIT` in the `onHoverEvent` handler of the rootview without having seen them in the `onInterceptHoverEvent` (re: capture phase down). This was confusing, where was the capture down?
* What tips me off that these events (`HOVER_ENTER/EXIT`) don't follow the classic capture, bubbling model as explained in the linked article, is that I don't receive `HOVER_ENTER/HOVER_EXIT` events for each child view in the root view's `onInterceptHoverEvent`.
* Like when a cursor moves from root -> child, I'd expect to motion events 1. exit for the rootview, 2. enter for the child view. But I never receive the 2. from the root view --
* I also wonder if the wording for `HOVER_EXIT` events mean that these events are directly dispatched to the view? Re: ["This action is always delivered to the window or view that was previously under the pointer."](https://developer.android.com/reference/android/view/MotionEvent#ACTION_HOVER_ENTER)
* There also seems to be some optimizations around the dispatch path as mentioned in this video at this timestamp: https://youtu.be/EZAoJU-nUyI?t=929 for the UP gesture.. so maybe there's some optimization happening with hover events? I'm not sure how hover events are account for in gesture handling for Android.
Reviewed By: vincentriemer
Differential Revision: D42817315
fbshipit-source-id: 412c971c1d1e7afc0d67fadcc4417189967fe48c
Nicola Corti
Riccardo Cipolleschi
David Vacca
Genki Kondo
Pieter De Baets
Ruslan Shestopalyuk
Ana Margarida Silva
Samuel Susla
Felipe Perez
Moti Zilberman
Tomek Zawadzki
Ramanpreet Nara
Xin Chen
Vincent Riemer
aleqsio
Nick Gerleman
yinfei
Lulu Wu
Matthijs Mullender
Kudo Chien
Birkir Gudjonsson
Fabrizio Cucci
Luna Wei
