Summary:
Android Gradle Plugin 7 removed dependency configurations, and it includes compile. Below is a snipped from release notes https://developer.android.com/studio/releases/gradle-plugin
I can confirm that RN 0.65.0 app is running as expected on Android with the patch.
> **compile**
Depending on use case, this has been replaced by api or implementation.
Also applies to *Compile variants, for example: debugCompile.
## Changelog
[Android] [Changed] - Android Gradle Plugin 7 compatibility
Pull Request resolved: https://github.com/facebook/react-native/pull/32030
Test Plan: Create a project with RN 0.65.0 and upgrade Android Gradle Plugin to 7.0.0, and Gradle to 7.0.2. It'll fail to sync. Then apply the change, and it'll sync as normal, and build the app.
Reviewed By: passy, ShikaSD
Differential Revision: D30394238
Pulled By: cortinico
fbshipit-source-id: cabc25754b9cd176a7d6c119d009728f2e5a93d9
Summary:
When retrieving the device dimensions through the JS `Dimensions` utility, the result of `Dimensions.get` can be incorrect on Android.
### Related issues
- https://github.com/facebook/react-native/issues/29105
- https://github.com/facebook/react-native/issues/29451
- https://github.com/facebook/react-native/issues/29323
The issue is caused by the Android `DeviceInfoModule` that provides initial screen dimensions and then subsequently updates those by emitting `didUpdateDimensions` events. The assumption in that implementation is that the initial display metrics will not have changed prior to the first check for updated metrics. However that is not the case as the device may be rotated (as shown in the attached video).
The solution in this PR is to keep track of the initial dimensions for comparison at the first check for updated metrics.
## Changelog
[Android] [Fixed] - Fix Dimensions not updating
Pull Request resolved: https://github.com/facebook/react-native/pull/31973
Test Plan:
### Steps to reproduce
1. Install the RNTester app on Android from the `main` branch.
2. Set the device auto-rotation to ON
3. Start the RNTester app
4. While the app is loading, rotate the device
5. Navigate to the `Dimensions` screen
6. Either
a. Observe the screen width and height are reversed, or
b. Quit the app and return to step 3.
### Verifying the fix
#### Manually
Using the above steps, the issue should no longer be reproducible.
#### Automatically
See unit tests in `ReactAndroid/src/test/java/com/facebook/react/modules/deviceinfo/DeviceInfoModuleTest.java`
### Video
https://user-images.githubusercontent.com/4940864/128485453-2ae04724-4ac5-4267-a59a-140cc3af626b.mp4
Reviewed By: JoshuaGross
Differential Revision: D30319919
Pulled By: lunaleaps
fbshipit-source-id: 52a2faeafc522b1c2a196ca40357027eafa1a84b
Summary:
Fix the CSS on the main Modal test
Move the warning message for the "Transparent" switch to below the switch, since warnings messages are usually under the field they're warning.
Move Presentation Style to be before Transparent, since Transparent is a modifier of "overFullScreen" Presentation Style.
Reviewed By: lunaleaps
Differential Revision: D30323087
fbshipit-source-id: b13d6c958145096da95c9888181ff457b093fb49
Summary:
In this diff:
1. Convert the ReactNativeLogger to c function for the future compatibility.
2. Bind the log function from Catalyst app
3. Update the call site
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D30271863
fbshipit-source-id: 4c0ea704cf19f53468a3b72631353959ea999884
Summary:
This PR fixes the border-style that is not respected when drawing a border with 0 border-radius on Android. This would cause the faster `drawRectangularBackgroundWithBorders` path to be used, but that uses rectangular drawing and doesn't support dashed/dotted stroke patterns.
This PR changes the behavior to use the generic `drawRoundedBackgroundWithBorders` code-path which does support dashed/dotted border-styles.
## Changelog
`[Android] [Fixed] - Fix dashed/dotted border-drawing when border-radius is 0`
Pull Request resolved: https://github.com/facebook/react-native/pull/28359
Test Plan:
**Faulty situation:**
**After the fix:**
Reviewed By: lunaleaps
Differential Revision: D20590739
Pulled By: charlesbdudley
fbshipit-source-id: 18657ea21e54f763e22c623bf979b3500c1bdcbd
Summary:
This PR aims to resolve iOS can't dismiss Modal on swipe gesture.
https://github.com/facebook/react-native/issues/29319
When modal presentationStyle is pageSheet, iOS allows to dismiss the modal using swipe gesture. This PR adds support for that feature
## 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] [Added] - Support for onRequestClose for iOS Modal component.
Pull Request resolved: https://github.com/facebook/react-native/pull/31500
Test Plan:
- If onRequestClose updates the visibility state, modal will be closed.
```
<Modal
visible={visible}
animationType="slide"
presentationStyle="pageSheet"
onRequestClose={dismiss}>
</Modal>
```
https://user-images.githubusercontent.com/23293248/117590263-36cd7f00-b14c-11eb-940c-86e700c0b8e7.mov
## Notes
- In this PR, only support for partial drag is added. i.e. user can't drag the modal up and down completely. I added full user dragging but reverted in this [commit](https://github.com/facebook/react-native/commit/bb65b9a60d54b61652d608661eba876b49be3b17) to support controllable onRequestClose. If someone has any suggestion to have full draggable support + controllable onRequestClose, please let me know.
<!--
the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes the user interface. -->
Reviewed By: p-sun
Differential Revision: D30041625
Pulled By: sammy-SC
fbshipit-source-id: 9675da760bd5c070c4f0e1d30271c8af5c50b998
Summary: Changelog: [Internal] - Annotated the MessageCallback and ConnectionCallback params of the ReconnectingWebSocket with Nullable
Reviewed By: makovkastar
Differential Revision: D30298832
fbshipit-source-id: 4e0a6ea339d1d8b25fb7bb24dfbada93d5cebc96
Summary:
On Android, when a hardware keyboard is connected pressing the escape key will partially dismiss an active `<Modal>` without calling the `onRequestClose` callback. The modal will disappear, but I beleive the underlying activity may still be present, blocking interaction with the main app below and leaving things in a partially broken state.
This code change allows the escape key to be handled in the same way as the hardware back button, calling the `onRequestClose` and allowing the developer to decide the behaviour.
This issue isn't present on iOS, so no change is required there.
## 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 Modal being dismissed incorrectly when pressing escape on a hardware keyboard
Pull Request resolved: https://github.com/facebook/react-native/pull/31564
Test Plan: I've tested this manually locally, but unsure if it's possible to test in an automated way as the emulator didn't respond to a hardware escape key in the same way as a physical device.
Reviewed By: ShikaSD
Differential Revision: D28953718
Pulled By: lunaleaps
fbshipit-source-id: 5547bc5d894da0d3d9daf4515b1af9c2407815db
Summary:
seperated -> separated
## 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] - Fixed typo in comment
Pull Request resolved: https://github.com/facebook/react-native/pull/31067
Test Plan: NONE
Reviewed By: sammy-SC
Differential Revision: D30176244
Pulled By: sota000
fbshipit-source-id: 617607aaa7eb5f613344773c4bbbc09a8c5096c1
Summary:
After this diff, when ReactFeatureFlags.warnOnLegacyNativeModuleSystemUse is enabled, the legacy NativeModule infra will log soft exceptions whenever legacy NativeModules are accessed/used.
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D30272695
fbshipit-source-id: 7111402c1d8b883a600dcb4559e9ff1d56447070
Summary:
When the TurboModule system is enabled, C++ NativeModules shouldn't be used in production. We'll use this JReactSoftExceptionLogger to log soft exceptions from C++ NativeModules this scenario.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D30272694
fbshipit-source-id: 8dadcfe51bcbc353d438d1a403e74da5e2cb9546
Summary:
When ReactFeatureFlags.warnOnLegacyNativeModuleSystemUse is true, we will log a SoftException, whenever:
1. A Java/Cxx NativeModule is created by the legacy system.
2. Any method on the Java NativeModule is executed, including getConstants().
NOTE: Logs to CXXModule use incoming.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D30252953
fbshipit-source-id: 570929624d0114bb298c593ba909e5cdbd54bd6c
Summary:
When true, this flag will cause React Native to start logging soft exceptions, whenever the legacy NativeModule system is used. This flag is independent of useTurboModules. In practice, it's only enabled when TurboModules is enabled.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D30250363
fbshipit-source-id: f610567c5b99a4fbf8252c3962908668f483d028
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32007
This Diff simplifies the codegen Gradle build.
Previously the build used to have a 2-level nesting of included build.
Turns out that the `react-native-codegen/android/build.gradle` build
is just providing a task and including an inner build that contains the codegen
Gradle plugin. I've moved such plugin to the outer build.
This will also make sure that the Gradle plugin files are properly index by the
IDE when opening the build (as nested included build are not yet supported).
Changelog:
Internal - Flatten the `react-native-codegen` Gradle included build
Reviewed By: fkgozali, ShikaSD
Differential Revision: D30227784
fbshipit-source-id: af304afeeba1926f8b7b5b47cf69889d3f808f5f
Summary:
This is just a minor bump in the Android Gradle plugin.
Changelog:
[Android][Changed] - Bumped AGP to 4.2.2
allow-large-files
Reviewed By: ShikaSD
Differential Revision: D30220591
fbshipit-source-id: 217a21e4935bcd258ac3bcd45c7fb1ff5c0a1ead
Summary:
Globbing is case sensitive only when eden is enabled. This causes Android cold builds to regress by 2 minutes because a large number of react native targets have to be built and fetched.
This change causes srcs to match with and without eden.
Changelog: [Internal]
Reviewed By: cute-jumper
Differential Revision: D30266076
fbshipit-source-id: 39ac2cbfa146fcdda1d8d3a6f40b0ec41bfb3c2f
Summary:
ReactSoftException makes it seem like the class is an Exception, when it's actually a logger. This rename I think is more appropriate.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D30251735
fbshipit-source-id: 550bd543388e698774ec31753200bd3f722d8c17
Summary:
After creating and using this utility, we learned that (1) it's really useful, and (2) its interface is good enough. So, let's un-deprecate this utility.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D30251651
fbshipit-source-id: d1ecf81484f865587a5552d5ddf0e68da86397d9
Summary:
We had some confusion lately, where errorName was used to dump "error message". This caused problems in Scuba.
This doc should add some clarity on what is expected from endFailure users.
Changelog:
[Internal][Added] - Documentation for method in UserFlow.js class
Reviewed By: mityal
Differential Revision: D30192127
fbshipit-source-id: d057668aab714a9342131c83daf41cbe9372cb39
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/31998
Overall Context: We want to add a way to log errors (e.g. mustfix, warn, etc on the server with stack trace) without crashing the app (e.g. react_native_assert crashes the app).
This diff: I am writing very simple logger functions which will get resolved at build time depending on the platforms/apps.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D30174404
fbshipit-source-id: 2e5bc865dd8576c5a758c56e080a1e582a8c3ada
Summary:
Changelog: [Internal]
when we try to write a `SharedColor` type prop in the renderer, the template function we match to is the following:
https://www.internalfb.com/intern/diffusion/FBS/browsefile/master/xplat/js/react-native-github/ReactCommon/react/renderer/core/propsConversions.h?commit=28dacb972cda702d37dedd4612bc67c212d4d9eb&lines=108-132
this is because `SharedColor` is an alias of `better::optional<Color>`. ultimately, this causes a crash in L130 - the template deduction in L130 interprets the T as an `int`, rather than `SharedColor`, but our `rawValue` is pointing to `SharedColor`.
there was a number of options i considered, but didn't feel the most correct:
- wrapping `SharedColor` in another `better::optional` - this felt like a hack and didn't really provide any real benefits of the `optional` wrapper.
- writing a template specialization on SharedColor - this didn't seem future proof because we could introduce another type that could potentially wrap an integer, which doesn't seem impossible in the future - then we would get some conflict with our `SharedColor` conversion, which is custom to the behavior of colors.
- coercing the template during the function call - from an engineering perspective, this didn't seem like a great idea since it isn't clear to the engineer that this would be necessary and they would most likely only find out to do this after seeing a crash on their builds.
i ultimately decided to convert `SharedColor` to a simple class wrapper, similar to the implementation already used in Android. this alleviates all of the concerns with the other options above.
Reviewed By: sammy-SC
Differential Revision: D30149880
fbshipit-source-id: 7e8abafcd9fd7465b13ef227d140e859f8df6ecd
Summary:
Changelog: [Internal]
in this diff, we iterate through the list of color passed down in the props, and write the RGBA value of the first valid UIColor
Reviewed By: sammy-SC
Differential Revision: D30110297
fbshipit-source-id: c6730110129d0fe1f784fa89cd26b46d3dda7f28
Summary:
Changelog: [Internal]
in this diff, we add the logic to handle converting PlatformColor strings to their corresponding RGBA values, using `UIColor`'s API as the source of truth of these colors.
functionality not covered yet:
- customColor
- iOS Dynamic Colors
- Variant Colors
Reviewed By: sammy-SC
Differential Revision: D30103451
fbshipit-source-id: 7d7be0f08dc2fb95b606b8f5d73784766787a574
Summary:
This diff is cleaning up some configurations in the `Android.mk` files
of the native build. Specifically I simplified some of the rules and removed
a duplicate file specification.
Changelog:
Internal - Cleanup warnings in the NDK build
Reviewed By: ShikaSD
Differential Revision: D30220715
fbshipit-source-id: a100953fe977879a6d28cb0a2ef4b3358fb7c774
Summary:
Changelog: [Internal]
Currently, `global` is typed as `any` and any `global` properties
accesses are untyped. This diff add a flow libdefs for the `global`
object as a start point.
Reviewed By: yungsters
Differential Revision: D30000895
fbshipit-source-id: ab6988d01921a3c2a3434b534b2f69083570fb6d
Summary:
changelog: [internal]
If nodesManager has the information if animated node is managed by Fabric, we can't decide if the operation queue should be flushed before it is flushed. Therefore, keep the information about animated nodes inside a set instead of nodesManager.
For simplicity, I will refer to class `RCTNativeAnimatedTurboModule` as *NativeAnimated* and to `RCTNativeAnimatedNodesManager` as *NodesManager*
Notice that each call to *NativeAnimated* is queued up in `_operations` or `_preOperations`. When the queues are flushed, only then methods are called on `RCTNativeAnimatedNodesManager`.
There are two mechanisms that flush operations.
One is triggered by `RCTMountingManager` before mounting operations are applied and after they are applied. This works fine but is important to paint the picture.
The second mechanism is inside `[RCTNativeAnimatedTurboModule startAnimatingNode]`. It flushes the queues for Fabric nodes only (not sure why Fabric nodes only, I couldn't find any explanation in old diffs). It checks with *NativeAnimated* if a node is managed by Fabric. Keep in mind, *NodesManager* only knows about the nodes when the queues have been flushed.
Exampe:
JavaScript calls methods on *NativeAnimated*.
For example:
1. `createNode`
2. `connectAnimatedNodeToView`
3. `startAnimatingNode`. (here, the queues should be flushed, since we are in Fabric)
All of these operations are queued up and for as long as `RCTMountingManager` executes mounting, all proceeds as expected.
But if those operations happen after mounting phase, `startAnimatingNode` will not flush the operations queues, because it can't tell if nodeTag is managed by fabric or it isn't. This is because *NodesManager* hasn't been notified about any new nodes.
Reviewed By: RSNara
Differential Revision: D30099010
fbshipit-source-id: d3fc021dd4346d1cbbda3b49ecd9d982c543e705
Summary:
Recent change in https://github.com/facebook/react-native/pull/31865 made it so if `ReactSliderManager` is created on the react context creation thread it will crash with the following error. This happens because `ReactAccessibilityDelegate` tries to create a handler on a thread without a looper.
This seems to happen because react-native-reanimated tries to get the UIManager module during its initialization which will cause view managers to be created and explains why the crash probably does not happens in RNTester or using only RN bundled modules.
```
08-03 14:44:56.318 21206 21360 E AndroidRuntime: FATAL EXCEPTION: create_react_context
08-03 14:44:56.318 21206 21360 E AndroidRuntime: Process: com.th3rdwave, PID: 21206
08-03 14:44:56.318 21206 21360 E AndroidRuntime: java.lang.ExceptionInInitializerError
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.shell.MainReactPackage.createViewManagers(MainReactPackage.java:166)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.ReactInstanceManager.getOrCreateViewManagers(ReactInstanceManager.java:882)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.CoreModulesPackage.createUIManager(CoreModulesPackage.java:137)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.CoreModulesPackage.getModule(CoreModulesPackage.java:102)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.TurboReactPackage$ModuleHolderProvider.get(TurboReactPackage.java:159)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.TurboReactPackage$ModuleHolderProvider.get(TurboReactPackage.java:147)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.bridge.ModuleHolder.create(ModuleHolder.java:191)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.bridge.ModuleHolder.getModule(ModuleHolder.java:156)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.bridge.NativeModuleRegistry.getModule(NativeModuleRegistry.java:153)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.bridge.CatalystInstanceImpl.getNativeModule(CatalystInstanceImpl.java:486)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.bridge.CatalystInstanceImpl.getNativeModule(CatalystInstanceImpl.java:462)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.bridge.ReactContext.getNativeModule(ReactContext.java:176)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.swmansion.reanimated.NodesManager.<init>(NodesManager.java:153)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.swmansion.reanimated.ReanimatedModule.getNodesManager(ReanimatedModule.java:101)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.swmansion.reanimated.ReanimatedJSIModulePackage.getJSIModules(ReanimatedJSIModulePackage.java:17)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.th3rdwave.MainApplication$1$1.getJSIModules(MainApplication.java:135)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.ReactInstanceManager.createReactContext(ReactInstanceManager.java:1329)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.ReactInstanceManager.access$1100(ReactInstanceManager.java:136)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.ReactInstanceManager$5.run(ReactInstanceManager.java:1058)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at java.lang.Thread.run(Thread.java:923)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: Caused by: java.lang.RuntimeException: Can't create handler inside thread Thread[create_react_context,5,main] that has not called Looper.prepare()
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at android.os.Handler.<init>(Handler.java:227)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at android.os.Handler.<init>(Handler.java:129)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.uimanager.ReactAccessibilityDelegate$1.<init>(ReactAccessibilityDelegate.java:185)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.uimanager.ReactAccessibilityDelegate.<init>(ReactAccessibilityDelegate.java:184)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.views.slider.ReactSliderManager$ReactSliderAccessibilityDelegate.<init>(ReactSliderManager.java:281)
08-03 14:44:56.318 21206 21360 E AndroidRuntime: at com.facebook.react.views.slider.ReactSliderManager.<clinit>(ReactSliderManager.java:301)
```
To fix it I changed the delegate creation to be done in `createViewInstance` which will be called on main thread. This is also more in line with how other accessibility delegates are created for other view managers. Since Slider is probably not used a lot, creating more delegate instance won't be an issue.
Another alternative could be to initialize a Looper on the thread that creates the react context, but it seems more involved and probably not needed.
## Changelog
[Android] [Fixed] - Create slider accessibility delegate in createViewInstance
Pull Request resolved: https://github.com/facebook/react-native/pull/31942
Test Plan: Reproduced the crash in an app and made sure this patch fixes it.
Reviewed By: JoshuaGross
Differential Revision: D30167451
Pulled By: p-sun
fbshipit-source-id: 5327130064db52ac0086e1ae5541a1b3e3954f15
Dulmandakh
alessandro
Jonathan Andrew
hank121314
Nicholas Tinsley
Paige Sun
nacam403
Dark Knight
Chris Tolliday
Rick Hanlon
Sota Ogo
Hein Rutjes
Matthew Gray
fabriziobertoglio1987
Nishan Bende
Samuel Susla
Amy Nichol
Levi Buzolic
Ikko Ashimine
Ramanpreet Nara
Luna Wei
Nicola Corti
jeswinsimon
Dmytro Voronkevych
Evan Yeung
Phillip Pan
Jordan Becker
Xuan Huang
Janic Duplessis
