Status Update
Comments
du...@google.com <du...@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
}
}
}
d-...@yandex-team.ru <d-...@yandex-team.ru> #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
py...@gmail.com <py...@gmail.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.
mo...@google.com <mo...@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
mo...@google.com <mo...@google.com> #6
Since release signing config is used by default instead of debug
is not mentioned in release notes - maybe this is a bug?
Cause the last time I found it mentioned in the release notes was in version 1.1
signingConfig.debug is used as the default signing config (
) b/153583269
So, if the switch to the release one indeed happened - maybe it's an issue?
du...@google.com <du...@google.com> #7
ap...@google.com <ap...@google.com> #8
Branch: androidx-main
commit 2c947e6474a89b230eb6f7acae460a9059b006c1
Author: George Mount <mount@google.com>
Date: Tue May 21 09:21:11 2024
Expose packedValue properties of IntIntPair and FloatFloatPair
Fixes: 331853566
Relnote: "Exposed the packedValue internal representation for IntIntPair
and FloatFloatPair."
Test: new tests
Change-Id: Ifeb75cb8ea63d2b5c23d78640fd76bf81ec4f090
M collection/collection/api/current.txt
M collection/collection/api/restricted_current.txt
M collection/collection/src/commonMain/kotlin/androidx/collection/FloatFloatPair.kt
M collection/collection/src/commonMain/kotlin/androidx/collection/IntIntPair.kt
M collection/collection/src/commonTest/kotlin/androidx/collection/PairTest.kt
pr...@google.com <pr...@google.com> #9
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.collection:collection:1.5.0-alpha01
androidx.collection:collection-iosarm64:1.5.0-alpha01
androidx.collection:collection-iossimulatorarm64:1.5.0-alpha01
androidx.collection:collection-iosx64:1.5.0-alpha01
androidx.collection:collection-jvm:1.5.0-alpha01
androidx.collection:collection-linuxarm64:1.5.0-alpha01
androidx.collection:collection-linuxx64:1.5.0-alpha01
androidx.collection:collection-macosarm64:1.5.0-alpha01
androidx.collection:collection-macosx64:1.5.0-alpha01
androidx.collection:collection-tvosarm64:1.5.0-alpha01
androidx.collection:collection-tvossimulatorarm64:1.5.0-alpha01
androidx.collection:collection-tvosx64:1.5.0-alpha01
androidx.collection:collection-watchosarm32:1.5.0-alpha01
androidx.collection:collection-watchosarm64:1.5.0-alpha01
androidx.collection:collection-watchossimulatorarm64:1.5.0-alpha01
androidx.collection:collection-watchosx64:1.5.0-alpha01
Description
Version used: 1.4.0
Devices/Android versions reproduced on: any
It would be beneficial to have the ability to utilize primitive pairs within collections. At present, there is no means to store numerous pairs that are internally represented as the Long type (IntIntPair, FloatFloatPair) within a MutableLongMap. Therefore, in instances where we require storing multiple pairs, an ArrayList or a MutableObjectList is currently utilized, which leads to unnecessary boxing/unboxing operations.
It would be beneficial to provide public access to the internal pair's Long value or to generate an IntIntPairList and FloatFloatPairList classes within the library.