IllegalStateException: ViewTreeLifecycleOwner not found from android.view.ViewOverlay$OverlayViewGroup thrown when ComposeView is inside RecyclerView [340894487]

Assigned

Bug

Status Update

No update yet.

Description

at...@netflix.com

created issue #1

May 15, 2024 06:51PM

Jetpack Compose version: 1.6.7

Jetpack Compose component(s) used: ComposeView

Android Studio Build: Android Studio Jellyfish | 2023.3.1 Build #AI-233.14808.21.2331.11709847, built on April 12, 2024

Kotlin version: 1.9.23

Steps to Reproduce or Code Sample to Reproduce:

We have been seeing this compose crash in production, but have not been able to reproduce it. We are currently doing some Recyclerview + ComposeView interoperability - our screen is essentially one vertical RecyclerView. One of the items within this RecyclerView contains a ComposeView that is inflated from an XML layout. We see in our logging a back press occurs before many (if not all) of these crashes.

Here is some RecyclerView.Adapter related code that would be relevant:

override fun onBindViewHolder(viewHolder: ViewHolder, position: Int) {
    holder.composeView.setContent {
        NumberedPageIndicator(
            currentIndex = currentPage.intValue,
            pageCount = models.count(),
            modifier = Modifier.padding(vertical = 8.dp),
        )
    }

    statesSubscriptions = CompositeDisposable().apply {
        add(
            ...
        )
    }
}

override fun onViewRecycled(holder: Holder) {
    super.onViewRecycled(holder)
    holder.composeView.disposeComposition()
    statesSubscriptions?.let {
        it.dispose()
        statesSubscriptions = null
    }
}

Stack trace:

java.lang.IllegalStateException: ViewTreeLifecycleOwner not found from android.view.ViewOverlay$OverlayViewGroup{d78d62c V.E...... .......D 0,0-1080,2264}
        at androidx.compose.ui.platform.WindowRecomposer_androidKt.createLifecycleAwareWindowRecomposer(WindowRecomposer_androidKt:352)
        at androidx.compose.ui.platform.WindowRecomposer_androidKt.createLifecycleAwareWindowRecomposer$default(WindowRecomposer_androidKt:325)
        at androidx.compose.ui.platform.WindowRecomposerFactory$Companion.LifecycleAware$lambda$0(WindowRecomposerFactory:168)
        at androidx.compose.ui.platform.WindowRecomposerFactory$Companion.$r8$lambda$FWAPLXs0qWMqekhMr83xkKattCY(WindowRecomposerFactory)
        at androidx.compose.ui.platform.WindowRecomposerFactory$Companion$$ExternalSyntheticLambda0.createRecomposer(WindowRecomposerFactory)
        at androidx.compose.ui.platform.WindowRecomposerPolicy.createAndInstallWindowRecomposer$ui_release(WindowRecomposerPolicy:224)
        at androidx.compose.ui.platform.WindowRecomposer_androidKt.getWindowRecomposer(WindowRecomposer_androidKt:300)
        at androidx.compose.ui.platform.AbstractComposeView.resolveParentCompositionContext(AbstractComposeView:244)
        at androidx.compose.ui.platform.AbstractComposeView.ensureCompositionCreated(AbstractComposeView:251)
        at androidx.compose.ui.platform.AbstractComposeView.onAttachedToWindow(AbstractComposeView:283)
        at android.view.View.dispatchAttachedToWindow(View.java:21372)
        at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:3551)
        at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:3558)
        at android.view.ViewGroup.addViewInner(ViewGroup.java:5357)
        at android.view.ViewGroup.addView(ViewGroup.java:5137)
        at android.view.ViewGroup.addView(ViewGroup.java:5077)
        at androidx.recyclerview.widget.RecyclerView$5.addView(RecyclerView:950)
        at androidx.recyclerview.widget.ChildHelper.addView(ChildHelper:131)
        at androidx.recyclerview.widget.RecyclerView$LayoutManager.addViewInt(RecyclerView:9430)
        at androidx.recyclerview.widget.RecyclerView$LayoutManager.addView(RecyclerView:9388)
        at androidx.recyclerview.widget.RecyclerView$LayoutManager.addView(RecyclerView:9375)
        at androidx.recyclerview.widget.LinearLayoutManager.layoutChunk(LinearLayoutManager:1676)
        at androidx.recyclerview.widget.LinearLayoutManager.fill(LinearLayoutManager:1622)
        at androidx.recyclerview.widget.LinearLayoutManager.onLayoutChildren(LinearLayoutManager:687)
        at androidx.recyclerview.widget.RecyclerView.dispatchLayoutStep2(RecyclerView:4645)
        at androidx.recyclerview.widget.RecyclerView.dispatchLayout(RecyclerView:4348)
        at androidx.recyclerview.widget.RecyclerView.consumePendingUpdateOperations(RecyclerView:2106)
        at androidx.recyclerview.widget.RecyclerView$1.run(RecyclerView:468)
        at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1315)
        at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1323)
        at android.view.Choreographer.doCallbacks(Choreographer.java:956)
        at android.view.Choreographer.doFrame(Choreographer.java:863)
        at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1298)
        at android.os.Handler.handleCallback(Handler.java:942)
        at android.os.Handler.dispatchMessage(Handler.java:99)
        at android.os.Looper.loopOnce(Looper.java:201)
        at android.os.Looper.loop(Looper.java:288)
        at android.app.ActivityThread.main(ActivityThread.java:7937)
        at java.lang.reflect.Method.invoke(Method.java:-2)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:569)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1019)

Comments

ia...@google.com <ia...@google.com> #2Jun 12, 2024 12:15AM

> The Transition Kotlin extensions target the Framework Transition class which is a bit confusing

All extensions in 'core-ktx' target either 'core' or the framework types. This is working as expected. It sounds like this is a feature request for a transition-ktx with equivalent extensions for the androidx.transition types.

> as most framework classes are being deprecated in favor of their AndroidX counterparts, Fragments for example.

"Most"? This *dramatically* overstates what is actually happening. Fragments (and loaders) were added to the framework in a time where the Android team did not have external libraries for shipping features. Transition was added 5 years later.

mn...@google.com <mn...@google.com> Jun 13, 2024 06:36PM

Assigned to ry...@google.com.

ap...@google.com <ap...@google.com> #3Nov 13, 2024 09:28PM

Pardon my misunderstanding, I was under the belief that where possible, new features that could be developed outside the framework, would be under Androidx. Also it's a common refrain to use the Androidx libraries over the framework libraries where possible, as those ship update independently of platform releases. I wasn't attempting to be dramatic.

If the Transition api is unlikely to change, there is no need for a transition-ktx for androidx.transition types. If developers should use Androidx transitions over framework transitions where possible however, then it would be much appreciated.

I am well aware of the limitations that existed when Fragments and Loaders were created, and when the Transition api was introduced.

Issue 340894487

Description

Issue summary

Comments

ia...@google.com <ia...@google.com> #2Jun 12, 2024 12:15AM

mn...@google.com <mn...@google.com> Jun 13, 2024 06:36PM

ap...@google.com <ap...@google.com> #3Nov 13, 2024 09:28PM

Add comment

Issue metadata