Summary:
Using Ricky's last changes I managed to subscribe for both new and old event name.
Fixed event to proper one for codegen in native code.
Reviewed By: TheSavior
Differential Revision: D16065660
fbshipit-source-id: b5d3762d673a34bbdf5a8e60ff4d51617c8adb81
Summary: We should annotate `ReactPackageTurboModuleManagerDelegate.getLegacyCxxModule` with `DoNotStrip`, so that ProGuard doesn't strip the method. `ReactPackageTurboModuleManagerDelegate.getModule` doesn't need the annotation because it's used in `TurboModuleManager`.
Reviewed By: fkgozali
Differential Revision: D16097376
fbshipit-source-id: 4b2622e8541fed0ab8fe13b5d0f5d25b58ea39ef
Summary: This diff prevents the execution of MountItems without mounting instructions
Reviewed By: JoshuaGross
Differential Revision: D16063571
fbshipit-source-id: 97ff93c6880c7d8857f61d4998df4327f41fafdd
Summary: The method FabricUIManager.scheduleMountItems receives only one MountItem, is makes more sense to be called FabricUIManager.scheduleMountItem
Reviewed By: JoshuaGross, makovkastar
Differential Revision: D16062749
fbshipit-source-id: a27063be33b644af83ede6a9198edbfb1c3296e1
Summary: I've been analyzing some issue in RN Android code and I noticed some warnings to clean up
Reviewed By: ejanzer
Differential Revision: D16060522
fbshipit-source-id: 327fa86c24c7dd67ac2376bbd2f0ca4339f106d1
Summary: This diff exposes LayoutDirection as part of UpdateLayoutMountItem
Reviewed By: JoshuaGross
Differential Revision: D16060521
fbshipit-source-id: 163bf2a0bdca62dcecb03a8aaa2f4bf595b18c8f
Summary:
This diff adds support to Update Modal State when there is a change on the size of the screen
// TODO
Reviewed By: JoshuaGross
Differential Revision: D16000755
fbshipit-source-id: be87caa6d7f85c3d2778d2707c1e0cd821d6f6c6
Summary: This diff ensures only one thread access the Binding.schedulerDidFinishTransaction method
Reviewed By: shergin
Differential Revision: D15995971
fbshipit-source-id: 31f03803e8829480dd30b9b9148fd09b218ebeab
Summary: After we ran google-java-format D16071725, some Javadocs which weren't properly written broke. This includes putting unordered and ordered lists not using <ul> and <ol>, putting code blocks and pseudo-graphics not using <pre>. I ran through all the changed classes and tried to fix the broken Javadocs.
Reviewed By: cpojer
Differential Revision: D16090087
fbshipit-source-id: f31971cbc0e367a04814ff90bbfb2192751d5e16
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: This fixes an issue that caused us to show a confusing message on the initial load. I guess at some point the field was renamed. The code falls back to the "generic" message if it can't parse JSON, and in this case, it couldn't find the field called `description` as it's now called `message`.
Reviewed By: cpojer
Differential Revision: D16073931
fbshipit-source-id: a70ae28635b72f674cb1da26f89744b4214f18d9
Summary:
Prior to this commit React Native on Android was not properly setting
the transform's scale properly correctly when setting it to 0. In order
to properly set one would need to use values close to 0, like 0.0001.
This was happing due to BaseViewManager sharing sMatrixDecompositionContext
across all views in a React Native app.
In some cases the decomposeMatrix() method from the MatrixMathHelper would
return early and not set any new values in sMatrixDecompositionContext
(this is, the new transform values) and
since this is a shared object the BaseViewManager would set the transform values
from the a previous transform.
In order to prevent this issue, before setting the new transform values
always reset the sMatrixDecompositionContext values.
## Changelog
[Android] [Fixed] - Reset sMatrixDecompositionContext before applying transformations
Pull Request resolved: https://github.com/facebook/react-native/pull/25438
Test Plan:
Run the code below on an Android device/emulator and you should see the following results:
### Android without the patch - current implementation
Notice that the scale 0 is not properly applied to the last rectangle and the second rectangle does not animate properly.

### Android with the patch
Everything works fine

### iOS - current implementation
Everything works fine

