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)