Fixed
Status Update
No update yet.
Comments
cc...@google.com
ja...@gmail.com
Yigit, do you have time to fix it?
reemission of the same liveData is racy
reemission of the same liveData is racy
ja...@gmail.com
yea i'll take it.
ma...@google.com
Thanks for the detailed analysis. This may not be an issue anymore since we've started using Main.immediate there but I' not sure; I'll try to create a test case.
ja...@gmail.com
just emitting same live data reproduces the issue.
@Test
fun raceTest() {
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData)
emitSource(subLiveData) //crashes
}
subject.addObserver().apply {
testScope.advanceUntilIdle()
}
}
@Test
fun raceTest() {
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData)
emitSource(subLiveData) //crashes
}
subject.addObserver().apply {
testScope.advanceUntilIdle()
}
}
ma...@google.com
With 2.2.0-alpha04 (that use Main.immediate), the issue seems to be still there (I tested it by calling emitSource() twice, like your test case)
ja...@gmail.com
yea sorry immediate does not fix it.
I actually have a WIP fix for it:
https://android-review.googlesource.com/c/platform/frameworks/support/+/1112186
if your case is the one i found (emitting same LiveData multiple times, as shown in #5) you can work around it by adding a dummy transformation.
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData.map {it })
emitSource(subLiveData.map {it} )
}
I actually have a WIP fix for it:
if your case is the one i found (emitting same LiveData multiple times, as shown in #5) you can work around it by adding a dummy transformation.
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData.map {it })
emitSource(subLiveData.map {it} )
}
ch...@google.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit af12e75e6b4110f48e44ca121466943909de8f06
Author: Yigit Boyar <yboyar@google.com>
Date: Tue Sep 03 12:58:11 2019
Fix coroutine livedata race condition
This CL fixes a bug in liveData builder where emitting same
LiveData source twice would make it crash because the second
emission registry could possibly happen before first one is
removed as source.
We fix it by using a suspending dispose function. It does feel
a bit hacky but we cannot make DisposableHandle.dispose async
and we do not want to block there. This does not mean that there
is a problem if developer disposes it manually since our emit
functions take care of making sure it disposes (and there is
no other way to add source to the underlying MediatorLiveData)
Bug: 140249349
Test: BuildLiveDataTest#raceTest_*
Change-Id: I0b464c242a583da4669af195cf2504e2adc4de40
M lifecycle/lifecycle-livedata-ktx/api/2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/current.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_current.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_current.txt
M lifecycle/lifecycle-livedata-ktx/src/main/java/androidx/lifecycle/CoroutineLiveData.kt
M lifecycle/lifecycle-livedata-ktx/src/test/java/androidx/lifecycle/BuildLiveDataTest.kt
https://android-review.googlesource.com/1112186
https://goto.google.com/android-sha1/af12e75e6b4110f48e44ca121466943909de8f06
Branch: androidx-master-dev
commit af12e75e6b4110f48e44ca121466943909de8f06
Author: Yigit Boyar <yboyar@google.com>
Date: Tue Sep 03 12:58:11 2019
Fix coroutine livedata race condition
This CL fixes a bug in liveData builder where emitting same
LiveData source twice would make it crash because the second
emission registry could possibly happen before first one is
removed as source.
We fix it by using a suspending dispose function. It does feel
a bit hacky but we cannot make DisposableHandle.dispose async
and we do not want to block there. This does not mean that there
is a problem if developer disposes it manually since our emit
functions take care of making sure it disposes (and there is
no other way to add source to the underlying MediatorLiveData)
Bug: 140249349
Test: BuildLiveDataTest#raceTest_*
Change-Id: I0b464c242a583da4669af195cf2504e2adc4de40
M lifecycle/lifecycle-livedata-ktx/api/2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/current.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_current.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_current.txt
M lifecycle/lifecycle-livedata-ktx/src/main/java/androidx/lifecycle/CoroutineLiveData.kt
M lifecycle/lifecycle-livedata-ktx/src/test/java/androidx/lifecycle/BuildLiveDataTest.kt
ja...@gmail.com
I've just tried AGP 8.6.0 and 8.7.0-beta01 with the sample project I attached and both still display the redundant variants in AS Koala Feature Drop | 2024.1.2 and AS Ladybug | 2024.2.1 Beta 1.
Also, the ./gradlew tasks --all command for both mentioned AGP versions displays all the usual tasks for each of these variants. In turn, simple command like ./gradlew :app:assemble will assemble even the redundant variants.
The 'variant's experimental properties' were mentioned. Are they applied automatically by BP plugin or should they be specified manually somewhere?
ma...@google.com
For this bug we're looking at 2 things: -
- the additional build types that are created to generate baseline profiles and benchmark
- the build types that are visible in AS
There is a bug that should be fixed by aosp/3260794 about build types that should not be created. The AS part was to check that these wouldn't be visible. Will add this to version 1.3.1.
Thanks
ap...@google.com
Project: platform/frameworks/support
Branch: androidx-main
commit e75f0a518d11e27d4862ef903a9b29e64c0d6625
Author: Marcello Albano <maralb@google.com>
Date: Mon Sep 09 14:00:46 2024
Don't create nonMinified and benchmark build types if existing
Bug: 361370179
Test: ./gradlew :benchmark:benchmark-baseline-profile-gradle-plugin:test
Relnote: "Due to a bug even if nonMinified and
benchmark build types existed, they were going to
be recreated."
Change-Id: Ia8934fdf3ff51d993f4fef8195821d72315026e2
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
M benchmark/baseline-profile-gradle-plugin/src/test/kotlin/androidx/baselineprofile/gradle/utils/TestUtils.kt
https://android-review.googlesource.com/3260794
Branch: androidx-main
commit e75f0a518d11e27d4862ef903a9b29e64c0d6625
Author: Marcello Albano <maralb@google.com>
Date: Mon Sep 09 14:00:46 2024
Don't create nonMinified and benchmark build types if existing
Bug: 361370179
Test: ./gradlew :benchmark:benchmark-baseline-profile-gradle-plugin:test
Relnote: "Due to a bug even if nonMinified and
benchmark build types existed, they were going to
be recreated."
Change-Id: Ia8934fdf3ff51d993f4fef8195821d72315026e2
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
M benchmark/baseline-profile-gradle-plugin/src/test/kotlin/androidx/baselineprofile/gradle/utils/TestUtils.kt
na...@google.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.3.1
Description
Component used: Baseline Profile Gradle Plugin
Version used: 1.3.0
Devices/Android versions reproduced on: Android Studio Jellyfish/AGP 8.4.2 and Koala/AGP 8.5.2
I want to customize the generatedhttps://developer.android.com/topic/performance/baselineprofiles/configure-baselineprofiles#variant-specific-dependencies
benchmarkReleaseandnonMinifiedReleasebuild variants, which are generated by the Baseline Profile Gradle Plugin. So I follow the documentation:If (as per the docs) I add
benchmarkRelease {}andnonMinifiedRelease {}blocks in Groovy script, I gain a bloated list of build variants. The list goes really wild havingnonMinifiedBenchmarkReleasevariant and some others. See attached screenshots. Same happens to Kotlin script, if I usecreate("benchmarkRelease") {}, as equivalent to Groovy's code.Please fix the creating of the redundant build variants.
I have no sample project attached, as the issue is reproducible on a newly generated Android project with a freshly generated Baseline Profile Generator module. Also, the version of the latter should be bumped to 1.3.0, as the default one is 1.2.3 in AS Koala.