Fixed
Status Update
Comments
ve...@google.com <ve...@google.com>
ve...@google.com <ve...@google.com> #2
Forgot to paste the exception that was thrown:
No destination with route subGraph is on the NavController's back stack. The current destination is Destination(0xe5901274) route=a
th...@gmail.com <th...@gmail.com> #3
This is still happening with navigation-compose 2.4.0-alpha06
th...@gmail.com <th...@gmail.com> #4
Project: platform/frameworks/support
Branch: androidx-main
commit d7af5243adb70d92a0104005ff353c83933c97ed
Author: Jeremy Woods <jbwoods@google.com>
Date: Mon Aug 23 22:03:09 2021
Ensure NavGraph Navigators are destroyed properly
When navigating with transitions, we properly hold destination entries
until the transition completes, but not for NavGraph entries. This is a
particular issue for popping since it results in NavGraph entries will
be moved to DESTROYED before their child destinations.
We need to make NavGraph back stack entries keep the maximum lifecycle
state of all of the entries in the graph. This means that as long as one
entry in the graph is CREATED, the graph itself will be CREATED and only
after all entries have been DESTROYED, will the NavGraph entry also be
destroyed.
RelNote: "Using getBackStackEntry and previousBackStackEntry inside
composable(), in conjuction with remember() will no longer cause an
exception for no destination being on the back stack."
Test: add new test
Bug: 194313238
Change-Id: I75138d24d27dac83b5301507161578ac811454e3
M navigation/navigation-compose/src/androidTest/java/androidx/navigation/compose/NavHostTest.kt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavBackStackEntryLifecycleTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
https://android-review.googlesource.com/1806636
Branch: androidx-main
commit d7af5243adb70d92a0104005ff353c83933c97ed
Author: Jeremy Woods <jbwoods@google.com>
Date: Mon Aug 23 22:03:09 2021
Ensure NavGraph Navigators are destroyed properly
When navigating with transitions, we properly hold destination entries
until the transition completes, but not for NavGraph entries. This is a
particular issue for popping since it results in NavGraph entries will
be moved to DESTROYED before their child destinations.
We need to make NavGraph back stack entries keep the maximum lifecycle
state of all of the entries in the graph. This means that as long as one
entry in the graph is CREATED, the graph itself will be CREATED and only
after all entries have been DESTROYED, will the NavGraph entry also be
destroyed.
RelNote: "Using getBackStackEntry and previousBackStackEntry inside
composable(), in conjuction with remember() will no longer cause an
exception for no destination being on the back stack."
Test: add new test
Bug: 194313238
Change-Id: I75138d24d27dac83b5301507161578ac811454e3
M navigation/navigation-compose/src/androidTest/java/androidx/navigation/compose/NavHostTest.kt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavBackStackEntryLifecycleTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
me...@adriel.cafe <me...@adriel.cafe> #5
This has been fixed internally and will be available in the Navigation 2.4.0-alpha08
release.
This also includes a lint check to ensure you surround any calls to getBackStackEntry
within composition with a remember
, which you should always be doing anyway, and that is the only way this actually works.
ve...@google.com <ve...@google.com> #6
I don't understand why and how do we need to surround getBackStackEntry
with a remember
.
Even the docs does not do that
be...@gmail.com <be...@gmail.com> #7
cu...@google.com <cu...@google.com> #8
This error case appears to be triggered by creating BiometricPrompt immediately before calling authenticate(), rather than recreating the prompt in the Activity's onCreate() (or Fragment's onCreateView()) lifecycle method as intended. That's obviously an easy mistake to make, so I'll work on making sure the documentation is clearer here.
The fact that the activity appears to hang afterward is definitely a bug and will be fixed by aosp/1151594, likely in a 1.0.1 bugfix release. For now, I'm closing this bug as a duplicate of b/143683687 .
The fact that the activity appears to hang afterward is definitely a bug and will be fixed by aosp/1151594, likely in a 1.0.1 bugfix release. For now, I'm closing this bug as a duplicate of
th...@gmail.com <th...@gmail.com> #10
Must it be in onCreate?
I'm doing this in onResume instead of onCreate so that the prompt shows up when the user comes back to my app.
I'm doing this in onResume instead of onCreate so that the prompt shows up when the user comes back to my app.
cu...@google.com <cu...@google.com>
ap...@google.com <ap...@google.com> #11
Project: platform/frameworks/support
Branch: androidx-master-dev
commit df08869e2c6f2d066f1caf143cebdb965c1b5a2c
Author: Curtis Belmonte <curtislb@google.com>
Date: Mon Nov 18 15:17:00 2019
Fix BiometricPrompt + device credential error case
BiometricPrompt currently has a bug in the following usage scenario:
1. The prompt is not instantiated in onCreate() or onCreateView()
2. Device credential auth is enabled with setDeviceCredentialAllowed()
3. authenticate() is called twice in the same activity/fragment
When this happens, the handler bridge is incorrectly reset before the
handler activity can be launched, preventing the prompt from being shown
at all. While this isn't a recommended usage pattern for
BiometricPrompt at the moment, it still shouldn't cause the prompt to
get stuck in this state. This commit therefore ensures that the above
scenario no longer triggers the bug.
Test: Manually, using sample app from b/143097321
Test: ./gradlew biometric:test
Test: ./gradlew biometric:connectedAndroidTest
Fixes: 143097321
Change-Id: Ie7e343d9323437d9765e512a09a0e25a6c86dd8e
M biometric/src/main/java/androidx/biometric/BiometricPrompt.java
M biometric/src/main/java/androidx/biometric/DeviceCredentialHandlerActivity.java
https://android-review.googlesource.com/1168851
Branch: androidx-master-dev
commit df08869e2c6f2d066f1caf143cebdb965c1b5a2c
Author: Curtis Belmonte <curtislb@google.com>
Date: Mon Nov 18 15:17:00 2019
Fix BiometricPrompt + device credential error case
BiometricPrompt currently has a bug in the following usage scenario:
1. The prompt is not instantiated in onCreate() or onCreateView()
2. Device credential auth is enabled with setDeviceCredentialAllowed()
3. authenticate() is called twice in the same activity/fragment
When this happens, the handler bridge is incorrectly reset before the
handler activity can be launched, preventing the prompt from being shown
at all. While this isn't a recommended usage pattern for
BiometricPrompt at the moment, it still shouldn't cause the prompt to
get stuck in this state. This commit therefore ensures that the above
scenario no longer triggers the bug.
Test: Manually, using sample app from
Test: ./gradlew biometric:test
Test: ./gradlew biometric:connectedAndroidTest
Fixes: 143097321
Change-Id: Ie7e343d9323437d9765e512a09a0e25a6c86dd8e
M biometric/src/main/java/androidx/biometric/BiometricPrompt.java
M biometric/src/main/java/androidx/biometric/DeviceCredentialHandlerActivity.java
cu...@google.com <cu...@google.com> #12
Yes, initializing the prompt in onResume() should be fine as well.
Unmarked as duplicate, since aosp/1168851 should be a more proper fix for this. Targeting it for inclusion in 1.0.1.
Unmarked as duplicate, since aosp/1168851 should be a more proper fix for this. Targeting it for inclusion in 1.0.1.
an...@google.com <an...@google.com> #13
mi...@quali-sign.com <mi...@quali-sign.com> #14
I believe I am facing a related issue. I am using BiometricPrompt with setDeviceCredentialAllowed. This is fully working on an older device running Oreo (now that I recreate the activity each time after using BiometricPrompt). The user can choose to use their fingerprint to authenticate, or can select to use the pin. In both cases, once the user successfully authenticates, onAuthenticationSucceeded is called on the BiometricPrompt.AuthenticationCallback.
However when used in the emulator, running Android 10, as soon as the user selects the "Use PIN" option, onAuthenticationError is called with errorCode=5 and errString=Authentication canceled
However when used in the emulator, running Android 10, as soon as the user selects the "Use PIN" option, onAuthenticationError is called with errorCode=5 and errString=Authentication canceled
[Deleted User] <[Deleted User]> #15
Yes I am facing the same issue. Once I get the errCode = 5, the activity starting acting very strange. It then again gives an errCode = 10 before crashing again.
Description
Android Studio 3.5.1
compileSdkVersion 29
buildToolsVersion '29.0.2'
minSdkVersion 17
targetSdkVersion 28
implementation 'androidx.biometric:biometric:1.0.0-rc01'
See "Allow for fallback to non-biometric credentials" in
Problem:
1. Show biometric prompt.
2. Tap "USE PASSWORD" instead of scanning fingerprint.
3. Unlock using pattern.
4. Activity stops responding.
Note: the problem does not occur if I authenticate using fingerprint.