IssueTracker

Is there any update on this issue? I can see pending code changes linked to this bug, but they are not yet merged (seems like CR is hanging without any action for a few months already).

Project: platform/frameworks/support
Branch: androidx-main
Author: Chet Haase <chet@google.com>
Link:      https://android-review.googlesource.com/2902007

Make use of View tags thread-safe, and simplify delegate scheduling

Make use of View tags thread-safe, and simplify delegate scheduling 
 
We stash a single library-wide instance of our pre draw listener on 
the DecorView on lower API levels. This could previously happen from a 
couple of different threads, and View tags are not thread safe, which 
can cause potential race condition errors if the underlying tag 
storage is accessed in parallel from different threads. 
 
This fix posts any changes to both the onPreDrawListener and the tags 
to happen from the main thread to make them safe. 
 
This also removes unnecessary logic from the onPreDraw loop itself, 
since delegates cannot be scheduled for addition or removal during the 
loop due to the synchronized block. 
 
This fix also simplifies logic of singleFrameState removal (it now 
happens while processing frames directly, on the following frame), 
which gets rid of the need to synchronously get and use the state 
holder from the FrameMetrics thread. 
 
Bug: 311218678 
Test: Manual testing to verify correct threading behavior, JankStatsTests passes 
Relnote: Fix crashes `DelegatingFrameMetricsListener cannot be cast...` 
 
Change-Id: Id891c0cfdd7f45ef9e3b068644a113f39c8fc383

I still see issues in the API24+ impl, reopening.

Project: platform/frameworks/support
Branch: androidx-main
Author: Chris Craik <ccraik@google.com>
Link:      https://android-review.googlesource.com/3512010

Improve tag/listener update safety on API 24+

Improve tag/listener update safety on API 24+ 
 
Improve JankStats API 24 impl to reduce thread hops and simplify 
delegate iteration/adding/removal. This brings the API 24 impl to be 
much closer to the API 16 implementation. 
 
Also ensures that delegates and window frame metrics available 
listeners are consistently set on main thread. 
 
Test: JankStatsTest 
Fixes: 311218678 
 
Change-Id: I2ab7c892ae114708f3cd8e80f180ab73e32b9d11

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

• androidx.metrics:metrics-performance:1.0.0-beta02

This fix was released yesterday with androidx.metrics:metrics-performance:1.0.0-beta02, see https://developer.android.com/jetpack/androidx/releases/metrics#1.0.0-beta02.

Please try it out and let us know if it doesn't address the problem.

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.