Summary:
Refactor EventEmitters to take an optional SurfaceId that Fabric will use, and non-Fabric will not.
Migrating touches is a good proof-of-concept for how this could be used generally, and as it turns out, TouchEvent's API is more flexible than most other event APIs (because it uses a dictionary to pass data around, so we can just stuff SurfaceId into it - not efficient, but flexible).
All new APIs are backwards-compatible and designed to work with old-style events, with Fabric and non-Fabric. Native Views that migrate to the new API will be backwards-compatible and get an efficiency boost in Fabric.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26025135
fbshipit-source-id: 5b418951e9d0a3882f2d67398f2aaadac8a3a556
Summary:
Create V2 EventEmitter that surfaceId can be passed into, with a backwards-compat layer, and some debug-only logging to help assist with migration.
Changelog: [Changed][Android] RCTEventEmitter has been deprecated in favor of RCTModernEventEmitter for optimal Fabric support; RCTEventEmitter will continue to work in Fabric, but there are minor perf implications.
Reviewed By: mdvacca
Differential Revision: D26027104
fbshipit-source-id: 784ca092bbc88d19c82f6c42537c34460d96de86
Summary:
There's a field called `surfaceID` in a couple of classes that isn't the same as the integer `surfaceId` in Fabric.
For consistency, I've deprecated a couple of them, or renamed when appropriate.
In addition, now we're passing the actual integer surfaceId into the ThemedReactContext. This means that every single View created in Fabric gets annotated with the surfaceId it's in. Currently this isn't used, but the idea is that now each View has a mapping back to its surface, which could be used to simplify / optimize operations with SurfaceMountingManager. In particular, we might be able to use this in the future to optimize animations and/or event emitters.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26021571
fbshipit-source-id: b7db7de123db07fa928a6f815be86bdbb030e62c
Summary:
This refactors MountingManager into a minimal API that shims into a more fully-featured SurfaceMountingManager. The SurfaceMountingManager keeps track of surface start/stop, surface ID, and surface Context.
This solves a number of issues around (1) race conditions around StopSurface/StartSurface, (2) memory management of Views, (3)
Concrete improvements:
1. Simpler to reason about race conditions around StopSurface/StartSurface.
2. 1:1 relationship between SurfaceId and all Views/tags.
3. When surface is stopped, all descendent Views can be GC'd immediately.
4. Fixed separation of concerns and leaky abstractions: surfaceId/rootTag and Surface Context are now stored and manipulated *only* in SurfaceMountingManager.
5. Simpler StopSurface flow: we simply remove references to all Views, and the Fragment (outside of the scope of this code) removes the RootView. This will trigger GC and we do ~0 work. Previously, we ran a REMOVE and DELETE instruction and kept track of each View in a HashMap. Now we can simply delete the map and move on.
The caveat: NativeAnimated (or other native modules that go through UIManager). APIs like `updateProps` currently uses only the ReactTag and does not store SurfaceId. This is a good argument for moving away from ReactTag, at least in its current incarnation, but: for now this requires that you do a lookup of a ReactTag across N surfaces (worst-case) to determine which Surface a ReactTag is in.
So, to summarize, the "con" of this approach is that now `getSurfaceManagerForViewEnforced` could be slower. It is used in:
* NativeAnimatedModule calls `updateProps` through UIManager
* FabricEventEmitter calls `receiveEvent` on FabricUIManager directly
* On audit, I could find zero native callsites to `sendAccessibilityEvent` through UIManager
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26000781
fbshipit-source-id: 386ae40c4333f8c584e05818c404868dbee6ce73
Summary:
MountingManager keeps a map of tags to Views, and attempts to clean it up by (1) deleting tags when they're explicitly deleted, (2) recursively deleting all Views when the View hierarchy is torn down.
However, there appear to be.... substantial gaps here. In tests, when navigating between screen X -> screen Y -> back to X (triggering a StopSurface), each "StopSurface" resulted in 200-600 Views being leaked (!).
What is causing these leaks? Well, for one, the "dropView" mechanism isn't perfect, so it might be missed Views. Second, Views don't always guarantee that `reactTag == getId()`, so that could result in leaks. Third, View preallocation on Android complicates things: Views can be preallocated and then never even inserted into the View hierarchy, so DELETE mutations could never be issued. Fourth, StopSurface is also complicated on Android (largely because of View preallocatioAndroid (largely because of View preallocation).
So, I introduce a new mechanism: keep a list of all tags for a surface, and remove all tags for a surface when the surface is torn down. This should be fool-proof: it handles preallocation and normal creation; it can handle deletes; and we're guaranteed that tags cannot be added after a surface is stopped.
Is this overly complicating things? Well, hopefully we can simplify all of this in the longterm. But until we get rid of View Preallocation, it seems like we need this mechanism - and View Preallocation might be around for a while, or forever.
Other thoughts: it's possible that using other data-structures could be more efficient, but I'm guessing the perf implications here are marginal (compared to the insane amount of memory leaks we're fixing). It could also simplify things to have a SurfaceMountingManager interface that implies all actions happen on a specific surface, including teardown.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25985409
fbshipit-source-id: f55b533770b1630c6c2a9b7a694d953aa3324428
Summary:
Original commit changeset: 3ed8e78e31b0
Backing-out D25938851 (69b3016171) and D25935785 (bdea479a1f). Based on analysis documented in T83141606, I believe this issue should be fixed in JS.
Additionally, this crash actually has nothing to do with (un)flattening or the differ; it is a side-effect of stale ShadowNodes being cloned, which I believe is either UB or a contract violation. Either way, it should probably be fixed either in JS, or in node cloning. So this isn't the right solution for this issue and should be reverted.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25949569
fbshipit-source-id: 8cf1094a767da98fff4430da60d223412e029545
Summary:
This diff changes the type of the SwipeRefreshLayoutManager.size prop from Int to String in Fabric.
The current implementation of this prop allows JS developers to use "int" type when fabric is enables and "int or string" types when using Fabric is disabled.
Since long term we want to only support "string" type for this prop, I'm changing the type of the prop to be String.
After my diff Fabric will start supporting only "string" types, non fabric screens will keep supporting "int or string" values.
**Will this break production?**
No, because there are no usages of RefreshControl.Size prop in fbsource
**What about if someone start using this prop next week?**
IMO It's very unlikely because of the nature of this prop, I will be monitoring next week and if there's an usage it will be detected by flow when trying to land D25933457.
Changelog: [Android][Changed] - RefreshControl.size prop changed its type to string, the valid values are: 'default' and 'large'
Reviewed By: JoshuaGross
Differential Revision: D25933458
fbshipit-source-id: 55067d7405b063f1e8d9bb7a5fd7731f5f168960
Summary:
Android has some optimizations around view allocation and pre-allocation that, in the case of View Unflattening, can cause "Create" mutations to be skipped.
To make sure that doesn't happen, we add a flag to ShadowViewMutation (in the core) that any platform can consume, that indicates if the mutation is a "recreation" mutation.
It is still a bit unclear why this is needed, in the sense that I would expect props revision to increment if a view is unflattened. However, there is at least one documented reproduction where that is *not* the case. So for now, we'll have a hack pending further investigation.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25935785
fbshipit-source-id: 6fb4f0a6dedba0fe46ba3cd558ac1daa70f671f5
Summary:
MountItem logging was broken in D25841763 (4076293aa1), by adding a field that wasn't logged.
Fixed here.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25934390
fbshipit-source-id: 2db4a809b150ad33ddf886db1db6585889bd7013
Summary:
This diff refactors the intialization of Fabric in order to avoid loading UIManagerModule as part of the creation of FabricJSIModuleProvider.
One caveat is that now we are not taking into consideration the flag mLazyViewManagersEnabled
master/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/CoreModulesPackage.java177
if (mLazyViewManagersEnabled) {
As a side effect of this diff view managers will be initialized twice if the user has fabric and paper enabled
This diff was originally backed out in D25739854 (4984c1e525) because it produced a couple of bugs:
https://fb.workplace.com/groups/rn.support/permalink/4917641074951135/https://fb.workplace.com/groups/rn.support/permalink/4918163014898941/
These bugs are fixed by D25667987 (2e63147109).
This diff was reverted a couple of times because of the change in the registration of eventDispatcher. That's why I'm gating that behavior change as part of the "StaticViewConfig" QE.
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D25858934
fbshipit-source-id: a632799ccac728d4efca44ee685519713b4a7cbb
Summary:
These methods can all throw exceptions that get caught and reported by JS. The logviews aren't currently very helpful; hopefully adding additional information will make batch debugging a little easier.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D25870788
fbshipit-source-id: a1cab225b11a3d2868f098d4575e475ee4064e65
Summary:
This diff migrates all the lookups of EventDispatcher to not depend on UIManagerModule anymore.
This refactor is necessary because:
- Users running in Fabric / Venice should not load on the UIManagerModule class
- D25858934 will introduce a change that will break all of these callsites
In the migration I'm relying on the method UIManagerHelper.getEventDispatcherFromReactTag() that returns the correct EventDispatcher for a reactTag.
I'm planning to land this change early in the week (to catch potential errors in alpha / beta versions)
As a followup we need to deprecate and prevent developers to continue using getNativeModule(UIManagerModule.class) moving forward. That will be part of another diff
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D25858933
fbshipit-source-id: e26c99759307517b5bef483274fe0e0d71bb4c6c
Summary:
Hermes has a way to set up a callback that is invoked when a fatal error
such as Out of Memory occurs. It is a static API that should be called at
most once, so it uses `std::call_once` to achieve that.
The fatal error handler is simple, it just uses glog to log an error message
to logcat, then aborts (using `__android_log_assert`).
The reason is typically very helpful for understanding why `hermes_fatal` was called.
Changelog:
[Android][Internal] - Print a logcat message when Hermes has a fatal error
Reviewed By: mhorowitz
Differential Revision: D25792805
fbshipit-source-id: 45de70d71e9bd8eaa880526d8835b4e32aab8fe3
Summary:
This diff logs a SoftError when there is not EventDispatcher associated to UIManager
The app will crash in Debug mode, this will not affect production users
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D25859546
fbshipit-source-id: 8045bcd67f613ea6286f30fe6f3c66113c700b0b
Summary:
The purpose of this diff is to ensure that visibility changes are handled correctly when the value of "display" for a View changes from 'flex' to 'none'.
RNTester is nesting several Views with different kind of visibilities. When the user tap on an item there's a state update that changes the visibility styles for some of these views. Fabric does not reflect the right changes of visibility on the screen.
changelog: internal
Reviewed By: shergin
Differential Revision: D25841763
fbshipit-source-id: 769b97afb72939d346a4c6f2669ff938b35596bc
Summary:
This is the Android native implementation of sendAccessibilityEvent for Fabric.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25852418
fbshipit-source-id: cb51e667a7f673da6b9c9e539770225b02bdc902
Summary:
Okhttp 3.12.X allows Connections using TLS 1.0 and TLS1.1.
TLS 1.0 and TLS 1.1 are no longer secure.
Google, Mozilla, Microsoft, and Apple announced that their browsers will require TLSv1.2 or better starting in early 2020.
https://square.github.io/okhttp/changelog_3x/#version-310https://github.com/facebook/react-native/wiki/Changelog
Starting from 3.13.0 TLSv1 and TLSv1.1 are no longer enabled by default.
3.13.0 requires JAVA 8 and Android SDK 21 (which was blocking the Upgrade in the Past).
## Changelog
[Android] [Changed] - Update Okhttp to version 3.14.19
Pull Request resolved: https://github.com/facebook/react-native/pull/30609
Test Plan:
Current tests should pass.
Connections using TLS 1.0 and TLS 1.1 should not be possible.
Reviewed By: mdvacca
Differential Revision: D25843511
Pulled By: fkgozali
fbshipit-source-id: f0b648c8037f945130c6f9983404ee7f75b178cb
Summary:
This diff refactors the intialization of Fabric in order to avoid loading UIManagerModule as part of the creation of FabricJSIModuleProvider.
One caveat is that now we are not taking into consideration the flag mLazyViewManagersEnabled
```
master/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/CoreModulesPackage.java177
if (mLazyViewManagersEnabled) {
```
As a side effect of this diff view managers will be initialized twice if the user has fabric and paper enabled
This diff was originally backed out in D25739854 (4984c1e525) because it produced a couple of bugs:
- https://fb.workplace.com/groups/rn.support/permalink/4917641074951135/
- https://fb.workplace.com/groups/rn.support/permalink/4918163014898941/
These bugs are fixed by D25667987 (2e63147109).
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D25746024
fbshipit-source-id: 3d12d29973a12b1edfea75f4dd954790f835e9bd
Summary:
This diff refactors the createViewInstance method in order to ensure that viewID is set before props are updated in the view.
This is necessary because there are components that deliver events at the same time their props are set. This means that some components might not have their viewId set correctly when events are delivered.
Since viewId is used to determine if a view belongs to Fabric or Paper, there are cases when the events are not delivered to the right renderer
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D25667987
fbshipit-source-id: 4acfa8f80d66e9e59514354481957d7d3b571248
Summary:
This experiment has been successfully running for several weeks and show small but statsig perf improvements. Delete the old code and ship this 100% in code to simplify Fabric code.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25775668
fbshipit-source-id: d2b41dfe691775e52b1e89c2fb6790a6500e560e
Summary:
When I try to run RNTester with Gradle the RNTester Required me to use **NDK 20.0.5594570**. I can't seem to find an explicit NDK version anywhere in ReactAndroid and RNTester. This PR Aims to add an explicit NDK version to RNTester and ReactAndroid.
## Changelog
[Android] [Added] - Add an explicit NDK version to RNTester and ReactAndroid.
Pull Request resolved: https://github.com/facebook/react-native/pull/29987
Test Plan: Build manually from RNTester
Reviewed By: fkgozali
Differential Revision: D23911371
Pulled By: ShikaSD
fbshipit-source-id: 2f297c73890c0eb0bfec0e2ba7ec5755b4d84243
Summary:
This is just a micro-optimization in ReadableNativeMaps. It wont change much in perf..
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D25733948
fbshipit-source-id: b01109acdf5b2eb532801469ef5cb845010c6ed0
Summary:
This diff D25468183 (c776f09e5f) is causing TetraFormTextInput's onChange not to fire.
See https://fb.workplace.com/groups/rn.support/permalink/4918163014898941/
I confirmed this was the bad diff via mobile bisect.
changelog: [internal] internal
Reviewed By: rickhanlonii, mdvacca, nadiia
Differential Revision: D25739854
fbshipit-source-id: efdfb1e464dd5d990d5c9ea291dde9895736817a
Summary:
Right now we assume in the Image component that any prop changes requires a redraw of the image, even if the props set are identical.
Noop prop updates can be caused in Fabric by LayoutAnimations. This may go away in the future, but only when we have a new animations system.
I don't think most other components need to be concerned with this, and many other components already guard against unnecessary redraws. Since the image "flashes"
when it is loaded, unlike most other native components, this issue is more noticeable for images.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25727482
fbshipit-source-id: 75ffa456bddc1208900733140ce4ff19f7e2c11e
Summary:
## Description
Suppose this was the codegen declaration before:
```
rn_library(
name = "FooModule",
native_module_spec_name = "FBReactNativeSpec",
codegen_modules = True,
# ...
)
```
Previously, this would generate the following BUCK targets:
- generated_objcpp_modules-FooModuleApple
- generated_java_modules-FooModuleAndroid
- generated_java_modules-FooModule-jniAndroid
## Changes
We will now generate:
- FBReactNativeSpecApple
- FBReactNativeSpecAndroid
- FBReactNativeSpec-jniAndroid
This matches the naming scheme of the old codegen.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D25680224
fbshipit-source-id: 617ac18fd915f3277f6bd98072d147f20fb193e5
Summary:
This replaces the internal core implementation of `setState` with the new `updateStateWithAutorepeat` which is now the only option.
In short, `updateStateWithAutorepeat` works as `setState` with the following features:
* The state update might be performed several times until it succeeds.
* The callback is being called on every retry with actual previous data provided (can be different on every call).
* In case of a static value is provided (simple case, not lambda, the only case on Android for now), the same *new*/provided value will be used for all state updates. In this case, the state update cannot fail.
* If a callback is provided, the update operation can be canceled via returning `nullptr` from the callback.
This diff removes all mentions of the previous state update approach from the core; some other leftovers will be removed separatly.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25695600
fbshipit-source-id: 14b3d4bad7ee69e024a9b0b9fc018f7d58bf060c
Summary:
This commit makes both `:ReactAndroid` and `:rn-tester:android:app` always compile in Fabric codegen outputs. However, one may still enable/disable Fabric at runtime by setting `USE_FABRIC` env var (set to 1 or 0, default is 0).
Note that we can't register custom components specific to the app, yet, so only the components in react-native github repo is covered by this commit.
RNTester doesn't enable Fabric by default yet due to known UI bugs that haven't been addressed yet.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25674311
fbshipit-source-id: 8db660c959319250ebc683c84076677cf6489e94
Summary:
Generate Fabric C++ files along side TM spec files for RNTester. The combined .so then has both TM and Fabric files.
This commit also removed the checked-in JNI files.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25674313
fbshipit-source-id: 8091d5a00f42849a74cab50e8d24f4010d500e5b
Summary:
The TM specs and Fabric files should be combined into the same .so. For short term parity with Fabric components and iOS, let's rename ReactAndroidSpec (default name based on project path) to "rncore".
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25674312
fbshipit-source-id: 3d71aa0cc945affecb06dcfc15e807dd48c76468
Summary:
For core components, we can start using the codegen output during build time instead of the checked in files in: https://github.com/facebook/react-native/tree/master/ReactAndroid/src/main/java/com/facebook/react/viewmanagers
Note: Some files seemed to be handwritten, so this only removed those that use codegen.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D25453157
fbshipit-source-id: f7eabddfd3fd668bef0c4aef3fddcb38c8b046a0
Summary:
This diff fixes a racecondition in registration of event listeners.
mPostEventDispatchListeners is accessed from different threads, most of the times this variable is used to executed the listeners. It is only written during initialization and turn down of the renderer.
changelog: [internal]
Reviewed By: PeteTheHeat
Differential Revision: D25667988
fbshipit-source-id: 1bf95f5193d55a737bad9403206cc3320185b8cb
Summary:
## Context
The legacy NativeModule infra implements promise methods using [async NativeModule method calls](https://fburl.com/diffusion/tpkff6vg). In the TurboModule infra, promise methods [treat as sync methods](https://fburl.com/diffusion/yde7xw71), and executed directly on the JavaScript thread. This experiment makes TurboModule promise methods async, and dispatches them to the NativeModules thread, when they're executed from JavaScript.
Reviewed By: fkgozali
Differential Revision: D25623192
fbshipit-source-id: 2b50d771c5272af3b6edf150054bb3e80cab0040
Summary:
## Context
Every time we require a NativeModule in Java, we [first try to create it with the TurboModuleManager](https://fburl.com/diffusion/3nkjwea2). In the TurboModule infra, when a NativeModule is requested, [we first create it](https://fburl.com/diffusion/d2c6iout), then [if it's not a TurboModule, we discard the newly created object](https://fburl.com/diffusion/44gjlo6y). This is extremely wasteful, especially when a NativeModule is requested frequently and periodically, like UIManagerModule.
Therefore, in D24811838 (803a26cb00) fkgozali launched a fix to the infra that would avoid creating the non-TurboModule object in the first place. Today, we're launching this optimization.
Reviewed By: fkgozali
Differential Revision: D25621570
fbshipit-source-id: dedba4d5ac6fcf2ec3c31e7163a6a226065c708b
Summary:
This diff fixes a race condition in the execution of FabricUIManager.StartSurface method.
The rootcause is that startSurface is executing getViewportOffset from a background thread.
changelog: [internal]
Reviewed By: shergin
Differential Revision: D25617154
fbshipit-source-id: 9351201088164e74bb0b9454e30651e1de0da912
Summary:
Remove proguard keep rules on okhttp3. The library already contains its own consumer proguard --> see https://square.github.io/okhttp/r8_proguard/
The keep rules will increase the final apk size of android app. Currently, there is no way to disable proguard rules from transitive dependencies ( https://issuetracker.google.com/issues/37073777). So any android app that use react native will also contains this proguard rules.
## Changelog
[Android] [Removed] - Remove okhttp3 proguard rules
Pull Request resolved: https://github.com/facebook/react-native/pull/30514
Test Plan: n/a
Reviewed By: mdvacca
Differential Revision: D25616704
Pulled By: fkgozali
fbshipit-source-id: eb0bcbc4ace398a55ce6902e34c17b030bb87130
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/30595
Changelog: [Internal]
Add support for loading HBC bundles from Metro in Twilight.
* adds `runtimeBytecodeVersion` to the bundleURL
* adds logic to check chunk hermes bytecode bundles
* adds support for running the bytecode bundles
Reviewed By: cpojer
Differential Revision: D24966992
fbshipit-source-id: acdd03a2e9e2b3e4c29c99c35a7c9136a3a7ef01
Summary:
Ship LayoutAnimations to 100% of users by removing feature-flag gating.
The `collapseDeleteCreateMountingInstructions_` stuff is always disabled for LayoutAnimations, so we can get rid of that too.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25510740
fbshipit-source-id: 71bac44f829530458e4906ecd1e7e68e766de2ec
Summary:
In preparation for flipping the default, marking autoglob as False in places where it isn't explicitly specified.
Changelog: [Internal]
Reviewed By: strulovich
Differential Revision: D25497305
fbshipit-source-id: 142e5caca2d67efcb3c25067a36934f7f6dd4b21
Summary:
Now, Metro should work with Venice. This piggybacks on Lulu's fix here: D22477500 (9b8ffeee4c).
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D25323041
fbshipit-source-id: 859958185c5be52a4bfdc12a82ecd7719042ae5f
Summary:
Some of the existing files under uimanager/ are self contained and used by the component codegen output. This commit split out those files into a dedicated uimanager/interfaces/ dir/target so that more targets can depend on it without causing dep cycle.
Also, the component codegen output doesn't need LayoutShadowNode at all, so this removed the import.
This will allow us to combine the Java codegen output for TM spec and Fabric components, simplifying build and dependency management (not in this commit yet).
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D25451409
fbshipit-source-id: 827545a3d78ebed1815cf9e52da2fa896b012aa1
Summary:
The flag `clipChildRectsIfOverflowIsHidden` has been set to false for a little over a year. Delete it and associated callsites.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25451696
fbshipit-source-id: a6067b2e25124f6bdef336c2ddead719dd44cca9
Summary:
In practice this has been enabled in production for months and is fine. Remove feature-flag and gating.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25451697
fbshipit-source-id: 9e70db3ed4e00de7b8295d9225d43ba09e4e68e9
Summary:
This has been true for 100% of users for months; clean up the old code.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25451470
fbshipit-source-id: feae59ce746869b9d84d6aaa69be10e91181f03a
Summary:
This code was useful for debugging T78035906 but is no longer needed.
I'm a bit conflicted about removing it, since such issues could crop up again in the future - but they're very rare, and hopefully now we know how to avoid them.
tl;dr: Make sure that mount instructions are not executed *during* a draw or measure.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25450846
fbshipit-source-id: e261f13db252d22773e373a5de744ecc8c380a43
Summary:
This code and this class isn't needed in Fabric, so don't create it during construction. Lazy-load it when it's needed outside of Fabric.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25450724
fbshipit-source-id: d14d8f03c194716f2aba0e499f3282ad2d1c1d29
Summary:
This diff prevents the pre-calculation of ViewManager's constants for users with static view config enabled.
We still load viewManager classes and create viewManger objects for perf reasons
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D25414068
fbshipit-source-id: a91f6113e35b42625c03d13bd67b63e3f9f75098
Summary:
Cleanup release.gradle and remove code used to upload RN to maven repository, which is not longer used. Also removed configuration to include Javadoc, Sources in maven repo, thus reduce NPM package size.
## Changelog
[Internal] [Changed] - cleanup and remove maven upload from release.gradle
Pull Request resolved: https://github.com/facebook/react-native/pull/30468
Test Plan: you will no longer see *uploadArchives* in ./gradlew tasks. Also you can run **./gradlew :ReactAndroid:installArchives**
Reviewed By: mdvacca
Differential Revision: D25408128
Pulled By: fkgozali
fbshipit-source-id: b3ced1b466b9f11e3970136a116af4e29dbd33a1
Summary:
Instead of doing a "containsKey then get", just get the rootViewTag and see if it's non-null. Theoretically, since it's a
concurrent data-structure, it could be removed from the ConcurrentHashMap between "containsKey" returning true and the "get".
This does not fix any known, existing problems.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25378703
fbshipit-source-id: 62a44e68e4443dac5a557263cc4bb33de9eea993
Summary:
There is an optimization in FabricUIManager.surfaceActiveForExecution that ensures it returns the same value (true or false)
for a given SurfaceId for a single frame (the value is cached until the next frame).
It seems like this can be causing a few different crashes, in a couple different ways:
1) If StopSurface is called off the UI thread, in the middle of a batch of operations (probably less likely to cause problems)
2) If StopSurface is called on the UI thread, in between different operations; the latter operations will still execute because the `true` value of `surfaceActiveForExecution` was cached.
I don't think that this optimization was providing much for us, and could be causing crashes. Remove it for now and we'll analyze impact on crashes and perf.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25379970
fbshipit-source-id: 2c15c971bd0c828e1d38a34662d93293271041b2
Summary:
The `BlobCollector` native module stored a `jni::global_ref` as a member,
and its destructor automatically destroys it.
However, as noted in JSI documentation, there is no guarantee that the destructor
is run on a JVM-registered thread. The destructor knew this and used a `jni::ThreadScope`
to do some other JNI behavior, but the global_ref needs to be destroyed during
that ThreadScope as well.
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D25372698
fbshipit-source-id: f4eba0b2da154c6eac54d7faeb9ea5bb9260bec9
Summary:
Props are transferred from C++ to Java using ReadableNativeMaps. The current implementation of ReadableNativeMaps creates an internal HashMap the first time one of its methods is executed.
During the update of props ReadableNativeMaps are consumed only once and they are accessed through an Iterator. That's why there is no reason to create the internal HashMap, which is inefficient from performance and memory point of view.
This diff creates an experiment that avoids the creation of the internal HashMap during prop updates, additionally it removes a lock that was being used in the creation of the internal HashMap. I expect this change to have a positive impact in TTRC and memory (in particular for ME devices)
This diff reduces the amount of ReadableNativeMaps's internal HashMaps created during initial render of MP Home by ~35%.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D25361169
fbshipit-source-id: 7b6efda11922d56127131494ca39b5cec75f1703
Summary:
The root cause of this bug is a race condition between the onMeasure method and setupReactContext.
ReactInstanceManager.attachRootView() method is responsible of the initialization of ReactRootViews and it is invoked by ReactRootView.onMeasure() method in the UIThread
Important initialization steps:
1. Clear the Id of the ReactRootView
2. Add the ReactRootView to the mAttachedReactRoots
3. Call StartSurface (if the bridge has been initialized)
Sometimes, when this method is invoked for the first time, the bridge is not initialized, in those cases we delay the start of the surface.
Once the bridge is initialized, StartSurface is called by the setupReactContext() running in the NativeModuleThread.
Since onMeasure can be called multiple times, it is possible that we call "StartSurface" twice for the same ReactRootView, causing the bug reported on T78832286.
This diff adds an extra check to prevent calling "StartSurface" twice. The fix is done using an AtomicInteger comparison and it is gated by the flag "enableStartSurfaceRaceConditionFix". Once we verify this works fine in production we will clean up the code, remove the flags and maybe revisit the API of ReactRoot.
changelog: [Android] Fix race-condition on the initialization of ReactRootViews
Reviewed By: JoshuaGross
Differential Revision: D25255877
fbshipit-source-id: ca8fb00f50e86891fb4c5a06240177cc1a0186d9
Summary:
These methods were being striped from proguard, which causes release builds to instacrash
Changelog: [Internal] Protect methods from Proguard
Reviewed By: RSNara
Differential Revision: D25314933
fbshipit-source-id: 173160eab953b7c24e02f5e6ef3bf335c1f85526
Summary:
This feature flag (enableStopSurfaceOnRootViewUnmount) was used to gate usage of the "stopSurface" API, which is now fully supported, and has been used
in the FB app for several months. This is safe to ship in code.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25275192
fbshipit-source-id: fa22bfd00aa023297bc19c83c138f133e9ff1645
Summary:
This was added to prevent mutating the UI during draw or measure, and appears to have been effective. Keep the comments, ship the feature, remove flags.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25258409
fbshipit-source-id: 36ad8a03d1eb82bc9dcd769372c03f1ebe8b8da8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/30416
This diff changes the constructor param for TurboModuleManager from jsContext (a long representing the `jsi::Runtime` pointer) to a RuntimeExecutor. It also updates callsites to use the new RuntimeExecutor created by CatalystInstance. This is only used for installing the TurboModule JSI binding; it's not currently used for JS invocation in TurboModules, which is handled separately by JSCallInvoker. Ultimately we may be able to implement JSCallInvoker *with* the provided RuntimeExecutor, but there's some additional logic in JSCallInvoker that we don't have here yet.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D21338930
fbshipit-source-id: 1480c328f1a1776ddf22752510c0f3b35168a489
Summary:
Updates `ReactScrollViewManager` and the `ViewConfig` for `ScrollView` so that they are equivalent.
- `inverted` was missing.
- `contentOffset` was missing differ on Android. (However, there does not seem to be any perceivable behavior difference besides the native `ViewConfig` being different.)
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D25084470
fbshipit-source-id: 8bea3b7a692c1038819a4147b174583a4faa71e9
Summary:
A bunch of deps were missing when generating Javadoc, producing warnings. One issue was:
```
project.getConfigurations().getByName("compile").asList()
```
Seems to be deprecated (?), so this list is always empty. The mitigation is to create a new configuration that just inherits from `api()` dependencies, so that we can add them in Javadoc task.
The other problem (not solved in this commit), is that some deps are .aar files, which require some manual unpacking before they can be processed: https://stackoverflow.com/questions/35853906/how-to-generate-javadoc-for-android-library-when-it-has-dependencies-which-are-a
Note that this is separate fix from https://github.com/facebook/react-native/pull/30417
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D25041164
fbshipit-source-id: 2ee8b268c2d38e3ecbf622c05c3c56123b7a15a6
Summary:
Fixes https://github.com/facebook/react-native/issues/30415
This is a quick and dirty fix to unblock publish, of excluding a class from Javadoc generation that is importing a class current build logic cannot handle. This is not a long-term fix for the issue.
## 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
-->
[Internal] [Fixed] - Fix :ReactAndroid:androidJavadoc task
Pull Request resolved: https://github.com/facebook/react-native/pull/30417
Test Plan: Tested that the task now completes locally.
Reviewed By: lunaleaps
Differential Revision: D25041282
Pulled By: fkgozali
fbshipit-source-id: f774ab30a09db473178e2a51c77860e4985dd8e3
Summary:
We don't support pre-API 21/Android <5/pre-Lollipop anymore; delete related code or checks.
No need for this to make it to the changelog, this announcement was already made.
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D24965249
fbshipit-source-id: e537e62e8eb18878c29afe17b8c7861d095a37b7
Summary:
Currently, queuing any sort of MountItem or getting the list of MountItems requires synchronization. Since these can be queued up at any point from the JS thread, there will, in theory, be constant contention between JS and UI thread.
To see if this is true, I'm creating an experiment instead of just switching over to concurrent structures. After seeing results, we can hopefully make a decision and delete the non-concurrent stuff or improve on it somehow.
The original was unlanded in D24973616 (26787e2260) due to a typo, which has been fixed now. The typo was that in Blocking Mode, we queued up all PreMountItems to the concurrent PreMountItems queue.
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D24974851
fbshipit-source-id: d081c081bbd0de445bb92408f0ec822056b905a5
Summary:
Fixes: https://github.com/facebook/react-native/issues/29455
Modal's onDismiss is not called on iOS.
This issue occurred the commit bd2b7d6c03 and was fixed the commit 27a3248a3b.
However, the master and stable-0.63 branches do not have this modified commit applied to them.
## 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
-->
[iOS] [Fixed] - Modal's onDismiss prop will now be called successfully.
Pull Request resolved: https://github.com/facebook/react-native/pull/29882
Test Plan:
Tested on iOS with this change:
1. Set function Modal's onDismiss prop.
1. Set Modal's visible props is true. (show Modal)
1. Set Modal's visible props is false. (close Modal)
1. The set function in onDismiss is called.
Reviewed By: shergin
Differential Revision: D24648412
Pulled By: hramos
fbshipit-source-id: acf28fef21420117c845d3aed97e47b5dd4e9390
Summary:
Adding more Systrace sections to get perf information during critical paths.
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D24960195
fbshipit-source-id: 099e9cfac8ac87287e48e9915e6b28fe7a448783
Summary:
Add Systrace sections to initialization of non-Fabric UIImplementationProvider. This path is sometimes invoked during startup of Fabric so I'd like to gather more information about its impact.
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D24959965
fbshipit-source-id: a8555b8db284d00f97c71ca859cb2020409cb110
Summary:
There are a very, very small number of crashes in production that are hitting this line. I would like to understand what the existing tag ID is (perhaps it's eqal to the ID being set, which would indicate "double-start"). If not, it indicates that fragments are being reused somewhere, or something else odd is going on with lifecycles.
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D24953785
fbshipit-source-id: 079c86cdb571749662cca46feeaebdd6cb1281f4
Summary:
Currently, queuing any sort of MountItem or getting the list of MountItems requires synchronization. Since these can be queued up at any point from the JS thread, there will, in theory, be constant contention between JS and UI thread.
To see if this is true, I'm creating an experiment instead of just switching over to concurrent structures. After seeing results, we can hopefully make a decision and delete the non-concurrent stuff or improve on it somehow.
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D24942110
fbshipit-source-id: fcbdeda51f91f4bd430a20d7484854fb1e94a832
Summary:
Add three markers for ReactRootView perf logging: onMeasure, attachToReactInstanceManager, and updateLayoutSpecs.
It is suspected that one or all of these have regressed under Fabric in some cases.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D24909635
fbshipit-source-id: 6b6c0cc792c4b2d72f2360d6cffc02ef00e8a88b
Summary:
This PR removes remains of Android Support Library, now replaced with AndroidX.
## Changelog
[Internal] [Changed] - remove Android Support Library from Buck
Pull Request resolved: https://github.com/facebook/react-native/pull/30347
Test Plan: CI is green
Reviewed By: JoshuaGross
Differential Revision: D24914088
Pulled By: fkgozali
fbshipit-source-id: 0ff18dfd7c684642a5c27308112b6fddc27608a7
Summary:
Currently the dimensions are created once, and then cached. This change will reload the dimensions when the device orientation changes to insure that dimension update events follow orientation changed events.
this should help address the following issues, that I know of:
https://github.com/facebook/react-native/issues/29105https://github.com/facebook/react-native/issues/29451https://github.com/facebook/react-native/issues/29323
## 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] - Dimension update events are now properly sent following orientation change
Pull Request resolved: https://github.com/facebook/react-native/pull/30324
Test Plan: Open up RNTester app. Select the Dimensions API list item. Rotate the device and verify that the dimensions are correct based on orientation.
Reviewed By: fkgozali
Differential Revision: D24874733
Pulled By: ejanzer
fbshipit-source-id: 867681ecb009d368a2ae7b67d94d6355e67dea7b
Summary:
Various TM infra classes previously were stripped by proguard. This updates the rule to not remove TM Android core infra.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24812999
fbshipit-source-id: 3b713c63e25a209b17869f7e5311ee54a113a567
Summary:
There is a flow where TM registry is creating a module instance (as registered in the TurboReactPackage), only to discard it if it's not a TM enabled module. This may be fine for many modules, but for module like `UIManagerModule`, this may cause a race condition or other issues, including potential perf regression when accessing UIManager from JS (e.g. for getting native viewConfigs).
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24811838
fbshipit-source-id: 6e1cce6993a6e5c9763773f175083bf52925c910
Summary:
This is the final diff in the JS TurboModule codegen stack for Android. It implements method dispatch using the TurboModuleSchema object.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D22837486
fbshipit-source-id: f91b03f064941457d4b8c5e37e011468559dee71
Summary:
## Android API
```
// Before we initialize TurboModuleManager
ReactFeatureFlags.useTurboModuleJSCodegen = true
```
## iOS API
```
// Before we initialize RCTBridge
RCTEnableTurboModuleJSCodegen(true);
```
## How is the JS Codegen actually enabled?
The above native flags are translated to the following global variable in JavaScript:
```
global.RN$JSTurboModuleCodegenEnabled = true;
```
Then, all our NativeModule specs are transpiled to contain this logic:
```
interface Foo extends TurboModule {
// ...
}
function __getModuleSchema() {
if (!global.RN$JSTurboModuleCodegenEnabled) {
return undefined;
}
// Return the schema of this spec.
return {...};
}
export default TurboModuleRegistry.get<Foo>('foo', __getModuleSchema());
```
Then, in our C++ JavaTurboModule, and ObjCTurboModule classes, we use the TurboModule JS codegen when the jsi::Object schema is provided from JavaScript in the TurboModuleRegistry.get call.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D24636307
fbshipit-source-id: 80dcd604cc1121b8a69df875bbfc87e9bb8e4814
Summary:
TurboModule methods that return promises are synchronously run on the JavaScript thread. Back in D22489338 (9c35b5b8c4), we wrote code to make them dispatch on the NativeModules thread. That code, however, was just left disabled. In this diff, I wire up the TurboModules infra to a MobileConfig, which should allow us to assess the performance impact of async dispatch of promise methods to the NativeModules thread in production, before we roll it out more widely.
Changelog: [Internal]
NOTE: This diff was reverted, beacuse we landed it it without D24685387.
Reviewed By: ejanzer
Differential Revision: D24787573
fbshipit-source-id: 324bd22ce79c2c16c7f7b6996496d255a2c6256e
Summary:
This pr fixes: https://github.com/facebook/react-native/issues/30123 .
When secureTextEntry is true, setInputType will set the inputType of textInput to password type.
Password type default font-family will be monospace font, so we need to setTypeface after the setInputType.
## Changelog
[Android] [Fixed] - Font family is not apply when secureTextEntry is true.
Pull Request resolved: https://github.com/facebook/react-native/pull/30164
Test Plan:
Before this pr:
After this pr:
Please initiated a new project and replaced the App.js with the following code:
```
iimport React from 'react';
import {SafeAreaView, TextInput} from 'react-native';
const App = () => {
return (
<SafeAreaView>
<TextInput
id={'email'}
placeholder={'Email'}
secureTextEntry={false}
style={{fontFamily: 'Helvetica', fontSize: 14, fontWeight: '400'}}
/>
<TextInput
id={'password'}
placeholder={'Password'}
secureTextEntry={true}
style={{fontFamily: 'Helvetica', fontSize: 14, fontWeight: '400'}}
/>
</SafeAreaView>
);
};
export default App;
```
Thanks you so much for your code review!
Reviewed By: cpojer
Differential Revision: D24686222
Pulled By: hramos
fbshipit-source-id: 863ebe1dba36cac7d91b2735fe6e914ac839ed44
Summary:
TurboModule methods that return promises are synchronously run on the JavaScript thread. Back in D22489338 (9c35b5b8c4), we wrote code to make them dispatch on the NativeModules thread. That code, however, was just left disabled. In this diff, I wire up the TurboModules infra to a MobileConfig, which should allow us to assess the performance impact of async dispatch of promise methods to the NativeModules thread in production, before we roll it out more widely.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24685389
fbshipit-source-id: 8ceb2e6effc125abecfa76e5e90bd310676aefc9
Summary:
Changelog: [Android] - Change StatusBar style handling strategy
Previously Android status bar can set to `dark-content` or `default`, I made the following changes:
- Added `light-content` to get align with iOS
- Changed the behavior of `default` from setting status bar with 'SYSTEM_UI_FLAG_LIGHT_STATUS_BAR' to not doing anything, I did this because 1, `setStyle('default')` is found called even without explicitly declared <StatusBar> on that surface, which I think should fail silently 2, my idea is that user should set status bar style to `dark-content` or `light-content` explicitly instead of using `default`.
- Fixed the bug found in Dating Settings's Second Look.
Reviewed By: RSNara
Differential Revision: D24714152
fbshipit-source-id: 76e7d0d45fd3b8c3733efaee81426f5f449cc7d8
Summary:
For over a month I've been searching for a crash that occurs during Android's native `dispatchDraw` method on View. The stack traces didn't show anything useful - everything in the stack trace was native Android code,
not React Native code.
This also seems to only repro on certain vendors, and only on a very few React Native screens - I'm still not sure why either of those are the case, but from my repro, a *very* specific set of interactions needs to happen
to trigger this crash. See comments inline and an example stack trace.
Luckily, the fix is trivial. Since this code is used for animations, accessibility, and a number of other important interactions, I'm gating this change for now.
In general we must be careful to only mutate the View hierarchy only when we /know/ for certain it is safe to do so. Indirectly mutating the View hierarchy during measure, onMeasure, layout, dispatchDraw, etc, can all be
very dangerous. This is one of the last "escape hatches" that can cause view hierarchy modifications unexpectedly, so I think it's a very good idea to "secure" this further, and only update props synchronously here - and
ensure that other MountItems like `Delete` are definitely /not/ executed here.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D24639793
fbshipit-source-id: b6219ce882e8d2204b4d10bf99f6a1120a33cb5a
Summary:
I've had my eyes on this optimization for a while: during TTRC especially, but really during any heavy render path, Fabric will create hundreds to thousands of MountItem class instances in order to construct a BatchMountItem.
This results in: hundreds/thousands of round-trip JNI calls, hundreds/thousands of Object allocations, etc. This will also result in increased memory and GC pressure.
Theoretically, by reducing the number of JNI calls and reducing allocations, we may be able to get some small wins in memory and CPU usage during very hot paths.
I am motivated to do this, in part, to indirectly measure the cost of JNI calls as well as allocating many objects vs an int buffer. I am unaware of such a measurement that we can use to make architectural decisions for React Native Android overall.
The other reason this could be a positive change: if it's successful and we can delete the old path, we'll be able to delete a bunch of Java classes entirely which is great for APK size wins.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D24631230
fbshipit-source-id: 86a46ffcaef4ecbec2e608ed226aed0b5c4b832e
Summary:
This re-uses the same logic as `logTaggedMarker` for `logTaggedMarkerWithInstanceKey`. When no instanceKey specified, use 0.
Changelog: [Internal]
Differential Revision: D24607919
fbshipit-source-id: 4a29e5ece9a5462eb1163185d26370ee873f1412
Summary:
Changelog:
Fix the cloneWithChildren implementation that was not copying the list of children on the java object.
We were missing on copying the list of children when cloning. This is pretty bad as it means that the clone operation was mutating the old node as well as the new. When multiple threads were involved this could cause crashes.
Reviewed By: SidharthGuglani
Differential Revision: D24565307
fbshipit-source-id: 4e2e111db389e25c315ce7603b4018ac695bb0f1
Summary: We support setting the text color in the ReactPicker component, but we don't apply the text color to the little arrow icon that appears next to it. This diff applies the color tint from the picker's primary text color (set with a style prop on the main picker component, *not* the 'color' prop on the Picker.Item) to the background of the picker, which tints the arrow icon.
Reviewed By: makovkastar
Differential Revision: D24480642
fbshipit-source-id: 7ce84d616ae677da8975be9444428392020c57dc
Summary:
Bump Okio to 1.17.5, which includes fixes for many bugs and crashes since current version. Also removed android.enableR8=false from gradle.properties because it's deprecated. And moved FEST_ASSERT_CORE_VERSION from gradle.properties to build.gradle because it's used in single line.
## Changelog
[Android] [Changed] - bump Okio to 1.17.5
Pull Request resolved: https://github.com/facebook/react-native/pull/30204
Test Plan: RNTester builds and runs as expected.
Reviewed By: hramos
Differential Revision: D24560711
Pulled By: fkgozali
fbshipit-source-id: 433075293ca2dc41869dbb272d674625639c8b83
Summary:
When working with RN installed from npm and a regular project structure `$rootDir` won't be at the react-native package root. Instead we can use `$projectRoot` which will always be the ReactAndroid folder.
## Changelog
[Android] [Internal] - Use $projectDir instead of $rootDir for ReactAndroid codegen
Pull Request resolved: https://github.com/facebook/react-native/pull/30220
Test Plan: Test building an app with RN as a regular dep with codegen enabled
Reviewed By: hramos
Differential Revision: D24560634
Pulled By: fkgozali
fbshipit-source-id: 434d32f37e6f9d48a8c562655ceff7249bd056ce
Summary:
Pass the ReactAndroid project build directory as a variable to the ndk build so it can be used instead of assuming that the build directory is under ReactAndroid/build.
## Changelog
[Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/30222
Test Plan: Tested in an app with a custom build directory
Reviewed By: yungsters
Differential Revision: D24560643
Pulled By: fkgozali
fbshipit-source-id: cc65a70582f546ca2e2ca9fb6a2ff03ea70ca9d8
Summary:
This does a few things:
* Remove USE_CODEGEN flag so that TurboModule is enabled by default for RNTester
* Use the codegen output for Java/JNI spec files
* Remove the checked in com.facebook.fbreact.specs Java/JNI files
Changelog: [Changed][Android] RNTester now enables TurboModule by default using codegen.
Reviewed By: RSNara
Differential Revision: D24382083
fbshipit-source-id: 87e3e0581bac3287ef01c1a0deb070c1d7d40f2d
Summary:
This moves all deps on the checked in fbreact/specs files to use the generated output (during build time) instead.
TLDR:
`react_native_target("java/com/facebook/fbreact/specs:FBReactNativeSpec")` ==> `react_native_root_target("Libraries:generated_java_modules-FBReactNativeSpec")`
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24520293
fbshipit-source-id: 3fb34f172f1ab89b7198dfb4fccf605fbc32d660
Summary:
Came to learn RN is deprecating Android 19, 20: a17ff44adc
Did a quick check of left over code from the deprecation.
## 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] [Deprecated] - Cleanup usages of deprecated Android API
Pull Request resolved: https://github.com/facebook/react-native/pull/30243
Reviewed By: fkgozali
Differential Revision: D24548084
Pulled By: JoshuaGross
fbshipit-source-id: 3054ca1455bcff2bd5c9791633942dc0cca7cb2c
Summary:
Sometimes stopSurface crashes when unmountReactApplication is called under Fabric; knowing the stack trace up to this point might assist in debugging.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D24532027
fbshipit-source-id: f350e77fb1a2de52eb146b449f1d2f6e960fa017
Summary:
Fabric should be inserting Views into the hierarchy in the correct order based on z-index already, so there should be no reason to enable this mechanism.
At best it's a perf pessimisation and at worst it could be causing consistency issues or crashing (TBD). Most likely this is a noop.
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D24512203
fbshipit-source-id: b9336240ef8506742bcbd8d08fc8b830f82cdfe2
Summary:
I want to see if the child count changes before/after this method execute; that would help pinpoint the cause of these crashes.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24510064
fbshipit-source-id: 11b4baf15bc5e0beb23d65546605b378d84d1b20
Summary:
The value of the `ScrollView.snapToOffsets` property can be an empty array (most likely an issue in the product code), which will crash the app. This diff adds a check to prevent crashing in this scenario and falling back to the default snap behaviour.
Changelog:
[Android][Fixed] - Do not crash when ScrollView snapToOffsets is empty
Reviewed By: sammy-SC
Differential Revision: D24502365
fbshipit-source-id: c63b8e3b8f2fb323ebd6c962ee628015934d8e11
Summary:
Proxy is now enabled by default in hermes 0.7 (https://github.com/facebook/hermes/releases/tag/v0.7.0). However we currently disable it because of the config we pass.
This removes the config so proxy is now enabled.
## Changelog
[Android] [Changed] - Use default for hermes es6 proxy enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/30142
Test Plan: Tested that proxy is now enabled (typeof Proxy !== 'undefined') with hermes 0.7.
Reviewed By: cpojer
Differential Revision: D24494182
Pulled By: mhorowitz
fbshipit-source-id: 7f8a506e2c436f2f1611e183ca22d33dc763643c
Summary:
Added a few FB vs OSS polyfills:
* react_native_root_target() to refer to the root FB react-native-github/ dir or repo dir in OSS
* react_native_xplat_synced_target() for anything xplat
* a few others
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24437245
fbshipit-source-id: ee290a87a98a8e9be67b102a96f2faac2a2cb92b
Summary:
There's a crash for a small number of users that looks like it is happening when cutting the text via a context menu, or deleting content near the end.
This is only happening because we cache the Spannable and it detects changes due to the cache mechanism itself. I'm making a minor change that will hopefully result
in Spannables being copied instead of the same Spannable instances being used for display on the View and measurement; and also swallowing this error, since it should
not be considered as a fatal, unrecoverable error for now. Hopefully we can delete entirely in the future.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D24430622
fbshipit-source-id: 495458b3d85733e46a7e62b5c954b7cb6b00470b
Summary:
We've deprecated API 20 and below. This is just a cleanup to remove code that assumes API level <21.
Changelog: [Android][Deprecated] Deprecate support of Android API levels 19 and 20.
Reviewed By: fkgozali
Differential Revision: D24380233
fbshipit-source-id: d8f98d7cb19446a60ba36137f1f9290e35f27c02
Summary:
This diff updates the minsdkversion of RN OSS template to API level 21.
Changelog: [Android][Deprecated] Deprecate support of Android API levels 19 and 20. The new minSDK version will be 21+ moving forward.
Reviewed By: fkgozali
Differential Revision: D24379607
fbshipit-source-id: 6801cdcd363065807cdc11006bd94217f914fac7
Summary:
Fixes a NPE in debug mode. This will only impact developers who have explicitly turned this debug flag on, so it's a very low-pri fix.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D24410825
fbshipit-source-id: 08c8a0c6d0e0fb7c132725ad6af9460b91a7edf3
Summary:
So that it's easier for C++ targets to depend on libglog.so for debugging purpose.
Changelog: [Internal]
Differential Revision: D24382033
fbshipit-source-id: 00ad6b2365d571583d6d1aaa40fac2c96974abf1
Summary:
Although the interface for both NativeModules is the same, we'd like to enforce 1 `TurboModuleRegistry.get` call per NativeModule spec file. Therefore this diff splits the one spec into two.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24325260
fbshipit-source-id: f18718e4235b7b8ccbfc44a7e48571ecf483a36c
Summary:
The iOS and Android NativeModules are very different. It's better to split the two interfaces, than to have one merged interface.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24324247
fbshipit-source-id: 097273829ffc719eff006ed2dde55f0dd6bd7d95
Summary:
This NativeModule is actualy not used! Removing this now.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24324362
fbshipit-source-id: 1322c5e072961f1c6c54bfc6dbd562d42f9e5b3f
Summary:
When switching between non-Fabric and Fabric screens, I believe that `initializeEventListenerForUIManagerType` is not always being called on the NativeAnimatedNodesManager if
`NativeAnimatedModule.initializeLifecycleEventListenersForViewTag` is being called before the NativeAnimatedNodesManager ivar has been set. This should occur very infrequently, but logs
indicate that it /does/ happen in some marginal cases. Protecting against these cases should be trivial, by using the `getNodesManager` method which is responsible for returning a nodes manager or creating a new one.
The existing uses of the `NativeAnimatedNodesManager` ivar also occur on different threads and we were not protecting against this, so I'm changing it to an atomic. It's very likely that
the inconsistency issues in the past were caused not by ordering errors, but thread races.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24267118
fbshipit-source-id: 68abbff7ef3d0b2ecc9aa9977165663ad9447ab8
Summary:
There are cases under investigation where unmountReactApplication is called before the ReactRootView gets an ID; in some or all of those cases, UIManagerBinding.stopSurface cannot get the ReactFabric JSI module and crashes there.
It's still unclear why `unmountReactApplication` is being called in these circumstances - maybe another crash causing React Native teardown?
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D24214712
fbshipit-source-id: 796594653f4ff6d87088c4841b89f06cc873b46f
Summary:
In D23640968 (78b42d7fb7) I introduced a mechanism to update offsetX/offsetY whenever onMeasure/onLayout were called, to ensure that `measureInWindow` had the correct metrics and would work properly.
However, now `uiManager.updateRootLayoutSpecs` gets spammed and is called too often. For example, whenever a TextInput is focused/blurred, `uiManager.updateRootLayoutSpecs` may be called 5+ times even though
the measure specs/offsets may only change once.
Thus, we just compare with previous values before calling into the UIManager. This should give us a very small perf improvement.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D24176867
fbshipit-source-id: f0dcc816e651a843607e9e5d40d8f3489894d4ba
Summary:
dispatchDraw, dispatchGetDisplayList, updateDisplayListIfDirty, recreateChildDisplayList, etc, can all crash internally for a variety of reasons and it can be very tricky to track down the root cause. This isn't a fix, this just adds extra logging to hopefully make debugging easier.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D24166149
fbshipit-source-id: 1bbaf34a92a9bcac5a594a25522c66e6e0cc80ca
Summary:
This PR changes ReadableNativeMap.getNullableValue to return null if key not found, instead of throwing exception. This matches method signature and nullable annotation.
## Changelog
[Android] [Changed] - fix ReadableNativeMap.getNullableValue to match signature
Pull Request resolved: https://github.com/facebook/react-native/pull/30121
Test Plan: RNTester app builds and runs as expected, and getNullableValue will return null instead of throwing exception.
Reviewed By: JoshuaGross
Differential Revision: D24164302
Pulled By: fkgozali
fbshipit-source-id: 572c1d4ae5fd493aa0018c2df1dfc7fc91cb4b6b
Summary:
Fix ReadableArray annotations, because these methods throw ArrayIndexOutOfBoundsException instead of null if index is not found.
## Changelog
[Android] [Changed] - fix ReadableArray null annotations. Possibly breaking change for Kotlin apps.
Pull Request resolved: https://github.com/facebook/react-native/pull/30122
Test Plan: RNTester app builds and runs as expected, and show correct type in when used with Kotlin code.
Reviewed By: JoshuaGross
Differential Revision: D24164326
Pulled By: fkgozali
fbshipit-source-id: 0c3f8fa9accbd32cc71c50befe9330e5201643f6
Summary:
When I landed D24042677 (030d2c1931), I had the right idea in spirit but forgot to negate the if statement. Oops.
This means that in non-Fabric, the cached spannable will be updated (potentially causing a crash) and the cached spannable will *never* be updated, meaning that most TextInputs will be measured as 0 in Fabric.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D24119952
fbshipit-source-id: dc86137956535e1f2b147bb432d050b3561e2658
Summary:
This is a resubmit of D21499015. It resolves https://github.com/facebook/react-native/pull/28852 and https://github.com/facebook/react-native/issues/27787.
From Harry Yu's original PR (too old to merge now):
Text in TextInputs can't be selected by long press. This happens only when they're inside of FlatLists that are rendered with removeClippedSubview prop set to true on Android.
Fixes https://github.com/facebook/react-native/issues/27787
Issue https://github.com/facebook/react-native/issues/6085 2 years ago had fixed this issue with a quick fix, but the code has since disappeared in another change. It has a longer explanation for why it's fixed, but essentially - the text is assumed to be not selectable since the TextInput is initialized without being attached to the window. We need to explicitly set the text to be selectable on attachment. This change redoes that change with a 1-line fix.
Changelog: [Android] [Fixed] - Fixed TextInput not being selectable in removeClippedSubviews FlatLists
Pull Request resolved: https://github.com/facebook/react-native/pull/28852
Test Plan:
This can be tested with a new toggle in RNTesterApp.
Go to the FlatList in RNTesterApp
Toggle on "removeClippedSubviews"
Try selecting some text in the list header. It should fail without this comment but succeed with it
Reviewed By: sammy-SC
Differential Revision: D24043533
Pulled By: JoshuaGross
fbshipit-source-id: c8e60f8131ccc5f6af31ed976c4184d0a16eb3af
Summary:
iOS Fabric actually ignores the `index` property and just uses parent and child tags to remove the child from a parent. This brings Android slightly closer to iOS: we try to use the index, but if the index is incorrect, we either (1) throw if the child isn't contained in the parent, or (2) find the correct index, and continue.
In debug, this will still crash, so we'll get more signal about why this happens.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D24056375
fbshipit-source-id: 07507cc32ad02505d3271fc95ecb45d080109078
Summary:
Adding another method to ReactMarker to log a marker with both a tag and an instanceKey. The instanceKey is used to attach the event to the correct marker instance - this is used already in Java, but not in C++ yet.
The way that ReactMarker is currently set up makes this change a little more complex/confusing. For some reason I'm not totally clear on, we're using C-style exports with some platforms-specific ifdefs in ReactMarker.h (even though the impl is .cpp?). And we swap out the implementation for `logTaggedMarker` at runtime in platform-specific code (JReactMarker and RCTCxxBridge).
In this diff, I just add a new function alongside `logTaggedMarker`, `logTaggedMarkerWithInstanceKey`. I did it this way because I figured modifying `logTaggedMarker` to add an argument would be a breaking change.
Reviewed By: PeteTheHeat
Differential Revision: D23831533
fbshipit-source-id: f5b3eba1f43a80f7723fdb64cfc0a792548db2ba
Summary:
Flow will soon stop allowing generic types to "escape" out of the scope in which they were defined. The fix will be to add annotations to currently-unannotated variables, parameters, and function returns, so that generics don't become inputs to type inference for those positions. This diff adds new type annotations to xplat where possible to minimize the impact of this change.
This diff was generated by running
```
buck run //flow/src/facebook/komodo/binaries:annotate_escaped_generics -- --write ../../xplat/js
```
from within the flow directory, and then reverting changes that led to new errors. Most changes were reverted by running:
```
facebook/flowd check --json --json-version=2 ../../xplat/js &> post-json
jq -f j.jq < post-json | xargs hg revert
```
where `j.jq` is
```
def locs: [.primaryLoc.source, (select(.rootLoc.source != null) | .rootLoc.source), .referenceLocs[].source ] | unique;
[.errors[] | locs[]] | unique | .[]
```
Changelog: [Internal]
Reviewed By: panagosg7
Differential Revision: D24006427
fbshipit-source-id: 0cd6ec8a9611d8b1e9b14c54f9fffd2d7de2fd9e
Summary:
This is a check to execute code only in Fabric, and... it's just wrong. This object is *always* present, for Fabric and non-Fabric. We instead need to check if there's actually a state object, as other parts of the code check for.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D24042677
fbshipit-source-id: 5cf6ebc8f07987d917fdf11042d1715876fa8229
Summary:
If removeViewAt crashes, log the children of the parent view, and all of the parent's ancestors.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D24019515
fbshipit-source-id: c5b1ca0948ebc47f2648e161770affa8542ca5dd
Summary:
It was recently upgraded to 4.4, so we don't need the 4.3.1 anymore.
Changelog: [Android][Removed] Removed Robolectric 4.3.1 setup
Reviewed By: jselbo
Differential Revision: D24030822
fbshipit-source-id: 09b3c577d32028723e7bbc02f13459a7ae69b749
Summary:
Before RNTester compilation starts, it needs to wait for :ReactAndroid NDK build to finish, so that it knows where to find the exported .so files. This tells the `preBuild` task to depends on `:ReactAndroid:prepareReactNdkLibs` task. The .so files are now copied over to the local project build dir, instead of depending on :ReactAndroid's build dir.
For cleanup, the reverse ordering is needed: before `clean` removed our temp dir to store the copied .so files, make sure the ndkBuild cleanup tasks execute beforehand.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23982989
fbshipit-source-id: 955d7c9bccb5855b6b066fca89764df2ede89f63
Summary:
Split the two specs, so that that we don't have to use Flow unions in the merged spec.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23800841
fbshipit-source-id: 28b67578832ebd733bd080877e4ab763c013fded
Summary:
Changelog: [internal]
# Why is text laid out twice in Fabric?
Layout constraints (min and max size) change during startup of Fabric surface.
1. `Scheduler::startSurface` is called with max size being {inf, inf}.
2. `Scheduler::constraintSurfaceLayout` is called with max size equal to viewport.
These are two operations that don't happen one after the other and on Android, CompleteRoot is called from JS before second operation is called. This triggers layout with max size {inf, inf} and later when second operation is called. Layout happens again now with correct size.
# Fix
Make sure `Scheduler::startSurface` is called with proper values and not {inf, inf}.
Reviewed By: JoshuaGross, yungsters
Differential Revision: D23866735
fbshipit-source-id: b16307543cc75c689d0c1f0a16aa581458f7417d
Summary:
Blocking people didn't work in Dating Settings without the Bridge.
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D23904867
fbshipit-source-id: 4a68b9d99fcc812f6616783a06dc047a3bc64491
Summary:
TurboModule Java files are still using the old lib name: `turbomodulejsijni`, so let's keep it that way for now.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D23946945
fbshipit-source-id: ff095ff51dca532c82e67e1c75e9a4e9be392d61
Summary:
To make it easier for hosting app or other lib to get access to the ReactAndroidNdk .so outputs, let's define common targets in a dedicated Android-prebuilt.mk. Hosting app's Android.mk just need to include the mk path.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D23938538
fbshipit-source-id: 850d690326d134212d5f040c6fa54ab50c53cb87
Summary:
in Android 11, there's an issue where Text content is being clipped. The root cause appears to be a breaking change in how Android 11 is measuring text. rounding up the layoutWidth calculation mitigates the issue.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D23944772
fbshipit-source-id: 1639259da1c2c507c6bfc80fed377577316febac
Summary:
This is a follow-up for fixing the xiaomi NullPointer crash (D23331828 (07a597ad18) D23451929 (b5b4a70410)):
1, Clean up previous temporary fix in js.
2, Cover all cases including caretHidden is set and isn't set, in previous fix if caretHidden isn't set then fix won't be executed.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D23816541
fbshipit-source-id: a7543f6767430abb74141a747b08391986662958
Summary:
Changelog: [Internal]
Padding needs to be rounded down (floor function), not rounded to the closest natural number.
Otherwise the content of the view might not fit.
Reviewed By: JoshuaGross
Differential Revision: D23905145
fbshipit-source-id: e84d70155b207144b98646dd0c4fea7a8c4bd876
Summary:
Changelog: [internal]
When paper measures text, it sets `useLineSpacingFromFallbacks` flag on the Layout object. In Fabric this was missing and can cause incorrect layout.
Reviewed By: JoshuaGross
Differential Revision: D23845441
fbshipit-source-id: 538f440cdbbf8df2cba0458837b80db103888113
Summary: Adding two new ReactMarkers for start and end of bridgeless initialization. Creating new ones instead of reusing existing ones to make it easier to differentiate data from the bridge vs. bridgeless, and also because our existing markers 1) aren't very easy to understand, and 2) don't map cleanly to the new architecture.
Reviewed By: PeteTheHeat
Differential Revision: D23789156
fbshipit-source-id: 2ed10769e08604e591503a2bc9566aeb1d0563ed
Summary:
Changelog: [Internal]
Construction of Layout will be needed in `TextLayoutManager.measureLines`, pulling it out into separate function prevents code duplication.
Reviewed By: shergin
Differential Revision: D23782905
fbshipit-source-id: 8ab817559ca154716a190ca1012e809c5fa2fd6e
Summary:
Now that the react-native-codegen produces the Android.mk for the JNI C++ output, let's compile them into its own shared library, to be included in the ReactAndroid final deliverable: libreact_codegen_reactandroidspec.so. This is gated behind `USE_CODEGEN` env var.
Note: RNTester specific C++ spec files are not compiled here.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23809081
fbshipit-source-id: 7a90f420a923d5d02654facac01ffe025c321e44
Summary:
This is to prepare for enabling TurboModule on Android. This commit compiles in all the core files (C++) into the ReactAndroid NDK build step. This doesn't yet enable TurboModule by default, just compiling in the infra, just like for iOS.
New shared libs:
* libreact_nativemodule_core.so: The TurboModule Android core
* libreact_nativemodule_manager.so: The TurboModule manager/delegate
To be compatible with `<ReactCommon/` .h include prefix, the files had to move to local `ReactCommon` subdirs.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23805717
fbshipit-source-id: b41c392a592dd095ae003f7b2a689f4add2c37a9
Summary:
In a previous recent diff we changed Android's Delete mount instruction to *not* recursively delete the tree. This is fine, but because of that, we stopped calling `onDropViewInstance` when views are normally deleted.
Bring back that behaviour.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23801666
fbshipit-source-id: 54e6b52ab51fff2a45102e37077fe41081499888
Summary:
This diff moves the code of TurboModule Core from ReactCommon/turbomodule to ReactCommon/react/nativemodule
For iOS: Pod spec name stays as "ReactCommon/turbomodule/..." for now, only the source/header location is affected. The target will be renamed/restructured closer to TurboModule rollout.
changelog: [internal] Internal
Reviewed By: RSNara
Differential Revision: D23362253
fbshipit-source-id: c2c8207578e50821c7573255d4319b9051b58a37
Summary:
Because BatchMountItem executes many items, sometimes it's unclear which MountItem causes a crash. Catch and log the exact item.
This shouldn't cause perf regressions because we have a try/catch block in FabricUIManager where execute is called.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23775500
fbshipit-source-id: c878e085c23d3d3a7ef02a34e5aca57759376aa6
Summary:
There are cases where we Delete+Create a node in the same frame. Practically, the new differ should prevent this, but we don't want to rely on that necessarily.
See comments for further justification on why deleteView can do less work overall.
In reparenting cases, this causes crashes because dropView removes *and deletes* children that shouldn't necessarily be deleted.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23775453
fbshipit-source-id: c577c5af8c27cfb185d527f0afd8aeb08ee3a5fe
Summary:
Inside JavaTurboModule, the native `CallInvoker` is used to schedule work on the NativeModules thread. So, in ~JavaTurboModule(), I scheduled some work on the NativeModules thread. This work holds a copy of the JNI global reference to the Java NativeModule object, and when it's executed, it resets this global reference to the Java NativeModule object. This should ensure that the we don't access the JVM in ~JavaTurboModule, which could crash the program.
I also removed the redundant `quitSynchronous()` in `~CatalystInstanceImpl()`, to prevent the NativeModules thread from being deleted before we delete the `jsi::Runtime`. This shouldn't cause an issue, because we delete the NativeModules thread when we call [ReactQueueConfigurationImpl.destroy()](https://fburl.com/codesearch/p7aurwn3).
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D23744777
fbshipit-source-id: a5c8d3f2ac4287dfef9a4b4404a04b335aa0963d
Summary:
Changelog: [internal]
# Problem
Default padding for TextEdit is top: 26, bottom: 29, left: 10, right: 10 however the default values for LayoutMetrics.contentInsets is {0, 0, 0, 0}.
If you try to construct TextEdit with padding 0, Fabric will drop padding update because padding is already 0, 0, 0, 0.
# Fix
To fix this, I added a special case to `Binding::createUpdatePaddingMountItem`, if the mutation is insert, proceed with updating padding.
Reviewed By: JoshuaGross
Differential Revision: D23731498
fbshipit-source-id: 294ab053e562c05aadf6e743fb6bf12285d50307
Summary:
Right now nested Text components are not accessible on Android. This is because we only create a native ReactTextView for the parent component; the styling and touch handling for the child component are handled using spans. In order for TalkBack to announce the link, we need to linkify the text using a ClickableSpan.
This diff adds ReactClickableSpan, which TextLayoutManager uses to linkify a span of text when its corresponding React component has `accessibilityRole="link"`. For example:
<Text>
A paragraph with some
<Text accessible={true} accessibilityRole="link" onPress={onPress} onClick={onClick}>links</Text>
surrounded by other text.
</Text>
With this diff, the child Text component will be announced by TalkBack ('links available') and exposed as an option in the context menu. Clicking on the link in the context menu fires the Text component's onClick, which we're explicitly forwarding to onPress in Text.js (for now - ideally this would probably use a separate event, but that would involve wiring it up in the renderer as well).
ReactClickableSpan also applies text color from React if it exists; this is to override the default Android link styling (teal + underline).
Changelog: [Android][Fixed] Make nested Text components accessible as links
Reviewed By: yungsters, mdvacca
Differential Revision: D23553222
fbshipit-source-id: a962b2833d73ec81047e86cfb41846513c486d87
Summary:
This fixes TextInput measurement caching. Previously we were not setting the correct Spannable in the cache; we needed to additional Spans to it to indicate font size and other attributes.
This brings Fabric closer to how non-Fabric was measuring Spannables for TextInputs (see ReactTextInputShadowNode.java).
This should fix a few crashes and will be most noticeable with dynamically-sized multiline textinputs where the number of lines changes over time.
This also allows us to transmit less data from C++ to Java in the majority of cases.
Changelog: [Internal]
Differential Revision: D23670779
fbshipit-source-id: cf9b8c848b9e0c2619e01766b72b074248466825
Summary:
Remove `enableFabricStartSurfaceWithLayoutMetrics` and treat as `true` always from now on.
Changelog: [Internal]
Differential Revision: D23633198
fbshipit-source-id: 5b7455b87e578ffa97d80746fa901cd2b50d3ea9
Summary:
This log was necessary to get to the bottom of the TurboModule Fb4a eager init crash. It's no longer necessary, plus it's okay for TurboModules to be null, so we'll remove it for now.
Changelog: [Internal]
Differential Revision: D23607208
fbshipit-source-id: 083b00abe6bdefc5986f842cd6f9438f47cce1ce
Summary:
Right now you can scroll a horizontal ScrollView with TalkBack even if you've disabled scrolling in JS, because our HorizontalScrollView component doesn't prevent the accessibility scroll event (this doesn't seem to happen with vertical ScrollViews for some reason...) This diff adds an accessibility delegate to both of the Android ScrollView components to make sure they're not scrollable if scrolling has been disabled in JS.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23582689
fbshipit-source-id: b670bdb462ab9c963c7125597d60ca97c7d88a9c
Summary:
When we render a text input that already has a text value (<TextInput value="123" />), its selection (cursor) is automatically set to the end of the text. However, when you swipe to focus the text input with TalkBack, Android decides it needs to clear the selection, which moves the cursor back to the beginning of the text input. This is probably not what you want if you're editing some text that's already there. Ideally we would just keep the selection at the end, but I don't know how to prevent this from happening - it seems to be part of how TextView handles the accessibility focus event? So instead I'm just explicitly setting the selection to the end of the text in our handler for accessibility click.
Changelog: [Android][Fixed] Move selection to the end of the text input on accessibility click
Reviewed By: mdvacca
Differential Revision: D23441077
fbshipit-source-id: 16964f5b106637e55a98c6b0ef0f0041e8e6215d
Summary:
SoLoader fixed crash on Android 4.1, and includes many improvements and fixes https://github.com/facebook/SoLoader/releases/tag/v0.9.0. Also Fresco 2.3.0 depends on it, and will create a PR soon to bump Fresco.
## Changelog
[Android] [Changed] - Bump SoLoader to 0.9.0
Pull Request resolved: https://github.com/facebook/react-native/pull/29821
Test Plan: CI is green
Reviewed By: fkgozali
Differential Revision: D23477538
Pulled By: mdvacca
fbshipit-source-id: d2d982d5c5c84fc173dc66dfe069713ca90711a8
Summary:
After monitoring scuba for a few days, previous fixes(D23301714 D23331828 (07a597ad18)) don't work as expected.
I managed to test this issue on a Xiaomi device, the crash didn't happen but the there was a popup "Frequetly used email" on top of email edit text:
{F317216473}
Getting rid of the popup probably be the right fix.
For more context see https://github.com/facebook/react-native/issues/27204
Changelog: [Android] - Set caretHidden to true to fix the Xiaomi crash
Reviewed By: mdvacca
Differential Revision: D23451929
fbshipit-source-id: 521931422f3a46a056a9faa4b10fe93cf4732db0
Summary:
This diff optimizes the caching of Spannable objects managed by the TextLayoutManager class.
Previously, these objects were cached using unsing a String representation of the RedableMap (creating this string adds a non trivial cost), this diff improves the caching performance relying on the equals / hashcode methods of the ReadableNativeMap class
I created a MC just to have a killswitch
Motivation: I was analysing another bug and I found this non performant code
changelog: [internal] internal
Reviewed By: shergin
Differential Revision: D23429365
fbshipit-source-id: 59e5ad0b1b95da992ac393aecfe029da68a8df97
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/29794
Per title - need to declare deps of attrs that we are using (soon Buck will enforce this).
Changelog: declare dependencies of all attributes that are used in the resource target.
Reviewed By: jiawei-lyu
Differential Revision: D23388058
fbshipit-source-id: b395d153188f75f8c0d4a6d69302812a56b23925
Summary:
`#import` is non-standard C++ extension which is AFAIK part of Objective-C. I am surprised that it even compiles on Android.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23407689
fbshipit-source-id: 2861138cbcce33674e118a1ad816e33bbf8f30fe
Summary:
This diff creates the new TransparentImmersiveReactActivity in FB4A, the intention is to help integrate TransparentReactActivity with Fb4A
Changelog: [Deprecated][Android] Deprecated method UIManagerModule.getUIImplementation. This method will not be part of the new architecture of React Native.
Reviewed By: stashuk
Differential Revision: D23324543
fbshipit-source-id: 35395fe410790a9611a4637361b888678eb0a836
Summary:
This updates okhttp to the newest compatible version with a couple of fixes and improvements. See https://github.com/square/okhttp/commits/okhttp_3.12.x
## Changelog
[Android] [Changed] - Update Okhttp to version 3.12.12
Pull Request resolved: https://github.com/facebook/react-native/pull/29741
Test Plan: Current tests should pass.
Reviewed By: shergin
Differential Revision: D23406613
Pulled By: mdvacca
fbshipit-source-id: b0b4ec52a6a8345f1c36e18e384761386096f1d8
Summary:
We have password components which allow visibility to be toggled by
setting both the keyboardType and secureTextEntry props. The order in
which those updates are executed is determined by iterating a NativeMap
of props, and the iteration order of a NativeMap is implementation
dependent.
With libc++ as our STL, we observe that setSecureTextEntry is called
before setKeyboardType. This results in the following sequence of input
type flag settings when toggling the component to visible and then back
to hidden:
* The field starts out with TYPE_TEXT_VARIATION_PASSWORD (0x80).
* When we toggle to visible, setSecureTextEntry is called with password
being false, which clears TYPE_TEXT_VARIATION_PASSWORD.
setKeyboardType is then called with the visible-password keyboard
type, which sets TYPE_TEXT_VARIATION_VISIBLE_PASSWORD (0x90).
* When we toggle back to hidden, setSecureTextEntry is called with
password being true, which sets TYPE_TEXT_VARIATION_PASSWORD but
doesn't clear TYPE_TEXT_VARIATION_VISIBLE_PASSWORD. setKeyboardType is
then called with the default keyboard type and additionally sets
TYPE_CLASS_TEXT, but TYPE_TEXT_VARIATION_VISIBLE_PASSWORD remains and
the password field remains visible.
The fix is to clear TYPE_TEXT_VARIATION_VISIBLE_PASSWORD when
setSecureTextEntry is called with password being true, to ensure the
password gets hidden.
Changelog:
[Android][Fixed] - Fix secure text entry setting to always hide text
Reviewed By: shergin
Differential Revision: D23399174
fbshipit-source-id: a81deec702e768672e2103b76ab50ec728dac229
Summary:
Long term fix in native for Error: android_crash:java.lang.NullPointerException:android.widget.Editor$SelectionModifierCursorController.access$300
For more detail please see T68183343 D23301714
Changelog:
[Android][Changed] - Fix Xiaomi TextInput crash in native
Reviewed By: mdvacca
Differential Revision: D23331828
fbshipit-source-id: 914f2d431772f49711b940d47a2b3ef57ab82cdc
Summary:
Make sure to check incoming state values before calling SetState, or we call back and forth forever.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D23389355
fbshipit-source-id: 9cf6110cf654fe93f555a6fbfd9b20f112214e0a
Summary:
See title.
This feature makes LayoutAnimations less stable and isn't needed generally; will be deleted soon.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23382973
fbshipit-source-id: f633f482d463b3ee3e4625b30544a33cd6e36119
Summary:
In some cases (BottomSheet?) the parent/ViewManager removes all children of the View before Fabric gets a chance to remove the children.
Apparently prior to D23368229 (d344fb4e29) (landed just today!) this sequence of operations happened and just noop'ed. Since we've been doing that happily as long as Fabric
has existed, we'll keep doing that for now.
I suspect that on *some* versions of Android this crashes and others it doesn't, based on logviews and my inability to repro certain crashes.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23387044
fbshipit-source-id: 88a46191adef4f6816bd7babd9103d103ddcef33
Summary:
If we try to delete a view and find the wrong one, when we crash, try to log the *actual* index of the view in question.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23368229
fbshipit-source-id: 7f9835fd07cfe4924d05c7e37b42b9bcdffff4a9
Summary:
Now we store a revision number of a Shadow Tree that leads to a transaction for which the concrete instance of MountingTelemetry corresponds. This is useful to understand how many actual transactions were skipped during a mounting phase (a mounting transaction does not directly correspond to a commit operation).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D23364663
fbshipit-source-id: 32b86bcdfc1ae97d8fff3b97a8615cc5a5b4d4a9
Summary:
Previously this was crashing only in debug, but that's too noisy and isn't giving us any value for now.
Changelog: [Internal]
Differential Revision: D23338800
fbshipit-source-id: bf1535cdda231ccf30af6d00509eec1499a552a1
Summary:
Simplifying the StopSurface flow. Before we would still attempt to execute MountItems, but only the "Delete" operations. This was... well, frankly, overcomplicated. Instead we can just ignore all future MountInstructions for that Surface and delete all views recursively from the root.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23338752
fbshipit-source-id: 6e7ab29ad85572782bfc6a39845a8a619f001559
Summary:
Microsoft’s RN for macOS fork supports the Hermes engine nowadays https://github.com/microsoft/react-native-macos/pull/473. As a longer term work item, we’ve started moving bits that are not invasive for iOS but _are_ a maintenance burden on us—mostly when merging—upstream. Seeing as this one is a recent addition, it seemed like a good candidate to start with.
As to the actual changes, these include:
* Sharing Android’s Hermes executor with the objc side of the codebase.
* Adding a CocoaPods subspec to build the Hermes inspector source and its dependencies (`Folly/Futures`, `libevent`).
* Adding the bits to the Xcode build phase script that creates the JS bundle for release builds to compile Hermes bytecode and source-maps…
* …coincidentally it turns out that the Xcode build phase script did _not_ by default output source-maps for iOS, which is now fixed too.
All of the Hermes bits are automatically enabled, on macOS, when providing the `hermes-engine-darwin` [npm package](https://www.npmjs.com/package/hermes-engine-darwin) and enabling the Hermes pods.
## Changelog
[General] [Added] - Upstream RN macOS Hermes integration bits
Pull Request resolved: https://github.com/facebook/react-native/pull/29748
Test Plan:
Building RNTester for iOS and Android still works as before.
To test the actual changes themselves, you’ll have to use the macOS target in RNTester in the macOS fork, or create a new application from `master`:
<img width="812" alt="Screenshot 2020-08-18 at 16 55 06" src="https://user-images.githubusercontent.com/2320/90547606-160f6480-e18c-11ea-9a98-edbbaa755800.png">
Reviewed By: TheSavior
Differential Revision: D23304618
Pulled By: fkgozali
fbshipit-source-id: 4ef0e0f60d909f3c59f9cfc87c667189df656a3b
Summary:
For some reason, these got out of sync again.
This diff modifies the Java Codegen to sort all the methods.
build-break
overriding_review_checks_triggers_an_audit_and_retroactive_review
Differential Revision:
D23363410
Oncall Short Name: fbandroid_sheriff
Ninja: master broken
fbshipit-source-id: 257d85f92017528e64ced31bc7be011acb333186
Summary:
I'm removing an ill-informed "optimization" that resulted in some StateUpdates being dropped. For some components (including TextInput) we rely on State updates to request a layout from the ShadowNode layer.
In the past we were performing an optimization that didn't update the View layer if the data contained in the State container is identical, but in the case of TextInput and other components, we simply pass an opaque
object with no meaningful data to trigger the layouts. In those cases, it could cause a permanent rift between the View layer's StateWrapper and the most recent state object from the C++ perspective.
In the case of TextInput this didn't cause tangible bugs because you can always update state using an out-of-date State object, but it's better this way anyway.
The other issue is that for some components, we want to know when there's a State update from the Cxx layer. This optimization broke certain logic in those components.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23306222
fbshipit-source-id: 8ef83149b814de50776674b5fd22406be1db14ba
Summary:
# What is this?
For a very long time, we've discussed the possibility of detecting Node Reparenting in the Fabric Differ. Practically, from the developer perspective, ReactJS and React Native do not allow reparenting: nodes cannot be reparented, only deleted and then recreated with entirely new tags.
However, Fabric introduced the idea of View Flattening where views deemed unnecessary would be removed from the View hierarchy entirely. This is great and improves memory usage, except for one issue: if a View becomes unflattened, or becomes flattened, the entire tree underneath it must be rebuilt.
In a past diff we introduced a mechanism to detect sibling reordering cleverly, and produce a minimal instruction set. This diff is very similar: we know the invariants around flattening and unflattening of views and we take advantage of them to produce an optimal set of instructions efficiently.
# What's different from previous attempts?
No global maps! Those are slow!
This seems to work and (hopefully) might even improve performance, since way less work is being done on the UI thread in cases when views are (un)flattened.
This *only* does extra work when flattening/unflattening happens, which gives product engineers a little more control over perf.
# So, how's it work?
This algorithm is intuitively simple (I think) but tricky to pull off, because there are lots of edge-cases.
In short: In the past, that information was hidden from the Differ: the differ didn't know if views were being reparented, it would see them
as entirely new views or as views being deleted if a View was flattened or unflattened. We very subtly change the information given to the differ:
all nodes are visible to the differ, but marked as Flattened or Unflattened. Thus, when the differ compares two nodes in the "old" and "new" tree,
it can tell not just if there are updates to the node but if it has been unflattened or flattened as well.
For example, take this tree, where * indicates that a View is flattened:
```
A
+
+----+---+
B* X
+ +
| |
+---+--+ +
E F Y
```
When the Differ asks for the children of A, in the past it would get a list `[E, F, X]`. That is, B* and X are both its children, but since B is flattened, it is omitted entirely from the list and
its children are substituted.
Now, when the Differ asks for the children of A, we give it this list instead: `[B*, E, F, X]`. That is: we give it a list which includes B, but B is marked as flattened.
Another wrinkle: A node `X` could have its children flattened, but still be a concrete view: so flattening/unflattening is a different operation from making a view "concrete" or "unconcrete", which can change independently of flattening.
There is one additional wrinkle: because of zIndex/stacking order, the children of `B` might not actually appear after `B` in the list. Depending on zIndex, a tree that looks like this:
```
A
+
+------+------+
B* C*
+ +
| |
+--+--+ +--+--+
D E F G
```
Could actually be linearized as: `[D G B* F C* E]` (as an extreme example; but basically all permutations as possible).
This is the reason, and the *only* reason that the inner Flattener/Unflattener
## The cases we need to handle
There are 7 cases/edge-cases of flattening and unflattening that we need to handle. Practically, all cases of reordering + flattening/unflattening, and taking recursive cases into account:
1. View A and A' (A in the old tree, A' in the new tree) are matched in the differ, and A* has been flattened or unflattened. These two cases are the easiest to handle.
2. View A' has been reordered with its siblings, and has been flattened or unflattened. These cases are slightly trickier to handle.
3. While flattening or unflattening, we encounter a child that has also been unflattened or flattened. So we need to handle four cases here in total: Flatten-Flatten, Flatten-Unflatten, Unflatten-Flatten, and Unflatten-Unflatten.
Other things to think about, also covered above:
1. Ordering. Views can be reordered and flattened/unflattened at the same time.
2. zIndex ordering: children in a certain order from the ShadowNode perspective may be stacked differently from a View perspective. We use the zIndex ordering for everything in the differ, and this prevents us from performing certain optimizations (see above: we cannot assume that children come after their parent in a list; they may come before, may be interwoven with children from other parents, etc).
# Perf Implications?
Practically, there should be very little negative overhead. There is some overhead in actually performing a flattening/unflattening operation, but... not much more than before. We don't use global maps, so the cost of flattening/unflattening is basically `O(number of nodes reparented)` - note that that's direct nodes reparented, *not* descendants.
tl;dr the perf hit should be similar to reordering, which is non-zero, but close to zero, and zero-cost for any diff operations on parts of the tree that don't involve flattening/unflattening. AFAICT this is very close to an ideal solution for that reason (but I wish it was simpler overall).
# In Summary?
I hope this works out and I think it could improve a number of things downstream: perf, LayoutAnimations, Bindings, certain crashes because of platform assumptions about mutations, etc.
Is it worth it? This new implementation is substantially harder to reason about, harder to read, and harder to understand. This is an important consideration. All I can say there is that I trust the test suite I've been using, but
the decreased readability is a big negative. Hopefully we can improve this in the future.
The rest is fiddly implementation details that I sincerely hope can be improved and simplified in the future.
# Followups?
The part that makes this algorithm the most expensive is that because of zIndex ordering, we cannot assume that children are linearized after their parents and so we rely more heavily on maps for the flattening/unflattening. Our TinyMap implementation should make these `find` operations fast enough unless trees' children are constantly being reordered, but it's still worth thinking of ways to make this even faster.
Changelog: [Internal]
Reviewed By: shergin, mdvacca
Differential Revision: D23259341
fbshipit-source-id: 35d9b90caf262d601a31996ea2cb37e329c61ffc
Summary:
Simplify the TextInput measurement mechanism.
Now, data only flows from JS->C++->Java and from Java->JS. C++ passes along AttributedStrings from JS if JS updates, and otherwise Java maintains the only source of truth.
Previously we tried to keep all three in sync. This was complicated, slow, and even lead to some crashes.
This feels a bit hacky but I believe it's the simplest way to achieve this short-term. Ideally, we would use something like `AttributedStringBox` and pass that to State from Java,
but currently everything passed through the State system from Java must be serializable as `folly::dynamic`. So, instead, we just cache one Spannable per TextInput component and
use ReactTag as the cache identifier for lookup.
An interesting side-effect is that `measure` could race with TextInput updates, but the race condition favors measuring the latest text, not outdated values.
Followups:
- Can we do this without copying the EditText Spannable on every keystroke? Maybe this approach is too aggressive, but I don't want a background thread measuring a Spannable as it's being mutated.
- Do we need to support measuring Attachments?
- How can we clean up this API? It should work for now, but feels a little hacky.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23290230
fbshipit-source-id: 832d2f397d30dfb17b77958af970d9c52a37e88b
Summary:
In MountingManager.java in Fabric, if we drop a view with any attached views, we also drop all children. If verbose logging is turned on, log all instances of that happening.
This has no impact unless you switch the flag on manually in debug mode.
Changelog: [Internal]
Differential Revision: D23257749
fbshipit-source-id: fce4476aa47cc1b7137cd9fd2fd0241af1593288
Summary:
Fix a failure in running a single command to clean and rebuild with Hermes (e.g. `./gradlew clean :RNTester:android:app:installHermesDebug`).
From my limited understanding of Gradle, the failure was caused by the fact that the `clean` task could end up running after `prepareHermes`, and therefore delete the shared library after it had been copied. This change updates the `prepareHermes` task to impose the proper order.
In investigating this failure, I also updated inconsistent use of the `$thirdPartyNdkDir` variable.
Changelog: [Internal][Fixed] Fix a failure in running a single command to clean and rebuild ReactAndroid with Hermes
Reviewed By: mdvacca
Differential Revision: D23098220
fbshipit-source-id: 822fa8ac9874d54a3fdd432ad8cbee78295228ee
Summary:
This diff updates the directory hierarchy of AndroidTextInput C++ files to be compatible with Android OSS build system
changelog: [internal] Internal
Reviewed By: PeteTheHeat
Differential Revision: D23179390
fbshipit-source-id: 1c52e4f882853799a58d44876cadd392b4a35050
Summary:
This comment shouldn't be committed, and should just be part of the template that generates new BUCK files.
Changelog: [Internal]
Differential Revision: D23225700
fbshipit-source-id: a1728e1a4ac0f3f94c4d1330d489bfae7a76a82d
Summary:
This diff filters the iOS C++ friles that are generated by the oss-android-codegen script
Also, as part of this diff I'm inlcuding .cpp files into the output.
These files are only used and compiled in Android
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23169268
fbshipit-source-id: 404607f3cd6e59197291ea67701774c9c492a282
Summary:
Twilight doesn't have TMPerfLogging enabled. However, the TurboModule infra uses the TMPerfLogger java class everywhere, which loads the turbomodulejsijni library on class load. For some reason, this class load doesn't work, and causes Twilight prod to crash.
To mitigate that crash, this diff delays the so load until it's absolutely necessary, which is by the time we call jniEnableCppLogging. This should never be called in Twilight, because it doesn't have TMPerfLogging enabled. Therefore, the crash should disappear on Twilight.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23192072
fbshipit-source-id: b73ece580e4345dbf835b0fc2f7d43b90f202411
Summary:
This diff extends test-react-native-oss-android-legocastle to test the build of RNTester with fabric enabled in Sandcastle
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23141524
fbshipit-source-id: 396dae1c0a23ce03db1053de1627eacb09a6df94
Summary:
This diff reintroduces the CoreComponentsRegistry class to register core components in the RN Tester app.
This class was previously deleted as part of D23091020 (7fb1afae7f). Different from a past approach, this diff doesn't use inheritance for Hybrid classes (which seems to bring problems in Android 4 devices)
I'm planning to land this diff after I verify that D23091020 (7fb1afae7f) fixed RC (maybe I will wait until sunday's cut)
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23109856
fbshipit-source-id: 5220e522e197f701c782ab5089f9f1036ec90c19
Summary:
This diff unifies the type and value of USE_FABRIC env variable exposed in Gradle with the USE_CODEGEN env variable
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23145658
fbshipit-source-id: 9575f6b50c7a977254e364037d1417b3b1cdb607
Summary:
JavaGenerator is a Java-based implementation for generating codegen output from the parsed schema file. Right now the output is a hardcoded Java file. In the next commits, proper JavaGenerator impl will be added.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23100171
fbshipit-source-id: 1bef23e3dba4d8c222ebdece0edeb4435d388cd4
Summary:
This diff removes the CoreComponentsRegistry class that was recently created to expose Fabric components in OSS
changelog: [internal] internal
Reviewed By: JoshuaGross, shergin
Differential Revision: D23091020
fbshipit-source-id: 9d851608ed0eddb98367265b5e346d5298f5f732
Summary:
This diff adds a new mechanism to enable or disable the build of Fabric in RN OSS
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23084586
fbshipit-source-id: b7b0b842486392ec4ccb91ad1e6441ba3a1f48b2
Summary:
Instead of applying configs from gradle scripts, this introduces a proper Gradle plugin to enable Codegen in an application or library project. In the build.gradle, one enables it by:
```
plugins {
id("com.android.application")
id("com.facebook.react.codegen") // <---
}
// ...
react { // <--- the new plugin extension
enableCodegen = System.getenv("USE_CODEGEN")
jsRootDir = file("$rootDir/RNTester")
reactNativeRootDir = file("$rootDir")
}
```
The plugin supports `react` plugin extension as demonstrated above. Adding this:
* automatically generates all TurboModule Java files via react-native-codegen **before the `preBuild` Gradle task**
* automatically adds the files to the `android {}` project configuration
* is done per project (build.gradle)
This will be the foundation for future React Native gradle plugin beyond just for react-native-codegen.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23065685
fbshipit-source-id: 4ea67e48fab33b238c0973463cdb00de8cdadfcc
Summary:
This diff removes the ndk.moduleName configuration from build.gradle. This seems to be unnecessary
The motivation is to reduce confusion and extra configuration that is not being used by the build system
changelog: [internal] internal change to cleanup ndk configuration in gradle
Reviewed By: fkgozali
Differential Revision: D23068404
fbshipit-source-id: 07bb68906286531efaa9dc0036704c4b3ee1faf5
Summary:
In the past I tried a few heuristics to guess when a batch of Animated Operations were ready, and none of these were super reliable. But it turns out we can safely allow JS to manage that explicitly.
Non-Fabric still uses the old behavior which seems fine.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23010844
fbshipit-source-id: 4c688d3a61460118557a4971e549ec7457f3eb8f
Summary:
This diff extends fabric module to compile in OSS
NOTE: As a side effect of this diff, Fabric will be included into "reactnativejni" which is used by RN OSS.
I'm planning to remove this dependency in the near future - T71320460
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D22991877
fbshipit-source-id: 0ab3ee410dd448bbd87130114bec27c6e6bc65c6
Summary:
This diff introduces the class CoreComponentsRegistry that is responsible of registering core components in fabric.
This is required to make RN Tester to work in Fabric, in the future we'll extract this registry into another module (once we figure it out what's the best way to do this)
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D22991876
fbshipit-source-id: 15e85e15aac5dd981161d9eae35eb2cee4fa66b6
Summary:
This diff refactors the ComponentFactoryDelegate class. It also introduces a new class called ComponentRegistry that will be used to register components into fabric
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D22985313
fbshipit-source-id: e33a3d4fcb3a1c509b80c6ff1f43889480b1c2c3
Summary:
This diff extends the 'textlayoutmanager' module to compile in OSS
As part of this diff I also moved Android files in order to make the module compatible with Android.mk system
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D22963706
fbshipit-source-id: 14a7309f589fe12c21131c7d5cef02b4323d4a93
Summary:
This diff refactors the class Runnable into a struct to make it work in OSS
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D22963704
fbshipit-source-id: 2212c8f1e4a62b2bcad5c061709e29b247454fc1
Summary:
New mechanism to soft-crash, or crash, and collect diagnostics in the mounting layer.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D22971260
fbshipit-source-id: 860cde3effa4a187f10f5dd1488dd41ace65e363
Summary:
Make react/core module to compile in OSS
This is necessary to make fabric compile in OSS
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D22908222
fbshipit-source-id: a37b87d02ecf77bb25693ce32cd0f3432be5daa7
Summary:
This diff creates the Android.mk file for the fabric graphics module
This is necessary to enable fabric in RN OSS
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D22908219
fbshipit-source-id: 70ef1d06053b0ca07a71c0a2d36e4edd617b2a25
Summary:
This diff creates the Android.mk file for the fabric debug module
This is necessary to enable fabric in RN OSS
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D22908220
fbshipit-source-id: f970fa1d8534a6043f60f362740bfc3e5199b511
Summary:
Update FabricViewStateManager so that the caller can bail out of updates by returning null.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22966024
fbshipit-source-id: 31cd9ec8a9a9918fbb94844e30ed1a2fcc61997d
Summary:
Improve logging slightly.
One issue I ran into is that the "after" view hierarchy looks identical to "before" unless you schedule for the next UI tick.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22962116
fbshipit-source-id: c7a1e16e26d2aebefa3baf3acfef4e133b8fde70
Summary:
iOS will need to be implemented separately, but the shared C++ bits are in place.
Explanation: there is currently no way for the View layer to /know/ if an UpdateState call has succeeded or failed. Generally we just assume it succeeds, but if it fails we have no way of knowing or retrying.
This can cause some UI bugs. To mitigate this, I'm introducing a "failure" notification callback mechanism. The JNI bridging for this is a little complicated to avoid passing Runnable across the JNI, but it
should be much simpler on iOS.
In development this seems to make View components much more reliable.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22940187
fbshipit-source-id: 917f2932ae22d421f91fe8f4fca3f07dc089f820
Summary:
With BackgroundExecutor+State Reconciliation, it is pretty common to have races where View layer UpdateState calls are thrown away.
Theoretically this is /always/ possible since C++ doesn't retry failed UpdateStates, we just try once and then bail. This is part 1 of improving our mechanisms for ensuring that State stays up-to-date from the View layer.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22933927
fbshipit-source-id: 77b3b87402f772e3f149be0f9200e673bbed7b57
Summary:
Making error more explicit to assist in debugging.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D22929047
fbshipit-source-id: 4f26668a96868e7c5865a587142c3bcd10a26c90
Summary:
Instead of sourcing-in a .gradle file to setup codegen tasks in Gradle, let's define a proper `com.facebook.react.codegen` Gradle plugin, so that any Gradle project (lib/app) can include it via:
```
plugins {
id 'com.facebook.react.codegen'
}
```
The idea (not yet implemented in this commit) is to then allow those projects to add this section in the projects:
```
codegen {
enableCodegen = ...
jsRootDir = ...
}
```
This is more scalable and less hacky.
Important notes:
* The Gradle plugin should be prepared during the build, we're not going to publish it to Maven or other repo at this point.
* This setup is inspired by composite build setup explained here: https://ncorti.com/blog/gradle-plugins-and-composite-builds
* All android specific setup is added under `packages/react-native-codegen/android/` dir, but long term, we may want to move it up to `packages/react-native-codegen/` along side setup for other platforms.
* As part of this setup, the plugin will have an option (to be validated) to produce Java specs using https://github.com/square/javapoet
* This is the same library already used for React Native Android annotation processors
* This generator will not deal with parsing Flow types into schema, it will just takes in the schema and produce Java code
* We're evaluating whether JavaPoet is a better choice for Java code generation long term, vs building it in JS via string concatenation: https://github.com/facebook/react-native/blob/master/packages/react-native-codegen/src/generators/modules/GenerateModuleJavaSpec.js
* This commit produces a sample Java code, not the actual codegen output
Changelog: [Internal]
To try this out, run this Gradle task:
```
USE_CODEGEN=1 ./gradlew :ReactAndroid:generateJava
```
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D22917315
fbshipit-source-id: 0b79dba939b73ff1305b4b4fd86ab897c7a48d53
Summary:
This diff creates the Android OSS build system for the module react/config
As part of this diff I also moved the module to react/config folder
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D22877264
fbshipit-source-id: 5b3c42580d2b1d73dc0abb48bcf4ff063b2f581f
Summary:
Hook up onSuccess and onFailure callbacks to LayoutAnimations.
Note that in non-Fabric RN, onSuccess is not known to work in Android. I could not find any uses of onFailure and it's not documented, so for now, it is only called if the setup of the animation fails.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D22889352
fbshipit-source-id: 4306debb350388dd2b7a2cbfe295eb99723988e2
Summary:
This diff removes the fb/xplat_init dependency from fabric onLoad class
This is necessary to make RM compile in OSS
changelog: [Internal] Internal
Reviewed By: RSNara
Differential Revision: D22875531
fbshipit-source-id: cc4cd2af875fe7eadfb3a8f4a9f16acf5fa415d8
Summary:
This diff removes the fb/xplat_init dependency from fabric onLoad class
This is necessary to make fabric compile in OSS
changelog: [Internal] Internal
Reviewed By: RSNara
Differential Revision: D22874850
fbshipit-source-id: 0c61a366e09ab072215ba2fe651f96ef4c2e455a
Summary:
EZ refactor in ReactViewBackgroundDrawable to remove an unnecessary class variable
changelog: [internal] Internal
Reviewed By: RSNara
Differential Revision: D22874851
fbshipit-source-id: 16808809b196cba0dab5c9972359d7786939a7ce
Summary:
Introduced `architecture.gradle` that sets up pluggable build-time codegen steps for Gradle so that:
* Libraries, including core ReactAndroid, can produce the new architecture codegen (NativeModule **Java** specs in this diff) during build time
* Hosting app (e.g. RNTester) can produce its own set of codegen specs separately
**Please note that this is still work in progress, hence app templates have not been updated to use it yet.**
In order to activate this setup, the env variable `USE_CODEGEN=1` must be set. Eventually, this var will be removed from the logic.
With this change, RNTester:
* Will see all the generated specs populated in the Gradle build dir, which should be equivalent to the currently [**checked in version**](https://github.com/facebook/react-native/tree/master/ReactAndroid/src/main/java/com/facebook/fbreact/specs).
* The specs will compile, but **have not been validated** vs the existing NativeModule .java classes through out the core -- that will be the next step
* The specs are under `com.facebook.fbreact.specs.beta` namespace, which will be configurable in the future. `.beta` is added to avoid conflict with the existing files in the repo.
### Is this all we need to enable TurboModule in Android?
No. There are a few more pieces needed:
* C++ codegen output for JNI layer for each NativeModule spec
* The C++ module lookup for TurboModule Manager
* The JNI build setup in Gradle for these C++ output
* Toggle to enable TurboModule system in the entire app
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D22838581
fbshipit-source-id: d972e2fbb37bdbd3354e72b014fc8bb27a33b9ac
Summary:
If `__turboModuleProxy` is called with a second argument, we'll now forward that `jsi::Value` to TurboModuleManager on iOS and Android, so that the TurboModuleManager can eventually use this `jsi::Value` to read data required to perform method invocation on the TurboModule object.
**Note:** This diff is basically a no-op right now.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D22828838
fbshipit-source-id: 19db2adcae6a58b4885fcd11bef23f9d5882bfce
Summary:
Unfortunately, the new codegen doesn't allow us to import types from other files. Therefore, I've inlined the interface specification of NativeAnimatedModule into NativeAnimatedTurboModule.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D22858790
fbshipit-source-id: 759bb960240afaba6b70c2730c3359b7e8c46c83
Summary:
This diff moves fabric C++ code from ReactCommon/fabric to ReactCommon/react/renderer
As part of this diff I also refactored components, codegen and callsites on CatalystApp, FB4A and venice
Script: P137350694
changelog: [internal] internal refactor
Reviewed By: fkgozali
Differential Revision: D22852139
fbshipit-source-id: f85310ba858b6afd81abfd9cbe6d70b28eca7415
Summary:
This instruments the following marker:
- MODULE_CREATE
**Note:** This marker isn't necessary to test the JS TurboModule codegen, since the JS codegen should only affect the C++ portion of the TurboModule infra. However, I implemented this while I was in this area of the code, for completeness.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D22679888
fbshipit-source-id: aa04822bd5a7c889813fcd13ca23c0b7a1d8444a
Summary:
In D17480605 (689233b018), I made all methods with void return types dispatch to the NativeModules thread. This diff makes the same change to methods with promise return types.
**Note:** The changes are disabled for now. I'll add an MC so that we can test this in production in a later diff.
Changelog:
[Android][Fixed] - Make promise NativeModule methods dispatch to NativeModules thread
Reviewed By: PeteTheHeat
Differential Revision: D22489338
fbshipit-source-id: d5b030871f9f7b3f48eb111225516521493cb05e
Summary:
Android's `VibrationModule` uses deprecated `vibrate(long milliseconds)` and `vibrate(long[] pattern, int repeat)` methods. Deprecation notes: [[1]](https://developer.android.com/reference/android/os/Vibrator#vibrate(long)) [[2]](https://developer.android.com/reference/android/os/Vibrator#vibrate(long[],%20int)).
Changes in this pull request use recent `Vibrator` API for devices with API Level >= 26 (since mentioned methods were depreceted in API Level 26).
## 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] [Internal] - Use non-deprecated `Vibrator` API in `VibrationModule`
Pull Request resolved: https://github.com/facebook/react-native/pull/29534
Test Plan: API is the same as before, but it uses recent `Vibrator` API.
Reviewed By: makovkastar
Differential Revision: D22857382
Pulled By: mdvacca
fbshipit-source-id: 6793a7d165fa73d81064865861ed55af2de83d52
Summary:
This diff cleansup unused code on AccessibilityInfoModule class
changelog: [Android][Deprecated] Remove code used by deprecated Android API levels
Reviewed By: JoshuaGross
Differential Revision: D22771912
fbshipit-source-id: f32808fa93f75c10324e8875b85fe4e541b284b8
Summary:
This diff removes code that was used to support android APIs < kitkat
changelog: [Android][Deprecated] Remove calls to Android API < Kitkat
Reviewed By: JoshuaGross
Differential Revision: D22771913
fbshipit-source-id: b9bba9e94fbc8e18889b821050dcd6eace4c202d
Joshua Gross
David Vacca
Ron Edelstein
generatedunixname89002005325676
generatedunixname89002005325674
Ramanpreet Nara
Dulmandakh
Riley Dulin
Valentin Shergin
Andres Suarez
Igor Klemenski
Lukas Müller
Jayme Deffenbaugh
Agastya Darma
Kacie Bawiec
Kevin Gozali
doniwinata0309
Keion Anvaripour
Andrei Shikov
Xiaoyu Yin
Emily Janzer
Tim Yung
Nick Gerleman
Koichi Nagaoka
ajpaulingalls
Lulu Wu
Hank Chen
Alessandro Sisto
Peter Argany
Pasquale Anatriello
Janic Duplessis
Jason Safaiyeh
Oleksandr Melnykov
hy.harry.yu@gmail.com
Mike Vitousek
Joshua Selbo
Samuel Susla
Michael Yoon (LAX)
Ian Childs
Hamid
Shoaib Meenai
Eloy Durán
Betty Ni
Neil Dhar
Sahil Jain
Jiawei Lv
Oleg Lokhvitsky
Anton Bryukhov
