Summary:
Fix for https://github.com/facebook/react-native/issues/27952.
Noticed more than just `AUTOFILL_HINT_NEW_PASSWORD` were missing, this PR will support every `AUTOFILL_HINT_*` type.
## Changelog
[Android] [Added] - Added all autofill types to TextEdit
Pull Request resolved: https://github.com/facebook/react-native/pull/28008
Reviewed By: sturmen
Differential Revision: D29766235
Pulled By: mdvacca
fbshipit-source-id: d5171aef8092d37716fddcb6f3443637a4af8481
Summary:
Updates documentation in React Native to reference `main` (or `HEAD` for URLs) instead of `master`.
Part of https://github.com/facebook/react-native/issues/31788.
Changelog:
[General][Changed] - Update documentation reference from `master` to `main` or `HEAD`.
Reviewed By: JoshuaGross
Differential Revision: D29717128
fbshipit-source-id: 0b0babd8407c6fd3d0e5431f6eaf976059731d6f
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:
Upgrade folly for the https://github.com/facebook/folly/pull/1593 fix for NDK 21 failure
## 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] [Changed] - Upgrade folly to 2021.06.28.00
Pull Request resolved: https://github.com/facebook/react-native/pull/31802
Test Plan:
`./gradlew :ReactAndroid:installArchives`
`./gradlew packages:rn-tester:android:app:installJscRelease`
`./gradlew packages:rn-tester:android:app:installHermesRelease`
Reviewed By: RSNara
Differential Revision: D29547027
Pulled By: ShikaSD
fbshipit-source-id: a10c7c65f459091bd0e7cca750a9b9e067189b73
Summary:
The native libraries are compiled outside of the usual Android build flow using separate CLI task. Because of that, shared native libraries may not exist when AAR is bundled, resulting in weird sequencing issues.
This change updates gradle dependency graph, executing RN native build before Android part (as it is done in RNTester already).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29209249
fbshipit-source-id: 36386c78996b1cd9b1731735e36e571199e9e81b
Summary:
This PR bumps NDK_VERSION to 21.4.7075529, and patches FileUtil.cpp from folly based on patch from https://github.com/facebook/folly/pull/1593. We can remove the patch once PR lands in Folly and bump Folly version in RN.
FYI, NDK 20 is deprecated and 21 is LTS release.
## Changelog
[Android] [Changed] - Bump NDK to 21.4.7075529
Pull Request resolved: https://github.com/facebook/react-native/pull/31731
Reviewed By: mdvacca
Differential Revision: D29166690
Pulled By: ShikaSD
fbshipit-source-id: 0792691404f718aaf5af1369f66f0cba046b4e20
Summary:
Gradle has been showing below warning for a while, and this PR fixes the warning using maven-publish plugin, thus taking us one step closer to Gradle 7.x.
> The maven plugin has been deprecated. This is scheduled to be removed in Gradle 7.0. Please use the maven-publish plugin instead. Consult the upgrading guide for further information: https://docs.gradle.org/6.9/userguide/upgrading_version_5.html#legacy_publication_system_is_deprecated_and_replaced_with_the_publish_plugins
Configured maven-publish plugin according to https://developer.android.com/studio/build/maven-publish-plugin, also added **installArchives** task for backwards compatibility.
## Changelog
[Internal] [Changed] - use maven-publish plugin to build and publish Android artifact
Pull Request resolved: https://github.com/facebook/react-native/pull/31611
Test Plan: ./gradlew :ReactAndroid:installArchives will create **android** directory for local maven repository with **react-native** package.
Reviewed By: yungsters
Differential Revision: D28802435
Pulled By: ShikaSD
fbshipit-source-id: 7bc7650a700e1a61213c5ec238bcb24fdca954db
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:
Updates Gradle script to include new version of folly (synced to iOS update)
Adds fmt and libevent as well as some boost ASM sources to enable compilation of folly futures.
Changelog:
[Android] Updated folly to 2021.04.26
Reviewed By: fkgozali
Differential Revision: D28124377
fbshipit-source-id: d44c5a1ded5ee7ad514a9df14ea2ba326d4aa0e3
Summary:
Extends https://github.com/facebook/react-native/pull/30694 to fix tests.
OkHttp v4 was released almost a year ago. Even though v3 is still receiving security and bug fixes, most of the new improvements and features are landing in v4. This PR bumps OkHttp from v3 to v4 and addresses backward-incompatible changes.
Side effects of this upgrade:
- OkHttp v4 depends on Kotlin's standard library, so react-native will have a transitive dependency on it.
- The dex method count of test apk has exceeded the maximum, so multidexing had to be enabled for android tests.
## 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] [Changed] - Bumping OkHttp from v3 to v4.
Pull Request resolved: https://github.com/facebook/react-native/pull/31084
Test Plan: Automated (relying on the test suite) and manual testing.
Reviewed By: fkgozali
Differential Revision: D27597430
Pulled By: ShikaSD
fbshipit-source-id: 967379b41c2bcd7cfd4083f65059f5da467b8a91
Summary:
Instead of annotating individual methods with DoNotStrip, we actually want to ensure that nothing in this class gets stripped out.
This also upgrades the yoga/proguard-annotations package for Gradle builds.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27335181
fbshipit-source-id: 5b696c26faf4d1b32a3fd885e42a996aff23f0be
Summary:
android fbjni dependency bump to 0.2.2
The motivation is to address https://github.com/pytorch/pytorch/issues/34682 that pytorch_android and react-native use different versions of fbjni with the same name libfbjni.so
In case of loading 0.0.2 version it is missing functions in binary
Fbjni is not changing much, that's why this will solve that problem for a long time (Until fbjni changed and versions will not be aligned)
## Changelog
[Android][Added] fbjni version bump to 0.0.3
Pull Request resolved: https://github.com/facebook/react-native/pull/31191
Test Plan: Automated (relying on the test suite) and manual testing.
Reviewed By: passy
Differential Revision: D27330370
Pulled By: IvanKobzarev
fbshipit-source-id: 2ea07d80d23f8dbc80e946a8818c1ecb8eb746e8
Summary:
## Summary
Bump Android compileSdkVersion and targetSdkVersion to 30
## Changelog
[Android][Changed] Bump Android compileSdkVersion and targetSdkVersion from 29 to 30
Pull Request resolved: https://github.com/facebook/react-native/pull/31078
Test Plan: Circle CI and Sandcastle
Reviewed By: mdvacca
Differential Revision: D26765188
Pulled By: hramos
fbshipit-source-id: a971641cea4860df58ce6e9b0f14405bfc4e0979
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:
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/30595
Changelog: [Internal]
Add support for loading HBC bundles from Metro in Twilight.
* adds `runtimeBytecodeVersion` to the bundleURL
* adds logic to check chunk hermes bytecode bundles
* adds support for running the bytecode bundles
Reviewed By: cpojer
Differential Revision: D24966992
fbshipit-source-id: acdd03a2e9e2b3e4c29c99c35a7c9136a3a7ef01
Summary:
A bunch of deps were missing when generating Javadoc, producing warnings. One issue was:
```
project.getConfigurations().getByName("compile").asList()
```
Seems to be deprecated (?), so this list is always empty. The mitigation is to create a new configuration that just inherits from `api()` dependencies, so that we can add them in Javadoc task.
The other problem (not solved in this commit), is that some deps are .aar files, which require some manual unpacking before they can be processed: https://stackoverflow.com/questions/35853906/how-to-generate-javadoc-for-android-library-when-it-has-dependencies-which-are-a
Note that this is separate fix from https://github.com/facebook/react-native/pull/30417
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D25041164
fbshipit-source-id: 2ee8b268c2d38e3ecbf622c05c3c56123b7a15a6
Summary:
Various TM infra classes previously were stripped by proguard. This updates the rule to not remove TM Android core infra.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24812999
fbshipit-source-id: 3b713c63e25a209b17869f7e5311ee54a113a567
Summary:
Bump Okio to 1.17.5, which includes fixes for many bugs and crashes since current version. Also removed android.enableR8=false from gradle.properties because it's deprecated. And moved FEST_ASSERT_CORE_VERSION from gradle.properties to build.gradle because it's used in single line.
## Changelog
[Android] [Changed] - bump Okio to 1.17.5
Pull Request resolved: https://github.com/facebook/react-native/pull/30204
Test Plan: RNTester builds and runs as expected.
Reviewed By: hramos
Differential Revision: D24560711
Pulled By: fkgozali
fbshipit-source-id: 433075293ca2dc41869dbb272d674625639c8b83
Summary:
When working with RN installed from npm and a regular project structure `$rootDir` won't be at the react-native package root. Instead we can use `$projectRoot` which will always be the ReactAndroid folder.
## Changelog
[Android] [Internal] - Use $projectDir instead of $rootDir for ReactAndroid codegen
Pull Request resolved: https://github.com/facebook/react-native/pull/30220
Test Plan: Test building an app with RN as a regular dep with codegen enabled
Reviewed By: hramos
Differential Revision: D24560634
Pulled By: fkgozali
fbshipit-source-id: 434d32f37e6f9d48a8c562655ceff7249bd056ce
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:
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:
Fix a failure in running a single command to clean and rebuild with Hermes (e.g. `./gradlew clean :RNTester:android:app:installHermesDebug`).
From my limited understanding of Gradle, the failure was caused by the fact that the `clean` task could end up running after `prepareHermes`, and therefore delete the shared library after it had been copied. This change updates the `prepareHermes` task to impose the proper order.
In investigating this failure, I also updated inconsistent use of the `$thirdPartyNdkDir` variable.
Changelog: [Internal][Fixed] Fix a failure in running a single command to clean and rebuild ReactAndroid with Hermes
Reviewed By: mdvacca
Differential Revision: D23098220
fbshipit-source-id: 822fa8ac9874d54a3fdd432ad8cbee78295228ee
Summary:
This diff unifies the type and value of USE_FABRIC env variable exposed in Gradle with the USE_CODEGEN env variable
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23145658
fbshipit-source-id: 9575f6b50c7a977254e364037d1417b3b1cdb607
Summary:
JavaGenerator is a Java-based implementation for generating codegen output from the parsed schema file. Right now the output is a hardcoded Java file. In the next commits, proper JavaGenerator impl will be added.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23100171
fbshipit-source-id: 1bef23e3dba4d8c222ebdece0edeb4435d388cd4
Summary:
This diff adds a new mechanism to enable or disable the build of Fabric in RN OSS
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23084586
fbshipit-source-id: b7b0b842486392ec4ccb91ad1e6441ba3a1f48b2
Summary:
Instead of applying configs from gradle scripts, this introduces a proper Gradle plugin to enable Codegen in an application or library project. In the build.gradle, one enables it by:
```
plugins {
id("com.android.application")
id("com.facebook.react.codegen") // <---
}
// ...
react { // <--- the new plugin extension
enableCodegen = System.getenv("USE_CODEGEN")
jsRootDir = file("$rootDir/RNTester")
reactNativeRootDir = file("$rootDir")
}
```
The plugin supports `react` plugin extension as demonstrated above. Adding this:
* automatically generates all TurboModule Java files via react-native-codegen **before the `preBuild` Gradle task**
* automatically adds the files to the `android {}` project configuration
* is done per project (build.gradle)
This will be the foundation for future React Native gradle plugin beyond just for react-native-codegen.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23065685
fbshipit-source-id: 4ea67e48fab33b238c0973463cdb00de8cdadfcc
Summary:
This diff removes the ndk.moduleName configuration from build.gradle. This seems to be unnecessary
The motivation is to reduce confusion and extra configuration that is not being used by the build system
changelog: [internal] internal change to cleanup ndk configuration in gradle
Reviewed By: fkgozali
Differential Revision: D23068404
fbshipit-source-id: 07bb68906286531efaa9dc0036704c4b3ee1faf5
Summary:
Instead of sourcing-in a .gradle file to setup codegen tasks in Gradle, let's define a proper `com.facebook.react.codegen` Gradle plugin, so that any Gradle project (lib/app) can include it via:
```
plugins {
id 'com.facebook.react.codegen'
}
```
The idea (not yet implemented in this commit) is to then allow those projects to add this section in the projects:
```
codegen {
enableCodegen = ...
jsRootDir = ...
}
```
This is more scalable and less hacky.
Important notes:
* The Gradle plugin should be prepared during the build, we're not going to publish it to Maven or other repo at this point.
* This setup is inspired by composite build setup explained here: https://ncorti.com/blog/gradle-plugins-and-composite-builds
* All android specific setup is added under `packages/react-native-codegen/android/` dir, but long term, we may want to move it up to `packages/react-native-codegen/` along side setup for other platforms.
* As part of this setup, the plugin will have an option (to be validated) to produce Java specs using https://github.com/square/javapoet
* This is the same library already used for React Native Android annotation processors
* This generator will not deal with parsing Flow types into schema, it will just takes in the schema and produce Java code
* We're evaluating whether JavaPoet is a better choice for Java code generation long term, vs building it in JS via string concatenation: https://github.com/facebook/react-native/blob/master/packages/react-native-codegen/src/generators/modules/GenerateModuleJavaSpec.js
* This commit produces a sample Java code, not the actual codegen output
Changelog: [Internal]
To try this out, run this Gradle task:
```
USE_CODEGEN=1 ./gradlew :ReactAndroid:generateJava
```
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D22917315
fbshipit-source-id: 0b79dba939b73ff1305b4b4fd86ab897c7a48d53
Summary:
Introduced `architecture.gradle` that sets up pluggable build-time codegen steps for Gradle so that:
* Libraries, including core ReactAndroid, can produce the new architecture codegen (NativeModule **Java** specs in this diff) during build time
* Hosting app (e.g. RNTester) can produce its own set of codegen specs separately
**Please note that this is still work in progress, hence app templates have not been updated to use it yet.**
In order to activate this setup, the env variable `USE_CODEGEN=1` must be set. Eventually, this var will be removed from the logic.
With this change, RNTester:
* Will see all the generated specs populated in the Gradle build dir, which should be equivalent to the currently [**checked in version**](https://github.com/facebook/react-native/tree/master/ReactAndroid/src/main/java/com/facebook/fbreact/specs).
* The specs will compile, but **have not been validated** vs the existing NativeModule .java classes through out the core -- that will be the next step
* The specs are under `com.facebook.fbreact.specs.beta` namespace, which will be configurable in the future. `.beta` is added to avoid conflict with the existing files in the repo.
### Is this all we need to enable TurboModule in Android?
No. There are a few more pieces needed:
* C++ codegen output for JNI layer for each NativeModule spec
* The C++ module lookup for TurboModule Manager
* The JNI build setup in Gradle for these C++ output
* Toggle to enable TurboModule system in the entire app
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D22838581
fbshipit-source-id: d972e2fbb37bdbd3354e72b014fc8bb27a33b9ac
Summary:
This diff upgrades react-native-github Android to support API level 19+
changelog: [Android][Deprecated] Deprecate support of Android API levels 16 to 18. The new minSDK version will be 19+ moving forward
Reviewed By: JoshuaGross
Differential Revision: D22734208
fbshipit-source-id: b052721c8cfb44f8d74cf4bbb5b7a769e544d1d9
Summary:
This Pull Request implements the PlatformColor proposal discussed at https://github.com/react-native-community/discussions-and-proposals/issues/126. The changes include implementations for iOS and Android as well as a PlatformColorExample page in RNTester.
Every native platform has the concept of system defined colors. Instead of specifying a concrete color value the app developer can choose a system color that varies in appearance depending on a system theme settings such Light or Dark mode, accessibility settings such as a High Contrast mode, and even its context within the app such as the traits of a containing view or window.
The proposal is to add true platform color support to react-native by extending the Flow type `ColorValue` with platform specific color type information for each platform and to provide a convenience function, `PlatformColor()`, for instantiating platform specific ColorValue objects.
`PlatformColor(name [, name ...])` where `name` is a system color name on a given platform. If `name` does not resolve to a color for any reason, the next `name` in the argument list will be resolved and so on. If none of the names resolve, a RedBox error occurs. This allows a latest platform color to be used, but if running on an older platform it will fallback to a previous version.
The function returns a `ColorValue`.
On iOS the values of `name` is one of the iOS [UI Element](https://developer.apple.com/documentation/uikit/uicolor/ui_element_colors) or [Standard Color](https://developer.apple.com/documentation/uikit/uicolor/standard_colors) names such as `labelColor` or `systemFillColor`.
On Android the `name` values are the same [app resource](https://developer.android.com/guide/topics/resources/providing-resources) path strings that can be expressed in XML:
XML Resource:
`@ [<package_name>:]<resource_type>/<resource_name>`
Style reference from current theme:
`?[<package_name>:][<resource_type>/]<resource_name>`
For example:
- `?android:colorError`
- `?android:attr/colorError`
- `?attr/colorPrimary`
- `?colorPrimaryDark`
- `android:color/holo_purple`
- `color/catalyst_redbox_background`
On iOS another type of system dynamic color can be created using the `IOSDynamicColor({dark: <color>, light:<color>})` method. The arguments are a tuple containing custom colors for light and dark themes. Such dynamic colors are useful for branding colors or other app specific colors that still respond automatically to system setting changes.
Example: `<View style={{ backgroundColor: IOSDynamicColor({light: 'black', dark: 'white'}) }}/>`
Other platforms could create platform specific functions similar to `IOSDynamicColor` per the needs of those platforms. For example, macOS has a similar dynamic color type that could be implemented via a `MacDynamicColor`. On Windows custom brushes that tint or otherwise modify a system brush could be created using a platform specific method.
## Changelog
[General] [Added] - Added PlatformColor implementations for iOS and Android
Pull Request resolved: https://github.com/facebook/react-native/pull/27908
Test Plan:
The changes have been tested using the RNTester test app for iOS and Android. On iOS a set of XCTestCase's were added to the Unit Tests.
<img width="924" alt="PlatformColor-ios-android" src="https://user-images.githubusercontent.com/30053638/73472497-ff183a80-433f-11ea-90d8-2b04338bbe79.png">
In addition `PlatformColor` support has been added to other out-of-tree platforms such as macOS and Windows has been implemented using these changes:
react-native for macOS branch: https://github.com/microsoft/react-native/compare/master...tom-un:tomun/platformcolors
react-native for Windows branch: https://github.com/microsoft/react-native-windows/compare/master...tom-un:tomun/platformcolors
iOS
|Light|Dark|
|{F229354502}|{F229354515}|
Android
|Light|Dark|
|{F230114392}|{F230114490}|
{F230122700}
Reviewed By: hramos
Differential Revision: D19837753
Pulled By: TheSavior
fbshipit-source-id: 82ca70d40802f3b24591bfd4b94b61f3c38ba829
Summary:
This is an incomplete effort to migrate from libfb to libfbjni. This is needed to restore the compatibility with Flipper and other FB Android projects that make use of FBJNI. Effectively, the outcome is that `fbjni` no longer has a checked-in copy here, but instead relies on the public artifacts published at github.com/facebookincubator/fbjni that can be deduplicated at build-time.
**A non-exhaustive list of tasks:**
* [X] Gradle builds the SDK and RNTester for Android.
* [X] Buck build for rntester works in OSS.
* [ ] Move from `java-only` release to full `fbjni` release. This requires finding a solution for stripping out `.so` files that the old `Android.mk` insists on including in the final artifacts and will clash with the full distribution.
* [ ] Import this and fix potential internal build issues.
* [ ] Verify that the changes made to the Hermes integration don't have any unintended consequences.
## Changelog
[Android] [Changed] - Migrated from libfb to libfbjni for JNI calls
Pull Request resolved: https://github.com/facebook/react-native/pull/27729
Test Plan:
- CI is already passing again for Gradle and Buck in OSS.
- After applying the following patch, RNTester builds and works with the latest Flipper SDK:
```
diff --git a/RNTester/android/app/build.gradle b/RNTester/android/app/build.gradle
index b8a6437d7..eac942104 100644
--- a/RNTester/android/app/build.gradle
+++ b/RNTester/android/app/build.gradle
@@ -170,10 +170,19 @@ dependencies {
debugImplementation files(hermesPath + "hermes-debug.aar")
releaseImplementation files(hermesPath + "hermes-release.aar")
- debugImplementation("com.facebook.flipper:flipper:0.23.4") {
+ debugImplementation("com.facebook.flipper🐬+") {
exclude group:'com.facebook.yoga'
- exclude group:'com.facebook.flipper', module: 'fbjni'
- exclude group:'com.facebook.litho', module: 'litho-annotations'
+ exclude group:'com.facebook.fbjni'
+ }
+
+ debugImplementation("com.facebook.flipper:flipper-network-plugin:+") {
+ exclude group:'com.facebook.yoga'
+ exclude group:'com.facebook.fbjni'
+ }
+
+ debugImplementation("com.facebook.flipper:flipper-fresco-plugin:+") {
+ exclude group:'com.facebook.yoga'
+ exclude group:'com.facebook.fbjni'
}
if (useIntlJsc) {
```
Reviewed By: mdvacca
Differential Revision: D19345270
Pulled By: passy
fbshipit-source-id: 33811e7f97f44f2ec5999e1c35339909dc4fd3b1
Summary:
The Gradle build file looks up jsc-android and hermes-engine using hard-coded paths. Rather than assuming the location of these packages, which are distributed and installed as npm packages, this commit makes the Gradle file use Node's standard module resolution algorithm. It looks up the file hierarchy until it finds a matching npm package or reaches the root directory.
## Changelog:
[Android] [Changed] - ReactAndroid's Gradle file uses Node's module resolution algorithm to find JSC & Hermes
Pull Request resolved: https://github.com/facebook/react-native/pull/26773
Test Plan: Ensure that CI tests pass, and that `./gradlew :ReactAndroid:installArchives` works. Printed out the paths that the Gradle script found for jsc-android and hermes-engine (both were `<my stuff>/react-native/node_modules/jsc-android|hermes-engine`).
Differential Revision: D17903179
Pulled By: cpojer
fbshipit-source-id: 9ac3ba509974f39f87b511d5bc3398451c12393f
Summary:
This PR is extracts and reuses ANDROIDX_TEST_VERSION, and is part of Gradle script refactoring effort.
## Changelog
[Android] [Changed] - extract and reuse ANDROIDX_TEST_VERSION
Pull Request resolved: https://github.com/facebook/react-native/pull/26487
Differential Revision: D17488766
Pulled By: mdvacca
fbshipit-source-id: f1968ffc403074d78d792eb5cc773cc6366ad2d1
Summary:
Reland https://github.com/facebook/react-native/pull/24767
The commit had to be reverted because it caused a crash when using remote debugging in chrome. This is normal since jsi is not available in that environment. The crash was caused by `jsContext.get()` being 0, then being dereferenced later in c++. We can simply skip initializing the blob collector in this case.
This also includes the fix from https://github.com/facebook/react-native/issues/25720 to fix a crash when using hermes.
## Changelog
[Android] [Fixed] - Release underlying resources when JS instance is GC'ed on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/26155
Test Plan:
Test using RN tester with jsc and hermes
Test remote debugging
Reviewed By: mdvacca, fred2028
Differential Revision: D17072644
Pulled By: makovkastar
fbshipit-source-id: 079d1d43501e854297fbbe586ba229920c892584
Jason Safaiyeh
Tim Yung
Janic Duplessis
Andrei Shikov
Kudo Chien
Dulmandakh
Araz Abishov
Joshua Gross
Ivan Kobzarev
Héctor Ramos
David Vacca
Agastya Darma
Kevin Gozali
Keion Anvaripour
Neil Dhar
Joshua Selbo
Tom Underhill
Pascal Hartig
Andres Suarez
James Ide
