Status Update
Comments
ap...@google.com <ap...@google.com> #2
Can you include a sample project that crashes in release mode?
ap...@google.com <ap...@google.com> #3
For us this is only happening in places where LifecycleEventEffect
is used. Example stacktrace:
Fatal Exception: java.lang.IllegalStateException
CompositionLocal LocalLifecycleOwner not present
androidx.lifecycle.compose.LocalLifecycleOwnerKt$LocalLifecycleOwner$1$1.invoke (LocalLifecycleOwner.android.kt:63)
androidx.lifecycle.compose.LocalLifecycleOwnerKt$LocalLifecycleOwner$1$1.invoke (LocalLifecycleOwner.android.kt:62)
kotlin.SynchronizedLazyImpl.getValue (LazyJVM.kt:74)
androidx.compose.runtime.LazyValueHolder.getCurrent (LazyValueHolder.java:29)
androidx.compose.runtime.LazyValueHolder.getValue (LazyValueHolder.java:31)
androidx.compose.runtime.CompositionLocalMapKt.read (CompositionLocalMap.kt:90)
androidx.compose.runtime.ComposerImpl.consume (Composer.kt:2135)
androidx.lifecycle.compose.LifecycleEffectKt.LifecycleEventEffect (LifecycleEffect.kt:748)
com.freeletics.feature.profile.ProfileUiKt$ProfileUi$1.invoke (ProfileUi.kt:62)
This is also on Lifecycle 2.8.2 with Compose 1.6.
ap...@google.com <ap...@google.com> #4
Here is a sample project
- Checkout repository
- Build release apk with ./gradlew :app:assembleRelease -PenableReleaseSigning=true
- App starts without crash
- Comment or remove line 14 in
https://github.com/nilsjr/Koncept/blob/develop/app/proguard-rules.pro - Build release apk with ./gradlew :app:assembleRelease -PenableReleaseSigning=true
- App crashing on start
FATAL EXCEPTION: main (Ask Gemini)
Process: de.nilsdruyen.koncept, PID: 5880
java.lang.IllegalStateException: CompositionLocal LocalLifecycleOwner not present
...
ap...@google.com <ap...@google.com> #5
Thank you for sharing the sample project. I can confirm that I was able to reproduce the issue, and that
ap...@google.com <ap...@google.com> #6
It appears that the custom ProGuard rule was not working as intended across all projects.
However, using public static *** getLocalLifecycleOwner();
(with the wildcard type ***
) seems to work consistently in the sample project and our internal experiments:
-if public class androidx.compose.ui.platform.AndroidCompositionLocals_androidKt {
public static *** getLocalLifecycleOwner();
}
-keep public class androidx.compose.ui.platform.AndroidCompositionLocals_androidKt {
public static *** getLocalLifecycleOwner();
}
We are investigating further, and we will be working on a fix for the issue.
ap...@google.com <ap...@google.com> #7
Branch: androidx-main
commit 79f5644cb937d950318c3c5ef2aca70ab1413119
Author: Marcello Galhardo <mgalhardo@google.com>
Date: Fri Jun 14 16:34:11 2024
Fix Lifecycle 2.8 custom ProGuard rule
* The custom ProGuard rule was not working as intended across all projects.
* Replacing by `public static *** getLocalLifecycleOwner();` (with the wildcard type `***`) seems to work consistently in all projects.
Fixes:
Test: manual
Change-Id: I4cfdecc0bbfc0be02d66efcee2c63bb5b025dca2
M lifecycle/lifecycle-runtime-compose/proguard-rules.pro
ap...@google.com <ap...@google.com> #8
Could you please make an immediate patch release as 2.8.2 crashes with the above exception?
ap...@google.com <ap...@google.com> #10
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
ap...@google.com <ap...@google.com> #11
ap...@google.com <ap...@google.com> #12
There was a mix-up, and the Lifecycle 2.8.3 artifacts won't be available until Monday. Sorry for the false alarm.
ap...@google.com <ap...@google.com> #14
Lifecycle 2.8.3 is now available on
na...@google.com <na...@google.com> #15
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.
da...@google.com <da...@google.com> #16
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
sa...@google.com <sa...@google.com> #17
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.lifecycle:lifecycle-runtime-compose:2.9.0-alpha01
androidx.lifecycle:lifecycle-runtime-compose-android:2.9.0-alpha01
androidx.lifecycle:lifecycle-runtime-compose-desktop:2.9.0-alpha01
na...@google.com <na...@google.com> #18
The following release(s) address this bug:
androidx.lifecycle:lifecycle-runtime:2.6.0-alpha03
androidx.lifecycle:lifecycle-runtime-compose:2.6.0-alpha03
androidx.lifecycle:lifecycle-viewmodel-compose:2.6.0-alpha03
androidx.lifecycle:lifecycle-viewmodel-savedstate:2.6.0-alpha03
Description
Component used: Lifecycle
Version used: 2.6.0-alpha01
Until feature requests such as b/146802533 are released, Gradle does not do any enforcement that Lifecycle artifacts are of the same version (i.e., you could mix and match
lifecycle-common:2.6.0-alpha01
withlifecycle-runtime:2.5.1
).Gradle supports constraints , which ensure that upgrading a transitive dependency will also upgrade other dependencies.
We should manually add two way constraints, similarly to what was done for Paging in b/235256201 , to the various lifecycle artifacts, which will help Gradle enforce the same version policy we intend.
The pairs of artifacts we should add constraints to should match the dependencies we have right now, which should mean the list looks something like: