IssueTracker

Do you have a branch I can test?

Unfortunately we do not control that and we may have to ask AGP if that's an actual issue.

I think the issue here is that calling assemble will not just build the variants but also "prepare" the configurations with any required artifact. As a result, the configurations exposed to retrieve the baseline profile artifact (in the producer module) will lazily trigger baseline profile generation.

There is no easy way to do this. This is because you may have your own tasks triggering generateBaselineProfile, or you want simply to run the tests to generate the profile without actually updating the consumer. Or because you do expect that calling assemble will update the profiles.

I would simply rely on documentation here.

The right syntax to disable those tasks (so that profiles won't be generated when calling assemble) in that project is:

./gradlew assemble -x :baselineProfile:pixel6Api31Setup -x :baselineProfile:pixel6Api31NonMinifiedReleaseAndroidTest

We could add a property if it makes it easier, since it's an issue specific to ubuntu github runners, something along the lines of:

-Pandroidx.baselineprofiles.skipgeneration

That basically does the same of the -x options I mentioned above.

While I'm ok with adding the parameters, it feels like a hard-to-understand problem for a newcomer that just applies the plugin and suddenly their build or assemble tasks start failing (or start taking way longer).

I agree but there isn't much we can do. This is also not related to AGP but to how gradle works: assemble is a task that also "prepares" the configurations (that in gradle are used to carry artifacts). When triggering the configuration we use to expose the baseline profile artifacts the GMD device setup also starts, since it's part of the task chain to produce the artifact.

The only option we've is to decide when to disable those specific tasks, so that the configuration won't have any artifact and don't generate/update the baseline profile.

The property I've implemented is one way. The other way I've explored is to check what task the user invoked but this can potentially break other flows. For example, consider if the user launched:

./gradlew :baselineprofile:assemble :app:generateBaselineProfile :app:assemble

The result is that the baseline profile wouldn't be generated (or updated), the app would be assembled and there would be no failure. Other examples could be cases in which the user defined its own task and adds a dependency on the generation task.

Disabling some tasks based on what the user launched might ultimately be worse in other settings. I think a good trade-off is documentation and the above mentioned property but I'm open to ideas.

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.benchmark:benchmark-baseline-profile-gradle-plugin:1.2.0-alpha15