```javascript
/**
* Sample React Native App
* https://github.com/facebook/react-native
*
* format
* flow
*/
import React from 'react';
import { Animated, Button, StyleSheet, View, Text, SafeAreaView } from 'react-native';
const HorizontalContainer = ({ children, title }) => (
<View style={styles.horizontalContainer}>
{children}
<Text style={styles.text}>{title}</Text>
</View>
);
const App = () => {
const animValue1 = React.useRef(new Animated.Value(1)).current;
const animValue2 = React.useRef(new Animated.Value(1)).current;
const onStartAnim = React.useCallback(() => {
animValue1.setValue(0);
animValue2.setValue(0);
Animated.sequence([
Animated.timing(animValue1, {
toValue: 1,
duration: 300,
useNativeDriver: true,
}),
Animated.timing(animValue2, {
toValue: 1,
delay: 700,
duration: 300,
useNativeDriver: true,
})
]).start();
}, [animValue1, animValue2]);
return (
<SafeAreaView style={styles.container}>
<Button title="Start Animation" onPress={onStartAnim} />
<HorizontalContainer title="Animated scale from 0 to 1">
<Animated.View style={[styles.view, { transform: [{ scaleX: animValue1 }] }]} />
</HorizontalContainer>
<HorizontalContainer title="Animated scale from 0 to 1 - delayed">
<Animated.View style={[styles.view, { transform: [{ scaleX: animValue2 }] }]} />
</HorizontalContainer>
<HorizontalContainer title="Scale 0.4">
<View style={[styles.view, { transform: [{ scaleX: 0.4 }] }]} />
</HorizontalContainer>
<HorizontalContainer title="Scale 0.2">
<View style={[styles.view, { transform: [{ scaleX: 0.2 }] }]} />
</HorizontalContainer>
<HorizontalContainer title="Scale 0">
<View style={[styles.view, { transform: [{ scaleX: 0 }, { translateY: 100 }] }]} />
</HorizontalContainer>
</SafeAreaView>
);
};
export default App;
const styles = StyleSheet.create({
text: {
fontSize: 10,
color: 'black',
marginLeft: 10,
},
horizontalContainer: {
justifyContent: 'center',
alignItems: 'center',
flex: 1,
flexDirection: 'row',
},
container: {
flex: 1,
justifyContent: 'center',
alignItems: 'center',
backgroundColor: '#F5FCFF',
},
view: {
width: 100,
height: 100,
backgroundColor: 'indigo',
marginVertical: 5,
}
});
```
Closes https://github.com/facebook/react-native/issues/25205
Closes https://github.com/facebook/react-native/issues/6278
Closes https://github.com/facebook/react-native/issues/6278
Differential Revision: D16071126
Pulled By: cpojer
fbshipit-source-id: 50820229db2e3c22cf6296831413d26b42f57070
Summary: The metheod viewIsDescendantOf is not used anymore, this diff removes it from Android code
Reviewed By: fkgozali
Differential Revision: D16014664
fbshipit-source-id: e189be38a02cdf5c07ceab13454d52ab842fd0ca
Summary:
ScrollView doesn't handle the scrollEnabled property using dpad. When set to false, the directionnal pad still allows to scroll in the view.
## Changelog
[ANDROID] [ADDED] - Prevent scrollView to scroll with dpad when scrollEnabled property is set to false.
Pull Request resolved: https://github.com/facebook/react-native/pull/25309
Test Plan:
Add P67680731 to Playground.js and start the Catalyst Android app:
```buck install -r catalyst```
Send the following adb commands to the device/emulator:
```adb shell input keyevent DPAD_RIGHT_LEFT```
```adb shell input keyevent DPAD_RIGHT_RIGHT```
Make sure the ScrollView doesn't scroll to the left and right.
Add ```horizontal={true}``` to ScrollView and send the following adb commands to the device/emulator:
```adb shell input keyevent DPAD_RIGHT_TOP```
```adb shell input keyevent DPAD_RIGHT_BOTTOM```
Make sure the ScrollView doesn't scroll to the top and bottom.
Reviewed By: mdvacca
Differential Revision: D15983785
Pulled By: makovkastar
fbshipit-source-id: 678cc801a168531d71c8651b986c99ecd9da400e
Summary: `ReactPackageTurboModuleManagerDelegate.getLegacyCxxModule` isn't called from Java. Therefore, ProGuard will strip this method to reduce code size. To prevent this, we need to add the `DoNotStrip` annotation to this method. This annotation isn't necessary for the `getModule` method, since `getModule` is used in `TurboModuleManager.getJavaModule`.
Reviewed By: fkgozali
Differential Revision: D15996432
fbshipit-source-id: d34a7d28f7678e2dfc917f52d5cacc286bc33a0a
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: The method ReactChoreographer.postFrameCallbackOnChoreographer should be private and it should be called from a context that contains the lock mCallbackQueuesLock
Reviewed By: JoshuaGross
Differential Revision: D15891758
fbshipit-source-id: fedba0db663aade25dbad1ef7151df1e340e05f6
Summary: This diff extends the ReactChoreographer to allow the execution of FrameCallbacks that removes another FrameCallback from the mCallbackQueues.
Reviewed By: ejanzer
Differential Revision: D15891759
fbshipit-source-id: 62bc2b6afac45c50ac18771b0821742b4f7fc10e
Summary:
Right now JS triggers a view manager command with the following code:
```
UIManager.dispatchViewManagerCommand(
ReactNative.findNodeHandle(this),
UIManager.getViewManagerConfig('RCTView').Commands.hotspotUpdate,
[destX || 0, destY || 0],
);
```
As we want to get rid of calls to UIManager, we need to stop looking for the integer defined in native from JavaScript. We will be changing methods like this to be:
```
UIManager.dispatchViewManagerCommand(
ReactNative.findNodeHandle(this),
'hotspotUpdate',
[destX || 0, destY || 0],
);
```
We need to support ints and Strings to be backwards compatible, but ints will be deprecated.
Reviewed By: shergin
Differential Revision: D15955444
fbshipit-source-id: d1c488975ae03404f8f851a7035b58a90ed34163
Summary:
We have too many options in the Dev Menu, and they're really hard to pick from. They're also somewhat conflicting. This replaces two menu choices that have a similar purpose (faster iteration cycle) with one.
"Fast Refresh" tries to only update the affected modules, but falls back to doing a full reload if the update can't be handled by the React components.
If for some reason you prefer the "Reload-on-Save" behavior, please:
- Reach out to me so I can learn more about your use case.
- As a workaround, you can add `if (__DEV__) require.Refresh.forceFullRefresh = true` to your app's entry point to always do a full refresh.
Also note that I only removed the user-facing part of "Reload-on-Save". So if you have automation depending on it, that's gonna keep working.
I moved it above Systrace since it's a more generic feature.
As a total aside nit, I renamed "Enable Inspector" and "Disable Inspector" to "Show Inspector" and "Hide Inspector" because... that's what those options do, really.
Reviewed By: rickhanlonii
Differential Revision: D15958697
fbshipit-source-id: 20e856d56f661fe4d39b5ab47d8c44754bf70f67
Summary:
As we saw in D15947985, and later traced down to D5623623, the `hot` option isn't used by Metro anymore. The relevant transforms _always_ run in DEV regardless of the option.
Given that, it doesn't make sense that enabling or disabling Hot Reloading forces a full refresh. This significantly raises the usage barrier because **currently, you might have to wait ~20 seconds (on a large app) to just start using Hot Reloading when you're already in the middle of some screen.** So you just end up not using it.
This diff changes enabling/disabling Hot Reloading to be _instant_.
Here's how it works:
1. Now we always send the necessary info to the client via the new `HMRClient.setup()` function. It creates a Metro HMR client instance, but only actually sets up the socket if Hot Reloading is on.
2. The "Enable Hot Reloading" menu no longer forces a reload. Instead, it calls `HMRClient.enable()` which lazily sets up a socket (at most once).
3. The "Disable Hot Reloading" menu also doesn't trigger a refresh now. Instead, it calls `HMRClient.disable()`. We don't actually tear down the socket here because it's a pain to deal with race conditions and such. Instead, we keep the connection — but we _ignore the updates_ that come in while we're disabled.
4. As a result, it is possible to enable and disable it many times during a single session. (Updates while disabled would be ignored — which has a risk of making your running app inconsistent — but I'd argue it's expected and is worth it. You can always save a particular file to force it to update once the mode is on.)
5. In order to support "ignoring" updates, Metro's `HMRClient` (not to be confused with RN's module) now supports a `shouldApplyUpdates` field. The RN module uses it to disable handling updates when the mode is off.
6. In case there is an error that makes hot reloading unavailable (such as the server disconnecting), we surface the error only if the mode is on. If the mode is off, we stash the error message in the `_hmrUnavailableReason` variable, and display it next time you try to enable Hot Reloading.
Reviewed By: rickhanlonii
Differential Revision: D15958160
fbshipit-source-id: 8256fc4d5c2c3f653a78edf13b8515a5671953e4
Summary: Passing whether layout cache or measure cache was used or not
Reviewed By: davidaurelio
Differential Revision: D15920937
fbshipit-source-id: a6728e7af07ea228a285f824fbdfddc8130c5990
Summary: This diff fixes a typo in the JavaDoc for ReactScrollViewManager.
Reviewed By: cpojer
Differential Revision: D15965028
fbshipit-source-id: 3506cdde21c8d00ab916455a2d9fa29772f35359
Summary:
On Android, if the ActivityIndicator component is initially set to `animate={false}`, it does not display if later set to `true` (https://github.com/facebook/react-native/issues/9023)
For some reason, the layout width/height of the associated ProgressBar remains 0, despite the parent layout having the correct width/height:

I wasn't able to determine why this is the case, but I did notice that changing the visibility settings from `View.GONE` to `View.INVISIBLE` fixes the issue while not (as far as I can tell) having an impact on the React Native layout:
#### Before:

#### After:

Using `View.INVISIBLE` appears to alleviate the issue.
This should fix https://github.com/facebook/react-native/issues/9023
## Changelog
[Android][fixed] - ActivityIndicator appears as expected when `animated={false}` is later set to `true`.
Pull Request resolved: https://github.com/facebook/react-native/pull/25354
Test Plan:
Link this branch to a new React native project with the following App.js class:
```javascript
import React, { Component } from "react";
import {
StyleSheet,
Text,
Button,
View,
ActivityIndicator,
TouchableHighlight
} from "react-native";
export default class App extends Component {
constructor() {
super();
this.state = {
show: false
};
}
hide = () => {
this.setState({ show: false });
};
show = () => {
this.setState({ show: true });
};
render() {
return (
<View>
<ActivityIndicator
animating={this.state.show}
size="large"
style={styles.indicator}
/>
<ActivityIndicator
animating={this.state.show}
size="small"
style={styles.indicator}
/>
<View style={{ flexDirection: "row" }}>
<Button title="Hide" style={styles.button} onPress={this.hide} />
<Button title="Show" style={styles.button} onPress={this.show} />
</View>
<Text>Showing ? {this.state.show.toString()}</Text>
</View>
);
}
}
const styles = StyleSheet.create({
indicator: {
borderColor: "red",
borderWidth: 1
},
button: {
marginRight: 8
}
});
```
Differential Revision: D15963366
Pulled By: cpojer
fbshipit-source-id: ee3df3fd84acbff342599dc6f4f4a391704876fa
Summary:
Bump Fresco to 2.0.0, which supports AndroidX. We should cherry-pick to 0.60 release, to support brown field apps but also native components.
## Changelog
[Android] [Changed] - Bump Fresco to 2.0.0, supports AndroidX
Pull Request resolved: https://github.com/facebook/react-native/pull/25358
Test Plan: CI is green, and RNTester builds and runs as expected.
Differential Revision: D15959443
Pulled By: mdvacca
fbshipit-source-id: 58ba2c3e4d1342014d6ea632cd865b4f413548d9
Summary:
I found that on Android we only support 2 fontWeight options, either **normal** or **bold**, even developer can set any numeric value. But iOS supports all possible numeric values. This PR tries to add support for all possible numeric values on Android, even if it's supported only on Android P(28) and above.
This change might break texts where fontWeight use improperly, because this PR removes conversion of values above 500 to BOLD and below 500 to normal.
FYI, also moved **mCustomTypefaceCache** usage up because it was working after unnecessary mFontCache usage.
## Changelog
[Android] [Changed] - add custom font weight support to Text component on Android, only on P(API 28) and above versions.
Pull Request resolved: https://github.com/facebook/react-native/pull/25341
Test Plan: RNTester app's Text examples will show Rubik Regular, Rubik Light, Rubik Bold, Rubik Medium and Rubik Medium Italic texts in corresponding font family, style and weights.
Differential Revision: D15956350
Pulled By: mdvacca
fbshipit-source-id: 61079d953c65fb34ab4497d44c22317912a5a616
Summary: Removing the UiThread annotation from MountingManager.addRootView() because it doesn't seem like it's needed.
Reviewed By: mdvacca
Differential Revision: D15945819
fbshipit-source-id: 0cb9bfb2fe2889001f1c061a07518cf9734f0c16
Summary:
Similar to D15909582, this change makes the Android TextInput take strings for the value of autoCapitalize and not just numbers. As we are going to stop sending view configs from native and instead hardcode them in JS we can't do that anymore.
In this commit we are supporting the old style as well as the new style.
Changelog:
[Android] [Internal] - Supporting autoCapitalize as string to clean up internal TextInput.js file
Reviewed By: mdvacca
Differential Revision: D15911323
fbshipit-source-id: b236fdb314489cc1ef33f9214ff2d6b0e28b7310
Summary:
Previously DrawerLayoutAndroid required taking an int as the drawerPosition. This required a complex dance of pulling these constant values off of the native view config. As we are going to stop sending view configs from native and instead hardcode them in JS we can't do that anymore.
In this commit we are supporting the old style as well as the new style. The old way of specifying the sizes will go away in a future release.
Changelog:
[Android][Added] - DrawerLayoutAndroid now supports strings and not just numbers for drawerPosition.
Reviewed By: mdvacca
Differential Revision: D15912607
fbshipit-source-id: b444454a1e74f8f659995b9ebe5e164ac9660138
Summary: This diff adds extra logging in FabricUIManager, this will be useful to debug production issues
Reviewed By: JoshuaGross
Differential Revision: D15907520
fbshipit-source-id: 94e16444af3c023b6c4837c4797404d3debe8e95
Summary:
Since Ads Manager for Android is crashing when a user tries to log in, I'm reverting D15826082 for now. Will investigate the reason of the crash later.
Crashlog: P67222724
Reviewed By: cpojer
Differential Revision: D15939152
fbshipit-source-id: bc1276e6057418821e1ebd90203bea586943b633
Summary:
Prior to this patch the websocket protocol was not being set when a connection
was opened, which could cause client libraries and apps to not work properly.
According to the [whatwg] spec the protocol must be set once the connection is
estabilished.
[whatwg]: https://html.spec.whatwg.org/multipage/web-sockets.html#feedback-from-the-protocol
## Changelog
[Javascript] [Fixed] - Properly set the this.protocol on WebSocket open
[Android] [Fixed] - Send the server chosen protocol to the WebSocket object
[iOS] [Fixed] - Send the server chosen protocol to the WebSocket object
Pull Request resolved: https://github.com/facebook/react-native/pull/25273
Test Plan:
In order to reproduce the issue you **need to install wampy@6.2.1**. Since **wampy@6.2.2** and newer contains a workaround for this react-native bug.
https://www.npmjs.com/package/wampy
```javascript
/**
* Sample React Native App
* https://github.com/facebook/react-native
*
* format
* flow
*/
import React, { Component } from 'react';
import { Platform, StyleSheet, Text, View } from 'react-native';
import Wampy from "wampy";
const instructions = Platform.select({
ios: 'Press Cmd+R to reload,\n' + 'Cmd+D or shake for dev menu',
android:
'Double tap R on your keyboard to reload,\n' +
'Shake or press menu button for dev menu',
});
type Props = {};
export default class App extends Component<Props> {
state = {conState: 'Initializing...'};
componentDidMount() {
const url = "wss://demo.crossbar.io/ws";
const ws = new Wampy(url, {
realm: "crossbardemo",
ws: WebSocket,
debug: true,
onConnect: () => {
console.log("WAMP onConnect");
this.setState({conState: 'Connected'});
},
onClose: () => {
console.log("WAMP onClose");
this.setState({conState: 'Connection closed'});
},
onError: () => {
console.log("WAMP onError");
this.setState({conState: 'Connection Error'});
}
});
}
render() {
return (
<View style={styles.container}>
<Text style={styles.message}>{this.state.conState}</Text>
</View>
);
}
}
const styles = StyleSheet.create({
container: {
flex: 1,
justifyContent: 'center',
alignItems: 'center',
backgroundColor: '#F5FCFF',
},
message: {
fontSize: 20,
color: 'black'
},
});
```
Using the code above one must see the message **WAMP onConnect** on Console and **Connected** in the middle of the screen
Closes https://github.com/facebook/react-native/issues/24796
Differential Revision: D15938870
Pulled By: cpojer
fbshipit-source-id: 10a0a9b40c2a69e484ead37149abc2b1158a4ffc
Summary:
This is a follow up PR to https://github.com/facebook/react-native/issues/24359. There's a good thread in the mentioned PR for more background for why I'm doing this change. Essentially `focusable` makes more sense since it is about whether a view can receive user-initiated focus from a pointer or keyboard.
Pull Request resolved: https://github.com/facebook/react-native/pull/25274
Differential Revision: D15873739
Pulled By: cpojer
fbshipit-source-id: 0f526bb99ecdc68131dfc10200a5d44c2ef75b33
Summary:
Add event key action for Android EventHandler events, helps to know if the key event is a up (key release, value is 1) or down (key pressed, value is 0) action.
## Changelog
[ANDROID] [ADDED] - Add event key action to EventHandler events.
Pull Request resolved: https://github.com/facebook/react-native/pull/25300
Test Plan: No test added
Differential Revision: D15897484
Pulled By: cpojer
fbshipit-source-id: fdb3d5413d9da3dd5f46d41e31ac60f0b341f3eb
Summary:
Previously SwipeRefreshLayout (RefreshControl on Android) required taking an int as the size. This required a complex dance of pulling these constant values off of the native view config. As we are going to stop sending view configs from native and instead hardcode them in JS we can't do that anymore.
We will change the type of size from:
```
size?: ?(
| typeof RefreshLayoutConsts.SIZE.DEFAULT
| typeof RefreshLayoutConsts.SIZE.LARGE
),
```
to:
```
size?: ?('default' | 'large')
```
In this commit we are supporting the old style as well as the new style. The old way of specifying the sizes will go away in a future release.
Changelog:
[Android] [Added] - RefreshControl now supports strings and not just numbers for size.
Reviewed By: mdvacca
Differential Revision: D15909582
fbshipit-source-id: 1849edc980e1698de147e88d710e0f28d0fdc8d8
Summary:
[Android] [Added] - Release underlying resources when JS instance is GC'ed on Android
D15279651 introduced a crash for Oculus Twilight on Android (T45199437), so it was reverted by D15611385.
This diff fixes the crash and re-applies D15279651. The problem was that ProGuard renamed BlobModule.remove() to BlobModule.release(), but the C++ code in `BlobCollector.cpp` still expected the old name. I confirmed this by looking at the Extracted Symbols file for the build which introduces the crash (https://fburl.com/mobile/ud40od3i):
```
com.facebook.react.modules.blob.BlobModule -> com.facebook.react.modules.blob.BlobModule:
...
8190:8193:void remove(java.lang.String):190:193 -> release
...
```
See the full log file here: https://fburl.com/pn02bwkb.
The solution is to annotate the method with `DoNotStrip` so that ProGuard doesn't rename it.
Reviewed By: mdvacca, cpojer
Differential Revision: D15826082
fbshipit-source-id: f7470d394666cd34c1acae5c6ffaecc84d5ca5a3
Summary: Previously, we didn't provide any LayoutContext to the very first commit (aka startSurface); apparently it causes problems.
Reviewed By: mdvacca
Differential Revision: D15891472
fbshipit-source-id: b2a785bdad5764eb97b41f5bf5679807107bd8a0