IssueTracker

Would it be possible to add a NavDirections overload to NavDeepLinkBuilder for this? It has both the id and the args so it's a nice way to add destination. I can also create an extra ticket.

Currently deep links always start with the nav_graph's startDestination. This is a problem for apps which use multiple root-level destinations in a bottom-navigation view, and unexpected for explicitly created synthetic task stacks using only addDestination().

I'm using an invocation like: navDeeplinkBuilder.addDestinaton(frag_two).addDestination(frag_three), where start_destination = frag_one. Using an initial setDestination doesn't seem to change anything. frag_one is always at the bottom of the back stack, with two and three above.

After building the deep link, I can see the first R.id is always 0 (or the android:id of the nav_graph, if you remembered to set one), as a result of NavDeepLinkBuilder's node.buildDeepLinkIds(prevdestination)

When navController receives the deep link, it will attempt to navigate to 0 (the navGraph itself), which NavGraphNavigator always substitutes with the startDestination.

Separately, the navGraph will be explicitly added above it as the parent of that startDestination using the mGraph id set on the end Fragment. link

So it seems like both NavDeepLinkBuilder and NavController are attempting to set the mGraph to the bottom of the task stack. I think the initial navGraph should just be implicit in the NavDeepLinkBuilder-created Intent, since there's already a stated dependency on the navGraph being the same at Intent-build-time and when the deep link is executed.

Quick update:

I was able to repro and investigate the issue. It is indeed related to how the save and restore is set up. What I am seeing is the size change animation is accessing a stale AnimatedContentTransitionScope instance and therefore it operates on the wrong info.

Now I'm in the process to create a minimal repro that can be added to the test to verify a potential fix.

Project: platform/frameworks/support
Branch: androidx-main
Author: Doris Liu <tianliu@google.com>
Link:      https://android-review.googlesource.com/3312267

Update SizeAnimation internal state when transition is recreated

Update SizeAnimation internal state when transition is recreated

This change ensures that the size animtion reads the up-to-date
target sizes when AnimatedContent is being
re-used for different transitions.

Test: New tests added
Bug: 372512085
Change-Id: I7b0569287fb5e7e59be5226d827fdbcf90e46733

Verified the fix above with repro in comment #7. Please feel free to try out the new fix with snapshot: https://androidx.dev/snapshots/builds/12514980/artifacts

Can confirm it's fixed in my main app too.

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

• androidx.compose.animation:animation:1.8.0-alpha05
• androidx.compose.animation:animation-android:1.8.0-alpha05
• androidx.compose.animation:animation-jvmstubs:1.8.0-alpha05
• androidx.compose.animation:animation-linuxx64stubs:1.8.0-alpha05