Unknown destination during deep link when there are multiple NavHostFragment [121340440]

Fixed

Bug

Status Update

No update yet.

Description

[Deleted User]

created issue #1

Dec 21, 2018 04:53PM

Component used: Navigation
Version used: 1.0.0-alpha09
Devices/Android versions reproduced on: Android 9 emulator

In our app, we use multiple NavHostFragment in one Activity, few of them have their own navGraph set in xml, say nav_subgraph_1, nav_subgraph_2.

In code, we use NavDeepLinkBuilder to navigate to a specified page.
NavDeepLinkBuilder(it)
.setGraph(R.navigation.nav_subgraph_1)
.setDestination(R.id.dest_in_subgraph1)
.createTaskStackBuilder()
.startActivities()

It leads a crash in setContentView since the dest_in_subgraph1 couldn't be found in nav_subgraph_2 (while parsing the second NavHostFragment in the same Activity)

Crash log:
E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.testapp.mobile.android.staging.debug, PID: 12615
java.lang.RuntimeException: Unable to start activity ComponentInfo{com.testapp.mobile.android.staging.debug/com.testapp.mobile.android.ui.HomeActivity}: android.view.InflateException: Binary XML file line #85: Binary XML file line #85: Error inflating class fragment
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2913)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3048)
at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:78)
at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:108)
at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:68)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1808)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:193)
at android.app.ActivityThread.main(ActivityThread.java:6669)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)
Caused by: android.view.InflateException: Binary XML file line #85: Binary XML file line #85: Error inflating class fragment
Caused by: android.view.InflateException: Binary XML file line #85: Error inflating class fragment
Caused by: java.lang.IllegalStateException: unknown destination during deep link: com.testapp.mobile.android.staging.debug:id/an_id_set_in_graph
at androidx.navigation.NavController.onHandleDeepLink(NavController.java:546)
at androidx.navigation.NavController.onGraphCreated(NavController.java:466)
at androidx.navigation.NavController.setGraph(NavController.java:421)
at androidx.navigation.fragment.NavHostFragment.onCreate(NavHostFragment.java:221)
at android.support.v4.app.Fragment.performCreate(Fragment.java:2414)
at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1418)
at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1684)
at android.support.v4.app.FragmentManagerImpl.addFragment(FragmentManager.java:1930)
at android.support.v4.app.FragmentManagerImpl.onCreateView(FragmentManager.java:3745)
at android.support.v4.app.FragmentController.onCreateView(FragmentController.java:120)
at android.support.v4.app.FragmentActivity.dispatchFragmentsOnCreateView(FragmentActivity.java:405)
at android.support.v4.app.FragmentActivity.onCreateView(FragmentActivity.java:387)
at android.view.LayoutInflater.createViewFromTag(LayoutInflater.java:780)
at android.view.LayoutInflater.createViewFromTag(LayoutInflater.java:730)
at android.view.LayoutInflater.rInflate(LayoutInflater.java:863)
at android.view.LayoutInflater.rInflateChildren(LayoutInflater.java:824)
at android.view.LayoutInflater.rInflate(LayoutInflater.java:866)
at android.view.LayoutInflater.rInflateChildren(LayoutInflater.java:824)
at android.view.LayoutInflater.inflate(LayoutInflater.java:515)
at android.view.LayoutInflater.inflate(LayoutInflater.java:423)
at android.view.LayoutInflater.inflate(LayoutInflater.java:374)
at android.support.v7.app.AppCompatDelegateImpl.setContentView(AppCompatDelegateImpl.java:469)
at android.support.v7.app.AppCompatActivity.setContentView(AppCompatActivity.java:140)
at com.testapp.mobile.android.ui.HomeActivity.onCreate
at android.app.Activity.performCreate(Activity.java:7136)
at android.app.Activity.performCreate(Activity.java:7127)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1271)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2893)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3048)
at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:78)
E/AndroidRuntime: at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:108)
at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:68)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1808)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:193)
at android.app.ActivityThread.main(ActivityThread.java:6669)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)

Comments

il...@google.com <il...@google.com> Jan 2, 2019 09:12PM

Assigned to il...@google.com.

il...@google.com <il...@google.com> Jan 14, 2019 09:50PM

Accepted by il...@google.com.

il...@google.com <il...@google.com> #2Jan 15, 2019 10:40PM

Marked as fixed.

Project: platform/frameworks/support
Branch: androidx-master-dev

commit d92e6ab2da02250bfbff957f733a4a2aaaf0c82c
Author: Ian Lake <ilake@google.com>
Date: Thu Jul 09 16:04:11 2020

Allow multiple destinations in NavDeepLinkBuilder

Expand the ability of NavDeepLinkBuilder to support
adding multiple destinations. This allows developers
to effectively build a custom synthetic back stack
that goes through multiple destinations in the same
graph or through destinations in separate graphs.

This augments, not replaces, the existing synthetic
back stack logic: the start destinations of any
graphs needed to make the chosen destination visible
*are* still added to the back stack.

