Android 11 gives developers tools to decide how secure biometrics need to be and makes it easier to include methods that aren't fingerprint-based.
Biometric security has made it easy to keep our phones secure, which means most of us actually are doing it. It's easy to argue that your fingerprint or iris or a map of your head aren't as secure as a strong password or are your identity and not a passcode, but in the end, more people securing their phones is better for everyone. It's easy to understand why your bank wants you to secure your phone, but remember that some of your personal details are probably on someone else's phone, too.
We saw big changes to biometrics with . The introduction of the BiometricPrompt API tried to unify how different types of biometric authentication could function by providing a unified interface that worked with fingerprint scanners (both capacitive and ultrasonic), Iris scanning, and secure facial unlocking.
It was needed. Before the new APIs, developers had to use programming interfaces that weren't part of the operating system or build a workaround that used the standard fingerprint sensor APIs. Iris scanning depended on a Samsung SDK, Huawei's facial unlocking had its own programming interface, and so did HTC's. Android 10 made further changes so that everything — including the newly released — could use a single way to authenticate without reinventing the wheel.
We saw how that worked. App developers were slow to adapt because of a couple of hurdles: the new programming interface still forced a direct query of the actual hardware and the system determined if it was "good enough" and not the people who actually wanted to include it in an app.
Enter . What seems like a simple change, the addition of defined authentication types, it's easier than ever for a developer to use any biometric hardware how they see fit.
Android now includes categories for weak, strong, and device credential biometric hardware. In a developer could only use what Google defined as secure biometrics: fingerprint scanners, iris scanners, and true 3D facial recognition. That actually led to code being written to (Galaxy S8/Note 8, Galaxy S9/Note 9, Galaxy S10/Note 10) from using the BiometricPrompt API and forced the fallback to the old workarounds using the original fingerprint methods because of a bug. Having a shiny new way of doing things means little when most devices can't even use it.
Now when a developer wants to include biometric authentication, they can look to all methods — including those marked as "weak" — to see which fit their needs best. Maybe your bank wants to only allow authentication marked as strong (it probably does) so it can ignore things like Android's standard facial recognition or even force you to enter your unlock code or PIN after authenticating if they are extremely security-conscious (they probably don't, but maybe they should).
Alternatively, something like a secure photo browser can allow weaker authentication methods like regular photo-based facial unlocking or even in-between solutions that almost meet the "strong" criteria like HTC's depth-sensing facial unlock.
Once that's out of the way all an app needs to do is tell the BiometricPrompt API to show you a dialog and it's done. No more custom coding or third-party SDKs or doing everything by hand. And that's how it should be; when things become easy (or easier) for developers, we benefit.
See you on Android 11 very soon.
Get More Pixel 4
Google Pixel 4 & 4 XL