Summary:
Extend the codegen script to allow arbitrary library name to be passed along as an argument, as well as the desired output directory for TurboModules and Fabric output.
New arguments:
- `:library_name`
- `:modules_output_dir`
- `:components_output_dir`
These arguments remain optional, and in their absence, the codegen will generate output that should work for the FBReactNativeSpec core native modules use case.
Internally, the script has been updated to use the correct path for the core modules use case as well as third party modules.
Changelog:
[Internal] - Extend the codegen script to take additional parameters
Reviewed By: RSNara
Differential Revision: D29243707
fbshipit-source-id: 1921bd3e5fd62d7cbf4c8b5089acfdd112f4b014
Summary:
This changeset is limited to whitespace and reordering changes that have no effect on the output or execution of the script. The sole purpose of this changeset is to apply these trivial changes prior to making some larger adjustments to the script in a followup.
With these changes, the ordering of statements more closely matches the order they are executed in (e.g. prepare_command before the script_phase).
Changelog:
[Internal]
Reviewed By: RSNara
Differential Revision: D29527804
fbshipit-source-id: d161ed31321d68baf420457c7aa0aa23a6fc98d2
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:
This is a followup to D29514800.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D29647688
fbshipit-source-id: d6b7be96f4e0ec6ae97c11685be7e44a558116f2
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:
Gradle cannot find the property, because it is defined conditionally depending on env variable.
We want the default for it to be null instead, so the variable exists but doesn't change default NDK location.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D29634984
fbshipit-source-id: 4cf40a1c8d20b2f9008a637456bf9d228d2959d3
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:
Add animation queuing back into createAnimatedComponent_EXPERIMENTAL.js, which is a concurrent-safe version of createAnimatedComponent.
T93269035 for details on why this is needed.
# How does this work?
In the old createAnimatedComponent, Animations were queued by calling `setWaitingForIdentifier` before render, and then calling `unsetWaitingForIdentifier` after render.
In this diff, instead we are calling `setWaitingForIdentifier` in an `useLayoutEffect` before calling `useAnimatedProps`, and we are calling `unsetWaitingForIdentifier` in a `useEffect` after `useAnimatedProps`. So the ordering for the effects are:
1. `useLayoutEffect` with `setWaiting`
2. `useLayoutEffect`s in `useAnimatedProps`
3. `useEffect`s in `useAnimatedProps`
4. `useEffect` with `unsetWaiting`.
There's a React guarantee that **if one effect is called, all of them will be called**, so we don't have a concern about the queue getting locked.
## **Main concerns:**
1. This works in my test cases, but it's not the same behavior as the old createAnimatedComponent (which is wait before and unset wait after render). This may still be ok because the relevant side effects in render from that component have been moved to `useLayoutEffect` or `useEffect` in `useAnimatedProps` (so the ordering is still the same?).
2. I'm not sure about the ordering of `onLayoutEffect`, `onLayout` callbacks, and `useEffect`. createAnimatedComponent_EXPERIMENTAL doesn't use `onLayout`, but with this new method of queuing, **`onLayout` calls will likely be called before the animation queue has been flushed**. It's not clear to me whether this is bad.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D29467458
fbshipit-source-id: 2be23a8968404526d0fa394a7879fda8b5ffbfdc
Summary:
iOS 13 added a new property to `UIScrollView`: `automaticallyAdjustsScrollIndicatorInsets`, which is `YES` by default. The property changes the meaning of the `scrollIndicatorInsets` property. When `YES`, any such insets are **in addition to** whatever insets would be applied by the device's safe area. When `NO`, the iOS <13 behavior is restored, which is for such insets to not account for safe area.
In other words, this effects ScrollViews that underlay the device's safe area (i.e. under the notch). When `YES`, the OS "automatically" insets the scroll indicators, when `NO` it does not.
There are two problems with the default `YES` setting:
1. It means applying `scrollIndicatorInsets` to a `ScrollView` has a different effect on iOS 13 versus iOS 12.
2. It limits developers' control over `scrollIndicatorInsets`. Since negative insets are not supported, if the insets the OS chooses are too large for your app, you cannot fix it.
Further explanation & sample code is available in issue https://github.com/facebook/react-native/issues/28140 .
This change sets the default for this property to `NO`, making the behavior consistent across iOS versions, and allowing developers full control.
## 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
-->
[iOS] [Changed] - ScrollView scrollIndicatorInsets to not automatically add safe area on iOS13+
Pull Request resolved: https://github.com/facebook/react-native/pull/29809
Test Plan:
Updated the RNTester example to explain what to expect. Also removed the `pageScreen` modal example for now as mentioned in my Github comment.
{F628636466}
Here are screenshots of the demo app (from the original bug) before (with safe area applied to insets) & after (without safe area applied to insets):
![before](https://user-images.githubusercontent.com/428831/91644197-ea03a700-ea07-11ea-9489-be27820930eb.png)
![after](https://user-images.githubusercontent.com/428831/91644200-eff98800-ea07-11ea-8788-daf1e783639d.png)
Reviewed By: p-sun
Differential Revision: D28229603
Pulled By: lunaleaps
fbshipit-source-id: 2e774ae150b1dc41680b8b7886c7ceac8808136a
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:
Changelog: [Internal] Fix things in RNTester
* Make SectionList-contentInset example iOS only and update styling
* Fix a typo in SectionList-onEndReached example
* Fix module example styling and pressed state styling for Android
Reviewed By: kacieb
Differential Revision: D29571327
fbshipit-source-id: 5cbb68781536e21ca73ca22b01343379306babd4
Summary: Changelog: [Internal] Update title when navigating to an example
Reviewed By: kacieb
Differential Revision: D29545092
fbshipit-source-id: 7ce2f7d978601a5e11e2d60a8fd17be0249ce122
Summary: Changelog: [Internal] - iOS title jumps currently due to SafeAreaView re-mounting because of the layout structure we use. Simplified the layout tree
Reviewed By: kacieb
Differential Revision: D29545113
fbshipit-source-id: 9ed764c1c9f3da7c58baf8028454859bd50ded60
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:
Changelog: [internal]
Make sure correct text attributes are used inside of view command.
Reviewed By: sshic
Differential Revision: D29585943
fbshipit-source-id: 4748c843ff586f1dd42f3a89460afb624f9b371a
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:
#import is common in Objective C, but is a vendor-specific extension of C++, which breaks MSVC compat. Fix an #import that made its way into C++ code.
## 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
-->
[Internal] [Fixed] - Replace #import in C++ Header with #include
Pull Request resolved: https://github.com/facebook/react-native/pull/31805
Reviewed By: sammy-SC
Differential Revision: D29553429
Pulled By: javache
fbshipit-source-id: d609981f0c6a756eafb58d50e98975625d08de21
Summary: Changelog: [Internal] - Move SectionList examples together. An interim state for next diff to add a 3rd level of navigation so each example is rendered in separate surface.
Reviewed By: kacieb
Differential Revision: D29480143
fbshipit-source-id: f7f10920bd4ab938665f17f0a80debaff55b9788
Summary:
Changelog:
[Internal] - Rename some types and components in RNTester to support work for tertiary levels of navigation.
module = component | api
moduleExample = an example of a certain feature a module
Reviewed By: kacieb
Differential Revision: D29381875
fbshipit-source-id: c348bcbb73aaf95e85928bb14080a097e685cc78
Summary:
Add a test case showing off a pressable sticky header to RNTester.
Note that this test case does not follow the styling of the other ScrollView Examples. I chose not to make it follow the styling because the existing examples need to be refactored later to not use custom buttons.
Changelog:
[General][Added] Add Pressable Sticky Header example to ScrollViewExamples in RNTester
Reviewed By: lunaleaps
Differential Revision: D29437827
fbshipit-source-id: 3ccee5df99bc6f00a04e1ecbd47fbe86b1eda4dc
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:
When you reload React Native surfaces via the CMD + OPT + R keystroke, this is the actual code that executes:
https://www.internalfb.com/code/fbsource/[9c79fc6a17b7738b391a605412abf1cb15ef8ea1]/xplat/js/react-native-github/React/CoreModules/RCTDevSettings.mm?lines=172-175%2C179-183
It's only executed when RCTDevSettings is instantiated by the bridge. So, if only bridgeless surfaces are loaded, then CMD + OPT + R doesn't work.
## Fix
In this diff, I ensure that
1. We set up the reload listener when RCTDevSettings is *first* instantiated
2. We clear the reload listener when all instances of RCTDevSettings are invalidated.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D29437952
fbshipit-source-id: 9f2ff8340575c0ed881df26249433b2075bbd2ac
Summary:
The Facebook app can have both bridge and bridgeless surface. Each type of surface has its own DevMenu. It's important to specify which DevMenu is being rendered, because not doing so can make for some confusing/frustrating devx (e.g: the bridgeless dev menu shows up for bridge surfaces: https://pxl.cl/1L1m7).
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D29439980
fbshipit-source-id: 24de1e6b44e5315c0cee0684d0db5df31514d3e2
Summary:
When using lock-holder objects, it is typically required to conduct all unlocking and relocking through them. That way, the RAII lock-holder does not attempt to unlock an unlocked mutex should the code throw after unlocking but before relocking.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D29238721
fbshipit-source-id: 2403ce8c9e86f96b56a35a456e017486a2854c74
Summary:
A future version of Flow will make the `indexed_access` option on by default. Turn it off explicitly in xplat until we're ready to deploy.
Changelog: [Internal]
Reviewed By: panagosg7
Differential Revision: D29468755
fbshipit-source-id: 1ae5bb5f57315a2dab3072cc25689c3fc72ef871
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