Summary:
This diff uses a new MC to Start Fabric surfaces using layoutMetrics or not.
The motivation is to verify if the new initialization of fabric surfaces is regressing in production
changelog: [Internal] Internal change in fabric
Reviewed By: JoshuaGross
Differential Revision: D21606971
fbshipit-source-id: ed1f6937ffd0f1e6c54e3ebc34595d75b6c5f6e1
Summary:
This diff implements the eager initialization of fabric based on the param created in previous diffs
changelog: [Internal] Internal change in Fabric
Reviewed By: JoshuaGross
Differential Revision: D21574815
fbshipit-source-id: 1dfd2611ce8c8529ce5f6a7a8c48f8bee19be256
Summary:
This diff refactors the initial render of Fabric in order to set the layout metrics as we start the surface.
This prevents to create an additional fabric commit during initial render. Also this migth help fixing T63495589 (I wasn't able to repro T63495589 again when using this diff)
changelog: [Internal][Android] Internal change to reduce the amount of commits during initial render of Fabric
Reviewed By: JoshuaGross
Differential Revision: D21330072
fbshipit-source-id: 758c49b52ea4c12d5623b7c7d68c7318f4a6cd83
Summary:
This is the codemod portion of the parent diff.
I modified all call-sites to `ReactContext.getNativeModule` to do a null check on the returned NativeModule.
Changelog:
[Android][Fixed] - Check if NativeModules returned from CatalystInstanceImpl.getNativeModule are null before using them.
Reviewed By: JoshuaGross
Differential Revision: D21272028
fbshipit-source-id: 6bd16c6bf30605f2dfdf4c481352063712965342
Summary:
Marketplace eagerly initializes a few NativeModules. These NativeModules are TurboModule compatible, and the device/user is in the TurboModule test. So these NativeModuels should be returned from the TurboModule system. However, for some reason, we end up doing a lookup on the `NativeModuleRegistry` for these NativeModules.
This means that either:
1. The TurboModuleManager isn't attached to the CatalystInstance
2. The TurboModuleManager returned null from getModule.
These logs will help us get to the bottom of what's going on.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D20260150
fbshipit-source-id: bb554ead412ad3b0fa7502b77f575365608ebc98
Summary:
Add debug logs for T62192299, which will hopefully tell us why RN is being destroyed in otherwise useless logs.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19866793
fbshipit-source-id: 6656c305c8ef567335ea7fe82e4e1c68092a49d2
Summary:
This diff refactors the usages of UIManagerHelper.getUIManager() to make sure we always consider null objects.
Some of the callsites were throwing a NullPointerExcetpion, now they throw a more explicit exception.
changelog: [internal]
Reviewed By: makovkastar
Differential Revision: D19383064
fbshipit-source-id: 1806a37528e80cab1c8fdff5eb631aaf47bde819
Summary:
I stumbled on this comment where the task was closed
Changelog: [Internal]
Reviewed By: lunaleaps, RSNara
Differential Revision: D18933260
fbshipit-source-id: 8d35e0fa19dc9aec7b811131318858c27c34accd
Summary:
This diff adds a NativeLogBox module implementation on Android to manage rendering LogBox the way we render RedBox, except rendering a React Native component instead of a native view.
The strategy here is:
- initialize: will create a React rootview and render it.
- show: will add the rootview to a dialog and display the dialog.
- hide: will remove the rootview from it's parent, dismiss the dialog, and release the reference to the activity to prevent leaks.
Most of this is copied from the way RedBox works, the difference here is that we eagerly initialize the rootview with the `initialize` function so that it's warm by the time the dialog needs to render.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18768517
fbshipit-source-id: 2510d6c186ccf73153ef9372c736c9e0c71bbc7d
Summary:
The TurboModuleManagerDelegate now supports a `getEagerInitModuleNames()` method, which is supposed to return a `java.util.List` containing the names of all NativeModules that require eager initialization. The NativeModuels are created when the `TurboModuleManager` is created. This happens inside `ReactInstanceManager.createReactContext` slightly after the NativeModuleRegistry is created, which is when our legacy NativeModules are eagerly initialized.
All NativeModules declared in `TurboReactPackages` that are wired into the `TurboModules` infra via `ReactPackageTurboModuleManagerDelegate` can use the `ReactModule(needsEagerInit = true)` annotation. Our build pipeline should correctly process the annotation into a `ModuleInfo`, and `ReactPackageTurboModuleManagerDelegate` should correctly forward the eagerly initialized module names to TurboModuleManager.
Changelog:
[Android][Added] - Implement TurboModule eager initialization support
Reviewed By: mdvacca
Differential Revision: D18819552
fbshipit-source-id: b2009a3b8f4e064362d2abeb5281637962531678
Summary:
`getUIManagerX(...)` can return null now. Guard in a few places that use it or add comments.
Changelog: [Internal]
Reviewed By: alexeylang
Differential Revision: D18351197
fbshipit-source-id: f077835468a75d1af24cfb4210989ba875ff9086
Summary:
We no longer need to gate by OS version since we want to allow in-app theming. This diff ensures that we are passing in the updated system context to retrieve the correct app theme.
Changelog:
[Android] Enable AppearanceModule for all OS versions
Reviewed By: mdvacca
Differential Revision: D18224915
fbshipit-source-id: 42d5db8497d8bead32c49e3e2a25d4ba779e2b33
Summary:
See T55861104. In rare cases if `removeReactInstanceEventListener` is called right after (like, a small number of CPU instructions later, on a different thread) we allocate the `listeners` array with a certain size, then we could have one or more `null` listeners in the array, which is what we've been seeing in prod, at very low volumes, for several years. Without solving the root of the race condition we can just add a null check here.
Maybe it's also possible that if `addReactInstanceEventListener` is called on another thread in a racey way, that the size will be incremented on the array before we can access the additional member. That seems crazy, but maybe.
While this has been firing for multiple years it seems like a more recent change caused a regression. This diff doesn't address that and only resolves the crash.
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D18192801
fbshipit-source-id: c1000cfcdf6f251b03061d1386eabb9f0617a7d3
Summary:
In previous diffs I migrated many (all?) NativeModules in FB and open-source to check for `hasActiveCatalystInstance` before calling `getJSModule`. We log SoftExceptions in those cases to find more potential race condition and lifecycle bugs without crashing.
In this diff, I migrate all the non-NativeModule callsites that I could find.
Previous diffs: see D18032458, D18035359, D18032788, D18092136, D18092137, D18112989, D18134400
Changelog: [Internal]
Reviewed By: mdvacca, mmmulani
Differential Revision: D18134694
fbshipit-source-id: 4729abfb84280b634463b1cd9b4dd808f310b6e7
Summary:
In `tearDownReactContext`, `reactContext.destroy()` sets `mCatalystInstance` to null. We cannot call `reactContext.getCatalystInstance()` after that without hitting an assertion. Change ordering so that doesn't happen in reload or teardown.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D18041279
fbshipit-source-id: 22658dc506b76cf58aee1008841abacfe9410c9d
Summary:
This PR solves bug https://github.com/facebook/react-native/issues/26552 for Android. Allows an app to receive url events through Linking from NFC tags
## Changelog
[Android] [Fixed] - This branch checks also for `ACTION_NDEF_DISCOVERED` intent matches to send the url events
Pull Request resolved: https://github.com/facebook/react-native/pull/26553
Test Plan: Tested the code multiple times with both NFC tags and normal links
Differential Revision: D17589654
Pulled By: cpojer
fbshipit-source-id: 55e854e765a84da5e22ec2cc51d0fe0972254175
Summary: Same as prior diff, but Android.
Reviewed By: JoshuaGross
Differential Revision: D17005308
fbshipit-source-id: 1ac815a232dceaf918e14b045e04aed53a00ae47
Summary:
This change fixes the issue "[ReactInstanceManagerBuilder.build fails unless SoLoader.init has been called](https://github.com/facebook/react-native/issues/26342)" on Android.
The `ReactInstanceManager` constructor calls `initializeSoLoaderIfNecessary`, so the intent is clearly that things should work without an explicit call to `SoLoader.init` on the part of the application.
However, with the introduction of Hermes, we have `ReactInstanceManagerBuilder.getDefaultJSExecutorFactory`, which gets called before the `ReactInstanceManager` constructor. It attempts this:
SoLoader.loadLibrary("jscexecutor");
This fails with the following stack trace:
java.lang.RuntimeException: Unable to start activity ComponentInfo{com.facebook.react.uiapp/com.facebook.react.uiapp.RNTesterActivity}: java.lang.RuntimeException: SoLoader.init() not yet called
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2957)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3032)
at android.app.ActivityThread.-wrap11(Unknown Source:0)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1696)
at android.os.Handler.dispatchMessage(Handler.java:105)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6944)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:327)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1374)
Caused by: java.lang.RuntimeException: SoLoader.init() not yet called
at com.facebook.soloader.SoLoader.assertInitialized(SoLoader.java:781)
at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:505)
at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:484)
at com.facebook.react.ReactInstanceManagerBuilder.getDefaultJSExecutorFactory(ReactInstanceManagerBuilder.java:291)
at com.facebook.react.ReactInstanceManagerBuilder.build(ReactInstanceManagerBuilder.java:266)
at com.facebook.react.ReactNativeHost.createReactInstanceManager(ReactNativeHost.java:86)
at com.facebook.react.ReactNativeHost.getReactInstanceManager(ReactNativeHost.java:38)
at com.facebook.react.ReactDelegate.loadApp(ReactDelegate.java:103)
at com.facebook.react.ReactActivityDelegate.loadApp(ReactActivityDelegate.java:83)
at com.facebook.react.ReactActivityDelegate.onCreate(ReactActivityDelegate.java:78)
at com.facebook.react.uiapp.RNTesterActivity$RNTesterActivityDelegate.onCreate(RNTesterActivity.java:40)
at com.facebook.react.ReactActivity.onCreate(ReactActivity.java:44)
at android.app.Activity.performCreate(Activity.java:7183)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1220)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2910)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3032)
at android.app.ActivityThread.-wrap11(Unknown Source:0)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1696)
at android.os.Handler.dispatchMessage(Handler.java:105)
at android.os.Looper.loop(Looper.java:164)
at android.app.ActivityThread.main(ActivityThread.java:6944)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:327)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1374)
## Changelog
[Android] [Fixed] - Don't crash ReactInstanceManagerBuilder.build even if SoLoader has not been explicitly initialized
Pull Request resolved: https://github.com/facebook/react-native/pull/26343
Test Plan:
To demonstrate the defect, remove the call to `SoLoader.init` from `RNTester.onCreate` and run the app.
To demonstrate the fix, apply this PR, which does in fact also remove the call to `SoLoader.init`
Differential Revision: D17223701
Pulled By: mdvacca
fbshipit-source-id: c508ab52bd3fefe8a946ebab7b2906a5d8c21e0f
Summary:
Android implementation of the Appearance native module. Exposes the user's preferred color scheme: "dark" for Night theme ON, "light" for Night theme OFF.
Emits a `appearanceChanged` event when the current uiMode configuration changes.
To make your app handle Night mode changes, make sure to do the following:
* Declare your Activity can handle uiMode configuration changes (https://developer.android.com/preview/features/darktheme#java):
```
android:configChanges="uiMode"
```
* Make sure to pass the configuration changed activity lifecycle callback from your ReactActivity:
```
Override
protected void onConfigurationChanged(Configuration newConfig) {
super.onConfigurationChanged();
if (mReactInstanceManager != null) {
mReactInstanceManager.onConfigurationChanged(newConfig);
}
}
```
### RNTester
Adds the AppearanceExample to RNTester on Android.
Changelog:
[Android][Added] - New Appearance module exposes the user's current Night theme preference
Reviewed By: makovkastar
Differential Revision: D16942161
fbshipit-source-id: d24a8ff800a1c5f70f4efdec6891396c2078067e
Summary: This was an experiment to patch individual deltas in development instead of reloading the whole JS bundle. With improvements such as Fast Refresh that reduces the need for reloads and bundle splitting that reduces the number of modules and memory by 10x, we won't be needing this complex optimization that we never properly made work. This diff removes that code and I will be removing the JS side of things in Metro in a follow-up diff.
Reviewed By: fkgozali
Differential Revision: D16832709
fbshipit-source-id: 46596a3126d52d7d74f4b9ffc9a6ee9d82ec9522
Summary:
`createReactContextInBackground` must be run on the UI Thread, so we update the DI annotation from `DefaultIdleExecutor` to `ForUiThread` so that happens.
Unclear why Infer didn't flag this. Asked [here](https://fb.workplace.com/groups/572076376174315/permalink/2661423100572955/).
Also adds an additional thread assert before setting `mHasStartedCreatingInitialContext = true` so that if a similar bug happens in the future, RN won't be completely hosed.
Reviewed By: mdvacca
Differential Revision: D16574901
fbshipit-source-id: 02ba63979904e9df9ef6d782aa7379cb44702508
Summary: Having a cached JS bundle being loaded instead of loading it from Metro can cause recent changes made with Fast Refresh not to be picked up after an app is killed and started again. This diff makes a change so that we always download the bundle from Metro if it's running and only if it's not running we check if there is a cached recent bundle.
Reviewed By: gaearon, davidaurelio
Differential Revision: D16380243
fbshipit-source-id: b2842f718e0c21a3f4ca5ebeb3c2bae1df87a6e1
Summary:
This diff migrates the usages Nullable and NonNull annotations to AndroidX instead of javax.
The purpose of this change is to bring consistency in the annotations used by the core of RN
Reviewed By: makovkastar
Differential Revision: D16054504
fbshipit-source-id: 21d888854da088d2a14615a90d4dc058e5286b91
Summary:
This diff formats the Java class files inside xplat/js/react-native-github. Since google-java-format was enabled in D16071401 we want to codemode the existing code so that users don't have to deal with formatter lint noise at diff-time.
```arc f --paths-cmd 'hg files -I "**/*.java"'```
drop-conflicts
Reviewed By: cpojer
Differential Revision: D16071725
fbshipit-source-id: fc6e3852e45742c109f0c5ac4065d64201c74204
Summary:
NativeModuleRegistry is initialized in `ReactInstanceManager.createReactContext` and passed to the CatalystInstanceImpl's constructor. After we create the CatalystInstanceImpl, we then run the JS by calling `CatalystInstance.runJSBundle`. This makes it so that NativeModules are available by the time we run JS code that could require them.
With TurboModules, however, the JS startes executing first, and then we initialize TurboModuleManager. This is bad because by the time JS calls `TurboModuleRegistry.getEnforcing`, TurboModuleManager may yet not be ready. So, `TurboModuleRegistry.get` will just return null for all TurboModules. This will cause TurboModuleRegistry to raise errors. I suspect this is what's causing all RN surfaces to crash with "Unexpected error occurred" in prod builds of the app for users that are in the TurboModules FB4A test. But even if it doesn't fix the error, I think this is a better way to initialize TurboModules.
Reviewed By: ejanzer
Differential Revision: D16064364
fbshipit-source-id: 6053c251ace1668a331110d0cc64aba9d41a4837
Summary:
TurboModuleManager was initialized in `ReactInstanceManager.setupReactContext`, which is executed on the NativeModule thread after we call `ReactInstanceManager.createReactContext` on a new thread. `NativeModuleRegistry` is initialized in `ReactInstanceManager.createReactContext`, so if someone requests a TurboModule after `ReactInstanceManager.createReactContext` is called and before `ReactInstanceManager.setupReactContext` fully finishes executing, that TurboModule won't be found.
This diff moves TurboModuleManager initialization into `ReactInstanceManager.createReactContext`
Reviewed By: fkgozali
Differential Revision: D15978486
fbshipit-source-id: 734e83eced414e545fe275e9a124d0df35204c40
Summary: Some TM lookup from native will fail assertion if done too early, because TM Manager is not initialized yet.
Reviewed By: mdvacca
Differential Revision: D15872776
fbshipit-source-id: 7616c1424816f73a45aa1d9723e7807ae10392a7
Summary:
## Description
To initialize `TurboModuleManager`, we first need to wait until `ReactContext` is initialized. Then, we get the `TurboModuleManager` instance and assign it as the `TurboModuleRegistry` of `CatalystInstanceImpl`. This allows `CatalystInstanceImpl` to return TurboModules from its `getNativeModule` method. In `FbReactFragment`, we also wait until the `ReactContext` is initialized before then eagerly initialize a bunch of NativeModules. All this waiting is done by adding instances of `ReactInstanceEventListener` to `ReactInstanceManager`'s `mReactInstanceEventListeners` synchronized Set. When the `ReactContext` is finally initialized, we loop over this set and invoke all the listeners.
## Problem
We want to initialize `TurboModuleManager` and set it as the `TurboModuleRegistry` of `CatalystInstanceImpl` before we start eagerly initializing our NativeModules. Why? Because otherwise TurboModules that need to be eagerly initialized won't be. The fact that we're using a Set to manage the `ReactInstanceEventListener`s means that our listeners can be invoked in any order. This is bad because we can start to eagerly initialize NativeModules before we've had the chance to assign `TurboModuleManager` as the `TurboModuleRegistry` of `CatalystInstanceImpl`. In development, this race was leading to the following crash:
```
06-05 11:11:02.020 10461 10617 E AndroidRuntime: FATAL EXCEPTION: CombinedTP8
06-05 11:11:02.020 10461 10617 E AndroidRuntime: Process: com.facebook.wakizashi, PID: 10461
06-05 11:11:02.020 10461 10617 E AndroidRuntime: java.lang.AssertionError: Could not find module with name PrimedStorage
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.infer.annotation.Assertions.assertNotNull(Assertions.java:35)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.react.bridge.NativeModuleRegistry.getModule(NativeModuleRegistry.java:147)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.react.bridge.CatalystInstanceImpl.getNativeModule(CatalystInstanceImpl.java:444)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.fbreact.fragment.FbReactFragment$4$1.run(FbReactFragment.java:418)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:457)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.common.executors.WrappingExecutorService$1.run(WrappingExecutorService.java:82)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.common.combinedthreadpool.queue.CombinedSimpleTask.run(CombinedSimpleTask.java:81)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.common.combinedthreadpool.queue.CombinedLifetimeThreadFactory$1.run(CombinedLifetimeThreadFactory.java:40)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.common.executors.NamedThreadFactory$1.run(NamedThreadFactory.java:53)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at java.lang.Thread.run(Thread.java:764)
```
## Diagnosing the crash
It looks like `NativeModuleRegistry.getModule` was throwing an error because `PrimedStorage` was null. `PrimedStorage` was turned into a TurboModule, so of course it wouldn't be in the `NativeModuleRegistry`. It should be in the `TurboModuleRegistry`. So, I placed an assertion in `CatalystInstanceImpl`:
```
Override
public NativeModule getNativeModule(String moduleName) {
Assertions.assertNotNull(mTurboModuleRegistry, "TurboModuleRegsitry is not null");
if (mTurboModuleRegistry != null) {
TurboModule turboModule = mTurboModuleRegistry.getModule(moduleName);
if (turboModule != null) {
return (NativeModule)turboModule;
}
}
return mNativeModuleRegistry.getModule(moduleName);
}
```
Sure enough, this assertion started tripping, which meant that `mTurboModuleRegistry` was null. From this information, I hypothesized that we started to eagerly initialize our NativeModules before `TurboModuleManager` was initialized. To verify this hypothesis, I added logging statements in each `ReactInstanceEventListener`: P65477469. `eagerInitializeReactNativeComponents (START)` documents when we start to eagerly intialize our NativeModules. `getReactInstanceManager (START)` documents when we start to initialize `TurboModuleManager` inside `FbReactInstanceHolder.getReactInstanceManager` method. Sure enough, when the program finally crashed, I saw in our logs that we started eagerly initializing our NativeModules before we initialized the TurboModuleManager:
```
06-05 11:11:01.951 10461 10617 V Ramanpreet: eagerInitializeReactNativeComponents (START): 1559758261951
06-05 11:11:01.956 10461 10461 V Ramanpreet: getReactInstanceManager (START): 1559758261956
06-05 11:11:01.958 10461 10461 D SoLoader: About to load: libturbomodulejsijni.so
06-05 11:11:01.960 10461 10461 D SoLoader: libturbomodulejsijni.so not found on /data/data/com.facebook.wakizashi/lib-zstd
06-05 11:11:01.960 10461 10461 D SoLoader: libturbomodulejsijni.so not found on /data/data/com.facebook.wakizashi/lib-xzs
06-05 11:11:01.960 10461 10461 D SoLoader: libturbomodulejsijni.so not found on /data/data/com.facebook.wakizashi/lib-assets
06-05 11:11:01.961 10461 10461 D SoLoader: libturbomodulejsijni.so found on /data/data/com.facebook.wakizashi/lib-main
06-05 11:11:01.965 10461 10461 D SoLoader: Loading lib dependencies: [libfb.so, libfbjni.so, libglog.so, libdouble-conversion.so, libxplat_jsi_jsiAndroid.so, libxplat_jsi_JSIDynamicAndroid.so, libfbsystrace.so, libmemalign16.so, libgnustl_shared.so, libm.so, libc.so]
06-05 11:11:01.999 10461 10769 D SoLoader: init exiting
06-05 11:11:01.999 10461 10461 D SoLoader: Loaded: libturbomodulejsijni.so
06-05 11:11:01.999 10461 10461 D SoLoader: About to load: libfb4aturbomodulemanagerdelegate.so
06-05 11:11:01.999 10461 10769 W fb4a.ImagePipelineFactory: ImagePipelineFactory has already been initialized! `ImagePipelineFactory.initialize(...)` should only be called once to avoid unexpected behavior.
06-05 11:11:02.002 10461 10461 D SoLoader: libfb4aturbomodulemanagerdelegate.so not found on /data/data/com.facebook.wakizashi/lib-zstd
06-05 11:11:02.002 10461 10461 D SoLoader: libfb4aturbomodulemanagerdelegate.so not found on /data/data/com.facebook.wakizashi/lib-xzs
06-05 11:11:02.002 10461 10461 D SoLoader: libfb4aturbomodulemanagerdelegate.so not found on /data/data/com.facebook.wakizashi/lib-assets
06-05 11:11:02.004 10461 10461 D SoLoader: libfb4aturbomodulemanagerdelegate.so found on /data/data/com.facebook.wakizashi/lib-main
06-05 11:11:02.007 10461 10461 D SoLoader: Loading lib dependencies: [libturbomodulejsijni.so, libfb.so, libfbjni.so, libxplat_jsi_jsiAndroid.so, libxplat_jsi_JSIDynamicAndroid.so, libreactnativejni.so, libmemalign16.so, libgnustl_shared.so, libc.so]
06-05 11:11:02.020 10461 10617 E AndroidRuntime: FATAL EXCEPTION: CombinedTP8
06-05 11:11:02.020 10461 10617 E AndroidRuntime: Process: com.facebook.wakizashi, PID: 10461
06-05 11:11:02.020 10461 10617 E AndroidRuntime: java.lang.AssertionError: Could not find module with name PrimedStorage
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.infer.annotation.Assertions.assertNotNull(Assertions.java:35)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.react.bridge.NativeModuleRegistry.getModule(NativeModuleRegistry.java:147)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.react.bridge.CatalystInstanceImpl.getNativeModule(CatalystInstanceImpl.java:444)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.fbreact.fragment.FbReactFragment$4$1.run(FbReactFragment.java:418)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:457)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.common.executors.WrappingExecutorService$1.run(WrappingExecutorService.java:82)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.common.combinedthreadpool.queue.CombinedSimpleTask.run(CombinedSimpleTask.java:81)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.common.combinedthreadpool.queue.CombinedLifetimeThreadFactory$1.run(CombinedLifetimeThreadFactory.java:40)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at com.facebook.common.executors.NamedThreadFactory$1.run(NamedThreadFactory.java:53)
06-05 11:11:02.020 10461 10617 E AndroidRuntime: at java.lang.Thread.run(Thread.java:764)
06-05 11:11:02.038 1647 1667 I WifiService: requestActivityInfo uid=1000
06-05 11:11:02.038 1647 1667 I WifiService: reportActivityInfo uid=1000
06-05 11:11:02.038 1647 1667 I WifiService: getSupportedFeatures uid=1000
06-05 11:11:02.044 1647 1667 E BluetoothAdapter: Bluetooth binder is null
06-05 11:11:02.049 1647 1667 E KernelCpuSpeedReader: Failed to read cpu-freq: /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state (No such file or directory)
06-05 11:11:02.050 1647 1667 E BatteryExternalStatsWorker: modem info is invalid: ModemActivityInfo{ mTimestamp=0 mSleepTimeMs=0 mIdleTimeMs=0 mTxTimeMs[]=[0, 0, 0, 0, 0] mRxTimeMs=0 mEnergyUsed=0}
06-05 11:11:02.057 2147 10435 W ctxmgr : [AclManager]No 2 for (accnt=account#-517948760#, com.google.android.gms(10013):IndoorOutdoorProducer, vrsn=13280000, 0, 3pPkg = null , 3pMdlId = null , pid = 2147). Was: 3 for 57, account#-517948760#
06-05 11:11:02.077 10461 10461 D SoLoader: Loaded: libfb4aturbomodulemanagerdelegate.so
06-05 11:11:02.079 10461 10461 V Ramanpreet: getReactInstanceManager (END): 1559758262079
```
Reviewed By: mdvacca
Differential Revision: D15676746
fbshipit-source-id: a7ac02d868abf31c5d664b10f70b6db247f388f5
Summary:
Every call site is either already using `createReactContextInBackground` correctly or guarding the invocation using `hasStartedCreatingInitialContext`. This is an unnecessary and overly complex dance that can be simplified.
This revision simplifies the use of `createReactContextInBackground` by integrating the check. This is not a breaking change.
Reviewed By: zackargyle, mdvacca
Differential Revision: D15566632
fbshipit-source-id: 7b50285c9ac6776d1297d2c9c53dff208851b722
Summary:
We currently have two different codepaths for actually rendering a surface with Fabric on iOS and Android: on iOS we use Fabric's `UIManagerBinding.startSurface` to call `AppRegistry.runApplication`, but on Android we don't; instead we use the same codepath as paper, calling `ReactRootView.runApplication`.
This diff does a few different things:
1. Unify iOS and Android by removing the `#ifndef` for Android so that we call `startSurface` for both
2. Pass through the JS module name on Android so that this actually works (it currently passes in an empty string)
3. Remove the call to `ReactRootView.runApplication` for Fabric so that we don't end up doing this twice
4. Copy over some logic that we need from `ReactRootView.runApplication` (make sure that root layout specs get updated, and that content appeared gets logged)
Reviewed By: mdvacca
Differential Revision: D15501666
fbshipit-source-id: 5c96c8cf036261cb99729b1dbdff0f7c09a32d76
Summary:
## Summary
People use `ReactPackage` instances to create NativeModules. To make the migration from NativeModule to TurboModule easy, I'm introducing a `TurboModuleManagerDelegate` that understands `ReactPackage`s, and uses them to lookup and create the Java TurboModule objects. This way, we don't have to change the way we declare NativeModules for the migration.
## TurboModule registration
Each application should have its own subclass of `ReactPackageTurboModuleManagerDelegate`. This subclass is a hybrid class with a C++ and a Java part. The Java part can (and probably should) do nothing (for now). The C++ part has to implement the `moduleName -> jni::HostObject` and `moduleName, javaInstance -> jni::HostObject` functions for all TurboModules in the application.
**Use Case: Migrating a NativeModule to TurboModule system**
1. Make the Java NativeModule extend `TurboModule`. (The reason why this doesn't happen automatically is probably because we haven't changed the Java codegen yet).
2. Modify the `moduleName -> jni::HostObject` or `moduleName, javaInstance -> jni::HostObject` functions to return the `TurboModule`.
**Use Case: Adding a new TurboModule**
1. Add the TurboModule to a `ReactPackage` in the application.
2. Modify the `moduleName -> jni::HostObject` or `moduleName, javaInstance -> jni::HostObject` functions to return the TurboModule `jsi::HostObject`.
**Note:** It's also possible to declare TurboModules by overriding the `getModule(String moduleName)` function of `ReactPackageTurboModuleManagerDelegate`. It's not a good idea, because it'll make switching between the NativeModule/TurboModule system difficult.
Reviewed By: mdvacca
Differential Revision: D15209129
fbshipit-source-id: 4b0a303595145be9b19d6f4934f956b91990f859
Summary: Remove dependency on ReactRootView in ReactInstanceManager by creating a rough interface (ReactRoot) so that either a Surface or ReactRootView can be attached to ReactInstanceManager.
Reviewed By: ejanzer, mdvacca
Differential Revision: D14158890
fbshipit-source-id: b7ab4654b1e0ef8343230a3c15023653a7f23a4b
Summary:
This diff migrates RN to AndroidX.
As part of this diff I disabled few tests in RNAndroid OSS that will be re-enabled this week. As part of the refactor of BUCK files in OSS
Reviewed By: shergin
Differential Revision: D14200097
fbshipit-source-id: 932fcae251d1553e672acd67ecd0e703dcb364aa
Summary: Flesh out how surface will be used with a flag in ReactRootView
Reviewed By: mdvacca
Differential Revision: D14112897
fbshipit-source-id: adf6078048dbf83452d3523f0530a4d6dca7b3e8
Summary: Due to the way (initial) surface implementation plays with ReactRootView (RRV), the react tag from the UIManagerModule is now set on the surface container view rather than on RRV as it was historically done. RRV still caches the react tag but just doesn't use it as an id on the view so `RRV.getViewId()` no longer equals `RRV.getReactTag()`.
Reviewed By: mdvacca
Differential Revision: D14110104
fbshipit-source-id: 6dbcc41c85fd7a6c32c7250f68f4a84bed4e075a
Summary:
Yet another issue with mAttachedRootViews. Every time attachRootView is called, the root view's id is reset to NO_ID. However, there can be a case where the react context has not initialized yet, so we delay attaching the root view to the instance manager until setupReactContext. If attachRootView was called a second time before the react context has finished initializing, we end up in a situation where we try to attach the same root view twice
I'm planning to remove mAttachedRootViews all together in a future diff, but for now let's avoid these crashes.
Reviewed By: mmmulani
Differential Revision: D12835167
fbshipit-source-id: ebef3fadc5f9f467eebb3b5644c685acc5ea10bf
Summary:
When RN starts up, it lowers the default priority of the JS thread. This diff sets a point to see when the JS thread priority is lowered.
In subsequent diffs, we will be able to use this marker to play around with bumping the priority of the JS thread till TTI is done.
Reviewed By: alexeylang
Differential Revision: D8965457
fbshipit-source-id: 87cb1e3d3b370af183f388c411fd9a87a6cba250
Summary:
D12829677 introduced a deadlock where onHostResume holds the lock on `moveToResumedLifecycleState()` then waits for the `mReactContext` lock, but at the same time setupReactContext holds the `mReactContext` lock and waits for `moveToResumedLifecycleState()` https://our.intern.facebook.com/intern/everpaste/?handle=GAgXFgLQH1ZlQikBAMQzo2LZ6h9TbiAxAAAz. The purpose of the previous diff was to make sure that detachRootoView and
setupReactContext did not interfere with each other, and implemented that by blocking on mReactContext. Since this overloads the usage of mReactContext, let's use a different lock `mAttachedRootViews` to implement this behavior instead
Reviewed By: mdvacca
Differential Revision: D12989555
fbshipit-source-id: c12e5fd9c5fa4c2037167e9400dc0c1578e38959
Summary: This diff fixes exception handling for Mounting of views, as soon as there is an exception we stop the mounting of views because from that point the UI View tree is going to be inconsistent with the ReactShadow tree from C++. We also stop the mounting of views when the host is paused, this allows us to not keep mounting views
Reviewed By: shergin
Differential Revision: D10510334
fbshipit-source-id: b0d3eba580ff92d8b8400244ec9d7c266db42ff9
Summary:
It works great on iOS, and mostly works on Android, and is now OTA'able as part of the screen config! Haven't done template view yet. One remaining issue:
Layout is borked on Android. I'm guessing the issue has to do with the timing of setting the constraints in `updateRootLayoutSpecs` and calling `mBinding.startSurface` which actually builds the shadow tree. If I try to call `updateRootLayoutSpecs` earlier, it just crashes immediately. Here's the layout it spits out, which clearly has -440 for the x of 420006, which is the RCTText component, causing it to get cut off on the left of the screen:
```
updateLayoutMountItem for reactTag: 420006 x: -440, y: -13, width: 931, height: 78
updateLayoutMountItem for reactTag: 420010 x: 26, y: 79, width: 0, height: 1651
updateLayoutMountItem for reactTag: 420012 x: 0, y: 26, width: 0, height: 158
updateLayoutMountItem for reactTag: 420016 x: 0, y: 210, width: 454, height: 454
updateLayoutMountItem for reactTag: 420018 x: 454, y: 210, width: 455, height: 454
updateLayoutMountItem for reactTag: 420022 x: 0, y: 690, width: 454, height: 454
updateLayoutMountItem for reactTag: 420024 x: 454, y: 690, width: 455, height: 454
updateLayoutMountItem for reactTag: 420028 x: 0, y: 1171, width: 454, height: 454
updateLayoutMountItem for reactTag: 420030 x: 454, y: 1171, width: 455, height: 454
updateLayoutMountItem for reactTag: 420032 x: 0, y: 1651, width: 0, height: 0
```
Reviewed By: mdvacca
Differential Revision: D12813192
fbshipit-source-id: 450d646af4883ff25184141721351da67b091b7c
Summary:
There are multiple reports of the NativeViewHierarchyManager trying to remove a root view with id -1. This can occur because of a race condition caused by calls to startReactApplication + unmountReactApplication.
We unfortunately overload overload the id field of the ReactRootView to store its react tag. This id is typically set when the view is attached to the react instance, and reset to NO_ID right before an attach occurs or when the react context is tearing down. If the react context has already been initialized, attaching the root view is synchronous and the id is set immediately. If the context has not been initialized, we save the root view in a mAttachedRootViews list and wait until setupReactContext (where the context is created) to finish attaching the root views.
There were two issues:
1) In setupReactContext, synchronizing on mReactContextLock is not enough to ensure that the root views in mAttachedRootViews have been initialized already
2) In detachRootView, removing the root view from mAttachedRootViews immediately will cause mAttachedRootViews to be out of sync when it is accessed by the time it is accessed in setupReactContext
To address these, the mReactContextLock will synchronize both the creation of the react context AND the initialization of the root views and detachRootView will synchronize on the mReactContextLock before mutating the mAttachedRootViews list.
Reviewed By: mmmulani
Differential Revision: D12829677
fbshipit-source-id: 3f3b0669e5be2b570c9d534503d04e5d0816196b
Summary: UIImplementationProvider was removed as part of D8650376, this was a breaking change that caused problems in OSS. This diff introduces the concept of a deprecated UIImplementationProvider again to allow OSS community to upgrade to latest version of RN.
Reviewed By: achen1
Differential Revision: D10456317
fbshipit-source-id: 6817629524f927dfcb5ebc054dbfd983877b7606
Summary: This diff avoids deleting all the views of ReactRootView when the ReactContext is destroyed (ONLY FOR FABRIC). In Fabric these views are removed and deleted by the framework when the ReactShadowNode is destroyed.
Reviewed By: shergin
Differential Revision: D10319737
fbshipit-source-id: 2e2d2599006cd8205e0153c18cd75383387ce1df
David Vacca
Ramanpreet Nara
Joshua Gross
Rick Hanlon
Elisa Lou
Andres Suarez
Andrea Cimitan
Petter Hesselberg
Héctor Ramos
Christoph Nakazawa
Spencer Ahrens
Oleksandr Melnykov
Ram N
Kevin Gozali
Krzysztof Borowy
Tim Yung
Emily Janzer
Luna Wei
Andrew Chen (Eng)