Skip to content
Commit dbe67876 authored by Kevin Chyn's avatar Kevin Chyn
Browse files

20/n: Update infrastructure to support upcoming scheduler

1) Templates ClientMonitor<T>, so that redundant code can be removed
2) Moves ClientMonitor and subclass's HAL reference and FinishCallback
   to be initialized in ClientMonitor#start. This allows the logic
   to be centralied in the upcoming scheduler (e.g. HAL availability
   check, having the scheduler use an internal FinishCallback, etc)
3) Moved HAL null-checking to a centralized location. As such, also
   added abstract ClientMonitor#unableToStart method, which is invoked
   when the ClientMonitor can't/shouldn't be started. Each subclass
   handles this case individually based on its own API lifecycle
4) Added BiometricAuthenticator interface to query current lockout mode.
   Looks like BiometricService was relying on receiving onError(lockout)
   being sent before onReadyForAuthentication. However, to clean up the
   FingerprintService/FaceService code and move client lifecycle into
   ClientMonitor, we shouldn't rely on this ordering.

Note that this change also makes BiometricServiceBase templated solely
for the purpose of getting a reference to the biometric HAL. This is
a little ugly. This is temporary and will only exist during the middle
of the refactor. By the end of the refactor, BiometricServiceBase will
be gone/deleted, and we should end up with a Scheduler<T> :)

Bug: 157790417

Test: Enroll, authenticate, resetLockout, set/getFeature in settings,
      internal cleanup (modifying fingerprint/face utils), for
      fingerprint and face, and for multi-user/profile
Test: Lockout user, then request authenticate again. Notice no vibration,
      no UI, and correct error result
Test: Lockout user, then request auth with biometric|credential.
      Credential UI is shown immediately.
Test: Lockout user, then check canAuthenticate. Returns success, since
      the hardware is OK, just the user was rejected too many times.
      Note that this is functionally the same as before, since the
      sensor would have been considered eligible.
Test: atest com.android.server.biometrics

Change-Id: I420002d2b54a4ab530d0698fcc612ee7c770d5ff
parent 11e1f825
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment