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:
Noticed in D36098912 (https://github.com/facebook/react-native/commit/5de0f145eca36d3263cb8a9928add278cdfffa2b) 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:
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:
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:
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:
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:
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:
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
