Summary:
D14014668 introduced support for nesting views within Text on Android. Part of the implementation involved accessing the UIManagerModule from ReactTextView through context. This doesn't work in bridgeless RN because we have no UIManagerModule, and the ReactContext has no Catalyst instance. Trying to access the Catalyst instance from ReactContext throws an exception if it doesn't exist, so i'm just adding a simple check here to make sure the instance exists before proceeding.
This means that this feature won't work in bridgeless mode, but that's ok for now - eventually we want to change the way this works so that it doesn't rely on accessing views in Java, which is potentially unsafe (there's nothing to stop you from mutating the views, and cpp/js would never know about it).
Reviewed By: mdvacca
Differential Revision: D15703100
fbshipit-source-id: 0448d55b8345fc707a25210a505cb6ac520c708a
Summary:
These changes were originally landed in D15327683. Unfortunately, I had to back these out because they revelaled problems with our TurboModules infra. Those problems have since been fixed, so I think it's safe for us to re-land these changes.
Please refer to D15327683 for a description.
Differential Revision: D15739355
fbshipit-source-id: 69bb3cec0731ba325f60c6c8459426546c79b54d
Summary:
## Description
CompositeReactPackage will now eagerly initialize all NativeModules inside the TurboReactPackages. Before it would just crash the program because calling `createNativeModules()` on the TurboReactPackage instance. Longer term, we should make CompositeReactPackage a TurboReactPackage.
## Why am I making this change?
I made MainReactPackage into a TurboReactPackge. But ExpressWifiTechnician uses MainReactPackage to create a CompositeReactPackage:
**java/com/expresswifi/technician/MainActivity.java**
```
protected ReactPackage getPackage() {
ReactInstanceManager reactInstanceManager = getReactInstanceManager();
Nullable DevSupportManager devSupportManager = null;
if (reactInstanceManager != null) {
devSupportManager = reactInstanceManager.getDevSupportManager();
}
return new CompositeReactPackage(
super.getPackage(),
mXWFTechnicianReactPackage,
new RNFusedLocationPackage(),
mXWFTechnicialMobileConfigPackageProvider.get(devSupportManager));
}
```
**java/com/facebook/catalyst/shell/MainReactActivity.java**
```
public abstract class MainReactActivity extends AbstractReactActivity {
protected ReactPackage getPackage() {
return new MainReactPackage();
}
}
```
Reviewed By: fkgozali
Differential Revision: D15738677
fbshipit-source-id: 3220dfe6434de56f2917c77fb21acef4cfc79278
Summary: Removes `unsetOwner` from Yoga. This was temporarily for patching a crash.
Reviewed By: colriot
Differential Revision: D15737613
fbshipit-source-id: 8ab93ecf7ffb913df6207fe5db47a8cc93eded2c
Summary:
Scrolling improvements in ReactAndroid:
1.
Issue: With current ReactHorizontalScrollView behavior, it treats all views as focusable, regardless of if they are in view or not. This is fine for non-paged horizontal scroll view, but when paged this allows focus on elements that are not within the current page. Combined with logic to scroll to the focused view, this breaks the paging for ReactHorizontalScrollView.
Fix: limit the focusable elements to only elements that are currently in view when ReactHorizontalScrollView has paging enabled
2.
Issue: When keyboard is attached and user tries to navigate through Tab key, Scroll views do not scroll to the focused child.
Since ReactScrollView handles layout changes on JS side, it does not call super.onlayout due to which mIsLayoutDirty flag in android ScrollView remains true and prevents scrolling to child when requestChildFocus is called.
Fix: To fix the focus navigation, we are overriding requestChildFocus method in ReactScrollView. We are not checking any dirty layout flag and scrolling to child directly. This will fix focus navigation issue for KeyEvents which are not handled by android's ScrollView, for example: KEYCODE_TAB. Same applies to ReactHorizontalScrollView.
3.
Set Android ScrollView to be non-focusable when scroll is disabled. Prior to this change, non-scrollable Scrollview would still be focusable, causing a poor keyboarding experience
## Changelog
[Android] [Fixed] Scrolling improvements in ReactAndroid
Pull Request resolved: https://github.com/facebook/react-native/pull/25105
Differential Revision: D15737563
Pulled By: mdvacca
fbshipit-source-id: 0d57563415c68668dc1acb05fb3399e6645c9595
Summary:
React Native on Android has currently been focused and targeted at using an Activity for its main form of instantiation.
While this has probably worked for most companies and developers, you lose some of the modularity of a more cohesive application when working in a "brown-field" project that is currently native. This hurts more companies that are looking to adopt React Native and slowly implement it in a fully native application.
A lot of developers follow Android's guidelines of using Fragments in their projects, even if it is a debated subject in the Android community, and this addition will allow others to embrace React Native more freely. (I even assume it could help with managing navigation state in applications that contain a decent amount of Native code and would be appreciated in those projects. Such as sharing the Toolbar, TabBar, ViewPager, etc in Native Android)
Even with this addition, a developer will still need to host the fragment in an activity, but now that activity can contain native logic like a Drawer, Tabs, ViewPager, etc.
Test plan (required)
We have been using this class at Hudl for over a couple of months and have found it valuable.
If the community agrees on the addition, I can add documentation to the Android sections to include notes about the potential of this Fragment.
If the community agrees on the addition, I can update one or more of the examples in the /Examples folder and make use of the Fragment, or even create a new example that uses a native layout manager like Drawer, Tabs, Viewpager, etc)
Make sure tests pass on both Travis and Circle CI.
_To Note:_
There is also talk of using React Native inside Android Fragment's without any legit documentation, this could help remedy some of that with more documentation included in this PR https://facebook.github.io/react-native/releases/0.26/docs/embedded-app-android.html#sharing-a-reactinstance-across-multiple-activities-fragments-in-your-app
Others have also requested something similar and have a half-baked solution as well http://stackoverflow.com/questions/35221447/react-native-inside-a-fragment
Release Notes
[ANDROID][FEATURE][ReactAndroid/src/main/java/com/facebook/react/ReactFragment.java] - Adds support for Android's Fragment system. This allows for a more hybrid application.
Reviewed By: cpojer
Differential Revision: D15731340
fbshipit-source-id: 74b7aaedcfd6ad6e074ff911cd7f18a5111caf5c
Summary: Listen to NodeLayout event and passes this event callback to java layer along with the information whether layout or measure was done in this pass
Reviewed By: davidaurelio
Differential Revision: D15696021
fbshipit-source-id: 8c5ca69330a9baca26b77052d4965cc67fe97c75
Summary: This diff creates a new react feature flag to enable extra logging on React Web Views
Reviewed By: RSNara
Differential Revision: D15729871
fbshipit-source-id: 931d4a1b022c6a405228bf896b50ecc7a44478d1
Summary: `ReactTurboModuleManagerDelegate` only understands `TurboReactPackage`s. So, we need to convert `FBMainReactPackage` and all its dependent packages into `TurboReactPackage`.
Reviewed By: fkgozali
Differential Revision: D15711546
fbshipit-source-id: df626d542a6477b116c867299219156423c6364a
Summary: To implement the `getModule` method of `TurboReactPackages`, we need to be able to access the JS Names of NativeModule classes.
Reviewed By: fkgozali
Differential Revision: D15711544
fbshipit-source-id: 51a649d08410557a4bdbf20d065bf98646a8d18a
Summary:
When `ModuleHolder` instantiates `NativeModules`, it calls the `initialize()` method. We should replicate this call in the TurboModule system.
`NativeModule.initialize()` is meant to be called after ReactApplicationContext is initialized. TurboModuleManager is initialized after ReactApplicationContext is initialized. Therefore, after we create the TurboModule, it should be safe to call `initialize()` on it.
Reviewed By: mdvacca
Differential Revision: D15711540
fbshipit-source-id: c2ef1a2ab164996bfc5716d81b3b3c716bf0e120
Summary:
... and slighly new behaviour for one of them.
The method does nothing if given `key` already exists in the container.
This diff finishes the transition of ContextContainer from an internal bag of things with unclear yet ownership into a legit dedicated dependency injection container for the product code.
The original names of methods imply that the container can have only one object of a given type which is no longer true. The new API is much more generic and idiomatic to C++, it mimics `std:map` API which is intuitive to anyone who familiar with C++ containers.
Besides the naming, `insert` method changed the semantic a bit; now it does nothing in case of inserting an object with a key that already exists. That might seem counterintuitive for "normal" people, but C++ has some wired reasons for that and, hopefully, it's expected behavior in the C++ community.
Fun fact: We need this to fix hot-reload.
Reviewed By: sahrens
Differential Revision: D15681736
fbshipit-source-id: 194f342528446a911eaf072ba3a94a5d8af3cb52
Summary:
Original commit changeset: e295dafdab7a
I'm backing this out because it's broken Catalyst. The fixes are in D15711539, but it could take some time to review and land them.
Reviewed By: rickhanlonii
Differential Revision: D15714896
fbshipit-source-id: c2c555a52d3d140dfdea7d54ccd8d3102c22a1c6
Summary: Move PtrJNodeMap to header file so that it can be accessed in events subscribers outside yoga
Reviewed By: davidaurelio
Differential Revision: D15619629
fbshipit-source-id: 1bf213efd38ec7bcac6a38070f21fa837c5f17da
Summary:
`/*` is the standard throughout open source code. For example, Firefox uses single /*: https://hg.mozilla.org/mozilla-central/file/21d22b2f541258d3d1cf96c7ba5ad73e96e616b5/gfx/ipc/CompositorWidgetVsyncObserver.cpp#l3
In addition, Rust considers `/**` to be a doc comment (similar to Javadoc) and having such a comment at the beginning of the file causes `rustc` to barf.
Note that some JavaScript tooling requires `/**`. This is OK since JavaScript files were not covered by the linter in the first place, but it would be good to have that tooling fixed too.
Reviewed By: zertosh
Differential Revision: D15640366
fbshipit-source-id: b4ed4599071516364d6109720750d6a43304c089
Summary:
`setTimeout` inside a headless JS task does not always works; the function does not get invoked until the user starts an `Activity`.
This was attempted to be used in the context of widgets. When the widget update or user interaction causes the process and React context to be created, the headless JS task may run before other app-specific JS initialisation logic has completed. If it's not possible to change the behaviour of the pre-requisites to be synchronous, then the headless JS task blocks such asynchronous JS work that it may depend on. A primitive solution is the use of `setTimeout` in order to wait for the pre-conditions to be met before continuing with the rest of the headless JS task. But as the function passed to `setTimeout` is not always called, the task will not run to completion.
This PR solves this scenario by allowing the task to be retried again with a delay. If the task returns a promise that resolves to a `{'timeout': number}` object, `AppRegistry.js` will not notify that the task has finished as per master, instead it will tell `HeadlessJsContext` to `startTask` again (cleaning up any posted `Runnable`s beforehand) via a `Handler` within the `HeadlessJsContext`.
Documentation also updated here: https://github.com/facebook/react-native-website/pull/771
### AppRegistry.js
If the task provider does not return any data, or if the data it returns does not contain `timeout` as a number, then it behaves as `master`; notifies that the task has finished. If the response does contain `{timeout: number}`, then it will attempt to queue a retry. If that fails, then it will behaves as if the task provider returned no response i.e. behaves as `master` again. If the retry was successfully queued, then there is nothing to do as we do not want the `Service` to stop itself.
### HeadlessJsTaskSupportModule.java
Similar to notify start/finished, we simply check if the context is running, and if so, pass the request onto `HeadlessJsTaskContext`. The only difference here is that we return a `Promise`, so that `AppRegistry`, as above, knows whether the enqueuing failed and thus needs to perform the usual task clean-up.
### HeadlessJsTaskContext.java
Before retrying, we need to clean-up any timeout `Runnable`'s posted for the first attempt. Then we need to copy the task config so that if this retry (second attempt) also fails, then on the third attempt (second retry) we do not run into a consumed exception. This is also why in `startTask` we copy the config before putting it in the `Map`, so that the initial attempt does leave the config's in the map as consumed. Then we post a `Runnable` to call `startTask` on the main thread's `Handler`. We use the same `taskId` because the `Service` is keeping track of active task IDs in order to calculate whether it needs to `stopSelf`. This negates the need to inform the `Service` of a new task id and us having to remove the old one.
## Changelog
[Android][added] - Allow headless JS tasks to return a promise that will cause the task to be retried again with the specified delay
Pull Request resolved: https://github.com/facebook/react-native/pull/23231
Differential Revision: D15646870
fbshipit-source-id: 4440f4b4392f1fa5c69aab7908b51b7007ba2c40
Summary:
Add example showing regression before this fix is applied.
https://github.com/facebook/react-native/pull/18187 Was found to introduce a regression in some internal facebook code-base end to end test which couldn't be shared. I was able to create a reproducible demo of a regression I found, and made a fix for it. Hopefully this will fix the internal test, such that the pr can stay merged.
## Changelog
[GENERAL] [Fixed] - Fix connection of animated nodes and scroll offset with useNativeDriver.
Pull Request resolved: https://github.com/facebook/react-native/pull/24177
Reviewed By: rickhanlonii
Differential Revision: D14845617
Pulled By: cpojer
fbshipit-source-id: 1f121dbe773b0cde2adf1ee5a8c3c0266034e50d
Summary: This moves the Android related files to FB internal and moves the BUCK deps around.
Reviewed By: fkgozali
Differential Revision: D15392573
fbshipit-source-id: 251d2766729ed42a6fe312b3ab9c6b8f1a8c46d1
Summary: This moves the Toolbar Java files out RN and into our internal React shell.
Reviewed By: fkgozali
Differential Revision: D15469205
fbshipit-source-id: 15298505d74260618eb89673deb12d1b837b559f
Summary: Adding TurboModule for PlatformConstantsAndroid, and adding to Catalyst and Venice
Reviewed By: mdvacca
Differential Revision: D15630344
fbshipit-source-id: df6d5868cd3c9f54297bfea58683c8c1fd9375f0
Summary: Making DeviceInfo support TurboModule on Android; implementing the interface in the Java class and setting up codegen for the spec.
Reviewed By: mdvacca
Differential Revision: D15616194
fbshipit-source-id: 6326f23d95295e570df6f6c88289102ac733def7
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:
## Summary
If a NativeModule Spec interface extends `TurboModule`, we want to make the auto-generated Java base class for that NativeModule to implement `com.facebook.react.turbomodule.core.interfaces.TurboModule`. This makes it so that our Android code recognizes that Java module as a TurboModule.
When this diff lands, all internal FB4A NativeModules will start going through the TurboModule system.
Reviewed By: fkgozali
Differential Revision: D15327683
fbshipit-source-id: e295dafdab7a0e130820318aeaf0cafa41487689
Summary: This diff introduces `TurboModuleManagerDelegate` in Fb4a and Workplace. `Fb4aTurboModuleManagerDelegate` is responsible for creating TurboModules for Fb4a. `WorkTurboModuleManagerDelegate` is responsible for creating TurboModules for Workplace.
Reviewed By: mdvacca
Differential Revision: D15268563
fbshipit-source-id: c254c31856c59b3551bfe54b25c715c848646c5a
Summary:
### Problem
According to https://github.com/facebook/react-native/issues/9145, the `--port` setting is not respected when executing `react-native run-android`. The templates that report things like what port the dev server runs on are hard coded as well.
### Solution
This commit replaces the hardcoded instances of port 8081 on Android with a build configuration property. This allows setting of the port React Native Android connects to for the local build server.
For this change to work, there must also be an update to the react native CLI to pass along this setting:
https://github.com/react-native-community/react-native-cli/compare/master...nhunzaker:9145-android-no-port-hardcode-cli
To avoid some noise on their end, I figured I wouldn't submit a PR until it's this approach is deemed workable.
## Changelog
[Android][fixed] - `react-native run-android --port <x>` correctly connects to dev server and related error messages display the correct port
Pull Request resolved: https://github.com/facebook/react-native/pull/23616
Differential Revision: D15645200
Pulled By: cpojer
fbshipit-source-id: 3bdfd458b8ac3ec78290736c9ed0db2e5776ed46
Summary:
With JSI based architecture, there will be more and more C++ native code involved.
Original NDK builder in RN only supports release build and that's not reasonable for native debugging.
This change introduces a way to build native code in debuggable version.
Simply add `NATIVE_BUILD_TYPE=Debug` environment variable during gradle build,
e.g.
`NATIVE_BUILD_TYPE=Debug ./gradlew clean :ReactAndroid:assembleDebug`
## Changelog
[Android] [Added] - Add native debug build support to improve debugging DX
Pull Request resolved: https://github.com/facebook/react-native/pull/25147
Differential Revision: D15628533
Pulled By: cpojer
fbshipit-source-id: 8f5b54c4580824452d2a1236a7bd641889b001ec
Summary: `TurboModuleManagerDelegate` is an interface used to query/create TurboModules. It doesn't need to know anything about `ReactApplicationContext`. So, I'm removing all references of `ReactApplicationContext` from this class.
Reviewed By: mdvacca
Differential Revision: D15590552
fbshipit-source-id: 761d3ed71f124955f9c6b997e68a7a8338182126
Summary: Move PtrJNodeMap to header file so that it can be accessed in events subscribers outside yoga
Reviewed By: davidaurelio
Differential Revision: D15602627
fbshipit-source-id: bb5bd5bbf8dcb279f5f87a4fd7287909d4e895d8
Summary:
Co-Authored: zamotany
With React Native 0.59.8 the app keeps crashing with indexed RAM bundle on Android with the following error:
```
2019-05-09 11:58:06.684 2793-2856/? E/AndroidRuntime: FATAL EXCEPTION: mqt_js
Process: com.ramtestapp, PID: 2793
com.facebook.jni.CppException: getPropertyAsObject: property '__fbRequireBatchedBridge' is not an Object
no stack
at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
at android.os.Handler.handleCallback(Handler.java:873)
at android.os.Handler.dispatchMessage(Handler.java:99)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:29)
at android.os.Looper.loop(Looper.java:193)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:232)
at java.lang.Thread.run(Thread.java:764)
```
After investigation we found that when using any bundle, let it be non-ram, FIle RAM bundle or Index RAM bundle, the `CatalystInstanceImpl.java` is always using `loadScriptsFromAsset`, which is calling `CatalystInstanceImpl::jniLoadScriptFromAssets` in C++. This method when checking if bundle is a RAM bundle, uses `JniJSModulesUnbundle::isUnbundle` which only check for js-modules/UNBUNDLE - file generated when building File RAM bundle. There is no other logic to handle Indexed RAM bundle, so it figures that the bundle is not RAM, cause there is no js-modules/UNBUNDLE file and tries to load as regular bundle and fails.
In this PR we added check if it is indexed RAM bundle in `jniLoadScriptFromAssets` and handle it if it is.
## Changelog
[Android] [Fixed] fix indexed RAM bundle
Solves https://github.com/facebook/react-native/issues/21282
Pull Request resolved: https://github.com/facebook/react-native/pull/24967
Differential Revision: D15575924
Pulled By: cpojer
fbshipit-source-id: 5ea428e0b793edd8242243f39f933d1092b35260
Summary:
Android followup for #24745. This adds a jsi object that removes blobs when it is gc'ed. We don't have many modules with native code on Android so I've added the native code directly in the blob package as a separate .so. I used a similar structure as the turbomodule package.
## Changelog
[Android] [Fixed] - [Blob] Release underlying resources when JS instance is GC'ed on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/24767
Differential Revision: D15279651
Pulled By: cpojer
fbshipit-source-id: 2bbdc4bbcbeae8945588ac5e3e895c49e6ac9e1a
Summary:
Addresses a number of pieces of feedback regarding the debug menu.
- Simplify labels for the debugger actions (e.g. no "remote", no emoji).
- Reorder actions so that modal items are generally lower.
- Renamed "Live Reloading" to "Reload-on-Save".
- Renamed "Dev Settings" to "Settings".
Changelog:
[Android] [Changed] - Cleaned up debug menu.
Reviewed By: cpojer
Differential Revision: D15553883
fbshipit-source-id: d30e8cd0804e010985c0cf40d443defc7c0710ac
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: D15391408 (https://github.com/facebook/react-native/pull/24695) added a new event type with the registration name 'onAccessibilityAction' on Android, using the key 'performAction'. On iOS the same event uses the key 'topAccessibilityAction', which caused a runtime error after I started registering both using the unified JS view config in D15488008. This diff changes Android to use the same name as iOS since the convention is to start with 'top'.
Reviewed By: cpojer
Differential Revision: D15542623
fbshipit-source-id: c339621d2b4d3e1700feb5419ae3e3af8b185ca8
Summary:
If you (try to) build React Native for Android without having the NDK properly installed and referenced, you get the following error:
>A problem occurred evaluating project ':ReactAndroid'.
\> Cannot get property 'absolutePath' on null object
This is not an overly helpful diagnostic. This PR results in this message instead:
>ndk-build binary cannot be found, check if you've set $ANDROID_NDK environment variable correctly or if ndk.dir is setup in local.properties
Fixes#25087
## Changelog
[Android] [Fixed] - Show proper error message instead of throwing a NullReferenceException if Gradle cannot find the NDK
Pull Request resolved: https://github.com/facebook/react-native/pull/25088
Differential Revision: D15559271
Pulled By: cpojer
fbshipit-source-id: 35c9a9321af4e4a34bf519144ada48884b48352d
Summary:
This diff fixes the bug of the switch component on Android being stuck in the middle when a user releases their finger whily dragging the thumb.
When a user releases their finger while dragging the thumb, `setChecked` will be called and if `mAllowChange` is set to false, `super.setChecked` is never called. The supper method will actually make sure the thumb will be animated to the correct edge. Without calling the super method, the thumb might stay in the middle of the switch where a user released their finger.
The fix had to be applied both to ReactSwitch and FbReactSwitchCompat.
One more fix had to be made to FbReactSwitchCompat since D5884661 was applied to ReactSwitch, but not to FbReactSwitchCompat:
if (mAllowChange && **isChecked() != checked**) {
...
}
Reviewed By: mdvacca
Differential Revision: D15535611
fbshipit-source-id: 22ca1fe3fa993ae65cbd677bfae2208a02c368d4
Summary:
This is an ESLint plugin that infers whether an import looks like a Haste module name. To keep the linter fast and simple, it does not look in the Haste map. Instead, it looks for uppercase characters in single-name import paths, since npm has disallowed uppercase letters in package names for a long time. There are some false negatives (e.g. "merge" is a Haste module and this linter rule would not pick it up) but those are about 1.1% of the module names in the RN repo, and unit tests and integration tests will fail anyway once Haste is turned off.
You can disable the lint rule on varying granular levels with ESLint's normal disabling/enabling mechanisms.
Also rewrote more Haste imports so that the linter passes (i.e. fixed lint errors as part of this PR).
## Changelog
[General] [Changed] - Add a lint rule to disallow Haste imports
Pull Request resolved: https://github.com/facebook/react-native/pull/25058
Differential Revision: D15515826
Pulled By: cpojer
fbshipit-source-id: d58a3c30dfe0887f8a530e3393af4af5a1ec1cac
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:
[Android][Fix] - Fix how we normalize indices
Before, we were incorrectly normalizing indices given pending view deletion in the view hierarchy (namely, using LayoutAnimations)
What we had before (that was wrong):
* Maintained a pendingIndices sparse array for each tag
* For each pendingIndices sparse array we'd keep track of how many views we deleted at each abstract index
* Given an abstract index to delete a view at, we'd consult `pendingIndices` array to sum how many pending deletes we had for indices equal or smaller than and add to abstract index
^ Above algorithm is wrong and you can follow along with the following example to see how.
## The correct approach
Given these operations in this order:
1. {tagsToDelete: [123], indicesToDelete [2]}
2. {tagsToDelete: [124], indicesToDelete [1]}
3. {tagsToDelete: [125], indicesToDelete [2]}
4. {tagsToDelete: [126], indicesToDelete [1]}
The approach we want to be using to calculate normalized indices:
### Step 1: Delete tag 124 at index 2
|Views:|122|123|124|125|126|127|
|Actual Indices:|0|1|2|3|4|5|
|Abstract Indices:|0|1|2|3|4|5|
=> simple, we just mark the view at 2
### Step 2: Delete tag 123 at index 1
View tags and indices:
|Views|122|123|~~124~~|125|126|127|
|Actual indices|0|1|~~2~~|3|4|5|
|Abstract Indices|0|1||2|3|4|
=> again, simple, we can just use the normalized index 1 because no pending deletes affect this operation
### Step 3: Delete tag 126 at index 2
View tags and indices:
|Views|122|~~123~~|~~124~~|125|126|127|
|Actual Indices|0|~~1~~|~~2~~|3|4|5|
|Abstract Indices|0|||1|2|3|
=> Here we want to normalize this index to 4 because we need to account the 2 views that should be skipped
### Step 4: Delete tag 125 at index 1
View tags and indices:
|Views|122|~~123~~|~~124~~|125|~~126~~|127|
|Actual Indices|0|~~1~~|~~2~~|3|~~4~~|5|
|Abstract Indices|0|||1||2|
=> The normalized index should be 3.
This diff updates the function `normalizeIndex` to do the above algorithm by repurposing `pendingIndicesToDelete` to instead be a sparse int array that holds [normalizedIndex]=[tag] pairs
It's required that `pendingIndicesToDelete` is ordered by the normalizedIndex.
Reviewed By: mdvacca
Differential Revision: D15485132
fbshipit-source-id: 43e57dffa807e8ea50fa1650c5dec13a6fded624
Summary:
This PR solves bug https://github.com/facebook/react-native/issues/24393 for Android. Allows an app to be opened with an NFC tag and getting the url trough Linking.getInitialURL()
## Changelog
[Android] [Fixed] - This branch checks also for `ACTION_NDEF_DISCOVERED` intent matches to set the initialURL
Pull Request resolved: https://github.com/facebook/react-native/pull/25055
Differential Revision: D15516873
Pulled By: cpojer
fbshipit-source-id: e8803738d857a69e1063e926fc3858a416a0b25e
Summary:
Add prop showSoftInputOnFocus to TextInput. This fixes#14045. This prop can be used to prevent the system keyboard from displaying at all when focusing an input text, for example if a custom keyboard component needs to be displayed instead.
On Android, currently TextInput always open the soft keyboard when focused. This is because `requestFocus` calls `showSoftKeyboard`, which in turn instructs `InputMethodManager` to show the soft keyboard.
Unfortunately even if we were to define a new input type that extends ReactEditText, there is no way to overcome this issue.
This is because `showSoftKeyboard` is a private method so it can't be overriden. And at the same time `requestFocus` needs to invoke `super.requestFocus` to properly instruct Android that the field has gained focused, so overriding `requestFocus` in a subclass of ReactEditText is also not an option, as when invoking `super.requestFocus` we would end up calling again the one defined in ReactEditText.
So currently the only way of doing this is to basically add a listener on the focus event that will close the soft keyboard immediately after. But for a split second it will still be displayed.
The code in the PR changes `requestFocus` to honor showSoftInputOnFocus as defined in Android TextView, displaying the soft keyboard unless instructed otherwise.
## Changelog
[Android] [Added] - Add showSoftInputOnFocus to TextInput
Pull Request resolved: https://github.com/facebook/react-native/pull/25028
Differential Revision: D15503070
Pulled By: mdvacca
fbshipit-source-id: db4616fa165643d6ef2b3185008c4d279ae08092
Emily Janzer
Ramanpreet Nara
Aditya Sharat
Onti Vals
David Vacca
Sidharth Guglani
Valentin Shergin
Rain
Joshua Ong
Mikael Sand
Christoph Nakazawa
Krzysztof Borowy
Nate
Kody Greenbaum
Kudo Chien
Joshua Gross
Hermanyo
Dratwas
Janic Duplessis
Tim Yung
Ram N
Petter Hesselberg
Oleksandr Melnykov
James Ide
Luna Wei
Andrea Cimitan
valerio.ponte
rkang
