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:
Pull Request resolved: https://github.com/facebook/react-native/pull/35967
In https://github.com/facebook/react-native/issues/35936 we observed that the presence of AbsoluteSizeSpan may lead to hangs when using the Grammarly keyboard on Samsung.
This mitigation makes it so that we do not emit this span in any case where it is sufficient to rely on already set EditText textSize. In simple cases, tested on two devices, it causes typing into the TextInput to no longer hang.
This does not fully resolve the issue for TextInputs which meaningfully use layout-effecting spans (or at least font size), such as non-uniform text size within the input. We instead just try to reduce to minimum AbsoluteSizeSpan possible.
Testing the first commit was able to resolve hangs in some simpler inputs tested, by me and cortinico.
Changelog:
[Android][Fixed] - Mitigation for Samsung TextInput Hangs
Reviewed By: cortinico
Differential Revision: D42721684
fbshipit-source-id: e0388dfb4617f0217bc1d0b71752c733e10261dd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35897
Fixes https://github.com/facebook/react-native/issues/35894
Android 11 added native support for querying whether the IME is present along with its size, as part of the WindowInsets API. D38500859 (https://github.com/facebook/react-native/commit/1e48274223ee647ac4fc2c21822b5240f3c47e4c) changed our logic for Android keyboard events to use it when available, fixing a longstanding issues where we could not reliably tell where the keyboard was open depending on softInputMode.
An androidx library WindowInsetsCompat aimed to backport some of the functionality to older versions of Android, with the same API, documenting IME queries to work down to API level 23 (Android 6). I used this, so that we would be able to remove our own logic for detecting keyboard insets once we supported 23+.
From an issue report, WindowInsetsCompat is not accurately returning whether the IME is open on at least Android 9. So this change makes it so we only use WindowInsets methods when they are provided by the OS (a tested golden path), and otherwise use the previously working heuristics on anything older.
Changelog:
[Android][Fixed] - Do not use WindowInsetsCompat for Keyboard Events
Reviewed By: christophpurrer
Differential Revision: D42604176
fbshipit-source-id: da6a0bbc34c36f8e6d4e4ac07bc96da048fd6aa8
Summary:
react-native-navigation allows to register React components to be included in the navigation top bar as buttons, the way this work is by using the AppRegistry. When the ViewTreeObserver executes the `CustomGlobalLayout` we are checking for the RootWindowInsets in the `checkKeyboardEvents` which in the case for the top bar component it returns null and the **WindowInsetsCompat.toWindowInsetsCompat** function throws if the insets are null causing the app to crash.
Interestingly in the function `checkForKeyboardEventsLegacy` the null value is being checked, so I guess it was overlooked in the newer function.
## Changelog
[ANDROID] [FIXED] - Fix ReactRootView crash when root view window insets are null
Pull Request resolved: https://github.com/facebook/react-native/pull/35869
Test Plan:
The following videos show how the app crashes as soon as we attempt to pop a screen that contains a react component as a button in the navigation top bar and how it correctly pops to the previous screen after applying the fix
| Crash | Fix |
| -- | -- |
| https://user-images.githubusercontent.com/6757047/213116971-fe693989-f978-438c-b8f9-fc56f2a477c8.mp4 | https://user-images.githubusercontent.com/6757047/213118352-fe258f28-07aa-4d17-98d2-97136464ffd5.mp4 |
Reviewed By: cipolleschi
Differential Revision: D42580156
Pulled By: cortinico
fbshipit-source-id: 4dbd656d7c8148df67668a2a50913206bc35c07f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35857
It seems like there is an incompatibility between NDK 23 (shipped in 0.71)
and the usage of custom `CMAKE_BUILD_TYPE` we do for Hermes.
Specifically the `-DCMAKE_BUILD_TYPE=Release` we specify for the debug
variant of Hermes is partially ignored by the new Android native build toolchain.
See https://github.com/android/ndk/issues/463 for mentions on how the
toolchains requires CMake 3.20+
As AGP 7.3 defaults to use CMake 3.18 unless specified, and NDK 23 unless specified.
AGP 7.4 defaults to use CMake 3.22 unless specified, and NDK 23 unless specified.
See: https://developer.android.com/studio/releases/gradle-plugin#7-4-0
Here I'm:
1. Bumping the docker image to an image that contains the CMake 3.22
2. Updating the logic for building `react-native` & `hermes-engine` to use 3.22
3. Provide fallbacks if the user specified `CMAKE_VERSION`
Template tests will run on AGP 7.3 and will still use CMake 3.18, but I forecast
no problem there as the user is not supposed to specify custom `CMAKE_BUILD_TYPE`.
This is only a problem as we build `hermes-engine` with custom build types.
Changelog:
[Android] [Fixed] - Bump CMake to 3.22.1 to properly honor CMAKE_BUILD_TYPE
Reviewed By: cipolleschi
Differential Revision: D42544864
fbshipit-source-id: efd0f51120370fb808337c201df31d71f4ddfdbc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35619
Reference https://github.com/reactwg/react-native-releases/discussions/41#discussioncomment-4353534
I'm exposing `ReactAndroid/src/main/jni/react/cxxcomponents` to be consumed via prefab.
It will be available to both: `react_nativemodule_core` and `reactnativejni`
Changelog:
[Internal] [Changed] - Expose ReactAndroid/src/main/jni/react/cxxcomponents via prefab
Reviewed By: cipolleschi
Differential Revision: D41965512
fbshipit-source-id: 3a5a7473267e2e161d9d7fb0e8dfa74593b47b6e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35521
Inside RC3 the jscexecutor target was prepared for prefab consumption
but not properly exposed.
This was not caught by the CI as we're not effectively using this target,
but some of our popular libraries do (i.e. Reanimated). I'm exposing it here.
Changelog:
[Internal] [Changed] - Properly expose `jscexecutor` as a prefab target
Reviewed By: javache
Differential Revision: D41648349
fbshipit-source-id: 1a04bc21aa50eece304828ce1d99ae795a51af48
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35506
In our build we had a mixture of `_` and `-` to separate targets.
Dashes don't play well with Gradle + as we expose them now via Prefab,
let's stick to use only underscores
Changelog:
[Internal] [Changed] - Rename target to don't use dashes
Reviewed By: cipolleschi
Differential Revision: D41578938
fbshipit-source-id: 8aa44aa2dc7bf4822b45e5044532837b989817d2
Summary:
This is the last library that we should expose via Prefab.
Thanks to cipolleschi 's work here moving the file to `/ReactCommon/jsc` folder
we can easily expose it to be consumed by third parties.
Changelog:
[Internal] [Changed] - Expose `jscruntime` to be consumed via Prefab
Reviewed By: cipolleschi
Differential Revision: D41534564
fbshipit-source-id: fb4b2d801def8caf71638dcb74eb87f8230984d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35482
This change moves the JSCRuntime.h/cpp into a `jsc` folder.
This change is required for several reasons:
1. on iOS, the new `jsi`, `jsidynamic` and `jsc` setup is breaking the `use_frameworks!` with `:linkage => :static` option with the old architecture. So it is a regression.
2. JSCRuntime is required by some libraries and needs to be exposed as a prefab and the current setup makes it hard to achieve.
allow-large-files
[General][Changed] - Move JSCRuntime into a separate pod/prefab
Reviewed By: cortinico
Differential Revision: D41533778
fbshipit-source-id: 642240c93a6c124280430d4f196049cb67cb130b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35461
This is another library which is adding prefab support as it's needed by
Expo libraries and Reanimated.
Changelog:
[Internal] [Changed] - Allow `reactnativejni` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D41520801
fbshipit-source-id: 91142a5b5051cfba478d93a2475a178eed6fbb29
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35460
Reanimated reported that `react_nativemodule_core` was missing some headers.
Specifically the one from ReactAndroid::react_debug, ReactAndroid::react_render_core, ReactAndroid::glog,
and ReactAndroid::react_render_debug.
I'm adding them here so they get included in the shipped headers for `react_nativemodule_core`
Changelog:
[Internal] [Changed] - Add missing headers to `react_nativemodule_core` prefab module
Reviewed By: cipolleschi
Differential Revision: D41520751
fbshipit-source-id: 4627a2d0f880d4bb3ff2f0e43cd735cf9a3f2f9a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35458
We're adding prefab support for those modules as they're needed by Reanimated
and we're exposing headers for them as well.
Changelog:
[Internal] [Changed] - Add prefab for _uimanager _scheduler and _mounting
Reviewed By: cipolleschi
Differential Revision: D41520606
fbshipit-source-id: 76f3c81705e99057b92cd9b86d0601a2b1410f95
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35457
This exposes `hermes-executor` to be consumed via prefab so that
libraries can depend on it and use its symbols if needed (Expo and Reanimated need it).
Changelog:
[Internal] [Changed] - Expose `hermes-executor` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D41520019
fbshipit-source-id: d590a043ea89fdd8ff41b0ed20900c9cf381a1e4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35454
Historically, we used to have hermes-executor debug and release as separate dynamic libraries.
This makes it impossible to prefab this library, so I have to reconcile it into a single library.
This will also help keep the setup consistent with the internal (BUCK) where we have a single target.
Changelog:
[Internal] [Changed] - Consolidate hermes-executor-debug and -release inside a single target
Reviewed By: cipolleschi
Differential Revision: D41519119
fbshipit-source-id: d9ddc30b72164daa29c735836ea433fd4d917fc8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35379
This diff moves the publishing coordinates from:
```
com.facebook.react:react-native
com.facebook.react:hermes-engine
```
to
```
com.facebook.react:react-android
com.facebook.react:hermes-android
```
I've picked those they are the most layout friendly when building from source, but we can discuss if we want others.
I've updated the Gradle plugin to have a dependencySubstitution rule + update the template with those changes.
It should now be possible to still use `implementation("com.facebook.react:react-native:+")` inside libraries
on 0.71+ and RNGP will resolve dependencies correctly.
Changelog:
[Android] [Changed] - Void the Maven coordinates for react-native and hermes-engine
Reviewed By: cipolleschi
Differential Revision: D41380525
fbshipit-source-id: 91e059fa261acb89bee7ca0c79c30c3d856a2c80
Summary:
From exception logging, found crashes due to `Attempt to invoke virtual method 'int android.view.ViewGroup.getChildCount()' on a null object reference`. Tracing through the stack, it appears the constructor for `ViewGroup` conditionally calls `initializeScrollbarsInternal()`, which in turn calls `getChildCount()`. However `ReactModalHostView` overrides `getChildCount()`, so `getChildCount()` is called before `ReactModalHostView` constructor completes, resulting in null reference when accessing `mHostView` from `getChildCount()`.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Fixed] - Fix crash on initialize modal
Pull Request resolved: https://github.com/facebook/react-native/pull/35380
Test Plan: In the rn-tester project, display a modal.
Reviewed By: javache, cipolleschi
Differential Revision: D41392235
Pulled By: ryancat
fbshipit-source-id: ce78e4d458ad41769e78139ea0a8a038384e830d
Summary:
Hi, while adjusting [react-native-screens](https://github.com/software-mansion/react-native-screens) to `0.71.0-rc.0` I encountered the same problems as reported [here](https://github.com/reactwg/react-native-releases/discussions/41#discussioncomment-4085694) by WoLewicki.
Basically inside `CMake`'s `foreach` loop iterator variable is not being expanded to the actual value:
```cmake
foreach(autolinked_library ${AUTOLINKED_LIBRARIES})
target_link_libraries(autolinked_library common_flags) // <-- here we are literally linking to "autolinked_library".
endforeach()
```
## Changelog
[Android] [Fixed] - Fix Android autolinking failing because of not expanded variable
Pull Request resolved: https://github.com/facebook/react-native/pull/35306
Reviewed By: christophpurrer, cipolleschi
Differential Revision: D41220408
Pulled By: rshest
fbshipit-source-id: 12ce993f0c5227ca7d3c2cc272fe3739126930b3
Summary:
In the top js errors there are 2 mids related to segment fetching:
- requireForFacebook.js:unknownModuleError (https://www.internalfb.com/logview/details/facebook_android_javascripterrors/ba11461526aff8a6842401b35b02f5a4), 11.64 K vs. 524
- asyncRequire.js:verifySegment (https://www.internalfb.com/logview/details/facebook_android_javascripterrors/5452ba893b8d9ba8e97e070cf6976b65) 5.39 K vs. 180
Both errors will result in surface not loading.
A lot of traces have logs similar with the following:
```11-01 19:57:51.166 27735 7626 W fb4a.BridgelessReact: registerSegment(segmentId = "1090", path = "/data/data/com.facebook.katana/app_overtheair/resources/412137089/414433453/hbc-seg-1090__DELIM__main.jsbundle")
11-01 19:57:51.167 27735 7445 I ReactNativeJS: Module 39122 in segment 0 doesn not exist moduleDefiner
11-01 19:57:51.171 27735 7445 E ReactNativeJS: Error: Requiring unknown module "39122"., js build: 414433453
11-01 19:57:51.175 27735 7445 E ReactNativeJS: Error: Segment meta module is not setup properly. Details: segmentId = 1090, metaModule === undefined
11-01 19:57:51.175 27735 7445 E ReactNativeJS:
11-01 19:57:51.175 27735 7445 E ReactNativeJS: This error is located at:
```
RegisterSegment lives through 3 threads while in bridge there are only 2 threads involved (native & JS):
- Native thread, log printed (fb4a.BridgelessReact: registerSegment...)
- Background thread: no log, added in this diff (Finish registerSegment...)
- JS thread: logs not printed, should print logs here:
https://www.internalfb.com/code/fbsource/[60521987354ed1ef9a0d10bafc60db3c25302ab4]/xplat/ReactNative/venice/ReactInstance.cpp?lines=308-330
Since the JS thread logs aren't printed and there are segment errors right after calling registerSegemnt, I think registerSegment is not done. It could be caused by:
- ReactInstance being null, I added logs in background thread to verify (Finish registerSegment...) since dispatching to background thread relies on non-nullable ReactInstance.
- Work on JS thread hasn't been executed when trying to use/verify the segment. I added atomic method ```registerSegmentAtomic``` to make sure JS thread is blocked until segment is fully registered.
```registerSegmentAtomic``` will be tested behind gating added in D40917444.
Changelog:
[Android][Changed] - Add feature flag enableAtomicRegisterSegment
Reviewed By: RSNara
Differential Revision: D40921759
fbshipit-source-id: 84221aa81f0c549f931a4847b154187299639ef4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35181
As the title says, this unblocks `test_buck` by removign the lambdas used inside test.
Changelog:
[Internal] [Changed] - Fix test_buck by not using lambdas inside ReactImagePropertyTest
Reviewed By: cipolleschi
Differential Revision: D40958412
fbshipit-source-id: 60b8609a25985230dfd6c4dcdf983dc2a8cfaf64
Summary:
Saw in the logs an ever increasing number of warnings coming from WebSocketModule about requesting an instance that has already gone away.
On module invalidation we should close all outstanding websockets, as they will no longer be able to send events to JS.
Changelog: [Android][Fixed] On instance destroy, websockets are correctly closed
Reviewed By: mdvacca
Differential Revision: D40897255
fbshipit-source-id: 1578de8baa342479d14ee1070c3314d45c7fbd8d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35176
This commit extends the ReactNative-application.cmake logic so
that if the app is using codegen at the app level, the generate library
is properly built and linked.
It helps us simplify the RN Tester setup and makes it easier for app users
to use the codegen at the app level.
Changelog:
[Internal] [Changed] - [Android] Link against the app codegen if available
Reviewed By: cipolleschi
Differential Revision: D40936941
fbshipit-source-id: 26fa4d764fb369c987e94e0c3bce61841b982b27
Summary:
Changelog: [Internal]
Override logic for determining whether a dispatched `Event` triggers a native `EventAnimationDriver`.
Natively driven AnimatedEvents on bubbling events is not supported. `PointerEvents` requires this and this diff adds custom matching logic such that if a parent specifies an `AnimatedEvent` on `onPointerMove` and a child view dispatches it, the `AnimatedEvent` will still fire.
Reviewed By: javache
Differential Revision: D38722563
fbshipit-source-id: 7cde57eaff9584b33c6ab15f1fe85c0a9bac132e
Summary:
Changelog: [Internal] - Refactor match logic on determining whether to run an EventAnimationDriver (drivers for natively animated events) for an Event dispatched.
Previously, drivers were stored by key on the NativeAnimatedNodesManager (based on event handler and viewTag) and has been refactored to be stored in a list for easier matching.
This diff changes it so the match logic for running an EventAnimationDriver happens on the Event instance. This change is motivated by PointerEvents needing custom match logic (done on a following change).
Reviewed By: javache
Differential Revision: D40691002
fbshipit-source-id: e4f6742a2af3b751214aefa1fc069f65e8e71d77
Summary:
This is a follow up action item from S295231 and T136039462 where we want to make sure null uri in image source is handled properly. This diff adds an unit test to make sure we are using transparent image when uri is null.
Changelog:
[Android][Internal] - Add unit test to ImageView for null uri in source
Reviewed By: javache
Differential Revision: D40732791
fbshipit-source-id: fd468bfe7c33a4f3f8913ead3e84a1770d7c907f
Distiller
Kudo Chien
Distiller
Nick Gerleman
Distiller
Elias Nahum
Nicola Corti
Distiller
Distiller
Distiller
Distiller
Distiller
Riccardo Cipolleschi
Distiller
Distiller
Alpha
Kacper Kafara
Oleksandr Melnykov
Christoph Purrer
Distiller
Lorenzo Sciandra
Distiller
Distiller
Distiller
Riccardo Cipolleschi
Distiller
Lulu Wu
Pieter De Baets
Ramanpreet Nara
Luna Wei
Xin Chen