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: ![test-screenshot](https://user-images.githubusercontent.com/69216913/125802180-c0791a8c-a740-4657-a44f-42b1885eee39.png)
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:
Updates documentation in React Native to reference `main` (or `HEAD` for URLs) instead of `master`.
Part of https://github.com/facebook/react-native/issues/31788.
Changelog:
[General][Changed] - Update documentation reference from `master` to `main` or `HEAD`.
Reviewed By: JoshuaGross
Differential Revision: D29717128
fbshipit-source-id: 0b0babd8407c6fd3d0e5431f6eaf976059731d6f
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.
41ecccefcf/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:
Building from source in debug takes a very long time because native builds need to run for all supported architectures. It is possible to check which architecture the devices for which we are about to launch the app on are and build only for those. For most cases we can reduce the number of architectures we build for to 1 instead of 4, resulting in a large speedup of the build.
This is inspired by iOS which has a "Build for active architecture only" option. Since android doesn't really support this natively we can implement it here and also in react-native by reading the build properties that we pass and alter the abi we build for.
With fabric / codegen coming up I suspect that we might want to default to building c++ soon. This should ease the transition as builds won't be orders of magnitude slower.
See https://github.com/react-native-community/cli/pull/1388 for more context and how we use this new config to automatically detect running emulator architectures.
## Changelog
[Android] [Added] - Allow configuring ndk build architectures
Pull Request resolved: https://github.com/facebook/react-native/pull/31232
Test Plan:
Tested by setting reactNativeDebugArchitectures with different values in gradle.properties. Checked the build logs to see which architectures are being built. Also made sure release builds are not affected by this value.
Clean build
reactNativeDebugArchitectures not set
824.41s
reactNativeDebugArchitectures=x86
299.77s
Reviewed By: mdvacca
Differential Revision: D29613939
Pulled By: ShikaSD
fbshipit-source-id: d20a23d1d9bbf33f5afaaf3475f208a2e48c0e1a
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:
Latest Android Gradle plugin doesn't respond to ANDROID_NDK env variable, so I propagated it explicitly and included with recommended `ndkPath` clause.
Changelog: [Internal]
allow-large-files
Reviewed By: fkgozali
Differential Revision: D29593132
fbshipit-source-id: 0785fe92385037d2d4cf290c2462b299800b6928
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)
...
```
![Screen Shot 2021-07-07 at 1 38 23 PM](https://user-images.githubusercontent.com/8868908/124711795-b5fee980-df28-11eb-98c4-9668661340b6.png)
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 (18165367b0) 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
Summary:
In stopSurface we destroy these EventEmitters which is not a threadsafe operation. Wrap usage and destruction of these wrappers to prevent crashes.
This crash is caused by D29020768 (25e8fbe8ff) which was landed to fix T92179998, which was in turn caused by D28938637 (ac6d1982f4).
Changelog: [internal]
Reviewed By: sammy-SC, mdvacca
Differential Revision: D29239828
fbshipit-source-id: 6be5acf4a24b82c75c13fe9f1d16a87cce5b7e00
Summary:
Because of the "disable preallocation of virtual views" experiment, for some reason, some views are being preallocated multiple times instead of not being preallocated at all.
This isn't really a problem for CreateView, and Preallocate is actually more strict here than it needs to be. I'm going to downgrade this to a soft error and will continue to analyze more. This is more of a perf issue than a correctness issue, so this should be fine.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29206416
fbshipit-source-id: 9490a1a705c2b39def3a3e56086634439543515e
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:
Changelog: [internal]
We should be calling invokeUnique if event can be coalesced, not the other way around.
Reviewed By: JoshuaGross
Differential Revision: D29194528
fbshipit-source-id: 36e4ae71254420ef47deea436cad20eec09712fc
Summary:
Changelog: [internal]
Why does the crash happen?
We call method on invalid address. We crash on `std::weak_ptr::lock` because that's the first accessed ivar.
In D29020768 (25e8fbe8ff), eventEmitter may be destroyed before an event is dispatched. Calling destroy on hybrid object destroys only C++ part.
Reviewed By: JoshuaGross
Differential Revision: D29194906
fbshipit-source-id: ae8d9d90aa8d98d69d29884e80d6b930b1e66870
Summary:
Changelog: [internal]
It is recommended to not use `using namespace` in the header file. It changes namespace for anything that imports the header file.
Also keeping imports in header file to minimum is recommended to lower build times.
Reviewed By: JoshuaGross
Differential Revision: D29131371
fbshipit-source-id: ad1868f6200c00023a62a00859d9a05140a12849
Summary:
This PR bumps NDK_VERSION to 21.4.7075529, and patches FileUtil.cpp from folly based on patch from https://github.com/facebook/folly/pull/1593. We can remove the patch once PR lands in Folly and bump Folly version in RN.
FYI, NDK 20 is deprecated and 21 is LTS release.
## Changelog
[Android] [Changed] - Bump NDK to 21.4.7075529
Pull Request resolved: https://github.com/facebook/react-native/pull/31731
Reviewed By: mdvacca
Differential Revision: D29166690
Pulled By: ShikaSD
fbshipit-source-id: 0792691404f718aaf5af1369f66f0cba046b4e20
Summary:
Rationale:
- This makes the element inspector button consistent with the Fast Refresh, Perf Monitor and other buttons in the DevMenu
- This makes the button more informative
Changelog: [Android][Changed] Rename the "Toggle Inspector" DevMenu item to "Hide/Show Element Inspector"
Reviewed By: JoshuaGross
Differential Revision: D29146871
fbshipit-source-id: 8e8c19217ea2ff2f1d176521aa22200058e7e643
Summary:
Changelog: [internal]
RuntimeScheduler needs to be created and registered in the runtime before any JS is allowed to run. This diff moves the registration right after the runtime is initialised.
This diff removes funnelling of Fabric events through RuntimeScheduler. This will be added in subsequent diff to keep the complexity low.
Reviewed By: JoshuaGross
Differential Revision: D29131766
fbshipit-source-id: cbc650f6fbce95e4b9c2c9695e8e0aba5beac635
Summary:
Changelog: [internal]
Remove `RuntimeScheduler` from `SchedulerToolbox` and all of its uses.
`RuntimeScheduler` needs to be allocated before `Scheduler` and therefore its presence in the toolbox is redundant.
Reviewed By: JoshuaGross
Differential Revision: D29134769
fbshipit-source-id: fa00c5dcc4b565d6941e6d742c6aefade37b31c4