Summary:
This is the Android analogue to D30019833.
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D30029295
fbshipit-source-id: 13df0dfb915697eeedcc527dcdb6c246e89afb0c
Summary:
Unfortunately, parsing some props requires stateful context - namely, PlatformColor on Android. We explored several different options but they all seemed inferior to the approach of using ContextContainer, and most would require using global state.
By introducing this change everywhere as early as possible, we can avoid later pain. It is likely that some prop, on some platform, will require this mechanism. We'll be ready for it!
Because we can pass a constref of the ContextContainer through to all props and because the context and context data is never retained by prop parsers, perf and memory hit should be ~0.
This diff contains core changes only. Leaf changes to all props structs and conversions files will be in next diff(s).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29838789
fbshipit-source-id: f5090e7f02eb6e8fbe0ef4dd201e7d12104a3e3c
Summary:
Changelog: [Internal]
Separate the functionality of the isPackagerRunning() function into a new class PackagerStatusCheck with the intention of being able to use this without needing a DevServerHelper
Reviewed By: makovkastar, ShikaSD
Differential Revision: D29933318
fbshipit-source-id: d708bb987b08634015d6ee6b6c8989faba416c5a
Summary:
This diff fixes the Android View dimensions in VR
PixelUtil.toSPFromPixel and PixelUtil.getDisplayMetricDensity() are both using getScreenDisplayMetrics() to perform conversion of dimensions. This is not correct because we should take into consideration the density of the Context / Activity instead of the Screen. This problem didn't raise before in Fabric Android because it seems that android OS on phones usually share the scale between the screen and the Activity?
These two methods are only used in Fabric and they were introduced by D9583972 (https://github.com/facebook/react-native/commit/5c0da011cbaa788c52519f8091157ca6d87d8abb) and D9173758 (https://github.com/facebook/react-native/commit/8b5e3fc16b1e58441318b6ada629dcff572dd120)
As part of this diff I'm also deleting the method toSPFromPixel in favor of toDIPFromPixel because I noticed the usages of these methods are meant to use toDIPFromPixel()
changelog: [Internal] internal
Reviewed By: JoshuaGross
Differential Revision: D29864944
fbshipit-source-id: a0a093c120bde21a6cf9e1043a83c31e870d4368
Summary:
**Context:**
Issue:
```java.lang.IllegalStateException: Message queue threads already initialized
at com.facebook.react.bridge.ReactContext.initializeMessageQueueThreads(ReactContext.java:100)
```
Possible root cause:
1, ReactContext.initializeMessageQueueThreads() can be called from different threads, so it's not thread safe
2, ReactContext.initializeMessageQueueThreads() is called again without detroying the threads.
**Fix:**
Make initializeMessageQueueThreads() thread safe. If this won't fix T93983690, I'll continue investigating with possible root cause 2.
Changelog:
[Android][Changed] - Make initializeMessageQueueThreads() thread safe
Reviewed By: GijsWeterings
Differential Revision: D29877386
fbshipit-source-id: 11b32c7184e9e8d6f882474fd607538df12276b7
Summary:
In T94154173, when calling ```EventEmitterWrapper->invoke()```, hybrid function ```invokeEvent``` is null, even if we checked that ```mHybridData``` is valid before calling ```invokeEvent```.
**Theory:**
```invoke()``` is called from ```mqt_js``` thread, ```desotry()``` is called from ```main``` thread, which cause multi-thread access of```mHybridData```.
So if ```desotry()``` is called after ```isValid()``` check and before calling ```invokeEvent()```, ```invokeEvent``` could be destroyed and is null.
I can reproduce with above theory:
{F633411001}
**Fix:**
Make functions synchronized so ```mHybridData``` can be thread safe.
Changelog:
[Android][Fixed] - Make mHybridData thread safe
Reviewed By: RSNara
Differential Revision: D29792453
fbshipit-source-id: 8b4c754d53ece933be7b2cf99c6cd026b39e24ad
Summary:
This diff exposes a new API in FabricUIManager called getInspectorDataForInstance. The goal of this method is to return React metadata for a Native view.
This data will be used from partner teams to build tools that uses React metadata in RN
Data returned from React: P429701924
changelog: [internal] internal
allow-large-files
Reviewed By: JoshuaGross
Differential Revision: D29747864
fbshipit-source-id: 8cb55573be08cb530f7e3c83eed8b4fcf43e7781
Summary:
Similar to D29786190 (https://github.com/facebook/react-native/commit/b0e39b2ed9b66b378eb75bee9e692fc801431ddd) on iOS, keeps cursor position constant to the end of the text whenever text changes without selection updates.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29879663
fbshipit-source-id: da1b50a99ae3b9ef796423146ba49e4172e286df
Summary:
With the advent of https://github.com/facebook/react-native/issues/29610, we are now able to use the `testID` view prop on Android in black-box testing framework through the view's `resource-id`.
But after testing it, I noticed that on the `TextInput`, `Slider` and `ScrollView` components, the `testID` prop was not exposed as the `resource-id` properly. The main issue was that those component was using the `AccessibilityDelegateCompat` instead of the `ReactAccessibilityDelegate`.
## Changelog
[Android] [Fixed] - Fix `testID` prop for `TextInput`, `Slider` and `ScrollView` components
Pull Request resolved: https://github.com/facebook/react-native/pull/31865
Test Plan: 
Reviewed By: mdvacca
Differential Revision: D29765333
Pulled By: yungsters
fbshipit-source-id: 2b8e362257e3e5fdcd20330280c588dabb44f28a
Summary:
Add INFO, and MENU key event support to Android TV
## Changelog
[Android] [Added] - Add INFO, and MENU key event support to Android TV
Pull Request resolved: https://github.com/facebook/react-native/pull/31884
Test Plan: We develop application that utilizes aforementioned events, we've made a build against react-native fork with these changes and it was working as expected. These changes just add 2 more button mappings, so I don't think it requires some extensive testing.
Reviewed By: mdvacca
Differential Revision: D29821996
Pulled By: yungsters
fbshipit-source-id: 5f97c29c9c29d6e3bafed352b8b65f0cb02f3f1d
Summary: - This is crashing too much in debug, which is good signal but making it harder to test, and test unrelated features.
Reviewed By: JoshuaGross
Differential Revision: D29857626
fbshipit-source-id: c52cfb6131747ae420b27de0591620fe79f47359
Summary:
Tests like `CatalystSubviewsClippingTestCase` are intermittently failing due to registered callable modules not yet being registered.
Increasing the timeout to wait for the bundle execution to mitigate these intermittent failures.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D29835227
fbshipit-source-id: c9fe03202ad4028d3785216d50c6c173a56c6d84
Summary:
Fix for https://github.com/facebook/react-native/issues/27952.
Noticed more than just `AUTOFILL_HINT_NEW_PASSWORD` were missing, this PR will support every `AUTOFILL_HINT_*` type.
## Changelog
[Android] [Added] - Added all autofill types to TextEdit
Pull Request resolved: https://github.com/facebook/react-native/pull/28008
Reviewed By: sturmen
Differential Revision: D29766235
Pulled By: mdvacca
fbshipit-source-id: d5171aef8092d37716fddcb6f3443637a4af8481
Summary:
I'm hunting down the source of a perf regression on a screen and think that having these systrace sections could be handy for this and future investigations.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D29802969
fbshipit-source-id: f4030261da8888ddeb32ae41b9cf2b25af6a5583
Summary:
Android react-native `TextInput` component does nothing if prop `keyboardType` is `url` value. This PR solves that problem.
## Changelog
[Android] [Added] - Add support to URI keyboard type in Android
Pull Request resolved: https://github.com/facebook/react-native/pull/31781
Test Plan:
Before change:
{F630980679}
After Change:
{F630986399}
Reviewed By: lunaleaps
Differential Revision: D29517822
Pulled By: sshic
fbshipit-source-id: 1bda29584a3799570f34e772b5589b59ac80c524
Summary:
In Fabric, we currently incur the cost of (frequently!) flushing non-Fabric UI updates, even if there are no non-Fabric views.
For now it is still possible to run both renderers at the same time, so we still largely continue to use the non-Fabric path, but only use UIImplementation if there is actually a RootView being managed outside of Fabric.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29724538
fbshipit-source-id: 0f1148870c04ca9aaed0edfd6b5c55a3756a2bd7
Summary:
Always create a new EventEmitter specifically for Fabric when initializing the Fabric JSI module.
Previously, we were (sometimes!) reusing the EventEmitter being used for the old renderer and they were shared. There doesn't seem to be a compelling reason to continue doing this, and Fabric has optimized EventEmitters that we can use instead.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29724537
fbshipit-source-id: 1b2c7a7d656e3fb86ddf98a6cf0f2e67dcbf8aef
Summary:
This is crashing too much in debug, which is good signal but making it harder to test, and test unrelated features.
We have some good data about this internally and validated that it's useful; we can follow up on the logged soft exceptions without actually crashing now.
Changelog: [Internal]
Differential Revision: D29698447
fbshipit-source-id: 61387c18f17f76e5de60baa1fd3c94028229c0f6
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:
Refactors how `Typeface` style and weight are applied in React Native on Android.
- Unifies all style and weight normalization logic into a new `TypefaceStyle` class.
- Fixes font weight support for the Fabric renderer.
- De-duplicates code with `TextAttributeProps`.
- Simplified normalization logic.
- Fixes a rare crash due to `Typeface.sDefaultTypeface` (Android SDK) being `null`.
- Adds a new example to test font weights in `TextInput`.
- Adds missing `Nullsafe` and `Nullable` annotations.
- Clean up a bunch of obsolete inline comments.
Changelog:
[Android][Fixed] - Fixed a rare crash due to `Typeface.sDefaultTypeface` (Android SDK) being `null`.
[Android][Fixed] - Fixed font weight support for the Fabric renderer.
[Android][Added] - Added a new example to test font weights in `TextInput`.
Reviewed By: JoshuaGross
Differential Revision: D29631134
fbshipit-source-id: 3f227d84253104fa828a5561b77ba7a9cbc030c4
Summary:
Add MEDIA_STOP, MEDIA_NEXT, and MEDIA_PREVIOUS event support to Android TV (TVEventHandler)
## Changelog
[Android] [Added] - Add MEDIA_STOP, MEDIA_NEXT, and MEDIA_PREVIOUS event support to Android TV
Pull Request resolved: https://github.com/facebook/react-native/pull/31837
Test Plan: We develop application that utilizes aforementioned events, we've made a build against react-native fork with these changes and it was working as expected. These changes just add 3 more button mappings, so I don't think it requires some extensive testing.
Reviewed By: TheSavior
Differential Revision: D29668706
Pulled By: yungsters
fbshipit-source-id: e4bd8dcf7de6b094ffdbbca12d875b85e468d49a
Summary:
Could not repro myself, but logview shows steady low number of crashes coming from this mid. Current fix returns early if the layout is not defined, relying on the following layout passes to position view correctly.
Changelog: [Android][Fixed] Exit early from layout in textview if text layout is null
Reviewed By: JoshuaGross
Differential Revision: D29636040
fbshipit-source-id: 876ce80222cbc5ff09450224f6808f9f6433c62a
Summary:
Issue https://github.com/facebook/react-native/issues/30964 .When using a screen reader, flatlist does not announce entrance/ exit from the flat list.
## Changelog
[Android] [Changed] - Added support for accessibility role of "list" for flatlist and sectioned list
Pull Request resolved: https://github.com/facebook/react-native/pull/31630
Test Plan: I have added accessibility role prop in flatlist and sectioned list in rntester app, that will announce entrance/ exit from flatlist and sectioned list.
Reviewed By: kacieb
Differential Revision: D29599351
Pulled By: blavalla
fbshipit-source-id: e16ec69a694780d12f15f88a1e6bb5d7d77ac15f
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:
At risk of hiding errors, given the low volume, I think it's safe to cause this to crash in debug and continue gracefully in release-mode.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29618047
fbshipit-source-id: 19b19d8f6e27703227de4947ed01f7f2177f463b
Summary:
This diff fixes a NullPointerException that is caused when the method ReactInstanceManager.getViewManagerNames is called at the same time ReactInstanceManager is being destroyed.
Following the stacktrace I noticed that this crash can only happen when RN was destroyed by another thread while this method was being executed
This diff fixes the NullPointerException, but it doesn't fix the root cause race condition that cuases this bug
changelog: [Android][Fixed] Fix NullPointerException caused by race condition in ReactInstanceManager.getViewManagerNames method
Reviewed By: JoshuaGross
Differential Revision: D29616401
fbshipit-source-id: 6ae8ecdd765d2fe3529fef3237f08b182d8ed243
Summary:
It is possible for receiveEvent to be called concurrently with/after destruction of FabricUIManager. Drop events if we are able to detect that case.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D29596271
fbshipit-source-id: 1fa50d9c3cff0bf578316d905966e1bdfffe94d1
Summary:
As a followup to T91209139, ship "state update scroll race" in code. This also ships it for HorizontalScrollView since it's been validated for vertical scroll views.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D29595601
fbshipit-source-id: 64b6a23e2dab2c13123e132d9d899fb769d03172
Summary:
I suspect that T94864568 is caused by TouchEvents being dispatched after they've been recycled. This needs further analysis, but to stop the bleeding, we can drop events at the point they'd be dispatched before the crash, and log a soft error.
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D29594749
fbshipit-source-id: f50df8df2125b83126616ceaf4e529127d154c7c
Summary:
It is unlikely but possible that the crash T94864568 is caused by a TouchEvent being initialized with a null MotionEvent. Regardless, we should guard against this case.
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D29594750
fbshipit-source-id: 3a409b716a9f1eec8017002ae7e23273677e53ba
Summary:
Upgrade folly for the https://github.com/facebook/folly/pull/1593 fix for NDK 21 failure
## 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] [Changed] - Upgrade folly to 2021.06.28.00
Pull Request resolved: https://github.com/facebook/react-native/pull/31802
Test Plan:
`./gradlew :ReactAndroid:installArchives`
`./gradlew packages:rn-tester:android:app:installJscRelease`
`./gradlew packages:rn-tester:android:app:installHermesRelease`
Reviewed By: RSNara
Differential Revision: D29547027
Pulled By: ShikaSD
fbshipit-source-id: a10c7c65f459091bd0e7cca750a9b9e067189b73
Summary:
See comments in ReactClippingProhibitedView for details and motivation behind this new feature.
You may have a View class inherit from the ReactClippingProhibitedView interface in order to enable this feature for instances of that View type.
This can be added to Views that should /never/ be clipped from the View hierarchy - namely, TTRC components or other telemetry components that always need to be rendered in order for some feature to function.
Changelog: [Added] Opt-in mechanism to allow native Android Views to be marked as "not clippable", soft exceptions will be logged if these Views are clipped from the View hierarchy
Reviewed By: sshic
Differential Revision: D29472439
fbshipit-source-id: b3be53df836b452aed5dc40514ff585ce0ad812b
Summary:
@public
When PlatformColor is used with backgroundColor, this line would throw, as the object type is not convertible to int.
Changelog:
[Android][Fixed] - Fix Crash in ViewProps.isLayoutOnly
Reviewed By: JoshuaGross
Differential Revision: D29430151
fbshipit-source-id: a1fe801925430dad3a17871bdebb79d942775280
Summary:
Immediately destroy EventEmitterWrapper on update instead of waiting for Java GC. This can resolve JSI::~Pointer deallocation crashes by clearing out EventEmitter and therefore EventTarget sooner, before RN teardown.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D29415386
fbshipit-source-id: 05517bfd9e2cc2bd1b8c58d4f84c84f6f547268a
Summary:
This prevents us from leaking things via this static field.
Changelog: [Android][Changed] Native ScrollView listeners list maintains weak references to listeners to avoid memory leaks
Reviewed By: JoshuaGross
Differential Revision: D29317937
fbshipit-source-id: 4daeb8b5533cccaebcb03acf3d595dfa58de7883
Summary:
Changelog: [internal]
Reland of D29131766 (https://github.com/facebook/react-native/commit/18165367b0347fc46cd52a6ac00afcf62d05cb30) which had to reverted because it caused binary size regression in instagram.
Size check for `automation_instagram_stablesize_release` and `automation_igtv_release`
{F626711916}
Reviewed By: JoshuaGross
Differential Revision: D29263302
fbshipit-source-id: cc8f5609ebaed9ddf666f7c57cdbf3dbf77a8f78
Summary:
Because of T92179998, T93607943, and T93394807, we are still seeking resolution to tricky crashes wrt the use of EventEmitters.
I believe the recent spike is because of two recent changes: we pass in EventEmitters earlier, during PreAllocation; and we clean them up earlier, during stopSurface, to avoid jsi::~Pointer crashes.
Additionally, the gating previously added around the PreAllocation path was incorrect and led to more nullptrs being passed around as EventEmitters.
To mitigate these issues:
1) I am adding/fixing gating to preallocation and early cleanup paths
2) I am making EventEmitterWrapper more resilient by ensuring EventEmitter is non-null before invoking it.
3) I am making sure that in more cases, we pass a non-null EventEmitter pointer to Java.
4) I am backing out the synchronization in EventEmitterWrapper (java side) as that did not resolve the issue and is a pessimisation
There are older, unchanged paths that could still be passing in nullptr as the EventEmitter (Update and Create). As those have not changed recently, I'm not going to fix those cases and instead, we can now rely on the caller to ensure that the EventEmitter is non-null before calling.
Changelog: [internal]
Differential Revision: D29252806
fbshipit-source-id: 5c68d95fa2465afe45e0083a0685c8c1abf31619
Vegas Murphy
Ramanpreet Nara
Samuel Susla
fabriziobertoglio1987
David Vacca
jeswinsimon
Joshua Gross
Amy Nichol
Lulu Wu
Andrei Shikov
Hubert Gendron
Tomáš Havlas
Sandeep Raghunandhan
Tim Yung
Yuqing Duan
Jason Safaiyeh
Adrián Cuesta
CodemodService FBSourceGoogleJavaFormatLinterBot
Tomek Zawadzki
Anas Khurshid
Agastya Darma
Kudo Chien
Pieter De Baets
David Alves
Luna Wei
