Status Update
Comments
xa...@google.com <xa...@google.com>
ma...@google.com <ma...@google.com> #2
Thanks for your detailed post.
However, benchmark build type is under configured: at least isProfileable is not set to true for existing build type, probably there's more.
We should set isProfileable = true
by default when overriding an existing benchmark build type.
This issue is not about some specific configuration flag, but the general approach of dealing with external configuration. As a developer adopting baseline profiles, it seems extremely risky to me using a custom configuration due to how it's applied under the hood and the fact it may break default configuration.
I agree that is not great but this is a little tricky to do. For custom baseline profile build types we override all the properties. For benchmark I left it open to configure but it's mostly about these 2 properties:
isMinifyEnabled
isShrinkResources
I don't have a way to see if the user is setting them before overriding, so for this reason, I'd prefer not to. I agree with you that some other properties could be set by default to make this easier, i.e.:
isJniDebuggable = false
isDebuggable = false
isProfileable = true
The reason why I mentioned the release signing config in the beginning is because I want to use debug signing config.
In the specific of your issue, i.e. using a debug certificate can you override the benchmark and baseline profile setting? You should be able to do something like:
android {
buildTypes {
release { ... }
debug { ... }
benchmarkRelease {
...
signingConfig signingConfigs.debug
}
nonMinifiedRelease {
...
signingConfig signingConfigs.debug
}
}
}
ap...@google.com <ap...@google.com> #3
Project: platform/frameworks/support
Branch: androidx-main
Author: Marcello Albano <
Link:
Added override for debuggable and profileable for benchmark builds in bpgp
Expand for full commit details
Added override for debuggable and profileable for benchmark builds in bpgp
Test: ./gradlew :benchmark:benchmark-baseline-profile-gradle-plugin:test
Bug: 369213505
Relnote: "isProfileable is always overridden in benchmark builds,
and isDebuggable is also now always overridden in both benchmark and
nonMinified (baseline profile capture) builds."
Change-Id: I487fa71083921682173f04fcbb477be5baf165f8
Files:
- M
benchmark/baseline-profile-gradle-plugin/src/main/kotlin/androidx/baselineprofile/gradle/apptarget/BaselineProfileAppTargetPlugin.kt
- M
benchmark/baseline-profile-gradle-plugin/src/test/kotlin/androidx/baselineprofile/gradle/apptarget/BaselineProfileAppTargetPluginTest.kt
Hash: 1906bbe52ba7ccb9ca0e1c1d6de33e7c91b5c6f0
Date: Fri Oct 11 10:07:06 2024
ma...@google.com <ma...@google.com>
xa...@google.com <xa...@google.com> #4
I've landed a change that will set the following properties also when the benchmark build type already exists:
isJniDebuggable = false
isDebuggable = false
isProfileable = true
As well as the following for agp 8.0:
isDebuggable = false
I'm going ahead and closing this - if you've further questions please answer here and will reopen. Thanks.
ma...@google.com <ma...@google.com> #5
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.4.0-alpha04
Description
The
androidx.baselineprofile
plugin generates additional<flavor>NonMinifiedRelease
and<flavor>BenchmarkRelease
variants for each original variant that's non-debuggable (release).Sometimes not all combinations of flavor + build type are needed so it makes sense to disable certain variants with the
androidComponents.beforeVariants
API.For example, a project has defined 1 flavor dimension "environment" with 4 flavors:
By default this produces 8 variants:
We can disable 4 of the variants that are irrelevant:
When baseline profile plugin is applied to the app module, before any variant filtering it adds the following variants:
Let's say I want to generate baseline profile and run benchmark with just the
devRelease
variant.The generated
devNonMinifiedRelease
anddevBenchmarkRelease
should be enough. So I would still filter outdevRelease
.I'm also able to filter out the generated
<mock|demo>NonMinifiedRelease
and<mock|demo>BenchmarkRelease
variants as well as the original<mock|demo>Release
.Now I also want to filter out
prodNonMinifiedRelease
andprodBenchmarkRelease
as I don't need to generate BP or run benchmark with theprod
flavor. So the variant filter looks like thisWith this the build fails during configuration:
It seems like the task wiring fails when a
release
variant (prodRelease
in this case) is enabled but the correspondingbenchmarkRelease
variant is disabled.Adding the
prodBenchmarkRelease
variant fixes it.But the
prodBenchmarkRelease
variant is useless while lot of tasks are registered for it.I'm not sure what the right solution should be as there seems to be a chicken and egg problem when variants are being filtered out by user but also being added by the plugin during configuration.
To reproduce, please checkout this sample .
app/build.gradle.kts
, comment out"prodBenchmarkRelease",
from line 170../gradlew
Studio Build: Android Studio Koala 2024.1.1 Canary 3
Version of Gradle Plugin: 8.5.0-alpha03
Version of Gradle: 8.7
Version of
androidx.baselineprofile
: 1.3.0-alpha02Version of Java: 21
OS: macOS