A modern programming language that makes developers happier.

kotlinlang

Upgraded to AndroidX Lifecycle `2.8.0` and now get a crash right when the app starts. Anyone else?

```java.lang.IllegalStateException: CompositionLocal LocalLifecycleOwner not present```

Is this same issue?

<https://issuetracker.google.com/issues/336842920#comment2>

Seems so :see_no_evil: So Lifecycle `2.8.0` can only be used with Compose UI `1.7.0` which however is still beta :grimacing:

Or you can just provide that local yourself. Fetch the right owner from the old local, and give it to the new local :wink:

This crash is coming internally from Compose. Haven’t done anything with `LocalLifecycleOwner` before with Lifecycle `2.7.0` so I wouldn’t even know where to start :shrug::skin-tone-3: I just wait for Compose UI `1.7.0`.

Wrap your entire app with
`CompositionLocalProvider(new.package.LocalLifecycleOwner provides old.package.LocalLifecycleOwner.current)` 

Just like you'd provide any composition local

There are two versions of the composition local, that's all. And if you're mix and matching versions, you need both locals to be present

Well the <https://developer.android.com/jetpack/androidx/releases/lifecycle#2.8.0|release notes> state

> `LocalLifecycleOwner` has been moved from Compose UI to `lifecycle-runtime-compose` so that its Compose-based helper APIs can be used outside of Compose UI.
so it didn’t even come to my mind that the package was moved. I thought it was only moved to a new module.
Also it would have been nice if they mentioned the incompatibility with Compose UI `1.6` there because I usually don’t follow every alpha and beta release.

"was moved" implies that there are now two of them of course.
They can't just delete the old one and break compatibility with the world. The local now exists in both places, and the old UI module couldn't have known the future to already provide both locals.

&gt; “was moved” implies that there are now two of them of course.
I guess they could have moved `LocalLifecycleOwner` to a new artifact / module under the *same package* and it would have worked unless other dependencies still depend on `2.7.0`. Then we probably would get a compilation error because of multiple classes in the classpath :shrug::skin-tone-3:

Either way, thanks for your workaround. But I rather wait for Compose UI `1.7.0` as there is nothing in Lifecycle `2.8.0` that I desperately need.

If it was kept on the same package it would make no sense in the future for the new users that they want to support by doing this move. If they imported compose.ui it would be super confusing in non UI contexts.
And it would introduce a name clash where if you got both artifacts imported and now we'd be discussing that problem instead :sweat_smile:

Well, Compose Multiplatform developers also work with `androidx.*` package names although they might not even develop for Android :zany_face:

That's definitely another big story but that one is I am afraid way too late to fix now