tree 1a7be814f415f9b630887f178ac75fcc5e5c0eff
parent 11e1f825ad0e0dccedbf330b745a93d08a6e57ac
author Kevin Chyn <kchyn@google.com> 1593479460 -0700
committer Kevin Chyn <kchyn@google.com> 1593637853 -0700

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