react-native-macos/ReactAndroid/build.gradle

459 строки
18 KiB
Groovy
Исходник Обычный вид История

/*
* Copyright (c) Meta Platforms, Inc. and affiliates.
*
* This source code is licensed under the MIT license found in the
* LICENSE file in the root directory of this source tree.
*/
2015-09-16 20:38:42 +03:00
plugins {
id("com.android.library")
id("com.facebook.react")
id("maven-publish")
id("de.undercouch.download")
}
2015-09-16 20:38:42 +03:00
import com.facebook.react.tasks.internal.*
import java.nio.file.Paths
2015-09-16 20:38:42 +03:00
import de.undercouch.gradle.tasks.download.Download
import org.apache.tools.ant.taskdefs.condition.Os
import org.apache.tools.ant.filters.ReplaceTokens
def AAR_OUTPUT_URL = "file://${projectDir}/../android"
2015-09-16 20:38:42 +03:00
// We download various C++ open-source dependencies into downloads.
// We then copy both the downloaded code and our custom makefiles and headers into third-party-ndk.
// After that we build native code from src/main/jni with module path pointing at third-party-ndk.
2015-09-16 20:38:42 +03:00
def customDownloadsDir = System.getenv("REACT_NATIVE_DOWNLOADS_DIR")
def downloadsDir = customDownloadsDir ? new File(customDownloadsDir) : new File("$buildDir/downloads")
2015-09-16 20:38:42 +03:00
def thirdPartyNdkDir = new File("$buildDir/third-party-ndk")
// You need to have following folders in this directory:
// - boost_1_63_0
// - double-conversion-1.1.6
// - folly-deprecate-dynamic-initializer
// - glog-0.3.5
def dependenciesPath = System.getenv("REACT_NATIVE_DEPENDENCIES")
// The Boost library is a very large download (>100MB).
// If Boost is already present on your system, define the REACT_NATIVE_BOOST_PATH env variable
// and the build will use that.
def boostPath = dependenciesPath ?: System.getenv("REACT_NATIVE_BOOST_PATH")
// Setup build type for NDK, supported values: {debug, release}
def nativeBuildType = System.getenv("NATIVE_BUILD_TYPE") ?: "release"
2015-09-16 20:38:42 +03:00
task createNativeDepsDirectories {
downloadsDir.mkdirs()
thirdPartyNdkDir.mkdirs()
}
task downloadBoost(dependsOn: createNativeDepsDirectories, type: Download) {
src("https://github.com/react-native-community/boost-for-react-native/releases/download/v${BOOST_VERSION.replace("_", ".")}-0/boost_${BOOST_VERSION}.tar.gz")
onlyIfNewer(true)
overwrite(false)
dest(new File(downloadsDir, "boost_${BOOST_VERSION}.tar.gz"))
2015-09-16 20:38:42 +03:00
}
final def prepareBoost = tasks.register("prepareBoost", PrepareBoostTask) {
it.dependsOn(boostPath ? [] : [downloadBoost])
it.boostPath.setFrom(boostPath ?: tarTree(resources.gzip(downloadBoost.dest)))
it.boostVersion.set(BOOST_VERSION)
it.outputDir.set(new File(thirdPartyNdkDir, "boost"))
2015-09-16 20:38:42 +03:00
}
task downloadDoubleConversion(dependsOn: createNativeDepsDirectories, type: Download) {
src("https://github.com/google/double-conversion/archive/v${DOUBLE_CONVERSION_VERSION}.tar.gz")
onlyIfNewer(true)
overwrite(false)
dest(new File(downloadsDir, "double-conversion-${DOUBLE_CONVERSION_VERSION}.tar.gz"))
2015-09-16 20:38:42 +03:00
}
task prepareDoubleConversion(dependsOn: dependenciesPath ? [] : [downloadDoubleConversion], type: Copy) {
from(dependenciesPath ?: tarTree(downloadDoubleConversion.dest))
from("src/main/jni/third-party/double-conversion/Android.mk")
include("double-conversion-${DOUBLE_CONVERSION_VERSION}/src/**/*", "Android.mk")
filesMatching("*/src/**/*", { fname -> fname.path = "double-conversion/${fname.name}" })
2015-09-16 20:38:42 +03:00
includeEmptyDirs = false
into("$thirdPartyNdkDir/double-conversion")
2015-09-16 20:38:42 +03:00
}
task downloadFolly(dependsOn: createNativeDepsDirectories, type: Download) {
src("https://github.com/facebook/folly/archive/v${FOLLY_VERSION}.tar.gz")
onlyIfNewer(true)
overwrite(false)
dest(new File(downloadsDir, "folly-${FOLLY_VERSION}.tar.gz"))
2015-09-16 20:38:42 +03:00
}
task prepareFolly(dependsOn: dependenciesPath ? [] : [downloadFolly], type: Copy) {
from(dependenciesPath ?: tarTree(downloadFolly.dest))
from("src/main/jni/third-party/folly/Android.mk")
include("folly-${FOLLY_VERSION}/folly/**/*", "Android.mk")
eachFile { fname -> fname.path = (fname.path - "folly-${FOLLY_VERSION}/") }
2015-09-16 20:38:42 +03:00
includeEmptyDirs = false
into("$thirdPartyNdkDir/folly")
2015-09-16 20:38:42 +03:00
}
task downloadFmt(dependsOn: createNativeDepsDirectories, type: Download) {
src("https://github.com/fmtlib/fmt/archive/${FMT_VERSION}.tar.gz")
onlyIfNewer(true)
overwrite(false)
dest(new File(downloadsDir, "fmt-${FMT_VERSION}.tar.gz"))
}
task prepareFmt(dependsOn: dependenciesPath ? [] : [downloadFmt], type: Copy) {
from(dependenciesPath ?: tarTree(downloadFmt.dest))
from("src/main/jni/third-party/fmt/Android.mk")
include("fmt-${FMT_VERSION}/src/**/*", "fmt-${FMT_VERSION}/include/**/*", "Android.mk")
eachFile { fname -> fname.path = (fname.path - "fmt-${FMT_VERSION}/") }
includeEmptyDirs = false
into("$thirdPartyNdkDir/fmt")
}
task downloadLibevent(dependsOn: createNativeDepsDirectories, type: Download) {
src("https://github.com/libevent/libevent/releases/download/release-${LIBEVENT_VERSION}-stable/libevent-${LIBEVENT_VERSION}-stable.tar.gz")
onlyIfNewer(true)
overwrite(false)
dest(new File(downloadsDir, "libevent-${LIBEVENT_VERSION}.tar.gz"))
}
final def prepareLibevent = tasks.register("prepareLibevent", PrepareLibeventTask) {
it.dependsOn(dependenciesPath ? [] : [downloadLibevent])
it.libeventPath.setFrom(dependenciesPath ?: tarTree(downloadLibevent.dest))
it.libeventVersion.set(LIBEVENT_VERSION)
it.outputDir.set(new File(thirdPartyNdkDir, "libevent"))
}
task prepareHermes(dependsOn: createNativeDepsDirectories, type: Copy) {
def hermesPackagePath = findNodeModulePath(projectDir, "hermes-engine")
if (!hermesPackagePath) {
throw new GradleScriptException("Could not find the hermes-engine npm package", null)
}
def hermesAAR = file("$hermesPackagePath/android/hermes-debug.aar")
if (!hermesAAR.exists()) {
throw new GradleScriptException("The hermes-engine npm package is missing \"android/hermes-debug.aar\"", null)
}
def soFiles = zipTree(hermesAAR).matching({ it.include "**/*.so" })
from soFiles
from "src/main/jni/first-party/hermes/Android.mk"
into "$thirdPartyNdkDir/hermes"
}
2015-09-16 20:38:42 +03:00
task downloadGlog(dependsOn: createNativeDepsDirectories, type: Download) {
src("https://github.com/google/glog/archive/v${GLOG_VERSION}.tar.gz")
onlyIfNewer(true)
overwrite(false)
dest(new File(downloadsDir, "glog-${GLOG_VERSION}.tar.gz"))
2015-09-16 20:38:42 +03:00
}
// Prepare glog sources to be compiled, this task will perform steps that normally should've been
2015-09-16 20:38:42 +03:00
// executed by automake. This way we can avoid dependencies on make/automake
final def prepareGlog = tasks.register("prepareGlog", PrepareGlogTask) {
it.dependsOn(dependenciesPath ? [] : [downloadGlog])
it.glogPath.setFrom(dependenciesPath ?: tarTree(downloadGlog.dest))
it.glogVersion.set(GLOG_VERSION)
it.outputDir.set(new File(thirdPartyNdkDir, "glog"))
2015-09-16 20:38:42 +03:00
}
// Create Android.mk library module based on jsc from npm
tasks.register('prepareJSC', PrepareJSCTask) {
it.jscPackagePath.set(findNodeModulePath(projectDir, "jsc-android"))
it.outputDir = project.layout.buildDirectory.dir("third-party-ndk/jsc")
2015-09-16 20:38:42 +03:00
}
task downloadNdkBuildDependencies {
if (!boostPath) {
dependsOn(downloadBoost)
}
dependsOn(downloadDoubleConversion)
dependsOn(downloadFolly)
dependsOn(downloadGlog)
dependsOn(downloadFmt)
dependsOn(downloadLibevent)
}
/**
* Finds the path of the installed npm package with the given name using Node's
* module resolution algorithm, which searches "node_modules" directories up to
* the file system root. This handles various cases, including:
*
* - Working in the open-source RN repo:
* Gradle: /path/to/react-native/ReactAndroid
* Node module: /path/to/react-native/node_modules/[package]
*
* - Installing RN as a dependency of an app and searching for hoisted
* dependencies:
* Gradle: /path/to/app/node_modules/react-native/ReactAndroid
* Node module: /path/to/app/node_modules/[package]
*
* - Working in a larger repo (e.g., Facebook) that contains RN:
* Gradle: /path/to/repo/path/to/react-native/ReactAndroid
* Node module: /path/to/repo/node_modules/[package]
*
* The search begins at the given base directory (a File object). The returned
* path is a string.
*/
def findNodeModulePath(baseDir, packageName) {
def basePath = baseDir.toPath().normalize()
// Node's module resolution algorithm searches up to the root directory,
// after which the base path will be null
while (basePath) {
def candidatePath = Paths.get(basePath.toString(), "node_modules", packageName)
if (candidatePath.toFile().exists()) {
return candidatePath.toString()
}
basePath = basePath.getParent()
}
return null
}
2015-09-16 20:38:42 +03:00
def reactNativeDevServerPort() {
def value = project.getProperties().get("reactNativeDevServerPort")
return value != null ? value : "8081"
}
def reactNativeInspectorProxyPort() {
def value = project.getProperties().get("reactNativeInspectorProxyPort")
return value != null ? value : reactNativeDevServerPort()
}
Allow configuring ndk build architectures (#31232) 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
2021-07-12 19:51:14 +03:00
def reactNativeArchitectures() {
def value = project.getProperties().get("reactNativeArchitectures")
return value ? value.split(",") : ["armeabi-v7a", "x86", "x86_64", "arm64-v8a"]
Allow configuring ndk build architectures (#31232) 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
2021-07-12 19:51:14 +03:00
}
Update ReactAndroid to use the AGP NDK Apis (#32443) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/32443 This diff removes all the custom Gradle machinery to build the native code and delegates to AGP the triggering of the `ndk-build` command. This means that the native build will be now invoked with the `:ReactAndroid:externalNativeBuild<Variant>` task. An important thing to notice is that that task will always run, and will delegate to Make the compilation avoidance. If you invoke the task twice, the second time it will be significantly faster. On my machine this takes ~6/7 mins the first time, and 30 seconds the second time. There are some gotchas that are worth noting: * The native build will run on every build now. Given the complexity of our native build graph, even with an up-to-date build, Make will still take ~30 seconds on my machine to analyse all the targets and mention that there is no work to be done. I believe this could be impactful for local development experience. The mitigation I found was to apply an `abiFilter` to build only the ABI of the target device (e.g. arm64 for a real device and so on). This reduces the native build to ~10 seconds. * All the change to the `react-native-gradle-plugin` source will cause the Gradle tasks to be considered invalid. Therefore they will re-extract the header files inside the folders that are used by Make to compile, triggering a near-full rebuild. This can be a bit painful when building locally, if you plan to edit react-native-gradle-plugin and relaunch rn-tester (seems to be like an edge case scenario but worth pointing out). The mitigation here would be to invoke the tasks like ``` gw :packages:rn-tester:android:app:installHermesDebug -x prepareBoost -x prepareLibevent -x prepareGlog \ -x prepareJSC -x extractNativeDependencies -x generateCodegenArtifactsFromSchema \ -x generateCodegenSchemaFromJavaScript ``` Changelog: [Internal] [Changed] - Refactor Extract Headers and JNI from AARs to an internal task Reviewed By: ShikaSD Differential Revision: D31683721 fbshipit-source-id: fa85793c567796f4e04751e10503717a88cb0620
2021-11-01 15:56:47 +03:00
def ndkBuildJobs() {
return project.findProperty("jobs") ?: Runtime.runtime.availableProcessors()
2015-09-16 20:38:42 +03:00
}
tasks.register("packageReactNdkLibsForBuck") {
dependsOn("packageReactNdkDebugLibsForBuck")
}
tasks.register("packageReactNdkDebugLibsForBuck", Copy) {
Update ReactAndroid to use the AGP NDK Apis (#32443) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/32443 This diff removes all the custom Gradle machinery to build the native code and delegates to AGP the triggering of the `ndk-build` command. This means that the native build will be now invoked with the `:ReactAndroid:externalNativeBuild<Variant>` task. An important thing to notice is that that task will always run, and will delegate to Make the compilation avoidance. If you invoke the task twice, the second time it will be significantly faster. On my machine this takes ~6/7 mins the first time, and 30 seconds the second time. There are some gotchas that are worth noting: * The native build will run on every build now. Given the complexity of our native build graph, even with an up-to-date build, Make will still take ~30 seconds on my machine to analyse all the targets and mention that there is no work to be done. I believe this could be impactful for local development experience. The mitigation I found was to apply an `abiFilter` to build only the ABI of the target device (e.g. arm64 for a real device and so on). This reduces the native build to ~10 seconds. * All the change to the `react-native-gradle-plugin` source will cause the Gradle tasks to be considered invalid. Therefore they will re-extract the header files inside the folders that are used by Make to compile, triggering a near-full rebuild. This can be a bit painful when building locally, if you plan to edit react-native-gradle-plugin and relaunch rn-tester (seems to be like an edge case scenario but worth pointing out). The mitigation here would be to invoke the tasks like ``` gw :packages:rn-tester:android:app:installHermesDebug -x prepareBoost -x prepareLibevent -x prepareGlog \ -x prepareJSC -x extractNativeDependencies -x generateCodegenArtifactsFromSchema \ -x generateCodegenSchemaFromJavaScript ``` Changelog: [Internal] [Changed] - Refactor Extract Headers and JNI from AARs to an internal task Reviewed By: ShikaSD Differential Revision: D31683721 fbshipit-source-id: fa85793c567796f4e04751e10503717a88cb0620
2021-11-01 15:56:47 +03:00
dependsOn("mergeDebugNativeLibs")
// Shared libraries (.so) are copied from the merged_native_libs folder instead
Update ReactAndroid to use the AGP NDK Apis (#32443) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/32443 This diff removes all the custom Gradle machinery to build the native code and delegates to AGP the triggering of the `ndk-build` command. This means that the native build will be now invoked with the `:ReactAndroid:externalNativeBuild<Variant>` task. An important thing to notice is that that task will always run, and will delegate to Make the compilation avoidance. If you invoke the task twice, the second time it will be significantly faster. On my machine this takes ~6/7 mins the first time, and 30 seconds the second time. There are some gotchas that are worth noting: * The native build will run on every build now. Given the complexity of our native build graph, even with an up-to-date build, Make will still take ~30 seconds on my machine to analyse all the targets and mention that there is no work to be done. I believe this could be impactful for local development experience. The mitigation I found was to apply an `abiFilter` to build only the ABI of the target device (e.g. arm64 for a real device and so on). This reduces the native build to ~10 seconds. * All the change to the `react-native-gradle-plugin` source will cause the Gradle tasks to be considered invalid. Therefore they will re-extract the header files inside the folders that are used by Make to compile, triggering a near-full rebuild. This can be a bit painful when building locally, if you plan to edit react-native-gradle-plugin and relaunch rn-tester (seems to be like an edge case scenario but worth pointing out). The mitigation here would be to invoke the tasks like ``` gw :packages:rn-tester:android:app:installHermesDebug -x prepareBoost -x prepareLibevent -x prepareGlog \ -x prepareJSC -x extractNativeDependencies -x generateCodegenArtifactsFromSchema \ -x generateCodegenSchemaFromJavaScript ``` Changelog: [Internal] [Changed] - Refactor Extract Headers and JNI from AARs to an internal task Reviewed By: ShikaSD Differential Revision: D31683721 fbshipit-source-id: fa85793c567796f4e04751e10503717a88cb0620
2021-11-01 15:56:47 +03:00
from("$buildDir/intermediates/merged_native_libs/debug/out/lib/")
exclude("**/libjsc.so")
exclude("**/libhermes.so")
into("src/main/jni/prebuilt/lib")
}
tasks.register("packageReactNdkReleaseLibsForBuck", Copy) {
dependsOn("mergeReleaseNativeLibs")
// Shared libraries (.so) are copied from the merged_native_libs folder instead
from("$buildDir/intermediates/merged_native_libs/release/out/lib/")
exclude("**/libjsc.so")
exclude("**/libhermes.so")
into("src/main/jni/prebuilt/lib")
}
final def extractNativeDependencies = tasks.register('extractNativeDependencies', ExtractJniAndHeadersTask) {
it.extractHeadersConfiguration.setFrom(configurations.extractHeaders)
it.extractJniConfiguration.setFrom(configurations.extractJNI)
it.baseOutputDir = project.file("src/main/jni/first-party/")
// Sadly this task as an output folder path that is directly dependent on
// the task input (i.e. src/main/jni/first-party/<package-name>/...
// This means that this task is using the parent folder (first-party/) as
// @OutputFolder. The `prepareHermes` task will also output inside that
// folder and if the two tasks happen to be inside the same run, we want
// `extractNativeDependencies` to run after `prepareHermes` to do not
// invalidate the input/output calculation for this task.
it.mustRunAfter(prepareHermes)
Migrate to FBJNI (#27729) 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: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
2020-01-21 13:30:57 +03:00
}
task installArchives {
dependsOn("publishReleasePublicationToNpmRepository")
}
2015-09-16 20:38:42 +03:00
android {
compileSdkVersion 31
// Used to override the NDK path & version on internal CI
if (System.getenv("ANDROID_NDK") != null && System.getenv("LOCAL_ANDROID_NDK_VERSION") != null) {
ndkPath System.getenv("ANDROID_NDK")
ndkVersion System.getenv("LOCAL_ANDROID_NDK_VERSION")
}
2015-09-16 20:38:42 +03:00
defaultConfig {
minSdkVersion(21)
targetSdkVersion(31)
versionCode(1)
versionName("1.0")
2015-09-16 20:38:42 +03:00
consumerProguardFiles("proguard-rules.pro")
Inline and fix proguard rules Summary: The original proguard rules are put in the template, which is not very convenient and easy to get wrong. Because new rules get put, people also has two copy paste the rule. And there are also existing project import react native as a dependency. So the best way to keep a android library project proguard rule is to manage the rule itself, using `consumerProguardFiles` like [dagger](https://github.com/JakeWharton/butterknife/blob/46baef6d96e93a1872efa17fdfc1d2af59b36f0c/butterknife/build.gradle#L9) and other android library project. <!-- Required: Write your motivation here. If this PR fixes an issue, type "Fixes #issueNumber" to automatically close the issue when the PR is merged. --> Use RNTester to build the release flavor (now it has bugs https://github.com/facebook/react-native/issues/18460, I keep my change in local for now), after build success, run to check if crash. In the process, I also fix https://github.com/facebook/react-native/issues/12994 and https://github.com/facebook/react-native/issues/6624 by adding the following to proguard rules ```proguard -keep,includedescriptorclasses class com.facebook.react.bridge.** { *; } ``` <!-- Does this PR require a documentation change? Create a PR at https://github.com/facebook/react-native-website and add a link to it here. --> [ANDROID] [ENHANCEMENT and BUGFIX] [Proguard rules] - inline and fix proguard rules . <!-- **INTERNAL and MINOR tagged notes will not be included in the next version's final release notes.** CATEGORY [----------] TYPE [ CLI ] [-------------] LOCATION [ DOCS ] [ BREAKING ] [-------------] [ GENERAL ] [ BUGFIX ] [ {Component} ] [ INTERNAL ] [ ENHANCEMENT ] [ {Filename} ] [ IOS ] [ FEATURE ] [ {Directory} ] |-----------| [ ANDROID ] [ MINOR ] [ {Framework} ] - | {Message} | [----------] [-------------] [-------------] |-----------| EXAMPLES: [IOS] [BREAKING] [FlatList] - Change a thing that breaks other things [ANDROID] [BUGFIX] [TextInput] - Did a thing to TextInput [CLI] [FEATURE] [local-cli/info/info.js] - CLI easier to do things with [DOCS] [BUGFIX] [GettingStarted.md] - Accidentally a thing/word [GENERAL] [ENHANCEMENT] [Yoga] - Added new yoga thing/position [INTERNAL] [FEATURE] [./scripts] - Added thing to script that nobody will see --> Closes https://github.com/facebook/react-native/pull/18461 Differential Revision: D7527533 Pulled By: hramos fbshipit-source-id: 447dbc16983bcfb597187b40c1be3987a8c5a832
2018-04-06 03:26:39 +03:00
buildConfigField("boolean", "IS_INTERNAL_BUILD", "false")
buildConfigField("int", "EXOPACKAGE_FLAGS", "0")
buildConfigField("int", "HERMES_BYTECODE_VERSION", "0")
resValue "integer", "react_native_dev_server_port", reactNativeDevServerPort()
resValue "integer", "react_native_inspector_proxy_port", reactNativeInspectorProxyPort()
testApplicationId("com.facebook.react.tests.gradle")
testInstrumentationRunner("androidx.test.runner.AndroidJUnitRunner")
Update ReactAndroid to use the AGP NDK Apis (#32443) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/32443 This diff removes all the custom Gradle machinery to build the native code and delegates to AGP the triggering of the `ndk-build` command. This means that the native build will be now invoked with the `:ReactAndroid:externalNativeBuild<Variant>` task. An important thing to notice is that that task will always run, and will delegate to Make the compilation avoidance. If you invoke the task twice, the second time it will be significantly faster. On my machine this takes ~6/7 mins the first time, and 30 seconds the second time. There are some gotchas that are worth noting: * The native build will run on every build now. Given the complexity of our native build graph, even with an up-to-date build, Make will still take ~30 seconds on my machine to analyse all the targets and mention that there is no work to be done. I believe this could be impactful for local development experience. The mitigation I found was to apply an `abiFilter` to build only the ABI of the target device (e.g. arm64 for a real device and so on). This reduces the native build to ~10 seconds. * All the change to the `react-native-gradle-plugin` source will cause the Gradle tasks to be considered invalid. Therefore they will re-extract the header files inside the folders that are used by Make to compile, triggering a near-full rebuild. This can be a bit painful when building locally, if you plan to edit react-native-gradle-plugin and relaunch rn-tester (seems to be like an edge case scenario but worth pointing out). The mitigation here would be to invoke the tasks like ``` gw :packages:rn-tester:android:app:installHermesDebug -x prepareBoost -x prepareLibevent -x prepareGlog \ -x prepareJSC -x extractNativeDependencies -x generateCodegenArtifactsFromSchema \ -x generateCodegenSchemaFromJavaScript ``` Changelog: [Internal] [Changed] - Refactor Extract Headers and JNI from AARs to an internal task Reviewed By: ShikaSD Differential Revision: D31683721 fbshipit-source-id: fa85793c567796f4e04751e10503717a88cb0620
2021-11-01 15:56:47 +03:00
externalNativeBuild {
ndkBuild {
arguments "NDK_APPLICATION_MK=$projectDir/src/main/jni/Application.mk",
Update ReactAndroid to use the AGP NDK Apis (#32443) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/32443 This diff removes all the custom Gradle machinery to build the native code and delegates to AGP the triggering of the `ndk-build` command. This means that the native build will be now invoked with the `:ReactAndroid:externalNativeBuild<Variant>` task. An important thing to notice is that that task will always run, and will delegate to Make the compilation avoidance. If you invoke the task twice, the second time it will be significantly faster. On my machine this takes ~6/7 mins the first time, and 30 seconds the second time. There are some gotchas that are worth noting: * The native build will run on every build now. Given the complexity of our native build graph, even with an up-to-date build, Make will still take ~30 seconds on my machine to analyse all the targets and mention that there is no work to be done. I believe this could be impactful for local development experience. The mitigation I found was to apply an `abiFilter` to build only the ABI of the target device (e.g. arm64 for a real device and so on). This reduces the native build to ~10 seconds. * All the change to the `react-native-gradle-plugin` source will cause the Gradle tasks to be considered invalid. Therefore they will re-extract the header files inside the folders that are used by Make to compile, triggering a near-full rebuild. This can be a bit painful when building locally, if you plan to edit react-native-gradle-plugin and relaunch rn-tester (seems to be like an edge case scenario but worth pointing out). The mitigation here would be to invoke the tasks like ``` gw :packages:rn-tester:android:app:installHermesDebug -x prepareBoost -x prepareLibevent -x prepareGlog \ -x prepareJSC -x extractNativeDependencies -x generateCodegenArtifactsFromSchema \ -x generateCodegenSchemaFromJavaScript ``` Changelog: [Internal] [Changed] - Refactor Extract Headers and JNI from AARs to an internal task Reviewed By: ShikaSD Differential Revision: D31683721 fbshipit-source-id: fa85793c567796f4e04751e10503717a88cb0620
2021-11-01 15:56:47 +03:00
"THIRD_PARTY_NDK_DIR=$thirdPartyNdkDir",
"REACT_COMMON_DIR=$projectDir/../ReactCommon",
"REACT_GENERATED_SRC_DIR=$buildDir/generated/source",
"REACT_SRC_DIR=$projectDir/src/main/java/com/facebook/react",
"-j${ndkBuildJobs()}"
if (Os.isFamily(Os.FAMILY_MAC)) {
// This flag will suppress "fcntl(): Bad file descriptor" warnings on local builds.
arguments "--output-sync=none"
}
}
}
ndk {
abiFilters (*reactNativeArchitectures())
}
2015-09-16 20:38:42 +03:00
}
Update ReactAndroid to use the AGP NDK Apis (#32443) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/32443 This diff removes all the custom Gradle machinery to build the native code and delegates to AGP the triggering of the `ndk-build` command. This means that the native build will be now invoked with the `:ReactAndroid:externalNativeBuild<Variant>` task. An important thing to notice is that that task will always run, and will delegate to Make the compilation avoidance. If you invoke the task twice, the second time it will be significantly faster. On my machine this takes ~6/7 mins the first time, and 30 seconds the second time. There are some gotchas that are worth noting: * The native build will run on every build now. Given the complexity of our native build graph, even with an up-to-date build, Make will still take ~30 seconds on my machine to analyse all the targets and mention that there is no work to be done. I believe this could be impactful for local development experience. The mitigation I found was to apply an `abiFilter` to build only the ABI of the target device (e.g. arm64 for a real device and so on). This reduces the native build to ~10 seconds. * All the change to the `react-native-gradle-plugin` source will cause the Gradle tasks to be considered invalid. Therefore they will re-extract the header files inside the folders that are used by Make to compile, triggering a near-full rebuild. This can be a bit painful when building locally, if you plan to edit react-native-gradle-plugin and relaunch rn-tester (seems to be like an edge case scenario but worth pointing out). The mitigation here would be to invoke the tasks like ``` gw :packages:rn-tester:android:app:installHermesDebug -x prepareBoost -x prepareLibevent -x prepareGlog \ -x prepareJSC -x extractNativeDependencies -x generateCodegenArtifactsFromSchema \ -x generateCodegenSchemaFromJavaScript ``` Changelog: [Internal] [Changed] - Refactor Extract Headers and JNI from AARs to an internal task Reviewed By: ShikaSD Differential Revision: D31683721 fbshipit-source-id: fa85793c567796f4e04751e10503717a88cb0620
2021-11-01 15:56:47 +03:00
externalNativeBuild {
ndkBuild {
path "src/main/jni/react/jni/Android.mk"
}
}
preBuild.dependsOn(prepareJSC, prepareHermes, prepareBoost, prepareDoubleConversion, prepareFmt, prepareFolly, prepareGlog, prepareLibevent, extractNativeDependencies)
preBuild.dependsOn("generateCodegenArtifactsFromSchema")
2015-09-16 20:38:42 +03:00
sourceSets.main {
jni.srcDirs = []
res.srcDirs = ["src/main/res/devsupport", "src/main/res/shell", "src/main/res/views/modal", "src/main/res/views/uimanager"]
java {
srcDirs = ["src/main/java", "src/main/libraries/soloader/java", "src/main/jni/first-party/fb/jni/java"]
exclude("com/facebook/react/processing")
exclude("com/facebook/react/module/processing")
}
2015-09-16 20:38:42 +03:00
}
lintOptions {
abortOnError(false)
2015-09-16 20:38:42 +03:00
}
Migrate to FBJNI (#27729) 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: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
2020-01-21 13:30:57 +03:00
packagingOptions {
exclude("META-INF/NOTICE")
exclude("META-INF/LICENSE")
}
Migrate to FBJNI (#27729) 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: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
2020-01-21 13:30:57 +03:00
configurations {
extractHeaders
extractJNI
javadocDeps.extendsFrom api
Migrate to FBJNI (#27729) 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: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
2020-01-21 13:30:57 +03:00
}
2015-09-16 20:38:42 +03:00
}
dependencies {
api("com.facebook.infer.annotation:infer-annotation:0.18.0")
api("com.facebook.yoga:proguard-annotations:1.19.0")
api("javax.inject:javax.inject:1")
api("androidx.appcompat:appcompat:1.0.2")
api("androidx.autofill:autofill:1.1.0")
PlatformColor implementations for iOS and Android (#27908) 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
2020-03-03 02:07:50 +03:00
api("androidx.swiperefreshlayout:swiperefreshlayout:1.0.0")
api("com.facebook.fresco:fresco:${FRESCO_VERSION}")
api("com.facebook.fresco:imagepipeline-okhttp3:${FRESCO_VERSION}")
api("com.facebook.fresco:ui-common:${FRESCO_VERSION}")
api("com.facebook.soloader:soloader:${SO_LOADER_VERSION}")
api("com.google.code.findbugs:jsr305:3.0.2")
api("com.squareup.okhttp3:okhttp:${OKHTTP_VERSION}")
api("com.squareup.okhttp3:okhttp-urlconnection:${OKHTTP_VERSION}")
api("com.squareup.okio:okio:2.9.0")
api("com.facebook.fbjni:fbjni-java-only:0.2.2")
extractHeaders("com.facebook.fbjni:fbjni:0.2.2:headers")
extractJNI("com.facebook.fbjni:fbjni:0.2.2")
javadocDeps("com.squareup:javapoet:1.13.0")
testImplementation("junit:junit:${JUNIT_VERSION}")
testImplementation("org.powermock:powermock-api-mockito2:${POWERMOCK_VERSION}")
testImplementation("org.powermock:powermock-module-junit4-rule:${POWERMOCK_VERSION}")
testImplementation("org.powermock:powermock-classloading-xstream:${POWERMOCK_VERSION}")
testImplementation("org.mockito:mockito-core:${MOCKITO_CORE_VERSION}")
testImplementation("org.assertj:assertj-core:3.21.0")
testImplementation("org.robolectric:robolectric:${ROBOLECTRIC_VERSION}")
androidTestImplementation(fileTree(dir: "src/main/third-party/java/buck-android-support/", include: ["*.jar"]))
androidTestImplementation("androidx.test:runner:${ANDROIDX_TEST_VERSION}")
androidTestImplementation("androidx.test:rules:${ANDROIDX_TEST_VERSION}")
androidTestImplementation("org.mockito:mockito-core:${MOCKITO_CORE_VERSION}")
2015-09-16 20:38:42 +03:00
}
react {
// TODO: The library name is chosen for parity with Fabric components & iOS
// This should be changed to a more generic name, e.g. `ReactCoreSpec`.
libraryName = "rncore"
jsRootDir = file("../Libraries")
reactRoot = file("$projectDir/..")
useJavaGenerator = System.getenv("USE_CODEGEN_JAVAPOET")?.toBoolean() ?: false
// We search for the codegen in either one of the `node_modules` folder or in the
// root packages folder (that's for when we build from source without calling `yarn install`).
codegenDir = file(findNodeModulePath(projectDir, "react-native-codegen") ?: "../packages/react-native-codegen/")
}
afterEvaluate {
// Needed as some of the native sources needs to be downloaded
// before configureNdkBuildDebug could be executed.
configureNdkBuildDebug.dependsOn(preBuild)
configureNdkBuildRelease.dependsOn(preBuild)
publishing {
publications {
release(MavenPublication) {
// Applies the component for the release build variant.
from components.release
// You can then customize attributes of the publication as shown below.
artifactId = POM_ARTIFACT_ID
groupId = GROUP
version = VERSION_NAME
pom {
name = POM_NAME
description = "A framework for building native apps with React"
url = "https://github.com/facebook/react-native"
developers {
developer {
id = "facebook"
name = "Facebook"
}
}
licenses {
license {
name = "MIT License"
url = "https://github.com/facebook/react-native/blob/HEAD/LICENSE"
distribution = "repo"
}
}
scm {
url = "https://github.com/facebook/react-native.git"
connection = "scm:git:https://github.com/facebook/react-native.git"
developerConnection = "scm:git:git@github.com:facebook/react-native.git"
}
}
}
}
repositories {
maven {
name = "npm"
url = AAR_OUTPUT_URL
}
}
}
}