IssueTracker

What's the use case for this? The only advantage I can see is to prevent overwriting the apk of a previously installed release build. If there is no other use case, would it work if we were to statically add baselineprofile and benchmark as application id suffix?

In any case, as I mentioned on the ASG conversation, it is already possible to customize the benchmark and baseline profile build type simply creating it before the plugin does. For example, to customize the baseline profile and benchmark build types for release, you can just create nonMinifiedRelease and benchmarkRelease:

android {
    buildTypes {
        nonMinifiedRelease { ... }
        benchmarkRelease { ... }
    }
}

I think there are some legitimate use cases to customize the build type beside the application id suffix, for example to change signingConfig, but I'm wondering if we can tackle that separately rather than a generic system to configure the new build types.

(reassigning for visibility)

With aosp/3032806 even though it's still possible to customize the benchmark and baseline profile build types, some properties will be overridden.

This is for example to avoid customizing the baseline profile build type properties that would break the baseline profile generation. We should document this.

For now, I don't know other use case for overriding it, but people use build system in various forms and the API generally allows you to customize it. The applicationIdSuffix was a real example in NowInAndroid, which we had to remove.

I wasn't aware you can customize it when you define the two buildTypes! I think this is fine. I think your change in aosp/3032806 makes sense.

Out of curiosity, can we warn if a parameter is overriden? I assume not, but just checking.

Over to Ben for documenting it :)

This is a summary of how build type configuration works:

buildTypes {
    release {
        ...
    }
    benchmarkRelease {
        // Properties for benchmark release can be overridden here.
        // It's also possible to specify a different signing config.
    }
    nonMinifiedRelease {
        // Properties for nonMinifiedRelease can be specified here.
        //
        // From 1.2.5 and 1.3.0-alpha04, the following properties are always overridden to avoid breaking baseline profile generation:
        //
        // isJniDebuggable = false
        // isDebuggable = false
        // isMinifyEnabled = false
        // isShrinkResources = false
        // isProfileable = true
        // enableAndroidTestCoverage = false
        // enableUnitTestCoverage = false
        //
        // It's still possible to specify a different signing config.
    }
}

Documentation updated