Summary:
Instead of having a special flag just for View MapBuffer props, we now use one flag to indicate that MapBuffer should be used for all props; each XShadowNode must set a special trait indicating if that ShadowNode supports MapBuffer props.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D38708718
fbshipit-source-id: b398ec62a0db9c0ff23c0007c5503cf2838c4173
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34829
I realized there is a race condition in how prefab headers are prepared and bundled. If the download of boost is not 'fast enough' the headers will be missing during prefab preparation.
This fixes it.
Changelog:
[Internal] [Changed] - Fix broken template tests due to missing boost headers
Reviewed By: cipolleschi
Differential Revision: D39968622
fbshipit-source-id: 4680f84c15f4443a16def45d41a10a1083f4f196
Summary:
I accidentally broke `main` as I added a PRIVATE link for external libraries.
I need to get back to this, but for the meantime I'm disabling this linking
to make the CI green.
Changelog:
[Internal] [Fixed] - Unblock template jobs on main due to accidental PRIVATE linking
Reviewed By: cipolleschi
Differential Revision: D39932205
fbshipit-source-id: 5acbf567e0c194224a01141273665a293ead8e32
Summary:
This adds the YGGutter enum, used to choose between row/column gap variants (row-gap, column-gap, gap).
This used later in changes from https://github.com/facebook/yoga/pull/1116, in the APIs which deal with setting gap on style on yoga node.
Note the original PR called this `YGGap`, but this ending up leading to a couple public method signatures that could appear ambiguous:
1. `SetGap(YGGap gap, float gapLength)`: Enums like `YGAlign` are the vaues for an `align` prop. `YGGap` controls the variant of the gap (like `YGEdge` does for left/right/top/bottom variants). So the enum reads as if it is the `gapValue`, and it looks like we have two of the same parameter.
2. `SetGap(YGGap gapDirection, float gap)`: This is misleading, because the direction gaps flow is the cross-axis of flex-direction.
3. `GetGap(YGGap gap)`: `gap` is the variant, but looks like an out param.
The [CSS Box Alignment](https://www.w3.org/TR/css-align-3/#column-row-gap) spec refers to these gaps as "Gutters", which removes the ambiguity.
Changelog:
[General][Added] - Add YGGutter Enum
Reviewed By: yungsters
Differential Revision: D39922412
fbshipit-source-id: 4b0baf800fecb3d03560a4267c7fb4c4330fd39e
Summary:
https://github.com/facebook/yoga/pull/1116 adds a new enum. The enum generator is out of date with copyright header, and some codemods, but it also looks like there were manual changes, types added, etc since generation. I fixed up the script to incorporate generating the changes folks made manually, and also added an enum that was previously only added manually to the C ABI.
Changelog:
[General][Fixed] - Fixup Yoga Enum Generator
Reviewed By: yungsters
Differential Revision: D39922252
fbshipit-source-id: b678fa9a43a896873d8c434745bdaf3f16fd991f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34819
This is crashing on A12 because of using the regular Context instead of the application context. That said, this probably makes more sense as a log warning.
Reviewed By: javache
Differential Revision: D39852058
fbshipit-source-id: 1ac93f8cc9ecdb14f60baca175c8ecff2ff42ac0
Summary:
This removes the old way of consuming `libreact_nativemodule_core.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
This is the last mode that we'll have to handle the prefab for.
I'll do the cleanup just after this change landed.
Changelog:
[Internal] [Changed] - Move `react_nativemodule_core` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39929261
fbshipit-source-id: 61669da2cfd0545160a2a4c596c8e4adb22303ec
Summary:
This removes the old way of consuming `libfolly_runtime.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Moreover, I've exposed a `folly-flags.cmake` file which can be used by libraries
to know which lists of flags they need to use for Folly.
Changelog:
[Internal] [Changed] - Move `folly_runtime` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39928571
fbshipit-source-id: 4864c37813ec681a6a464c97de6dfc078f5553f1
Summary:
This removes the old way of consuming `libyoga.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `yoga` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39927496
fbshipit-source-id: f7ab2a3aab3cb42effa648dfeff6711d183260e4
Summary:
This removes the old way of consuming `libreact_renderer_mapbuffer.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_renderer_mapbuffer` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39927266
fbshipit-source-id: e82c2bda02c85a2a6747b92a3f20f2a5118bda65
Summary:
This removes the old way of consuming `libfabricjni.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `fabricjni` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39927210
fbshipit-source-id: dbd8814a6cad38d09484561120df911ab24b5f8a
Summary:
This removes the old way of consuming `libglog.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `glog` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39927147
fbshipit-source-id: 99f0241da1dece0efc8d928c3d25f30f3fa48a09
Summary:
This removes the old way of consuming `libjsi.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `jsi` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39924434
fbshipit-source-id: cb92d3a4ed6cb87e75462082506f310feb7bec9f
Summary:
This removes the old way of consuming `librrc_view.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `rrc_view` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39924231
fbshipit-source-id: 231809631f807ea2ea40d2581759f391adfba94d
Summary:
This removes the old way of consuming `libreact_render_graphics.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_render_graphics` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39923620
fbshipit-source-id: 9edb6557b4d195e1703b1ae532ca14126930a43a
Summary:
This removes the old way of consuming `libreact_render_core.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_render_core` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39923551
fbshipit-source-id: b800d4369f0de8edbc68b11d9efecf2cb5ea68c1
Summary:
This removes the old way of consuming `react_newarchdefaults.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_newarchdefaults` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39857115
fbshipit-source-id: 194a75b530b21e593b0390565a3b91155e07f17e
Summary:
This removes the old way of consuming `libreact_render_componentregistry.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_render_componentregistry` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39856487
fbshipit-source-id: 98006054481a5635ee3241e3281455cd934eca08
Summary:
This removes the old way of consuming `react_debug.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_debug` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39889945
fbshipit-source-id: e31f3c3027718a54c0a7228db00d145c1f3f7873
Summary:
This removes the old way of consuming `react_codegen_rncore` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_codegen_rncore` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39855726
fbshipit-source-id: a8ee00ea31422a20832909b9d7e5a8123cf88c84
Summary:
This removes the old way of consuming `runtimeexecutor` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `runtimeexecutor` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39852978
fbshipit-source-id: 87795118f1bcf496a3c50791f920d8b230932555
Summary:
This removes the old way of consuming `turbomodulejsijni.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `turbomodulejsijni` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39851647
fbshipit-source-id: 6201546ad47a53b366a54b022457fce7b744f064
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34802
This removes the old way of consuming `libreact_render_debug.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_render_debug` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39849622
fbshipit-source-id: 45451dfe92ecce94d1b466094baae05a75ed803f
Summary:
I've just realized that CMake is ignoring `ccache`, even if you have it
installed. This is the necessary change needed to verify if the user
has `ccache` installed and eventually use it.
While not a necessary change for Prefab supprot, this is a nice to have
that I've discovered while working on it.
Changelog:
[Internal] [Changed] - Make sure ccache is considered as part of the CMake build
Reviewed By: cipolleschi
Differential Revision: D39815089
fbshipit-source-id: be62e5fe98954593fd907ec21c41950a967cff04
Summary:
Changelog: [Internal][Bridgeless][iOS]
# Before diff
Be in Venice > run Metro > run FBiOS > navigate to any RN surface.
`UIManagerBinding createAndInstallIfNeeded` happens After `ReactInstance loadScript -> evaluateJavaScript`: install Fabric UIManager before main bundle execution
Reviewed By: RSNara
Differential Revision: D39760231
fbshipit-source-id: f17bf02e9b1fb0f9b0ff24c86aa6dc9349c42192
Summary:
We want to fix the order of execution of layout, layout effects and passive effects in React Native, but the use of the Fabric background executor for layout complicates this (and other things).
This brings back a flag to disable this background thread to do layout synchronously in JavaScript, before the execution of layout effects and passive effects.
This is expected to regress performance on some screens, so we need to address the antipatterns in those screens before shipping this.
Changelog: [internal]
Reviewed By: javache
Differential Revision: D39727131
fbshipit-source-id: 4323b089234d3304ca3bfe5697668fb44ac64c12
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34754
This Diff is the second step of enabling the CodeGen to parse and generate a NativeState for the components.
The feature has been largely requested by the OSS community but it could be also helpful for people in Meta.
## Changelog
[General][Added] - Always generate an empty NativeState for Fabric Components
Reviewed By: cortinico
Differential Revision: D39696435
fbshipit-source-id: e24768af78f59696c0b4db009e8065bb5c89316b
Summary:
when specifying dev server without port, e.g. http://www.example.com/, there are some issues.
1. redbox error
<img src="https://user-images.githubusercontent.com/46429/190540390-8ee420f2-7642-427b-9f2e-e0c6d31015f8.png" width="30%">
2. showing -1 in loading view
<img src="https://user-images.githubusercontent.com/46429/190540727-158f35ad-359f-443a-a4b0-768dd2f7e400.png" width="50%">
the root cause is coming from [`java.net.URL.getPort()` will return -1 when the url doesn't have a port](https://developer.android.com/reference/java/net/URL#getPort()). this pr replaces the parser to [`okhttp3.HttpUrl`](https://square.github.io/okhttp/4.x/okhttp/okhttp3/-http-url/#port) that it will have default port 80 for http or port 443 for https. the two call paths should only serve http/https address, not file:// address. it should be safe to change from java.net.URL to okhttp3.HttpUrl.
not fully related, in the case above, android will connect to `ws://www.example.com/:8097` for react-devtools
we should strip the trailing slash in *setUpReactDevTools.js*
## Changelog
[Android] [Fixed] - Fix port as -1 if dev server without specifying port on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/34705
Test Plan:
test on rn-tester with the following steps
1. `yarn start`
2. open another terminal and run `ngrok http 8081` and it will return a tunnel url, e.g. `71a1-114-36-194-97.jp.ngrok.io`
3. open dev setting in app and change the dev server to `71a1-114-36-194-97.jp.ngrok.io`
5. reload the app
Reviewed By: cipolleschi
Differential Revision: D39573988
Pulled By: cortinico
fbshipit-source-id: 397df90ab30533207bd87a3f069132d97c22c7fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34747
Just a minor cleanup after the AGP bump.
Changelog:
[Internal] [Changed] - Cleanup of ReactAndroid/build.gradle after AGP 7.3.x bump
Reviewed By: cipolleschi
Differential Revision: D39687286
fbshipit-source-id: 441e449b51b25e4152cf1e7e7e22c7c9f1432d05
Summary: Changelog: [Internal] - A refactor to pass the object PointerEventState containing relevant state / and also properties for pointerEvent objects
Reviewed By: vincentriemer
Differential Revision: D39626285
fbshipit-source-id: e2ff5313ef03d7d2d36c35ca459950ec07650df2
Summary:
Changelog: [Internal]
Stop using `TouchEventCoalescingKeyHelper` for tracking and stop making the distinction between traditional touch events (down, up, move) vs hover only events. The only events that currently coalesce are `onpointermove` events. This change uses just one counter now that we increment whenever some non-move event is fired.
Let me know if there's a simpler way to ensure counter doesn't overflow.
This change also ensures we're overriding `getCoalescingKey` which isn't used by Fabric but for old event emitter it might be (which we use for native animations). Part of that requires the `coalescingKey` to be a short so updated to that.
There was also a bug where I forgot to pass `mLastButtonState` to one of the dispatch calls. Will be wrokign on refactor so its less argument soup.
Reviewed By: javache
Differential Revision: D39530927
fbshipit-source-id: 689fa98580b206a480cc08121971cdf96bdbbfaa
Summary:
The previous approach to set a heading in Android required us to trick the accessibility service into thinking that this element was the heading inside of a list, which used to be the only place you could use headings on Android.
This worked for the most part, but could cause problems in specific circumstances, such as if that element actually *was* part of a list. Since we were overriding its CollectionItemInfo, and presenting it as the first item in a single column list, the parent list could have confusing announcements such as announcing this item as "Item 1" even if it was not the first item in the actual list.
Since API 28, there has been an API to set any view as a heading (https://developer.android.com/reference/android/view/View#setAccessibilityHeading(boolean)).
This switches our implementation to use this new API via the AccessibilityNodeInfoCompat class for backwards compatibility to older API versions.
Changelog:
[Android][Changed] - Simplify Accessibility Heading role implementation.
Differential Revision: D39076827
fbshipit-source-id: 583dc1e9d2779a4efa5f98cabef506df2770d892
Summary:
This diff moves Component and ComponentManager classes -> react/cxxcomponents. The purpose is to be able to use these classes from any platform, not only Android
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D39531533
fbshipit-source-id: 4732aa7bf59d82dae11441212975f0e225c6d458
Summary:
This diff integrates the registration of C++ component into React Native Android
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D38725769
fbshipit-source-id: 33eb9ebb93983c4038529748758eac3e43eec3e5
Summary:
CppViewMutationWrapper is a class that will be used to execute operations to mutate C++ Components in React Native Android
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D38725765
fbshipit-source-id: 3dfe11deb873750a78f6dbbaee82b62134908de4
Summary:
This diff introduces the APIs that will be used to register C++ components in React Native Renderer for Android
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D38725768
fbshipit-source-id: a7116b787f83544282230666d9d5acbfb1df4047
Summary:
Customize gradle/buck to be able to build fabric C++ components files
changelog: [internal] internal
Reviewed By: cortinico, sammy-SC
Differential Revision: D39448416
fbshipit-source-id: 3beddf27082728e2316e483c2541c7405e4c57f7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34690
While working on another part of the codebase I realized that
our Unit Tests are not compiling due to references to missing classes.
I'm cleaning them up + hooking the compileTest task inside the
`buildAll` task so at least they will be compiled on both CIs.
Changelog:
[Internal] [Changed] - Make the Android unitTests compile
Reviewed By: cipolleschi
Differential Revision: D39501945
fbshipit-source-id: 03d3e4872d6c738b8b85d1fef9302ac230e857d2
Summary:
`Android.mk`s are no longer used for internal Gradle tasks since [First Round of CMake files for React Android](b676ca560d) and [CMake setup for ReactAndroid](e3830ddffd)
## 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
-->
[General] [Fixed] - Remove Android.mk from internal Gradle task
Pull Request resolved: https://github.com/facebook/react-native/pull/34687
Test Plan: None
Reviewed By: cipolleschi
Differential Revision: D39541322
Pulled By: cortinico
fbshipit-source-id: 421591effab2c1a82bcacff656360a2d02439a53
Summary:
This diff removes the feature flag ReactFeatureFlags.enableSpannableCache and it's already disabled MC
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D39449840
fbshipit-source-id: 69a514b611c1179f2160a1bfd4c4199538738448
Summary:
Remove feature flag: ReactFeatureFlags.enableScrollEventThrottle
This feature has been disabled for a while
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D39449184
fbshipit-source-id: c5ad0d43462422d284e14302fb9d7b39aa37da70
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34671
I'm simplifying the template further by:
- Do not expose a configurable dynamic library name. Let's use `appmodules`
and still allow the users to configure it, if needed.
- Move all the initialization logic inside the `JNI_OnLoad` method
- Cleanup the `DefaultReactNativeHost` to don't require a dynamic library
name but just a boolean.
Changelog:
[Android] [Changed] - Further simplify the New App Template by don't requiring the dynamic library name
Reviewed By: cipolleschi
Differential Revision: D39462948
fbshipit-source-id: 737733fc263162a0baf3b7a451e48b8616679d3b
Summary:
PlatformColor should work on all *color style attributes on all platform.
Partially fixes https://github.com/facebook/react-native/issues/32942
## Changelog
[Android] [Fixed] - Support PlatformColor in borderColor
Pull Request resolved: https://github.com/facebook/react-native/pull/33544
Test Plan: Open rn tester (USE_FABRIC=false) platform color api examples. Without the changes to ViewProps.java, it will error out.
Reviewed By: lunaleaps
Differential Revision: D39413519
Pulled By: NickGerleman
fbshipit-source-id: 58962ba2956aa3df45144108eec194aedf23886b
Summary:
This diff reduces the amount of C++ code in user space by:
- Moving all the C++ implementation of the .defaults package inside a `react_newarchdefaults` shared library
- Exposing only the entrypoint logic inside the RN-Tester's `OnLoad.cpp` file.
Changelog:
[Android] [Changed] - Reduce the amount of C++ code in user space for New Architecture
Reviewed By: cipolleschi
Differential Revision: D39381820
fbshipit-source-id: 9c4b5596b67b5a7ee58824319c80e325348ed06c
Summary:
Changelog: [Internal] - Stop dispatching pointer events when a child view has indicated it wants to handle a native gesture.
In discussion and alignment with web standards, we've decided to not dispatch any pointer events during a native gesture.
Currently, on ACTION_HOVER_MOVE, we remove child views of the native gesture handling view and continue dispatching onPointerMove for ancestor views. This change removes this logic and won't dispatch a onPointerMove event at all.
For all other MotionEvent actions, this is already the case.
Also adding an example in RNTester that involves a scrollView (which handles gestures during scrolling)
Reviewed By: javache
Differential Revision: D39377157
fbshipit-source-id: cb0a719f67136e31b68d6f6e794fee10b256bf21
Summary:
When I moved the C++ file around I only updated the Android-prebuilt.cmake
I haven't update the Android.mk equivalent. I'm doing it here.
Changelog:
[Internal] [Changed] - Update Android-prebuilt.mk to use the correct paths for turbomodule & fabricjni
Reviewed By: cipolleschi
Differential Revision: D39397567
fbshipit-source-id: f9f412ef4a9402f9528414af24eac06a0657f6f5
Summary:
This adds the `id` prop to `Text`, `TouchableWithoutFeedback` and `View` components as requested on https://github.com/facebook/react-native/issues/34424 mapping the existing `nativeID` prop to `id`. As this components are inherited by others this also adds the `id` prop support to `Image`, `TouchableBounce`, `TouchableHighlight`, `TouchableOpacity` and `TextInput`.
This PR also adds android tests ensuring that the `id` property is passed to the native view via the `nativeID` prop, these tests were based on the existing `nativeID` tests ([NativeIdTestCase.java](https://github.com/facebook/react-native/blob/main/ReactAndroid/src/androidTest/java/com/facebook/react/tests/NativeIdTestCase.java)).
## Changelog
[General] [Added] - Add id prop to Text, TouchableWithoutFeedback and View components
Pull Request resolved: https://github.com/facebook/react-native/pull/34522
Test Plan: Ensure that the new `id` prop android tests pass on CircleCI
Reviewed By: lunaleaps
Differential Revision: D39089639
Pulled By: cipolleschi
fbshipit-source-id: 884fb2461720835ca5048004fa79096dac89c51c
Summary:
With the IDE autocompletion now working \o/ I was able to apply some suggestions
to the Kotlin code I wrote inside the .defaults package (like remove redudant qualifiers and similar).
Changelog:
[Internal] [Changed] - Cleanup the Kotlin code in the .defaults package
Reviewed By: cipolleschi
Differential Revision: D39348983
fbshipit-source-id: b443a6be179c85d2a4f4293051c4f26af93eb5f1
Summary:
This diff creates a proxy module to interact with the React Native renderer. The goal of this proxy is to decouple usages of several functions (e.g.: `findNodeHandle`, etc.) from the actual renderer used in an app. This way, we can easily switch between renderers without having to change code depending on it.
This will be useful to remove a specific renderer from an app bundle when it's no longer used (e.g.: Paper on the Facebook App).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D39205975
fbshipit-source-id: 05289c0c3c8cd26d81aa1d2163097c73ec40c6ad
Summary:
Noticed this marker was not properly ended in the case where an early return happens. The fact that that early return is happening there is problematic too, so added a warning to follow-up on.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D39271917
fbshipit-source-id: 86dd5b1a46978629584f7cb0d615f2ad99d5a2f8
Summary:
UIImplementation(Provider) is not compatible with the new renderer (Fabric) and the relevant constructors have been marked deprecated for a while. While ReactInstanceManagerBuilder creates a default instance, it's not even used by CoreModulesPackage.
Changelog: [Android][Removed] Removed deprecated UIImplementationProvider
Reviewed By: NickGerleman
Differential Revision: D39271916
fbshipit-source-id: 20a3b02843ea9a2ba4bfc1352037239febbafc64
Summary:
The `JSDevSupport` module is incompatible with Fabric. Given it's not used internally and it's undocumented in OSS, we decided to remove it altogether.
Changelog: [Internal]
Reviewed By: javache, nlutsenko
Differential Revision: D39305892
fbshipit-source-id: 82455701a0b9ba83e6f971fc774280dceb2b22e0
Summary:
This PR should fix the issues introduced by commit c34659a5d3.
The problem is that `Collections.emptyList` creates a `List<Object>` which is not compatible with the `List<TargetView>` type.
## Changelog
[Android] [Fixed] - Make Android CI build again.
Pull Request resolved: https://github.com/facebook/react-native/pull/34573
Test Plan: test_buck and the "test Docker android" must be green.
Reviewed By: cipolleschi
Differential Revision: D39235674
Pulled By: cortinico
fbshipit-source-id: 574338e74aeb4635c67d91de28780fb784c9f405
Summary:
Changelog: [Internal] - Key cached values between different MotionEvents by pointerId.
Currently the implementation uses one cached list and array to store the last hitPath and event coordinates. We use these to determine if we've entered or left any views.
With more pointers, we need to be tracking these values for each pointer.
As well, clean up usage of `mLastTargetCoordinates`. This doesn't need to be a global as its an array that's updated by reference in `findTargetPathAndCoordinatesForTouch`
Reviewed By: vincentriemer
Differential Revision: D39152528
fbshipit-source-id: 28c18629bf974f41950401c7726a4757ad43ac28
Summary:
Changelog: [Internal] - Fix more pointer event platform tests.
* Fix the coordinate system to use DIP
* Set some properties for when pointerType="mouse"
Reviewed By: vincentriemer
Differential Revision: D39184713
fbshipit-source-id: d86f798f3e0a377ff1c159fb308329a2c9ae03ff
Summary:
Changelog: [Internal] - Refactor JSPointerDispatcher to group secondary actions (pointer_up, pointer_down) to use same logic and emit non-direct events
This diff re-arranges some code and re-uses some logic for different MotionEvent types.
Specifically, before our code for handling a motionEvent looked like
```
func onMotionEvent(event) {
if (event is HOVER_MOVE) {
handleHoverEvent(event)
}
if (event is ACTION_DOWN) {
// logic for dispatching down, enter, over
}
if (event is ACTION_POINTER_DOWN) { // this represents any secondary pointer going down
// logic for dispatching down
}
if (event is ACTION_MOVE) {
// logic for dispatching touch move
}
if (event is ACTION_UP) {
// logic for dispatching up, out, leave
}
if (event is ACTION_POINTER_UP) { // this represents any secondary pointer going up
// logic for dispatching up
}
....
}
```
now, we've refactored it to be like:
```
func onMotionEvent(event) {
if (event is HOVER_MOVE) { // Still keep this as separate because it does some special things. Will refactor in follow-up diff
handleHoverEvent(event)
}
switch() {
case ACTION_DOWN or ACTION_POINTER_DOWN:
// do same logic
break;
case ACTION_UP or ACTION_POINTER_UP:
// do same logic
break;
case ACTION_MOVE:
// do same logic, we will want to converge this logic with HOVER_MOVE, todo in a follow-up
break;
...
}
....
}
```
This refactor adds the functionality of `enter, over, out, leave` to secondary pointer events in which they weren't fired before.
Reviewed By: vincentriemer
Differential Revision: D39142820
fbshipit-source-id: 8b89db6dc22f24583f8c14dbb8392d4dc8ff6e4d
Summary:
Changelog: [Internal] - Make sure `onChildEndedNativeGesture` is called for view managers that call `onChildStartedNativeGesture`
This affects `JSTouchDispatcher`, `JSPointerDispatcher` as they track what view is reporting native gesturing handling.
This is a bug that view managers never shared the fact that they've stopped managing a native gesture. Both `JSTouchDispatcher`, `JSPointerDispatcher` get around this by manually resetting their internal flag on ACTION_DOWN event (we will get rid of this in a later diff)
Reviewed By: javache
Differential Revision: D38850609
fbshipit-source-id: ef4afb591249bb621f42667608dc1ef20424b65c
Summary:
`JNIEnv`'s `FindClass(..)` function takes the classes in the standard
`foo/bar/Baz` class specification (unless they're special, like arrays).
Specifying them with `Lfoo/bar/Baz;` results in a
`ClassNotFoundException` being raised -- which is especially unhelpful
when intending to re-throw an exception.
The docs for `JNIEnv#FindClass(..)` can be found [here][jnienv].
[jnienv]:
https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html#:~:text=The%20name%20argument,java/lang/String%22
## Changelog
[Android] [Fixed] - Correctly resolve classes with FindClass(..)
Pull Request resolved: https://github.com/facebook/react-native/pull/34533
Test Plan:
No exact test plan. However, if an exception is thrown during the
rendering process, a fatal `ClassNotFoundException` is raised, rather
than having the error be passed up to the `ReactNativeManager`.
Fixes: facebook/yoga#1120
Reviewed By: amir-shalem
Differential Revision: D39133326
Pulled By: jacdebug
fbshipit-source-id: 86283b7d21aed49ed0e9027b2aef85f0108cdf9a
Summary:
When the webview is updated by play store, all apps that has loaded webview gets killed. For background see https://issuetracker.google.com/issues/228611949?pli=1
We have a long-running app and don't want this to happen and while we are not using webview anywhere, we are using websockets that loads it for reading cookies, however we are not using cookies to authenticate the websocket and thus want to disable the webview to avoid loading it unnecessarily and then getting killed unnecessarily.
The webview has support for beeing disabled https://developer.android.com/reference/android/webkit/WebView#disableWebView() however as-is this crashes React Native. It seems to me like this case is very similar to not having web view installed and should be handled in the same way.
## 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] - Avoid crash in ForwardingCookieHandler if webview is disabled
Pull Request resolved: https://github.com/facebook/react-native/pull/34483
Test Plan: Add `WebView.disableWebView();` as the first line in `MainActivity.onCreate`.
Reviewed By: christophpurrer
Differential Revision: D38981827
Pulled By: cipolleschi
fbshipit-source-id: 335a8420568ad0c80b834ae8a3b164e55ebe26f3
Summary:
## Context
```isRootViewVisible``` doesn't work as expected for non-Venice: when enter Marketplace tab, ```isRootViewVisible``` should returns true with Marketplace tab's rootViewTag, but it returns false.
## Root cause
```rootViewTag``` is added to "mVisibleRootTags" in "FbReactRootVisibilityTracker" when ```BaseFbReactFragment.onViewDidAppear()``` gets called, but ```BaseFbReactFragment.onViewDidAppear()``` is called earlier than when the ```rootViewTag``` is set.
## Fix
Move setRootViewTag to earlier when RootView is created instead of in startSurface or mounting.
Changelog:
[Android][Changed] - Move setRootViewTag to earlier when RootView is created
Reviewed By: RSNara
Differential Revision: D38586584
fbshipit-source-id: aec3ed37eb62289a19794e68b1a6b5ca213cb14a
Summary:
This diff introduces the API that will be used to describe React Native Components written in C++
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D38725766
fbshipit-source-id: 292e28409ac6be8f9a1c2209b8c558e0e2cb96ea
Summary:
https://github.com/facebook/react-native/issues/31056#issuecomment-786349025
>Re-implement accessibilityHint on Android so that rather that concatenate into the contentDescription, it sets the toolTipText property on the AccessibilityNodeInfo (not on the view). This is the closest analog to iOS's hint that Android has, as the text is announced after the contentDescription rather than part of it. It will will not adhere to users preferences on whether they want hints disabled or not, and still has no pause before it like real hints have, but it's far closer than using the contentDescription directly.
fixes https://github.com/facebook/react-native/issues/31056
## Changelog
[Android] [Fixed] - Re-implement accessibilityHint on Android to use AccessibililltyNodeInfo#setToolTipText instead of contentDescription
Pull Request resolved: https://github.com/facebook/react-native/pull/34427
Test Plan: https://user-images.githubusercontent.com/24992535/184837154-5c65dbf1-1031-4d56-ac1e-066af7e08edc.mp4
Reviewed By: christophpurrer
Differential Revision: D38982158
Pulled By: cipolleschi
fbshipit-source-id: 7a616e6df9f83bd21ca02cc26b5918986a1d64f8
Summary:
When a view is rendered with a combination of `overflow: hidden` and `borderRadius: >0`, the `ReactViewGroup` would apply the border radius using Canvas `clipPath`. In Android graphics, clipPath is not an anti-aliased operation and caused aliasing artifacts.
Changing the method to a bitmask using the `PorterDuff` method results in the same functionality, but with hardware accelerated antialiasing.
https://github.com/facebook/react-native/issues/24486
Changelog:
[Android][Change] - Views with overflow: hidden and borderRadius: >0 now render anti-aliased borders.
Reviewed By: javache
Differential Revision: D38914878
fbshipit-source-id: 45ac7e4aece7a76c4216412175e49d3d73b6f391
Summary:
Noticed this logging was broken when enabling the flag.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38616851
fbshipit-source-id: acf0ab75918b389586cb713c2edf5a6bf83ee7a2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34446
I'm adding another class to the .defaults package. This will take care of setting the RootView
with Fabric enabled/disabled as well as controlling concurrent root.
Changelog:
[Android] [Added] - Introduce the DefaultMainActivityDelegate to simplify enabling/disabling Fabric for new apps.
Reviewed By: cipolleschi
Differential Revision: D38823181
fbshipit-source-id: 2293b9df6b0d8fa79695bd52a8e0bb46b44c43c8
Summary:
Currently we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from ReactAndroid/src/main/java/com/facebook/... to ReactAndroid/src/main/jni/react/...
This is the diff for turbomodule
I've also updated all the internal usages and references to the new path.
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - turbomodule
Reviewed By: cipolleschi
Differential Revision: D38820638
fbshipit-source-id: febb3f8cef18b30e82c3a4776baa85d0c0d19e4b
Summary:
This is an attempt to fix the broken `test_buck` as the `/textinput` target now needs to access the Kotlin stdlib dependencies
## Changelog
[Internal] - Fix test_buck by providing exported deps for textinput target
Pull Request resolved: https://github.com/facebook/react-native/pull/34436
Test Plan: Will wait for a CircleCI result
Reviewed By: cipolleschi
Differential Revision: D38782473
Pulled By: cortinico
fbshipit-source-id: 72265c34092372189d75df732b64a1e370453472
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34435
Currently we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from ReactAndroid/src/main/java/com/facebook/... to ReactAndroid/src/main/jni/react/...
This is the diff for fabricjni
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - fabricjni
Reviewed By: cipolleschi
Differential Revision: D38741130
fbshipit-source-id: f9e3e4514d3ae0ddeac65256928d71d5134d08f8
Summary:
Unfortunately my last diff didn't completely fix this; now there are more printed parameters than arguments provided to the formatter.
Easy fix, confirmed this works by running internally.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38678116
fbshipit-source-id: 51f32905debc1946bc260f06a5bdc2f43141ddf4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34418
This is an attempt to relax the need of specifying a custom `TurboModuleManagerDelegate` and a `JSIModulePackage` in new apps for New Architecture.
Users can just specify the name of the dynamic library to load and they'll default to use the `DefaultTurboModuleManagerDelegate` and `DefaultJSIModulePackage`.
Users will still have to provide a C++ implementation for it for the time being, but this at least removes
one extra file that we requested them to create and maintain.
If we're fine with this approach, I'll replicate it inside the default template.
Changelog:
[Android] [Added] - Provide defaults for TurboModuleManagerDelegate and JSIModulePackage
Reviewed By: cipolleschi
Differential Revision: D38701180
fbshipit-source-id: eec302c5789990700eb75353d97751358ca6799f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34421
Currently we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from ReactAndroid/src/main/java/com/facebook/... to ReactAndroid/src/main/jni/react/...
This is the diff for reactnativeblob
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - reactnativeblob
Reviewed By: cipolleschi
Differential Revision: D38703092
fbshipit-source-id: 3d4391d8ee5587b199efa4001f68c6d4ed3ce2c2
Summary:
Currently we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from ReactAndroid/src/main/java/com/facebook/... to ReactAndroid/src/main/jni/react/...
This is the diff for mapbuffer
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - mapbuffer
Reviewed By: cipolleschi
Differential Revision: D38699253
fbshipit-source-id: c1c8f8693b6da4e3428f8f280e1ca4d5c5d0f853
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34420
Currently we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from ReactAndroid/src/main/java/com/facebook/... to ReactAndroid/src/main/jni/react/...
This is the diff for hermes/reactexecutor and hermes/instrumentation
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - hermes modules
Reviewed By: yungsters
Differential Revision: D38700760
fbshipit-source-id: 50cf38a0dae4f617e6d78317e5fe2a858290d0c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34396
Current we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from ReactAndroid/src/main/java/com/facebook/... to ReactAndroid/src/main/jni/react/...
This is the diff for jscexecutor
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - jscexecutor
Reviewed By: sshic
Differential Revision: D38615007
fbshipit-source-id: e5085130579f37f052b5c8a5702d2c0f1b332bee
Summary:
Currently we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from ReactAndroid/src/main/java/com/facebook/... to ReactAndroid/src/main/jni/react/...
This is the diff for uimanager
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - uimanager
Reviewed By: dmitryrykun
Differential Revision: D38656400
fbshipit-source-id: f52487160fa6c05ec382842e2a6125a5c4cb1e86
Summary:
As the title says, android.sourceSets.main.jni is deprecated in AGP. We should not be accessing it. Here we were setting it to the empty array (the default value).
It will cause the build to break in a future AGP bump, hence I'm removing it.
Changelog:
[Internal] [Changed] - Remove deprecated jni.srcDirs from ReactAndroid build file
Created from CodeHub with https://fburl.com/edit-in-codehub
Reviewed By: cipolleschi
Differential Revision: D38655857
fbshipit-source-id: 2eb6897964554da462bde58937a6de708bc047dc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34386
Current we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from `ReactAndroid/src/main/java/com/facebook/...` to `ReactAndroid/src/main/jni/react/...`
This is the diff for reactperflogger
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - reactperflogger
Reviewed By: cipolleschi
Differential Revision: D38584681
fbshipit-source-id: 8b65b3fa47a7f106c7fea79fd739f0e4e37efa2a
Summary:
Add ability to store and retrieve a list of MapBuffer as an entry of MapBuffer.
```
Example:
MapBuffer1
{
key1: "test string",
key2: MapBuffer2,
key3: [MapBuffer3, MapBuffer4]
}
```
Changelog:
[General][Added] Add ability to store and retrieve a list of MapBuffer
Reviewed By: JoshuaGross
Differential Revision: D38460204
fbshipit-source-id: 3e721418be2dca6d5f15f665753844d6f531e31c
Summary:
Folly's molly target combines a number of targets that are supposed to be useable on mobile. Since we're trying to move away from folly, we should instead list explicitly which parts of folly we're using so we can remove them over time, and track which targets no longer have any folly dependencies.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38352060
fbshipit-source-id: 09d0d84793692f97f4d49390c99c38b23441df54
Summary:
React Native is compiled downstream with MSVC, meaning the introduction of code depending on language extensions specific to gcc/clang may cause breakage.
We can enable `-Wpedantic` to flag any behavior not officially supported by the specified C++ standard. This will includes rules beyond what MSVC has trouble with, but seems to not have too many "noisy warnings".
This change enables -Wpedantic in BUCK targets within ReactCommon.
This makes the OSS C++ build for Android/iOS slightly more permissive than the internal build, A followup is to add the changes to OSS build logic as well, to avoid contributors seeing more errors upon internal submission. (checking with cortinico on how to do this for Android).
react-native-windows uses a higher warning level than `-Wall`, which is an additional cause of compilation failures, but is not addressed as part of this change.
Changelog:
[Internal][Changed] - Enable -Wpedantic for targets inside ReactCommon
Reviewed By: rshest
Differential Revision: D38457812
fbshipit-source-id: 014da1ac0b7ad8f78154e6e447ed58def6bd0d47
Summary:
Calling `setPivotX` and `setPivotY` internally sets `isPivotExplicitlySet` in Android UI, which causes some transforms to no longer use the right transform. Instead use `resetPivot` to get the desired behaviour.
Changelog: [Android][Fixed] Bug with view transforms when view recycling is enabled
Reviewed By: NickGerleman
Differential Revision: D38579267
fbshipit-source-id: 36186286c6765f92aabaa44994546e06f34c2be0
Summary:
RN for Android fires `keyboardDidShow` and `keyboardDidHide` by observing changes to viewable window size. This isn't always reliable, such as when an activity has `awindowSoftInputMode` set to not have the system adjust the viewport when a keyboard is opened.
Android 11 added the direct ability to measure and check visibility of the soft keyboard via `WindowInsets`, which fixes these issues. This is exposed downlevel to API 23 via WindowInsetsComapt` with the same limitations as previously, but using it simplifies our calculations a lot.
Changelog:
[Android][Fixed] - Use WindowInsetsCompat for Keyboard Events
Reviewed By: javache
Differential Revision: D38500859
fbshipit-source-id: d4ad41d7e75e4b9c14a485539a5f9de19de74362
Summary:
We ran an experiment to test different implementations of TurboModules HostObjects, as the current one has various inefficiencies, such as re-creating HostFunctions on every property access. The strategy we found to be most efficient and flexible longer-term is to represent the TurboModule with a plain JavaScript object and use a HostObject as its prototype. Whenever a property is accessed through the prototype, we cache the property value on the plain object, so it can be efficiently resolved by the VM for future accesses.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38355134
fbshipit-source-id: 59253091412d0c6827ad7a4b1ac7dc0c7fe89cc2
Summary:
The Android version of PlatformConstants exposes the device's [UI Mode]( https://developer.android.com/guide/topics/resources/providing-resources#UiModeQualifier). It is missing the case for 'vrheadset', added in Android API 26. We should return the expected result when this is queried.
Changelog:
[Android][Added] - Expose UI_MODE_TYPE_VR_HEADSET in PlatformConstants
Reviewed By: rshest
Differential Revision: D38495875
fbshipit-source-id: fd904bd11213448415b7d75145d9ba6311ed407b
Summary:
Fixes https://github.com/facebook/react-native/issues/34229
Basically, the react android conflicts with the kotlin version that's defined in the top level build.gradle. To resolve it, the approach was to get the `kotlinVersion` defined in top level build.gradle and use it. If it's not defined, we use the default(1.6.10 as of now).
The reason behind not using the DSL is that it doesn't allow us to use the variables due to it's constrained syntax.
See [here](https://docs.gradle.org/current/userguide/plugins.html#sec:constrained_syntax)
So the idea was to use the build script to resolve the kotlin plugin and it works 👍 .
Kindly asking for review cortinico :)
## 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] [Changed] - refactored usage of kotlin plugin
Pull Request resolved: https://github.com/facebook/react-native/pull/34255
Test Plan: Ran the node ./scripts/run-ci-e2e-tests.js --js --android --ios to verify it doesn't introduce any unexpected issues.
Reviewed By: dmitryrykun
Differential Revision: D38468567
Pulled By: cortinico
fbshipit-source-id: f9ab635fcf033f1d337ed90793ba1667957b8e01
Summary:
After. D38153924 (e24ce708ab), layout mount items have 7 int arguments but the logger only pulls out and displays 6, which leads to the following exception: "Caught exception trying to print java.lang.IllegalArgumentException: Invalid type argument to IntBufferBatchMountItem"
Changelog: [Internal]
Created from CodeHub with https://fburl.com/edit-in-codehub
Differential Revision: D38472664
fbshipit-source-id: 1583a5514c2ab662eaf5c4ce4bf33c958cb05282
Summary: Changelog: [Internal] Add logic for `isPrimary` for PointerEvent object and set other properties to their default value
Reviewed By: javache
Differential Revision: D38363163
fbshipit-source-id: 5ec9de69fb5b34295f1da6daedd5c67e3bd3727e
Summary:
Changelog: [Internal] - Instead of using toolType which is a property per pointer in the MotionEvent, let's use [getSource](https://developer.android.com/reference/android/view/MotionEvent#getSource()) which is the source for the entire event (all pointers).
This aligns with what we've seen on Android when we have a mouse and touch input, there is only one active source input device.
And removes the need for checking a flag we set here: D36958947
Reviewed By: NickGerleman
Differential Revision: D37702090
fbshipit-source-id: ba2a4f0c28e1aff2b8b04314fe6f737b66ed0be3
Summary:
This Pull Request aims at removing the making of reactnativeutilsjni as it is built from the same sources as reactnativejni. It also replaces references to reactnativeutilsjni with reactnativejni.
This should get rid of `reactnativeutilsjni.so` while reusing `reactnativejni.so` in it's place. This should give us some size improvements in the finally built apk.
## 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] [Changed] - Replaced reactnativeutilsjni with reactnativejni in the build process to reduce size
Pull Request resolved: https://github.com/facebook/react-native/pull/34339
Test Plan:
1. Ran the CMakelist.txt file using CMake and I could see that reactnativeutilsjni.dir is no longer generated with my changes.
2. Built the aar from this branch in Android Studio and build happened successfully.
I am not sure if we could run any more tests. Please let me know in case anymore testing is required and I can do accordingly
Reviewed By: cortinico
Differential Revision: D38400481
Pulled By: genkikondo
fbshipit-source-id: 592736e56441328389ae89135667c336ff8018e6
Summary:
Some custom logic is applied to workaround a platform bug where velocity may be incorrect on Android P. [The bug in question](https://issuetracker.google.com/issues/112385925) appears to have been fixed before Android `Q` was released, so we shouldn't *need* to apply the workaround on other versions.
As described in https://github.com/facebook/react-native/issues/34226 the workaround can adversely affect certain scroll behaviors, which can easily be reproduced when you briefly scroll one direction then quickly fling the opposite direction (see the video in the linked ticket).
This PR changes the workaround to *only* be applied on Android P, in order to avoid causing weird scroll behavior on versions that are not actually affected by the bug the workaround is working around.
## Changelog
```
[Android] [Fixed] - Fix occasionally incorrect ScrollView fling behavior
```
Pull Request resolved: https://github.com/facebook/react-native/pull/34233
Test Plan:
- Repro the strange fling behavior in the current version (See video attached in https://github.com/facebook/react-native/issues/34226)
- Verify that the string fling behavior is fixed with this patch
- Verify that fling behavior still works as expected on Android versions affected by the [original bug](https://issuetracker.google.com/issues/112385925), and those immediately following it (to verify that the bug being worked around was, in fact, fixed as expected).
Reviewed By: javache
Differential Revision: D38287277
Pulled By: ryancat
fbshipit-source-id: 2c786872c4d41655b3849bb92e02f1f16c663b41
Summary:
Calculation of TransformedFrames was a method introduced by D37994809 (64528e5faa) to fix rendering of inverted flat lists.
We found that this operation is crashing in fb4a causing the UBN T127619309
This diff creates a feature flag to disable the calculation of TransformedFrames in Layoutable ShadowNodes. **The goal of this diff is to revert the behavior introduced by D37994809 (64528e5faa)**
The featureFlag is disabled in fb4a and enabled in react AR (because ReactAr apps relies on the calculation of TransformedFrames and these apps are not affected)
The root cause of the bug will be fixed by D38280674 (which still requires more testing and investigation)
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D38286857
fbshipit-source-id: 721cd0554ae6a6b369b3f8dbb584160a270d0f18
Summary:
While I was working on rewriting `react-native-slider` to Fabric I found a weird bug that prevented the slider to be set as disabled (to be exact: call the method `slider.setEnabled(false)`. As it turned out the `accessibilityState` (with value: `accessibilityState={{disabled: true}}` prop occurred after the `enabled={false}` prop that I was passing to the slider, which lead to both of this props overwrite each other.
Handling of `accessibilityState` props inside view leads to always overwriting the enabled prop to true (even if we explicitly set it to `{disabled: false}`.
Workaround for this was to reorder the props, so that the `accesibilityState` occur before `disabled`, but I think it's better to not set `view.setEnabled(true)` if we are passing a disabled property.
## Changelog
[Android] [Fixed] - Fix accessibilityState overwriting view's disabled state on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/34287
Test Plan:
Change order of props inside native component implementation (that `disabled` occurs before `accesibilityState`). For example: `Libraries/Components/Slider/Slider.js`
<details>
<summary>Video showing the bug in RNTester (using Switch component)</summary>
https://user-images.githubusercontent.com/52801365/181287547-964f50e2-55dc-450f-b413-0d1c14d4bb83.mp4
</details>
Reviewed By: NickGerleman
Differential Revision: D38209232
Pulled By: dmitryrykun
fbshipit-source-id: 93d423716f89b45251be9d5aefcf01f7bd776f2c
Summary:
Fixes https://github.com/facebook/react-native/issues/34120
The new React Native architecture doesn't check `needsCustomLayoutForChildren` so it wrongly positions native views on Android. In https://github.com/facebook/react-native/issues/34120 there are videos comparing the positioning of a native action view in the old and the new architecture.
This PR passes the parent tag to the `updateLayout` method of the `SurfaceMountingManager`. The `SurfaceMountingManager` calls `needsCustomLayoutForChildren` on the parent view manager (copied the code from the `NativeViewHierarchyManager` in the old architecture).
**NOTE** - I wasn't sure where to get the parent shadow view from so I've put in my best guesses where I could and left it as `{}` otherwise.
## Changelog
[Android] [Fixed] - Migrate `needsCustomLayoutForChildren` check to the new architecture
Pull Request resolved: https://github.com/facebook/react-native/pull/34254
Test Plan:
I checked the fix in the repro from https://github.com/facebook/react-native/issues/34165. Here is a video of the action view closing using the native button that is now visible in the new architecture.
https://user-images.githubusercontent.com/1761227/180607896-35bf477f-4552-4b8a-8e09-9e8c49122c0c.mov
Reviewed By: cipolleschi
Differential Revision: D38153924
Pulled By: javache
fbshipit-source-id: e2c77fa70d725a33ce73fe4a615f6d884312580c
Summary:
Implements most of systrace using androidx.tracing, this makes it usable using Android Studio profiler systrace.
## Changelog
[Android] [Added] - Improve OSS systrace
Pull Request resolved: https://github.com/facebook/react-native/pull/34252
Test Plan:
Run a systrace in Android Studio for RN Tester and make sure RN specific sections are there.
<img width="1263" alt="image" src="https://user-images.githubusercontent.com/2677334/180593493-fc087b4a-2253-43e1-b246-bed3e7bba7ac.png">
Reviewed By: NickGerleman
Differential Revision: D38116890
Pulled By: dmitryrykun
fbshipit-source-id: 744bedbf9ad4004488340a5b4e93d936d9a1e582
Summary:
The purpose of this diff is to un-deprecate the method DisplayMetrics.getWindowDisplayMetrics().
As React Native is used in devices with multiple screens and displays, we need to provide a non-deprecated way to access display metrics (e.g. screen density) for the window that's used to render react native views.
This diff doesn't make any change in behavior, but it un-deprecates the API
changelog: [Android][Added] Un-deprecate DisplayMetrics.getWindowDisplayMetrics() method
Reviewed By: javache
Differential Revision: D37871954
fbshipit-source-id: d8eb97cfae096f2f62ed1389a6de17a892a46b43
Summary:
In D37873933, we update the buildifier binaries, which apply some minor changes to existing lint. Specifically, entries are now properly sorted.
Update the files in xplat such that updating buildifier does not cause lint changes in users diffs.
drop-conflicts
allow_many_files
#nocancel
#forcetdhashing
(Note: this ignores all push blocking failures!)
Reviewed By: d16r
Differential Revision: D37873936
fbshipit-source-id: f31d9c50d64ae99f99298977b471bf13e7ed5262
Summary:
changelog: [internal]
This diff is reverting D37912783 (2b57b749fb)
Depends on D38035753
D37912783 (2b57b749fb) has been identified to be causing the following test or build failures:
Tests affected:
- https://www.internalfb.com/intern/test/281475006604971/
Here's the Multisect link:
https://www.internalfb.com/intern/testinfra/multisect/1077515
Here are the tasks that are relevant to this breakage:
T93091116: 1 test started failing for oncall messenger_kids_www_rn in the last 2 weeks
We're generating a revert to back out the changes in this diff, please note the backout may land if someone accepts it.
Reviewed By: sammy-SC
Differential Revision: D38035761
fbshipit-source-id: 70034af3275b7b69c0b50f12a377182d4f23e669
Summary:
Changelog: [Android][Fixed] - Fix such that when the scrollviews call `onChildStartedNativeGesture`, they appropriately call `onChildEndedNativeGesture` to unlock the native gesture such that `JSTouchDispatcher` or `JSPointerDispatcher` will continue to emit events.
### How did we find this issue?
As React Native is adding pointer event support for different input types, we noticed after pressing and dragging on a ScrollView, hover events would not fire.
### Why was this not an issue before?
This was always an issue -- it was just that `JSTouchDispatcher` worked its way around it by explicitly setting `mChildIsHandlingNativeGesture = false` on a `ACTION_DOWN` event, [code pointer](https://github.com/facebook/react-native/blob/main/ReactAndroid/src/main/java/com/facebook/react/uimanager/JSTouchDispatcher.java#L76). Similarly, `JSPointerDispatcher` [copied this logic](https://github.com/facebook/react-native/blob/main/ReactAndroid/src/main/java/com/facebook/react/uimanager/JSPointerDispatcher.java#L106).
With new hover support in `JSPointerDispatcher` no similar workaround was put in (or even a good place to insert).
### What's next?
* As a follow-up, we should look at removing this workaround (at least for `JSPointerDispatcher`)
* By searching for usages of where we `notifyNativeGestureStarted`, it looks like `ReactDrawerLayout` and `ReactSwipeRefreshLayout` both do and don't call the symmetric `notifyNativeGestureEnded`. This will likely be an issue in the future (or maybe if we remove the workaround)
Reviewed By: mdvacca
Differential Revision: D37977982
fbshipit-source-id: 0d18767f4debbf24cfb24b54df1310f6f96a0d03
Summary:
The native module might be null, and that should not be an exception thrown by the subclassed method.
Changelog:
[Android][Internal] - Mark getModule API to be nullable
Reviewed By: mdvacca, makovkastar
Differential Revision: D37900294
fbshipit-source-id: a4ecc9804b95bf0512554e96985f272b435e33b2
Summary:
This cleans up a bit our dependency list inside `ReactAndroid`. I've re-sorted the lists, and exported everything I could in the `gradle.properties`.
I wish we could move to the Gradle Version Catalog for Android, but that's not possible at the moment (it will make impossible for users to build from source).
## Changelog
[Internal] - Cleanup some of the dependencies inside ReactAndroid
Pull Request resolved: https://github.com/facebook/react-native/pull/34191
Test Plan: Will rely on a Green CircleCI
Reviewed By: huntie
Differential Revision: D37828614
Pulled By: cortinico
fbshipit-source-id: f433d08d691db4145e0c72ca4dab2f0350e4101f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34161
This is a follow up to D37648363 (64fe67695b) which breaks up `TestBundle.js` into two modules. This enables `TestApps.js` (which defines and exports the set of integration test apps) to be required in the Meta-specific dependency graph without violating our internal naming pattern for JS entry points.
`force_include_bundles` is removed from the `js_glob` macro signature.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D37686883
fbshipit-source-id: 492c13dfcdd76ea8347d4d11c85818e31777c663
Summary:
Subclassing a ViewManager means an additional PropsSetter class is generated (and other overheads). Instead we can use a Factory/Provider to construct ReactTextViewManager, since we don't actually need a subclass.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D36411098
fbshipit-source-id: 11c5ba5c9683a3ae4741cf61338f1983c69d9b69
Summary:
These changes are a side-effect of a Meta-internal Buck macro change. This does not affect how RNTester is built in open source.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D37648363
fbshipit-source-id: 6fd5d56a7a7a9ea71dc3d0df91e510fcd45a1e17
Summary:
This diff fixed a NPE in horizontal scroll view when calling scrollToEnd API in side effect.
The problem here is we may trigger side-effects before the required view got mounted for performance reasons. We've been fixing this with retry logic on those side-effects and we've already done this in vertical scroll view. This is to fix on the horizontal scroll as well.
Changelog:
[Android][Fixed] - Fixed HorizontalScrollView API scrollToEnd causing NPE in side-effects.
Reviewed By: lunaleaps, JoshuaGross
Differential Revision: D37571847
fbshipit-source-id: 0a4dc38381008350fd09908aa3ebb64e3e65a424
Summary: Changelog: [Internal] Allow for MotionEvents to indicate whether they are dispatched from an input device that supports hoverability
Reviewed By: javache
Differential Revision: D37543296
fbshipit-source-id: 4f70d2bf69ff1c563d8e4a6b5eb6b13b53996b9a
Summary: Changelog: [Internal] - We can now remove the '2' suffix as we had an internal implementation that was not truly aligned with W3C pointers but used the same name. We have aligned the internal types to match w3c so we can now remove the suffix that differentiates them.
Reviewed By: vincentriemer
Differential Revision: D37545813
fbshipit-source-id: 6f2336ae9e314066c340161113268c1f28621a71
Summary:
Internal tests are indicating that there's an OOM that happens during the RemoveDeleteTree worker loop while trying to expand the size of the tag stack.
In practice during manual testing I was not able to get the capacity beyond 40, but for deletions of very large trees, it's easy to imagine the size of the stack growing to at least the number of nodes in the tree being deleted. To mitigate this, we relax our requirements around the order in which onViewStateDeleted can be called and call it top-down instead of bottom up to maintain a smaller stack (see comments for more details).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D37619259
fbshipit-source-id: 8f7af0137a868606a72fdc7bdca13c5e89b69573
Summary:
There is a very small volume of production errors caused by a View that is already in the hierarchy being added to the hierarchy again; this results in a crash on the Android platform layer.
We detect and attempt to silently recover from this case, while logging and collecting more diagnostics. This will still crash in debug mode.
It is unclear what layer this error is coming from: it could be an issue with the C++ differ (ordering, or something more tricky); that is unlikely but there are few other hypotheses at the moment.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D37557663
fbshipit-source-id: ffe320ff646e314fa921a2c2cf8058254713505c
Summary:
The initial version of this would result in LayoutAnimations running potentially much faster than 60FPS (incorrectly). Resolve by calling tryDispatchMountItems directly instead of the frame callback runner.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D37543693
fbshipit-source-id: 91dbd961ecc155221c84148cb6b252a4aac9ec91
Summary:
Before
```
"If you want to override a property, don't addthe ReactProp annotation to the property in the subclass",
```
After
```
"If you want to override a property, don't add the ReactProp annotation to the property in the subclass",
```
Reviewed By: michaeltangelo
Differential Revision: D37526541
fbshipit-source-id: 850424a1b5a5aeb0abe64b6defcf6db96d2000cc
Summary:
Crashes can occur if we try to disassemble trees not managed by React Native - for example a native component tree, Litho hierarchies, etc.
As we disassemble the tree, ensure that children are managed before disassembling a subtree.
Changelog: [Internal]
Reviewed By: ryancat
Differential Revision: D37493854
fbshipit-source-id: fee4d303133edcef663abfe8637bce6b24627724
Summary:
Due to the way we're dispatching queued MountItems on Android, we could be doing nothing on the UI thread for up to 15.99...ms before the start of the next frame, resulting in a delayed paint of up to 1 full (16ms) frame.
The delay is totally random and depends only on when the work is scheduled.
The tl;dr is that currently all MountItems are dispatched starting only at the /beginning/ of a UI frame. If we schedule work at FrameStart+0.000001ms, it will not be operated on until the start of the next frame, 16ms later. So the "wasted" time could be anywhere from 0 to ~16ms, but will result in at least 1 wasted frame regardless.
The fix is fairly trivial: start working on large buffered work as soon as we schedule it.
Changelog: [Android][Changed] Optimization to paint changes up to 1 frame earlier on Android/Fabric
Reviewed By: NickGerleman
Differential Revision: D37478885
fbshipit-source-id: 8af846736caf3a9d9f0d0c5e33328bebb87b1b32
Summary:
Instead of directly scheduling a Runnable on the UI thread, use a GuardedFrameCallback which (1) guards against exceptions thrown on the UI thread (in this case, errors in deferred remove/delete work really should not disrupt the UI at all or cause user-visible crashes) (2) allows us to split work across multiple frames if necessary (3) is more consistent with how we schedule other work on Android.
The only functionality change is that we might split work across multiple callbacks, in the case of tearing down a particularly large tree.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D37470531
fbshipit-source-id: d9d1fc85c29e53addea886db975c0d914581e618
Summary:
This is the companion PR of https://github.com/react-native-community/cli/pull/1630
It extends the `ReactNative-application.cmake` file with instructions to pickup the autolinked libraries.
## Changelog
[Internal] [Changed] - Extend the RN Application.cmake file to support Android autolinking
Pull Request resolved: https://github.com/facebook/react-native/pull/34082
Test Plan: Tested locally as we don't have a way to test autolinking on CI.
Reviewed By: cipolleschi
Differential Revision: D37463203
Pulled By: cortinico
fbshipit-source-id: 0b28e7f214c265ebfec4ccc59ae321f682299cf8
Summary:
setFocusable(int) was added in Android O, and setHyphenationFreqauency was added in M.
Changelog: [Internal]
Reviewed By: kacieb
Differential Revision: D37462117
fbshipit-source-id: e59d2de49dbdcddfdba25def6bb39695c65efe89
Summary:
TL;DR: For applications using JS navigation, save 50-95% of CPU during mounting phase in N>2 navigations that replace ~most of screen.
During investigation of performance on the UI thread of React Native applications, I noticed that the /initial/ render of an screen for an application using JS navigation is /mostly/ consumed (on the UI thread) by tearing-down the previous View hierarchy. In one 185ms segment on the UI thread in production, 95% of the CPU time was Remove/Delete instructions and only 5% of CPU time was consumed by actually displaying the new hierarchy (this is specific to Android and also assumes that View Preallocation is being used, so post-commit work consists of Insert and UpdateLayout mutations primarily).
There are /some/ cases where the C++ differ knows that we are deleting an entire subtree and therefore we could communicate this to the mounting layer. All that matters is that these Views are removed from the View hierarchy immediately; and secondarily that their memory is cleaned up ASAP, but that doesn't need to happen immediately.
Some additional constraints and notes:
1) As noted in the comments, we cannot simply stop producing Remove and Delete instructions. We need to produce /both/ the new RemoveDeleteTree instruction, /and/ produce all the Remove/Delete instructions, primarily because LayoutAnimations relies heavily on these Remove/Delete instructions and certain things would break if we removed those instructions entirely. However, we can mark those Remove/Delete instructions as redundant, process them only in LayoutAnimations, and not send them to the Android mounting layer.
2) We want to make sure that View Recycling is not impacted. Since Android cannot take advantage of View Recycling until /after/ the second major render (preallocation of views will happen before any views are recycled), this doesn't impact View Recycling and we'll make sure Views are recycled whenever they are deleted.
Thus, we do two things:
1) Introduce a new RemoveDeleteTree operation that can delete an entire subtree recursively as part of one operation. This allows us to avoid serializing hundreds or thousands of instructions and prevents JNI traffic.
2) Besides removing the topmost View from the View hierarchy, and ensuring it's not drawn, the full teardown and recycling of the tree can happen /after/ the paint.
In some flows with JS navigation this saves us 95% of CPU during the mount phase. In the general case it is probably closer to 25-50% of CPU time that is saved and/or deferred.
Changelog: [Android][Changed] Significant perf optimization to Fabric Remove/Delete operations
Reviewed By: ryancat
Differential Revision: D37257864
fbshipit-source-id: a7d33fc74683939965cfb98be4db7890644110b2
Summary:
Changelog: [Internal] - Fix a bug in dispatch filtering that was too aggressively filtering out events to fire.
My flaw in logic was limiting the `isListening(view, bubble)` logic to `i==0` for relevant `ViewTargets`, when in reality, we need to be checking if every `ViewTarget` passed to `filterByShouldDispatch` is listening to a bubble event.
Further, as vincentriemer pointed out, `ancestorListening` should only be set true if a `ViewTarget` is listening to a capture event.
Reviewed By: vincentriemer
Differential Revision: D37423952
fbshipit-source-id: 2ed08038632677c24766bca6214dc00013fa2446
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predictable.
Reviewed By: bradzacher
Differential Revision: D37388949
fbshipit-source-id: cdcbc98035ce9b6994842005ea46df42de54f9b8
Summary:
The current implementation of **getDefaultJSExecutorFactory** relies solely on try catch to load the correct .so file for jsc or hermes based on the project configuration.
Relying solely on try catch block and loading jsc even when project is using hermes can lead to launch time crashes especially in monorepo architectures and hybrid apps using both native android and react native.
So we can make use of an additional **ReactInstanceManager :: setJsEngineAsHermes** method that accepts a Boolean argument from the host app while building ReactInstanceManager which can tell which library to load at startup in **ReactInstanceManagerBuilder** which will now have an enhanced getDefaultJSExecutorFactory method that will combine the old logic with the new one to load the dso files.
The code snippet in **ReactInstanceManager** for adding a new setter method:
```
/**
* Sets the jsEngine as JSC or HERMES as per the setJsEngineAsHermes call
* Uses the enum {link JSInterpreter}
* param jsEngine
*/
private void setJSEngine(JSInterpreter jsEngine){
this.jsEngine = jsEngine;
}
/**
* Utility setter to set the required JSEngine as HERMES or JSC
* Defaults to OLD_LOGIC if not called by the host app
* param hermesEnabled
* hermesEnabled = true sets the JS Engine as HERMES and JSC otherwise
*/
public ReactInstanceManagerBuilder setJsEngineAsHermes(boolean hermesEnabled){
if(hermesEnabled){
setJSEngine(JSInterpreter.HERMES);
}
else{
setJSEngine(JSInterpreter.JSC);
}
return this;
}
```
The code snippet for the new logic in **ReactInstanceManagerBuilder**:
1) Setting up the new logic:
Adding a new enum class :
```
public enum JSInterpreter {
OLD_LOGIC,
JSC,
HERMES
}
```
A setter getting boolean value telling whether to use hermes or not and calling a private setter to update the enum variable.
```
/**
* Sets the jsEngine as JSC or HERMES as per the setJsEngineAsHermes call
* Uses the enum {link JSInterpreter}
* param jsEngine
*/
private void setJSEngine(JSInterpreter jsEngine){
this.jsEngine = jsEngine;
}
/**
* Utility setter to set the required JSEngine as HERMES or JSC
* Defaults to OLD_LOGIC if not called by the host app
* param hermesEnabled
* hermesEnabled = true sets the JS Engine as HERMES and JSC otherwise
*/
public ReactInstanceManagerBuilder setJsEngineAsHermes(boolean hermesEnabled){
if(hermesEnabled){
setJSEngine(JSInterpreter.HERMES);
}
else{
setJSEngine(JSInterpreter.JSC);
}
return this;
}
```
2) Modifying the getDefaultJSExecutorFactory method to incorporate the new logic with the old one:
```
private JavaScriptExecutorFactory getDefaultJSExecutorFactory(
String appName, String deviceName, Context applicationContext) {
// Relying solely on try catch block and loading jsc even when
// project is using hermes can lead to launch-time crashes especially in
// monorepo architectures and hybrid apps using both native android
// and react native.
// So we can use the value of enableHermes received by the constructor
// to decide which library to load at launch
// if nothing is specified, use old loading method
// else load the required engine
if (jsEngine == JSInterpreter.OLD_LOGIC) {
try {
// If JSC is included, use it as normal
initializeSoLoaderIfNecessary(applicationContext);
JSCExecutor.loadLibrary();
return new JSCExecutorFactory(appName, deviceName);
} catch (UnsatisfiedLinkError jscE) {
if (jscE.getMessage().contains("__cxa_bad_typeid")) {
throw jscE;
}
HermesExecutor.loadLibrary();
return new HermesExecutorFactory();
}
} else if (jsEngine == JSInterpreter.HERMES) {
HermesExecutor.loadLibrary();
return new HermesExecutorFactory();
} else {
JSCExecutor.loadLibrary();
return new JSCExecutorFactory(appName, deviceName);
}
}
```
### **Suggested changes in any Android App's MainApplication that extends ReactApplication to take advantage of this fix**
```
builder = ReactInstanceManager.builder()
.setApplication(this)
.setJsEngineAsHermes(BuildConfig.HERMES_ENABLED)
.setBundleAssetName("index.android.bundle")
.setJSMainModulePath("index")
```
where HERMES_ENABLED is a buildConfigField based on the enableHermes flag in build.gradle:
`def enableHermes = project.ext.react.get("enableHermes", true)
`
and then
```
defaultConfig{
if(enableHermes) {
buildConfigField("boolean", "HERMES_ENABLED", "true")
}
else{
buildConfigField("boolean", "HERMES_ENABLED", "false")
}
}
```
Our app was facing a similar issue as listed in this list: **https://github.com/facebook/react-native/issues?q=is%3Aissue+is%3Aopen+DSO**. Which was react-native trying to load jsc even when our project used hermes when a debug build was deployed on a device using android studio play button.
This change can possibly solve many of the issues listed in the list as it solved ours.
## Changelog
[GENERAL] [ADDED] - An enum JSInterpreter in com.facebook.react package:
```
/**
* An enum that specifies the JS Engine to be used in the app
* Old Logic uses the legacy code
* JSC/HERMES loads the respective engine using the revamped logic
*/
public enum JSInterpreter {
OLD_LOGIC,
JSC,
HERMES
}
```
[GENERAL] [ADDED] - An enum variable storing the default value of Js Engine loading mechanism in ReactInstanceManagerBuilder:
```
private JSInterpreter jsEngine = JSInterpreter.OLD_LOGIC;
```
[GENERAL] [ADDED] - A new setter method and a helper method to set the js engine in ReactInstanceManagerBuilder:
```
/**
* Sets the jsEngine as JSC or HERMES as per the setJsEngineAsHermes call
* Uses the enum {link JSInterpreter}
* param jsEngine
*/
private void setJSEngine(JSInterpreter jsEngine){
this.jsEngine = jsEngine;
}
/**
* Utility setter to set the required JSEngine as HERMES or JSC
* Defaults to OLD_LOGIC if not called by the host app
* param hermesEnabled
* hermesEnabled = true sets the JS Engine as HERMES and JSC otherwise
*/
public ReactInstanceManagerBuilder setJsEngineAsHermes(boolean hermesEnabled){
if(hermesEnabled){
setJSEngine(JSInterpreter.HERMES);
}
else{
setJSEngine(JSInterpreter.JSC);
}
return this;
}
```
[GENERAL] [ADDED] - Modified **getDefaultJSExecutorFactory** method
```
private JavaScriptExecutorFactory getDefaultJSExecutorFactory(
String appName, String deviceName, Context applicationContext) {
// Relying solely on try catch block and loading jsc even when
// project is using hermes can lead to launch-time crashes especially in
// monorepo architectures and hybrid apps using both native android
// and react native.
// So we can use the value of enableHermes received by the constructor
// to decide which library to load at launch
// if nothing is specified, use old loading method
// else load the required engine
if (jsEngine == JSInterpreter.OLD_LOGIC) {
try {
// If JSC is included, use it as normal
initializeSoLoaderIfNecessary(applicationContext);
JSCExecutor.loadLibrary();
return new JSCExecutorFactory(appName, deviceName);
} catch (UnsatisfiedLinkError jscE) {
if (jscE.getMessage().contains("__cxa_bad_typeid")) {
throw jscE;
}
HermesExecutor.loadLibrary();
return new HermesExecutorFactory();
}
} else if (jsEngine == JSInterpreter.HERMES) {
HermesExecutor.loadLibrary();
return new HermesExecutorFactory();
} else {
JSCExecutor.loadLibrary();
return new JSCExecutorFactory(appName, deviceName);
}
}
```
Pull Request resolved: https://github.com/facebook/react-native/pull/33952
Test Plan:
The testing for this change might be tricky but can be done by following the reproduction steps in the issues related to DSO loading here: https://github.com/facebook/react-native/issues?q=is%3Aissue+is%3Aopen+DSO
Generally, the app will not crash anymore on deploying debug using android studio if we are removing libjsc and its related libraries in **packagingOptions** in build.gradle and using hermes in the project.
It can be like:
```
packagingOptions {
if (enableHermes) {
exclude "**/libjsc*.so"
}
}
```
Reviewed By: lunaleaps
Differential Revision: D37191981
Pulled By: cortinico
fbshipit-source-id: c528ead126939f1d788af7523f3798ed2a14f36e
Summary:
Changelog: [Internal] Fixing a recent optimization to prevent event dispatches for events that are not listened for. An incorrect hitpath was passed in for `leave` events.
Refactored the PointerEvent optimization such that `filterByShouldDispatch` determines what views should dispatch a PointerEvent, and `dispatchEventForViewTargets` to actually dispatch them. We are separating this because the order of dispatch differs between `enter` and `leave` events.
Reviewed By: vincentriemer
Differential Revision: D37348726
fbshipit-source-id: a09a04df3ae027cce95e0d93a4163c2015fe3fe3
Summary:
We need to check that the animated node exists prior to executing the animation. The native animated node lifecycle is not synced with Fabric and nodes are frequently destroyed and re-created on rerenders. Therefore, there is a possibility that the the animated node does not exist when the native event is dispatched, in particular with native call batching.
Changelog:
[Internal] - Make NativeAnimatedNodesManager.getNodeById public
Reviewed By: JoshuaGross
Differential Revision: D37323138
fbshipit-source-id: ed0567871b4189c454b6b3145b853ecdfe844840
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predicatable.
Reviewed By: evanyeung
Differential Revision: D37353648
fbshipit-source-id: e5a0c685ced85a8ff353d578b373f836b376bb28
Summary:
ThemedReactContext should be what is stored as the context on all RN views, but some legacy components use other things like an Activity.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D37356865
fbshipit-source-id: bc914cd06a8846037506a50f254995a6e10c8a9c
Summary:
This PR is a follow up for the contributing content move on the website:
* https://github.com/facebook/react-native-website/pull/3120
It replaces most of the CONTRIBUTING file content with a reference to the contributing overview page on the website, which has been based off the content of this file.
Additionally I have searched thought the code for the wiki links and replaces theme with the correct website links. There was an instance where comment was referring to an old and removed a while ago wiki page, so I just get rid of this link.
## Changelog
[Internal] [Chore] - Update CONTRIBUTING.md, replace wiki links
Pull Request resolved: https://github.com/facebook/react-native/pull/34035
Test Plan: N/A
Reviewed By: lunaleaps
Differential Revision: D37318814
Pulled By: cortinico
fbshipit-source-id: d3f5e5c5bd477c0de5c4f0f1d5de81f464b9f5b4
Summary:
Fix crashes that can occur on older versions of Android due to not-yet-implemented APIs.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D37321713
fbshipit-source-id: a27aaf4b28e19a86f4cb10808162102177b9f306
Summary:
Bumping RTC-Folly version used to address CVE-2022-24440.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General][Security] - Bump RTC-Folly to 2021-07-22
Pull Request resolved: https://github.com/facebook/react-native/pull/33841
Reviewed By: Andjeliko, philIip
Differential Revision: D36425598
Pulled By: cortinico
fbshipit-source-id: d38c5f020dbecf794b10f12ed2da30e1825071af
Summary:
Fixes a trivial crash that occurs when running View Recycling on pre-Android P devices.
Changelog: [Internal]
Reviewed By: bvanderhoof
Differential Revision: D37242858
fbshipit-source-id: 74f3912d60799172c47c67a87f662b4ff8fb1e35
Summary:
Changelog: [Internal][Changed]
The diff I'm backing out accidentally made Hover events in Felios apps that use RN under the hood stopped working in headsets (Oculus, Arcata). So we can't test our apps properly without these events.
We, with the diff author Luna tried to fix that but it turned out to be not easy so we decided to revert the commit in order to unblock experiences teams.
Original commit changeset: d6b5c32ae50b
Original Phabricator Diff: D36601638 (40769f2212)
(Note: this ignores all push blocking failures!)
Reviewed By: arhelmus
Differential Revision: D37135208
fbshipit-source-id: 4f7d5f168b795690e951ce7063ae3feec3338772
Summary:
Adds support for handling animations in response to events on the platform side, without needing a JS round trip. With this TM, NativeViewEvents will no longer affected by JS thread - hover events will not be delayed when JS thread is busy. This makes a significant difference for VR panel apps - see test plan for an example for the before and after in Store.
Changelog:
[Internal] - Make NativeAnimatedNodesManager public
Reviewed By: JoshuaGross
Differential Revision: D37082069
fbshipit-source-id: 330acd78c547587de5545b61895e0d821fb99552
Summary:
We currently wrap colors in an object to make it look similar to a `PlatformColor` object, but since this is a hot codepath, let's just optimize it to a simple array of strings. The next step is to apply a layer of caching here, but this should be a simple improvement.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D31057046
fbshipit-source-id: f68e17167ddd5bba3b545d039600c7c9b40808f5
Summary:
In https://github.com/facebook/react-native/pull/32695, the `Performance.now()` implementation changed to use unix epoch timestamps instead of a monotonic clock.
This is problematic, because it means that performance measurements get skewed if the device clock changes between two measurements.
With this change, the clock is now monotonic (and the implementation stays consistent between platforms).
More details and repro steps can be found in [this issue](https://github.com/facebook/react-native/issues/33977)
Closes https://github.com/facebook/react-native/issues/33977
## Changelog
[General] [Fixed] - Use monotonic clock for performance.now()
Pull Request resolved: https://github.com/facebook/react-native/pull/33983
Test Plan:
Run on iOS and Android:
```
const now = global.performance.now()
console.log(`${Platform.OS}: ${now}`)
```
Reviewed By: JoshuaGross, cipolleschi
Differential Revision: D37066999
Pulled By: dmitryrykun
fbshipit-source-id: 298547bf39faea1b025c17ff2d2e1a03f929865b
Summary:
The idea behind this is to encapsulate as much build logic as possible inside a `.cmake` file which is contained inside React Native.
This reduces the API surface for the users, once we apply this change to the `template` project, and makes easier for us to evolve native library dependencies on Android, without having to worry about asking users to replicate those changes.
Currently the change is only on RN Tester, will replicate to the template afterwards
## Changelog
[Internal] [Changed] - Encapsulate all the CMake build logic inside a `ReactNative-application.cmake` file for RN Tester
Pull Request resolved: https://github.com/facebook/react-native/pull/33985
Test Plan: Circle CI
Reviewed By: cipolleschi
Differential Revision: D37039658
Pulled By: cortinico
fbshipit-source-id: 536593e3b7227158acba3f0fb6561efaaa9720a5
Summary:
It turned out the previous attempt to rely on the Event's UIManagerType wasn't sufficient, as not all Fabric touch event had a surfaceId set on them, e.g. Modal etc.
This brings back the UIManagerType detection based on reactTag, but do it only for non-rootView to keep handling touch via the right dispatcher for rootView as well.
Changelog: [Fixed][Android] Bring back non-rootview touch handling based on reactTag
Reviewed By: JoshuaGross, sshic
Differential Revision: D37063335
fbshipit-source-id: 76e2d7ae5f00006c5ecaf50c86920ea6e85155b7
Summary:
This diff adds an assertion to make sure the pending events are enqueued only when the event emitter is null. This is to avoid unexpected workflow when we queue events but we should just dispatch them.
Changelog:
[Android][Internal] - Make sure we only queue events when event emitter is null
Reviewed By: javache
Differential Revision: D36916482
fbshipit-source-id: fff305615b302ece26bc2482c826b74de4f70266
Summary:
D36784563 (ec307e0167) caused some issues with TextInputs with numeric keyboard types not respecting the secureTextEntry prop
Changelog
[Android] [Fixed] - Revert PR 33924 because of issues with TextInputs with numeric keyboard types not respecting the secureTextEntry prop
Reviewed By: makovkastar
Differential Revision: D36994688
fbshipit-source-id: 89cd556ca1cf8fd89560aeb9ead129607b4c13c6
Summary:
This diff address an edge case when the pending events are enqueued when the surface is stopped. In this case we will reset map that holds view state to null, which will cause NPE.
Changelog:
[Android][Fixed] - Fix edge case when we enqueue a pending event to views on stopped surface
Reviewed By: javache, gorodscy
Differential Revision: D36912786
fbshipit-source-id: 3ae5a4b08a0a6bf55538d69ac80a101c2c3d899a
Summary:
When tapping on ReactRootView and having Fabric enabled, the touch logic mistakenly dispatch the event to JS via the legacy renderer. This is because the destination was computed based on reactTag (odd = legacy, even = Fabric), but root view tag happens to be always odd (always ends with 1). This change uses the right destination based on what the Event itself tells us, instead of deriving from the reactTag.
Changelog: [Android][Fixed] Fix Fabric touch event dispatching for root views
Reviewed By: JoshuaGross, sshic
Differential Revision: D36917300
fbshipit-source-id: 838b4e135d7df07c37040bd47d71370ff10df067
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33937
This moves the build of RNTester from Unix Make to CMake
This will serve as a blueprint for users that are looking into using CMake end-to-end in their buildls.
In order to make this possible I had to:
* Add an `Android-prebuilt.cmake` file that works similar to the `Android-prebuilt.mk` for feeding prebuilt .so files to the consumer build.
* Update the codegen to use `JSI_EXPORT` on several objects/classes as CMake has stricter visibility rules than Make
* Update the sample native module in `nativemodule/samples/platform/android/` to use CMake instead of Make
Changelog:
[Internal] [Changed] - Build RN Tester with CMake
Reviewed By: cipolleschi
Differential Revision: D36760309
fbshipit-source-id: b99449a4b824b6c0064e833d4bcd5969b141df70
Summary:
This diff fixes the rendering of transparent borders in RN Android views
The fix clips the view ONLY when there is a border color that's non transparent
This change unifies the rendering of transparent and semitransparent borders for Views between RN Android, iOS and Web
Changelog: [Android][Fix] Fix rendering of transparent borders in RN Android
Reviewed By: JoshuaGross
Differential Revision: D36890856
fbshipit-source-id: 38fc2ae215f136160a73ca470e03fada8cb81ced
Summary:
In the constructor we should get the default gravity params (as we did previously) and then never change these; thus, we can also make these fields final. These are used in `initView` during construction and upon recycling to reset vertical and horizontal alignment to their defaults.
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36885646
fbshipit-source-id: 2f4d0b125b8645a380a08965e08db3ba1f12cae3
Summary:
Right now, when we change the keyboardType on android between between default and email, the value keyboard type stays as email (specially noticeable with the key next to the spacebar, that changes between the comma (`,`) to the at sign (`@`)).
This is because the mask we are using when updating the input is only taking into account the class, and not the flags nor the variations.
We don't apply all masks because it may interfere with flags assigned by other props, like multiline or secure text entry. Therefore, we have created our own mask, taking into account all the variations and flags that the keyboardType prop may set. This may be hard to maintain, since whenever we add any other keyboard type, we have to take these flags into mind.
The error I was trying to fix was in particular regarding going back and forward from email, but this fix may solve other similar issues with other keyboard styles.
## Changelog
[Android] [Fixed] - Fix a bug where the keyboard, once set as email, won't change back to default.
Pull Request resolved: https://github.com/facebook/react-native/pull/33924
Test Plan: In order to test this PR, any test code with a TextInput, and a way to change the value of the keyboardType should work. We should be able to see how the keyboard changes to the correct type without staying, for example, on the email state.
Reviewed By: lunaleaps
Differential Revision: D36784563
Pulled By: makovkastar
fbshipit-source-id: 74d7b61b3c07feea4e4050d7a07603a68b98e835
Summary:
tldr; `ReactEditText` and Android's emoji support in Android's AppCompat 1.4.0 / 1.4.x conflict in an odd way, causing NPEs.
`ReactEditText` defines an `InternalKeyListener`, `mKeyListener`, that it uses to make sure input from all keyboards works correctly. This listener is normally initialized at the end of the constructor.
Unfortunately, some versions of `AppCompatEditText`, most notably the version in the App Compat `1.4.0-alpha0x`, the [minimum version required for the Play Store's emoji compliance](https://developer.android.com/guide/topics/ui/look-and-feel/emoji2#appcompat) call `setInputType` from `AppCompatEditText`'s constructor. `ReactEditText` operates on the key listener inside of `setInputType` and since the `AppCompatEditText` constructor is called via call to `super` before the key listener is initialized, these versions of app compat can cause NPEs when used with React Native.
The fix is simple; check to see if `mKeyListener` is null, and initialize it if it is. This is necessary in both the constructor and inside of `setInputType`.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
https://github.com/facebook/react-native/wiki/Changelog
[Android] [Fixed] - NPE in `ReactEditText.setInputType` when React Native is used with some versions of a AppCompat 1.4.x. (and possibly others)
Pull Request resolved: https://github.com/facebook/react-native/pull/33920
Test Plan:
1. Build an app with both React Native and load it inside an app that is using AppCompat 1.4.x
2. Add a text field using React Native.
3. Open the screen of the app that contains the text field.
If you're working from this branch, you'll be fine. If you're working from main you'll get an NPE.
I can put together a test repo if needed.
Reviewed By: kacieb
Differential Revision: D36802622
Pulled By: cortinico
fbshipit-source-id: e7646da9a1ef0e0334152aecab0f972ca25092ec
Summary:
Adding a flag to prepare for the phase 3 of the new architecture. This is still work in progress, not usable yet.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D36767843
fbshipit-source-id: 338d775681f2890461608b403749c3a7f05f84ff
Summary:
Followups to View Recycling diffs to improve things / clean up things a bit. This also fixes memory warnings which were not hooked up before.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D36707792
fbshipit-source-id: 410e70bf0eeec5569566138af547e1601394d0e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33897
Now the exception will display the class which caused the exception as well as helpful information as to why.
We've seen this happen a bunch due and have been very confused by the error message. It turns out that this processor runs before the classes listed are compiled. This means that if there's a compile error (or a missing import) the user will only see that this processor crashed, and not the compile error.
The additional information in the error is:
`java.lang.RuntimeException: Could not load classes set in ReactModuleList.nativeModules. Check that they exist and are imported correctly on class: com.meta.x.y.ReactPackage`
In this case, `com.meta.x.y.ReactPackage` is the class which needs to be fixed. Before, the error message made no mention of this class or the annotation.
Changelog: [Internal] This will change the way the annotation processor crashes. It will throw a RuntimeException instead of a ClassCastException.
Reviewed By: javache
Differential Revision: D36606279
fbshipit-source-id: aedf9682286fba49e23716b7eda16b2dd3b13422
Summary:
See previous diff for details on general approach and benchmarks.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D36676887
fbshipit-source-id: b177dcd19f1ea687bf7d2d4f2f637d2924723340
Summary:
Changelog: [Internal][Changed] - Make the same optimization on enter/leave/move pointer events being dispatched by a mouse input.
If any ancestor view is listening to enter/leave events (just capture) then we dispatch the enter/leave event.
Reviewed By: vincentriemer
Differential Revision: D36601638
fbshipit-source-id: d6b5c32ae50bcf000100bcb878ca2ca89bd5c02e
Summary:
RN-Tester is currently crashing at startup time due to an NPE.
This PR fixes it.
## Changelog
[Android] [Fixed] - Fix NPE on `ReactEditText` due to null mFabricViewStateManager
Pull Request resolved: https://github.com/facebook/react-native/pull/33910
Test Plan: Tested locally that RN Tester runs both in Debug and in Release
Reviewed By: cipolleschi
Differential Revision: D36666440
Pulled By: cortinico
fbshipit-source-id: f004ff228fb4f9ff339aac606858d47de3706426
Summary:
There are two methods in ReactRootView to handle touch events "onInterceptTouchEvent" and "onTouchEvent", for Venice we have ReactSurfaceView inherits ReactRootView but the implementation for above 2 touch handling methods still calls into it's super implementation which uses the bridge.
In this diff we make ReactSurfaceView inherits ReactRootView's "dispatchJSTouchEvent" and "dispatchJSPointerEvent". So that Venice has separate implementation for touch events handling.
Changelog:
[Android][Changed] - Revamp touch event dispatching methods
Reviewed By: fkgozali, JoshuaGross
Differential Revision: D36629466
fbshipit-source-id: fb7c5950afe6249d22edd3fac3fa5d3b83b3af84
Summary:
This op code was incorrectly configured to take two args, while it only takes one.
Changelog: [Internal]
Differential Revision: D36664590
fbshipit-source-id: 6e1fdb9f64bbd32fbe05bbd174f94ae57292bcf9
Summary:
This diff cleans up several Android Makefiles which we're not using anymore
as they've been replaced by CMake files.
There are still 3 Makefiles left, which I'm aiming to remove in the near future.
Changelog:
[Internal] [Changed] - Remove unused Makefiles from React Native core
Reviewed By: javache
Differential Revision: D36660902
fbshipit-source-id: 8afffac74d493616b0f9414567821cd69f4ef803
Summary:
There's no need for this to be a setter/getter, as there are no side-effects, and it means we can use the same helper method to read it as other feature flags.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36595602
fbshipit-source-id: d27c01bd39d03606a6f8c17ba181a8cd0bf58dbb
Summary:
Enables two new experiments (and the current behaviour as default) to speed up access to TurboModule methods from JS.
1) HostObject - Current behaviour
2) Prototype - Connect the TM HostObject via `__proto__`, and cache any methods accessed on the wrapper object.
3) Eager - Eagerly store all methods on the wrapper object, do not expose the HostObject to JS at all (TurboModules no longer need to be HostObjects in this scenario)
Changelog: [Internal]
Reviewed By: JoshuaGross, rubennorte, mdvacca
Differential Revision: D36590018
fbshipit-source-id: c9565eb239eb6aeee0f06b581ff8cd72a92073fc
Summary:
* Make constructor private, all access is through install()
* Use nullability of longLivedObjectCollection_ instead of separate bool disableGlobalLongLivedObjectCollection_
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D36592492
fbshipit-source-id: d65e779e1ac9fbe121937c5a20763aefcd589795
Summary:
In D36345402 (56e9aa369f) I changed the behaviour for mount items to be skipped if they were just setting zero values. AndroidTextInput is the only component that I'm aware of that has non-zero padding by default, and we account for this when creating the native shadow node. This optimization broken TextInput use-cases that explicitly request zero-padding, since we end up ignoring it.
To keep this optimization, explicitly init ReactTextInput's padding to 0, but only in Fabric. `updateState` was the closest thing I could find to a Fabric-only callback, once it's fully rolled out, we can also move this to the constructor.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D36545775
fbshipit-source-id: 07bb96032c69d7e350980b0b975e637b66c307ed
Summary:
I have never seen these asserts fire in production. They're pretty cheap but the cost is not zero. We will use annotations and test carefully in debug if we need to ensure that something runs on a particular thread - which we do anyway.
Motivation: this method is called /extremely frequently/, everywhere in the mounting layer. And 99.99% of the time it's completely useless and results in absolutely no signal. In many cases, it will be called hundreds or thousands of times during a single operation (for example, when executing the IntMountBuffer items, each sub-item will call this many times).
Wall-clock time is usually low according to systrace (sometimes there are odd spikes), but over time these do add up and it seems good to save a few ms here and there.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D36539399
fbshipit-source-id: 3e023be64b8c9f0e6c3c8347c077ce9fa38f74a4
Summary:
It's useful to have more systrace markers that are all the same, so that they can all be aggregated and work underneath them aggregated across an entire trace. As it is, this marker gets treated as unique nearly every time which makes analysis harder.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D36533075
fbshipit-source-id: 925afa7db152eca1166891b41e7c6f6a511840af
Summary: Changelog: [Internal] - Bypass dispatching an event if no view along the hierarchy is listening to it. Only applied for touch-based interactions. Next change will add optimization for mouse interactions
Reviewed By: vincentriemer
Differential Revision: D35739417
fbshipit-source-id: 134ffefef3bb4f97bf3e63b6bccc0caca464dfbd
Summary:
We don't want to include tests as they're not valuable for our users + the might break users build if they try to run `./gradlew build`.
Changelog:
[Internal] [Changed] - Do not publish Android tests inside the NPM package
Reviewed By: cipolleschi
Differential Revision: D36600831
fbshipit-source-id: b88ee4dc93f276cd0729a2193346f5fcde34323c
Summary:
I've accidentally broke the external CI.
The reason is that root is defaulted to `$rootProject/..`.
The Gradle Plugin assumes there is a package.json there, which is always the case for RN projects, given that root is configured properly.
This was green on internal CIs as it was actually hitting the file on `xplat/js/package.json`. Externally, there is no such file, therefore is failing.
The fix is to specify the root path and don't use the default for ReactAndroid
Changelog:
[Internal] [Fixed] - Set root to be `..` for ReactAndroid
Reviewed By: cipolleschi
Differential Revision: D36597308
fbshipit-source-id: 66638ee1014ef35c81195526e0b325f5cc008b82
Summary:
Splitting these changes of from D36482630, which is a minor improvement to the singleOp experiment. Since we call start/finish already on the native side, we don't need to repeat it from JS.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D36541700
fbshipit-source-id: 7d61669710faca3153be557fb2d214011eda87c5
Summary:
* Make inner classes static where possible
* Make member variables final when set from constructor
* Remove Nullable on `mFabricViewStateManager` and associated checks
* Remove `createInternalEditText` which has moved to the ShadowNode (paper-only)
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36545807
fbshipit-source-id: 85517511d1734f0e55de5caa012e32feb40e8492
Summary:
ViewManager does a null-check already, and so inside the `updateState` method, we can safely assume this parameter is no longer nullable.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D36545806
fbshipit-source-id: 92eefa518f11c17b91aa3da2e14066d36fa4f4c2
Summary:
`test_android` is currently broken as it tries to build with `source = "7"` (the default).
This is a best guess fix to try to fix this issue.
## Changelog
[Internal] - Attempt to fix test_android by specifying source 8
Pull Request resolved: https://github.com/facebook/react-native/pull/33890
Test Plan: Will rely on CI
Reviewed By: cipolleschi
Differential Revision: D36589814
Pulled By: cortinico
fbshipit-source-id: 8ef50f8531b9d4367d2f2c75a312e8fdaf38fd85
Summary:
This will fix a crash on Motorola devices on Android 7, where WebView fails to load due to initialisation issues in the WebViewChromiumFactoryProvider (Caused by org.chromium.base.library_loader.ProcessInitException).
## Changelog
[Android][Fix] - Exception with `Cannot load WebView` message will initialising WebView (along with existing checks)
Pull Request resolved: https://github.com/facebook/react-native/pull/33867
Test Plan: <img width="1368" alt="Screenshot 2022-05-19 at 02 21 57" src="https://user-images.githubusercontent.com/933314/169154293-c442a54f-96f5-4309-a6ce-c8f9c4beeb17.png">
Reviewed By: javache
Differential Revision: D36517673
Pulled By: cortinico
fbshipit-source-id: 4fa5b903529eb04d01ed8fa540cbd883224e8e62
Summary:
I'm finding it useful to keep track of a few additional numbers when doing perf analysis in Fabric.
Also making it easier to enable just these perf logs without all of the other verbose Fabric logs.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D36500518
fbshipit-source-id: e57e1e75131c5d59da876d1decb96d4da386f025
Summary:
We were calling the wrong operation from the MegaOp which caused indices to become offset. Trivial fix.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D36482822
fbshipit-source-id: 83ebc37a8773f0277db4caff9d3e7c9c91931ddb
Summary:
Which idiot wrote this? Oh yeah, I did.
This was introduced in D36109810 (bf405d7083) so hasn't been around too long luckily.
Changelog: [Internal]
Reviewed By: cortinico, GijsWeterings
Differential Revision: D36480272
fbshipit-source-id: b0fbb6b820185185359c6c75f77f2921dc892b02
Summary:
I'm disabling the publishing of Javadoc as it's currently failing on CI.
The failure is happening due to a concurrency problem during the Kotlin
documentation generation.
As we don't have much Javadoc to export, I'm removing this for now.
Changelog:
[Internal] [Fixed] - Disable Javadoc publishing as it's currently failing on CI
Reviewed By: cipolleschi
Differential Revision: D36481215
fbshipit-source-id: 6f875932013f80779151f75e20d25ba3b71de074
Summary: Changelog: [Android][Fixed] Scroll views would still receive scroll events when nested in a view with `pointer-events: "none"`
Differential Revision: D36423921
fbshipit-source-id: 87b8a236e15dda7b648b6fc649187e95a9a2cc42
Summary:
Noticed that we emit a large amount of (admittedly cheap) mountitems as part of node creation for values that are all zero (e.g. padding, overflowinset), which we can assume to be already initialised with these values on the native side.
There's a further opportunity to do this for State as well, as ReactImageComponentState exports just empty maps to Java.
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36345402
fbshipit-source-id: 8d776ca124bdb9e1cd4de57a04e2785a9a0f918c
Summary:
We introduce a few optimizations:
(1) Previous diff: We defer calling any NativeAnimatedModule methods by waiting 1ms before flushing the queue, and debouncing until no flush is requested. Practically, this just means that we'll call NativeAnimatedModule methods N times at once, at the end of a render loop, instead of N times smeared throughout the render loop.
(2) Additionally, instead of calling N methods, we create multi-operation argument buffer and call a single NativeAnimatedModule API, which should essentially throttle NativeAnimatedModule API calls to once-ish per frame. On the native side, this also reduces a lot of overhead associated with scheduling work on the UI thread (we schedule 1 function to run on the UI thread and perform N operations, as opposed to scheduling N functions to run on the UI thread).
TODO:
- implement stubs for iOS
- write gating code so this can be properly tested in VR and in fb4a
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36338606
fbshipit-source-id: 29ac949b53b874683128a76525586c22def3143b
Summary:
We try to remove the use test_ownership_2020 oncall, which was created to enforce oncall field in test module. This diff stack tries its best to guess who the right oncall is for these "unowned" tests.
If you don't think this belongs to you, please
1. Either re-assign to another team to your best knowledge
2. Or delete the test
Every test should have an owner!
Differential Revision: D36404812
fbshipit-source-id: daf57e860d3700928ae4518897d87247a672eae4
Summary:
Noticed that (LockFree)EventDispatcherImpl had NativeAnimatedNodesManager as a listener 100+ times, as listener registration can happen multiple times from Animated node creation. Since listener management on event dispatcher is thread-safe, we can avoid the thread hop for this.
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36316102
fbshipit-source-id: f2f417b69885def87f88460d8b1e0b35b66726cb
Summary:
This diff fixed an edge case that event dispatching is failed after pre-allocation of a view and before the view is mounted.
When a cached image is loaded, we will dispatch the event to JS immediately. This is could happen after the view is created during pre-allocation phase, when the event emitter is not instantiated yet. In that case, we will see [an error](https://github.com/facebook/react-native/blob/main/ReactAndroid/src/main/java/com/facebook/react/fabric/FabricUIManager.java#L927) and the event will effectively be ignored.
To fix that we introduced a queue in this diff for those events. They will be dispatched in order when the view is mounted and the event emitter is non-null.
Changelog:
[Android][Fixed] - Fixed an edge case that event dispatching is failed after pre-allocation of a view and before the view is mounted.
Reviewed By: mullender
Differential Revision: D36331914
fbshipit-source-id: cd065b0b36978cb5f0aac793d8d16f07a48f0881
Summary:
Currently on Android, React Native can only accept font resource IDs which it internally converts into Typeface objects. This change allows ReactFontManager to be passed a Typeface at runtime to enable e.g. downloading fonts on demand.
Changelog:
[Android][Added] - Ability to pass a Typeface object to ReactFontManager in addition to a font resource ID
Reviewed By: makovkastar
Differential Revision: D36138123
fbshipit-source-id: b314e8c7fc28174b5caa017076b6eb3d4f6dbaa8
Summary:
This way we can avoid unnecessary ArrayList copies.
Changelog: [Android][Changed] Generalized the return type of ViewManagerOnDemandReactPackage.getViewManagerNames
Reviewed By: nlutsenko
Differential Revision: D36131516
fbshipit-source-id: 6a42c76cadbcce4c3720875d80062e1ee237bc2f
Summary:
Based on Google Play crash logs, crashes due to the assertions in `dispatchViewManagerCommand` is our top source of crashes:
```
com.facebook.react.uimanager.IllegalViewOperationException: Unable to execute operation dispatchViewManagerCommand: blur on view with tag: 17549, since the view does not exists
at com.facebook.react.uimanager.UIImplementation.assertViewExists(UIImplementation.java:830)
at com.facebook.react.uimanager.UIImplementation.dispatchViewManagerCommand(UIImplementation.java:713)
at com.facebook.react.uimanager.UIManagerModule.dispatchCommand(UIManagerModule.java:739)
at com.facebook.react.uimanager.UIManagerModule.dispatchViewManagerCommand(UIManagerModule.java:726)
at com.facebook.react.uimanager.ReanimatedUIManager.dispatchViewManagerCommand(ReanimatedUIManager.java:233)
at java.lang.reflect.Method.invoke(Method.java:-2)
at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:372)
at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:151)
at com.facebook.react.bridge.queue.NativeRunnable.run(NativeRunnable.java:-2)
```
There are many other places in UIImplementation that instead of throwing a fatal exception, just log a message and continues execution.
Logging a message and discarding the command should be safe for commands like "blur this view". We keep the previous behavior in debug mode, but just log and discard commands in production.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Android] [Fixed] - Avoid crash by handling missing views in dispatchViewManagerCommand
Pull Request resolved: https://github.com/facebook/react-native/pull/33795
Test Plan: We had a tough time reproducing specific crashes, but we ran with this binary in the latest release of our app and it has eliminated this class of crashes from Google Play and Bugsnag instrumentation.
Reviewed By: cortinico
Differential Revision: D36285603
Pulled By: JoshuaGross
fbshipit-source-id: db0be74926c4cb83f07686398579236da8e586bf
Summary:
This diff adds a CompositeReactPackageTurboModuleManagerDelegate which can be used to combine 1 or more TurboModuleManagerDelegates into a single one.
This is useful when both the app and one or multiple of its libraries provides a TurboModuleManagerDelegate
Changelog:
[Internal] [Changed] - Add CompositeReactPackageTurboModuleManagerDelegate
Reviewed By: mdvacca
Differential Revision: D36187694
fbshipit-source-id: 88f1d689342345b4cb7e67186791ad5bd1a6f21b
Summary:
This Change fixes a possible null exception as the user uses AppCompat 1.4.0
as a dependency in their App and uses a `TextInput` component.
The exception may happen as `mFabricViewStateManager` is accessed during
the constructor of the superclass, and is not yet initialized.
- For reference, commit #e21f8ec34984551f87a306672160cc88e67e4793 fixes the crash which was already happening.
<!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? -->
Possible null exception as `mFabricViewStateManager` is accessed during
the constructor of the superclass, white it is not yet initialized.
This commit #e21f8ec34984551f87a306672160cc88e67e4793 fixes the crash which was already happening, accessing of mFabricViewStateManager before initialization, and left another one of the call of the same nature.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
Fix: accessing `mFabricViewStateManager` before initialization.
[JavaScript] [Fixed] - accessing `mFabricViewStateManager` before initialization.
Pull Request resolved: https://github.com/facebook/react-native/pull/33769
Test Plan: no external tool was used.
Reviewed By: javache
Differential Revision: D36205441
Pulled By: cortinico
fbshipit-source-id: f3fca69224c7794757514f026a5293b213986186
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33776
The implementations of these modules is pretty much identical, and we're already shipping the fbjni version of this anyway.
Changelog: [Internal]
Reviewed By: mhorowitz
Differential Revision: D36200330
fbshipit-source-id: 135ee621e1e4c5eb9616ce7f442fc6d4b946f865
Summary:
Cherry picking https://github.com/facebook/react-native/pull/33707 to main branch
This change is extending the changes made by alespergl to reduce the file paths and command lengths of ndk build commands
Essentially we are shortening the length of the source files by using relative paths instead of absolute paths as enumerated by the wildcard expression
This commit is extending the fix by including all the new modules introduced into RN for the new architecture, including the generated modules.
We are also reverting the ndk bump as ndk23 is crashing frequently when building RN with new arch. The reduced file paths lengths ensures the ndk bump is not required for relatively short application paths.
Fix building RN with new architecture on Windows boxes by using relative paths for C++ sources
## Changelog
Fix building RN with new architecture on Windows boxes by using relative paths for C++ sources
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/33784
Test Plan: Verified building on windows box
Reviewed By: javache
Differential Revision: D36241928
Pulled By: cortinico
fbshipit-source-id: 1ce428a271724cbd3b00a24fe03e7d69253f169b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33780
Currently this just has a default ThreadPool name, which can be confusing in systraces and crash reports.
Changelog: [Internal]
Reviewed By: ryancat
Differential Revision: D36200090
fbshipit-source-id: 22918993e7c822ed721ccaf79cdcd9d2a972193d
Summary:
the `WITH_INSPECTOR` build flag is missing from cmake migration. original we had it in [Application.mk](ed46ea2058/ReactAndroid/src/main/jni/Application.mk (L29))
this pr adds back the build flag and make hermes inspector (or debugging hermes in flipper) work again.
## Changelog
[Android] [Fixed] - add back hermes inspector support
Pull Request resolved: https://github.com/facebook/react-native/pull/33778
Test Plan: test on rn-tester hermes variant
Reviewed By: cipolleschi
Differential Revision: D36204525
Pulled By: cortinico
fbshipit-source-id: 417874a7d0e05b5ee886f3160d526ff9c2df44ee
Summary:
Noticed in D36098912 (5de0f145ec) that the definition of NativeAnimatedModule's OperationQueue.isEmpty was incorrect as it didn't account for `mPeekedOperation`, while `drainQueueIntoList` did.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D36109810
fbshipit-source-id: afd7059975ce6e5c65d1975d168a03f0881bd7c1
Summary:
The ReactAndroid cmake build assumes that the build directory is ReactAndroid/build, but this is not always the case if gradle is configured with a different build location. Instead of assuming the build location in cmake, pass it from gradle.
## Changelog
[Android] [Fixed] - Pass react build dir to cmake
Pull Request resolved: https://github.com/facebook/react-native/pull/33736
Test Plan:
Tested in an app with a custom build dir that RN now builds properly after this change.
In build.gradle add:
```groovy
allprojects {
buildDir = "${System.getProperty("user.home")}/.gradle/builds/${rootProject.name}/${project.name}"
}
```
Reviewed By: christophpurrer
Differential Revision: D36128556
Pulled By: cortinico
fbshipit-source-id: cdb8283c93ea7c384ec94cd3e24012220965b6dc
Summary:
This change caused some internal regression in release builds, hence reverting it
Changelog:
[Internal] [Changed] - Back out > Add CompositeReactPackageTurboModuleManagerDelegate
Reviewed By: alsun2001
Differential Revision: D36182014
fbshipit-source-id: e49fc897f3b1a2e9d33fcb7687244be74020c5be
Summary:
Assertion failure would lead to a crash, in real world not being able to start an activity shouldn't crash - usually a navigation won't happen as expected, user could try again.
Changelog:
[Android][Changed] - Don't assert on current activity when call startActivityForResult
Reviewed By: cortinico
Differential Revision: D35746652
fbshipit-source-id: 0b77ca5a69b2f3f3b0b969d84980ed8290ac9b1f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33758
This fails to compile in our CircleCI builds
```
/root/react-native/ReactAndroid/src/main/java/com/facebook/react/CompositeReactPackageTurboModuleManagerDelegate.java:52: error: incompatible types: java.util.List<java.lang.Object> cannot be converted to java.util.List<com.facebook.react.ReactPackage>
delegates.add(delegatesBuilder.build(context, Collections.emptyList()));
```
Make the empty collection generic should solve the issue
Changelog:
[Internal] [Changed] - Fix Circle CI for CompositeReactPackageTurboModuleManagerDelegate
Reviewed By: cortinico, dmitryrykun
Differential Revision: D36130573
fbshipit-source-id: 9615311798fbbd7c000838dfbc043f450c2d9e2e
Summary:
This diff adds a CompositeReactPackageTurboModuleManagerDelegate which can be used to combine 1 or more TurboModuleManagerDelegates into a single one.
This is useful when both the app and one or multiple of its libraries provides a TurboModuleManagerDelegate
Changelog:
[Internal] [Changed] - Add CompositeReactPackageTurboModuleManagerDelegate
Reviewed By: cortinico
Differential Revision: D36057036
fbshipit-source-id: bf131fa7315941b3353c0522e4d77d909b82914b
Summary: There's no need to use private feature flag for overflowInset feature. This makes future refactor on feature flags easier.
Reviewed By: javache
Differential Revision: D35866302
fbshipit-source-id: a3fde212ff40cd6d4c68832bb39b34de5a17a8d4
Summary:
Currently, we build Hermes by specifying the Cmake flag `-B ./hermes`. That means
that the output out the build is going to be placed along side the source code.
This is fine, as long as the user doesn't use the `REACT_NATIVE_OVERRIDE_HERMES_DIR`,
which is used inside the Hermes CI. In that case, the source location of Hermes can be
changed, leading to scenarios where `hermesc` can't be found.
Here I'm changing the flag to be `-B $buildDir/hermes`. Therefore the build output
will always be located within the `./ReactAndroid/hermes-engine/build` folder.
This is a more robust solution as the build output will be encapsulated within the
`build/` folder.
Changelog:i
[Internal] [Changed] - Update the hermesc output to be inside the $buildDir
Reviewed By: cipolleschi
Differential Revision: D35964402
fbshipit-source-id: aa7e0775b282897d5a99c1c46265884d19c5f289
Ruslan Shestopalyuk
Nicola Corti
Nick Gerleman
Christopher Jones
Rachit Mishra
Paige Sun
Rubén Norte
Riccardo Cipolleschi
Samuel Susla
Kudo Chien
Luna Wei
Brett Lavalla
David Vacca
Sunbreak
Paige Sun
Joshua Selbo
Danilo Bürger
Samuel Susla
Gabriel Donadel Dall'Agnol
Pieter De Baets
Evan Charlton
Rasmus Eneman
Lulu Wu
Harrison Spain
hurali97
fabriziobertoglio1987
Thuong Tran
Joshua Gross
Oleksandr Melnykov
Nick Gerleman
Alex Hunt
Sparsha Saha
Pieter Vanderwerff
Daniel Leong
Oskar Kwaśniewski
Graham Mendick
Janic Duplessis
Chatura Atapattu
Tony Du
Sim Sun
Dark Knight
Xin Chen
Mike Hardy
Ron Edelstein
Kevin Gozali
Mark Verlingieri
Kunal Farmah
Genki Kondo
Simek
Luis Santana
Artem Goncharov
Olivier Payen
Charles Dudley
Daniel Espino García
Andy Zolyak
Daniel Abramowitz
Tianyu Li
Derek Thurn
Harry Yu
Hetan Thakkar
Christoph Purrer
Mike Masam
Anandraj Govindan
Aniket Mathur
