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
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34161
This is a follow up to D37648363 (https://github.com/facebook/react-native/commit/64fe67695be3c038414c5ed3e02d487c449702b6) 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
Nicola Corti
Oleksandr Melnykov
Lulu Wu
Pieter De Baets
Nick Gerleman
Alex Hunt
Muhammad Hur Ali
Joshua Gross
Samuel Susla
Luna Wei
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
Ron Edelstein
Kevin Gozali
