IssueTracker

I encountered the same issue, i just assumed it was done intendently.

Same issue. Honestly, this API is very confusing. Basically, to indicate that FragmentA should be popped from backstack when navigating to FragmentB, action options need to declare FragmentB as primary destination and as popUpTo destination with inclusivity flag as true.

<fragment
        android:id="@+id/fragmentA"
        android:name="com.test.FragmentA">
        <action
            android:id="@+id/action_a_to_b"
            app:popUpTo="@id/fragmentB"
            app:popUpToInclusive="true"
            app:destination="@id/fragmentB" />
</fragment>

With 'clearTask' flag it was clearer that everything before new destination will be popped. Although 'clearTask' itself was ambiguous cause it comes from Activity's launch options.

I have tried setting "FragmentB" in a "popUpToInclusive=true" action as both "destination" and "popUpTo", but still I cannot achieve this behavior. Is it possible at all on alpha02?

Demoed on top of navigation code lab:

https://github.com/googlecodelabs/android-navigation/compare/master...zbigniew-malinowski:clear_stack_problem

For me also "clearTask" was more intuitive, maybe "clearBackstack" name would be less ambiguous?

This has been fixed internally and will be available in alpha03.

As per the Principles of Navigation (https://developer.android.com/topic/libraries/architecture/navigation/navigation-principles), you should structure your navigation graph and your app around having a fixed start destination that serves as a signpost for users that the next time they hit the system back button, they'll go back to the launcher. This, in many cases, precludes the need to remove the initial start destination from the back stack.

The Implement Conditional Navigation page (https://developer.android.com/topic/libraries/architecture/navigation/navigation-conditional) explains the suggested approach where navigation destinations such as onboarding, login, etc. are something that should be launched only as needed from the fixed start destination / elsewhere in your graph rather than be used as the start destination of your graph entirely. We're working on fleshing out the Conditional Navigation page with further examples and code on how to approach this common scenario.

Any update on when alpha03 will drop?

@5 Are you suggesting that the start Fragment would just check which Fragment to navigate to right away, such as login/permissions/onboarding,  vs the rest?
This Fragment won't have any UI ..

Why this weird solution, instead of just setting a new root to the graph and switch to it?
If at some point, for example, a core permission was found not to be granted, we could set to switch to the permissions Fragment and make it the new root.
Or, if the user has chosen to logout, we could set to switch to the login Fragment and make it the new root.

What you suggest is to just pop all to the same Fragment, and let it choose instead?

Any news or updates? I change the startDestination and want to remove the first-started fragment, before go next. I can't do it. setPopUpTo doesn't work, popBackStack just closes the activity. From time to time I check the jetpack navigation - it becomes better, but it's still to raw. Old school navigation or Cicerone work simpler and better