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
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 (7b5b114d57) 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:
Fixes https://github.com/facebook/react-native/issues/33043 and thereby https://github.com/invertase/react-native-firebase/issues/3955.
The issue arised because when there currently is no available React context, `HeadlessJsTaskService` will create a new one in background and start the task using `onReactContextInitialized` of `ReactInstanceManager.addReactInstanceEventListener`.
7ef14af81f/ReactAndroid/src/main/java/com/facebook/react/HeadlessJsTaskService.java (L94-L113)
The `TimingModule` however is initialized asynchronously, meaning the headless JS is started before its initialization. That's an issue because the `TimingModule` is only run when there is JS code executing (meaning if the application is running or there is a headless task running) - this is checked by registering a `HeadlessJsTaskEventListener` on the `HeadlessJsTaskContext` in `TimingModule.initialize()`.
7ef14af81f/ReactAndroid/src/main/java/com/facebook/react/modules/core/TimingModule.java (L69-L75)
However this event listener is never invoked because the task was started before `TimingModule.initialize()` is called -> `TimingModule.onHeadlessJsTaskStart(...)` is not called and the timer never resumes.
In order to fix this we can just invoke `HeadlessJsTaskEventListener.onHeadlessJsTaskStart(...)` for all currently running tasks when a new listener is added to `HeadlessJsTaskContext`. This call then needs to be `synchronized` as otherwise there's a race condition with `HeadlessJsTaskContext.finishTask(...)` where `onHeadlessJsTaskFinish(...)` could be called before `onHeadlessJsTaskStart(...)`. See the diff for the exact changes.
## 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] [Fix] - Fixed `TimingModule` related functions for headless JS tasks, eg. `setTimeout`
Pull Request resolved: https://github.com/facebook/react-native/pull/33044
Test Plan: I did a local build with the changes and tested the provided example code from https://github.com/facebook/react-native/issues/33043 there.
Reviewed By: sshic
Differential Revision: D34006573
Pulled By: dmitryrykun
fbshipit-source-id: d6a821bbd6476ba278c1d8895edb4a0ba16d889e
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:
The reason why I'm working on this is to reduce the delta between this and the react-native-macos fork, in particular with the android patch folder "Build": https://github.com/microsoft/react-native-macos/tree/main/android-patches/patches/Build (it's a long story)
While checking the changes in there, I noticed that one of them was a bump of boost. Looking back into main (here), I then noticed that there have been two bumps to boot in the repo so far:
* a combo update 5 years ago to 1.63:
* 193afff926
* 5c24a9110a
* and an update for the iOS side to 1.76 by Kudo last year: https://github.com/facebook/react-native/pull/31840
So this quickly turned into this: the PR wants to re-align the version of boost used in both iOS and Android.
I explored the option of bumping both to 1.78 (latest at the time of writing: https://www.boost.org/users/history/version_1_78_0.html) but then I noticed that there's a Flipper dependency, `Flipper-Boost-iOSX`, on the iOS pods side that has been released only once and it seems to imply that it's 1.76 only compatible https://github.com/priteshrnandgaonkar/Flipper-Boost-iOSX/releases/tag/1.76.0.1.11.
So going to 1.78 at least for now seems like a no-go, and I've settled for just aligning everything to 1.76 and just like iOS, move away from `boost-for-react-native` in favour of the original one.
While doing so, I also noticed that the `React/third-party.xcconfig` still had a reference to 1.68 instead of 1.76 which seems like a leftover from Kudo's PR... it's probably because it was not doing anything in the first place, so lmk if you want me to delete it.
## 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] [Changed] - Bump boost for Android to 1.76 to align with iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/33565
Test Plan:
CI is green (aside an unrelated ios rntester job that is also broken on main) ✅
Locally both RNTester and new app work:
<img width="432" alt="Screenshot 2022-04-05 at 16 42 31" src="https://user-images.githubusercontent.com/16104054/161815444-0de63919-b90d-4a48-963a-872f0cc4ce79.png">
<img width="346" alt="Screenshot 2022-04-05 at 18 06 01" src="https://user-images.githubusercontent.com/16104054/161815438-b7b1c997-9dcd-47bd-acbe-732155941bb0.png">
Reviewed By: sshic
Differential Revision: D35433032
Pulled By: cortinico
fbshipit-source-id: 0d93f61f8c26eda1dd04127a8b20e799ab6828cb
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
Luna Wei
Nicola Corti
Oleksandr Melnykov
Lulu Wu
Pieter De Baets
Nick Gerleman
Alex Hunt
Muhammad Hur Ali
Joshua Gross
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
Ron Edelstein
Kevin Gozali
Mark Verlingieri
Kunal Farmah
Genki Kondo
Simek
Luis Santana
fabriziobertoglio1987
Artem Goncharov
Olivier Payen
Charles Dudley
Daniel Espino García
Andy Zolyak
Daniel Abramowitz
Rubén Norte
Rachit Mishra
Tianyu Li
Derek Thurn
Harry Yu
Hetan Thakkar
Christoph Purrer
Mike Masam
Anandraj Govindan
Kudo Chien
Aniket Mathur
Steven Vascellaro
Carmi Grushko
Alex Liang
Moti Zilberman
Brett Lavalla
Vladyslav Stepanov
Marces Engel
Lorenzo Sciandra
Chris Olszewski
Neil Dhar
Ramanpreet Nara
Andrei Shikov
