Summary:
This PR fixes a few issues with the Appearance API (as noted here https://github.com/facebook/react-native/issues/28823).
1. For the Appearance API to work correctly on Android you need to call `AppearanceModule.onConfigurationChanged` when the current Activity goes through a configuration change. This was being called in the RNTester app but not in `ReactActivity` so it meant the Appearance API wouldn't work for Android in newly generated RN projects (or ones upgraded to the latest version of RN).
2. The Appearance API wasn't working correctly for brownfield scenarios on Android. It's possible to force an app light or dark natively on Android by calling `AppCompatDelegate.setDefaultNightMode()`. The Appearance API wasn't picking up changes from this function because it was using the Application context instead of the current Activity context.
3. The Appearance API wasn't working correctly for brownfield scenarios on iOS. Just like on Android its possible to force an app light or dark natively by setting `window.overrideUserInterfaceStyle`. The Appearance API didn't work with this override because we were overwriting `_currentColorScheme` back to default as soon as we set it.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
### Fixed
https://github.com/facebook/react-native/issues/28823
* [Android] [Fixed] - Appearance API now works on Android
* [Android] [Fixed] - Appearance API now works correctly when calling `AppCompatDelegate.setDefaultNightMode()`
* [iOS] [Fixed] - Appearance API now works correctly when setting `window.overrideUserInterfaceStyle`
Pull Request resolved: https://github.com/facebook/react-native/pull/29106
Test Plan: Ran RNTester on iOS and Android and verified the Appearance examples still worked [correctly.](url)
Reviewed By: hramos
Differential Revision: D31284331
Pulled By: sota000
fbshipit-source-id: 45bbe33983e506eb177d596d33ddf15f846708fd
Summary:
Fixes https://github.com/facebook/react-native/issues/31774.
This pull request resolves a problem related to accessing blobs greater than 64 KB on Android. When an object URL for such blob is passed as source of `<Image />` component, the image does not load.
This issue was related to the fact that pipe buffer has a limited capacity of 65536 bytes (https://man7.org/linux/man-pages/man7/pipe.7.html, section "Pipe capacity"). If there is more bytes to be written than free space in the buffer left, the write operation blocks and waits until the content is read from the pipe.
The current implementation of `BlobProvider.openFile` first creates a pipe, then writes the blob data to the pipe and finally returns the read side descriptor of the pipe. For blobs larger than 64 KB, the write operation will block forever, because there are no readers to empty the buffer.
https://github.com/facebook/react-native/blob/41ecccefcf16ac8bcf858dd955af709eb20f7e4a/ReactAndroid/src/main/java/com/facebook/react/modules/blob/BlobProvider.java#L86-L95
This pull request moves the write operation to a separate thread. The read side descriptor is returned immediately so that both writer and reader can work simultaneously. Reading from the pipe empties the buffer and allows the next chunks to be written.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Android] [Fixed] - Fix support for blobs larger than 64 KB
Pull Request resolved: https://github.com/facebook/react-native/pull/31789
Test Plan:
A new example has been added to RN Tester app to verify if the new implementation properly loads the image of size 455 KB from a blob via object URL passed as image source.
<img src="https://user-images.githubusercontent.com/20516055/123859163-9eba6d80-d924-11eb-8a09-2b1f353bb968.png" alt="Screenshot_1624996413" width="300" />
Reviewed By: ShikaSD
Differential Revision: D29674273
Pulled By: yungsters
fbshipit-source-id: e0ac3ec0a23690b05ab843061803f95f7666c0db
Summary:
Douring our routine crash report check we are occasionally seeing reports of exceptions like this in the wild from our crash stack:
```
java.lang.NullPointerException: bio == null
at com.android.org.conscrypt.NativeCrypto.SSL_pending_written_bytes_in_BIO(NativeCrypto.java)
at com.android.org.conscrypt.NativeSsl$BioWrapper.getPendingWrittenBytes(NativeSsl.java:660)
at com.android.org.conscrypt.ConscryptEngine.pendingOutboundEncryptedBytes(ConscryptEngine.java:566)
at com.android.org.conscrypt.ConscryptEngineSocket.drainOutgoingQueue(ConscryptEngineSocket.java:584)
at com.android.org.conscrypt.ConscryptEngineSocket.close(ConscryptEngineSocket.java:480)
at okhttp3.internal.Util.closeQuietly(Util.kt:501)
at okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFile:245)
at okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFile:106)
at okhttp3.internal.connection.ExchangeFinder.find(ExchangeFile:74)
at okhttp3.internal.connection.RealCall.initExchange$okhttp(ExchangeFile:255)
at okhttp3.internal.connection.ConnectInterceptor.intercept(ExchangeFile:32)
...
```
This appears to only be happening on devices running Android 10 and 11. This happens because there is concurrency issue in Conscrypt where two threads race to close an SSLEngine-based SSLSocket and access to the underlying BIO is unsynchronized.
**The OkHttp team already released a fix for this issue on version 4.9.1** this PR aims to update our OkHttp package to version 4.9.1.
Related discussion:
[https://issuetracker.google.com/issues/177450597](https://issuetracker.google.com/issues/177450597)
[https://publicobject.com/2021/01/30/bio-null/](https://publicobject.com/2021/01/30/bio-null/)
cc dulmandakh fkgozali
## Changelog
[Android] [Changed] - Bumping OkHttp from 4.9.0 to 4.9.1.
Pull Request resolved: https://github.com/facebook/react-native/pull/31822
Test Plan: Manual & Automated from CI
Reviewed By: fkgozali
Differential Revision: D29590198
Pulled By: ShikaSD
fbshipit-source-id: 4228bfd3472114253e13acb436dc1dd9287a148d
Summary:
The native libraries are compiled outside of the usual Android build flow using separate CLI task. Because of that, shared native libraries may not exist when AAR is bundled, resulting in weird sequencing issues.
This change updates gradle dependency graph, executing RN native build before Android part (as it is done in RNTester already).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29209249
fbshipit-source-id: 36386c78996b1cd9b1731735e36e571199e9e81b
Summary:
This PR bumps Fresco to 2.5.0, which is first version on MavenCentral since jCenter announcement.
## Changelog
[Android] [Changed] - Bump Fresco to 2.5.0
Pull Request resolved: https://github.com/facebook/react-native/pull/31699
Test Plan: CI is green
Reviewed By: TheSavior
Differential Revision: D29031847
Pulled By: passy
fbshipit-source-id: 486ffbf5461d07d736c0ebe17c0c7726937db344
Summary:
Gradle has been showing below warning for a while, and this PR fixes the warning using maven-publish plugin, thus taking us one step closer to Gradle 7.x.
> The maven plugin has been deprecated. This is scheduled to be removed in Gradle 7.0. Please use the maven-publish plugin instead. Consult the upgrading guide for further information: https://docs.gradle.org/6.9/userguide/upgrading_version_5.html#legacy_publication_system_is_deprecated_and_replaced_with_the_publish_plugins
Configured maven-publish plugin according to https://developer.android.com/studio/build/maven-publish-plugin, also added **installArchives** task for backwards compatibility.
## Changelog
[Internal] [Changed] - use maven-publish plugin to build and publish Android artifact
Pull Request resolved: https://github.com/facebook/react-native/pull/31611
Test Plan: ./gradlew :ReactAndroid:installArchives will create **android** directory for local maven repository with **react-native** package.
Reviewed By: yungsters
Differential Revision: D28802435
Pulled By: ShikaSD
fbshipit-source-id: 7bc7650a700e1a61213c5ec238bcb24fdca954db
Summary:
jcenter is read-only now, and newer versions of dependencies will be published to either MavenCentral or Jitpack. This PR removes jcenter to avoid future issues, then uses MavenCentral and Jitpack as replacement. Current flipper depends on Stetho version that is not available on MavenCentral, so had to exclude and bump the version.
Both Gradle and Buck successfully download all the dependencies.
## Changelog
[Android] [Changed] - Remove jcenter
Pull Request resolved: https://github.com/facebook/react-native/pull/31609
Test Plan: rn-tester builds and runs as expected.
Reviewed By: mdvacca
Differential Revision: D28802444
Pulled By: ShikaSD
fbshipit-source-id: 043ef079d0cda77a1f8dd732678452ed712741a4
Summary:
Bump Gradle to 6.9 which supports Apple Silicon, also Android Gradle Plugin 4.2.1 which defaults to Java 1.8 so no additional config required.
## Changelog
[Android] [Changed] - Bump Gradle to 6.9, Android Gradle Plugin to 4.2.1
Pull Request resolved: https://github.com/facebook/react-native/pull/31593
Test Plan: rn-tester builds and runs as expected
Reviewed By: mdvacca
Differential Revision: D28711942
Pulled By: ShikaSD
fbshipit-source-id: 2a4616cd0f17db7616ab29dea1652717f2cd0f6d
Summary:
This diff refactors the UIManagerHelper.getUIManager method to return null when there's no UIManager registered for the uiManagerType received as a parameter.
This is necessary to workaround: https://github.com/facebook/react-native/issues/31245
changelog: [changed] UIManagerHelper.getUIManager now returns null when there's no UIManager registered for the uiManagerType received as a parameter
Reviewed By: fkgozali
Differential Revision: D28242592
fbshipit-source-id: c3a4979bcf6e547d0f0060737e41bbf19860a984
Summary:
This diff fixes an IllegalArgumentException that's thrown when creating layout with negative width.
This is not a new bug, but it started firing recently (probably caused by a change in text being measured)
stacktrace:
```
stack_trace: java.lang.IllegalArgumentException: Layout: -2 < 0
at android.text.Layout.<init>(Layout.java:265)
at android.text.Layout.<init>(Layout.java:241)
at android.text.BoringLayout.<init>(BoringLayout.java:179)
at android.text.BoringLayout.make(BoringLayout.java:61)
at com.facebook.react.views.text.TextLayoutManager.createLayout(TextLayoutManager.java:290)
at com.facebook.react.views.text.TextLayoutManager.measureText(TextLayoutManager.java:384) [inlined]
at com.facebook.react.views.text.ReactTextViewManager.measure(ReactTextViewManager.java:172) [inlined]
at com.facebook.react.fabric.mounting.MountingManager.measure(MountingManager.java:349) [inlined]
at com.facebook.react.fabric.FabricUIManager.measure(FabricUIManager.java:461)
at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:923)
```
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D28015820
fbshipit-source-id: 129cd2a4c492d95d57fcdf3883b967a0b5df639a
Summary:
This change broke some animations on non-Fabric surfaces due to inconsistent batching of animation operations.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D28013968
fbshipit-source-id: 2f65c799dbe00168f1e756ef0af60206df5a8fcc
Summary:
This change caused crashes in animations on some surfaces.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D28013969
fbshipit-source-id: 95845c69d6e67d59582ea14ad08cbf42fd3e2f8f
Summary:
Changelog:
[General][Changed] Make the RootTag an opaque type
Reviewed By: yungsters
Differential Revision: D27992320
fbshipit-source-id: 2901f0e59f573106295b986fe04db227134235da
Summary:
Changelog: [internal]
Prevent redundant calls to RuntimeExecutor by making sure no two calls to the executor are scheduled at the same time.
Reviewed By: mdvacca
Differential Revision: D27989412
fbshipit-source-id: 8f9b1591f7c9c2265fd4b05bf3dc5505ffc2568b
Summary:
With D27975839, RuntimeExecutor will be able to start flushing the queued up NativeModule calls in every call from C++ -> JavaScript. We're going to test this feature to measure its impact. In this diff, I wire up the the MobileConfig to ReactFeatureFlags.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D27978112
fbshipit-source-id: 47e1e74398c62755bb0fdc6b54b7fd3aa47eb877
Summary:
## Motivation
With the bridge, every call into JS flushes the queue of NativeModule calls. Fabric bypasses this mechanism, because it uses a RuntimeExecutor that schedules work directly on the JavaScript thread. This diff makes Fabric's RuntimeExecutor also flush the queue of NativeModule calls.
This likely won't fix anything in Fabric, because we don't execute any async NativeModule calls on Fb4a. However, this is necessary for the drainMicrotask work we're doing in D27729702 (https://github.com/facebook/react-native/commit/73108477589a18cecb303ef556fa3da02f8ca1b8), because (1) we need to drain the Hermes microtask queue on every call from C++ -> JavaScript (2) we drain the microtask queue [inside JSIExecutor::flush()](https://github.com/facebook/react-native/blob/de477a0df6da770e579892d4875a8995c430ebdf/ReactCommon/jsiexecutor/jsireact/JSIExecutor.cpp#L427,L445).
Changelog: [Android][Fixed] - Flush JSIExecutor in Fabric's RuntimeExecutor
Reviewed By: JoshuaGross
Differential Revision: D27975839
fbshipit-source-id: 27f031fb36593253da116a033e30998475eb1473
Summary:
By the time that we call [ReactContext.assertOnNativeModulesQueueThread()](https://www.internalfb.com/intern/diffusion/FBS/browsefile/master/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/bridge/ReactContext.java?commit=747a25280435d276fb975ccfe36fd5e60254c4e4&lines=355%2C359), ReactContext.mNativeModulesMessageQueueThread must be non-null. This implies that two things must have happened:
1. We initialized the ReactContext
2. After initialization, ReactContext.mNativeModulesMessageQueueThread must be non-null.
According to T85807990, ReactContext.mNativeModulesMessageQueueThread is null. Since ReactContext doesn't ever write to ReactContext.mNativeModulesMessageQueueThread aside from during initialization, it must mean that we either didn't initialize properly, or we initialized, but set the NativeModules thread to null. This diff throws IllegalStateExceptions inside ReactContext initialization, which should help narrow down the crash in T85807990.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D27729355
fbshipit-source-id: e39030b7db8862ae76fb644efaafb382a79b8ad0
Summary:
D27682424 (https://github.com/facebook/react-native/commit/ea1ff374de2ece7d1698b14d4e1aa8075df22cdd) updated how animated node batches are executed in Fabric. On Paper, these batches were controlled by native module in some places (batch was executed ~every 2 frames), but some animations were switching animation batching control to JS globally there as well.
This change updates two things:
- If batching is controlled by native, it makes sure batches are calculated correctly.
- At the same time, this change switches control for animation node batching to JS, aligning it with Fabric.
Changelog: [Internal]
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D27939659
fbshipit-source-id: d6251bce2a303a4a007dc10297edc0175cc4b348
Summary:
Noticed while working in MobileHome with android device, when interacting with the Tasks change progress/priority components (MobileHomeTasksDetailsSelectorToken), which provides `borderRadius` style and `backgroundColor: ifSelected ? value : null`, and when `backgroundColor` is `null`, the line changed in this diff crashes (throwing the `NoSuchKeyException` at `ReadableNativeMap:110` [because of isNull check on `ReadableNativeMap:107`])
Changelog:
[Android][Fixed] - Fixed crash when using style borderRadius: any with backgroundColor: null
Reviewed By: JoshuaGross
Differential Revision: D27932828
fbshipit-source-id: 801b04c856ee9dc5a36bbf3e6e3d81de9b1e81a1
Summary:
This diff replaces all usages of int by int32_t. This is to ensure we always use a fixed size for int that matches what's expected on Java.
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27915608
fbshipit-source-id: 634c45796dda1d4434c3ad6ff3e199931c22940b
Summary:
Adds surface id for string logs of the IntBufferBatchMountItem to help debug updates with multiple surfaces.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D27884232
fbshipit-source-id: c5ec65585830f7aa5b902603bcd1e91b61cfe4c1
Summary:
Refactor MapBufferBuilder to use int to store size of Mapbuffer data
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D27904646
fbshipit-source-id: 6b8b96fdd30184b6d35c1d612743eae653854d6d
Summary:
DynamicData can contain a big amount of data, refactoring type to use int instead of short
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27904643
fbshipit-source-id: 157064b280e27a9c7c4a4f55af310392b178feda
Summary:
Add extra asserts and early deallocation in ReadableMapBuffer::importByteBufferAllocateDirect
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27904645
fbshipit-source-id: 075a007c4ec5e005b839add054bd68c233b65801
Summary:
This diff fixes the importByteBufferAllocateDirect method.
This was tested enabling importByteBufferAllocateDirect in ReadableMapBuffer.java
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27867055
fbshipit-source-id: 9ef5e93ff6c7903782598dde1c499daa82cd467b
Summary:
To fix [the CI error](https://app.circleci.com/pipelines/github/facebook/react-native/8708/workflows/d584348e-941f-4653-96c2-46375894dfaa/jobs/196410)
There are two errors:
`error: undefined reference to '__android_log_write'` which solved by adding `-llog` linker flag.
`ld: error: cannot find -lc++` which workaround by static linking.
For the root cause, I am thinking that is after [NDK r19](https://developer.android.com/ndk/guides/other_build_systems),
the `-target` should specificy api level.
However, buck does not add this accordingly, e.g. `-target armv7-none-linux-androideabi`
Given wrong target will make NDK to have `cannot find -lc++` error.
The workaround is to use static linking.
Since it was an oss_cxx_library, the change should not have impact to Facebook internal testing.
## Changelog
[Internal] [Fixed] - Fix CI "Build Tests: Android Instrumentation Tests" errors
Pull Request resolved: https://github.com/facebook/react-native/pull/31352
Test Plan: Make CI green
Reviewed By: JoshuaGross
Differential Revision: D27757838
Pulled By: fkgozali
fbshipit-source-id: 8f9c80a89c6240938218abacb8a82e3e2e71adbc
Luna Wei
Brent Kelly
Lorenzo Sciandra
hank121314
Tomek Zawadzki
Agastya Darma
Andrei Shikov
Dulmandakh
fabriziobertoglio1987
Tommy Nguyen
David Vacca
Nadiia D
Samuel Susla
Ramanpreet Nara
Peter Laraia
Lulu Wu
CodemodService FBSourceBuckFormatLinterBot
Kudo Chien
Mike
