[local-authentication] add new biometric type for android biometric prompt

[byCedric]

Why

Fixes #7838

How

I added the type both in Android and iOS. On Android, it's the only type that we return if Biometric Prompt can be used. For iOS, the biometric type is included if either facial recognition or touch id is available.

Test Plan

See #7838 or https://snack.expo.io/@ouihealth/a78fc1

[byCedric]

I removed the iOS only tags here because this is also implemented in Android now (via #8219)

[github-actions]

Native Component List for this branch is ready

[lukmccall]

LGTM 🥇
Thanks for updating docs ;) I've forgotten about it :/

[tsapeta]

looks good to me,

but...

changelog entry please! 😁

[byCedric]

looks good to me,

but...

Done! Even used et add-changelog 💋

[tsapeta]

@byCedric - take a look at this new comment: #7838 (comment)
Maybe it's worth trying before merging this one? 🤔

[byCedric]

@tsapeta it does seems to detect if a biometric method is available. But this still doesn't help the user, imho. You still can't ask the BiometricPrompt to use a specific authentication method, right?

[tsapeta]

Yeah, we can't specify authentication type, but that would give us more info which types are supported. Also, looks like some new features will be added in Android 11. https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt#getAllowedAuthenticators() and https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt.Builder#setAllowedAuthenticators(int)

[byCedric]

Awesome, but still, this doesn't allow us to specify either fingerprint, facial recognition or iris authentication. It only allows us to define the strength of the authentication. But both fingerprint and face recognition can be strong and weak 🙈 It does provide a way for using the device credentials, but I think that's mostly covered with disableDeviceFallback.

So instead of matching the functionality with iOS, implementing this will only deviate more from the iOS behavior I guess.

From the Authenticator docs:

BIOMETRIC_STRONG
Any biometric (e.g. fingerprint, iris, or face) on the device that meets or exceeds the requirements for Strong, as defined by the Android CDD.

BIOMETRIC_WEAK
Any biometric (e.g. fingerprint, iris, or face) on the device that meets or exceeds the requirements for Weak, as defined by the Android CDD.

[beaur]

I'm not sure adding BIOMETRIC here as a response to supportedAuthenticationTypesAsync really adds much value does it? On android we will already be able to determine if a biometric method is available through the isEnrolledAsync method. At least if we return an array containing one or more biometric types in supportedAuthenticationTypesAsync a developer has some idea about what type of biometric prompt may be displayed to the user and build UI around that as needed. This is already an array, and it is possible iOS will allow multiple types in the future too.

If the device supports a single type, then in theory that should match what it presented to the user. If the device supports multiple types more generic UI may need to be used as it would not be clear which method the system would select. Unfortunately this is the path Google is taking at the moment though.

When Android R comes along having the option to set BIOMETRIC_STRONG would be a very useful option for financial sector apps that need to enforce strong security. This would be a great option on the authenticateAsync options. We could then pass this to android with the setAllowedAuthenticators property - https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt.Builder#setAllowedAuthenticators(int)

[tsapeta]

I'm not sure adding BIOMETRIC here as a response to supportedAuthenticationTypesAsync really adds much value does it? On android we will already be able to determine if a biometric method is available through the isEnrolledAsync method. At least if we return an array containing one or more biometric types in supportedAuthenticationTypesAsync a developer has some idea about what type of biometric prompt may be displayed to the user and build UI around that as needed. This is already an array, and it is possible iOS will allow multiple types in the future too.

Yeah, generally right now supportedAuthenticationTypesAsync doesn't have much sense on Android but we would like to keep a good API that works on both platforms. On iOS result of this method might be useful for as you said some UI aspects.

If the device supports a single type, then in theory that should match what it presented to the user. If the device supports multiple types more generic UI may need to be used as it would not be clear which method the system would select. Unfortunately this is the path Google is taking at the moment though.

I agree here – if the device supports only one type, then users can build specific UI for this.

When Android R comes along having the option to set BIOMETRIC_STRONG would be a very useful option for financial sector apps that need to enforce strong security. This would be a great option on the authenticateAsync options. We could then pass this to android with the setAllowedAuthenticators property - https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt.Builder#setAllowedAuthenticators(int)

Actually we can say that BIOMETRIC_STRONG is the default option and it's used on Android's before 11. Fingerprint is considered to be stronger than facial recognition and I've seen some devices with multiple supported auth types where the system always chooses fingerprint. Sometimes the system doesn't even fall back to facial/iris recognition if fingerprint is not enrolled because they are not strong enough.

[byCedric]

Actually we can say that BIOMETRIC_STRONG is the default option and it's used on Android's before 11. Fingerprint is considered to be stronger than facial recognition and I've seen some devices with multiple supported auth types where the system always chooses fingerprint. Sometimes the system doesn't even fall back to facial/iris recognition if fingerprint is not enrolled because they are not strong enough.

So that would mean we could do an "estimate" of what type of authentication would be used? But is that good enough to implement?

[tsapeta]

We can predict what type of authentication would be used, but certainly we shouldn't do this in our API 🙃
However having more relevant supported auth types, using aforementioned way might be useful in my opinion as it sounds to be closer to what we offer on iOS – let's do this if you agree with me, otherwise just merge it 😉

[beaur]

Having supportedAuthenticationTypesAsync return [LocalAuthentication.AuthenticationType.FINGERPRINT, LocalAuthentication.AuthenticationType.FACIAL_RECOGNITION, LocalAuthentication.AuthenticationType.IRIS] on android would much more closely match the iOS response and allow developers to make and estimate of what type would be used when they call authenticateAsync. It is also more backwards compatible since previously android would return [] or [LocalAuthentication.AuthenticationType.FINGERPRINT].

[beaur]

I'm happy to work on a pull request for these changes if needed.

[byCedric]

Let's go for the backwards-compatible implementation! @beaur, if you can create a PR for this I'll be happy to double-check 😄 I just created the PR because time is essential at the moment 😄