Status Update
Comments
ri...@google.com <ri...@google.com> #2
Confirmed that the sample attached crashes for me too.
ri...@google.com <ri...@google.com> #4
A workaround for the issue until the above is merged, is to install a copy of the lifecycle owner into the view overlay parent.
The following prevents the crash in the attached sample:
sceneView.overlay.add(object : View(this) {
override fun onAttachedToWindow() {
super.onAttachedToWindow()
val parent = parent as ViewGroup
parent.setViewTreeLifecycleOwner(sceneView.findViewTreeLifecycleOwner())
parent.setViewTreeSavedStateRegistryOwner(sceneView.findViewTreeSavedStateRegistryOwner())
parent.removeView(this)
}
})
Make sure to invoke this at least once before calling beginDelayedTransition
.
di...@gmail.com <di...@gmail.com> #5
That workaround works well for us, thanks a ton! Looking forward to the permanent fix.
ni...@parshipgroup.com <ni...@parshipgroup.com> #6
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.
ek...@uber.com <ek...@uber.com> #7
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?
ek...@uber.com <ek...@uber.com> #8
Bumping this thread again - the fix in
at...@netflix.com <at...@netflix.com> #9
sa...@google.com <sa...@google.com> #10
an...@google.com <an...@google.com> #11
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
ek...@uber.com <ek...@uber.com> #12
OK - Is that work planned for a future release then?
ek...@uber.com <ek...@uber.com> #13
Checking in on this bug since we're seeing high volumes in production and are considering rolling back Compose features.
an...@google.com <an...@google.com> #14
I've started working on the platform component of the bugfix I mentioned in
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.
an...@google.com <an...@google.com>
do...@google.com <do...@google.com> #15
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.
an...@google.com <an...@google.com> #16
Hey all, quick update here.
We've partially landed this fix. There's
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.
ap...@google.com <ap...@google.com> #17
Project: platform/frameworks/support
Branch: androidx-main
Author: Andrew Bailey <
Link:
Set disjoint parents in transition overlays
Expand for full commit details
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
Files:
- M
fragment/integration-tests/testapp/build.gradle
- M
navigation/integration-tests/testapp/build.gradle
- M
transition/transition-ktx/build.gradle
- M
transition/transition/build.gradle
- M
transition/transition/src/main/java/androidx/transition/GhostViewHolder.java
- M
transition/transition/src/main/java/androidx/transition/TransitionUtils.java
- M
transition/transition/src/main/java/androidx/transition/Visibility.java
Hash: b4846dbfd6e1e98421fe44d673965622fb5e66a4
Date: Wed Jul 31 09:56:27 2024
an...@google.com <an...@google.com> #18
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
Description
Jetpack Compose version: 1.4.3
Jetpack Compose component used: UI, ComposeView
Android Studio Build: Android Studio Hedgehog | 2023.1.1 Canary 8 Build #AI-231.9011.34.2311.10290408
Kotlin version: 1.8.10
Steps to Reproduce:
Visibility
Transition
in which the RecyclerView disappears.recyclerView.smoothScrollToPosition()
to reveal the off-screen ComposeView.Sample project attached. Click any item (without scrolling) to run.
I'm seeing this crash infrequently in a production app, and while we should probably avoid calling
smoothScrollToPosition()
on a view that we know is disappearing, this ideally wouldn't crash. Not sure if this is more an issue with RecyclerView or Compose.Stack trace: