Summary:
Starting August 2018, Google Play will require targetSdkVersion 26 for new applications, and November 2018 for application updates.
This PR will use Android build tools 26.0.3 and compilerSdk 26, then support library version 26.0.2 to make targeting 26 easier in the future.
I think this PR will help to people compile and test their applications, thus make transition easier (smoother). Also we'll have opportunity and time to migrate code to target 26.
https://github.com/facebook/react-native/issues/18095
React Native on android must work as usual
Closes https://github.com/facebook/react-native/pull/19257
Differential Revision: D8010354
Pulled By: mdvacca
fbshipit-source-id: 63ba03585e918b38c2a2adb5d2f2e85d7ce46fae
Summary:
Fresco now maintain proguard rules by itself (https://github.com/facebook/fresco/pull/2075), so it won't be necessary for react native copy its rules.
Run RNTTester Android app in release mode, app build successful and won't crash in ImageModule.
none
[ANDROID] [BUGFIX] [PROGUARD] - remove fresco proguard rules
Closes https://github.com/facebook/react-native/pull/19040
Differential Revision: D7992146
Pulled By: hramos
fbshipit-source-id: 9ee3dd4c6756472395ec9e36a967b469f0760999
Summary:
<!--
Required: Write your motivation here.
If this PR fixes an issue, type "Fixes #issueNumber" to automatically close the issue when the PR is merged.
-->
Fixes a crash with the Android Dialog. This occurs when the Activity is finishing or has been removed and React Native requests the modal to be shown.
Stacktrace here:
```
Caused by android.view.WindowManager$BadTokenException: Unable to add window -- token android.os.BinderProxy@f125ea3 is not valid; is your activity running?
at android.view.ViewRootImpl.setView(ViewRootImpl.java:683)
at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:319)
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:85)
at android.app.Dialog.show(Dialog.java:326)
at com.facebook.react.views.modal.ReactModalHostView.showOrUpdate(ReactModalHostView.java:256)
at com.facebook.react.views.modal.ReactModalHostManager.onAfterUpdateTransaction(ReactModalHostManager.java:107)
at com.facebook.react.views.modal.ReactModalHostManager.onAfterUpdateTransaction(ReactModalHostManager.java:28)
at com.facebook.react.uimanager.ViewManager.updateProperties(ViewManager.java:35)
at com.facebook.react.uimanager.NativeViewHierarchyManager.createView(NativeViewHierarchyManager.java:233)
at com.facebook.react.uimanager.UIViewOperationQueue$CreateViewOperation.execute(UIViewOperationQueue.java:153)
at com.facebook.react.uimanager.UIViewOperationQueue$1.run(UIViewOperationQueue.java:816)
at com.facebook.react.uimanager.UIViewOperationQueue.flushPendingBatches(UIViewOperationQueue.java:929)
at com.facebook.react.uimanager.UIViewOperationQueue.access$2100(UIViewOperationQueue.java:47)
at com.facebook.react.uimanager.UIViewOperationQueue$2.runGuarded(UIViewOperationQueue.java:887)
at com.facebook.react.bridge.GuardedRunnable.run(GuardedRunnable.java:21)
at android.os.Handler.handleCallback(Handler.java:815)
at android.os.Handler.dispatchMessage(Handler.java:104)
at android.os.Looper.loop(Looper.java:207)
at android.app.ActivityThread.main(ActivityThread.java:5728)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:789)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:679)
```
Related issues: #18570 & #18634
mdvacca added to this file in e5c2a66897
Doesn't look like the issue was introduced in the above change, but it masks the issue. The wrapping if block should not allow a null activity to display a dialog.
<!--
Required: Write your test plan here. If you changed any code, please provide us with
clear instructions on how you verified your changes work. Bonus points for screenshots and videos!
-->
Run sample app on Android and display dialog when app is about to close.
<!--
Required.
Help reviewers and the release process by writing your own release notes. See below for an example.
-->
[ANDROID] [BUGFIX] [Modal] - Fix Android BadTokenException crash
<!--
**INTERNAL and MINOR tagged notes will not be included in the next version's final release notes.**
CATEGORY
[----------] TYPE
[ CLI ] [-------------] LOCATION
[ DOCS ] [ BREAKING ] [-------------]
[ GENERAL ] [ BUGFIX ] [ {Component} ]
[ INTERNAL ] [ ENHANCEMENT ] [ {Filename} ]
[ IOS ] [ FEATURE ] [ {Directory} ] |-----------|
[ ANDROID ] [ MINOR ] [ {Framework} ] - | {Message} |
[----------] [-------------] [-------------] |-----------|
EXAMPLES:
[IOS] [BREAKING] [FlatList] - Change a thing that breaks other things
[ANDROID] [BUGFIX] [TextInput] - Did a thing to TextInput
[CLI] [FEATURE] [local-cli/info/info.js] - CLI easier to do things with
[DOCS] [BUGFIX] [GettingStarted.md] - Accidentally a thing/word
[GENERAL] [ENHANCEMENT] [Yoga] - Added new yoga thing/position
[INTERNAL] [FEATURE] [./scripts] - Added thing to script that nobody will see
-->
Closes https://github.com/facebook/react-native/pull/18996
Differential Revision: D7938147
Pulled By: hramos
fbshipit-source-id: f4ffd1746304d6184d727339072a7e926ffdaf39
Summary: Adds information which type of delta client is used (if at all) to the `BundleInfo` object.
Reviewed By: fromcelticpark
Differential Revision: D7845139
fbshipit-source-id: e4bf6cda62c71a78aaff97aa69daec263e6d3cdf
Summary:
Adds support for native clients to `ReactAndroid`:
- `.devsupport.BundleDeltaClient` is now abstract with two implementations: the existing Java client, and a native client
- `BundleDeltaClient#processDelta(...)` can now return a native delta client object
- if that client object is non-null, the bridge is started up with that client rather than a script written to disk
Reviewed By: fromcelticpark
Differential Revision: D7845135
fbshipit-source-id: 379a9c6f9319c62eec3c370cda9ffa0969266a29
Summary: Adds glue between `CatalystInstance` and `JSBundleLoader`: Adds the possibility to create a `JSBundleLoader` instance that calls into `CatalystInstanceImpl#loadScriptFromDeltaBundle(...)`.
Reviewed By: fromcelticpark
Differential Revision: D7845134
fbshipit-source-id: 9585b44a6e7c63245c9f634543642be55c928896
Summary:
Adds the possibility to disable native delta clients in `DevInternalSettings`
Depending on the bridge in use, there might not be support for native delta clients, but since the settings are shared app-wide, it can not be enabled individually.
Reviewed By: johnislarry
Differential Revision: D7845137
fbshipit-source-id: ab368e6fed0f4bec49032c4a20466e156d20fdae
Summary:
Adds `loadScriptFromDeltaBundle` / `jniLoadScriptFromDeltaBundle` methods to `CatalystInstanceImpl`.
These methods allow to run JS coming from a native delta client as RAM bundles, to leverage the RAM bundle mechanism for development / reload scenarios.
Reviewed By: fromcelticpark
Differential Revision: D7845140
fbshipit-source-id: b79b340f36c28939a31eb63a3c463d0792a208f7
Summary:
Adds hybrid JNI wrapper class that can hold a native delta client.
This class allows Java code in the `devsupport` package to hold onto a native delta client across reloads.
It also takes care of passing `okhttp` response objects to native code, where we build a `std::string` to hold JSON messages coming from Metro, and parse them with `folly::parseJson`.
In a follow-up, we will switch to a streaming-friendly binary format that will make allocating memory for the whole message unnecessary.
Reviewed By: fromcelticpark
Differential Revision: D7845138
fbshipit-source-id: 7a29b30645331addf843097dd0d05c03b3143991
Summary:
Adds C++ delta client that keeps modules in memory, and can be used as a RAM bundle.
For now, this client expects a `folly::dynamic` object as payload for patches, i.e. the JSON response retrieved from Metro needs to be parsed with `folly::parseJson` by the caller.
In the future, we will replace JSON with a streaming friendly binary format.
Reviewed By: fromcelticpark
Differential Revision: D7845136
fbshipit-source-id: f003f98a2607c8354c427a7e60e01e19e20295b1
Summary:
Adds a menu item to enable handling of JS module deltas in native code.
The check box is dependent on JS Deltas being activated in the first place.
Reviewed By: cpojer
Differential Revision: D7380167
fbshipit-source-id: 3001d12140542b4e52b1ce96be3c5f56e52a15f8
Summary:
Fixing from call response.body.string() twice in DevServerHelper.java.
https://github.com/square/okhttp/issues/1240#issuecomment-68142603
I'm getting error like this
```
05-01 21:16:47.080 22836-23064/com.my.company.bundle E/AndroidRuntime: FATAL EXCEPTION: OkHttp Dispatcher
Process: com.my.company.bundle, PID: 22836
java.lang.IllegalStateException: closed
at okio.RealBufferedSource.rangeEquals(RealBufferedSource.java:398)
at okio.RealBufferedSource.rangeEquals(RealBufferedSource.java:392)
at okhttp3.internal.c.a(Util.java:449)
at okhttp3.v.string(ResponseBody.java:174)
at com.facebook.react.devsupport.f$8.onResponse(DevServerHelper.java:487)
at com.newrelic.agent.android.instrumentation.okhttp3.CallbackExtension.onResponse(CallbackExtension.java:41)
at okhttp3.s$a.c(RealCall.java:153)
at okhttp3.internal.b.run(NamedRunnable.java:32)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
at java.lang.Thread.run(Thread.java:764)
```
<!--
Required: Write your motivation here.
If this PR fixes an issue, type "Fixes #issueNumber" to automatically close the issue when the PR is merged.
-->
- In my case, My device is using a Proxy, and tried to connect the packager. When it failed from connecting packager through websocket, It crash by this line of code.
<!--
Required: Write your test plan here. If you changed any code, please provide us with
clear instructions on how you verified your changes work. Bonus points for screenshots and videos!
-->
<!--
Does this PR require a documentation change?
Create a PR at https://github.com/facebook/react-native-website and add a link to it here.
-->
<!--
Required.
Help reviewers and the release process by writing your own release notes. See below for an example.
-->
[ANDROID] [BUGFIX] [DevServerHelper] - fixing from calling body.string() twice.
<!--
**INTERNAL and MINOR tagged notes will not be included in the next version's final release notes.**
CATEGORY
[----------] TYPE
[ CLI ] [-------------] LOCATION
[ DOCS ] [ BREAKING ] [-------------]
[ GENERAL ] [ BUGFIX ] [ {Component} ]
[ INTERNAL ] [ ENHANCEMENT ] [ {Filename} ]
[ IOS ] [ FEATURE ] [ {Directory} ] |-----------|
[ ANDROID ] [ MINOR ] [ {Framework} ] - | {Message} |
[----------] [-------------] [-------------] |-----------|
EXAMPLES:
[IOS] [BREAKING] [FlatList] - Change a thing that breaks other things
[ANDROID] [BUGFIX] [TextInput] - Did a thing to TextInput
[CLI] [FEATURE] [local-cli/info/info.js] - CLI easier to do things with
[DOCS] [BUGFIX] [GettingStarted.md] - Accidentally a thing/word
[GENERAL] [ENHANCEMENT] [Yoga] - Added new yoga thing/position
[INTERNAL] [FEATURE] [./scripts] - Added thing to script that nobody will see
-->
Closes https://github.com/facebook/react-native/pull/19088
Differential Revision: D7853822
Pulled By: mdvacca
fbshipit-source-id: c11a73ce2fa6d40b0a7bd8bc0fca7b07c6bc27ed
Summary:
There is a race condition stemming from `ReactRootView.onCreate` that occasionally causes the initial root layout calculation to never occur. In this method currently, `updateRootLayoutSpecs(...)` is called before `enableLayoutCalculation()`, meaning that it's possible for the native modules thread to reach `UIImplementation.updateViewHierarchy` before layout calculation has been enabled (i.e. before the rootViewTag is added to `UIImplementation.mMeasuredRootNodes` on the UI thread).
When this occurs, `UIImplementation.applyUpdatesRecursive` is never called. This causes the app to hang on the splash screen indefinitely, the JS never gets past the first call to `render`, and no layout events are ever sent to the JS.
This PR reverses the order of those two method calls to ensure that the rootViewTag is always added to `mMeasuredRootNodes` before `UIImplementation.updateViewHierarchy` expects it. We inspected all of the code paths of both `enableLayoutCalculation()` and `updateRootLayoutSpecs()` to ensure that in this new order, the rootViewTag will *always* be added to `mMeasuredRootNodes` before the call to `updateViewHierarchy` is dispatched, and that no other side effects would be introduced.
Tested with an app that reliably had this issue (hanging splash screen) on 1 out of every ~10 launches. Logged values to ensure that empty `mMeasuredRootNodes` was the difference between failed and successful launches. After this change, I launched the same app 50+ times without any issues.
[ANDROID][BUGFIX][ReactRootView] - remove race condition in initial layout of ReactRootView
Closes https://github.com/facebook/react-native/pull/19038
Differential Revision: D7834270
Pulled By: hramos
fbshipit-source-id: 6040da900f807dcacbc86ae2c36b4ca004f80178
Summary: Adds the name of the active JS executor when logging the `CREATE_REACT_CONTEXT_START` marker.
Reviewed By: fromcelticpark
Differential Revision: D7800760
fbshipit-source-id: d5090a9f90cf4b7bcfb7218e75621becebd70675
Summary: adds a `getName()` method to all `JavaScriptExecutor` classes that can be used by `ReactInstanceManager` to identify the bridge type when logging markers.
Reviewed By: fromcelticpark
Differential Revision: D7790531
fbshipit-source-id: efe485588738a38936accc4a7956840784b2dd08
Sebastian Markbage
David Vacca
Dmitry Zakharov
Oleg Lokhvitsky
Taras Tsugrii
Héctor Ramos
Dulmandakh
gengjiawen
Eli White
Andrew Chen (Eng)
Marc Horowitz
Andrew Jack
David Aurelio
Jacky Wijaya
Eric Samelson
Himabindu Gadupudi