Summary:
## Rationale
Inlining the maybeLoadSoLibrary private static method makes following the So load chain from TurboModuleManagerDelegate through ReactPackageTurboModuleManagerDelegate to each app's TurboModuleManagerDelegate much easier to understand.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D30082675
fbshipit-source-id: ff467d6ac8c792317dd9bdcd91844d3b480cbb60
Summary:
Fixes https://github.com/facebook/react-native/issues/31774.
This pull request resolves a problem related to accessing blobs greater than 64 KB on Android. When an object URL for such blob is passed as source of `<Image />` component, the image does not load.
This issue was related to the fact that pipe buffer has a limited capacity of 65536 bytes (https://man7.org/linux/man-pages/man7/pipe.7.html, section "Pipe capacity"). If there is more bytes to be written than free space in the buffer left, the write operation blocks and waits until the content is read from the pipe.
The current implementation of `BlobProvider.openFile` first creates a pipe, then writes the blob data to the pipe and finally returns the read side descriptor of the pipe. For blobs larger than 64 KB, the write operation will block forever, because there are no readers to empty the buffer.
https://github.com/facebook/react-native/blob/41ecccefcf16ac8bcf858dd955af709eb20f7e4a/ReactAndroid/src/main/java/com/facebook/react/modules/blob/BlobProvider.java#L86-L95
This pull request moves the write operation to a separate thread. The read side descriptor is returned immediately so that both writer and reader can work simultaneously. Reading from the pipe empties the buffer and allows the next chunks to be written.
## 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 support for blobs larger than 64 KB
Pull Request resolved: https://github.com/facebook/react-native/pull/31789
Test Plan:
A new example has been added to RN Tester app to verify if the new implementation properly loads the image of size 455 KB from a blob via object URL passed as image source.
<img src="https://user-images.githubusercontent.com/20516055/123859163-9eba6d80-d924-11eb-8a09-2b1f353bb968.png" alt="Screenshot_1624996413" width="300" />
Reviewed By: ShikaSD
Differential Revision: D29674273
Pulled By: yungsters
fbshipit-source-id: e0ac3ec0a23690b05ab843061803f95f7666c0db
Summary:
Building from source in debug takes a very long time because native builds need to run for all supported architectures. It is possible to check which architecture the devices for which we are about to launch the app on are and build only for those. For most cases we can reduce the number of architectures we build for to 1 instead of 4, resulting in a large speedup of the build.
This is inspired by iOS which has a "Build for active architecture only" option. Since android doesn't really support this natively we can implement it here and also in react-native by reading the build properties that we pass and alter the abi we build for.
With fabric / codegen coming up I suspect that we might want to default to building c++ soon. This should ease the transition as builds won't be orders of magnitude slower.
See https://github.com/react-native-community/cli/pull/1388 for more context and how we use this new config to automatically detect running emulator architectures.
## Changelog
[Android] [Added] - Allow configuring ndk build architectures
Pull Request resolved: https://github.com/facebook/react-native/pull/31232
Test Plan:
Tested by setting reactNativeDebugArchitectures with different values in gradle.properties. Checked the build logs to see which architectures are being built. Also made sure release builds are not affected by this value.
Clean build
reactNativeDebugArchitectures not set
824.41s
reactNativeDebugArchitectures=x86
299.77s
Reviewed By: mdvacca
Differential Revision: D29613939
Pulled By: ShikaSD
fbshipit-source-id: d20a23d1d9bbf33f5afaaf3475f208a2e48c0e1a
Summary:
Latest Android Gradle plugin doesn't respond to ANDROID_NDK env variable, so I propagated it explicitly and included with recommended `ndkPath` clause.
Changelog: [Internal]
allow-large-files
Reviewed By: fkgozali
Differential Revision: D29593132
fbshipit-source-id: 0785fe92385037d2d4cf290c2462b299800b6928
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/31675
As requested in parent diff, moved the Android dep bumps into a separate diff.
## Changelog
[general][changed] - [Android] Update Flipper to 0.93.0
Reviewed By: mdvacca, ShikaSD
Differential Revision: D28688486
fbshipit-source-id: c3a8e0edeebdabd490b2885497e261f64bdab4bd
Summary:
jcenter is read-only now, and newer versions of dependencies will be published to either MavenCentral or Jitpack. This PR removes jcenter to avoid future issues, then uses MavenCentral and Jitpack as replacement. Current flipper depends on Stetho version that is not available on MavenCentral, so had to exclude and bump the version.
Both Gradle and Buck successfully download all the dependencies.
## Changelog
[Android] [Changed] - Remove jcenter
Pull Request resolved: https://github.com/facebook/react-native/pull/31609
Test Plan: rn-tester builds and runs as expected.
Reviewed By: mdvacca
Differential Revision: D28802444
Pulled By: ShikaSD
fbshipit-source-id: 043ef079d0cda77a1f8dd732678452ed712741a4
Summary:
Bump Gradle to 6.9 which supports Apple Silicon, also Android Gradle Plugin 4.2.1 which defaults to Java 1.8 so no additional config required.
## Changelog
[Android] [Changed] - Bump Gradle to 6.9, Android Gradle Plugin to 4.2.1
Pull Request resolved: https://github.com/facebook/react-native/pull/31593
Test Plan: rn-tester builds and runs as expected
Reviewed By: mdvacca
Differential Revision: D28711942
Pulled By: ShikaSD
fbshipit-source-id: 2a4616cd0f17db7616ab29dea1652717f2cd0f6d
Summary:
Changelog: [Internal] enable support for C++ 17.
C++ 17 in React Native targets.
Short and comprehensive list of C++ features:
https://github.com/AnthonyCalandra/modern-cpp-features#c17-language-features
Reviewed By: JoshuaGross
Differential Revision: D27431145
fbshipit-source-id: e8da6fe9d70e9b7343a8caec21cdbeb043478575
Summary:
allow-large-files
RN Tester is using an old version of Flipper. This will help testing regressions in the latest version (which is installed when starting a new project). This also fixes an issue where libevent is incompatible between the one in flipper and when using hermes on iOS. To fix it I changed to use the version published on cocoapods instead of using a local podspec (see https://github.com/facebook/flipper/issues/1916).
## Changelog
[General] [Changed] - Update flipper
Pull Request resolved: https://github.com/facebook/react-native/pull/31010
Test Plan:
- Tested that RN tester builds and flipper works with hermes enabled / disabled and fabric on iOS
- Tested that RN tester builds and flipper works on Android
Reviewed By: fkgozali
Differential Revision: D26592317
Pulled By: PeteTheHeat
fbshipit-source-id: 2cd278c7a51b1859dab0465846b061221f07d3f6
Summary:
Changelog: [Internal]
Debuggable flag defines multiple things for flavours including `NDEBUG` flag in native builds. We need to explicitly state this from build.gradle to use it.
Reviewed By: JoshuaGross
Differential Revision: D26610482
fbshipit-source-id: e0c8095e239241c57a119e561b125cab16bf299f
Summary:
Changelog:
[Android][Added] - Basic definition for react gradle plugin
Adds plugin and build configuration + copies config from react.gradle to extension.
Copies internals of react.gradle to the plugin. Will be refactored in the next commits.
Reviewed By: mdvacca
Differential Revision: D25693008
fbshipit-source-id: b0feaa02cee8a1ee94d032426d19c501ff3b2534
Summary:
Building ReactAndroid from source on Windows has recently hit the limitation of maximum path lengths.
At build time, during the `:ReactAndroid:buildReactNdkLib` task, the linker tries to access several of the intermediate binaries located deep in the tmp folder hierarchy, eg.
```
D:\r\ReactAndroid\build\tmp\buildReactNdkLib/local/armeabi-v7a/objs/react_render_components_progressbar/D_/r/ReactAndroid/__/ReactCommon/react/renderer/components/progressbar/android/react/renderer/components/progressbar/AndroidProgressBarMeasurementsManager.o
```
**Suggested fix:** for modules such as `react_render_components_progressbar` and `react_render_components_picker`, rename them to `rrc_progressbar` etc.
**NOTE**: this assumes that the fix from https://github.com/facebook/react-native/issues/30535 is in place. This regression happened while https://github.com/facebook/react-native/issues/30535 has been pending checkin.
**Other mitigations I've tried:**
- setting [`LOCAL_SHORT_COMMANDS`](https://developer.android.com/ndk/guides/android_mk#local_short_commands) for the problematic modules or `APP_SHORT_COMMANDS` for the root project. Turns out those commands don't work on the NDK version RN requires, but even after manually applying a [patch ](https://android-review.googlesource.com/c/platform/ndk/+/1126440) to my local copy of the NDK, these flags had no effect.
- moving the repo directory higher in the file system tree, and using short directory names `D:\r\...` was not enough
- creating virtual drive letters for specific long paths with the [`sust`](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/subst#examples) command is not workable, since they depend on the source folder structure, and get partly generated by the build system, which I can't plug into
- just enabling long path support on Windows is not enough, since the compiler toolchain doesn't support them.
## 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 source build on Windows machines vol. 2
Pull Request resolved: https://github.com/facebook/react-native/pull/30776
Test Plan:
Run `.\gradlew installArchives`
Before:
Now:
Differential Revision: D26194286
Pulled By: mdvacca
fbshipit-source-id: 778b5a0515148e2ace19e7902f74301831ebed94
Summary:
We'll pass these ReactPackageTurboModuleManagerDelegate.Builders to ReactInstanceManager. ReactInstanceManager will then use these builders to initialize the TurboModule system. To allow TurboModules to work with RNTester, we have to switch RNTester over to using these Builders.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26193054
fbshipit-source-id: d98b857226be3ebaa22b1b734a4e76c0f4be6608
Summary:
Previously, owner(TurboModuleManager) used to depend on owner(ReactInstanceManager). Now, owner(ReactInstanceManager) depends on owner(TurboModuleManager).
**Rationale:** This allows ReactInstanceManager to create TurboModuleManager.
## Changes
We moved ReactPackageTurboModuleManagerDelegate to com.facebook.react.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26163661
fbshipit-source-id: 3ebff16ef2aa77e20bb55500ed44c9214acb91dd
Summary:
This diff refactors the intialization of Fabric in order to avoid loading UIManagerModule as part of the creation of FabricJSIModuleProvider.
One caveat is that now we are not taking into consideration the flag mLazyViewManagersEnabled
master/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/CoreModulesPackage.java177
if (mLazyViewManagersEnabled) {
As a side effect of this diff view managers will be initialized twice if the user has fabric and paper enabled
This diff was originally backed out in D25739854 (https://github.com/facebook/react-native/commit/4984c1e525e310f15c7d89230fdb2fa8fea91f05) because it produced a couple of bugs:
https://fb.workplace.com/groups/rn.support/permalink/4917641074951135/https://fb.workplace.com/groups/rn.support/permalink/4918163014898941/
These bugs are fixed by D25667987 (https://github.com/facebook/react-native/commit/2e631471092090e743245377742166ecae1d7e26).
This diff was reverted a couple of times because of the change in the registration of eventDispatcher. That's why I'm gating that behavior change as part of the "StaticViewConfig" QE.
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D25858934
fbshipit-source-id: a632799ccac728d4efca44ee685519713b4a7cbb
Summary:
When I try to run RNTester with Gradle the RNTester Required me to use **NDK 20.0.5594570**. I can't seem to find an explicit NDK version anywhere in ReactAndroid and RNTester. This PR Aims to add an explicit NDK version to RNTester and ReactAndroid.
## Changelog
[Android] [Added] - Add an explicit NDK version to RNTester and ReactAndroid.
Pull Request resolved: https://github.com/facebook/react-native/pull/29987
Test Plan: Build manually from RNTester
Reviewed By: fkgozali
Differential Revision: D23911371
Pulled By: ShikaSD
fbshipit-source-id: 2f297c73890c0eb0bfec0e2ba7ec5755b4d84243
Summary:
This commit makes both `:ReactAndroid` and `:rn-tester:android:app` always compile in Fabric codegen outputs. However, one may still enable/disable Fabric at runtime by setting `USE_FABRIC` env var (set to 1 or 0, default is 0).
Note that we can't register custom components specific to the app, yet, so only the components in react-native github repo is covered by this commit.
RNTester doesn't enable Fabric by default yet due to known UI bugs that haven't been addressed yet.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25674311
fbshipit-source-id: 8db660c959319250ebc683c84076677cf6489e94
Summary:
Generate Fabric C++ files along side TM spec files for RNTester. The combined .so then has both TM and Fabric files.
This commit also removed the checked-in JNI files.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25674313
fbshipit-source-id: 8091d5a00f42849a74cab50e8d24f4010d500e5b
Summary:
The TM specs and Fabric files should be combined into the same .so. For short term parity with Fabric components and iOS, let's rename ReactAndroidSpec (default name based on project path) to "rncore".
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25674312
fbshipit-source-id: 3d71aa0cc945affecb06dcfc15e807dd48c76468
Summary:
## Context
Every time we require a NativeModule in Java, we [first try to create it with the TurboModuleManager](https://fburl.com/diffusion/3nkjwea2). In the TurboModule infra, when a NativeModule is requested, [we first create it](https://fburl.com/diffusion/d2c6iout), then [if it's not a TurboModule, we discard the newly created object](https://fburl.com/diffusion/44gjlo6y). This is extremely wasteful, especially when a NativeModule is requested frequently and periodically, like UIManagerModule.
Therefore, in D24811838 (https://github.com/facebook/react-native/commit/803a26cb003e6b790e3a1ab31beb0c95795fff0c) fkgozali launched a fix to the infra that would avoid creating the non-TurboModule object in the first place. Today, we're launching this optimization.
Reviewed By: fkgozali
Differential Revision: D25621570
fbshipit-source-id: dedba4d5ac6fcf2ec3c31e7163a6a226065c708b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/30416
This diff changes the constructor param for TurboModuleManager from jsContext (a long representing the `jsi::Runtime` pointer) to a RuntimeExecutor. It also updates callsites to use the new RuntimeExecutor created by CatalystInstance. This is only used for installing the TurboModule JSI binding; it's not currently used for JS invocation in TurboModules, which is handled separately by JSCallInvoker. Ultimately we may be able to implement JSCallInvoker *with* the provided RuntimeExecutor, but there's some additional logic in JSCallInvoker that we don't have here yet.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D21338930
fbshipit-source-id: 1480c328f1a1776ddf22752510c0f3b35168a489
Summary:
Migrate over to [how we load so libraries in Fb4aTurboModuleManagerDelegate](https://fburl.com/diffusion/wu0mcr8o).
## Motivation
When we migrated Twilight over to TurboModules, we used the CatalystTurboModuleManager as a template. This led to a production crash (T70918829) because we weren't loading so's this way. The fix: D24894071.
I'm updating these two TMMDelegates so that people don't fall into the same trap when migrating other Standalone apps.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24992931
fbshipit-source-id: 3ac3b8c30a67e24f79021f915abf5ae980d5b5d3
Summary:
There is a flow where TM registry is creating a module instance (as registered in the TurboReactPackage), only to discard it if it's not a TM enabled module. This may be fine for many modules, but for module like `UIManagerModule`, this may cause a race condition or other issues, including potential perf regression when accessing UIManager from JS (e.g. for getting native viewConfigs).
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24811838
fbshipit-source-id: 6e1cce6993a6e5c9763773f175083bf52925c910
Summary:
Pass the ReactAndroid project build directory as a variable to the ndk build so it can be used instead of assuming that the build directory is under ReactAndroid/build.
## Changelog
[Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/30222
Test Plan: Tested in an app with a custom build directory
Reviewed By: yungsters
Differential Revision: D24560643
Pulled By: fkgozali
fbshipit-source-id: cc65a70582f546ca2e2ca9fb6a2ff03ea70ca9d8
Summary:
This does a few things:
* Remove USE_CODEGEN flag so that TurboModule is enabled by default for RNTester
* Use the codegen output for Java/JNI spec files
* Remove the checked in com.facebook.fbreact.specs Java/JNI files
Changelog: [Changed][Android] RNTester now enables TurboModule by default using codegen.
Reviewed By: RSNara
Differential Revision: D24382083
fbshipit-source-id: 87e3e0581bac3287ef01c1a0deb070c1d7d40f2d
Summary:
This diff updates the minsdkversion of RN OSS template to API level 21.
Changelog: [Android][Deprecated] Deprecate support of Android API levels 19 and 20. The new minSDK version will be 21+ moving forward.
Reviewed By: fkgozali
Differential Revision: D24379607
fbshipit-source-id: 6801cdcd363065807cdc11006bd94217f914fac7
Summary:
The manual lookup logic was needed before we properly parse the module names from the spec js files. This is no longer necessary after the commit stack starting with https://github.com/facebook/react-native/commit/3a75b376cc3c44f9693d99b33046cf76d6fafa89
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24370567
fbshipit-source-id: fc307d93cdda240a977e37dfe602502bd3f7c2a4
Summary:
The sample module is meant for demo only, but it lives alongside other core modules in react-native repo.
For now, exclude it in the Flow-type parsing, just like `NativeUIManager.js`
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24005108
fbshipit-source-id: 9ef524bfe2778dd983c94d1701f9ce49da5e0a68
Summary:
This compiles SampleTurboModule into RNTester Android. It also adds the NativeModule playground to show case TurboModule system to RNTester examples, just like in iOS.
{F337854369}
Changelog: [Android][TurboModule] Added TurboModule example to RNTester when `USE_CODEGEN` is set
Reviewed By: hramos
Differential Revision: D24004711
fbshipit-source-id: b682dd51fa998ee2e60f8d6ffd8c39220d13a7fe
Summary:
Before RNTester compilation starts, it needs to wait for :ReactAndroid NDK build to finish, so that it knows where to find the exported .so files. This tells the `preBuild` task to depends on `:ReactAndroid:prepareReactNdkLibs` task. The .so files are now copied over to the local project build dir, instead of depending on :ReactAndroid's build dir.
For cleanup, the reverse ordering is needed: before `clean` removed our temp dir to store the copied .so files, make sure the ndkBuild cleanup tasks execute beforehand.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23982989
fbshipit-source-id: 955d7c9bccb5855b6b066fca89764df2ede89f63
Summary:
If built with `USE_CODEGEN=1` flag set, RNTester now activates the TurboModule system, also using various codegen output from the previous commits.
Note that this is very early integration, and not thoroughly tested yet.
To verify:
```
console.warn('TM enabled?', global.__turboModuleProxy != null);
```
{F337454276}
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D23946944
fbshipit-source-id: 5838aeb9ded07b1cc0fcb069535d1c6fb3725973
Summary:
This provides the RNTester specific impl of the manager delegate. The class is responsible to provide module lookup during runtime for TurboModule, and the C++ impl is using the codegen-generated lookup functions from :ReactAndroid and :packages:rn-tester:android:app Gradle targets.
Note: RNTester still needs to explicitly enable TurboModule and instantiate this manager before it can activate TurboModule.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D23938537
fbshipit-source-id: 7957847ecc58fef8d9a276d9d3d477ecec36a700
Summary:
TurboModule Java files are still using the old lib name: `turbomodulejsijni`, so let's keep it that way for now.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D23946945
fbshipit-source-id: ff095ff51dca532c82e67e1c75e9a4e9be392d61
Summary:
To make it easier for hosting app or other lib to get access to the ReactAndroidNdk .so outputs, let's define common targets in a dedicated Android-prebuilt.mk. Hosting app's Android.mk just need to include the mk path.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D23938538
fbshipit-source-id: 850d690326d134212d5f040c6fa54ab50c53cb87
Summary:
The react-native-codegen provides Android.mk in the Android C++ output, but for RNTester (or hosting apps), we should just compile the codegen output with the rest of the app-specific C++ files. This is to simplify the build configuration, and also to not add too many additional .so libs to the APK.
With this commit, `RNTesterAppModuleProvider.cpp` should be "complete" for RNTester use-case. This TurboModule lookup function is the one described in https://github.com/react-native-community/discussions-and-proposals/issues/273.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23913149
fbshipit-source-id: d1ca136787b87a0e8e6504318e1f0a78efef46ea
Summary:
This adds shared libraries dependencies to RNTester so that it can call `ReactAndroidSpec_ReactAndroidSpec_ModuleProvider()` C++ lookup function. That function is generated by the react-native-codegen during build time. This does not make RNTester use TurboModule yet, just the necessary setup to link the C++ libs together.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23901952
fbshipit-source-id: fd5ee0ca266609207962adc5ceaf814956052eec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/30014
This is the base setup to compile C++ as part of RNTester app. There is no dependencies on ReactAndroidNdk lib yet, just a bunch of ndkBuild setup in Gradle. Note: this is using Gradle's `nkdBuild` support instead of calling `ndk-build` manually like in ReactAndroid/build.gradle.
Reference: https://google.github.io/android-gradle-dsl/current/com.android.build.gradle.internal.dsl.ExternalNativeNdkBuildOptions.html
Note that `ANDROID_NDK` env var is honored to pick the right NDK version.
For now, this is gated behind `USE_CODEGEN` env variable.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D23887058
fbshipit-source-id: 7a962649461d15af46999a15b900464543e5b05c
Summary:
Now that the react-native-codegen produces the Android.mk for the JNI C++ output, let's compile them into its own shared library, to be included in the ReactAndroid final deliverable: libreact_codegen_reactandroidspec.so. This is gated behind `USE_CODEGEN` env var.
Note: RNTester specific C++ spec files are not compiled here.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23809081
fbshipit-source-id: 7a90f420a923d5d02654facac01ffe025c321e44
Summary:
The current Flipper version included in new React Native is quite old, causing some bugs to be present which have long been solved, such as freezing the UI after inspecting it.
Fixes
This fixes https://github.com/facebook/react-native/issues/29492 /
https://github.com/facebook/flipper/issues/1399
## 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][changed] - Update Flipper to 0.54
Pull Request resolved: https://github.com/facebook/react-native/pull/29787
Test Plan:
Updated the RN 0.63.2 based test project https://github.com/mweststrate/flipper-issue-1399-repo with `use_flipper!('Flipper' => '0.54.0')` (in `ios/Podspec`) / `FLIPPER_VERSION=0.52.1` in `gradle.properties` in the test project https://github.com/mweststrate/flipper-issue-1399-repo and verified that everything builds and connects correctly, and that the bug is no longer present.
Tried to run RN-tester project in this repo. For iOS this succeeded, on Android I got a build error:
```
make: Leaving directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
make: Entering directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
fcntl(): Bad file descriptor
[armeabi-v7a] Compile++ thumb: folly_json <= FileUtil.cpp
/Users/mweststrate/Desktop/react-native/ReactAndroid/build/third-party-ndk/folly/folly/FileUtil.cpp:37:14: error: no matching function for call to 'wrapNoInt'
make: Leaving directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
return int(wrapNoInt(open, name, flags, mode));
^~~~~~~~~
/Users/mweststrate/Desktop/react-native/ReactAndroid/build/third-party-ndk/folly/folly/detail/FileUtilDetail.h:34:9: note: candidate template ignored: couldn't infer template argument 'F'
ssize_t wrapNoInt(F f, Args... args) {
^
1 error generated.
make: *** [/opt/android_sdk/ndk/21.3.6528147/build/core/build-binary.mk:478: /Users/mweststrate/Desktop/react-native/ReactAndroid/build/tmp/buildReactNdkLib/local/armeabi-v7a/objs/folly_json/folly/FileUtil.o] Error 1
make: *** Waiting for unfinished jobs....
fcntl(): Bad file descriptor
make: Entering directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
[armeabi-v7a] Compile++ thumb: folly_json <= Demangle.cpp
```
No idea if it is related. I guess not since without making the change I got the same error.
Reviewed By: mweststrate
Differential Revision: D23767388
Pulled By: fkgozali
fbshipit-source-id: 35f0d3ddec41942f5bbc96cb391975d84729ef5e
Summary:
It looks like this config in gradle.properties caused the :packages:rn-tester:android:app:dependencies task to fail. This was reported here: https://github.com/gradle/gradle/issues/9645#issuecomment-530746758 -- it's likely related to using Kotlin build.gradle.kts?
For now comment these out.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23521954
fbshipit-source-id: 9997f4950d89e5fc57036b05db5518b39d47737b
Summary:
## 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
-->
This PR aims to migrate the RNTester App to `packages` directory. But is currently, open to inspect the CI issues and resolve the merge conflicts.
Currently done
- Working on iOS
- Working on Android
- Detox Tests working on iOS
Need to work on
- Errors generated by the CI builds
[General] [Changed] - Migrated the RNTester App to the packages directory.
Pull Request resolved: https://github.com/facebook/react-native/pull/29567
Test Plan: It runs on both ios and android for now and the detox iOS builds are working.
Reviewed By: cpojer
Differential Revision: D23034761
Pulled By: rickhanlonii
fbshipit-source-id: e04bb06e1c7ef15d340206090d1575a871b9e6f5
Ramanpreet Nara
Stefan Wrobel
Tomek Zawadzki
Janic Duplessis
Andrei Shikov
Michel Weststrate
Dulmandakh
Samuel Susla
Igor Klemenski
David Vacca
Agastya Darma
Kacie Bawiec
Kevin Gozali
Emily Janzer
Joshua Gross
Rick Hanlon
stealthanthrax
