fix: Let react.gradle Hermes config use devDisabledIn-flag

[cbrevik]

Summary

Issues: #27829 #25601

At the moment react.gradle doesn't support custom build variants for Hermes in release-builds. Say I have have a build type in my android/app/build.gradle named store, which is supposed to be a release-build:

buildTypes {
    store {
        initWith buildTypes.release
        matchingFallbacks = ['release']
    }
}

Then the explicit check for the target name in react.gradle will not work:

targetName.toLowerCase().contains("release")

My suggestion is that we let the "release"-check for Hermes be the "devDisabledIn${targetName}" flag. This is used to assign the devEnabled variable, which also does the release targetName-check, and should in this case be backwards-compatible.

This would let me configure the behaviour through the pre-existing devDisabledIn-flag in my android/app/build.gradle:

project.ext.react = [
    entryFile: "index.js",
    enableHermes: true,
    devDisabledInStore: true,
    bundleInStore: true
]

Changelog

[Android] [Added] - Hermes now supports the devDisabledIn{targetName}-flag for custom build variants in build.gradle

Test Plan

1. Create a new React Native-project
2. Add a new build type which inits with the release build type:

buildTypes {
    staging {
        initWith buildTypes.release
        matchingFallbacks = ['release']
    }
}

3. Disable dev for the staging build variant in my config, enable Hermes:

project.ext.react = [
    entryFile: "index.js",
    enableHermes: true,  // clean and rebuild if changing
    devDisabledInStaging: true,
    bundleInStaging: true
]

4. Add the extra necessary Hermes-config in dependencies for the build variant (stagingImplementation):

if (enableHermes) {
    def hermesPath = "../../node_modules/hermes-engine/android/";
    debugImplementation files(hermesPath + "hermes-debug.aar")
    releaseImplementation files(hermesPath + "hermes-release.aar")
    stagingImplementation files(hermesPath + "hermes-release.aar")
} else {
    implementation jscFlavor
}

5. Build the staging variant and run on device to verify that it works.

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
android	hermes	arm64-v8a	6,605,785	0
android	hermes	armeabi-v7a	6,282,649	0
android	hermes	x86	6,946,522	0
android	hermes	x86_64	6,876,768	0
android	jsc	arm64-v8a	8,914,058	0
android	jsc	armeabi-v7a	8,554,272	0
android	jsc	x86	8,738,837	0
android	jsc	x86_64	9,315,314	0

Base commit: 6f627f6

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
ios	-	universal	10,836,448	0

Base commit: 6f627f6

[benoitdion]

What do you think about adding a new config value what'd work similarly to devDisabledIn... and bundleIn... specific to hermes release mode? Overloading devDisabledIn might not be the expected behavior for everyone.

[cbrevik]

You're probably right, it will be unexpected behaviour for those who know about the config flag. The devDisabledIn.. and bundleIn.. are specific to the react-native bundle task as it stands today.

I find the description in a vanilla build.gradle to be a bit more general though:

 *   // whether to disable dev mode in custom build variants (by default only disabled in release)
 *   // for example: to disable dev mode in the staging build type (if configured)
 *   devDisabledInStaging: true

And I wonder how many would disable dev-mode bundling in a non-Release build? It seemed appropriate to me to "merge" behaviour here.

There are a lot of other specific config flags in build.gradle though, so I'm definitely open for adding another config flag for "hermes release mode" if that seems appropriate.

[cortinico]

Thanks for sending the PR. I'm closing this as the logic is completely rewritten now.