IssueTracker

I don't know if this is something that can be changed, but I'll look into it.

Hmm... it is supposed to work like this, but you are seeing a bug.

It cou8ld be tricky to get this right because the onAnimationEnd() and onTransitionEnd() often modify the state. We must execute the Runnable only after the state has been changed to its final value.

I think it could be dangerous to make a change, but it is possible to run all the internal listeners first, then run all of the external ones with the Runnable executed between. Again, it wouldn't be safe because we can't guarantee that only the internal listeners change the system state.

Passing to Jeremy to get his thoughts

What we really need is a signal to say when all transitions are done and with it running early, we don't have that. For fragments this means that we could end up moving the fragment to RESUMED before all the transitions are actually completed and execute some code that is normally fine when the system is settled, but dangerous when it is not.

If moving onTransitionEnd() might be too dangerous are there other options? If you are in the animateToStart case should you even get an onTransitionEnd(). Maybe all external listeners get is an onTransitionCancel() since you are reversing a transition you started in the middle of it. Is that a safer signal to send back?

I think it is okay to separate the signals as long as they are explicit, but we for sure need a way to know that the Transition system is completely done doing any work and our Views are back in the original state that we passed them in.

Maybe you could notify at the end of your animateToStart lambda?

Per offline discussion, we can move ahead with the solution suggested in comment#4 and run external listeners last.

This will change the current order:

start transition > animateToStart > onTransitionEnd() > Runnable > finish up transition work

to

start transition > animateToStart > Runnable > finish up transition work > onTransitionEnd()


This has the implications that if developers are doing something with a specific result in their onTransitionEnd() callback, they will also need to handle the cancellation case by overriding the new onTransitionEnd(Transition, boolean).

For example, if there is a transition from View_A to View_B and the onTransitionEnd() callback has logic that expects View_B to be the final state, it will now need to add some additional logic based on the boolean in the case that View_A is the final state.

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.transition:transition:1.5.0-alpha06

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.