Summary:
## Motivation
The concept behind JSCallInvoker doesn't necessarily have to apply only to the JS thread. On Android, we need to re-use this abstraction to allow execution of async method calls on the NativeModules thread.
Reviewed By: PeteTheHeat
Differential Revision: D17377313
fbshipit-source-id: 3d9075cbfce0b908d800a366947cfd16a3013d1c
Summary:
This PR removes Java reflection use in ReactDrawerLayoutManager.java because we all use AndroidX and setDrawerElevation is available. Also adds NonNull annotations
## Changelog
[Android] [Changed] - cleanup DrawerLayoutAndroid
Pull Request resolved: https://github.com/facebook/react-native/pull/26497
Test Plan: RNTester is working as expected.
Differential Revision: D17488727
Pulled By: mdvacca
fbshipit-source-id: fd626e3e7aca3965f62c4c82a55c69e81facc61d
Summary:
This diff splits up the current `createTimer` method (which is used for setTimeout, setInterval, etc.) into two methods, `createTimer` and `createAndMaybeCallTimer`. The latter is what's used by the existing Timing native module, and it preserves the existing behavior of this function.
What's the difference? The current implementation of createTimer makes some assumptions about how it's called - namely, that it's called from JS asynchronously (using the bridge). Right now when you create a timer from JS, the JSTimers module passes in the timestamp for when the timer was created; in the native `createTimer`, we compare this timestamp to the current time, and if we find the timer has already expired, we immediately invoke the callback.
Presumably this is done because we don't know how much time has elapsed since when the timer was scheduled in JS, and we want to make sure that it's called as soon as possible. Of course, this also means that `setTimeout(0)` will be immediately invoked, too, without waiting for the next frame.
This all sounds fine, until we take a look at immediates. Immediates are currently implemented entirely in JS, and are called by the JS bridge; before returning control to native, we flush the immediates queue.
This means that the current behavior is: 1) `setImmediate()` is always invoked before `setTimeout(0)`; 2) `setTimeout(0)` is invoked as soon as possible, before the next frame.
However, this changes with bridgeless RN. With bridgeless RN, the native module methods are being replaced by C++ host functions, which are called synchronously. So if we keep the current logic in JavaTimerManager (where it checks if the timer has already expired), then `setTimeout(0)` will be invoked **before** immediates are called.
So the change that I'm making for bridgeless RN is to always wait until the next frame before calling timers. This preserves the order of immediates/timers, although it does mean that `setTimeout(0)` will no longer be called as soon as possible. Of the two options, this seems preferable.
Reviewed By: PeteTheHeat
Differential Revision: D17403144
fbshipit-source-id: 8230f6ebe56aa20bfcf2325177c7812bc8e9c2ec
Summary:
This change restores the possibility of injecting custom root views via ReactAcitivtyDelegate. It has been used by react-native-gesture-handler library in order to replace default root view with a one that'd route touch events to gesture-handler internal pipeline.
The regression happened in d0792d4b8a where new `ReactDelegate` was introduced to provide support for rendering react native views in both Android fragments and activities. As a part of that change the logic responsible for creating root view has been moved from `ReactActivityDelegate` to `ReactDelegate` rendering `ReactActivityDelegate.createRootView` unused – that is there is no code path that leads to this method being called. Instead `ReactDelegate.createRootView` method has been added which now plays the same role. The custom root view injection was relying on overwriting that method and hence the method is no longer referenced overwriting it has no effect. Following the logic migration out of `ReactActivityDelegate` into `ReactDelegate` we could potentially now start overwriting methods of `ReactDelegate`. However when working with Android's activities in React Native we can only provide an instance of `ReactActivityDelegate` and in my opinion it does not make too much sense to expose also a way to provide own instance of `ReactDelegate`.
The proposed fix was to route `ReactDelegate.createRootView` to call `ReactActivityDelegate.createRootView` and this way regaining control over root view creation to `ReactActivityDelgate`. The change of the behavior has been implemented by subclassing `ReactDelegate` directly from `ReactActivityDelegate` and hooking the aforementioned methods together. Thanks to this approach, the change has no effect on `ReactDelegate` being used directly from fragments or in other scenarios where it is not being instantiated from `ReactActivityDelegate`.
This fixes an issue reported in https://github.com/kmagiera/react-native-gesture-handler/issues/745 and discussed on 0.61 release thread: https://github.com/react-native-community/releases/issues/140#issuecomment-532235945
## Changelog
[Internal] [Fixed] - Allow for custom root view to be injected via ReactActivityDelegate
Pull Request resolved: https://github.com/facebook/react-native/pull/26495
Test Plan:
1. Run RNTester, take layout snapshot, see the react root view being on the top of view hierarchy.
2. Run gesture-handler Example app (or some other app that overwrites ReactActivityDelegate.createRootView method), on layout snapshot see custom root view being used.
Differential Revision: D17482966
Pulled By: mdvacca
fbshipit-source-id: 866f551b8b077bafe1eb9e34e5dccb1240fa935e
Summary:
The next step to making our existing timers logic usable outside of the context of the native module. This diff removes the bridge access through ReactContext in JavaTimerManager, and instead relies on a delegate that implements the JSTimers interface. I'm reusing the JSTimers interface for convenience even though it extends JavaScriptModule, which I don't plan on using for bridgeless RN.
Also changing from ReadableArray to ReadableNativeArray so that it can be directly accessed from C++.
Reviewed By: PeteTheHeat
Differential Revision: D17282188
fbshipit-source-id: 5c5e0b12a2250334e96885c220feb52146e57c83
Summary:
Decoupling the logic for managing timers from the native module interface in TimingModule. I'm doing this so we can more easily share this logic with bridgeless RN, which won't use a native module for timers but instead will define the bindings with JSI.
This diff just moves things around and doesn't change any of the behavior.
Reviewed By: PeteTheHeat
Differential Revision: D17282187
fbshipit-source-id: ef54254dd0c7e2f6e294e9ae5a7d4b010f98de2e
Summary: Most of our other native modules end in 'module', so let's update Timing to match.
Reviewed By: RSNara
Differential Revision: D17260848
fbshipit-source-id: 808b4d370a7036a247724fda5ab7210ac985476b
Summary:
This is a easy change in ReactEventEmitter that refactors the TAG used by this class to log events.
This is a follow up of D17422611
Reviewed By: makovkastar
Differential Revision: D17437034
fbshipit-source-id: 9974a244b24b04315c6a328696954b7acf7efbfd
Summary:
Reland https://github.com/facebook/react-native/pull/24767
The commit had to be reverted because it caused a crash when using remote debugging in chrome. This is normal since jsi is not available in that environment. The crash was caused by `jsContext.get()` being 0, then being dereferenced later in c++. We can simply skip initializing the blob collector in this case.
This also includes the fix from https://github.com/facebook/react-native/issues/25720 to fix a crash when using hermes.
## Changelog
[Android] [Fixed] - Release underlying resources when JS instance is GC'ed on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/26155
Test Plan:
Test using RN tester with jsc and hermes
Test remote debugging
Reviewed By: mdvacca, fred2028
Differential Revision: D17072644
Pulled By: makovkastar
fbshipit-source-id: 079d1d43501e854297fbbe586ba229920c892584
Summary:
React Native components need a mechanism to specify their value to assistive technologies. This PR adds the notion of accessibilityValueDescription-- a property which either contains a textual description of a component's value, or for range-based components, such as sliders and progress bars, it contains range information (minimum, current, and maximum).
On iOS, the range-based info if present is converted into a percentage and added to the accessibilityValue property of the UIView. If text is present as part of the accessibilityValueDescription, it is used instead of the range-based information.
On Android, any range-based information in accessibilityValueDescription is exposed in the AccessibilityNodeInfo's RangeInfo. Text which is part of accessibilityValueDescription is appended to the content description.
## Changelog
[GENERAL] [Change] - add accessibilityValuedescription property.
Pull Request resolved: https://github.com/facebook/react-native/pull/26169
Test Plan: Added two new accessibility examples to RNTester, one which uses text and another which uses range-based info in accessibilityValueDescription. Verified that they both behave correctly on both Android and iOS.
Differential Revision: D17444730
Pulled By: cpojer
fbshipit-source-id: 1fb3252a90f88f7cafe1cbf7db08c03f14cc2321
Summary:
Remove YogaNode.create() from the abstract class after we made sure nothing uses it anymore
This is the final stage to make `YogaNode` a pure class without JNI references
Reviewed By: SidharthGuglani
Differential Revision: D17280571
fbshipit-source-id: bd0eb138f7a6a9de8988fc0a7b90badbf635dac5
Summary:
Split YogaConfig into the same way YogaNode is split today.
Into an abstract class defining the interface, and actual JNI implementation
Reviewed By: SidharthGuglani
Differential Revision: D17266404
fbshipit-source-id: 3d5d6aa65c55cfa61d47c662d140cdce6dcb0ea1
Summary:
The concept of `EventBeat::Owner` was introduced in D17128549, this diff implements some missing pieces of that.
After the change, AsyncEventEmitter will check the existence of the "owner" (which is EventDispatcher) which guarantees that the rest of the pipeline is still alive (the validity of Runtime is guaranteed by RuntimeExecutor separately).
The overall workflow is described in D17128549.
Reviewed By: JoshuaGross
Differential Revision: D17410738
fbshipit-source-id: a1ae8e09600546874cdc7c622b3d884b71c5b48d
Summary:
This diff forces ReactEventEmitter to use RCTEventEmitter as default event emitter class. This is necessary because of T54134149.
This is a temporary fix until we find the root cause of T54134149
Reviewed By: JoshuaGross
Differential Revision: D17422611
fbshipit-source-id: 159b216434c79466427b7b1a2b0f71f466b0f606
Summary:
Expose native pointer thru an interface function for YogaConfig (its package private to `com.facebook.yoga` namespace),
This way we can make later on YogaConfig a pure abstract class.
Plus, it makes sure external users don't modify the pointer
Reviewed By: SidharthGuglani
Differential Revision: D17266401
fbshipit-source-id: f39b488cea0b73bc3578bb3aa90ab00139bf9271
Summary:
I wanted to configure the RN dev menu without having to write native code. This is pretty useful in a greenfield app since it avoids having to write a custom native module for both platforms (and might enable the feature for expo too).
This ended up a bit more involved than planned since callbacks can only be called once. I needed to convert the `DevSettings` module to a `NativeEventEmitter` and use events when buttons are clicked. This means creating a JS wrapper for it. Currently it does not export all methods, they can be added in follow ups as needed.
## Changelog
[General] [Added] - Export the DevSettings module, add `addMenuItem` method
Pull Request resolved: https://github.com/facebook/react-native/pull/25848
Test Plan:
Tested in an app using the following code.
```js
if (__DEV__) {
DevSettings.addMenuItem('Show Dev Screen', () => {
dispatchNavigationAction(
NavigationActions.navigate({
routeName: 'dev',
}),
);
});
}
```
Added an example in RN tester
Differential Revision: D17394916
Pulled By: cpojer
fbshipit-source-id: f9d2c548b09821c594189d1436a27b97cf5a5737
Summary: I think this array is copied when we call the function over the JNI, and that we need to free the local copy we make.
Reviewed By: mdvacca
Differential Revision: D17377077
fbshipit-source-id: 82fe4ec89e95335a329f4ce562441561dbe88693
Summary:
This diff refactors ReactEventEmitter to not use the method ReactContext.getJSModule()
Since the initialization of events is performed by UIManagerModule or FabricUIManager classes we don't need to use JSModules as part of this class
Reviewed By: ejanzer
Differential Revision: D17176948
fbshipit-source-id: 6915a74b486851fbeda24f779d97873df22fd79b
Summary: Today, View Managers are all initialized as soon as we start up the app. Making them lazy, so that we only intantiate them when they are really needed
Differential Revision: D17329940
fbshipit-source-id: 821bf121f04d58c7b871c7923fed81d8c735f8b4
Summary:
Add standalone factory classes which generate YogaNode + YogaConfig, later on it will allow us to separate the yoga interface and actual implementation buck targets (see D17266406)
We've done such breakage change previously in D14122974.
Reviewed By: SidharthGuglani
Differential Revision: D17258196
fbshipit-source-id: b12f1a0d23c3f82b14cee0731a1daf1c015ee32c
Summary:
Removed unused file YogaNodeJNIPhantomRefs.java as this was causing oss build failures because of an import.
````:yoga:compileDebugJavaWithJavac/home/travis/build/facebook/yoga/java/com/facebook/yoga/YogaNodeJNIPhantomRefs.java:9: error: package com.facebook.jni does not exist
import com.facebook.jni.DestructorThread;
^
/home/travis/build/facebook/yoga/java/com/facebook/yoga/YogaNodeJNIPhantomRefs.java:30: error: package DestructorThread does not exist
new DestructorThread.Destructor(node) {
^
2 errors
FAILED
Reviewed By: pasqualeanatriello
Differential Revision: D17257330
fbshipit-source-id: 98b0c5d5b7dcd94bee559b58194c13b07f47723d
Summary:
Collapse many Remove/Delete mount items into a single batched item.
Since a delete is always preceded by a remove mountitem, we can batch these into one instruction. Since deletes tend to come in large blocks, it might make sense to batch many into a single instruction.
Reviewed By: mdvacca
Differential Revision: D17254631
fbshipit-source-id: abfd54cdb0bbb9a4c0880ec8e8bbd681367aecd4
Summary: Retain reference to reactNativeConfig to allow feature checks within core. This also rearranges the members of Binding to make them private instead of public.
Reviewed By: mdvacca
Differential Revision: D17275344
fbshipit-source-id: 67ad00aeebd3534a45a6ea8a28e14b7fcd9eb2e5
Summary: We were using an alias_ref which is like a raw pointer (not managed/retained); as it turns out, everywhere (?) else we accept an alias_ref we convert it to a global_ref (see Binding.cpp, JMessageQueueThread). We've just gotten lucky to not have already hit use-after-free errors.
Reviewed By: mdvacca
Differential Revision: D17275200
fbshipit-source-id: 581a51da36e96c353ed1117e9e0f428e65d36d69
Summary:
Log every item in a BatchMountItem. There's a lot of useful debug information being hidden there currently.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D17254629
fbshipit-source-id: c72f0aa8506059da5225ebead24d3f8ead5bdebd
Summary: Same as prior diff, but Android.
Reviewed By: JoshuaGross
Differential Revision: D17005308
fbshipit-source-id: 1ac815a232dceaf918e14b045e04aed53a00ae47
Summary: This feature is not necessary any longer with Fast Refresh enabled by default.
Reviewed By: gaearon
Differential Revision: D17156607
fbshipit-source-id: 2396a86d192c6b5d90cbed9cefbf13367dd6b699
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:
This ressurects D14994945 and fixes the following extra issues:
1. Source map not being accounted for after reloads
2. Breakpoints being resent before Hermes is ready for them
3. Connection being dropped when reloading at inopportune times
This hopefully fixes the issue of having to close and re-open the debugger if
it's attached when reloading.
Reviewed By: sahrens
Differential Revision: D17100911
fbshipit-source-id: df988e7bb532170f5add47b9e49cd7c8ddf67b43
Summary: Fixes the crash when calling setCameraDistance with NaN on Android Q.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D17170045
fbshipit-source-id: 386f969e70c56bca6ae5b8ffead62453ebb72857
Summary: This diff migrates `FbReactTTRCStepRenderFlagManager` to use the generated `TTRCStepRenderFlagManagerDelegate` for setting its properties. A bit more work was required to migrate this view manager since it doesn't extend `BaseViewManager`, so I had to add an adapter which made it possible to pass an instance of `FbReactTTRCStepRenderFlagManager` to `TTRCStepRenderFlagManagerDelegate`.
Reviewed By: mdvacca
Differential Revision: D16984172
fbshipit-source-id: 7bf8c1342435c4e615eb9e7ca711f53c63ed3438
Summary:
Our JS codegen assumes that all Android view managers extend `BaseViewManager` which allows generated delegates to set base view props using `BaseViewManagerDelegate`, see and example of the generated delegate for `FbReactTTRCStepRenderFlagManager`:
```
public class TTRCStepRenderFlagManagerDelegate<T extends View, U extends BaseViewManager<T, ? extends LayoutShadowNode> & TTRCStepRenderFlagManagerInterface<T>>{
public TTRCStepRenderFlagManagerDelegate(U viewManager) {
super(viewManager);
}
Override
public void setProperty(T view, String propName, Nullable Object value) {
switch (propName) {
case "traceId":
mViewManager.setTraceId(view, value == null ? null : (String) value);
break;
case "stepName":
mViewManager.setStepName(view, value == null ? null : (String) value);
break;
default:
super.setProperty(view, propName, value);
}
}
}
```
The problem is that `FbReactTTRCStepRenderFlagManager` doesn't extend `BaseViewManager`, but `ViewManager`, which means that we cannot use it with the generated delegate. We cannot use `ViewManager` instead of `BaseViewManager` in our JS codegen either, otherwise we will not be able to set base view props.
This diff makes it possible for delegates generated by JS to be used by Android view managers that do not extend `BaseViewManager`. By having a `BaseViewManagerInterface` we will be able to introduce a no-op base view manager implementation and wrap our original view manager in it so that we can pass as a constructor parameter to `BaseViewManagerDelegate`.
See an example of this approach for `FbReactTTRCStepRenderFlagManager`:
```
public class FbReactTTRCStepRenderFlagManager extends ViewManager<FbReactTTRCStepRenderFlag, ReactShadowNodeImpl> implements TTRCStepRenderFlagManagerInterface<FbReactTTRCStepRenderFlag> {
private final ViewManagerDelegate<FbReactTTRCStepRenderFlag> mDelegate;
public FbReactTTRCStepRenderFlagManager() {
mDelegate = new TTRCStepRenderFlagManagerDelegate<>(new ViewManagerWrapper(this));
}
...
private static class ViewManagerWrapper extends BaseViewManagerAdapter<FbReactTTRCStepRenderFlag> implements TTRCStepRenderFlagManagerInterface<FbReactTTRCStepRenderFlag> {
private final TTRCStepRenderFlagManagerInterface<FbReactTTRCStepRenderFlag> mViewManager;
private FbReactTTRCStepRenderFlagManagerAdapter(TTRCStepRenderFlagManagerInterface<FbReactTTRCStepRenderFlag> viewManager) {
mViewManager = viewManager;
}
Override
public void setTraceId(FbReactTTRCStepRenderFlag view, Nullable String traceId) {
mViewManager.setTraceId(view, traceId);
}
Override
public void setStepName(FbReactTTRCStepRenderFlag view, Nullable String stepName) {
mViewManager.setStepName(view, stepName);
}
}
}
```
Reviewed By: mdvacca
Differential Revision: D16984121
fbshipit-source-id: ea2761dda68a96ff3ba6ac64153bc4e56e396774
Summary:
We probably don't always need to crash in these cases.
This should replace all prod/dev crashes with logged SoftExceptions.
Note that this is currently only used for Fabric.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D17170459
fbshipit-source-id: 70757ae88deb8c893b36971d879174e25a194fb9
Summary:
## Summary
When an exception is raised by Java in a synchronous call from JS to Java, the Java portion of the stack trace is simply ignored when the exception is forwarded to JS. This problem doesn't exist for async calls. I did some digging to figure out why this works with async calls, but not sync calls, to get to the bottom of T52585087.
In T52585087, `TurboModuleRegistry.get<Spec>('I18nAssets')` fails because of a `NullPointerException` in Java. However, since there's no stack trace associated with the `NullPointerException`, it's hard to diagnose the problem.
## Asynchronous calls
ReactNative's NativeModules thread is a background thread on which we schedule asynchronous NativeModule method invocations. We spawn our background threads in Java using the [`MessageQueueThreadImpl`](https://fburl.com/diffusion/u0vdm5k3). Each thread is associated with a queue on which you can schedule some work. These `MessageQueueThread`s have a [C++ API](https://fburl.com/diffusion/596740d8) that we can use to schedule some work from C++.
NativeModule method invocations in JS produce a C++/Java boundry, because our JS executes C++, which executes the Java NativeModule method. But since the method is asynchronous, instead of invoking it immediately, we wrap it in a C++ lambda and use the C++ API of `MessageQueueThread` to schedule it to be invoked later. Therefore, when it actually invokes, we'll get Java invoking C++, which invokes Java.
When the NativeModule method (implemented in Java) throws an exception, fbjni will convert that exception into a `jni::JniException` and start unwinding the C++ stack. Eventually, this exception will reach the outermost Java/C++ boundry. Typically, at this point, the program would crash, but because we used fbjni to register all our native functions, our `jni::JniException` will automatically be converted into a regular Java exception. This exception will be caught by MessageQueueThreadHandler [here](https://fburl.com/diffusion/c4thoca7), and handled using our ExceptionHandler NativeModule.
## Synchronous calls
In synchronous execution, JS uses a `JSI::HostObject` to call the Java method directly. If the Java method throws an error, because we're using fbjni, that Java exception will be converted to a `jni::JniException` object, which will contain the stack tract of the Java object. However, from what I could gather, Hermes doesn't know about `jni::JniException`. So, simply ignore the stack trace associated with the Java exception, understanding only the exception message. Hence, all synchronous calls into Java only display the JS stack trace. What we really want is to build an platform-agnostic abstraction that understands `jni::JniException` (and whatever its analogue is in iOS, if any) and use that to bridge between Native and JS.
## Temporary Solution
We know that when NativeModules are created, we do a synchronous call from JS to C++ to Java. This synchronous call happens when you do a property access on the `NativeModules` object. Therefore, at the very least, to get to the bottom of T52585087, we could log all exceptions that are thrown whenever a NativeModule is created. This should help us get to the bottom of T52585087.
Reviewed By: mdvacca
Differential Revision: D17126667
fbshipit-source-id: a6fb27aaea094b9559939ddcc260d3a2c6e71492
Summary:
We added the accessibilityState property as a more semantically rich way for components to describe information about their state to accessibility services. This PR removes the old accessibilityStates property.
<!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? -->
## Changelog
[General] [Change] - Remove accessibilityStates property.
Pull Request resolved: https://github.com/facebook/react-native/pull/26168
Test Plan: Ensure that RNTester accessibility examples function properly on both iOS and Android.
Differential Revision: D17152891
Pulled By: cpojer
fbshipit-source-id: d71d3cf0f2e0846979d2ba104b6c69e4e5725252
Summary: The progress bar on Android was disabled in D5329011 because of T19653381, but was never enabled again. I spent some time trying to reproduce the issue of the bundle being stuck while loading, but didn't succeed. So let's enable the progress bar and monitor whether people would start seeing this bug again.
Reviewed By: cpojer
Differential Revision: D17148134
fbshipit-source-id: 5130b809460bc743d26a6e88961f81061089fe1d
Summary: Prior to Android P things like setScaleX() allowed passing float values that were bogus such as Float.NaN. If the app is targeting Android P or later then passing these values will result in an exception being thrown. Since JS might still send Float.NaN, we want to keep the code backward compatible and continue using the fallback value if an invalid float is passed. `sanitizeFloatPropertyValue` is an exact copy of the private method with the same name in `android.view.View.java`.
Reviewed By: cpojer
Differential Revision: D17153279
fbshipit-source-id: 036acc4baa6f0b7f206488991b428a84374fa453
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: Support existing, backwards-compatible AndroidTextInput component for minimal support of TextInput on Android.
Reviewed By: shergin, mdvacca
Differential Revision: D17086758
fbshipit-source-id: 25726f22229e0d5dfe96eb36b386a5317601283d
Summary: Support for `sendAccessibilityEvent` in the FabricUIManager.
Reviewed By: shergin
Differential Revision: D17142507
fbshipit-source-id: 5c131d7caa1e4189fd41ecfb558d0027394b6a15
Summary:
The purpose of `EventBeat` is handling an asynchronous callback to itself which is being delivered on some different thread. That brings a challenge of ensuring that the `EventBeat` object stays valid during the timeframe of callback execution. The concept of Owner helps with that.
The owner is a shared pointer that retains (probably indirectly) the `EventBeat` object. To ensure the correctness of the call, `EventBeat` retains the owner (practically creating a retain cycle) during executing the callback. In case if the pointer to the owner already null, `EventBeat` skips executing the callback.
It's impossible to retain itself directly or refer to the shared pointer to itself from a constructor. `OwnerBox` is designed to work around this issue; it allows to store the pointer later, right after the creation of some other object that owns an `EventBeat`.
Reviewed By: JoshuaGross
Differential Revision: D17128549
fbshipit-source-id: 7ed34fd865430975157fd362f51c4a3d64214430
Summary: This diff removes the 'RCT' prefix (if it's present) from the names of the generated Java classes. The motivation is that we don't want to have any Java files having this prefix in the RN Android codebase.
Reviewed By: JoshuaGross
Differential Revision: D17123804
fbshipit-source-id: 31905d3141e0f58ea47cdbdb0cf77d2d105de9a9
Summary: This diff checks in the OSS view manager interfaces and delegates generated by the JS codegen. This is a temporary workaround since we don't have the JS codegen running in open source.
Reviewed By: fkgozali
Differential Revision: D17104816
fbshipit-source-id: 848afc081785c9a78891d3dc0740ebe858eb8891
Ramanpreet Nara
Dulmandakh
Emily Janzer
Krzysztof Magiera
David Vacca
Amir Shalem
Janic Duplessis
Marc Mulcahy
Valentin Shergin
Joshua Gross
Ram N
Sidharth Guglani
Siddhant Soni
Christoph Nakazawa
Petter Hesselberg
Will Holen
Oleg Lokhvitsky
Oleksandr Melnykov
Héctor Ramos
