You might see this error appearing in your error monitoring tools or in your on-device testing after installing Identity Vault into your application. This error is caused by a concept in Android known as "Strong vs Weak biometrics". Android classifies biometrics for each device into one of these two categories, though just because one type of biometric is classified into one category for one device does not mean that the same biometric on a different device will be classified the same way. For example, on a Samsung device with both Fingerprint and FaceID biometric support, only the fingerprint reader is considered a Strong (or class 3) biometric security. The FaceID implementation is designated as a Weak (or class 2) biometric. However, on a Google Pixel 4 device, FaceID is classified as a Strong biometric for that device.
Knowing the difference is important in understanding the error above. Identity Vault requires a class 3, or Strong biometric, be used to securely store the data on a device when using the biometrics option. If a user has a device that only has a Weak biometric option enabled when attempting to create or unlock the vault, the following error is thrown in the console:
At least one biometric must be enrolled to create keys requiring user authentication for every use
If you or one of your users runs across this issue, it can cause your app experience to be impacted if you rely on Identity Vault to store any of your data. The best way to address this is to wrap any of your calls to login or unlock in a try/catch block. In your catch block, you can check for this error and if it is occurring, you can lookup the available hardware for an alternative biometric (ideally fingerprint) and prompt the user to configure a different, or additional, biometric option on their device. Alternatively, finding no other options, you can choose to disable biometric security on your application in favor of using an app specific passcode.
An upcoming release of Identity Vault will provide some additional tooling to address this issue, however the changes will require updating libraries from Google that include breaking changes. Because of the extended timeline in addressing this issue, we recommend implementing the solution above until the next major version of Identity Vault is released.