Set cargo release profile for different buildTypes

[ErikBjare]

I have two build types release and debug, and I'd like to set the cargo release profile depending on the build type (instead of using debug, which is bad in production, or using release, which is slow when developing or running in CI).

Example of my build types:

android {
    ...
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
        debug {
            applicationIdSuffix ".debug"
        }
    }
}

I noticed that https://github.com/willir/cargo-ndk-android-gradle did what I want by default, and supported additional configuration per-buildType. Is there a way to work around this? Or is the fix to support it easy?

[tmcguire]

I use this as a workaround:

cargo {
    ...

    // There doesn't seem to be a simpler way to get the current buildType than to check the task names,
    // see https://stackoverflow.com/a/53261807/1005419.
    profile = gradle.startParameter.taskNames.any{it.toLowerCase().contains("debug")} ? "debug" : "release"
}

Note that this only works as long as there are only two build types, "debug" and "release", configured in the project.

[ncalexan]

Just from a general Gradle and Android-Gradle plugin perspective, this isn't particularly robust. If you can inspect the Gradle task execution graph (see https://docs.gradle.org/current/javadoc/org/gradle/api/execution/TaskExecutionGraph.html) then you can figure out which tasks are actually going to be run. That avoids invoking gradle foo and missing that foo depends on assembleDebug or whatever.

But overall you're witnessing an architecture mismatch between Cargo (which has a limited set of build profiles), the Android-Gradle plugin (which has a rich set of build types and product flavors), and this plugin, which doesn't set up tasks for each Android-Gradle configuration.

To fix this "properly" we'd need to do quite a bit more work to have per-Android-Gradle-configuration cargo tasks, each with their own configuration. That's been done -- I think Google's protobuf plugin at https://github.com/google/protobuf-gradle-plugin is my preferred example -- but it's a ton of work :(

[ncalexan]

I'm just making a note to myself that there are more Gradle plugins that allow build and product configuration to cult from these days, e.g. https://github.com/usefulness/easylauncher-gradle-plugin.