Status Update
Comments
mg...@google.com <mg...@google.com> #2
This was fixed by aosp/1331903 and will be available in the Lifecycle 2.3.0-alpha04 release.
gr...@gmail.com <gr...@gmail.com> #3
Branch: androidx-master-dev
commit f891d66d44417ae7298d8306dc5cbca9cfe4b1ee
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed Jul 08 14:20:29 2020
Fix lifecycle-livedata-core-ktx-lint ObsoleteLintCustomCheck
Using the latest version of lint-core (27.1.0) as a dependency for the
livedata-core lint rule causes an ObsoleteLintCustomCheck for studio 4.0
and 4.1 (along with the subsequent gradle versions).
Instead of using the latest, using the minimum version seems to work
appropriately.
Added a lintMinVersion variable to the dependcies file and used that to
make updating easier.
Test: tested in studio 4.0 and 4.1-Canary 8
Bug: 158699265
Change-Id: If1636b3e08a368cf25fb268f42754c4c6ff2f463
M buildSrc/src/main/kotlin/androidx/build/dependencies/Dependencies.kt
M lifecycle/lifecycle-livedata-core-ktx-lint/build.gradle
ma...@marcardar.com <ma...@marcardar.com> #4
There was a use of a lint version that was too new to work in older studio versions. This has now be fixed and will be released in the Lifecycle 2.3.0-alpha06 release.
sj...@gmail.com <sj...@gmail.com> #5
Getting this again in AGP 8.2.2 and Gradle 8.6, please see the attached image file.
ha...@gmail.com <ha...@gmail.com> #6
Just found out that the issue comes after updating androidx.lifecycle:lifecycle-livedata-ktx
from 2.7.0 to 2.8.0.
th...@gmail.com <th...@gmail.com> #7
Using AGP 8.5.1 with Gradle 8.7 makes the latest occurrence of this go away for me (with androidx.lifecycle:lifecycle-runtime-ktx
2.8.4).
mg...@google.com <mg...@google.com> #8
This has come back using on AGP 8.7.0-alpha09 (starting maybe with alpha05 according to my build history? maybe alpha04?).
I'm using Gradle 8.9 as well, if that matters.
mg...@google.com <mg...@google.com>
th...@tempo.co.nz <th...@tempo.co.nz> #9
Thanks for the workaround!
ju...@veepee.com <ju...@veepee.com> #10
the option 2) will not work with compose navigation component, right ? As the lib also provides a LocalLifecycleOwner
and 3) will not work for any library that uses LocalLifecycleOwner
internally.
mg...@google.com <mg...@google.com> #11
the option 2) will not work with compose navigation component, right ? As the lib also provides a
LocalLifecycleOwner
Yes, you would need to also include it on each navigation page (composable()
route).
- will not work for any library that uses
LocalLifecycleOwner
internally.
Yes.
sj...@gmail.com <sj...@gmail.com> #12
For the record, the new dropUnlessResumed
and dropUnlessStarted
APIs won't work with Navigation 2.7 out of the box. Similar to the fix above, the new LocalLifecycleOwner
needs to be explicitly assigned to the NavBackStackEntry
in every composable()
route.
composable(...) { navBackStackEntry ->
CompositionLocalProvider(
androidx.lifecycle.compose.LocalLifecycleOwner provides navBackStackEntry
) {
MyScreen(
onBackClick = dropUnlessResumed { navController.popBackStack() }
)
}
}
ap...@google.com <ap...@google.com> #13
Branch: androidx-main
commit 5d638420d6b6f3df21e4c1cb7c9e48566c1dcafe
Author: Marcello Galhardo <mgalhardo@google.com>
Date: Tue May 21 19:23:41 2024
Add version constraint to Compose UI 1.7.0-beta01 in Lifecycle
RelNote: "`lifecycle-runtime-compose` now has a version constraints with Compose UI 1.7.0-beta01"
Fixes:
Test: Manual
Change-Id: I25dfd4100a4d3bd2f0f32f21711b95e987e2ff2a
M lifecycle/lifecycle-runtime-compose/build.gradle
bo...@gmail.com <bo...@gmail.com> #14
val orderLines by viewModel.orderLines.collectAsStateWithLifecycle(
lifecycleOwner = androidx.compose.ui.platform.LocalLifecycleOwner.current
)
ra...@gmail.com <ra...@gmail.com> #15
ma...@gmail.com <ma...@gmail.com> #16
fi...@gmail.com <fi...@gmail.com> #17
The ./gradlew app:dependencies --configuration releaseRuntimeClasspath
I couldn't find any Compose library resolved to alpha versions, the highest version was 1.6.5.
Is the statement correct? Or do I misinterpret it?
sj...@gmail.com <sj...@gmail.com> #18
@
Lifecycle does not have a transitive dependency on Compose since it's not strictly related to Compose. It's more like Compose 1.7 has been adjusted to Lifecycle 2.8.0. So you need to explicitly update your Compose dependencies.
mg...@google.com <mg...@google.com> #19
lifecycle-runtime-compose
2.8.* does not explicitly depend on compose-ui
1.7.* but there is a behavior compatibility issue between the versions - meaning standard POM dependency version checks will not detect the problem.
To understand the issue better, let’s go step by step on what happened:
- We have introduced a new
LocalLifecycleOwner
insidelifecycle-runtime-compose
. - We have inverted the dependency between
compose-ui
andlifecycle-runtime-compose
.- Before:
lifecycle-runtime-compose
- depends on ->compose-ui
. - After:
compose-ui
- depends on ->lifecycle-runtime-compose
.
- Before:
- We have changed the “old”
LocalLifecycleOwner
fromcompose-ui
to return the new one inlifecycle-runtime-compose
for binary compatibility.compose-ui
1.6.*, sets up the “old”LocalLifecycleOwner
at runtime.compose-ui
1.7.*, sets up the “new”LocalLifecycleOwner
at runtime.
lifecycle-runtime-compose
2.7.* needs the “old”LocalLifecycleOwner
.lifecycle-runtime-compose
2.8.* needs the “new”LocalLifecycleOwner
.
Now, when combining compose-ui
1.6.* and lifecycle-runtime-compose
2.8.* or compose-ui
1.7.* and lifecycle-runtime-compose
2.7.*, they will reference to different LocalLifecycleOwner
instances at runtime.
Since there's no direct dependency between them, standard POM checks cannot detect this issue. A call chain analysis would have been required to identify the behavior incompatibility between stable versions.
fi...@wartek.belajar.id <fi...@wartek.belajar.id> #20
mg...@google.com <mg...@google.com>
ap...@google.com <ap...@google.com> #21
Branch: androidx-main
commit 59dd212495f4378911cbb310367743b2aae734a3
Author: Marcello Galhardo <mgalhardo@google.com>
Date: Wed May 29 17:49:02 2024
Make `LocalLifecycleOwner` backward compatible with Compose 1.6.*
Lifecycle 2.8.* requires Compose 1.7.* for correctness, but
Compose 1.7.* have not yet reached stable.
For allowing Lifecycle 2.8.* to be used with Compose 1.6.*, we are
introducing the following measures:
* When Lifecycle 2.8.* detects it's running with Compose 1.6.*, it
uses reflection to access the previous version of
`androidx.compose.ui.platform.LocalLifecycleOwner`.
* A custom Proguard rule has been added to prevent the obfuscation of
`androidx.compose.ui.platform.LocalLifecycleOwner` when using
Compose 1.6.*. This ensures the reflection approach works correctly.
We have tested these backward compatibility measures in various
scenarios, including:
* Projects with and without Navigation Compose integrated.
* Compose versions 1.6.* and 1.7.*.
* Builds both with and without Proguard obfuscation applied.
Please note that backward compatibility reflection will be removed once
Compose 1.7.* is stable. A Gradle dependency constraint should be
put in place to ensure smooth migration for clients.
Fixes:
Test: manual
Change-Id: I3d0666a88eb309aae9a5c60eacc6818f52dd0bfd
M lifecycle/lifecycle-runtime-compose/build.gradle
A lifecycle/lifecycle-runtime-compose/proguard-rules.pro
A lifecycle/lifecycle-runtime-compose/src/androidMain/kotlin/androidx/lifecycle/compose/LocalLifecycleOwner.android.kt
M lifecycle/lifecycle-runtime-compose/src/commonMain/kotlin/androidx/lifecycle/compose/LocalLifecycleOwner.kt
A lifecycle/lifecycle-runtime-compose/src/desktopMain/kotlin/androidx/lifecycle/compose/LocalLifecycleOwner.desktop.kt
ca...@careem.com <ca...@careem.com> #22
Looking at the
mg...@google.com <mg...@google.com> #23
Lifecycle 2.8.1 was released last week (May 29, 2024). The workaround was merged yesterday (June 4, 2024), so it is not included in version 2.8.1. Please note that the "Date: Wed May 29" in the CL header above is a metadata that indicates when the CL was created, not when it was merged.
We intend to include it in the very next release, Lifecycle 2.8.2.
va...@cloudkitchens.com <va...@cloudkitchens.com> #24
pr...@google.com <pr...@google.com> #25
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.lifecycle:lifecycle-runtime-compose:2.8.2
androidx.lifecycle:lifecycle-runtime-compose-android:2.8.2
androidx.lifecycle:lifecycle-runtime-compose-desktop:2.8.2
li...@gmail.com <li...@gmail.com> #26
eg...@gmail.com <eg...@gmail.com> #27
Can confirm, the issue reproduces on release build
[Deleted User] <[Deleted User]> #28
ma...@gmail.com <ma...@gmail.com> #29
kr...@gmail.com <kr...@gmail.com> #30
Same for me too. I updated the Lifecycle lib to v2.8.2 and Compose BOM to v2024.06.00 which incorporate v1.6.8 of Compose libs. Still, the app got this exception and crashed, but only in the release mode and not in debug mode. Unfortunately, I got the crash in the production app after its release. After downgrading the Lifecycle lib to v2.7.0, it is working fine in the production app. Immediately, I had to release another patch version, so the users do not complain about app not working.
mg...@google.com <mg...@google.com> #31
We have received a similar report at -keep class androidx.compose.ui.platform.AndroidCompositionLocals_androidKt { *; }
to your ProGuard rules).
Although we have included a custom ProGuard rule as part of our fix, the rule is not working as intendend across all projects. We are currently investigating the problem, see
ba...@gmail.com <ba...@gmail.com> #32
Updating to 2.8.2 with Compose BOM "2024.06.00" the app is crashing on Release build with the error "CompositionLocal LocalLifecycleOwner not present".
A proguard rules should be provided or another version with fix.
su...@gmail.com <su...@gmail.com> #33
However, for the visitors
"-keep class androidx.compose.ui.platform.AndroidCompositionLocals_androidKt { *; }"
Add this to your app proguard file and it'll work fine.
ih...@enverus.com <ih...@enverus.com> #34
mo...@gmail.com <mo...@gmail.com> #35
I can confirm it's still an issue for me with Compose BOM "2024.06.00" and lifecycle 2.8.2.
I added these lines to proguard to fix the issue:
-if public class androidx.compose.ui.platform.AndroidCompositionLocals_androidKt {
public static *** getLocalLifecycleOwner();
}
-keep public class androidx.compose.ui.platform.AndroidCompositionLocals_androidKt {
public static *** getLocalLifecycleOwner();
}
mg...@google.com <mg...@google.com> #36
Following up on the issue mentioned in
mg...@google.com <mg...@google.com> #37
Following up on the issue mentioned in
mg...@google.com <mg...@google.com> #38
Lifecycle 2.8.3 is now available on
pr...@google.com <pr...@google.com> #39
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
Description
Version used:
lifecycle-runtime-compose:2.8.0-alpha03
androidx.compose.ui:ui-android:1.7.0-alpha03
When
Devices/Android versions reproduced on: Android14
When running collectAsStateWithLifecycle in setContent inside the fragment, the following error occurs.
Could any of the changes in lifecycle 2.8.0-alpha03 be caused by LocalLifecycleOwner's has different directory?
"LocalLifecycleOwner moved from Compose UI to lifecycle-runtime-compose so that its Compose-based helper APIs can be used outside of Compose UI"
java.lang.IllegalStateException: CompositionLocal LocalLifecycleOwner not present
at androidx.lifecycle.compose.LocalLifecycleOwnerKt$LocalLifecycleOwner$1.invoke(LocalLifecycleOwner.kt:26)
at androidx.lifecycle.compose.LocalLifecycleOwnerKt$LocalLifecycleOwner$1.invoke(LocalLifecycleOwner.kt:25)
at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:74)
at androidx.compose.runtime.LazyValueHolder.getCurrent(ValueHolders.kt:29)
at androidx.compose.runtime.LazyValueHolder.getValue(ValueHolders.kt:31)
at androidx.compose.runtime.CompositionLocalMapKt.read(CompositionLocalMap.kt:90)
at androidx.compose.runtime.ComposerImpl.consume(Composer.kt:2135)
at androidx.lifecycle.compose.FlowExtKt.collectAsStateWithLifecycle(FlowExt.kt:180)