lifecycle-runtime-compose:2.8.2 occurs CompositionLocal LocalLifecycleOwner not present Error [346808608]

Fixed

Bug

Status Update

No update yet.

Description

th...@gmail.com

created issue #1

Jun 13, 2024 12:57PM

This is basically an follow-up of https://issuetracker.google.com/issues/336842920.

Component used:

Version used:

Compose 1.6.8
Lifecycle 2.8.2
AGP 8.4.2

Devices/Android versions reproduced on: Android 14

We see the the following crashes directly at app start when using R8 (with default AGP 8.x fullMode enabled): IllegalStateException: CompositionLocal LocalLifecycleOwner not present

We saw the added proguard rules in https://android-review.googlesource.com/c/platform/frameworks/support/+/3105647/21/lifecycle/lifecycle-runtime-compose/proguard-rules.pro

Changing them to

-keep class androidx.compose.ui.platform.AndroidCompositionLocals_androidKt { *; }

fixes the crash.

So it seems the keep rule is currently not sufficient to make 2.8.2 compatible with Compose 1.6 when minify the build.

Comments

il...@google.com <il...@google.com> #2Jun 13, 2024 04:04PM

Yigit, do you have time to fix it?

reemission of the same liveData is racy

ga...@freeletics.com <ga...@freeletics.com> #3Jun 14, 2024 06:21AM

yea i'll take it.

mg...@google.com <mg...@google.com> Jun 14, 2024 10:22AM

Assigned to mg...@google.com.

Ni...@fressnapf.com <Ni...@fressnapf.com> #4Jun 14, 2024 11:16AM

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.

Message last modified on Jun 14, 2024 11:19AM

mg...@google.com <mg...@google.com> #5Jun 14, 2024 12:48PM

Accepted by mg...@google.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()
}
}

Message last modified on Jun 14, 2024 02:44PM

mg...@google.com <mg...@google.com> #6Jun 14, 2024 03:10PM

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)

Message last modified on Jun 27, 2024 09:26PM

ap...@google.com <ap...@google.com> #7Jun 17, 2024 09:50AM

Marked as fixed.

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} )
}

nu...@traderepublic.com <nu...@traderepublic.com> #8Jun 27, 2024 12:05PM

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

mg...@google.com <mg...@google.com> #9Jun 27, 2024 03:48PM

comment#8:

These changes are scheduled to be included in our upcoming hot-fix release, version 2.8.3.

Message last modified on Jun 27, 2024 03:49PM

pr...@google.com <pr...@google.com> #10Jun 27, 2024 10:50PM

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

androidx.lifecycle:lifecycle-runtime-compose:2.8.3
androidx.lifecycle:lifecycle-runtime-compose-android:2.8.3
androidx.lifecycle:lifecycle-runtime-compose-desktop:2.8.3

m....@gmail.com <m....@gmail.com> #11Jun 28, 2024 02:31PM

It seems that Lifecycle 2.8.3 is not available on Google's Maven repository: https://maven.google.com/web/index.html#androidx.lifecycle:lifecycle-runtime-compose Any idea when it will be deployed?

mg...@google.com <mg...@google.com> #12Jun 29, 2024 09:55AM

comment#11:

There was a mix-up, and the Lifecycle 2.8.3 artifacts won't be available until Monday. Sorry for the false alarm.

m....@gmail.com <m....@gmail.com> #13Jul 1, 2024 07:29PM

Seems to be good now. Thanks!

mg...@google.com <mg...@google.com> #14Jul 2, 2024 08:32AM

Lifecycle 2.8.3 is now available on maven.google.com.

pe...@mohemian.com <pe...@mohemian.com> #15Jul 8, 2024 08:48AM

I'm still getting "java.lang.IllegalStateException: CompositionLocal LocalLifecycleOwner not present" with 2.8.3 in release builds (with obfuscation enabled). Adding

-keep class androidx.compose.ui.platform.AndroidCompositionLocals_androidKt { *; }

to my ProGuard rules fixes the issue. Any advice?

In my setup I have an app that's using the lifecycle dependencies directly, but some other dependencies of mine also include the same (and these libraries are obfuscated too) - not sure if this makes a difference.

mg...@google.com <mg...@google.com> #16Jul 8, 2024 03:47PM

comment#15:

I'm unable to offer advice since I can't replicate the issue you're experiencing -- but based on your message, it appears Lifecycle "should" be working correctly.

Would you please create a separated issue and include a sample project that reproduces the problem you're encountering?

Message last modified on Jul 8, 2024 03:56PM

pr...@google.com <pr...@google.com> #17Aug 13, 2024 06:58PM