Summary:
Previously published by [grgr-dkrk][2] as [https://github.com/facebook/react-native/issues/31296][3], fixes the following issues:
1) ImportantForAccessibility="no" does not work on Text, Button
2) ImportantForAccessibility="no-hide-descendants" does not work on Text, Button, or ImageBackground.
Note: On ImageBackground, focus is prevented on the imageBackground node itself, but focus is not prevented on its descendants.
Note: [Button component expected behavior for prop importantForAccessibility][4]
>Some components like Button seem like atomic units, but they end up rendering a hierarchy of components for example a wrapper View with a Text inside them. Allowing those descendants to become focusable, breaks the model of these being a single component to consider and forcing no-hide-descendants makes sense here.
>The other option is always to render any descendants of these elements with importantForAccessibility="no", so they can never be focusable on their own. This would have the same result, **BUT may potentially cause issues when the descendant content is supposed to automatically get moved up to the focusable ancestor to act as a label** (which is what Talkback does with unfocusable text elements by default).
Note: [importantForAccessibility="no" does not allow screenreader focus on nested Text Components with accessibilityRole="link" or inline Images][5]
fixes https://github.com/facebook/react-native/issues/30850 related https://github.com/facebook/react-native/pull/33690
## Changelog
[Android] [Fixed] - adding importantForAccessibility for Text, Button, ImageBackground
Pull Request resolved: https://github.com/facebook/react-native/pull/34245
Test Plan:
1) testing ImageBackground importantForAccessiblity ([link to test][1])
2) importantForAccessibility="no" does not allow screenreader focus on nested Text Components with accessibilityRole="link" or inline Images ([link to test][5])
3) testing ImageBackground importantForAccessiblity ([link to test][6])
4) Button with importantForAccessibility=no ([link to test][7])
[1]: https://github.com/facebook/react-native/pull/31296#issuecomment-1192341626 ""
[2]: https://github.com/grgr-dkrk "grgr-dkrk"
[3]: https://github.com/facebook/react-native/pull/31296 "https://github.com/facebook/react-native/issues/31296"
[4]: https://github.com/facebook/react-native/pull/31296#discussion_r616184584 "expected behaviour with prop importantForAccessibility in Button component"
[5]: https://github.com/facebook/react-native/issues/30850#issuecomment-1192286477 "importantForAccessibility=no does not allow screenreader focus on nested Text Components with accessibilityRole=link or inline Images"
[6]: https://github.com/facebook/react-native/pull/34245#issuecomment-1192446124 "testing ImageBackground importantForAccessiblity"
[7]: https://github.com/facebook/react-native/pull/34245#issuecomment-1192443589 "Button with importantForAccessibility=no"
Reviewed By: cipolleschi
Differential Revision: D38121992
Pulled By: dmitryrykun
fbshipit-source-id: 368b4dcb47d7940274820aa2e39ed5e2ca068821
Summary:
Hermes is enabled by default. We set `USE_HERMES` envvar to `false` to explicilty disable Hermes. The only valid way to check it would be to compare it against `false`. Everything else will produce invalid results if `USE_HERMES` is not defined. For example `$USE_HERMES != true` will turn into `'' != true`, which evaluates to `true`.
Due to this bug source maps were not generated by default.
Changelog:
[iOS][Fixed] - USE_HERMES envvar check fixed in react-native-xcode.sh. Now source maps are generated by default.
Reviewed By: cipolleschi
Differential Revision: D38571971
fbshipit-source-id: bc6b505c225c56d62ee773b401b66d821965e106
Summary:
We ran an experiment to test different implementations of TurboModules HostObjects, as the current one has various inefficiencies, such as re-creating HostFunctions on every property access. The strategy we found to be most efficient and flexible longer-term is to represent the TurboModule with a plain JavaScript object and use a HostObject as its prototype. Whenever a property is accessed through the prototype, we cache the property value on the plain object, so it can be efficiently resolved by the VM for future accesses.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38355134
fbshipit-source-id: 59253091412d0c6827ad7a4b1ac7dc0c7fe89cc2
Summary:
After https://github.com/facebook/react-native/issues/34370, Danger started failing because the `DANGER_GITHUB_API_TOKEN` was not properly set.
This PR fixes it.
## Changelog
[General] [Changed] - Set back the `DANGER_GITHUB_API_TOKEN`.
Pull Request resolved: https://github.com/facebook/react-native/pull/34375
Test Plan: Danger GitHub action is executed correctly.
Reviewed By: cortinico
Differential Revision: D38571718
Pulled By: cipolleschi
fbshipit-source-id: 51168098b4f910f6fefd2872f917e12daad1ec4c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34373
By introducing a RCTAppDelegate base class, we can simplify the migration step to supports TM
## Changelog
[iOS][Changed] - Simplified migration steps for TM
Reviewed By: cortinico
Differential Revision: D38509891
fbshipit-source-id: 716c1e668a05ecbd9c679558889564780816e491
Summary:
`toJs()` resolution trips up on converting the plain old jsi values.
In order to help it - remove the automatic inference of template types, since we already know that `T` in this case is going to be the concrete jsi type.
This allows using implicit conversions on Sync/Async Callback types, as well as AsyncPromise.
Without it - AsyncPromise/Callback trip up on trying to convert Convertor<T> to jsi type.
Changelog:
[General][Added] SyncCallback/AsyncCallback/AsyncPromise bridging types in C++ now allow wrapping JSI types.
Reviewed By: JoshuaGross
Differential Revision: D38529799
fbshipit-source-id: 860de2d771899f331bf1a4ff0dade4eccc875618
Summary:
Changelog: [RNTester][Internal] - Add a pointer event attributes test variant for no-hover pointers
This adds a slightly different version of the existing PointerEventAttributesHoverablePointers test but for pointers that cannot hover (such as touches)
Reviewed By: lunaleaps
Differential Revision: D38401888
fbshipit-source-id: 4ed782cc2157dcaa8f6c294ae3589843d020bc92
Summary:
Fixed Flipper not recognizing app when using custom Xcode configuration names.
This fixes the problem that renaming the "Debug" Xcode configuration causes Flipper to not work. Despite using the recommended `:configurations` parameters and instructing Cocoapods that it was a debug build (see https://github.com/facebook/react-native/issues/34332), it still wouldn't recognize the app due to missing C preprocessor flags, specifically it was missing `-DFB_SONARKIT_ENABLED=1`.
## 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] - Flipper now supports custom Xcode build configuration names
Pull Request resolved: https://github.com/facebook/react-native/pull/34333
Test Plan:
I applied the PR change to 0.68.2 (which work similarly but code was refactored since then). I then used `patch-package` to test the change and the fix worked on 2 separate projects.
Patch-package change equivalent:
```diff
diff --git a/node_modules/react-native/scripts/react_native_pods.rb b/node_modules/react-native/scripts/react_native_pods.rb
index f2ceeda..2ea57d6 100644
--- a/node_modules/react-native/scripts/react_native_pods.rb
+++ b/node_modules/react-native/scripts/react_native_pods.rb
@@ -180,7 +180,7 @@ def flipper_post_install(installer)
# Enable flipper for React-Core Debug configuration
if target.name == 'React-Core'
target.build_configurations.each do |config|
- if config.name == 'Debug'
+ if config.debug?
config.build_settings['OTHER_CFLAGS'] = "$(inherited) -DFB_SONARKIT_ENABLED=1"
end
end
```
**Screen shot of Xcode after the patch has been applied, for RN v0.68.2:**
Reviewed By: dmitryrykun
Differential Revision: D38373812
Pulled By: cipolleschi
fbshipit-source-id: d2949927084160bf0c6f8af37a7966dd22fea9a6
Summary:
This is a nit. Did some cleanups on our Danger setup.
The most substantial work is:
- Moved over danger to run on `pull_request_target`. This allow us to re-use the Github Action access token without having to provide one.
- Fixed an issue with the `Pick Request` label which was not applied correctly.
- Removed the danger_id as we were not passing it correctly.
## Changelog
[Internal] - Let danger run on `pull_request_target`
Pull Request resolved: https://github.com/facebook/react-native/pull/34370
Test Plan: Tested locally with `yarn danger pr https://github.com/facebook/react-native/pull/34197`
Reviewed By: cipolleschi
Differential Revision: D38533144
Pulled By: cortinico
fbshipit-source-id: 178ce411eb956870563c4d51719ed4dae1f1536d
Summary:
This is a nit, but at least will help us reduce requests to rebase for PRs which maybe have a broken CI due to a stale base commit.
I've limited the scope to members and owners. A `/rebase` will trigger a rebase authored by Github Action bot.
We can play a bit around with it, and remove it if it doesn't really work well for us.
## Changelog
[Internal] - Setup Automatic Rebase given a /rebase comment
Pull Request resolved: https://github.com/facebook/react-native/pull/34369
Test Plan: Nothing to test here.
Reviewed By: cipolleschi
Differential Revision: D38509480
Pulled By: cortinico
fbshipit-source-id: 1df3927638b162d4a787c81372a835d583159498
Summary:
The Android version of PlatformConstants exposes the device's [UI Mode]( https://developer.android.com/guide/topics/resources/providing-resources#UiModeQualifier). It is missing the case for 'vrheadset', added in Android API 26. We should return the expected result when this is queried.
Changelog:
[Android][Added] - Expose UI_MODE_TYPE_VR_HEADSET in PlatformConstants
Reviewed By: rshest
Differential Revision: D38495875
fbshipit-source-id: fd904bd11213448415b7d75145d9ba6311ed407b
Summary:
This adds a simple debug UI to verify the keyboard events "keyboardDidShow" and "keyboardWillShow"
Changelog:
[Internal][Added] - Add "KeyboardExample" to RNTester
Reviewed By: cortinico
Differential Revision: D38500869
fbshipit-source-id: 99913a05849a7dd27dfdee2d622058b9c2604a7f
Summary:
- Current version of clang-format does not work on Apple M1/M2/... chipsets https://github.com/angular/clang-format/issues/78
Changelog:
[General][Fixed] - Make clang-format work in M1 (Apple Silicon)
Reviewed By: cortinico
Differential Revision: D38505844
fbshipit-source-id: c94a71dea82217e725a3609d72692a15a8fe22e0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34368
When a user runs `RCT_NEW_ARCH_ENABLED=1 pod install` to install the dependencies for the New Architecture, Cocoapods prints a warning because of React Native is still set up with a legacy configuration.
This diff silences these warnings because they can confuse the final user.
**Note:** We need to keep this legacy configuration to support both the legacy and the New Architecture.
## Changelog
[iOS][Changed] - Silence warning due to react-native internal details.
Reviewed By: cortinico
Differential Revision: D38503405
fbshipit-source-id: b89857aa88435b1c64da52875606003239ff2e05
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.68.3
Pull Request resolved: https://github.com/facebook/react-native/pull/34366
Test Plan: N/A
Reviewed By: christophpurrer
Differential Revision: D38500055
Pulled By: dmitryrykun
fbshipit-source-id: 0ef857ef1822522372a5743e9471b791d11e0181
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34354
This change simplifies the setup for New Architecture for users on Android.
Instead of using the Android.mk file, users can now use a CMake file which
encapsulate a lot of the complexities and reduces the maintainance cost.
Android.mk support is kept for backward compatibility.
Changelog:
[Android] [Changed] - Update the new app template to use CMake instead of Android.mk
Reviewed By: cipolleschi
Differential Revision: D38460536
fbshipit-source-id: 9d4c3b15be751921d34023b24c174044537e6f02
Summary:
Fixes https://github.com/facebook/react-native/issues/34229
Basically, the react android conflicts with the kotlin version that's defined in the top level build.gradle. To resolve it, the approach was to get the `kotlinVersion` defined in top level build.gradle and use it. If it's not defined, we use the default(1.6.10 as of now).
The reason behind not using the DSL is that it doesn't allow us to use the variables due to it's constrained syntax.
See [here](https://docs.gradle.org/current/userguide/plugins.html#sec:constrained_syntax)
So the idea was to use the build script to resolve the kotlin plugin and it works 👍 .
Kindly asking for review cortinico :)
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Changed] - refactored usage of kotlin plugin
Pull Request resolved: https://github.com/facebook/react-native/pull/34255
Test Plan: Ran the node ./scripts/run-ci-e2e-tests.js --js --android --ios to verify it doesn't introduce any unexpected issues.
Reviewed By: dmitryrykun
Differential Revision: D38468567
Pulled By: cortinico
fbshipit-source-id: f9ab635fcf033f1d337ed90793ba1667957b8e01
Summary:
## Summary
Fixes https://github.com/facebook/react-native/issues/32497
Fixes https://github.com/facebook/react-native/issues/34212
The assigned HBC_SOURCEMAP_FILE path is incorrect as it does not reference the hermes bundle source map file
See: https://github.com/facebook/react-native/issues/32497#issuecomment-1171379674
## Changelog
[General] [Fixed] - using SOURCEMAP_FILE during xcode build phase with Hermes enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/34111
Test Plan:
1. In a blank react-native project
1. Enable Hermes
1. Go to xCode -> Project -> Build Phases -> Bundle React Native code and images
3. Add `export SOURCEMAP_FILE="$(pwd)/../ios.jsbundle.map"` before `react-native-xcode.sh`
e.g.
```sh
export NODE_BINARY=node
export SOURCEMAP_FILE="$(pwd)/../ios.jsbundle.map"
../node_modules/react-native/scripts/react-native-xcode.sh
```
4. Make a release build `npx react-native run-ios --configuration Release` or `CMD + I` in xCode
5. Verify the build is successful
6. Verify the `.map` file is outputted at the specified path (`ios.jsbundle.map` in project root for the example above)
Reviewed By: cipolleschi
Differential Revision: D38460586
Pulled By: dmitryrykun
fbshipit-source-id: 54c1594b37fa2253896ce9739c1a9a712deecd0f
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.68.3
Pull Request resolved: https://github.com/facebook/react-native/pull/34367
Test Plan: N/A
Reviewed By: dmitryrykun
Differential Revision: D38500554
Pulled By: huntie
fbshipit-source-id: f2fd48b3a0a608d488c1edb85ea8c424029bd9c9
Summary:
changelog: [internal]
`_forceDispatchNextScrollEvent` is already called inside `- (void)scrollToOffset:(CGPoint)offset animated:(BOOL)animated`. No need to call it before.
Reviewed By: cipolleschi
Differential Revision: D38499299
fbshipit-source-id: cf6635e02bf582346869f77194cf06be7939351f
Summary:
I'm extending `test_android_template` to use a CI Matrix. This will allow us to make sure that we test a new app template against Debug/Release and against New/Old Arch.
This will make sure we catch a lot of bugs early on 👍
## Changelog
[Internal] - Setup a build matrix for test_android_template
Pull Request resolved: https://github.com/facebook/react-native/pull/34355
Test Plan: Will wait for a green CI
Reviewed By: cipolleschi
Differential Revision: D38499773
Pulled By: cortinico
fbshipit-source-id: 5a24c21d111fb4ae0f4600d86b786021f6ad2abe
Summary:
https://github.com/facebook/react-native/pull/34310 introduced Gradle 7.5.0, but I noticed that the Gradle team actually missed to remove the `Incubating` annotation for the Java 18 support. The latest 7.5.1 is fixing that. More details can be found here: https://github.com/gradle/gradle/releases/tag/v7.5.1
## Changelog
[Android] [Changed] - Bump Gradle to 7.5.1
Pull Request resolved: https://github.com/facebook/react-native/pull/34359
Test Plan: Successfully build on a local project. I can share the actual branch if needed.
Reviewed By: cipolleschi
Differential Revision: D38497804
Pulled By: cortinico
fbshipit-source-id: 792b83707d5b6aaf7ef29531f82a1bc9224b3204
Summary:
We have a older version of caniuselite in the yarn.lock.
This is causing several warnings on console which I'm resolving with:
`npx browserslist@latest --update-db`
Changelog:
[Internal] [Changed] - Update caniuse-lite with `npx browserslist@latest --update-db`
Reviewed By: cipolleschi
Differential Revision: D38459471
fbshipit-source-id: 4476e2f925f693e4aff457b80906faa51247772c
Summary:
Use of `__attribute__` and `__unused` is compiler specific. Opt for standard `[[maybe_unused]]` instead.
## Changelog
[General] [Fixed] - Remove compiler-specific syntax.
Pull Request resolved: https://github.com/facebook/react-native/pull/34357
Test Plan: Built on react-native-windows.
Reviewed By: cipolleschi
Differential Revision: D38498481
Pulled By: javache
fbshipit-source-id: af43206788f54dda3b747b6417e20096c7d520e8
Summary:
After. D38153924 (https://github.com/facebook/react-native/commit/e24ce708abffee8ec4521ba8162ea8964eb4429f), layout mount items have 7 int arguments but the logger only pulls out and displays 6, which leads to the following exception: "Caught exception trying to print java.lang.IllegalArgumentException: Invalid type argument to IntBufferBatchMountItem"
Changelog: [Internal]
Created from CodeHub with https://fburl.com/edit-in-codehub
Differential Revision: D38472664
fbshipit-source-id: 1583a5514c2ab662eaf5c4ce4bf33c958cb05282
Summary:
This diff is part of an overall stack, meant to fix incorrect usage of `setState()` in `VirtualizedList`, which triggers new invariant checks added in `VirtualizedList_EXPERIMENTAL`. See the stack summary below for more information on the broader change.
## Diff Summary
This adds a `StateSafePureComponent`, which will override `setState`, along with `this.props` and `this.state`, in order to add runtime enforcement that `this.props` and `this.state` are not accessed during a state update where we should be relying on parameter instead. This should be landed after the fixes for unsafe `this.props`/`this.state` usage.
## Stack Summary
`VirtualizedList`'s component state is a set of cells to render. This state is set via the `setState()` class component API. The main "tick" function `VirtualizedList._updateCellsToRender()` calculates this new state using a combination of the current component state, and instance-local state like maps, measurement caches, etc.
From: https://reactjs.org/docs/state-and-lifecycle.html#state-updates-may-be-asynchronous
---
> React may batch multiple setState() calls into a single update for performance. Because this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state. For example, this code may fail to update the counter:
```
// Wrong
this.setState({
counter: this.state.counter + this.props.increment,
});
```
> To fix it, use a second form of setState() that accepts a function rather than an object. That function will receive the previous state as the first argument, and the props at the time the update is applied as the second argument:
```
// Correct
this.setState((state, props) => ({
counter: state.counter + props.increment
}));
```
---
`_updateCellsToRender()` transitively calls many functions which will read directly from `this.props` or `this.state` instead of the value passed by the state updater. This intermittently fires invariant violations, when there is a mismatch.
This diff migrates all usages of `props` and `state` during state update to the values provied in `setState()`. To prevent future mismatch, and to provide better clarity on when it is safe to use `this.props`, `this.state`, I overrode `setState` to fire an invariant violation if it is accessed when it is unsafe to:
{F756963772}
Changelog:
[Internal][Changed] - Enable setState() hooks
Reviewed By: rshest
Differential Revision: D38294338
fbshipit-source-id: d04ff39f68df90adc9f4680887d308d997903675
Summary:
Current creation of the errorProcessor lambda does a full copy of folly::dynamic object, which for large objects can cause 1000's of memory allocations, and thus increasing app's memory footprint and speed.
Changelog:
[General][Fixed] - Avoid full copy of large folly::dynamic objects in JSIExecutor#defaultTimeoutInvoker
Reviewed By: sammy-SC
Differential Revision: D38368392
fbshipit-source-id: 88579a7069891828cf6dae130c4964db6b494565
Summary:
Make the interface to enable/disable debugging symmetrical; both enabling and disabling are done by passing in a reference to the RuntimeAdapter.
Doing so requires moving ownership of the RuntimeAdapter, so each caller (java2js, arfx engine, React Native, react-native-github, and venice) has been updated to own their adapter.
Additionally, the two implementations of the Inspector connection (react-native-github and arfx engine) have been updated to expect and use the new argument.
`Connection::getRuntime` could be removed and replaced with calls to `Connection::getRuntimeAdapter::getRuntime`. I've left that choice to a followup diff, as this one is getting messy enough as it is.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D38242964
fbshipit-source-id: f2a3354f9d424b203a76d2c15122a6515a0926f2
Summary:
Changelog: [Internal]
Debugging is enabled via `enableDebugging` with a `RuntimeAdapter` that provides a `HermesRuntime`. This same `HermesRuntime` should be passed to `disableDebugging`, not a decorated version. Change the argument type of `disableDebugging` to steer callers in the right direction.
Reviewed By: jpporto
Differential Revision: D38051662
fbshipit-source-id: ae436a4af12fa01143bfbcdb97e65e4fca90154d
Summary:
Changelog: [Internal]
Provide a `HermesRuntime` from the `RuntimeAdapter` (instead of a decorated Hermes runtime).
As the Inspector can now directly access the `HermesRuntime` (which exposes access to the debugger), `RuntimeAdapter::getDebugger` is no longer necessary; remove it.
Reviewed By: jpporto
Differential Revision: D38050821
fbshipit-source-id: fa83165a9348bdff0dce1b04ec1afb81d2b1c3e2
Summary:
Changelog: [Internal]
Make runtime use more consistent, always using the same undecorated runtime. This prevents the previous mixing of decorated and undecorated runtimes.
Reviewed By: jpporto
Differential Revision: D38035166
fbshipit-source-id: 81929e42ccc4de6d5c5c09ee7ee31f055af82735
Summary: Changelog: [Internal] Add logic for `isPrimary` for PointerEvent object and set other properties to their default value
Reviewed By: javache
Differential Revision: D38363163
fbshipit-source-id: 5ec9de69fb5b34295f1da6daedd5c67e3bd3727e
Summary:
Changelog: [Internal] - Instead of using toolType which is a property per pointer in the MotionEvent, let's use [getSource](https://developer.android.com/reference/android/view/MotionEvent#getSource()) which is the source for the entire event (all pointers).
This aligns with what we've seen on Android when we have a mouse and touch input, there is only one active source input device.
And removes the need for checking a flag we set here: D36958947
Reviewed By: NickGerleman
Differential Revision: D37702090
fbshipit-source-id: ba2a4f0c28e1aff2b8b04314fe6f737b66ed0be3
Summary:
Expo Go was using `nativeInjectHMRUpdate` for [snack](https://snack.expo.io/) to provide stack traces to OTA errors. `nativeInjectHMRUpdate` was replaced with `globalEvalWithSourceUrl` [here](https://github.com/facebook/react-native/commit/71c84cf6bebba701bb23b135e079aa68c05f4441). The issue with `globalEvalWithSourceUrl` is that it is stripped in RELEASE builds, and Expo Go is installed via the App Store, making it a release build.
I propose we keep the method, `eval` is still exposed in production so there's no increase in security risk, simply provides a better DX for multipurpose development clients.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Added] - Expose `globalEvalWithSourceUrl` in production builds.
[iOS] [Added] - Expose `globalEvalWithSourceUrl` in production builds.
Pull Request resolved: https://github.com/facebook/react-native/pull/34319
Test Plan: - Function should be available as `global.globalEvalWithSourceUrl` in a production build.
Reviewed By: christophpurrer
Differential Revision: D38312111
Pulled By: motiz88
fbshipit-source-id: adcd83ad1103c8fd4c6d5d7aec765f27881e0432
Summary:
Resolves https://github.com/facebook/react-native/issues/34116.
In a nutshell, the problem was a missing `.exe` extension on the `hermesc` binary path when running on Windows OS. The missing extension causes the method `.exists()` of the File instance to always return false, so none of the conditions ever met and an error was thrown whenever a release build with Hermes enabled was run on Windows. More details can be found in the comments on the above issues.
## 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 error of release builds with Hermes enabled for Windows users
Pull Request resolved: https://github.com/facebook/react-native/pull/34151
Test Plan:
### Reproduce
Changes on Gradle scrips are better tested on an actual application. To reproduce the issue you can:
1. Create or reuse a React Native application with version `v0.69.1` on a Windows machine
2. Enable Hermes on Android following the steps on the [documentation](https://reactnative.dev/docs/hermes#enabling-hermes)
3. Clean the build folder: `cd android && ./gradlew clean`
4. Bundle the JS and assets for a release version: `./gradlew bundleReleaseJsAndAssets`
5. The build fails with the following error:
```shell
Execution failed for task ':app:bundleReleaseJsAndAssets'.
> java.lang.Exception: Couldn't determine Hermesc location. Please set `project.ext.react.hermesCommand` to the path of the hermesc binary file. node_modules/react-native/sdks/hermesc/%OS-BIN%/hermesc
```
### Test the changes
Follow the same steps above using the fix on this PR and the error should disappear 🙂
Reviewed By: NickGerleman
Differential Revision: D37755468
Pulled By: cortinico
fbshipit-source-id: 2ad0ced583555b907259df116f64a45da6d153f3
Summary:
This Pull Request aims at removing the making of reactnativeutilsjni as it is built from the same sources as reactnativejni. It also replaces references to reactnativeutilsjni with reactnativejni.
This should get rid of `reactnativeutilsjni.so` while reusing `reactnativejni.so` in it's place. This should give us some size improvements in the finally built apk.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Changed] - Replaced reactnativeutilsjni with reactnativejni in the build process to reduce size
Pull Request resolved: https://github.com/facebook/react-native/pull/34339
Test Plan:
1. Ran the CMakelist.txt file using CMake and I could see that reactnativeutilsjni.dir is no longer generated with my changes.
2. Built the aar from this branch in Android Studio and build happened successfully.
I am not sure if we could run any more tests. Please let me know in case anymore testing is required and I can do accordingly
Reviewed By: cortinico
Differential Revision: D38400481
Pulled By: genkikondo
fbshipit-source-id: 592736e56441328389ae89135667c336ff8018e6
Alex Hunt
fabriziobertoglio1987
Dmitry Rykun
Pieter De Baets
Riccardo Cipolleschi
Sam Zhou
Nikita Lutsenko
Vincent Riemer
Christoph Purrer
Seph Soliman
Nicola Corti
Nick Gerleman
Samuel Susla
Lorenzo Sciandra
Muhammad Hur Ali
Peter Velkov
Alexander Eggers
Chiara Mooney
Andreas Eulitz
Genki Kondo
Joshua Gross
Dark Knight
Matt Blagden
Luna Wei
evanbacon
JoseLion
Sparsha Saha
Marshall Roch
Pieter Vanderwerff
