Fixed
Status Update
Comments
da...@gmail.com <da...@gmail.com> #2
Thank you for reporting this issue. For us to further investigate this issue, please provide the following additional information:
Steps to reproduce
What steps are needed to reproduce this issue?
Please provide sample project or apk to reproduce the issue. Also mention the steps to be followed for reproducing the issue with the given sample project or apk.
Frequency
How frequently does this issue occur? (e.g 100% of the time, 10% of the time)
Expected output
What is the expected output?
Current output
What is the current output?
Android bug report capturing
After reproducing the issue, press the volume up, volume down, and power button simultaneously. This will capture a bug report on your device in the “bug reports” directory. Attach the bug report file to this issue.
Alternate method
After reproducing the issue, navigate to “developer settings”, ensure “USB debugging” is enabled, then enable “Bug report shortcut”. Capture bug report by holding the power button and selecting the “Take bug report” option.
Note: Please upload the files to google drive and share the folder to android-bugreport@google.com, then share the link here.
Steps to reproduce
What steps are needed to reproduce this issue?
Please provide sample project or apk to reproduce the issue. Also mention the steps to be followed for reproducing the issue with the given sample project or apk.
Frequency
How frequently does this issue occur? (e.g 100% of the time, 10% of the time)
Expected output
What is the expected output?
Current output
What is the current output?
Android bug report capturing
After reproducing the issue, press the volume up, volume down, and power button simultaneously. This will capture a bug report on your device in the “bug reports” directory. Attach the bug report file to this issue.
Alternate method
After reproducing the issue, navigate to “developer settings”, ensure “USB debugging” is enabled, then enable “Bug report shortcut”. Capture bug report by holding the power button and selecting the “Take bug report” option.
Note: Please upload the files to google drive and share the folder to android-bugreport@google.com, then share the link here.
vi...@google.com <vi...@google.com> #3
Steps to reproduce
1. Show the biomterics prompt
2. Use the wrong finger to authenticate several times in a row
Frequency
100% of the time
Expected output
The behavior is the same on all api levels
Current output
The behavior differs between api levels as described in the initial report/video
Android bug report capturing
There's no bugs to capture, this is a behavior difference, not a crash
Attached is a sample apk, all it does is show the biometric prompt using the lib
1. Show the biomterics prompt
2. Use the wrong finger to authenticate several times in a row
Frequency
100% of the time
Expected output
The behavior is the same on all api levels
Current output
The behavior differs between api levels as described in the initial report/video
Android bug report capturing
There's no bugs to capture, this is a behavior difference, not a crash
Attached is a sample apk, all it does is show the biometric prompt using the lib
da...@gmail.com <da...@gmail.com> #4
Attached bug reports
vi...@google.com <vi...@google.com> #5
kc...@google.com <kc...@google.com>
cu...@google.com <cu...@google.com> #6
Oops, looks like this is related to b/119597723
We need to support both of the cases
1) if the dialog is not showing or about to be shown, and there's lockout, we need to return the lockout error immediately
2) (this bug) if the dialog is showing, we want to delay a few seconds before dismissing the dialog / forwarding the result to the client
Josh do you have cycles to dig into this? I can't think of a clean solution right now but we can chat about it offline, maybe there's a simple way to fix this.
https://cs.corp.google.com/aosp-androidx/biometric/src/main/java/androidx/biometric/FingerprintHelperFragment.java?q=fingerprinthelperfragment.java+%22errMsgId+%3D%3D+BiometricPrompt.ERROR_LOCKOUT%22+file:%5Ebiometric/src/main/java/androidx/biometric/+package:%5Eaosp-androidx$&g=0&l=91
We need to support both of the cases
1) if the dialog is not showing or about to be shown, and there's lockout, we need to return the lockout error immediately
2) (this bug) if the dialog is showing, we want to delay a few seconds before dismissing the dialog / forwarding the result to the client
Josh do you have cycles to dig into this? I can't think of a clean solution right now but we can chat about it offline, maybe there's a simple way to fix this.
Description
Version used:1.0.1
Theme used: Theme.AppCompat.Light.DarkActionBar
Devices/Android versions reproduced on: pixel 2 Android 10, Emulator API 27&29
- Relevant code to trigger the issue: equal to the documentation:
and using setDeviceCredentialAllowed(true)
I implemented the new androidx.biometric:biometric:1.0.1 as described in the documentation and using setDeviceCredentialAllowed(true). On API 29 it works correctly, on API < 29 when there aren't any device credentials set I would expect to get ERROR_NO_DEVICE_CREDENTIAL but I'm getting ERROR_USER_CANCELED, is this a library bug or if not what am I missing?
Since the documenation says this library is backwards compatible I would expect I don't need to handle anything myself for API<29, right?
As I could see in BiometricPrompt.java there is a code-block:
case DeviceCredentialHandlerBridge.RESULT_ERROR:
// Device credential auth failed. Assume this is due to the user canceling.
final CharSequence errorMsg = getActivity() != null
? getActivity().getString(R.string.generic_error_user_canceled) : "";
mAuthenticationCallback.onAuthenticationError(
BiometricConstants.ERROR_USER_CANCELED, errorMsg);
bridge.stopIgnoringReset();
bridge.reset();
break;
Don't know why the lib is returning a generic error code in form of ERROR_USER_CANCELED, nothing of this is documented in BiometricConstants.java.