Summary:
The current implementation of **getDefaultJSExecutorFactory** relies solely on try catch to load the correct .so file for jsc or hermes based on the project configuration.
Relying solely on try catch block and loading jsc even when project is using hermes can lead to launch time crashes especially in monorepo architectures and hybrid apps using both native android and react native.
So we can make use of an additional **ReactInstanceManager :: setJsEngineAsHermes** method that accepts a Boolean argument from the host app while building ReactInstanceManager which can tell which library to load at startup in **ReactInstanceManagerBuilder** which will now have an enhanced getDefaultJSExecutorFactory method that will combine the old logic with the new one to load the dso files.
The code snippet in **ReactInstanceManager** for adding a new setter method:
```
/**
* Sets the jsEngine as JSC or HERMES as per the setJsEngineAsHermes call
* Uses the enum {link JSInterpreter}
* param jsEngine
*/
private void setJSEngine(JSInterpreter jsEngine){
this.jsEngine = jsEngine;
}
/**
* Utility setter to set the required JSEngine as HERMES or JSC
* Defaults to OLD_LOGIC if not called by the host app
* param hermesEnabled
* hermesEnabled = true sets the JS Engine as HERMES and JSC otherwise
*/
public ReactInstanceManagerBuilder setJsEngineAsHermes(boolean hermesEnabled){
if(hermesEnabled){
setJSEngine(JSInterpreter.HERMES);
}
else{
setJSEngine(JSInterpreter.JSC);
}
return this;
}
```
The code snippet for the new logic in **ReactInstanceManagerBuilder**:
1) Setting up the new logic:
Adding a new enum class :
```
public enum JSInterpreter {
OLD_LOGIC,
JSC,
HERMES
}
```
A setter getting boolean value telling whether to use hermes or not and calling a private setter to update the enum variable.
```
/**
* Sets the jsEngine as JSC or HERMES as per the setJsEngineAsHermes call
* Uses the enum {link JSInterpreter}
* param jsEngine
*/
private void setJSEngine(JSInterpreter jsEngine){
this.jsEngine = jsEngine;
}
/**
* Utility setter to set the required JSEngine as HERMES or JSC
* Defaults to OLD_LOGIC if not called by the host app
* param hermesEnabled
* hermesEnabled = true sets the JS Engine as HERMES and JSC otherwise
*/
public ReactInstanceManagerBuilder setJsEngineAsHermes(boolean hermesEnabled){
if(hermesEnabled){
setJSEngine(JSInterpreter.HERMES);
}
else{
setJSEngine(JSInterpreter.JSC);
}
return this;
}
```
2) Modifying the getDefaultJSExecutorFactory method to incorporate the new logic with the old one:
```
private JavaScriptExecutorFactory getDefaultJSExecutorFactory(
String appName, String deviceName, Context applicationContext) {
// Relying solely on try catch block and loading jsc even when
// project is using hermes can lead to launch-time crashes especially in
// monorepo architectures and hybrid apps using both native android
// and react native.
// So we can use the value of enableHermes received by the constructor
// to decide which library to load at launch
// if nothing is specified, use old loading method
// else load the required engine
if (jsEngine == JSInterpreter.OLD_LOGIC) {
try {
// If JSC is included, use it as normal
initializeSoLoaderIfNecessary(applicationContext);
JSCExecutor.loadLibrary();
return new JSCExecutorFactory(appName, deviceName);
} catch (UnsatisfiedLinkError jscE) {
if (jscE.getMessage().contains("__cxa_bad_typeid")) {
throw jscE;
}
HermesExecutor.loadLibrary();
return new HermesExecutorFactory();
}
} else if (jsEngine == JSInterpreter.HERMES) {
HermesExecutor.loadLibrary();
return new HermesExecutorFactory();
} else {
JSCExecutor.loadLibrary();
return new JSCExecutorFactory(appName, deviceName);
}
}
```
### **Suggested changes in any Android App's MainApplication that extends ReactApplication to take advantage of this fix**
```
builder = ReactInstanceManager.builder()
.setApplication(this)
.setJsEngineAsHermes(BuildConfig.HERMES_ENABLED)
.setBundleAssetName("index.android.bundle")
.setJSMainModulePath("index")
```
where HERMES_ENABLED is a buildConfigField based on the enableHermes flag in build.gradle:
`def enableHermes = project.ext.react.get("enableHermes", true)
`
and then
```
defaultConfig{
if(enableHermes) {
buildConfigField("boolean", "HERMES_ENABLED", "true")
}
else{
buildConfigField("boolean", "HERMES_ENABLED", "false")
}
}
```
Our app was facing a similar issue as listed in this list: **https://github.com/facebook/react-native/issues?q=is%3Aissue+is%3Aopen+DSO**. Which was react-native trying to load jsc even when our project used hermes when a debug build was deployed on a device using android studio play button.
This change can possibly solve many of the issues listed in the list as it solved ours.
## Changelog
[GENERAL] [ADDED] - An enum JSInterpreter in com.facebook.react package:
```
/**
* An enum that specifies the JS Engine to be used in the app
* Old Logic uses the legacy code
* JSC/HERMES loads the respective engine using the revamped logic
*/
public enum JSInterpreter {
OLD_LOGIC,
JSC,
HERMES
}
```
[GENERAL] [ADDED] - An enum variable storing the default value of Js Engine loading mechanism in ReactInstanceManagerBuilder:
```
private JSInterpreter jsEngine = JSInterpreter.OLD_LOGIC;
```
[GENERAL] [ADDED] - A new setter method and a helper method to set the js engine in ReactInstanceManagerBuilder:
```
/**
* Sets the jsEngine as JSC or HERMES as per the setJsEngineAsHermes call
* Uses the enum {link JSInterpreter}
* param jsEngine
*/
private void setJSEngine(JSInterpreter jsEngine){
this.jsEngine = jsEngine;
}
/**
* Utility setter to set the required JSEngine as HERMES or JSC
* Defaults to OLD_LOGIC if not called by the host app
* param hermesEnabled
* hermesEnabled = true sets the JS Engine as HERMES and JSC otherwise
*/
public ReactInstanceManagerBuilder setJsEngineAsHermes(boolean hermesEnabled){
if(hermesEnabled){
setJSEngine(JSInterpreter.HERMES);
}
else{
setJSEngine(JSInterpreter.JSC);
}
return this;
}
```
[GENERAL] [ADDED] - Modified **getDefaultJSExecutorFactory** method
```
private JavaScriptExecutorFactory getDefaultJSExecutorFactory(
String appName, String deviceName, Context applicationContext) {
// Relying solely on try catch block and loading jsc even when
// project is using hermes can lead to launch-time crashes especially in
// monorepo architectures and hybrid apps using both native android
// and react native.
// So we can use the value of enableHermes received by the constructor
// to decide which library to load at launch
// if nothing is specified, use old loading method
// else load the required engine
if (jsEngine == JSInterpreter.OLD_LOGIC) {
try {
// If JSC is included, use it as normal
initializeSoLoaderIfNecessary(applicationContext);
JSCExecutor.loadLibrary();
return new JSCExecutorFactory(appName, deviceName);
} catch (UnsatisfiedLinkError jscE) {
if (jscE.getMessage().contains("__cxa_bad_typeid")) {
throw jscE;
}
HermesExecutor.loadLibrary();
return new HermesExecutorFactory();
}
} else if (jsEngine == JSInterpreter.HERMES) {
HermesExecutor.loadLibrary();
return new HermesExecutorFactory();
} else {
JSCExecutor.loadLibrary();
return new JSCExecutorFactory(appName, deviceName);
}
}
```
Pull Request resolved: https://github.com/facebook/react-native/pull/33952
Test Plan:
The testing for this change might be tricky but can be done by following the reproduction steps in the issues related to DSO loading here: https://github.com/facebook/react-native/issues?q=is%3Aissue+is%3Aopen+DSO
Generally, the app will not crash anymore on deploying debug using android studio if we are removing libjsc and its related libraries in **packagingOptions** in build.gradle and using hermes in the project.
It can be like:
```
packagingOptions {
if (enableHermes) {
exclude "**/libjsc*.so"
}
}
```
Reviewed By: lunaleaps
Differential Revision: D37191981
Pulled By: cortinico
fbshipit-source-id: c528ead126939f1d788af7523f3798ed2a14f36e
Summary:
In https://github.com/facebook/react-native/pull/32695, the `Performance.now()` implementation changed to use unix epoch timestamps instead of a monotonic clock.
This is problematic, because it means that performance measurements get skewed if the device clock changes between two measurements.
With this change, the clock is now monotonic (and the implementation stays consistent between platforms).
More details and repro steps can be found in [this issue](https://github.com/facebook/react-native/issues/33977)
Closes https://github.com/facebook/react-native/issues/33977
## Changelog
[General] [Fixed] - Use monotonic clock for performance.now()
Pull Request resolved: https://github.com/facebook/react-native/pull/33983
Test Plan:
Run on iOS and Android:
```
const now = global.performance.now()
console.log(`${Platform.OS}: ${now}`)
```
Reviewed By: JoshuaGross, cipolleschi
Differential Revision: D37066999
Pulled By: dmitryrykun
fbshipit-source-id: 298547bf39faea1b025c17ff2d2e1a03f929865b
Summary:
As per commit: https://github.com/facebook/react-native/commit/4f3b17412018a10f9293247c802598d2b94a844b which states that "React Native requires that the RootView id be managed entirely by React Native, and will crash in addRootView/startSurface if the native View id isn't set to NO_ID."
This behaviour can not be guaranteed in **hybrid** apps that have a native android layer over which ReactRootViews are added and the native views need to have ids on them in order to work. **The control of views can jump back and forth between native android and react-native (fabric). As the ReactRootView is added to ViewGroups (or layouts) in Android Fragments and Activities, they contain ids on their views which might get passed down to the reactRootView by features like DataBinding**
Hence this can cause unnecessary crashes at runtime for hybrid apps even when they are not changing the id of the reactRootView object they are adding to their ViewGroups.
Our app is a hybrid app that uses both native android and react-native on different screens and on one such screen that has a Fragment adding a ReactRootView to its FrameLayout to render native android views to render in ReactNative, this crash occurs on pressing the back button as well as on unlocking the screen while staying on the same screen.
The app was running fine on more than a 100 million devices on React Native 0.63.4 but after updating to 0.67.2, that features this commit, it crashes on the very first device it was tested on.
Refer to the issue: https://github.com/facebook/react-native/issues/33121 for more information on the crash
The fragment in which this issues arises is like this:
```binding.frameLayout.addView(getReactRootView())```
where getReactRootView() is like this:
```
private var mReactRootView: ReactRootView? = null
private var mReactInstanceManager: ReactInstanceManager? = null
mReactRootView = ReactRootView(context)
if (activity != null) {
val application = activity?.application
if (application is MainApplication) {
mReactInstanceManager = application.reactInstanceManager
}
}
fun getReactRootView():View?{
return mReactRootView
}
```
So converting this to a soft exception such that pure react-native devs can still see the error while hybrid apps continue to run without crashes.
### Snippet of the change:
```
if (getId() != View.NO_ID) {
ReactSoftExceptionLogger.logSoftException(
TAG,
new IllegalViewOperationException(
"Trying to attach a ReactRootView with an explicit id already set to ["
+ getId()
+ "]. React Native uses the id field to track react tags and will overwrite this"
+ " field. If that is fine, explicitly overwrite the id field to View.NO_ID."));
}
```
## Changelog
[GENERAL] [ADDED] - A ReactSoftException log instead of a direct exception being thrown:
```
if (getId() != View.NO_ID) {
ReactSoftExceptionLogger.logSoftException(
TAG,
new IllegalViewOperationException(
"Trying to attach a ReactRootView with an explicit id already set to ["
+ getId()
+ "]. React Native uses the id field to track react tags and will overwrite this"
+ " field. If that is fine, explicitly overwrite the id field to View.NO_ID."));
}
```
[GENERAL] [REMOVED]- Directly throwing an exception even when the code is not responsible for this issue:
```
if (getId() != View.NO_ID) {
throw new IllegalViewOperationException(
"Trying to attach a ReactRootView with an explicit id already set to ["
+ getId()
+ "]. React Native uses the id field to track react tags and will overwrite this"
+ " field. If that is fine, explicitly overwrite the id field to View.NO_ID.");
}
```
Pull Request resolved: https://github.com/facebook/react-native/pull/33133
Test Plan:
This crash is hard to reproduce but when it occurs, this is the only way to fix it.
If any app used to crash with this exact error, it will no longer crash but show an error log in Logcat for developers to be informed about the issue.
Reviewed By: ShikaSD
Differential Revision: D34304212
Pulled By: cortinico
fbshipit-source-id: f0eaeef2e905a6e0587df088b43cc49cabda397a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33611
Bumping the NDK to 23 to prevent build failures due to the NDK
using longer paths.
Changelog:
[Android] [Fixed] - Use NDK 23 only for Windows users.
Reviewed By: motiz88
Differential Revision: D35547459
fbshipit-source-id: 4e44c0b5fd8d1c559b04fb43eb4eeadc13943394
Summary:
This adds an unnecessary dependency between two NPM package which can be avoided. See https://github.com/reactwg/react-native-releases/discussions/17#discussioncomment-2452813
for context.
Changelog:
[Internal] [Changed] - react-native-gradle-plugin should not depend on react-native-codegen NPM package
Reviewed By: dmitryrykun
Differential Revision: D35279729
fbshipit-source-id: f18f79809f115f28203ac0a843fafead63528904
Summary:
It is not necessary to call node via yarn. Instead with this commit node is called directly (windows aware). This enables builds on systems that don't have yarn installed.
Fixes https://github.com/facebook/react-native/issues/33525
## Changelog
[Android] [Fixed] - Don't require yarn for codegen tasks
Pull Request resolved: https://github.com/facebook/react-native/pull/33530
Test Plan:
1. react-native init test
2. cd test
3. enable newArchEnabled=true (gradle.properties)
4. enable enableHermes: true (build.gradle)
5. react-native run-android (when the yarn is not installed on the system)
(I have not tested or verified if this works on windows build machines)
Reviewed By: sshic
Differential Revision: D35279376
Pulled By: cortinico
fbshipit-source-id: 430e4a7bcdec7d5377efac747f6b935d634451cc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33581
We currently have some code on the RN Gradle Plugin that we need to ship.
There are both bugfixes needed for RN 0.68.1 and for the current nightly
(therefore needed for RN 0.69).
I've verified that this works on a fresh RN 0.68.0 install with `npm pack`
and triggering a build on a fresh setup from app template, with newArchEnabled set to true.
Changelog:
[Android] [Changed] - Bump React Native Gradle plugin to 0.0.6
Reviewed By: rubennorte
Differential Revision: D35439444
fbshipit-source-id: 662b2211c44b261e3e3c9cddc946107cfb495c79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33588
Currently users on M1 machine can't use the New Architecture correctly as they will get build failures when building the native code.
This Diff fixes it by automatically recognizing the host architecture and switching to NDK 24 if user is runnign on `aarch64`
Changelog:
[Android] [Fixed] - Improve support for Android users on M1 machine
Reviewed By: mdvacca
Differential Revision: D35468252
fbshipit-source-id: b73f5262b9408f04f3ae4fd26458a4d17c1ec29a
Summary:
As users can toggle `enableSeparateBuildPerCPUArchitecture` to create a split APK, once that is off, the `-PreactNativeArchitecture` is not correctly considered when building the local module.
This will make sure that, if users have `enableSeparateBuildPerCPUArchitecture` set to `false`, their
app is building the local `app_modules` only for the requested architectures.
Practically, users invoking with `--active-arch-only` might experience a build failure if they have a fully clean environment (would be forced to do a full build before using `--active-arch-only`). This addresses this scenario.
Changelog:
[Android] [Fixed] - Template: Specify abiFilters if enableSeparateBuildPerCPUArchitecture is not set.
Reviewed By: ShikaSD
Differential Revision: D35250700
fbshipit-source-id: 4e555888636cf182495fab2b4a562d93a70b9e66
Summary:
This PR fixes RTTI (run-time type information) for ShadowNodeWrapper and ShadowNodeListWrapper classes, i.e., calls to dynamic_cast and dynamic_pointer_cast that are called via JSI's getHostObject calls.
The fix is simply to add a so-called "key function" in a form of virtual destructor. Key functions needs to be a virtual non-pure and non-inlined functions that points the compiler as to which library contains the vtable/type information for a given class (see https://itanium-cxx-abi.github.io/cxx-abi/abi.html#vague-vtable and https://developer.android.com/ndk/guides/common-problems#rttiexceptions_not_working_across_library_boundaries)
Without the "key function", calls to dynamic_cast for ShadowNodeWrapper instances won't work across library boundaries because the class will have separate definitions in each separate library, therefore objects created in one of those libraries won't be recognized as the same type by the other library. This has been a problem in reanimated and gesture-handler libraries where we call `object.getHostObject<ShadowNodeWrapper>(rt)` (this is a method from JSI) in order to access ShadowNode instance from a handle we have in JS. I think, this issue is going to be relevant to more libraries that cope with view instances. In this scenario, we have a separate library, say "libreanimated.so" that calls to `getHostObject` which is an inline function that calls `dynamic_cast` for the `ShadowNodeWrapper` class. On the other hand, the instances of `ShadowNodeWrapper` are created by the code from `libreact_render_uimanager.so`. Because of that `dynamic_cast` fails even though it is called on instance of `ShadowNodeWrapper` because the class has separate vtable/type info: one in `libreanimated.so` and one in `libreact_render_uimanager.so` (by "fails" I mean that it actually returns `nullptr`).
This problem has been documented here: https://developer.android.com/ndk/guides/common-problems#rttiexceptions_not_working_across_library_boundaries where the solution is for the class to have a so-called "key function". The key function makes it so that compiler sees that one of the implementation for a given class is missing and therefore can safely assume that a vtable/type info for a given class is embedded into some library we link to.
This change adds a virtual destructor that is declared in the header file but defined in file that gets compiled as a part of `libreact_render_uimanager`. As a result, the compiler only creates one vtable/type info and calls to dynamic_cast works as expected in all libraries for `ShadowNodeWrapper` and `ShadowNodeListWrapper` classes.
This issue would only surface on Android, because on iOS all libraries by default are bundled together via Pods, whereas on Android each library is loaded separately using dynamic loading.
## Changelog
[Fabric][Android specific] - Fix dynamic_cast (RTTI) for ShadowNodeWrapper and similar classes when accessed by third-party libraries.
Pull Request resolved: https://github.com/facebook/react-native/pull/33500
Test Plan:
1. In order to test this you need to add a library that'd include `<react/renderer/uimanager/primitives.h>` (i.e. use this branch of reanimated library: https://github.com/software-mansion/react-native-reanimated/tree/fabric)
2. After compiling the app inspect libreact_render_uimanager.so and libreanimated.so artifacts with `nm` tool
3. Notice that symbols like `vtable for facebook::react::ShadowNodeWrapper` and `typeinfo for facebook::react::ShadowNodeWrapper` are only present in the former and not in the latter library (before this change you'd see them both)
Reviewed By: ShikaSD
Differential Revision: D35143600
Pulled By: javache
fbshipit-source-id: 5fb25a02365b99a515edc81e5485a77017c56eb8
On Windows there are limits on number of character in file paths and in command lines
Ref: https://android.googlesource.com/platform/ndk/+/master/docs/BuildSystemMaintainers.md#Path-Length-Limits
NDK allows circumventing command line limits using response(RSP) files as inputs using NDK_APP_SHORT_COMMANDS flag.
Windows can support long file paths if configured through registry or by prefixing all file paths with a special character sequence
The latter requires changes in NDK. And there are tools in NDK (AR) which is not able to handle long paths (>256) even after setting the registry key.
The new architecutre source tree is too deep, and the object file naming conventions in NDK makes the matters worse, by producing incredibly long file paths.
Other solutions such as symlinking source code etc. didn't work as expected, and makes the build scripts complicated and hard to manage.
This change temporarily works around the issue by placing the temporary build outputs as short a path as possible within the project path.
Changelog:
[Android] [Fixed] - Fix for building new architecture sources on Windows
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33499
This DIFF turns on the `FB_SONARKIT_ENABLED` flag when installing Flipper ina RN app. The flag is enabled only in Debug config, given that Flipper is installed only in this configuration.
This PR also fixes this issue: https://github.com/facebook/react-native/issues/33497
This PR is required because release 0.67 has the Flag in the app, while release 0.68 moved it in the React-Core pod.
We can't enable the flag at the `React-Core.podspec` level because we should not make assumptions on whether users want flipper or not.
## Changelog
[iOS][Changed] - Enable SonarKit in React-Core when the configuration is `'Debug'`
Reviewed By: cortinico
Differential Revision: D35141506
fbshipit-source-id: 171b7fa8ea7727c633ef963408e86b332c32e9fa
Summary:
Flipper-DoubleConversion and Flipper-Glog iOS pods received a build optimization
a few versions back that pre-compiled the pods and references the xcframework slices
Unfortunately, the pre-compile did not include macCatalyst slices, so this disabled support
for flipper on macOS for react-native >0.65
lblasa has re-compiled the pods with the macCatalyst slices added
See https://github.com/facebook/flipper/issues/3117
<!-- 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] [Fixed] - update Flipper pods to support re-enable macCatalyst
Pull Request resolved: https://github.com/facebook/react-native/pull/33406
Test Plan:
- [ ] The Flipper repo has a react-native test that appeared to work with these versions, CI should work here
- [ ] Prove there is no regression, a flipper-enabled build test should work for simulator iOS target on arm64
- [ ] Prove there is no regression, a flipper-enabled build test should work for simulator iOS target on x86_64 mac
- [ ] Prove there is no regression, a flipper-enabled build test should work for real device iOS target
- [ ] To prove the issue is resolved, a build should be attempted for a macCatalyst target, and it should work.
Reviewed By: cortinico
Differential Revision: D34789654
Pulled By: lblasa
fbshipit-source-id: 466803dd07b5820220512b7d7d760b94b8aa65f7
Summary:
This re-applies Consider relative to pwd installation root when looking for files in rn module via cocoapods by danilobuerger
The `:reactNativePath` provided by `use_native_modules!` is the rn module path relative to the installation root (usually `./ios`). However, when executing cocoapods from a dir thats not the installation root, packages that use the relative `:reactNativePath` variable in their path must also consider the relative to pwd installation root.
This fixes usage of cocoapods with the `--project-directory` flag like
```bash
bundle exec pod install --project-directory=ios
```
## Changelog
[iOS] [Fixed] - Fix usage of cocoapods with --project-directory flag and new arch
Pull Request resolved: https://github.com/facebook/react-native/pull/33427
Test Plan:
1) Enable the new arch
2) Execute from the projects root dir
```bash
bundle exec pod install --project-directory=ios
```
3) It will fail with
```
[!] Invalid `Podfile` file: [codegen] Couldn't not find react-native-codegen..
```
4) Apply the patch
5) Execute from the projects root dir
```bash
bundle exec pod install --project-directory=ios
```
6) It will succeed
Reviewed By: cortinico
Differential Revision: D34890926
Pulled By: dmitryrykun
fbshipit-source-id: f7adc6196874822d5ff38f275414f529d385f2ea
Summary:
Avoid breaking tools relying on absolute path for `cliPath`
## Changelog
[Android] [Fixed] - Enable cliPath to have an absolute path value
Pull Request resolved: https://github.com/facebook/react-native/pull/32983
Test Plan:
declare `cliPath` from `expo`:
```groovy
cliPath: new File(["node", "--print", "require.resolve('react-native/package.json')"].execute(null, rootDir).text.trim()).getParentFile().getAbsolutePath() + "/cli.js",
```
and run an android build
Reviewed By: ShikaSD
Differential Revision: D33843275
Pulled By: cortinico
fbshipit-source-id: 65f55a5e07a4ec0a6205d5f06f150377708c30cc
Summary:
alternative solution for https://github.com/facebook/react-native/issues/33379
> when `use_frameworks!` is on, there are errors like:
> ```
> 'FBReactNativeSpec/FBReactNativeSpec.h' file not found
> #import <FBReactNativeSpec/FBReactNativeSpec.h>
> ```
> this error may come from from https://github.com/facebook/react-native/commit/f7e4c07c84b6 regression.
>
> when `use_frameworks!` is on, xcode will search headers from framework directories, the correct imports would be `#import <React_Codegen/FBReactNativeSpec/FBReactNativeSpec.h>` (xcode will transform dash to underscore, so it is `React_Codegen` but not `React-Codegen`). in the other hand, when `use_frameworks!` is off, the correct import is `#import <React-Codegen/FBReactNativeSpec/FBReactNativeSpec.h>`.
>
>
> this fix is specific for old architecture (fabric is off).
>
> when fabric is on, there are other errors from duplicated headers when copying to build folder. [the reason is that framework build would try to flatten headers](https://mkonrad.net/2015/03/29/xcode-static-libraries-preserving-header-directory-structure.html). we have `primitives.h` in different folders and they would be flattened into `React_Fabric.framework/Headers`. to be honest, i don't know how to deal with the problem in the meantime, maybe subspecs are not enough, we should separate them from subspecs to dedicated podspecs so that we can have these targets as different frameworks.
in this alternative fix, i try to add `React-Codegen/React_Codegen.framework/Headers` into header search paths and make original `#import <FBReactNativeSpec/FBReactNativeSpec.h>` reachable.
[this change](https://github.com/facebook/react-native/commit/7a0398c331f22abc619a64b444ec7153357b0a30) in the pr is just a workaround to solve breaking in latest main branch and this is not important to the `use_frameworks!` fix at all. this breaking was coming from https://github.com/facebook/react-native/commit/180495159517dc0bfa103621e5ff62fc04cb3c8b.
[iOS] [Fixed] - Fix iOS build error when Podfile `use_frameworks!` is on and Fabric is off
Pull Request resolved: https://github.com/facebook/react-native/pull/33409
Test Plan:
verify with rn-tester
1. change `fabric_enabled` to false in `packages/rn-tester/Podfile`
2. `USE_FRAMEWORKS=1 pod install`
3. build rn-tester in xcode
Reviewed By: dmitryrykun
Differential Revision: D34817041
Pulled By: cortinico
fbshipit-source-id: 4d1a610e99a807793eb3f64461e0d735c0a9ca9c
Summary:
When starting the surface, _propagateStageChange is called. This checks the delegate to call surface:didChangeStage: on it.
When initWithSurface:sizeMeasureMode: is called after start, then the delegate will be nil and thus not be called.
This turns it around so a delegate is present for the surface to propagate its state to.
This fixes RCTContentDidAppearNotification not getting posted otherwise.
## Changelog
[iOS] [Fixed] - Post RCTContentDidAppearNotification with new arch
Pull Request resolved: https://github.com/facebook/react-native/pull/33402
Test Plan:
I found it best to set a breakpoint in XCode to where RCTContentDidAppearNotification is being posted.
Prior to the patch that breakpoint will not be called. After applying the patch, it will be called.
Reviewed By: philIip
Differential Revision: D34753329
Pulled By: ShikaSD
fbshipit-source-id: cc44a4c3a787d49e22e9d0c3a82c0f11ed281a0a
Summary:
See the main spec preserve_paths, they are all also included as source_files. Without this, the folly fabric header files won't be available for other pods.
## Changelog
[iOS] [Fixed] - Include folly fabric headers in source files
Pull Request resolved: https://github.com/facebook/react-native/pull/33188
Test Plan:
Include react-native-safe-area-context 4.0.1 with new architecture active. It will result in a xcode build error:
<img width="466" alt="Screenshot 2022-02-26 at 19 33 35" src="https://user-images.githubusercontent.com/996231/155855017-8ea5f473-42a0-4e56-8108-472e6224ae7e.png">
Reviewed By: cortinico
Differential Revision: D34518841
Pulled By: motiz88
fbshipit-source-id: 1053fe204331a314427c793f28b2458e7b78e6c5
Summary:
Added a null check to native.value in Switch to fix regression from RN 66 -> stuck operation in mViewCommandOperations list in Android Release on initial layout of a screen with Switch component. If approved, please incorporate this fix into an RN 66 release.
## Changelog
[Android][Fixed] - Added a null check to native.value in Switch to fix https://github.com/facebook/react-native/issues/32594
Pull Request resolved: https://github.com/facebook/react-native/pull/32602
Test Plan: To reproduce, put a log in UIViewOperationQueue in dispatchViewUpdates you can see that the RetryableMountingException is no longer thrown for a screen with the Switch component on Android Release. As a result, mViewCommandOperations no longer has a stuck operation on initial layout.
Reviewed By: charlesbdudley
Differential Revision: D34397788
Pulled By: lunaleaps
fbshipit-source-id: 1cee3516fb987942dfa50ad1f2d11c965a947f05
Summary:
Due to a bug with AGP, the configureNdkBuild* tasks are not depending on
preBuild tasks. We need to manually fix this otherwise the build will fail the
first time the NDK is invoked.
More on this here: https://issuetracker.google.com/issues/207403732
Changelog:
[Android] [Fixed] - Make sure configureNdkBuild* tasks are depending on
preBuild in the Android template.
Reviewed By: passy
Differential Revision: D34578860
fbshipit-source-id: 5d4caa7d2b7a976b1c9caa6dce8e186c1486cafa
Summary:
Doing this patch level bump to ensure that all packages consuming `react-native` will get `7.0.3` and not lower 7.x versions.
This is because this new patch contains this fix: https://github.com/react-native-community/cli/pull/1560
(thanks NickGerleman & thymikee for your work!)
We'll have to cherry-pick this into the 0.68 branch.
While at it, I've also done a cheeky `npx yarn-deduplicate` to clean up the `yarn.lock` a bit.
<!-- 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] [Changed] - Bump RN CLI to v7.0.3 to address web debugging issue
Pull Request resolved: https://github.com/facebook/react-native/pull/33156
Test Plan:
CI + some local testing via `test-manual-e2e`:
<img width="1779" alt="Screenshot 2022-02-21 at 11 40 54" src="https://user-images.githubusercontent.com/16104054/154948695-8c40bb56-87eb-4326-a740-49930994c08b.png">
Reviewed By: cortinico
Differential Revision: D34385503
Pulled By: motiz88
fbshipit-source-id: f0d8c4e0e92f83c0d819eeaa0fbec27820145968
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33108
The codegen config is optional and can be removed from the default package.json configuration in the template to simplify 0.68 upgrade for people who are not opted-in to the new arch.
Changelog: [Internal] - Remove optional codegenConfig field from template
Reviewed By: cortinico
Differential Revision: D34216988
fbshipit-source-id: 5c448472eed99bc112aef204c4025454171a83c5
Summary:
Time to release a new version of the Gradle plugin and bump it to 0.0.5
This version includes a deprecation of `reactRoot` and a warning message
to migrate to `root`/`reactNativeDir`.
Changelog:
[Android] [Changed] - Release react-native-gradle-plugin 0.0.5
Reviewed By: ShikaSD
Differential Revision: D34339272
fbshipit-source-id: c03495bda7c4185d674761e58a94fde8612f2941
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33142
The `reactRoot` property was confusing as we were using it for both the root of the project
and the react-native NPM Package root. I'm deprecating it and splitting it in two.
I've added several warning in the codebase to tell the people how to migrate away from it.
Moreover this is specifying default values that are more user-friendly. Users won't have to
configure anything unless they are in a monorepo.
Changelog:
[Android] [Changed] - Gradle: Deprecate `reactRoot` in favor of `root` and `reactNativeDir`
Reviewed By: ShikaSD
Differential Revision: D34277050
fbshipit-source-id: fc7f45017452b086726516a9586cacd9a661c287
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33134
When a user is enabling New Architecture, we should make sure they don't accidentally mix
imports of React Native from source vs prebuilts.
With this resolution strategy, we'll make sure all the import of `com.facebook.react:react-native:+`
will be resolved to the correct dependency.
Changelog:
[Android] [Fixed] - Set a resolution strategy for com.facebook.react:react-native when on New Architecture
Reviewed By: ShikaSD
Differential Revision: D34303267
fbshipit-source-id: 492fec59175c5887571e1b09ca8e233584b45dd1
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:
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:
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:
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:
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:
Fixes a potential crash was introduced by https://github.com/facebook/react-native/issues/30919 that aimed to get the keyboard height on devices with a Notch. The problem is that it considers that any ReactRootView will have an insets available.
When using [react-native-navigation](https://github.com/wix/react-native-navigation) and assigning a Navigation button to the TopBar as a component, the component gets registered as a RootView but won't have any insets attach to the view.
[getRootWindowInsets()](https://developer.android.com/reference/android/view/View#getRootWindowInsets()) in fact return a `WindowInset` only available if the view is attached, so when executing `checkForKeyboardEvents` method from ReactRootView, is trying to access the `DisplayCutout` of a null object, leading to a crash.
## Changelog
[Android] [Fixed] - Fix potential crash if ReactRootView does not have insets attached.
Pull Request resolved: https://github.com/facebook/react-native/pull/32989
Test Plan:
Without the code change: Notice how the second screen being push contains a React Component on the top right of the navigation bar, and when component is unmounted (going back) the app crashes.
https://user-images.githubusercontent.com/6757047/151558235-39b9a8b5-be73-4c31-8053-02ce188637b8.mp4
crash log
```
2022-01-28 10:27:52.902 15600-15600/com.mattermost.rnbeta E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.mattermost.rnbeta, PID: 15600
java.lang.NullPointerException: Attempt to invoke virtual method 'android.view.DisplayCutout android.view.WindowInsets.getDisplayCutout()' on a null object reference
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.checkForKeyboardEvents(ReactRootView.java:778)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.onGlobalLayout(ReactRootView.java:769)
at android.view.ViewTreeObserver.dispatchOnGlobalLayout(ViewTreeObserver.java:1061)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3214)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2143)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:8665)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1037)
at android.view.Choreographer.doCallbacks(Choreographer.java:845)
at android.view.Choreographer.doFrame(Choreographer.java:780)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1022)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:201)
at android.os.Looper.loop(Looper.java:288)
at android.app.ActivityThread.main(ActivityThread.java:7839)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)
```
After applying the patch which is only a null check validation and does not change any previous behavior
https://user-images.githubusercontent.com/6757047/151558429-9ff1a608-abb6-4168-8db9-df0c3c71d79e.mp4
Reviewed By: cortinico
Differential Revision: D33844955
Pulled By: ShikaSD
fbshipit-source-id: ed5579ad3afeed009c61cc1851eee45c70087cf5
Summary:
Updates maximum heap size for the gradle build to account for building RN from source when new architecture is enabled.
Changelog: [Changed][Android] - Use 2g as a default heap size for gradle builds
Reviewed By: cortinico
Differential Revision: D33947090
fbshipit-source-id: 2f551e688f2d92c3092e053086f6933779cd6f63
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Distiller
Lorenzo Sciandra
Kunal FarmahandLorenzo Sciandra
Olivier PayenandLorenzo Sciandra
Kunal FarmahandLorenzo Sciandra
Nicola CortiandLorenzo Sciandra
Distiller
Distiller
Marek FořtandGitHub
Danilo Bürgerandfortmarek
Krzysztof Magieraandfortmarek
Distiller
Distiller
Riccardo CipolleschiandAndrei Shikov
Distiller
Mike HardyandAndrei Shikov
KrisztiaanandAndrei Shikov
Kudo ChienandAndrei Shikov
David VaccaandAndrei Shikov
Danilo BürgerandAndrei Shikov
jonathanmosandAndrei Shikov
Distiller
Muhammad NumanandAndrei Shikov
Alfonso CurbeloandAndrei Shikov
Minsik KimandAndrei Shikov
Chiara MooneyandGitHub
Distiller
Elias NahumandAndrei Shikov
Distiller
