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.

Yigit, do you have time to fix it?

reemission of the same liveData is racy

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

yea i'll take it.

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

Thanks for the detailed analysis. This may not be an issue anymore since we've started using Main.immediate there but I' not sure; I'll try to create a test case.

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

just emitting same live data reproduces the issue.

@Test
fun raceTest() {
val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData)
emitSource(subLiveData) //crashes
}
subject.addObserver().apply {
testScope.advanceUntilIdle()
}
}

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

With 2.2.0-alpha04 (that use Main.immediate), the issue seems to be still there (I tested it by calling emitSource() twice, like your test case)

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

yea sorry immediate does not fix it.
I actually have a WIP fix for it:

https://android-review.googlesource.com/c/platform/frameworks/support/+/1112186

if your case is the one i found (emitting same LiveData multiple times, as shown in #5) you can work around it by adding a dummy transformation.

val subLiveData = MutableLiveData(1)
val subject = liveData(testScope.coroutineContext) {
emitSource(subLiveData.map {it })
emitSource(subLiveData.map {it} )
}

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

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

commit af12e75e6b4110f48e44ca121466943909de8f06
Author: Yigit Boyar <yboyar@google.com>
Date: Tue Sep 03 12:58:11 2019

Fix coroutine livedata race condition

This CL fixes a bug in liveData builder where emitting same
LiveData source twice would make it crash because the second
emission registry could possibly happen before first one is
removed as source.

We fix it by using a suspending dispose function. It does feel
a bit hacky but we cannot make DisposableHandle.dispose async
and we do not want to block there. This does not mean that there
is a problem if developer disposes it manually since our emit
functions take care of making sure it disposes (and there is
no other way to add source to the underlying MediatorLiveData)

Bug: 140249349
Test: BuildLiveDataTest#raceTest_*

Change-Id: I0b464c242a583da4669af195cf2504e2adc4de40

M lifecycle/lifecycle-livedata-ktx/api/2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/current.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/public_plus_experimental_current.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_2.2.0-alpha05.txt
M lifecycle/lifecycle-livedata-ktx/api/restricted_current.txt
M lifecycle/lifecycle-livedata-ktx/src/main/java/androidx/lifecycle/CoroutineLiveData.kt
M lifecycle/lifecycle-livedata-ktx/src/test/java/androidx/lifecycle/BuildLiveDataTest.kt

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

https://goto.google.com/android-sha1/af12e75e6b4110f48e44ca121466943909de8f06

[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.