Status Update
Comments
ja...@robinhood.com <ja...@robinhood.com> #2
I beleive the problem is inside onSizeChanged that is called after onConfigurationChanged, it has following code:
if (w != oldw) {
recomputeScrollPosition(w, oldw, mPageMargin, mPageMargin);
}
w always not equals oldw when changing orientation, so recomputeScrollPosition is called, but whit the same values for margin and oldMargin.
This should be fixed.
ja...@robinhood.com <ja...@robinhood.com> #3
ju...@robinhood.com <ju...@robinhood.com> #4
ju...@robinhood.com <ju...@robinhood.com> #5
di...@google.com <di...@google.com> #6
I managed to fix the issue by importing the source code of ViewPager in my project and modifying from onSizeChanged method the following line:
From:
if (w != oldw) {
recomputeScrollPosition(w, oldw, mPageMargin, mPageMargin);
}
To:
if (w != oldw) {
recomputeScrollPosition(w, oldw, 0, 0);
}
dr...@google.com <dr...@google.com>
er...@google.com <er...@google.com> #7
ublic class FixedViewPager extends ViewPager {
public FixedViewPager(Context context, AttributeSet attrs) {
super(context, attrs);
}
public FixedViewPager(Context context) {
super(context);
}
@Override
protected void onSizeChanged(int w, int h, int oldw, int oldh) {
super.onSizeChanged(w-this.getPageMargin(), h, oldw-this.getPageMargin(), oldh);
}
}
eb...@google.com <eb...@google.com> #8
ja...@gmail.com <ja...@gmail.com> #9
eb...@google.com <eb...@google.com> #10
Workaround in post #6 still works.
ja...@robinhood.com <ja...@robinhood.com> #11
ja...@robinhood.com <ja...@robinhood.com> #12
eb...@google.com <eb...@google.com> #13
ja...@robinhood.com <ja...@robinhood.com> #14
Re
eb...@google.com <eb...@google.com> #15
In the
I don't know what's causing this. In AOSP main (future Android 15), Keystore logs information about the auth tokens it receives, which may give a hint. But since you're using Android 13, that additional log statement is not present.
Looking at Keystore's code, I don't see any problem with how Keystore generates and compares the timestamps of auth tokens. The error message does say that the auth token is expired, though. If we assume the timestamps are correct, the way that could still happen is if the fingerprint HAL incorrectly sets other attributes of the auth token (such as the authenticatorId which identifies the fingerprint enrollment), causing Keystore to consider the new token to not match. If there was an earlier fingerprint authentication with the correct attributes but more than 10s ago, that one would then be checked instead, causing the token expired error.
Does this issue reproduce on the first fingerprint authentication since boot, and if so is the Keystore error message in the log still "matching auth token is expired"?
Note that the fingerprint HAL is device-specific, and the emulator (goldfish) has its own implementation of it as there is no physical fingerprint sensor on the emulator. I wonder if the
ja...@robinhood.com <ja...@robinhood.com> #16
Seems like the issue I was noticing might be limited to the emulators. We've done a bit of testing internally on different devices, and I think in general: allowing for device-credential/LSKF when biometric fails seems to resolve the issue. We will do some more testing, but I'm hopeful.
It might be a good idea to include device-credentials as a suggestion in the official docs when something like the bug reported here happens to users. The discussion of LSKF here was the first I'd ever heard of it as a reason to support device credentials with BiometricPrompt.
ja...@robinhood.com <ja...@robinhood.com> #17
Seems like the issue I was noticing might be limited to the emulators.
To clarify, for this: I mean the issue from
We've done a bit of testing internally on different devices, and I think in general: allowing for device-credential/LSKF when biometric fails seems to resolve the issue.
And for this: i mean the issue from the beginning of this bug.
ga...@gmail.com <ga...@gmail.com> #18
androidx.biometric:biometric-ktx:1.4.0-alpha02
androidx.security:security-crypto:1.1.0-alpha06
Description
I'm noticing that even after a successful roundrip to Biometric authentication via BiometricPrompt, sometimes a UserNotAuthenticatedException is thrown when trying to initialize a Cipher object with a SecretKey managed by the AndroidKeyStore where that key was created with
setUserAuthenticationRequired(true)
.Steps to reproduce:
Note: This has been incredibly hard to reproduce reliably, but we have seen the issue in the wild on a large percentage of our users.
Cipher#init(secretKey, null)
, orSample Project
Sample Project which reproduces the issue on some devices with different approaches to using BiometricPrompt, CryptoObject, and the AndroidKeyStore:https://github.com/jasonwyatt/BiometricBug
BUILD INFO
EXPECTED RESULTS
We expect to be able to ask the user to authenticate with biometrics and then be able to successfully use a
SecretKey
which has been configured withsetUserAuthenticationRequired(true)
in conjunction with a Cipher object.OBSERVED RESULTS
On some occasions, a
UserNotAuthenticatedException
is thrown after successful authentication (this even happens within theonAuthenticationSucceeded
method of ourBiometricPrompt.AuthenticationCallback
implementation).Attached Bugreport
The attached bugreport comes from our actual app (not the sample app) and contains the exceptions being thrown - but not their full stacktraces. We have separately verified it comes from
Cipher#init(secretKey, null)
. Hopefully the bugreport can show additional information to the engineering team about the state of the AndroidKeyStore at least.