Summary:
This change allows native activities and fragments to also handle onActivityResult callbacks, in addition to sending the result to React Native.
Changelog:
[Android][Changed] - Call super.onActivityResult in ReactActivity's onActivityResult()
Reviewed By: JoshuaGross
Differential Revision: D30232449
fbshipit-source-id: cb080d6f2eff57dcf839660ee715cb4068ffcdd5
Summary:
Fabric core uses a lot of traits - I am reserving a few more for core usage, and also exposing a few "unreserved" traits.
It is recommended that all custom components that do use traits rely on these constants instead of hard-coding any trait values. That way, in the unlikely event that these values change in the future, it will not break components.
Changelog: [Internal]
Reviewed By: cortinico, RSNara
Differential Revision: D30401743
fbshipit-source-id: fb2e8f5cf33c94e31a0c25a89055acfc4eccf066
Summary:
Update FabricUIManager methods for `SurfaceHandler` to start usual rendering or prerendering based on presence of the view instead of using two methods with same logic.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D30346502
fbshipit-source-id: 297f2b4a16dc7af7c36379252bd73e6dc953ff59
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
