Status Update
No update yet.
Comments
ro...@gmail.com
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
}
}
}
rv...@google.com
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
ro...@gmail.com
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.
ro...@gmail.com
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
as...@google.com
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?
as...@google.com
ro...@gmail.com
Sure, how can I share it with (only) you?
as...@google.com
It seems like rememberAnimatedVectorPainter is active even if it is not being drawn / used.
A probable workaround is to do this:
painter = if (!started) {
painterResource(
id = R.drawable.ic_run_matchface
)
} else {
rememberAnimatedVectorPainter(animatedImageVector = runAnimIcon, atEnd = atEnd)
},
ro...@gmail.com
Not sure I'm seeing the workaround here other than that the animation stops. Is that what you're trying to do? The icon is only 700ms or so long and the idea is that it needs to be repeated over and over again. I've noticed that getting a smooth transition from the animation reaching its end to restart is not that perfect. It would be better if compose would have a built-in option just to keep it repeating indefinitely or for x times or so. Just as there was in the Views system. Now I have to trick it like I did to get a smooth continuous animation.
And eventually with whatever workaround, there should be no memory leaks.
I can share the icon with you, but I'm not keen to share it with the whole world. Let me know how I can do that.
as...@google.com
Sorry for the confusion, I meant moving rememberAnimatedVectorPainter inside else block rather than hoisting it outside. I think it should result in the same result as before but will only start animating after started condition has switched.
Obviously, we want the memory leak to be fixed regardless. You can upload the icon to google drive and share with
ro...@gmail.com
I've just send you two files. I forgot to mention that I have another icon with the same config. That is only shown when the systen detects that there is no network. Also, the aniomation is kicked off with a suspend function. Maybe there is a better way of doing this, but I couldn't find it.
var atEndNoNetwork by remember { mutableStateOf(false) }
val noNetworkAnimIcon = AnimatedImageVector.animatedVectorResource(R.drawable.ic_no_network)
val noNetworkAnimIconPainter1 = rememberAnimatedVectorPainter(animatedImageVector = noNetworkAnimIcon, atEnd = atEndNoNetwork)
val noNetworkAnimIconPainter2 = rememberAnimatedVectorPainter(animatedImageVector = noNetworkAnimIcon, atEnd = !atEndNoNetwork)
val isRunning by remember { mutableStateOf(true) }
suspend fun runAnimation() {
while (isRunning) {
delay(714)
atEnd = !atEnd
}
}
suspend fun noNetworkAnimation() {
while (isRunning) {
delay(3500)
atEndNoNetwork = !atEndNoNetwork
}
}
as...@google.com
It seems like the bug is in MutableObjectIntMap implementation. In the attached heap dump, the RecomposeScopeImpl#trackedInstances size is 1, but capacity is /very/ large.
ro...@gmail.com
Did you find the rootcause yet?
as...@google.com
Yeah, I found the cause, the bugfix is pending.
as...@google.com
Regression test:
@Test
fun insertManyRemoveMany() {
val map = MutableScatterMap<Int, String>()
for (i in 0..1000000) {
map[i] = i.toString()
map.remove(i)
assertTrue(map.capacity < 16, "Map grew larger than 16 after step $i")
}
}
ro...@gmail.com
Nice! Just let me know what I need to do to repeat my test with the bugfix in place.
ap...@google.com
Branch: androidx-main
commit 5e6b6d143647f1b06e3297ce7e8af2d976aefa2b
Author: Andrei Shikov <ashikov@google.com>
Date: Mon Jun 03 21:12:23 2024
Remove deleted tombstones from Map/Set when resizing
The ScatterMap/Set were increasing capacity infinitely when adding and removing elements frequently.
Fixes: 345960092
Test: Updated collection tests
Change-Id: Ic72352b3209e463de8de2278896a4b1bf10bd832
M collection/collection-benchmark/src/androidInstrumentedTest/kotlin/androidx/collection/ScatterMapBenchmarkTest.kt
M collection/collection-benchmark/src/commonMain/kotlin/androidx/collection/ScatterMapBenchmarks.kt
M collection/collection/src/commonMain/kotlin/androidx/collection/FloatFloatMap.kt
M collection/collection/src/commonMain/kotlin/androidx/collection/FloatIntMap.kt
M collection/collection/src/commonMain/kotlin/androidx/collection/FloatLongMap.kt
M collection/collection/src/commonMain/kotlin/androidx/collection/FloatObjectMap.kt
M collection/collection/src/commonMain/kotlin/androidx/collection/FloatSet.kt
M collection/collection/src/commonMain/kotlin/androidx/collection/IntFloatMap.kt
M collection/collection/src/commonMain/kotlin/androidx/collection/IntIntMap.kt
M collection/collection/src/commonMain/kotlin/androidx/collection/IntLongMap.kt
M collection/collection/src/commonMain/kotlin/androidx/collection/IntObjectMap.kt
M collection/collection/src/commonMain/kotlin/androidx/collection/IntSet.kt
M collection/collection/src/commonMain/kotlin/androidx/collection/LongFloatMap.kt
M collection/collection/src/commonMain/kotlin/androidx/collection/LongIntMap.kt
M collection/collection/src/commonMain/kotlin/androidx/collection/LongLongMap.kt
M collection/collection/src/commonMain/kotlin/androidx/collection/LongObjectMap.kt
M collection/collection/src/commonMain/kotlin/androidx/collection/LongSet.kt
M collection/collection/src/commonMain/kotlin/androidx/collection/ObjectFloatMap.kt
M collection/collection/src/commonMain/kotlin/androidx/collection/ObjectIntMap.kt
M collection/collection/src/commonMain/kotlin/androidx/collection/ObjectLongMap.kt
M collection/collection/src/commonMain/kotlin/androidx/collection/ScatterMap.kt
M collection/collection/src/commonMain/kotlin/androidx/collection/ScatterSet.kt
M collection/collection/src/commonTest/kotlin/androidx/collection/FloatFloatMapTest.kt
M collection/collection/src/commonTest/kotlin/androidx/collection/FloatIntMapTest.kt
M collection/collection/src/commonTest/kotlin/androidx/collection/FloatLongMapTest.kt
M collection/collection/src/commonTest/kotlin/androidx/collection/FloatObjectMapTest.kt
M collection/collection/src/commonTest/kotlin/androidx/collection/FloatSetTest.kt
M collection/collection/src/commonTest/kotlin/androidx/collection/IntFloatMapTest.kt
M collection/collection/src/commonTest/kotlin/androidx/collection/IntIntMapTest.kt
M collection/collection/src/commonTest/kotlin/androidx/collection/IntLongMapTest.kt
M collection/collection/src/commonTest/kotlin/androidx/collection/IntObjectMapTest.kt
M collection/collection/src/commonTest/kotlin/androidx/collection/IntSetTest.kt
M collection/collection/src/commonTest/kotlin/androidx/collection/LongFloatMapTest.kt
M collection/collection/src/commonTest/kotlin/androidx/collection/LongIntMapTest.kt
M collection/collection/src/commonTest/kotlin/androidx/collection/LongLongMapTest.kt
M collection/collection/src/commonTest/kotlin/androidx/collection/LongObjectMapTest.kt
M collection/collection/src/commonTest/kotlin/androidx/collection/LongSetTest.kt
M collection/collection/src/commonTest/kotlin/androidx/collection/ObjectFloatMapTest.kt
M collection/collection/src/commonTest/kotlin/androidx/collection/ObjectIntMapTest.kt
M collection/collection/src/commonTest/kotlin/androidx/collection/ObjectLongMapTest.kt
M collection/collection/src/commonTest/kotlin/androidx/collection/ScatterMapTest.kt
M collection/collection/src/commonTest/kotlin/androidx/collection/ScatterSetTest.kt
M collection/collection/template/ObjectPValueMap.kt.template
M collection/collection/template/ObjectPValueMapTest.kt.template
M collection/collection/template/PKeyObjectMap.kt.template
M collection/collection/template/PKeyObjectMapTest.kt.template
M collection/collection/template/PKeyPValueMap.kt.template
M collection/collection/template/PKeyPValueMapTest.kt.template
M collection/collection/template/PKeySet.kt.template
M collection/collection/template/PKeySetTest.kt.template
as...@google.com
Hey, the issue should be fixed now and I will cherry-pick it to the next beta/rc release.
You can test it with the latest snapshot build following instructions at
ro...@gmail.com
Thanks! Hopefully I won't encounter any additional bugs. I'll wait for the next Beta to come out. If you can let me know in which Beta it will arrive, that would be nice. Any idea how long that will take?
as...@google.com
Quick note, this won't be included in the next beta since we need to release a stable collection artifact first. I cherry-picked this change into collections 1.4.1 which should be released within next few weeks.
ro...@gmail.com
Thank you for the update. Just let me know when it's there for me to test.
na...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.collection:collection:1.4.1androidx.collection:collection-iosarm64:1.4.1androidx.collection:collection-iossimulatorarm64:1.4.1androidx.collection:collection-iosx64:1.4.1androidx.collection:collection-jvm:1.4.1androidx.collection:collection-linuxx64:1.4.1androidx.collection:collection-macosarm64:1.4.1androidx.collection:collection-macosx64:1.4.1
ro...@gmail.com
Hi, thank you for the update. I've checked, but this is not a dependency I have in my build.gradle.kts file. Is it something I can test?
as...@google.com
Hi, this is a transitive dependency from runtime, so you can add version 1.4.1 to your dependency list if you want to test.
ro...@gmail.com
Hi, thank you for your explanation. I've included the 1.4.1 release to the dependency list and I need to test it. I'm away for a few days and this takes some time (at least 82 hours of running, with me present). So I think I can come back to you within 3 weeks tops, maybe sooner.
ro...@gmail.com
After running my App for more than 1,5 week without any crashes, the issue seems to be fixed! Thank you for the efforts.
pr...@google.com
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.collection:collection:1.5.0-alpha01androidx.collection:collection-iosarm64:1.5.0-alpha01androidx.collection:collection-iossimulatorarm64:1.5.0-alpha01androidx.collection:collection-iosx64:1.5.0-alpha01androidx.collection:collection-jvm:1.5.0-alpha01androidx.collection:collection-linuxarm64:1.5.0-alpha01androidx.collection:collection-linuxx64:1.5.0-alpha01androidx.collection:collection-macosarm64:1.5.0-alpha01androidx.collection:collection-macosx64:1.5.0-alpha01androidx.collection:collection-tvosarm64:1.5.0-alpha01androidx.collection:collection-tvossimulatorarm64:1.5.0-alpha01androidx.collection:collection-tvosx64:1.5.0-alpha01androidx.collection:collection-watchosarm32:1.5.0-alpha01androidx.collection:collection-watchosarm64:1.5.0-alpha01androidx.collection:collection-watchossimulatorarm64:1.5.0-alpha01androidx.collection:collection-watchosx64:1.5.0-alpha01
ro...@gmail.com
Just wanted to let you know that after some long testing I come to the conclusion that if I don't include the transitive dependency mentioned below, the crash still occurs after approx. 82 hours.
implementation("androidx.collection:collection-ktx:1.4.3")
as...@google.com
Yes, this is a known issue, the dependency was not picked up by 1.7 release branch.
po...@gmail.com
Hello, when will this be released if it wasn't picked up by 1.7 branch but it is marked as fixed?
as...@google.com
The bug was in collections, and it should be available in the latest stable release
Compose will depend on the newer version starting from 1.8.
Description
Component used: TV
Version used: Android 12
Devices/Android versions reproduced on: Google Chromecast HD (happens on 2 devices simultaniously)
Please also review fixed bug:
Now that this is fixed, this new bug appears. After running the App on the TV for approx. 82 hours (3,5 days) it crashes with the stacklog below. This can be repeated. The App is just displaying some texts and is basically idle for the whole time. There is also an icon displayed that optionally an animated icon. This animated icon is not visible while idle (during these 3,5 days).
Maybe it has something to do with these lines of code?
But as you can see is that the runAnimIconPainters are not visible while the App is idle (not started). The ic_run_anim.xml is an animated-vector icon.
The previous bug was due to a memory leak in the compose libraries, this seems to be a similar issue?