Fixed
Status Update
Comments
dm...@gmail.com <dm...@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.
[Deleted User] <[Deleted User]> #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
[Deleted User] <[Deleted User]> #4
Attached bug reports
cu...@google.com <cu...@google.com>
ap...@google.com <ap...@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.
ap...@google.com <ap...@google.com> #7
I'll try and get to this next week if that's okay.
dk...@fundrise.com <dk...@fundrise.com> #8
3) Currently the FingerprintDialogFragment is shown regardless of lockout (which can result in a split second appearance), it's related to this bug and we should figure out a way to fix it as well.
lo...@gmail.com <lo...@gmail.com> #9
aosp/929948 is merged, not sure why it didn't get closed here
ap...@google.com <ap...@google.com> #10
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 6e031f7cad58675cf1522260727e3894122f9107
Author: Curtis Belmonte <curtislb@google.com>
Date: Thu Jul 30 13:33:30 2020
Fix memory leaks in androidx.biometric library
Addresses several memory leaks reported by LeakCanary for the following
classes:
- The BiometricFragment internal library class
- The BiometricViewModel internal library class
- The host activity from the client application
Test: Biometric integration test app on API 27-30
Test: LeakCanary e2e test added in a follow-up commit
Test: ./gradlew biometric:biometric:test
Test: ./gradlew biometric:biometric:connectedAndroidTest
Bug: 143929280
Bug: 144919472
Bug: 149344544
Change-Id: Ia055ffd6b97e3f3b0ba85c2cd665c94fe467bab6
M biometric/biometric/src/main/java/androidx/biometric/BiometricFragment.java
M biometric/biometric/src/main/java/androidx/biometric/BiometricViewModel.java
https://android-review.googlesource.com/1382564
Branch: androidx-master-dev
commit 6e031f7cad58675cf1522260727e3894122f9107
Author: Curtis Belmonte <curtislb@google.com>
Date: Thu Jul 30 13:33:30 2020
Fix memory leaks in androidx.biometric library
Addresses several memory leaks reported by LeakCanary for the following
classes:
- The BiometricFragment internal library class
- The BiometricViewModel internal library class
- The host activity from the client application
Test: Biometric integration test app on API 27-30
Test: LeakCanary e2e test added in a follow-up commit
Test: ./gradlew biometric:biometric:test
Test: ./gradlew biometric:biometric:connectedAndroidTest
Bug: 143929280
Bug: 144919472
Bug: 149344544
Change-Id: Ia055ffd6b97e3f3b0ba85c2cd665c94fe467bab6
M biometric/biometric/src/main/java/androidx/biometric/BiometricFragment.java
M biometric/biometric/src/main/java/androidx/biometric/BiometricViewModel.java
cu...@google.com <cu...@google.com> #11
This should be addressed as of version 1.1.0-alpha02. We've also added e2e tests with LeakCanary to avoid future regressions.
mi...@gmail.com <mi...@gmail.com> #12
I can confirm that this is fixed on 1.1.0-alpha02
na...@gmail.com <na...@gmail.com> #13
I still have this error in 1.1.0-alpha3 version
Description
Devices/Android versions reproduced on:
Emulator 25 API, X86 (behaves the same on all versions)
Android version 7.1.1
Code:
Steps:
Have a stored fingerprint on the device.
Launch the example app, see the fingerprint dialog.
Rotate the screen.
See 2 leaks in LeakCanary.
Frequency:
Each time on rotation.
Leak #1:
androidx.biometric.DeviceCredentialHandlerBridge
│ Leaking: NO (a class is never leaking)
│ GC Root: System class
│ ↓ static DeviceCredentialHandlerBridge.sInstance
│ ~~~~~~~~~
├─ androidx.biometric.DeviceCredentialHandlerBridge
│ Leaking: UNKNOWN
│ ↓ DeviceCredentialHandlerBridge.mAuthenticationCallback
│ ~~~~~~~~~~~~~~~~~~~~~~~
├─ com.eightbitlab.biometricbugs.MainActivity$onCreate$1
│ Leaking: UNKNOWN
│ Anonymous subclass of androidx.biometric.BiometricPrompt$AuthenticationCallback
│ ↓ MainActivity$onCreate$1.this$0
Leak #2:
┬
├─ androidx.biometric.DeviceCredentialHandlerBridge
│ Leaking: NO (a class is never leaking)
│ GC Root: System class
│ ↓ static DeviceCredentialHandlerBridge.sInstance
│ ~~~~~~~~~
├─ androidx.biometric.DeviceCredentialHandlerBridge
│ Leaking: UNKNOWN
│ ↓ DeviceCredentialHandlerBridge.mOnClickListener
│ ~~~~~~~~~~~~~~~~
├─ androidx.biometric.BiometricPrompt$1
│ Leaking: UNKNOWN
│ Anonymous class implementing android.content.DialogInterface$OnClickListener
│ ↓ BiometricPrompt$1.this$0
│ ~~~~~~
├─ androidx.biometric.BiometricPrompt
│ Leaking: UNKNOWN
│ ↓ BiometricPrompt.mFingerprintDialogFragment
│ ~~~~~~~~~~~~~~~~~~~~~~~~~~
╰→ androidx.biometric.FingerprintDialogFragment
Leaking: YES (Fragment#mFragmentManager is null and ObjectWatcher was watching this)
key = 42dbc3ac-2321-40a0-bfd4-4f74044ca615
watchDurationMillis = 2137697
retainedDurationMillis = 2132696
Another leak, that is not reported by LeakCanary right now is a non-static child of Handler in FingerprintDialogFragment.
Lint gives you a warning:
This Handler class should be static or leaks might occur.