Status Update
Comments
su...@gmail.com <su...@gmail.com> #2
Can you try with the latest snapshot? Not reproducible for me on androidx-main.
su...@gmail.com <su...@gmail.com> #3
Ok, after trying a couple more versions, realized this is a duplicate of
From the release notes:
AndroidView's update callback's first invocation will now be defered until the view is attached, instead of running when the composition that introduces the AndroidView is applied. This fixes a bug where the update callback wouldn't be invalidated if a state it read was changed immediately by an effect. (Ie9438,
) b/291094055
Sorry for the confusion!
st...@gmail.com <st...@gmail.com> #4
I would try to also remove all the scaffolds to make sure it's not a problem with sub composition. Seeing that constraint layout has a similar crash I feel like this is a likely problem here.
su...@gmail.com <su...@gmail.com> #6
Update
The crashes seem to come when I use sharedtransition in a top bar, large, medium, all of them
ti...@google.com <ti...@google.com> #7
Could you share a minimal repro project please? That'd help us speed up the investigation. Thanks.
ti...@google.com <ti...@google.com> #8
The stacktrace in sharedBounds
modifier happened before the lookaheadRoot is initialized in SharedTransitionScope. It's unclear what would cause that. A minimal repro would help reveal the root cause.
su...@gmail.com <su...@gmail.com> #9
reproduction on
the glance widget has a backlink directly to the second screen.
removing the app bar solves the problem.
ma...@gmail.com <ma...@gmail.com> #10
After testing with / without various configurations of Scaffold, the issue seems to be from having the shared element transition specifically inside the title composable.
ro...@ebay.com <ro...@ebay.com> #11
This is another issue, mentioning a SharedTransitionLayout bug with the 1.7.0-beta01:
su...@gmail.com <su...@gmail.com> #13
This is still a challenge and no details on if it has been reproduced internally
ti...@google.com <ti...@google.com> #14
Re #10:
I'm unable to repro any crash with the tip of the tree compose code base. Could you confirm the gist still crashes with the latest compose release?
ti...@google.com <ti...@google.com> #15
Re
Which compose release do you see the crash in? We would love to get a minimal repro to investigate the issue.
ti...@google.com <ti...@google.com> #16
The attached video shows what I get with the gist in
ca...@gmail.com <ca...@gmail.com> #17
I'm able to reproduce what I assume is the same issue. It only happens on 2 conditions:
- The composable with the transition applied is in the first destination opened in the app
- The sharedBounds modifier is applied to the title of the TopAppBar (applying to actions in the TopAppBar does not crash, for instance)
su...@gmail.com <su...@gmail.com> #18
I believe #17 is the same issue
ca...@gmail.com <ca...@gmail.com> #19
I was able to hack around the issue by waiting for the TopAppBar title to be positioned before applying the sharedBounds modifier to the start destination screen:
var hasPositioned by remember { mutableStateOf(false) }
val modifier = if (hasPositioned) {
Modifier.sharedBounds(...),
} else {
Modifier.onGloballyPositioned { hasPositioned = true }
}
ca...@gmail.com <ca...@gmail.com> #20
The app also crashes on rotation with this same error. If you still need a repro app let me know and I can spend an evening working on that.
Description
Jetpack Compose version: "1.7.0-beta02"
Jetpack Compose component used: Android Studio Build: Kotlin version: 2.0.0
Steps to Reproduce or Code Sample to Reproduce:
more details on stackoverflow athttps://stackoverflow.com/questions/78565098/app-crashes-when-opening-from-a-deeplink-and-using-sharedtransition-api
Stack trace (if applicable):