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 (https://github.com/facebook/react-native/commit/e24ce708abffee8ec4521ba8162ea8964eb4429f), 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 (https://github.com/facebook/react-native/commit/64528e5faa445907b8287b412c344f30c20fca61) 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 (https://github.com/facebook/react-native/commit/64528e5faa445907b8287b412c344f30c20fca61)**
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: [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
Nicola Corti
Thuong Tran
Joshua Gross
fabriziobertoglio1987
Luna Wei
Oleksandr Melnykov
Lulu Wu
Pieter De Baets
Nick Gerleman
Alex Hunt
Muhammad Hur Ali
Samuel Susla
Sparsha Saha
Pieter Vanderwerff
Daniel Leong
David Vacca
Oskar Kwaśniewski
Graham Mendick
Janic Duplessis
Chatura Atapattu
Tony Du
Sim Sun
Dark Knight
Xin Chen
Mike Hardy
