Closed davidvavra closed 5 years ago
Hello @davidvavra. You can currently customize the UI within the boundaries of the Android UX recommendations for old fingerprint authentication. The dialog UI and behaviour was suggested by the Material guidelines to look like it currently does...
For the next SDK release (June 2019), we will move to a unified Android P biometric authentication, that is the new suggested way to do biometric authentication, and the UI will follow the Android recommendations again.
Please do not attempt to deviate from what Android recommends. Despite having good intentions, you will probably deliver bad UX... You probably have more urgent things to do anyway. ;-)
Specifically, having a custom app based counter of failed auth attempts seem like a bad idea to me - it will interfere with the Android system counter of failed auth attempts and you will have to handle more states (at some point, your app will think there are 3 attempts left, but the user will only have one attempt since the system already registers X failures somewhere else).
Just a quick note: You certainly can override the whole biometric authentication GUI behaviour by setting the "biometry key" property of the authentication object yourself (when commiting activation and when preparing for signing):
PowerAuthAuthentication authentication = new PowerAuthAuthentication();
authentication.usePossession = true;
authentication.usePassword = null;
authentication.useBiometry = getSomeKeySomewhere();
However, I would suggest not to do so. Not only storing the keys in the Android Keystore correctly can be a bit tricky, but you will also disconnect the biometry handling logic from the rest of the SDK (for example, you might need to handle activation removal), and what we also do in our SDK is that we incorporate the best practices and Android guidelines into our GUI. This is sufficient for the customers with app ratings as high as 4.8 - consider developing the GUI with what we have now and possibly improving it later...
Thanks for a detailed explanation. I'm all for Material design, but our design has it integrated in our UI as a bottom sheet (not a dialog in the center) - very similar to the design you linked. So more flexibility would be good. However this is mostly about the failed attempts. You gave a good arguments not to change default behavior, I will pass them in the company.
So, we have finally merged our support for BiometricPrompt
into develop
branch. At first, I would like to say, that this brand new API introduced in "P", is quite poorly designed and doesn't provide all information that applications typically needs. For example, it's impossible to determine the biometric status, before you actually try to authenticate (that's quite ridiculous). That will be solved in Android "Q" 🥇 by a brand new BiometricManager
. We're trying to determine the status in the best effort (like access an old, deprecated FingerprintManager
, just like support library does).
So, back to your requirement. There's a new method in callback API that informs application that authentication failed. We're also have a new "not recognized" error code that is reported in case that biometric image is really not recognized. Unfortunately (for you), that's swallowed by SDK itself and allows us to simulate entering a wrong credentials. That basically leads to increase failed attempts counter on the server. You can use more low level API to override this behavior, but I would not recommend you to do this 😀
The good thing is that now we close the dialog in case that FingerprintManager
reports the failure. It's copying the behavior of BiometricPrompt
which also closes itself in case of error.
I'm closing this issue, because it's irrelevant now. The support for BiometricPrompt
will be released in SDK version 1.2.0
, which requires server 0.21
and newer.
We are using fingerprint authentication. There is a business requirement to switch to PIN authentication when user enters fingerprint wrongly 3 times.
The Android SDK uses a custom dialog for fingerprint and returns us only two callbacks (success or cancelled). We would need a third callback (fingerprint not recognized) to build our custom logic.
Or can we do it without your dialog? We would like to customize the UI anyway.
Possibly related to #19 and #112 cc @TomasKypta :)