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.