To maintain behavior compatibility, setArguments()
continues to apply the arguments set there to all
destinations created by the deep link. However, this
CL would be first step to also supporting arguments
at a destination level.

Test: newly added tests pass
Relnote: "`NavDeepLinkBuilder` now supports adding
multiple distinct destinations to the generated
back stack."
BUG: 147913689

Change-Id: I3ee0d5251ec1047774aa4e826b25a6d8cf4ec28d

M navigation/navigation-common/src/main/java/androidx/navigation/NavDestination.java
M navigation/navigation-common/src/test/java/androidx/navigation/NavDestinationTest.kt
M navigation/navigation-runtime/api/2.4.0-alpha01.txt
M navigation/navigation-runtime/api/current.txt
M navigation/navigation-runtime/api/public_plus_experimental_2.4.0-alpha01.txt
M navigation/navigation-runtime/api/public_plus_experimental_current.txt
M navigation/navigation-runtime/api/restricted_2.4.0-alpha01.txt
M navigation/navigation-runtime/api/restricted_current.txt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.java
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavDeepLinkBuilder.java

https://android-review.googlesource.com/1359698

li...@gmail.com <li...@gmail.com> #3Jan 23, 2020 11:33AM

Project: platform/frameworks/support
Branch: androidx-master-dev

commit cd8fc14c6f2ad77d563e726eb30aa36f324259d0
Author: Ian Lake <ilake@google.com>
Date: Fri Jul 10 13:22:43 2020

Support per destination arguments in NavDeepLinkBuilder

In addition to continuing to support setArguments()
as a way to set global arguments that apply to all
destinations, add an optional Bundle parameter to
setDestination() and addDestination() to allow per
destination arguments.

Test: updated tests pass
BUG: 147913689
Relnote: "`NavDeepLinkBuilder` now allows you to set
arguments at a per destination level in addition to
the global arguments set via `setArguments()`."

Change-Id: I3a18cbb67b5836db013804a6d6c468cb0bc22102

M navigation/navigation-runtime/api/2.4.0-alpha01.txt
M navigation/navigation-runtime/api/current.txt
M navigation/navigation-runtime/api/public_plus_experimental_2.4.0-alpha01.txt
M navigation/navigation-runtime/api/public_plus_experimental_current.txt
M navigation/navigation-runtime/api/restricted_2.4.0-alpha01.txt
M navigation/navigation-runtime/api/restricted_current.txt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavDeepLinkBuilderTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.java
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavDeepLinkBuilder.java

https://android-review.googlesource.com/1360905

[Deleted User] <[Deleted User]> #4Jan 28, 2020 08:58AM

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.

tu...@gmail.com <tu...@gmail.com> #5Feb 10, 2020 11:21AM

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.

pa...@gmail.com <pa...@gmail.com> #6Feb 26, 2020 08:31PM

Project: platform/frameworks/support
Branch: androidx-main

commit 64a958a72265aa72aae6dea6e78d531d0d5be096
Author: Faelyn O'Grady <fogrady@google.com>
Date: Wed Jul 21 13:20:11 2021

Fix deep link ids from a navGraph's id to one of its siblings.

For a nested NavGraph N with startDest=A, and another dest B in N:
addDestination(N)
addDestination(B)

Would previously result in:
[N, N, B]

This change fixes the result to:
[N, B]

(which implies [A, B], since A is the startDest)

Because B's buildDeepLinkIds(prevDestination = N) would generate both [N, B], even though N was already navigated to (literally set as the previousDestination).

Test: New unit tests included. All existing tests pass.
BUG: 147913689
Change-Id: I42da530ebb72be1a90164416b7ca7f95e7834bba

M navigation/navigation-common/src/main/java/androidx/navigation/NavDestination.kt
M navigation/navigation-common/src/test/java/androidx/navigation/NavDestinationTest.kt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavDeepLinkBuilderTest.kt
A navigation/navigation-runtime/src/androidTest/res/navigation/nav_non_start_nest.xml

https://android-review.googlesource.com/1773621

su...@gmail.com <su...@gmail.com> #7Mar 2, 2020 09:12AM

Project: platform/frameworks/support
Branch: androidx-main

commit 793e098ad770115fda31a1ae1264a62bf85ca3ec
Author: Faelyn O'Grady <fogrady@google.com>
Date: Wed Jul 21 13:24:24 2021

Use explicit task stack in navigateUp() when on another app's stack.

This change uses the synthetic task stack created by the NavDeepLinkBuilder#addDestination() API when deep-linked on top of another app's task stack when the user navigates up, rather than generating a stack based on navGraph parenting rules.

Test: New unit tests included. All existing tests pass.
Change-Id: I58f4694022fec38f8c06f5901b3001a1a700a529
BUG: 147913689

M navigation/navigation-runtime/build.gradle
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavDeepLinkBuilder.kt

https://android-review.googlesource.com/1714510

ma...@gmail.com <ma...@gmail.com> #8Mar 4, 2020 02:31PM

findInvalidDestinationDisplayNameInDeepLink always return null if deepLink length == 1 (deep link destination is start destination of any navGraph of BottomNavigationView)

