IssueTracker

That workaround works well for us, thanks a ton! Looking forward to the permanent fix.

Are there any updates regarding this issue? We are still facing these crashes in our production app and it seems like the fix was never merged.

We have also been continuing to see this in production. I've updated the sample in comment 0 to the latest BOM and still crashes. Any updates on the fix in the libraries?

Bumping this thread again - the fix in comment #3 was never merged and we're still having issues with this crash in prod without clear repro steps. Is this fix still being considered?

Sorry, I should've abandoned that CL a while ago — we decided we didn't want to pursue that particular change for some subtle implications that it had.

I think we concluded that a better way to solve this issue on our end is to:

• Add a platform API to expose ViewOverlay.OverlayViewGroup.mHostView publicly
• Add an appcompat API to backport the hostView property to older SDKs via reflection
• Update findViewTreeLifecycleOwner() to traverse the host view of a ViewOverlayGroup instead of its parent

OK - Is that work planned for a future release then?

Checking in on this bug since we're seeing high volumes in production and are considering rolling back Compose features.

I've started working on the platform component of the bugfix I mentioned in comment#11. The appcompat and lifecycle changes will follow it and should be easier to land. The good news, by the way, is that we won't need to wait for a platform update to be able to ship the androidx changes. And when the fix does land, you should only need to update your appcompat and lifecycle dependencies.

Once the androidx changes get published in a CL, they'll be linked here automatically and you can watch the progress more directly. The platform fixes are also technically linked here (see the Pending Code Changes in the right sidebar), but since they're in AOSP they won't be externally visible.

Just spoke with Andrew who informed me that the fix is well underway, and the hope is that it'll land within the next 6 weeks.

Hey all, quick update here.

We've partially landed this fix. There's one more CL to land before this issue will be addressed, plus some other follow-up work that's not relevant for this specific bug.

In the short term: You will be able to receive this fix by upgrading to androidx.transition:transition:1.6.0-alpha01 when it is released (Probably in mid-December, but possibly in mid-January because of the upcoming US holidays). That will also upgrade androidx.core:core to its latest version (which will probably be 1.16.0-alpha01) and introduce a new dependency on androidx.core:core-viewtree:1.0.0-alpha01, which is a new module we introduced as part of this change. You will not need to update any Compose dependencies to get the bug fix.

In the long term: We're planning to include a transitive dependency bump as part of the compose-ui 1.9.0 alphas. This bug will stay open until that happens. At some point, this will also work its way into a BOM, but I can't say when. We also can't include this in 1.8.0, unfortunately, because Compose is moving into beta soon, and beta libraries can't depend on core-viewtree since it's in alpha currently.

Project: platform/frameworks/support
Branch: androidx-main
Author: Andrew Bailey <anbailey@google.com>
Link:      https://android-review.googlesource.com/3201994

Set disjoint parents in transition overlays

Set disjoint parents in transition overlays 
 
Test: ComposeViewOverlayTest, in follow-up CL 
Bug: b/340894487, b/287484338 
Relnote: """ 
    Transition now sets the disjoint parent for ViewOverlays used to 
    animate its transitions. This allows for the resolution of owners 
    through the disjoint parent, which means you can now correctly 
    resolve ViewModels, lifecycles, etc. during a transition. 
    """ 
Change-Id: I10a16c84ba1efbf89a503418889ddd56bb711bed

androidx.transition:transition:1.6.0-alpha01 is included in today's androidx release. For everyone running into this issue, please upgrade your transition dependency to this version.

The next steps on our end are to bump the transition version that Compose UI depends on, which needs to wait until we bump the androidx-main branch to Compose 1.9.0-alpha01.

Bugjuggler: wait 2 months

FYI I'm still seeing this crash with Transition 1.6.0-alpha01.

Stacktrace:

