BiometricPrompt:为什么要在启用setDeviceCredentialAllowed之前检查KeyguardManager.isDeviceSecure()? [英] BiometricPrompt: Why should we check KeyguardManager.isDeviceSecure() before enabling setDeviceCredentialAllowed?

本文介绍了BiometricPrompt:为什么要在启用setDeviceCredentialAllowed之前检查KeyguardManager.isDeviceSecure()?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

BiometricPrompt.PromptInfo setDeviceCredentialAllowed 方法的文档指出:


[...]开发人员应首先检查KeyguardManager.isDeviceSecure(),然后再启用它。如果设备不安全,则会在BiometricPrompt.AuthenticationCallback.onAuthenticationError(int,CharSequence)中返回BiometricPrompt.ERROR_NO_DEVICE_CREDENTIAL。

[...] Developers should first check KeyguardManager.isDeviceSecure() before enabling this. If the device is not secure, BiometricPrompt.ERROR_NO_DEVICE_CREDENTIAL will be returned in BiometricPrompt.AuthenticationCallback.onAuthenticationError(int, CharSequence).

https://developer.android.com/reference /androidx/biometric/BiometricPrompt.PromptInfo.Builder.html#setDeviceCredentialAllowed(boolean)

但是,是为了首先启用生物识别位置,您必须设置设备PIN或密码。因此,当我们已经有了 BiometricManager.canAuthenticate 时,此检查(仅适用于API 23+)不是多余的吗?

However, in order to enable biometric authentication in the first place, you have to set up a device PIN or password. Isn't this check (which is only available on API 23+) therefore superfluous when we already have BiometricManager.canAuthenticate?

推荐答案

这是一个很好的问题!提供逐步的响应可能很重要。首先,让我们将特定设备上发生的事情与应用中发生的事情分开。然后,我们将解决更具体的问题。

This is a great question! It might be important to provide a step-wise response. First, let's separate what's happening on a particular device vs what's happening in your app. Then we'll address the more specific question.

设备

设备运行API 23+的设备可能会也可能没有设备登录凭据设置。不需要设备所有者设置设备PIN,图案,密码或生物特征模板。这是一种选择。

A device running API 23+ may or may not have device login credentials setup. The owner of a device is not required to setup device PIN, pattern, password, or biometric templates. It's a choice.

应用

用户应该能够安装您的应用程序,是否已设置设备登录凭据。因此,您的应用必须以能够处理未设置登录凭据的用例的方式编写。

A user should be able to install your app whether or not device login credentials have been setup. Therefore your app must be written in a way that handles use cases where login credentials haven't been setup.

回答您的更具体的问题

建议是在实现生物识别API时,将 CryptoObject 传递给 authenticate()。如果遵循该建议,则可以,您将在调用 authenticate(promptInfo,cryptoObject)之前检查 canAuthenticate()。造成这种情况的原因有很多,您可以通过阅读上面指出的博客文章获得这些原因。

The recommendation is that you pass in a CryptoObject to authenticate() when implementing the biometrics API. If you follow that recommendation, then yes, you will check canAuthenticate() before calling authenticate(promptInfo, cryptoObject). There are a number of reasons for this, which you can get from reading the blog post pointed to above.

由于您的问题专门与 setDeviceCredentialAllowed(true)有关,请务必记住 canAuthenticate()可以。它检查三件事:设备上是否有生物识别硬件可用,用户是否已注册模板或用户是否启用了生物识别认证。

Since your question is specifically about setDeviceCredentialAllowed(true), it's important to recall what canAuthenticate() does. It checks for three things: whether there is biometric hardware available on the device, whether the user has enrolled templates, or whether the user has enabled biometric authentication.

因此,您在您的情况下,不能使用 canAuthenticate(),因为它仅与生物识别有关,而 setDeviceCredentialAllowed(true)接受设备PIN,模式或

Hence, you cannot use canAuthenticate() in your case since it's exclusively about biometrics whereas setDeviceCredentialAllowed(true) accepts device PIN, pattern or password.

请注意,尽管建议您使用 CryptoObject ,但 setDeviceCredentialAllowed() CryptoObject setNegativeButtonText()不兼容。

Note that while the recommendation is that you use CryptoObject, setDeviceCredentialAllowed() is not compatible with CryptoObject nor with setNegativeButtonText().

P.S。您也可以从此博客中受益发布

P.S. You may also benefit from reading this blog post.

这篇关于BiometricPrompt:为什么要在启用setDeviceCredentialAllowed之前检查KeyguardManager.isDeviceSecure()?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