NavDestination node = i == 0 ? mGraph : graph.findNode(destinationId);
if deepLink.length == 1 node never will be null and this will cause IllegalStateException

Bug demo:

get NavigationAdvancedSample from github

on R.id.about_btn click

NavDeepLinkBuilder(it.context)
.setGraph(R.navigation.list)
.setDestination(R.id.leaderboard)
.createTaskStackBuilder()
.startActivities()

will crash because R.id.leaderboard is start destination (findInvalidDestinationDisplayNameInDeepLink will have deepLink length == 1)

NavDeepLinkBuilder(it.context)
.setGraph(R.navigation.list)
.setDestination(R.id.userProfile)
.createTaskStackBuilder()
.startActivities()

will work because findInvalidDestinationDisplayNameInDeepLink will return NOT null

[Deleted User] <[Deleted User]> #9Mar 11, 2020 05:07AM

It still crash with the latest version 2.2.1. I think the problem lies somewhere around this code

NavDestination node = i == 0 ? mGraph : graph.findNode(destinationId);

When i is 0, just return mGraph itself. When the deep link destination is a root of bottom_nav tab, the deeplink.length becomes 1. Which means this function still says there's no invalid Destination in deep link even if deepLink[0] is totally irrelevant tomGraph.

So this step passes and when findDestination() is actually triggered down the road, it won't find any destination and thus lead to unknown destination crash.

All NavControllers of bottom nav automatically call handleDeepLink() as part of onGraphCreated(). The problem arises the moment NavController whose graph is irrelevant to the root deep link destination calls handleDeepLink().

dr...@gmail.com <dr...@gmail.com> #10Mar 11, 2020 02:10PM

It still crashes with 2.3.0-alpha03 version but only if you try to deeplink to startDestination fragment inside navigation graph. Repro steps (described in #8, but lets repeat it in hope issue will be reopened):

download NavigationAdvancedSample
send pending intent to any startDestination screen, e.g.

val pendingIntent = NavDeepLinkBuilder(applicationContext)
                .setGraph(R.navigation.list)
                .setDestination(R.id.leaderboard)
                .setArguments(bundle) // no matter if it is empty in this use case
                .createPendingIntent()
pendingIntent.send()

Exception:

     Caused by: java.lang.IllegalStateException: unknown destination during deep link: com.example.android.navigationadvancedsample:id/list
        at androidx.navigation.NavController.handleDeepLink(NavController.java:689)
        at androidx.navigation.NavController.onGraphCreated(NavController.java:602)
        at androidx.navigation.NavController.setGraph(NavController.java:563)
        at androidx.navigation.NavController.setGraph(NavController.java:528)
        at androidx.navigation.fragment.NavHostFragment.onCreate(NavHostFragment.java:246)
        at androidx.fragment.app.Fragment.performCreate(Fragment.java:2684)
        at androidx.fragment.app.FragmentStateManager.create(FragmentStateManager.java:280)
        at androidx.fragment.app.FragmentManager.moveToState(FragmentManager.java:1175)
        at androidx.fragment.app.FragmentTransition.addToFirstInLastOut(FragmentTransition.java:1255)
        at androidx.fragment.app.FragmentTransition.calculateFragments(FragmentTransition.java:1138)
        at androidx.fragment.app.FragmentTransition.startTransitions(FragmentTransition.java:136)
        at androidx.fragment.app.FragmentManager.executeOpsTogether(FragmentManager.java:1989)
        at androidx.fragment.app.FragmentManager.removeRedundantOperationsAndExecute(FragmentManager.java:1947)
        at androidx.fragment.app.FragmentManager.execSingleAction(FragmentManager.java:1818)
        at androidx.fragment.app.BackStackRecord.commitNow(BackStackRecord.java:297)
        at com.example.android.navigationadvancedsample.NavigationExtensionsKt.obtainNavHostFragment(NavigationExtensions.kt:269)
        at com.example.android.navigationadvancedsample.NavigationExtensionsKt.setupWithNavController(NavigationExtensions.kt:61)
        at com.example.android.navigationadvancedsample.MainActivity.setupBottomNavigationBar(MainActivity.kt:121)
        at com.example.android.navigationadvancedsample.MainActivity.onCreate(MainActivity.kt:54)

Reopening would be a good sign that issue is recognized.

dr...@gmail.com <dr...@gmail.com> #11Mar 11, 2020 03:35PM

Just in a case Reopen feature is not implemented in IssueTracker :), new ticket is created: https://issuetracker.google.com/issues/151164638

mi...@gmail.com <mi...@gmail.com> #12Mar 11, 2020 03:43PM

I heard a rumour that instead of "Reopen" they implemented a "delete and block contributors" button 🙂

ne...@gmail.com <ne...@gmail.com> #13Mar 12, 2020 07:12PM

I would close it as "Working as Designed"😕

il...@google.com <il...@google.com> #14Mar 30, 2020 11:52PM

Filing a new bug with a sample project that reproduces the issue you're still seeing is indeed the correct behavior. We don't support bug necromancy, particularly 30 releases after the original fix was shipped.