* Using optimized V8 bins
* Updating V8 nuget version in build.gradle
* Ensuring aar published by npm has libs
* Removing code cooment which is no more required
Fix to React.xcodeproj/project.pbxproj to include JSCExecutorFactory.mm in tvOS target.
Fix to package.json/yarn.lock to update detox to 12.2.0 so that it works in macOS Mojave and later.
Fix to scripts/react-native-xcode.sh so that ip.txt is not written for mac RNTester builds.
Summary:
Upgrading the CLI to the latest with a bunch of fixes and features included.
## Changelog
[General] [Changed] - Bump CLI to 2.0.0-rc.0
Pull Request resolved: https://github.com/facebook/react-native/pull/25175
Differential Revision: D15694764
Pulled By: cpojer
fbshipit-source-id: 25fbf1c275ed5379e1cdb372512b6bb6327dea92
# Conflicts:
# jest/hasteImpl.js
# package.json
# yarn.lock
Summary:
Fixes#22752
On line 1021 you are passing base style to props:
`style: [baseStyle, this.props.style],`
Explicitly passing base style to ScrollView just overrides this line and doesn't let developers to customise style of any inheritors of ScrollView (not only FlatList) with custom RefreshControl.
So this line (1113) seems to be removed.
## Changelog
[GENERAL] [Fixed] - fix of Android's bug that doesn't let override ScrollView's Style with custom RefreshControl.
Pull Request resolved: https://github.com/facebook/react-native/pull/24411
Differential Revision: D15713061
Pulled By: cpojer
fbshipit-source-id: 461259800f867af15e53e0743a5057ea4528ae69
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:
Fixes build in Xcode 11 beta, the signature for `__unused` was changed. This adds a new check for the new style.
## Changelog
[iOS] [Fixed] - Xcode 11 beta build
Pull Request resolved: https://github.com/facebook/react-native/pull/25146
Differential Revision: D15628404
Pulled By: cpojer
fbshipit-source-id: 781a188a0e1562a3316fbe62920b12b03a44e4a7
Summary:
The accessibilityActions accessors in UIView+React.m are not aligned with the property declaration in the header file.
## Changelog
[General] [Fixed] - Fix accessibilityActions accessors
Pull Request resolved: https://github.com/facebook/react-native/pull/25134
Differential Revision: D15621848
Pulled By: cpojer
fbshipit-source-id: f344689292ae7988e46d0d4263980306d364366b
Summary:
Co-Authored: zamotany
With React Native 0.59.8 the app keeps crashing with indexed RAM bundle on Android with the following error:
```
2019-05-09 11:58:06.684 2793-2856/? E/AndroidRuntime: FATAL EXCEPTION: mqt_js
Process: com.ramtestapp, PID: 2793
com.facebook.jni.CppException: getPropertyAsObject: property '__fbRequireBatchedBridge' is not an Object
no stack
at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
at android.os.Handler.handleCallback(Handler.java:873)
at android.os.Handler.dispatchMessage(Handler.java:99)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:29)
at android.os.Looper.loop(Looper.java:193)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:232)
at java.lang.Thread.run(Thread.java:764)
```
After investigation we found that when using any bundle, let it be non-ram, FIle RAM bundle or Index RAM bundle, the `CatalystInstanceImpl.java` is always using `loadScriptsFromAsset`, which is calling `CatalystInstanceImpl::jniLoadScriptFromAssets` in C++. This method when checking if bundle is a RAM bundle, uses `JniJSModulesUnbundle::isUnbundle` which only check for js-modules/UNBUNDLE - file generated when building File RAM bundle. There is no other logic to handle Indexed RAM bundle, so it figures that the bundle is not RAM, cause there is no js-modules/UNBUNDLE file and tries to load as regular bundle and fails.
In this PR we added check if it is indexed RAM bundle in `jniLoadScriptFromAssets` and handle it if it is.
## Changelog
[Android] [Fixed] fix indexed RAM bundle
Solves https://github.com/facebook/react-native/issues/21282
Pull Request resolved: https://github.com/facebook/react-native/pull/24967
Differential Revision: D15575924
Pulled By: cpojer
fbshipit-source-id: 5ea428e0b793edd8242243f39f933d1092b35260
Summary:
The original reason for vendoring the fetch polyfill was to remove the default blob response type but this was reverted.
Here's a little history around the fetch polyfill and the blob issue:
- Original commit introducing the vendored polyfill: #19333, the goal was to fix a memory leak because our blob implementation doesn't release resources automatically. Not an ideal fix but since the issue was pretty severe and the infra for a proper fix was not in place.
- This introduced an issue when downloading images using `fetch` which was fixed by #22063 which re-added the default blob content type. However that re-introduced the original fetch memory leak.
- We have better infra now with jsi and I was able to get blob deallocation working, see #24405
Currently the vendored fetch polyfill is useless since it was changed back to the original version. We can just use the npm version again. I also updated to 3.0 which brings better spec compliance and support for cancellation via `AbortController`, https://github.com/github/fetch/releases/tag/v3.0.0.
## Changelog
[General] [Changed] - Remove vendored fetch polyfill, update to whatwg-fetch@3.0
Pull Request resolved: https://github.com/facebook/react-native/pull/24418
Differential Revision: D14932683
Pulled By: cpojer
fbshipit-source-id: 915e3d25978e8b9d7507ed807e7fba45aa88385a
Summary:
If you (try to) build React Native for Android without having the NDK properly installed and referenced, you get the following error:
>A problem occurred evaluating project ':ReactAndroid'.
\> Cannot get property 'absolutePath' on null object
This is not an overly helpful diagnostic. This PR results in this message instead:
>ndk-build binary cannot be found, check if you've set $ANDROID_NDK environment variable correctly or if ndk.dir is setup in local.properties
Fixes#25087
## Changelog
[Android] [Fixed] - Show proper error message instead of throwing a NullReferenceException if Gradle cannot find the NDK
Pull Request resolved: https://github.com/facebook/react-native/pull/25088
Differential Revision: D15559271
Pulled By: cpojer
fbshipit-source-id: 35c9a9321af4e4a34bf519144ada48884b48352d
Summary:
This 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:
Changelog: [Android] [FIXED] - Fix backgroundColor top level prop of TextInput
This diff fixes two issues with the `backgroundColor` top level property of TextInput on Android:
* Now it is possible to set a **string** value for the top-level `backgroundColor` property of TextInput (crashed the app previously):
```
<TextInput backgroundColor="#ffccbb">Hello, React Native</TextInput>
```
* Now it's possible to set an **integer** value for the top-level `backgroundColor` property of TextInput (had no effect previously):
```
<TextInput backgroundColor={0xffccbbff}>Hello, React Native</TextInput>
```
A `customType = "Color"` annotation parameter must be provided for `ReactBaseTextShadowNode.setBackgroundColor(...)` since the color value must be previously processed in JS before sending it over the bridge to the native code. The JS code will parse the color value and return the proper ARGB color integer to the native platforms (https://fburl.com/uqup52tn).
Without providing the custom type for the background color, if a string value is set for the top-level `backgroundColor` property in the JS code, the Android code will crash since it expects an integer value for the color in `ReactBaseTextShadowNode.setBackgroundColor(...)`, but a string will be passed from JS without any conversion and there will be a `ClassCastException` thrown. If an integer value without the alpha component (like `0xffccbb`) is set, the Android native view would get an integer color value with its alpha component set to `0x00`, which means a transparent color.
On a side note: the alpha component of a color must always be set when using an integer value for `backgroundColor` since the JS code, while processing the color type, shifts the rightmost 8 bytes (alpha component) to the leftmost position. If those 8 bytes are not the alpha component, you will get the wrong color in the end. It doesn't seem to be a problem for string values of `backgroundColor` though.
Reviewed By: mdvacca
Differential Revision: D15453980
fbshipit-source-id: f3f5d9c9877cdbce79a67f2ed93ad4589576d166
* Adding back the Accessibility Actions that were mistakenly remove in the last merge - RN57
* Add back performAccessibilityAction that was accidentaly removed during merge on RN57
* Adding More methods removed during last Merge on RN57