Summary:
This is necessary otherwise when building from source on JVM < 11, the `compileJava`
task of the Gradle Plugin will fail with `invalid source: 11`.
Essentially the Gradle build will not even start because of this. Instead we delegate
to a better formatted warning from either AGP or from our plugin.
Changelog:
[Internal] [Changed] - Set Java source/target compatibility for react-native-gradle-plugin to 8
Reviewed By: ShikaSD
Differential Revision: D34111799
fbshipit-source-id: 57ab11fe6c4532576776b586f75e8fcb5c71adcd
Summary:
Removes duplicated code in SharedColor conversions. The original copy was done for the MapBuffer experiment, as the method was returning `folly::dynamic` instead of integer. Nothing prevents us from returning integer here directly, so we can keep one implementation.
Changelog: [Internal] - Removed duplicated SharedColor conversion for Android
Reviewed By: javache
Differential Revision: D33797490
fbshipit-source-id: 196657f0616e6cb7e987225b76328fe77fd6c28a
Summary:
you can see discussion here: https://github.com/reactwg/react-native-releases/discussions/13#discussioncomment-2069527
we were getting this error message when we build Gradle with other than 11 JVM
```
> Task :react-native-gradle-plugin:compileJava FAILED
2 actionable tasks: 2 executed
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':react-native-gradle-plugin:compileJava'.
> invalid source release: 11
```
this solution is suggested by mikehardy
after this PR, now the error is like this
```
**************************************************************************************************************
ERROR: requires JDK11 or higher.
Incompatible major version detected: '8'
**************************************************************************************************************
```
## 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] - jvm 11 error message
Pull Request resolved: https://github.com/facebook/react-native/pull/33048
Test Plan: install other than 11 java version and just run `./scripts/test-manual-e2e.sh` this command at the root of RN repo than this error will appair `invalid source release: 11`
Reviewed By: ShikaSD
Differential Revision: D34110990
Pulled By: cortinico
fbshipit-source-id: c142a363c7cec0db65d5ab9da858fd25866c7c49
Summary:
I'm updating the `test_android_template` CI step to use the result of `build_npm_package` instead of sed-ing the RN version to `file:..`.
This should be more robust and will allow to install transitive deps automatically, without having to deal with separate installation steps.
This also fixes the broken CI for Android
Changelog:
[Internal] [Changed] - Update `test_android_template` to use `build_npm_package`
Pull Request resolved: https://github.com/facebook/react-native/pull/33068
Reviewed By: ShikaSD
Differential Revision: D34083047
Pulled By: cortinico
fbshipit-source-id: de34472d5737db445cfc0d4b1c6feaf1e746bb61
Summary:
This function is only used by the RNHostComponentList route. Let's move it into the route, so that we could keep the StaticViewConfigValidator slim.
This will also allow us to more heavily customize this function for the route.
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D34026073
fbshipit-source-id: c3b3a93aed6007fadda2993afa52c28c028f6327
Summary:
In order to support AnimatedColor.setValue for platform colors, we need to pass the platform color object to the native animated node which will then resolve and apply the color.
Thus, the approach is:
- Add a new API updateAnimatedNodeConfig to NativeAnimatedModule
- [JS] On AnimatedColor.setValue, if the value is a platform color, then we call updateAnimatedNodeConfig
- [Android] We introduce AnimatedNodeWithUpdateableConfig interface with a method updateConfig. On ColorAnimatedNode.java, we use updateConfig to resolve and apply the color
Changelog:
[Internal][Fixed] - Use context from view when resolving platform color
Reviewed By: javache, mdvacca
Differential Revision: D34025193
fbshipit-source-id: 8b368f6b7cb2cf7cebe8b66461cd4185cbadd44c
Summary:
There are cases where the activity may not exist (such as for VRShell panel apps). In this case we will search for a view associated with a PropsAnimatedNode to get the context.
Changelog:
[Internal][Fixed] - Use context from view when resolving platform color if activity doesn't exist
Reviewed By: javache
Differential Revision: D34022882
fbshipit-source-id: c316935af1034ea770f3ef9334f77d6dc783fb27
Summary:
We should now be able to remove the explicit `react-native-gradle-plugin` dependency
from the `template/package.json` file.
Changelog:
[Android] [Changed] - Remove `react-native-gradle-plugin` as a dependency from template's package.json
Reviewed By: motiz88
Differential Revision: D34050589
fbshipit-source-id: c8d4e4fba481af6b56723906b71411132d60aded
Summary:
Similarly to what we did for react-native-codegen, I'm introducing
a dependency between RN and the Gradle plugin, to be processed upon OSS bumps.
Changelog:
[General] [Added] - Make react-native depend on react-native-gradle-plugin
Reviewed By: motiz88
Differential Revision: D31334773
fbshipit-source-id: 978da4946b7864d891553e6a7dcb67783399e76f
Summary:
Updates early return in the CREATE command codepath that checks if the view already exists before allocating it. Normally the view state is expected to be created only if the view is preallocated, but empty view state is also created for the flattened nodes when they create an event emitter.
By checking the view existence, we can ensure that view was indeed preallocated before, and skip for optimization purposes.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D34050884
fbshipit-source-id: 489fc1052fec9f71712ea729121ac8ef3e3f3d4e
Summary:
Some test to make sure hermes engine follows the Chrome DevTools Protocol for all implemented Debugger Notifications
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D34055503
fbshipit-source-id: 8c2dd1066ba2b68e395226f15954d303894d0365
Summary:
Some test to make sure hermes engine follows the Chrome DevTools Protocol for all implemented Debugger Responses
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D34052619
fbshipit-source-id: d213ed41335b64bf3168a43ce043f2c57f05fc52
Summary:
This event listener does nothing by default and will do nothing if (developer) users don't explicitly create some telemetry system for their own app.
This EventEmitter makes that easier but isn't necessarily tied to telemetry, especially since it does nothing at all by default.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D34060116
fbshipit-source-id: 9345a52f502e0225358fdaa1431c052a70fa54ce
Summary:
This will be used from the React JS renderer in a followup PR.
Changelog: [Added][JS] New event telemetry mechanism exposed from JS to supercede the Pressability-specific telemetry mechanism
Reviewed By: ryancat
Differential Revision: D33986916
fbshipit-source-id: 912d0b351869348f0ca6e5f6a882fc0501c2c7f0
Summary:
This diff separates the content view creation logic from existing `RedBoxDialog` logic. After the change, `RedBoxDialog` is no longer a subclass of `Dialog`, but behaves like a dialog with forwarding pattern to delegate dialog API to internal member. This will keep the APIs consistent with dependent components.
The motivation of the change is to make the content view reusable. This is important in VR surface where we don't have activities and necessary implementations for Dialog to show.
Changelog:
[Android][Internal]
Reviewed By: javache
Differential Revision: D34016503
fbshipit-source-id: 261594bda9f6fb2d83764a1e5ec2e9e60d8d39a3
Summary:
We put the `:interfaces` target on the dependencies list for `:devsupport` target in the [BUCK file](https://fburl.com/code/lrr1c0pn). In the following diffs I will need to put the interface [`/devsupport/RedBoxHandler`](https://fburl.com/code/v53euvps) on to [`/devsupport/interfaces/DevSupportManager`](https://fburl.com/code/k8gwxa0f). This violates the dependency rule.
Since `RedBoxHandler` is an interface, I moved it to the interfaces list in this diff to unblock.
Changelog:
[Android][Internal]
Reviewed By: yungsters
Differential Revision: D33987834
fbshipit-source-id: 77a1ee14bd10c6bbaac2ee465ae7050e99ed0399
Summary:
Probably my smallest PR yet, this just fixes a comment in the template's Java files.
## 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
-->
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/33050
Reviewed By: christophpurrer
Differential Revision: D34045805
Pulled By: cortinico
fbshipit-source-id: a7355b4dbae84b79ee9d68e2524393d03cda67fc
Summary:
https://github.com/facebook/react-native/commit/c974cbff04a8d90ac0f856dbada3fc5a75c75b49 changed the border colors to be of UIColor instead of CGColor. This allowed working with dark mode to switch the border colors automatically. However, in certain situation the system can't resolve the current trait collection (see https://stackoverflow.com/a/57177411/2525941). This commit resolves the colors with the current trait collection to ensure the right colors are selected. This matches with the behavior of how the background color is resolved (also in displayLayer:).
## Changelog
[iOS] [Fixed] - Resolve border platform color based on current trait collection
Pull Request resolved: https://github.com/facebook/react-native/pull/32492
Test Plan: Same test plan as https://github.com/facebook/react-native/pull/29728
Reviewed By: sammy-SC
Differential Revision: D33819225
Pulled By: cortinico
fbshipit-source-id: 2f8024be7ee7b32d1852373b47fa1437cc569391
Summary:
changelog: [internal]
In order to call `RuntimeScheduler::callExpiredTasks`, we need to pass it to `Scheduler` through context container.
Reviewed By: javache
Differential Revision: D34042293
fbshipit-source-id: 62d18507fb107c5be2ac9d003f63735aab6a09ac
Summary:
changelog: [internal]
Rename method so it does not collide with immediates that already exist in React Native.
Reviewed By: javache
Differential Revision: D34041418
fbshipit-source-id: 0ae75b683983c3be50320b195a7068d7178b0ed8
Summary:
I was trying to add an object property to my ViewManager and got a really opaque error (and I almost thought Objects weren't supported by the codegen) until I realized it expected the object to wrapped in a $ReadOnly type.
Changelog: [Internal] Improved error in codegen
Reviewed By: mdvacca
Differential Revision: D34006557
fbshipit-source-id: b3ab15a40cb66fdcd377f4e68df92060498e8e7f
Summary:
Some test to make sure hermes engine follows the Chrome DevTools Protocol for all implemented Debugger Messages
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D34042008
fbshipit-source-id: 3a074e9840706ca977ff86d050e67b0dcea5c7ef
Summary:
This PR fixes the opacity bug where it fails to properly react to state change. This PR resolves the issue detailed in https://github.com/facebook/react-native/issues/32476
## 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
-->
[General] [Fixed] - Fixed opacity value in TouchableOpacity
Pull Request resolved: https://github.com/facebook/react-native/pull/32956
Test Plan: The code I added in componentDidUpdate does solve the issue and passes all the test cases
Reviewed By: ryancat
Differential Revision: D33766718
Pulled By: cortinico
fbshipit-source-id: 951bedf22619fc12e66156d0a6074cd8adf1d3eb
Summary: this is to break any unique dependencies this module is bringing in from the original module it was in.
Reviewed By: sammy-SC
Differential Revision: D33935581
fbshipit-source-id: 2ccf5b4a9d1dca1e6059cafb888091e450f6f980
Summary:
Invoke registerForRemoteNotifications on main UI thread to avoid error messages in Xcode.
Changelog:
[iOS][Fixed] - Invoke registerForRemoteNotifications on main UI thread.
Reviewed By: philIip
Differential Revision: D33780141
fbshipit-source-id: 64b825dfc15e7ac262e210b90bb334a7e415e402
Summary:
When setting ScrollView's contentOffset, if the ScrollView hasn't been laid out yet when ReactScrollViewManager.setContentOffset is called, then scroll position is never set properly. This is because the actual scroll offset (0, 0) was being passed into setPendingContentOffsets, instead of the desired scroll offset. Thus,
when ReactScrollView.onLayout gets called, ReactScrollView.scrollTo gets called with (0, 0).
Also updates out of date comments,
Changelog:
[Android][Fixed] - Fix ScrollView contentOffset
Reviewed By: ryancat
Differential Revision: D34015853
fbshipit-source-id: 84141a663fdb0ace2be7cef61f14944cb08125d1
Summary:
## Rationale
verifyComponentAttributeEquivalence is the legacy check for making sure that Static ViewConfigs match Native ViewConfigs. Eventually, we should just delete this module/check from the codebase.
## Changes
This diff migrates the RNHostComponentViewConfig differences screen to display the ViewConfig differences using the new StaticViewConfigValidator validation result vs the legacy validator's lefthandObjectDiff method.
## Benefits:
- Now, **all the diffing logic** on this route uses the new StaticViewConfigValidator.
- This takes us one step closer towards deleting verifyComponentAttributeEquivalence
- StaticViewConfigValidator [supports ignoring ViewConfig properties](https://fburl.com/code/2it5r7py). Now, the RNHostComponentViewConfig respects these ignores.
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D34017602
fbshipit-source-id: 3ad909adcbb95b932a269dd55dd5445834a9cfd4
Summary:
Update javadoc of ReactRoot.getState() since the task was fixed and the API remained the same
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D33981298
fbshipit-source-id: 0136a640b884a787b0a20162781735630c1fa1c7
Summary:
Optimize Android RNTester build workflow to run in a single job instead of running two separate Gradle invocations as Nicola suggested here https://github.com/facebook/react-native/pull/33033#discussion_r799066446
## Changelog
[General] [Changed] - Optimize CicleCI Android RNTester build job to run a single gradle invocation
Pull Request resolved: https://github.com/facebook/react-native/pull/33042
Test Plan: Make sure builds are working as expected and CI is green
Reviewed By: ShikaSD
Differential Revision: D34001440
Pulled By: cortinico
fbshipit-source-id: 90845482b69e5c2839d570db359223ee614ebf1b
Summary:
Changelog: [Internal]
Fixes some files to use the preferred `import type {Foo}` syntax instead of `import {type Foo}`.
Reviewed By: rh389
Differential Revision: D34001108
fbshipit-source-id: 64675fefa71b6832118eabc60c825c65b87514d9
Summary:
Changelog:
[General][Fixed] - Remove illegal private property access in VirtualizedSectionList.scrollToLocation
`VirtualizedSectionList.scrollToLocation` internally uses `VirtualizedList`'s `_getFrameMetricsApprox` method. This method is private by convention (since it's `_`-prefixed), but under certain build setups this is also enforced at runtime, so using `scrollToLocation` can throw an error.
Here, we rename this internal method to `__getFrameMetricsApprox` (adding another leading underscore) which opts it out of being treated as private, while still communicating that it's not part of the public API. We also delete the Flow error suppression that masked this issue.
For reference: This convention for private methods (including the double-underscore opt out) has its roots in Facebook's pre-Babel [JSTransform](https://github.com/facebookarchive/jstransform/blob/master/visitors/es6-class-visitors.js) compiler and is implemented in Flow as [`munge_underscores=true`](https://flow.org/en/docs/config/options/#toc-munge-underscores-boolean).
Reviewed By: yungsters
Differential Revision: D33982339
fbshipit-source-id: 498563c59d42549c94fe90d363677d6d3ea35d2d
Summary:
changelog: Attempt to fix a crash during app termination on iOS in the new renderer
We need to stop all surfaces before it is terminated to prevent app from crashing.
The crash happens on background thread.
The app crashes because it is probably accessing static variable that has been deallocated by the main thread. How can main thread deallocate things when background thread is still running? Because main thread is attached to our app's process, background thread is provided by the system and continues to live.
Reviewed By: ShikaSD
Differential Revision: D33977161
fbshipit-source-id: 87546d7b70d1aa465e63f0d37b70bae1fffa2304
Summary:
Add 4 new jobs to CI in order to test RNTester builds on both Android and iOS using Hermes and JSC
Closes https://github.com/facebook/react-native/issues/32676
## Changelog
[General] [Added] - Add build tests for RNTester to CircleCI
Pull Request resolved: https://github.com/facebook/react-native/pull/33033
Test Plan: Make sure builds are working as expected and CI is green
Reviewed By: lunaleaps
Differential Revision: D33982864
Pulled By: philIip
fbshipit-source-id: 00b2116be1b6484324e8162cc691b1d0863d282d
Summary:
changelog: [internal]
With multiple requests to the runtime, we need to make sure they are all granted before React continues with rendering. A boolean is not enough to track this. The first lambda that has VM will set it to false and subsequent requests will have to wait for React to finish rendering.
To prevent this, we can count how many lambdas are pending access to the runtime.
Reviewed By: ShikaSD
Differential Revision: D33792734
fbshipit-source-id: f785fae3575470179dd69acc6a466211b79b633b
Summary:
Running `test-manual-e2e.sh` from any folder other than the repo root results in errors regarding files not existing, that's because we're not taking into consideration the path from where the script is invoked. This PR updates it so that we get the absolute path of the script and then use it to get the parent directory and `cd` to the repo root folder.
Closes https://github.com/facebook/react-native/issues/32999
## Changelog
[Internal] [Fixed] - fix access to relative paths when invoking `test-manual-e2e.sh` from folders other than the repo root
Pull Request resolved: https://github.com/facebook/react-native/pull/33000
Test Plan:
1. Clone this repo
2. Navigate to the rn-tester folder `cd packages/rn-tester/`
3. Run `../../scripts/test-manual-e2e.sh`
4. Select RNTester, Android and Hermes
https://user-images.githubusercontent.com/11707729/151730441-18bc37de-0224-4f5e-a2fe-408e3ace5c1f.mov
Reviewed By: ShikaSD
Differential Revision: D33915561
Pulled By: cortinico
fbshipit-source-id: 66f2d1ebee50bba3fe884d6346ea08ffced47a96
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33038
While rolling out RN 0.68.x we noticed that `libhermes.so` and `libjsc.so` were included
inside the final .aar we publish to NPM. This forced users (on both old or new arch) to
specify a `pickFirst` directive inside their packaging option (which is unpractical and
risky as the two .so might not be compatible each other if they're coming from
different Hermes/JSC versions).
Changelog:
[Android] [Fixed] - Do not bundle libhermes.so or libjsc.so inside the React Native Android AAR
Reviewed By: ShikaSD
Differential Revision: D33979107
fbshipit-source-id: 0b71d59f210b8bc9903cd0f30ed6e2120aab99e0
Summary:
changelog: [internal]
pass raw ShadowNode instead of shared_ptr. Ownership is not transferred, shared_ptr is misleading.
Reviewed By: javache
Differential Revision: D33917010
fbshipit-source-id: 4d9fdd4b4e0376149f1719ad160b957de4afdce3
Nicola Corti
Kacie Bawiec
Andrei Shikov
Muhammad Numan
David Vacca
Pieter De Baets
CodemodService FBSourceClangFormatLinterBot
Ramanpreet Nara
Genki Kondo
Neil Dhar
Raphael Herouart
Joshua Gross
Xin Chen
Marc Rousavy
Danilo Bürger
Samuel Susla
Hetan Thakkar
Phillip Pan
Moses DeJong
Gabriel Donadel Dall'Agnol
Moti Zilberman
Pieter Vanderwerff