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.

For one of observables (single, maybe) we don't specify a subscvription thread so that developer can control where the action happens.
For flowables / observables; we always use the Room IO thread fo rthe actual query since we may repeat the work.

For LiveData, ti si always the Room IO Thread.

Until we can extend Room Query methods to receive non-query parameter (e.g. a Scheduler) we cannot do this.
At least room catches this instantly since it will crash w/ db access on main thread exception.

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

Hello Yigit, nice to meet you here! :)
Probably I should have described the problem more clearly.

I'm using Flowable, and hopefully it executes queries in background thread (at least, app does not crash with IllegalStateException, as with Single).

But nevertheless subscribing and disposing(!) does cause StrictMode violations. Stack trace examples:

D/StrictMode: StrictMode policy violation; ~duration=17 ms: android.os.StrictMode$StrictModeDiskWriteViolation: policy=31 violation=1
at android.os.StrictMode$AndroidBlockGuardPolicy.onWriteToDisk(StrictMode.java:1111)
at android.database.sqlite.SQLiteConnection.applyBlockGuardPolicy(SQLiteConnection.java:1043)
at android.database.sqlite.SQLiteConnection.execute(SQLiteConnection.java:552)
at android.database.sqlite.SQLiteSession.beginTransactionUnchecked(SQLiteSession.java:323)
at android.database.sqlite.SQLiteSession.beginTransaction(SQLiteSession.java:298)
at android.database.sqlite.SQLiteDatabase.beginTransaction(SQLiteDatabase.java:505)
at android.database.sqlite.SQLiteDatabase.beginTransaction(SQLiteDatabase.java:416)
at androidx.sqlite.db.framework.FrameworkSQLiteDatabase.beginTransaction(FrameworkSQLiteDatabase.java:69)
at androidx.room.InvalidationTracker.syncTriggers(InvalidationTracker.java:426)
at androidx.room.InvalidationTracker.syncTriggers(InvalidationTracker.java:465)
at androidx.room.InvalidationTracker.addObserver(InvalidationTracker.java:249)
at androidx.room.RxRoom$1.subscribe(RxRoom.java:79)
at io.reactivex.internal.operators.flowable.FlowableCreate.subscribeActual(FlowableCreate.java:71)
at io.reactivex.Flowable.subscribe(Flowable.java:14479)
at io.reactivex.internal.operators.flowable.FlowableObserveOn.subscribeActual(FlowableObserveOn.java:56)
at io.reactivex.Flowable.subscribe(Flowable.java:14479)
at io.reactivex.internal.operators.flowable.FlowableFlatMapMaybe.subscribeActual(FlowableFlatMapMaybe.java:54)
at io.reactivex.Flowable.subscribe(Flowable.java:14479)
at io.reactivex.Flowable.subscribe(Flowable.java:14416)
at io.reactivex.Flowable.subscribe(Flowable.java:14306)
at gmk57.strictroom.MainActivity.onCreate(MainActivity.java:30)

StrictMode policy violation; ~duration=108 ms: android.os.StrictMode$StrictModeDiskWriteViolation: policy=31 violation=1
at android.os.StrictMode$AndroidBlockGuardPolicy.onWriteToDisk(StrictMode.java:1111)
at android.database.sqlite.SQLiteConnection.applyBlockGuardPolicy(SQLiteConnection.java:1043)
at android.database.sqlite.SQLiteConnection.execute(SQLiteConnection.java:552)
at android.database.sqlite.SQLiteSession.beginTransactionUnchecked(SQLiteSession.java:323)
at android.database.sqlite.SQLiteSession.beginTransaction(SQLiteSession.java:298)
at android.database.sqlite.SQLiteDatabase.beginTransaction(SQLiteDatabase.java:505)
at android.database.sqlite.SQLiteDatabase.beginTransaction(SQLiteDatabase.java:416)
at androidx.sqlite.db.framework.FrameworkSQLiteDatabase.beginTransaction(FrameworkSQLiteDatabase.java:69)
at androidx.room.InvalidationTracker.syncTriggers(InvalidationTracker.java:426)
at androidx.room.InvalidationTracker.syncTriggers(InvalidationTracker.java:465)
at androidx.room.InvalidationTracker.removeObserver(InvalidationTracker.java:281)
at androidx.room.RxRoom$1$2.run(RxRoom.java:83)
at io.reactivex.disposables.ActionDisposable.onDisposed(ActionDisposable.java:30)
at io.reactivex.disposables.ActionDisposable.onDisposed(ActionDisposable.java:19)
at io.reactivex.disposables.ReferenceDisposable.dispose(ReferenceDisposable.java:43)
at io.reactivex.internal.disposables.DisposableHelper.dispose(DisposableHelper.java:124)
at io.reactivex.internal.disposables.SequentialDisposable.dispose(SequentialDisposable.java:72)
at io.reactivex.internal.operators.flowable.FlowableCreate$BaseEmitter.cancel(FlowableCreate.java:301)
at io.reactivex.internal.operators.flowable.FlowableObserveOn$BaseObserveOnSubscriber.cancel(FlowableObserveOn.java:154)
at io.reactivex.internal.operators.flowable.FlowableFlatMapMaybe$FlatMapMaybeSubscriber.cancel(FlowableFlatMapMaybe.java:158)
at io.reactivex.internal.subscriptions.SubscriptionHelper.cancel(SubscriptionHelper.java:189)
at io.reactivex.internal.subscribers.LambdaSubscriber.cancel(LambdaSubscriber.java:119)
at io.reactivex.internal.subscribers.LambdaSubscriber.dispose(LambdaSubscriber.java:104)
at gmk57.strictroom.MainActivity.onDestroy(MainActivity.java:37)

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

oh this is bad :/ we should fix it, thanks!

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

Looks like it is broken for both add observer and remove observer since both are sync.
We need to investigate this better because these methods were not @WorkerThread before and we had to change them to fix some invalidation problems (see internal bug

b/73592149

).
Luckily this is not an issue for LiveData since it uses ComputableLiveData and always calls observe on a background thread.

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

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

commit 79deed62f2188a6ce2d21244dd28c3dc8ab6d0de
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Wed Oct 17 11:07:39 2018

Specify subscribeOn and unsubscribeOn scheduler in RxRoom.

Setting subscriber and unsubscriber schedulers prevents triggers being
synced in the main thread when subscribing or disposing a RxRoom
flowable / observable.

Moved beginTransaction() calls in InvalidationTracker outside the try,
finally with endTransaction() so that exceptions thrown by
beginTransaction() aren't aborted nor forgotten.

Bug: 117201279
Test: Manual test with sample app.
Change-Id: Iefb33dc63cf78e125a8805bd66a26ada365d8453

A room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/test/InvalidationTrackerTest.java
M room/runtime/src/main/java/androidx/room/InvalidationTracker.java
M room/rxjava2/src/main/java/androidx/room/RxRoom.java
M room/rxjava2/src/test/java/androidx/room/RxRoomTest.java

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

https://goto.google.com/android-sha1/79deed62f2188a6ce2d21244dd28c3dc8ab6d0de

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

Dupe

https://issuetracker.google.com/issues/74227569

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

Run

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

Run

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

Run

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.