Status Update
No update yet.
Comments
ap...@google.com
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.
ap...@google.com
We have some
ap...@google.com
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
il...@google.com
ap...@google.com
Branch: androidx-master-dev
commit 7bbbab7dca4edda160e6b2169d38a25b81698f47
Author: Ian Lake <ilake@google.com>
Date: Fri Mar 15 09:59:23 2019
Centralize MATERIAL dependency
Remove references to SUPPORT_DESIGN and switch
to the full dependency instead of the previously
used @aar dependency.
Also removes the no longer needed exclude_for_material
exclusion since all libraries are now on AndroidX.
Removed ViewPager2 implementation on AppCompat,
replacing it with an androidTestImplementation since it
is not actually used in the library itself. This fixes
an error when including a ToT implementation dependency
along with the fixed dependency from MATERIAL that
appears when switching to the full dependency.
Test: ./gradlew bOS, ran all affected sample apps
Fixes: 128632612
Change-Id: I44579630cdc3eae58fc23924d8c4d45d2d457f2b
M buildSrc/dependencies.gradle
M buildSrc/src/main/kotlin/androidx/build/dependencies/Dependencies.kt
M car/core/build.gradle
M navigation/ui/build.gradle
M samples/SupportContentDemos/build.gradle
M samples/SupportDesignDemos/build.gradle
M viewpager2/build.gradle
M viewpager2/integration-tests/testapp/build.gradle
M work/integration-tests/testapp/build.gradle
il...@google.com
- core 1.0.1
- fragment 1.1.0-alpha05 (latest)
- material 1.0.0
And no longer depends on legacy-support-core-utils at all.
Description
Version used: 2.0.0
Devices/Android versions reproduced on:
Now that Navigation depends on AndroidX, we should switch to the latest versions of our dependencies where it makes sense and remove our dependency on the catch all legacy-support-core-utils artifact.