IssueTracker

https://issuetracker.google.com/issues/149344544 was marked as fixed with the release of Biometric library 1.1.0-alpha02 (and many other issues related to leaks with biometric).

While this version and 1.1.0-alpha01 solved many issues using ViewModels and LiveData, leaks are still happening.

In particular, the culprit seems to be FingerprintManager which holds a strong reference to the activity context.

Tested on BUILD INFO

• Device type: Motorola G5 Plus
• OS version: 8.1.0
• Biometric library version:1.1.0-alpha02

STEPS TO REPRODUCE

1. Compile and run attached project.
2. Enable biometrics with the Switch.
3. Type anything on email/password fields and sign in.
4. Touch fingerprint sensor.
5. Logged in to Main Activity. At this point the leak may or may not be detected after five seconds, if not:
6. Return to Login Activity.
7. Biometric authentication is now automatically requested, touch sensor.
8. Logged in again to Main Activity. You should see a Leak Canary notification.

NUMBER OF TIMES YOU WERE ABLE TO REPRODUCE - 10/10

Tracking the references to the context (LoginActivity) i found that FingerprintManager eventually receives the value through the BiometricManager.from(Context) method when BiometricManager.canAuthenticate(Int) is invoked, so i tried to use applicationContext to try and resolve the leak, but it happened anyway (file: LoginActivity.kt:190).

Eventually I found out that the possible cause may be the BiometricFragment class, specifically the BiometricFragment.authenticate(BiometricPromp.PromptInfo, BiometricPrompt.CryptoObject) method. The BiometricFragment instance uses the same method in the authenticate function, which gets the parent activity using getActivity() and then passes the value that will eventually reach FingerprintManager.

I don't believe there are any other places in the code where i pass an activity context, and I know that the value passed to create the BiometricPrompt object (file: LoginActivity.kt:195) is only used to get a BiometricViewModel instance and the FragmentActivity is never used again.

Leak results:

====================================
HEAP ANALYSIS RESULT
====================================
1 APPLICATION LEAKS

References underlined with "~~~" are likely causes.
Learn more at https://squ.re/leaks.

1552330 bytes retained by leaking objects
Displaying only 1 leak trace out of 2 with the same signature
Signature: 7dbc13f567c351b9c40dbddb3f08828f35c99b
┬───
│ GC Root: Global variable in native code
│
├─ android.hardware.fingerprint.FingerprintManager$1 instance
│    Leaking: UNKNOWN
│    Anonymous subclass of android.hardware.fingerprint.IFingerprintServiceReceiver$Stub
│    ↓ FingerprintManager$1.this$0
│                           ~~~~~~
├─ android.hardware.fingerprint.FingerprintManager instance
│    Leaking: UNKNOWN
│    ↓ FingerprintManager.mContext
│                         ~~~~~~~~
╰→ com.carvel94.biometricleak.ui.login.LoginActivity instance
​     Leaking: YES (ObjectWatcher was watching this because com.carvel94.biometricleak.ui.login.LoginActivity received Activity#onDestroy() callback and Activity#mDestroyed is true)
​     key = eff4b2b0-da2d-4e96-827c-07d8583ef827
​     watchDurationMillis = 5073
​     retainedDurationMillis = 73
====================================
0 LIBRARY LEAKS

A Library Leak is a leak caused by a known bug in 3rd party code that you do not have control over.
See https://square.github.io/leakcanary/fundamentals-how-leakcanary-works/#4-categorizing-leaks
====================================
METADATA

Please include this in bug reports and Stack Overflow questions.

Build.VERSION.SDK_INT: 27
Build.MANUFACTURER: motorola
LeakCanary version: 2.4
App process name: com.carvel94.biometricleak
Analysis duration: 13791 ms
Heap dump file path: /data/user/0/com.carvel94.biometricleak/files/leakcanary/2020-08-20_17-34-35_932.hprof
Heap dump timestamp: 1597959293116
====================================