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:
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:
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:
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: This feature is not necessary any longer with Fast Refresh enabled by default.
Reviewed By: gaearon
Differential Revision: D17156607
fbshipit-source-id: 2396a86d192c6b5d90cbed9cefbf13367dd6b699
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: Same as title. Changing as per suggestion.
Reviewed By: furdei
Differential Revision: D16615807
fbshipit-source-id: 1c35ae1471beb2460e975841f367ffd49ce34494
Summary: This diff implements the Turbo Module SoundManager, this will be used by following diffs of the stack
Reviewed By: JoshuaGross
Differential Revision: D16543430
fbshipit-source-id: 34ba545f54b759fe4e49d4e3c5f8867205de907c
Summary: In Dev Settings, we used to have an `Start Sampling Profiler on init` option, which was defunct. This diff re-enables that option. We can now start the Sampling Profiler on app start
Reviewed By: yinghuitan
Differential Revision: D7022382
fbshipit-source-id: 1db85d8a324e401c71187ba5871a91abcc18acf9
Summary:
@public
`reportException` is a new method on `NativeExceptionsManager` that is designed to allow more structured and flexible JS error reporting. `reportFatalException` and `reportSoftException` are now deprecated.
In addition to all the usual exception fields, `reportException` also accepts an `extraData` property which the JS exception handler can populate with arbitrary JSON-serialisable data (here: the raw stack trace, the current JS engine, and the number of frames popped off the call stack by the exception handler). The contents of `extraData` get attached as JSON to the `JavascriptException` instance (or just logged, in the case of `console.error`).
This change is backwards compatible in two senses:
1. We have a JS fallback that uses `reportFatalException` and `reportSoftException` if the new native method is unavailable.
2. We have a Java fallback that implements `reportFatalException` and `reportSoftException` in terms of `reportException`.
Naturally, both fallbacks mentioned above discard `extraData`.
NOTE: The current implementation is Android-only; for the time being, iOS will continue to use the JS fallback.
While we're in `ExceptionsManager.js`, this also changes `dismissRedbox()` to be optional (which it is, since it's Android-only); existing call sites already guard it with a null check so this requires no other changes.
Reviewed By: mmmulani
Differential Revision: D16133080
fbshipit-source-id: d0b209d58da40b736df63155bbea232e94ce635c
Summary:
This diff migrates the usages Nullable and NonNull annotations to AndroidX instead of javax.
The purpose of this change is to bring consistency in the annotations used by the core of RN
Reviewed By: makovkastar
Differential Revision: D16054504
fbshipit-source-id: 21d888854da088d2a14615a90d4dc058e5286b91
Summary: This diff fixes a potential memory leak which can occur if an exception is thrown inside the try block and `outputStream.close()` is not called. By wrapping `outputStream.write(data)` inside try-with-resource we guarantee that outputStream will be closed regardless of whether the try statement completes normally or abruptly.
Reviewed By: sammy-SC
Differential Revision: D16148850
fbshipit-source-id: c5c0a78b36375857f6e717bb581e8686a4a94bb9
Summary:
[Android] [Added] - Release underlying resources when JS instance is GC'ed on Android
D15826082 was reverted because it introduced a crash in Ads Manager for Android (see P67222724).
This diff fixes the crash and re-applies D15826082. The problem was that `jni::findClassStatic` in the destructor of BlobCollector.cpp couldn't find the Java class `com/facebook/react/modules/blob/BlobModule` and crashed the app.
JNI didn't seem to have access to the Java class loader probably because the destructor was called from a non-Java thread (https://our.intern.facebook.com/intern/wiki/Fbjni/environment-and-thread-management/?vitals_event=wiki_click_navigation_link#threads). The fix is to wrap the code in the destructor inside `ThreadScope::WithClassLoader `, which will allow to run code that has full access to Java as though you were running in a Java thread.
Reviewed By: shergin
Differential Revision: D16122059
fbshipit-source-id: 12f14fa4a58218242a482c2c3e2149bb6770e8ec
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: 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:
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:
[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: 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:
`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: 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: 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:
### 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:
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:
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:
Okay, I think this is the best I can do David, I don't think there's an obvious/easy way for me to try to get `getIdentifier()` to return a non zero value. Setting it to what Spencer suggested works for my use case.
## Changelog
[Android] [Changed] - Update spinner mode to render spinner instead of calendar
Reviewed By: sahrens
Differential Revision: D15427793
fbshipit-source-id: b04f024a9a1f052f69f3bda47d77821782dc2c0e
Summary:
Fixes this issue:
https://github.com/facebook/react-native/issues/24468
It was incorrectly closed by a fix on react-native-community CameraRoll implementation. CameraRoll in react-native still crashes when finding a file with # sign
[Android] [Fix] - Fix Android Camera Roll crash on mime type guessing
Pull Request resolved: https://github.com/facebook/react-native/pull/24780
Reviewed By: mdvacca
Differential Revision: D15281062
Pulled By: lunaleaps
fbshipit-source-id: ca3364c8478d9bfc9a0a6657b531ffb384145d8c
Summary:
AccessibilityInfo.announceForAccessibility is currently only available on iOS. I've added the Android specific implementation, updated RNTester, and the documentation.
[Android] [Added] - Added AccessibilityInfo.announceForAccessibility for Android
[General] [Added] - RNTester example for AccessibilityInfo.announceForAccessibility
Pull Request resolved: https://github.com/facebook/react-native/pull/24746
Differential Revision: D15258054
Pulled By: cpojer
fbshipit-source-id: 3e057a5c32b28e30ea2ee74a18854b012cd2dbfd
Summary: This diff refactors the way we synchronize in ReactChoreographer using a lock object
Reviewed By: ejanzer
Differential Revision: D14913056
fbshipit-source-id: e86c4395d5d3c3fd5b7330b72c14920b536f74ce
Summary:
Now RN has only ReactActivity which extends AppCompatActivity, subclass of FragmentActivity, therefore no need to check if activity is FragmentActivity or not. This PR changes DialogModule to work only with FragmentActivity.
Also DialogFragment from Android is deprecated in API 28, and recommends to use DialogFragment from Support Library. Excerpt from DialogFragment documentation.
> **This class was deprecated in API level 28.**
> Use the Support Library DialogFragment for consistent behavior across all devices and access to Lifecycle.
**BREAKING CHANGE**: Brown field apps must extend FragmentActivity or its subclasses.
[Android] [Changed] - DialogModule supports only FragmentActivity
Pull Request resolved: https://github.com/facebook/react-native/pull/23365
Differential Revision: D14021986
Pulled By: cpojer
fbshipit-source-id: b0ede60ef19cec48111a12701659a8bc1f66c331
Summary:
We are seeing crash reports that the webview is missing. In this case
it should fail gracefully so that a missing webview does not block
from using an app built with React Native.
The contains could also be changed to check for "webview" in general
to catch all webview related exception. It's currently checking on
for the specific string that I'm seeing in our app's crashreporting tool.
<img width="1507" alt="Screen Shot 2019-04-19 at 11 26 19 AM" src="https://user-images.githubusercontent.com/741767/56438307-5e1c2f80-6297-11e9-970b-a5095d18e9d7.png">
<img width="935" alt="Screen Shot 2019-04-19 at 11 32 58 AM" src="https://user-images.githubusercontent.com/741767/56438213-fa920200-6296-11e9-8008-5eb344eca8a8.png">
[Android] [Fixed] - The ReactCookieJarContainer/ForwardingCookieHandler now handles the missing WebView gracefully.
Pull Request resolved: https://github.com/facebook/react-native/pull/24533
Differential Revision: D15062824
Pulled By: cpojer
fbshipit-source-id: 80805a47494f0d924b7ee029ce8ca0504eaeee57
Summary:
React Native has a `NativeModule` to manipulate programmatically the dev menu options (live reload, hot reload, remote debugging, etc), called [`DevSettings`](https://github.com/facebook/react-native/blob/master/React/Modules/RCTDevSettings.mm#L120). However this module is only available for iOS.
This PR brings the same `DevSettings` for Android, making it a cross-platform NativeModule.
Motivation: Right now if your app needs to programmatically reload RN, one option is to install [`react-native-restart`](https://www.npmjs.com/package/react-native-restart). It's a tiny dependency, but it's annoying to have to install it, while the code to do so is inside RN codebase. According to NPM, react-native-restart has ~12k weekly downloads, shows it's a recurring feature for many apps (my case).
Thus making `NativeModules.DevSettings` is a small increment in the codebase, just exposing the dev menu methods, to improve the Development Experience
[Android] [Added] - Add DevSetting native module (making it cross-platform)
With expection of `setIsShakeToShowDevMenuEnabled`, the following methods will be available for both platforms:
* reload
* setHotLoadingEnabled
* setIsDebuggingRemotely
* setIsShakeToShowDevMenuEnabled
* setLiveReloadEnabled
* setProfilingEnabled
* toggleElementInspector
Pull Request resolved: https://github.com/facebook/react-native/pull/24441
Differential Revision: D14932751
Pulled By: cpojer
fbshipit-source-id: 465e6a89c3beb5fd1ea22e80ea02e9438f596a09
Summary: This is removing packages and libraries from the repo. Any modified buck files simply change the redirect targets to something more appropriate (no logic actually changed)
Differential Revision: D14950721
fbshipit-source-id: 6c14f827b76ca1dbaf83dcb983930f362c6a27d4
Summary:
For a small subset of Android devices, the following line of code caused the device to crash
```
output.transferFrom(input, 0, Long.MAX_VALUE);
```
According to the [Java docs](https://docs.oracle.com/javase/1.5.0/docs/api/java/nio/channels/FileChannel.html), this is what the function does.
> Transfers bytes into this channel's file from the given readable byte channel.
An attempt is made to read up to count bytes from the source channel and write them to this channel's file starting at the given position. An invocation of this method may or may not transfer all of the requested bytes; whether or not it does so depends upon the natures and states of the channels. Fewer than the requested number of bytes will be transferred if the source channel has fewer than count bytes remaining, or if the source channel is non-blocking and has fewer than count bytes immediately available in its input buffer.
Hence, using `Long.MAX_VALUE` seemed to be the standard way to transfer all bytes from one channel to the other.
However, it appeared that for some reason on a subset of old Android devices, the device tries to allocate `count` bytes of memory before transferring the bytes. Obviously, this caused a crash because no device has that much memory. This was fixed transferring bytes using a 1MB buffer.
Differential Revision: D14921778
fbshipit-source-id: 7fa46e10c656e23ae7d5679c72b278188f09ad0a
Emily Janzer
Janic Duplessis
Siddhant Soni
Christoph Nakazawa
Dulmandakh Sukhbaatar
Héctor Ramos
Sensen Chen
David Vacca
Ram N
Fred Liu
Min ho Kim
Moti Zilberman
Oleksandr Melnykov
Guilherme Iscaro
Ramanpreet Nara
Joshua Ong
Krzysztof Borowy
Nate
Kody Greenbaum
Hermanyo
Andrea Cimitan
Shen Jin
luancurti
Maciej Srokowski
Alan Kenyon
Thorben Primke
Estevão Lucas
Rick Ratmansky
Alston Lin
Nurzhan Bakibayev
