IssueTracker

The workaround I found so far is to use project.afterEvaluate {} to access the build types, as they are created only after Baseline Profile Gradle Plugin creates them:

Kotlin

android {
    buildTypes {
        release { ... }
        project.afterEvaluate {
            getByName("benchmarkRelease") { }
            getByName("nonMinifiedRelease") { }
        }
    }
}

Groovy

android {
    buildTypes {
        release { ... }
        project.afterEvaluate {
            benchmarkRelease { }
            nonMinifiedRelease { }
        }
    }
}

This way there are no redundant build variants created.

Attaching a sample project for convenience.

This should be a bug on the AS side.

I would say AS isn't the problem. Even without the AS in the project that I attached the simple commands:

./gradlew assembleBenchmarkBenchmarkRelease
./gradlew assembleNonMinifiedNonMinifiedRelease
./gradlew assembleNonMinifiedBenchmarkRelease

are executed successfully and produce some apks.

This is how the baseline profile works - it creates specific build types to correctly generate baseline profiles and benchmarks.

You can still disable the variants if you're not interested in one of them. But AS should not be showing them (by default, configurable through a flag).

Yes, the Baseline Profile Gradle Plugin creates the appropriate build types or updates them if they already exist (or supposed to, according to the source code).

What I'm refereing to exactly is those result build variants, that don't make sence: benchmarkBenchmarkRelease, nonMinifiedNonMinifiedRelease and nonMinifiedBenchmarkRelease.

AS displays whatever build variants were created by the gradle plugins and fixing this issue either on AS side or disabling all these weird build variants manually in build script seem more like treating a symptom, rather than the root cause.