Fix fingerprint listening state race conditions
When calling cancel() on the cancellation signal, it doesn't happen
immediately. Now, because of a state messup during boot, we go
through the sequence
startListeningForFingerprint
stopListeningForFingerprint
startListeningForFingerprint
However, the cancellation callback from stopListeningForFingeprint
happened AFTER the second startListeningForFingerprint, so we assumed
that fingerprint detection was not running anymore but in reality it
was - leading to weird states and all kinds of small state messups.
Introduce a state machine to track when we we called cancel but
waiting for the confirmation of FingerprintService in order to track
this properly.
Bug: 23380500
Change-Id: I403479fb749cf7c22b73611b69698e8b771777d0
1 file changed