java.lang.IllegalStateException: ViewTreeLifecycleOwner not found from android.view.ViewOverlay$OverlayViewGroup{2f4358c V.E...... ......ID 0,0-1080,2138}
       	at androidx.compose.ui.internal.InlineClassHelperKt.throwIllegalStateExceptionForNullCheck(InlineClassHelper.kt:30)
       	at androidx.compose.ui.platform.WindowRecomposer_androidKt.createLifecycleAwareWindowRecomposer(WindowRecomposer.android.kt:466)
       	at androidx.compose.ui.platform.WindowRecomposer_androidKt.createLifecycleAwareWindowRecomposer$default(WindowRecomposer.android.kt:327)
       	at androidx.compose.ui.platform.WindowRecomposerFactory$Companion.LifecycleAware$lambda$0(WindowRecomposer.android.kt:170)
       	at androidx.compose.ui.platform.WindowRecomposerFactory$Companion.$r8$lambda$FWAPLXs0qWMqekhMr83xkKattCY(Unknown Source:0)
       	at androidx.compose.ui.platform.WindowRecomposerFactory$Companion$$ExternalSyntheticLambda0.createRecomposer(D8$$SyntheticClass:0)
       	at androidx.compose.ui.platform.WindowRecomposerPolicy.createAndInstallWindowRecomposer$ui_release(WindowRecomposer.android.kt:226)
       	at androidx.compose.ui.platform.WindowRecomposer_androidKt.getWindowRecomposer(WindowRecomposer.android.kt:302)
       	at androidx.compose.ui.platform.AbstractComposeView.resolveParentCompositionContext(ComposeView.android.kt:251)
       	at androidx.compose.ui.platform.AbstractComposeView.ensureCompositionCreated(ComposeView.android.kt:258)
       	at androidx.compose.ui.platform.AbstractComposeView.onAttachedToWindow(ComposeView.android.kt:290)
       	at android.view.View.dispatchAttachedToWindow(View.java:21980)
       	at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:3490)
       	at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:3497)
       	at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:3497)
       	at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:3497)
       	at android.view.ViewGroup.addViewInner(ViewGroup.java:5318)
       	at android.view.ViewGroup.addView(ViewGroup.java:5104)
       	at android.view.ViewGroup.addView(ViewGroup.java:5044)
       	at android.view.ViewGroup.addView(ViewGroup.java:5016)
       	at android.view.ViewOverlay$OverlayViewGroup.add(ViewOverlay.java:209)
       	at android.view.ViewGroupOverlay.add(ViewGroupOverlay.java:72)
       	at androidx.core.view.ViewCompat.addOverlayView(ViewCompat.java:2854)
       	at androidx.transition.TransitionUtils.createViewBitmap(TransitionUtils.java:103)
       	at androidx.transition.TransitionUtils.copyViewImage(TransitionUtils.java:64)
       	at androidx.transition.Visibility.onDisappear(Visibility.java:400)
       	at androidx.transition.Visibility.createAnimator(Visibility.java:254)
       	at androidx.transition.Transition.createAnimators(Transition.java:789)
       	at androidx.transition.TransitionSet.createAnimators(TransitionSet.java:458)
       	at androidx.transition.TransitionSet.createAnimators(TransitionSet.java:458)
       	at androidx.transition.Transition.playTransition(Transition.java:1912)
       	at androidx.transition.TransitionManager$MultiListener.onPreDraw(TransitionManager.java:301)
       	at android.view.ViewTreeObserver.dispatchOnPreDraw(ViewTreeObserver.java:1176)
       	at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3772)
       	at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2465)
       	at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:9305)
       	at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1339)
       	at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1348)
       	at android.view.Choreographer.doCallbacks(Choreographer.java:952)
       	at android.view.Choreographer.doFrame(Choreographer.java:882)
       	at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1322)
       	at android.os.Handler.handleCallback(Handler.java:958)
       	at android.os.Handler.dispatchMessage(Handler.java:99)
       	at android.os.Looper.loopOnce(Looper.java:205)
       	at android.os.Looper.loop(Looper.java:294)
       	at android.app.ActivityThread.main(ActivityThread.java:8177)
       	at java.lang.reflect.Method.invoke(Native Method)

I was able to resolve the specific flavor of the crash described in #21 - the cause was a particular test screen that used android.R.id.content as a Fragment container for transactions. Setting up that test Activity with an actual layout file with a FragmentContainerView to host the Fragments resolved the crash.