Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32427
This diff refactors the `prepareJSC` task to a separate Gradle task in the `.internal` package.
The reason for this change is that `prepareJSC` was just a plain `Task` and not a `Copy` task.
It was defining a top level `doLast` action and would result in being
invalidated whenever the `build.gradle` file would change. This means that the JSC headers/source files
would have been extracted again, effectively invalidating the timestamps for the native build.
Changelog:
[Internal] [Changed] - Export prepareJSC to an internal task
Reviewed By: ShikaSD
Differential Revision: D31682293
fbshipit-source-id: 3d4cd9d9ce2fcd45e61f3c8c6685b69a622a1912
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32424
This diff refactors the `prepareBoost` task to a separate Gradle task in the `.internal` package.
The reason for this change is that `prepareBoost` was defining a `doLast` action and would result in being
invalidated whenever the `build.gradle` file would change. This means that the Boost headers/source files
would have been extracted again, effectively invalidating the timestamps for the native build.
Changelog:
[Internal] [Changed] - Export prepareBoost to an internal task
Reviewed By: ShikaSD
Differential Revision: D31662120
fbshipit-source-id: 87ba82c634da832ee54c3d13561df45d3fd71381
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32425
This diff refactors the `prepareLibevent` task to a separate Gradle task in the `.internal` package.
The reason for this change is that `prepareLibevent` was defining a `doLast` action and would result in being
invalidated whenever the `build.gradle` file would change. This means that the Libevent headers/source files
would have been extracted again, effectively invalidating the timestamps for the native build.
Changelog:
[Internal] [Changed] - Export prepareLibevent to an internal task
Reviewed By: ShikaSD
Differential Revision: D31661988
fbshipit-source-id: e55c2179a187fa156f701c25bae3b48a796e2660
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32421
This diff refactors the `prepareGlog` task to a separate Gradle task in the `.internal` package.
The reason for this change is that `prepareGlog` was defining a `doLast` action and would result in being
invalidated whenever the `build.gradle` file would change. This means that the Glog headers/source files
would have been extracted again, effectively invalidating the timestamps for the native build.
Changelog:
[Internal] [Changed] - Export prepareGlog to an internal task
Reviewed By: ShikaSD
Differential Revision: D31661668
fbshipit-source-id: efcd5505a67d6c9f02fcab7a5c3255a160215661
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32422
While working on the NDK AGP Api I realized that the `enableVmCleanup` function,
that is supposed to cleanup the extra `.so` files from the final artifacts, is broken
for apps with variants. Specifically say for a `liteDebug` app it tries to search for `.so` files inside:
```
intermediates/stripped_native_libs/lite/debug/out/lib
```
while the `.so` files are located inside:
```
intermediates/stripped_native_libs/liteDebug/out/lib
```
I've fixed changing the token of the path from `targetPath` to `variant.name`
Changelog:
[Android] [Fixed] - Fix enableVmCleanup not working for apps with product flavors
Reviewed By: ShikaSD
Differential Revision: D31654704
fbshipit-source-id: 4af3478a3079ebcde4bd8e0c62bf4df7b6c75c0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32420
While working on the NDK AGP Apis, I realized the the `applyAppPlugin` is accessed
too early inside the Gradle plugin. Specifically is accessed once the plugin is applied,
and the extension is not configured afterwards. This means that the extension is always set
the default values.
I'm fixing it moving it inside the `project.afterEvaluate` that was already need to access
the variant informations.
Changelog:
[Internal] [Changed] - Fix applyAppPlugin being accessed too early in the React App Gradle Plugin
Reviewed By: ShikaSD
Differential Revision: D31652984
fbshipit-source-id: e7ead3f8acb24372bf953fd90ad2a5dfbbeeeec0
Summary:
The [first implementation of `TextAttributes` in Fabric](https://github.com/facebook/react-native/commit/62576bcb7832e08c6fd9f9482285882c37a2ece5) included two separate props instead of `textDecorationStyle`: `textDecorationLineStyle` (single, double, ...) and `textDecorationLinePattern` (dot, dash, dotdash, ...). These two props were implemented in C++ and iOS but never supported in JS.
Pre-Fabric (and CSS) on the other hand use a single prop `textDecorationStyle: 'solid' | 'double' | 'dotted' | 'dashed'`.
This diff implements this same API in Fabric, and removes the unused `textDecorationLineStyle` and `textDecorationLinePattern` props.
Changelog:
[iOS][Fixed] - Implement `textDecorationStyle` on iOS and remove unused `textDecorationLineStyle` and `textDecorationLinePattern` from Fabric.
Reviewed By: dmitryrykun
Differential Revision: D31617598
fbshipit-source-id: f5173e7ecdd31aafa0e5f0e50137eefa0505e007
Summary:
While reworking our media picker, I ended up replacing the RNFetchBlob library to use `fetch()`, leveraging React Native's file resolver (especially to interpret `photos://` URI paths).
The migration process was pretty straightforward, however I kept getting RCTConvert errors when calling `fetch` with a `PUT` method and a blob body:
```
JSON value '<null>' of type NSNull cannot be converted to NSString
+[RCTConvert NSString:]
RCTConvert.m:59
-[RCTBlobManager handleNetworkingRequest:]
-[RCTNetworking processDataForHTTPQuery:callback:]
-[RCTNetworking buildRequest:completionBlock:]
-[RCTNetworking sendRequest:callback:]
__invoking___
-[NSInvocation invoke]
-[NSInvocation invokeWithTarget:]
-[RCTModuleMethod invokeWithBridge:module:arguments:]
Test Plan:
I'll put my `fetch` snippet here. This is using a third-party library in order to get a signed URL, but it is otherwise pretty straightforward.
This snippet would trigger an error before the changes introduced by this PR.
```js
// Setup (specific to third-party lib)
const key = `file/path/in/bucket`
const params = {
Key: key,
Bucket: 'my.awesome.bucket',
}
const s3url = await s3.getSignedUrl('putObject', params)
// Letting RN handle how to retrieve a platform-specific resource URI
const localFetch = await fetch(localPath)
// Getting the blob to upload as octet-stream
const blob = await localFetch.blob()
// Actually uploading
await fetch(s3url, {
method: 'PUT',
headers: {
'Accept': 'application/json',
'Content-Type': 'application/octet-stream',
},
body: blob,
})
```
Reviewed By: RSNara
Differential Revision: D31625636
Pulled By: sota000
fbshipit-source-id: a7770018bc3ff2f41321b1bd26ec145b86b18784
Summary:
The size information is currently not used for release branches. Further, the CI step failed because there is no PR associated with commits in RC branch. This commit fixed that error by skipping the entire work altogether.
Sample error: https://app.circleci.com/pipelines/github/facebook/react-native/10161/workflows/3625732a-531f-435d-83b6-1dbc638e1bab/jobs/215405/parallel-runs/0/steps/0-125
In theory, we should be storing RC bundle sizes as well, but the current backing Firebase DB has not been configured with proper index:
```
Error [FirebaseError]: The query requires an index.
...
```
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D31705912
fbshipit-source-id: 26757174f7937cb23d8e55066b833ae15ec011e3
Summary:
Changelog: [Internal]
making these imports a little more optimal & clean
Reviewed By: javache
Differential Revision: D31594240
fbshipit-source-id: 076610454a6f3c35ac58e97bd9f887b05b86f5bb
Summary:
Noticed we were sometimes receiving incorrect paths through the view hierarchy. This was largely harmless, as the hover events generated from this would still be correct. We just sometimes send more onExit/onEnter events than necessary.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D31434300
fbshipit-source-id: 3888270eaa16edf48f5d894a1e6daeca1ecfed1e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32403
As the title says, we should cleanup issues that are really stale (i.e. more than one year inactive).
I ended up using actions/stale which is the first party solution for this.
Changelog:
[Internal] [Changed] - Add stale GitHub action
Reviewed By: hramos
Differential Revision: D31653083
fbshipit-source-id: 48538a571183f9ff28a23e7d1fdd01980581de35
Summary:
These dynamic_casts aren't really giving us much (they have never fired once in dev! and don't run in prod anyway). They also prevent us from disabling RTTI. So, let's get rid of them.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D31634895
fbshipit-source-id: 4a9b259837127feb324f64fa3e9e23eb1cc481a6
Summary:
Using `WriteableNativeArray` directly in common code is breaking unit tests on CircleCI.
Changelog:
[Android][Internal] - Use mock of native array for sending touches
Reviewed By: mdvacca
Differential Revision: D31665842
fbshipit-source-id: 886418ff6a3f07046e8e17d4743060d80c26b288
Summary:
Nearly all of these are identical and these compiler_flags are now centralized in rn_defs.bzl. This should have NO CHANGE on build configuration, the flags have just moved for now.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D31631766
fbshipit-source-id: be40ebeb70ae52b7ded07ca08c4a29f10a0ed925
Summary:
Centralize C++ compiler flags in rn_defs.bzl.
There is really no reason for these Cxx libraries to specify their own compiler flags: nearly 100% of them are identical, and the copypasta makes it difficult to make repo-wide changes (like upgrading C++ versions, etc).
This is now causing build failures until everything is migrated properly, and there are two flags (enable_rtti and enable_exceptions) that MUST have the same value and can be configured per-module, as needed.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D31631767
fbshipit-source-id: 84f0441eb0ad09219e97d13babe0707d25f08472
Summary:
This seems like a remnant of an old refactor. This is passed in, we wrap it with a JMessageQueueThread and then never use it again.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D31506280
fbshipit-source-id: aca01439dcddbe2b44ce80342fa8664f827919c9
Summary:
Updates touch events in Fabric to be dispatched through the same pipeline as the rest of events, instead of relying on custom dispatch behavior.
Previous method of handling touches was reusing Paper behavior which required:
1. Transform event into a Paper-compatible form of WritableArray and dispatch it to `RCTEventEmitter.receiveTouches`.
2. Intercept `receiveTouches` for Fabric and redirect it to `FabricEventEmitter`
3. Perform transformations copied from Paper JS renderer in Java, transform it to the final form and dispatch this event as usual after.
The new behavior uses emitter's `receiveEvent` method directly to dispatch events. Additionally, it should decrease allocations done when transforming events during step 3 above, as `WritableNativeMap`-based operations performed many re-allocations when reading/re-creating arrays.
Changelog:
[Android][Changed] - Added an experimental touch dispatch path
Reviewed By: JoshuaGross
Differential Revision: D31280052
fbshipit-source-id: 829c2646ac6b0ebff0f0106159e76d84324ac732
Summary:
Simplifies logic of touch dispatch by retrieving surface id and other require info from the event directly.
Changelog: [Android][Internal] - Simplify logic of dispatching touches
Reviewed By: cortinico
Differential Revision: D31583314
fbshipit-source-id: c6b6e131a759c2ebe0cf4441c3aeb1a8b9f5781e
Summary:
Ref https://github.com/facebook/react-native/issues/25601#issuecomment-510856047.
From https://github.com/facebook/react-native/pull/31040.
The `hermesFlagsRelease` option only works with the release build type, but not with other build types.
This PR allows hermes flags on a per variant basis to be specified using the `hermesFlagsForVariant` lambda.
It also allows the hermes debugger cleanup to be run on a per variant basis using the `deleteDebugFilesForVariant` lambda.
## 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 hermesFlags not working with multiple variants
Pull Request resolved: https://github.com/facebook/react-native/pull/32281
Test Plan:
Set the following options in `android/app/build.gradle` and ensure warnings are hidden when running `./gradlew assembleRelease` and `./gradlew assembleLive`.
```
hermesFlagsForVariant: {
def v -> v.name.toLowerCase().contains('release') || v.name.toLowerCase().contains('live') ? ['-w'] : []
},
deleteDebugFilesForVariant: {
def v -> v.name.toLowerCase().contains('release') || v.name.toLowerCase().contains('live')
},
```
Reviewed By: cortinico
Differential Revision: D31234241
Pulled By: ShikaSD
fbshipit-source-id: 2cb3dd63adbcd023061076b5a3b262a87b470518
Summary:
Propagate event category definition to every event that is using `dispatchModernV2` (gated in production), providing opportunity to override categories of some events if needed. No events are meaningfully affected by this change, as coalesced events (e.g. scroll) are always dispatched as continuous and touch events are handled separately.
Changelog:
[Internal] Expose event category in Event class
Reviewed By: cortinico
Differential Revision: D31276249
fbshipit-source-id: f9a756b3a5cf5897e17209f3d0aed6a1c16cbd2e
Summary:
This Diff is restricting the scope of `mavenCentral` to do not
include react-native packages. This will make us sure we don't pickup older
versions of react-native.
This specifically is a problem if you're building on a nightly as the version
of RN nightly is `0.0.0.xxx` which is lower than then version on maven central.
More on this here https://github.com/facebook/react-native/pull/32326#issuecomment-933368880
Changelog:
[Internal] [Changed] - Restrict mavenCentral to exclude react-native older packages
Reviewed By: ShikaSD
Differential Revision: D31571803
fbshipit-source-id: d7ce7e82825cbebda2e4e534565d7ab15dba2624
Summary:
https://reactnative.dev/docs/view.html doesn't work, this diff replaces the url for the new link
[Changelog]
[General][Fixed] - Updated documentation link in `View`.
Reviewed By: yungsters
Differential Revision: D31519836
fbshipit-source-id: c93feee4652caf4ef8390a047599149fc547db48
Summary:
This issue is found when investigating T101563978 with IOS platform. When animation is off, the x position measurement is off after `scrollToItem` is called.
The android fix is checked in at D31492685 (https://github.com/facebook/react-native/commit/1a9e2d5d5589ce5cee92868ea5bccceb6e161eff). For IOS, the correct state data is updated only for animated cases, but not for instant scroll cases. This diff unified them.
Changelog
[IOS][Fixed] Fixed an edge case when scroll to item/index is called without animation, the offset position is not updated. This caused the measurement of the position to be wrong.
Reviewed By: sammy-SC
Differential Revision: D31564169
fbshipit-source-id: 89f47d8054afb03c2ace1d595163b160e5bb2036
Summary: Changelog: [Internal] - Change accessibilityValue.text type to allow for Stringish type
Reviewed By: yungsters
Differential Revision: D31577860
fbshipit-source-id: af12505794037a68850a16ce139359e2f8a879e4
Summary:
Added more logs to understand what's the root cause for https://fburl.com/logview/kgknonri
```java.lang.IllegalStateException: Message queue threads already initialized
at X.5y2.A0I(:64)
at com.facebook.venice.ReactInstance.<init>(:112)
at X.PrB.EgB(:33)
at X.2pN.run(:4)
at X.2pA.execute(:32)
at X.2p6.A00(:30)
at X.2p6.A08(:2)
at X.PrC.EgB(:26)
at X.Pr7.run(:4)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:919)
```
Changelog:
[Android][Changed] - Add some logs
Reviewed By: RSNara
Differential Revision: D31584264
fbshipit-source-id: 11b8bb2c6c9af2266688e3dae95e09f0160de79a
Summary:
This is a proposal to adjust the in-code documentation to clarify the semantics of the `enableHermes` variable.
This fixes https://github.com/facebook/react-native-website/issues/2813.
## 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] - Clarified in-code documentation in the template's `android/app/build.gradle`.
Pull Request resolved: https://github.com/facebook/react-native/pull/32382
Test Plan: This is just an update to documentation, no need for tests.
Reviewed By: yungsters
Differential Revision: D31550133
Pulled By: Huxpro
fbshipit-source-id: d60e5d256e1ffaf8556710b75582f1ae1c0f1fd3
Summary:
The elevation barriers that limited view reordering were applied incorrectly, disabling elevation completely for some combinations of views. This change ensures the order of barriers is correct and only disables elevation reorder between the children and not on them.
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D31541961
fbshipit-source-id: 2fa4dc6906790053bd4445c841aeda0e2b3830e5
Summary:
The test_docker_android job on Circle CI has a simple function: verify the base community RN Android image can be downloaded, and verify that we can use it to build a container with a compiled Android test app.
Since the job is not strictly running a suite of tests, it can be moved to GitHub Actions. It will run on GitHub Actions as a Check on commits to main and pull requests.
As building the test image requires the use of the base React Native Android image, we can skip downloading the base container and go straight to building the test image.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D31521978
fbshipit-source-id: ca8372a1464054e37f2da28a3ecfbc8f84db0408
Summary:
The `scrollTo` method in ScrollViews are using the `(x, y)` position they got from upperstream to scroll, and to set the state for Fabric. This diff fixes an edge case where the scroll result is not ended up to `(x, y)`. For example, if we are going to scroll to the last item in the list, the item may not scroll to the `(x, y)` position, but stay at the end position of the view.
- Change `scrollTo` method to use the actual `scrollX` and `scrollY` position after scrolling to set current state.
Changelog:
[Android][Fixed] - scrollTo API in ScrollView will check the actual scroll position before setting the scroll state
Reviewed By: JoshuaGross
Differential Revision: D31492685
fbshipit-source-id: e5513fb735ea68c5014b5c47fadffe461cad5c94
Summary: Changelog: [Internal] Configure circleCI to comment on PR after building tarball
Reviewed By: hramos
Differential Revision: D31387660
fbshipit-source-id: 28902148cf5e2ea15320333b90a6a7fa9d553c3b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32247
I don't think we need both libc++ and libstdc++.
allow-large-files
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D30950943
fbshipit-source-id: d0669815ff59c3e9ac45954a4a11930d1bc3959f
Summary:
changelog: [internal]
calling `setEnabled(true)` needs to have a matching `setEnabled(false)` in order for `eventTarget_` to be deallocated correctly.
Also, retaining `eventTarget_` longer, does not mean instanceHandle will be available later on.
Reviewed By: p-sun
Differential Revision: D31503119
fbshipit-source-id: 324e16fe0f6ad937ab2c38be9a536bdf14851172