Fix KeyguardUpdateMonitor auth lifecycle issues
This is split into two high-level issues which together cause
strange auth behavior on keyguard:
============= Issue 1 =============
For fingerprint, auth ends when:
1) Success
2) Error
For face, auth ends when:
1) Success
2) Reject
3) Error
This change ensures that cancellation signal is set to null upon
any of these conditions, so that there is never an opportunity of
using a stale CancellationSignal.
Furthermore, do not invoke stale cancellation signal when
starting authentication. In the off chance the bug is re-introduced,
or if some other situation can cause a cancellation signal to be
non-null when keyguard requests auth again (e.g. bad state management
in keyguard), do NOT invoke the stale cancellation signal's cancel
method. The framework already handles this case gracefully and will
automatically cancel the previous operation.
============= Issue 2 =============
We have a runnable that's scheduled to run after X ms if
ERROR_CANCELED is not received after cancel() is requested. However,
there are various bugs around that logic:
1) shared runnable for both fp and face, leading to unexpected
and incorrect state changes (e.g. face does not respond to cancel
within X ms, both fp and face will go to STATE_STOPPED, even though
cancel() was never requested of fp
2) Always remove and re-add runnable when requesting cancel() though
it should never occur that cancel() is requested in close temporal
proximity, it never hurts to have the correct timeout before
resetting the state.
Bug: 195365422
Bug: 193477749
Test: manual
Change-Id: I3702f41c8af7e870798f19c43012a26281a6632a
1 file changed