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
Summary:
The `notifyNativeGestureEnded` API is added to notify user gesture ended, so that any optimization we had during handling the gesture can be restored.
It's possible that when the gesture finishes, the RootView is already unmounted from the native side. This might happen when user starts a gesture that caused leave of the RN screen, or close the app.
Changelog:
[Android][Internal] - Avoid NPE for gesture notifier
Reviewed By: javache
Differential Revision: D35902523
fbshipit-source-id: 9bb5819a53dd053290031eebaae1b8f0318ae534
Summary:
This diff updates the CMake command used for configuring the Hermes build
from `cmake` from $PATH to the `cmake` bundled with the Android SDK.
If not found, fallsback to the previous behavior.
This relaxes the requirement of having to ask our users to install CMake
in their CLIs.
Changelog:
[Internal] [Changed] - Use Android SDK version of CMake rather than an external one
Reviewed By: neildhar
Differential Revision: D35931306
fbshipit-source-id: 8d6c554e5e9040e3bd4fed5f72fbdb0eb61d745a
Summary:
Refactor of TouchTargetHelper.findTargetPathAndCoordinatesForTouch to avoid unnecessary lookup of views during the dispatching of Hover Events
changelog: [internal] internal
Reviewed By: lunaleaps, mdvacca
Differential Revision: D32296003
fbshipit-source-id: 93834c37331ad5d75645a5665a1c8c3d965765fb
Summary:
WHen porting TurboModules or adding new TurboModules, ReactModuleSpecProcessor may fail during buck build, and when the failure is caused by typeElement.getAnnotation, no useful information gets collected, making it difficult to debug.
So here I am adding a try & catch so we can get useful debugging info.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D35767207
fbshipit-source-id: 7e1f9dfbfd31339ab37af19c51d85085e100955a
Summary:
This diff allows to customize the Hermes version exposed by the VM with
a version provided by React Native. This will make clearer that a specific
version of Hermes was built at a specific point of the RN release process.
Changelog:
[Internal] [Changed] - Customize the Hermes version using the RN one
Reviewed By: neildhar
Differential Revision: D35820268
fbshipit-source-id: 3e76db921c12a599743fb9312f52edd06d223bad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33645
With React 18, we now need to allow users on Fabric to opt-in for Concurrent Root.
This commit adds a new method that can be called on the ReactActivityDelegate
that can be used to set the `concurrentRoot` flag on the `initialProps` on the Render.
Changelog:
[Android] [Added] - Expose an API to enable Concurrent Root on Android
Reviewed By: mdvacca
Differential Revision: D35614879
fbshipit-source-id: 2de83e8115d3748c0346cdec6f31b2ab1f899478
Summary:
D34687371 (https://github.com/facebook/react-native/commit/7b5b114d578142d18bf4a7a5279b179a9ac8d958) unfortunately caused a regression with UIAutomator, where it would no longer be able to see any Views that have the ReactAccessibilityDelegate attached to them. This was because the delegate was changed to extend ExploreByTouchHelper which implements its own default AccessibilityNodeProvider, which does nothing in the case of a view without any virtual children.
This diff simply *only* uses the node provider if the view in question has virtual children, otherwise defaulting to the standard behavior from the View class.
Changelog:
[Android][Fixed] - Fixed issue where any node with an AccessibilityDelegate set (which was any node with any accessibility propoerty), was using ExploreByTouchHelper's built in AccessibilityNodeProvider, and not properly populating their AccessibilityNodeInfo's, leading to focus issues and issues with automated test services like UIAutomator.
Reviewed By: kacieb
Differential Revision: D35601320
fbshipit-source-id: 92e009c6e8b4ddcab860e2c91e6bd1a8f95359f0
Summary:
Changelog:
[Android][Fixed] - Fix Extras usage in Android implementation of Linking.sendIntent()
The implementation of sendIntent() has a bug in a way it uses extras map.
From JS layer the API sends and array of map, where each map contains exactly 2 entries: {"key" -> "name_of_extra_to_use", "value" -> value_of_extra_to_use}
However Java parsing was just picking a random pair out of this map and was sending it as extra.
Most frequently the result was "value" -> value_of_extra_to_use in Intent instead of name_of_extra_to_use -> value_of_extra_to_use
This diff fixes the problem
Reviewed By: lunaleaps
Differential Revision: D35516496
fbshipit-source-id: 7da0a1cb3b8aa30463004dbb47008c83d8e95bd1
Summary:
This diff fixes a NullPointerException when disaptching events while the SurfaceMountingManager is being destroyed
changelog: [android] android
Reviewed By: cortinico
Differential Revision: D35559550
fbshipit-source-id: c07f74493384fb1b306338ec1bc8b96f1b6f1f41
Summary: Changelog: [Internal] - Fix pointer event dispatch to also fire enter/leave for ancestors in the hit path. Compared the event order with web on the RNTester W3C pointer example
Reviewed By: appden
Differential Revision: D35403076
fbshipit-source-id: 726e45e49a901b1d97ad3e20f5898701fd1f763b
Summary:
As we introduced KGP inside `ReactAndroid` (cc ShikaSD), we now need to specify a version for it (as users will consume that build on Android New Architecture.
Currently, the version is loaded in the RN `rootProject` which is not available on user's project. I'm cleaning this up.
## Changelog
[Internal] - Do not specify a Kotlin version in the RN rootProject
Pull Request resolved: https://github.com/facebook/react-native/pull/33589
Test Plan:
Tested on a nightly version with
```
npx react-native init RNNightly --version nightly
```
Reviewed By: mdvacca
Differential Revision: D35476777
Pulled By: cortinico
fbshipit-source-id: 5a819ef5fa9a6886d7b7b683f31d59cb05a49f29
Summary:
This is a follow up to my previous diff. It applies the same customization for M1 users to the :ReactAndroid:hermes-engine build.
The two diffs are split so the first one can be cherry-picked into 0.68.1 if needed.
Changelog:
[Android] [Fixed] - Improve support for Android users on M1 machine
Reviewed By: mdvacca
Differential Revision: D35468658
fbshipit-source-id: c07822f6708f872456971378f44257f6c1e967ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33588
Currently users on M1 machine can't use the New Architecture correctly as they will get build failures when building the native code.
This Diff fixes it by automatically recognizing the host architecture and switching to NDK 24 if user is runnign on `aarch64`
Changelog:
[Android] [Fixed] - Improve support for Android users on M1 machine
Reviewed By: mdvacca
Differential Revision: D35468252
fbshipit-source-id: b73f5262b9408f04f3ae4fd26458a4d17c1ec29a
Summary:
While testing with the RN Nightly versions, I realized we pushed two changes
recently that are not working fine with the gradle setup of our users.
That's becuase we're referencing the `rootProject` directly.
`rootProject` should never be used directly as it resolves to:
- The root of the git repo of `react-native` when building the RN project (so
`./ReactCommon` exists there).
- The /android folder of users' project when building an app that uses RN (so
`./ReactCommon` does not exists there).
Changelog:
[Android] [Fixed] - Do not use `rootProject` directly in Gradle scripts
Reviewed By: sshic
Differential Revision: D35444967
fbshipit-source-id: be0508480a08224302168804b6feb52fd604d8db
Summary:
Now that the PFH node has been renamed this updates the pfh label.
Produced via `xbgs -l -e '"pfh:ReactNative_CommonInfrastructurePlaceholde"' | xargs sed -i 's/"pfh:ReactNative_CommonInfrastructurePlaceholde"/"pfh:ReactNative_CommonInfrastructurePlaceholder"/'`
Reviewed By: jkeljo
Differential Revision: D35374087
fbshipit-source-id: 61590f69de5a69ec3b8a0478f6dd43409de3c70b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33539
As we now provide `hermes-executor-debug` OR `hermes-executor-release` based on which version of RN we're building, we need to provide a variant aware AAR.
Changelog:
[Internal] [Changed] - Setup multi-variant publishing for React Native Android
Reviewed By: ShikaSD
Differential Revision: D35289444
fbshipit-source-id: ffccd2089dc2eb50ea8c08ed10d8fd9816f9efb7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33560
X-link: https://github.com/facebook/hermes/pull/720
Turn on ICF for the build whenever it is available. This requires us to
link with LLD, which is only the default starting in NDK r23, so
manually specify LLD for the Android build.
Also turn on LTO for the CircleCI build, so we generate highly
optimised binaries for distribution.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D35344254
fbshipit-source-id: 64b37e6a7817a7b7826cc7480468367b95d63c61
Summary:
We currently enable the debugger by default on all platforms except
Android. On Android, we then manually enable the debugger in debug
builds. Instead, change it so the debugger is manually disabled in
release builds, to simplify the setup.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D35347444
fbshipit-source-id: a97bba0c65c61c211cf9e361e7091343a2c6416f
Summary:
Changelog: [Internal]
Working towards removing configure.py, switch to invoking CMake directly.
Note that with this change, ninja is no longer a requirement, since it will use the default build system on the host.
Reviewed By: cortinico, jpporto
Differential Revision: D35342731
fbshipit-source-id: f04a367bda9fb22642f17e7c2c5cf493e44013d3
Summary:
ModuleDataCleaner.cleanDataFromModules(**ReactContext**) is just like ModuleDataCleaner.cleanDataFromModules(**CatalystInstance**). However, one key difference is that this new method is bridgeless mode compatible. CatalystInstance doesn't exist in bridgeless mode.
Changelog: [Android][Added] Introduce ModuleDataCleaner.cleanDataFromModules(ReactContext)
Reviewed By: sshic
Differential Revision: D35286939
fbshipit-source-id: 1c09a3b34add88f848eab43b42b39ab624f0818b
Summary:
## Rationale
The CatalystInstance exposes a public API that returns a list of all instantiated NativeModules: [CatalystInstance.getNativeModules()](https://www.internalfb.com/code/fbsource/[d9cd2e5dd41fc3e3022bfb777c8b31c92af8c537]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/bridge/CatalystInstance.java?lines=73).
This enables a use-case: process all NativeModules that conform to a particular interface, to, for example, remove sensitive data before logging out.
## Changes
This diff moves that CatalystInstance.getNativeModules() API into the ReactContext. This allows us to migrate NativeModules leveraging this use-case off of ReactContext.getCatalystInstance(), which makes them bridgeless-mode compatible.
Changelog: [Android][Added] Introduce ReactContext.getNativeModules()
Reviewed By: sshic
Differential Revision: D35286940
fbshipit-source-id: 1b64351aa3f65ee59e6438a7a95974e219ccc69c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33535
Hack to support Kotlin functions in Buck compilation: adds Kotlin stdlib as a dependency to make sure upstream targets include Kotlin jvm internal classes.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35284430
fbshipit-source-id: 0d29ad30386514c8df5376d0a6809d3105f0cd0f
Summary:
Aligns naming with `JWritableMapBuffer` and other fbjni classes to indicate that it is a JNI binding.
Changelog: [Internal] - Rename C++ part of ReadableMapBuffer to JReadableMapBuffer
Reviewed By: mdvacca
Differential Revision: D35219323
fbshipit-source-id: a7eb644a700a35dc94fa18e4fb3cc68f2cfa3e99
Summary:
Updates `ReadableMapBuffer` to conform to `MapBuffer` interface, to allow interchangeable use of `Readable/WritableMapBuffer` in the code.
Notable changes:
- MapBuffer.Entry getters are now represented as Kotlin properties and appended `Value` suffix (e.g. `entry.getInt()` becomes `entry.getIntValue()` in Java, or `entry.intValue` in Kotlin)
- `ByteBuffer` is imported in constructor instead of on demand. This method doesn't copy the data as the bytes are read directly from native heap, and benchmarking a 500-byte `MapBuffer` shows no difference in import speed.
- Internal logic of `ReadableMapBuffer` uses `UShort` kotlin type for key retrieval, for more correct representation of values.
- Explicit exception throws are replaced with `require` and `check` methods for `IllegalArgumentException` and `IllegalStateException` (default FB conversion).
The change also updates `ReadableMapBuffer` usages to `MapBuffer` interface where possible (virtually everywhere except JNI methods).
Changelog: [Android][Changed] - Adopt `MapBuffer` interface for `ReadableMapBuffer`
Reviewed By: mdvacca
Differential Revision: D35218633
fbshipit-source-id: 515dd974c27b2978ade325b2e1750ab8f068a20a
Summary:
Creates a `WritableMapBuffer` abstraction to pass data from JVM to C++, similarly to `ReadableMapBuffer`. This part also defines a Kotlin interface for both `Readable/WritableMapBuffer` to allow to use them interchangeably on Java side.
`WritableMapBuffer` is using Android's `SparseArray` which has almost identical structure to `MapBuffer`, with `log(N)` random access and instant sequential access.
To avoid paying the cost of JNI transfer, the data is only transferred when requested by native `JWritableMapBuffer::getMapBuffer`. `WritableMapBuffer` also owns it data, meaning it cannot be "consumed" as `WritableNativeMap`, with C++ usually receiving copy of the data on conversion. This allows to use `WritableMapBuffer` as JVM-only implementation of `MapBuffer` interface as well, e.g. for testing (although Robolectric will still be required due to `SparseArray` used as storage)
Changelog: [Android][Added] - MapBuffer implementation for JVM -> C++ communication
Reviewed By: mdvacca
Differential Revision: D35014011
fbshipit-source-id: 8430212bf6152b966cde8e6f483b4f2dab369e4e
Summary:
While it would be better to be able to do all of the ownership metadata at the Buck macro level, that proved to be more work than expected.
This diff adds the corresponding pfh label to all targets in `xplat/js/react-native-github` that have a Supermodule label. Once the migration is complete the Supermodules labels will be able to be removed.
Reviewed By: cortinico
Differential Revision: D35221544
fbshipit-source-id: d87d5e266dfb5e6ee087251dc34dff5db299bbaf
Summary:
I've noticed that some builds are sporadically failing as `configureCMake*` is runnign before
`preBuild`. When this happens, some 3rd party library folder won't exist yet and the build will
essentially fail. This is introducing flakyiness that this commit is essentially reducing
Changelog:
[Internal] [Changed] - Reintroduce missing dependency between configureCMakeDebug and preBuild
Reviewed By: ShikaSD
Differential Revision: D35213932
fbshipit-source-id: bfb4173843349ca4c1699d584bf0c915ab7b35cf