Status Update
Comments
ra...@gmail.com <ra...@gmail.com> #2
From the other issue:
note that it is never the right approach to attach a
<deeplink>
to an<activity>
destination as that will never give you the right behavior when using anon another app's task (where the system back should immediately take the user back to the app that triggered your deep link). Instead, you should attach your deep link directly to your second activity (either by manually writing the appropriate implicit deep link <intent-filter>
or by adding the<deeplink>
to the start destination of a nav host in that second activity).
A lint error saying as such when a <deepLink>
element is added in Navigation XML would go a really long way to avoiding this case. Our navigation-runtime-lint
artifact that would contain this check.
jb...@google.com <jb...@google.com>
cl...@google.com <cl...@google.com> #3
We have some
cl...@google.com <cl...@google.com> #5
Branch: androidx-main
commit cd77b4bbe312dd8892dfbb3c662344d13a96c82d
Author: Julia McClellan <juliamcclellan@google.com>
Date: Thu Apr 14 15:31:46 2022
Deep link in activity destination in navigation lint
Test: Included tests of API version and the lint rule
Bug: 178403185
Change-Id: Ic15a5ec165620b7ef5b3f03538cc83b5576add8d
A navigation/navigation-runtime-lint/src/main/java/androidx/navigation/runtime/lint/DeepLinkInActivityDestinationDetector.kt
A navigation/navigation-runtime-lint/src/test/java/androidx/navigation/runtime/lint/ApiLintVersionsTest.kt
M settings.gradle
A navigation/navigation-runtime-lint/build.gradle
M navigation/navigation-runtime/build.gradle
A navigation/navigation-runtime-lint/src/main/java/androidx/navigation/runtime/lint/NavigationRuntimeIssueRegistry.kt
A navigation/navigation-runtime-lint/src/test/java/androidx/navigation/runtime/lint/DeepLinkInActivityDestinationDetectorTest.kt
A navigation/navigation-runtime-lint/src/main/resources/META-INF/services/com.android.tools.lint.client.api.IssueRegistry
na...@google.com <na...@google.com> #6
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.navigation:navigation-compose:2.6.0-alpha09
androidx.navigation:navigation-runtime:2.6.0-alpha09
ra...@gmail.com <ra...@gmail.com> #7
It looks good to me. At least, this specific behaviour seems to be fixed.
Description
Component used: Navigation
Version used: 2.6.0-alpha05
Devices/Android versions reproduced on:
Not relevant, it will happen on all.
If this is a bug in the library, we would appreciate it if you could attach: Sample project to trigger the issue.
I'll add a couple of simple kotlin files instead, just use them with any version after 2.6.0-alpha05 navigation dependency and you'll be able to reproduce it.
MainActivity_rook.kt File
If we add destinations directly on "root" (route passed to NavHost call), then this will be the log of the back stack as we navigate:
MainActivity_no_root.kt File
If we add a navigation graph ("home_graph") as the only direct child of "root" and add destinations on that instead, it will work as expected, we'll see this:
This was a breaking change that could introduce bugs for anyone relying on that "root" sent on the NavHost and popping up to that, since after updating navigation it would instead just pop their last screen.