1) Introduces BiometricDeferredQueue in LockSettings package to move
slow operations off of the critical unlock path.
2) Changes generateChallenge to require sensorId. Callers to
generateChallengeBlocking are currently not affected. Their path
will need to be updated in the future.
3) Adds resetLockoutRequiresHardwareAuthToken for fingerprint sensor
properties, since IBiometricsFingerprint@2.1 and its derivatives
do not require the HAT yet
Fixes: 145978626
Test: atest com.android.server.biometrics
Test: Able to enroll after entering password
Test: Reset lockout on face device with single-profile-per-user
Test: Reset lockout on face device with managed profile + unified
credential
Test: Reset lockout on face device with managed profile and separate
credential (both owner and managed profile)
Test: Reset lockout for secondary user
Change-Id: Id4d7c39274a52ef61709161b6f24ec4f5d76720e
1) It may not be practical in all cases to bump the HIDL to
fingerprint2.3. So, give the framework a way to override this
parameter.
2) Updates Fingerprint21 so the HAL callback is a static inner class.
This A) allows subclasses to extend/override its functionality, and
B) is necessary now because the callback needs to be created prior
to Fingerprint21 construction (see 3 below)
3) Changes Fingerprint21 so that several objects are created before
its constructor. This is necessary because Fingerprint21's
constructor requires usage of the HAL, which implies the callback
must be ready, since using the HAL requires a valid callback. In
other words, the callback must be created before
Fingerprint21UdfpsMock invokes Fingerprint21's constructor.
4) UDFPS accept must be touched within 10s of sensor auth succeeding
5) Shows debug messages on UdfpsOverlay since fingerprint sensor no
longer gives feedback, etc
Bug: 163864182
Test: adb shell settings put secure ... (see defs in
Fingerprint21UdfpsMock)
adb shell stop && adb shell start
Change-Id: I07c3801024087f2e8ef10f125d20cb536aefbd91
IBiometricsFace@1.0 only supports a single in-flight challenge.
Currently, challenge owners paths are designed to never conflict
lifecycle-wise. However, to decouple resetLockout (which relies
on challenge) from the critical user unlock path, we need to
keep track of challenge interruptions, and notify clients when
an interruption starts/finishes.
This change only adds the infrastructure for tracking challenge
interruptions. A following change will make use of this.
Bug: 145978626
Test: Builds
Change-Id: I708312cafad29614e3708b5c606ae8a90704ac66
to test their behaviors
Bug: 162627132
Test: atest VirtualDisplayTest#testTrustedVirtualDisplay
Test: atest VirtualDisplayTest#testUntrustedSysDecorVirtualDisplay
Change-Id: I8e32cb42d93c59c015def0b0593038a0d961e3d4
Decouples the remainder of challenges from LockSettingsService.
Clients that require Gatekeeper HATs that wrap challenges should
request the Gatekeeper Password, then request LockSettingsService
to verify(GatekeeperPassword, Challenge). If the challenge is
biometric-related, it must be generated after LockSettingsService
completes verifyCredential, since LockSettingsService internally
does generateChallenge/resetLockout/revokeChallenge.
Bug: 161765592
Test: CtsVerifier biometric portion
Test: Reset fingerprint/face lockout
Test: atest com.android.server.locksettings
Change-Id: Icb384194ce5007b264068e697113d55cbf94945b
Remove the "CameraDevice#createCaptureSession" reference.
The capture session create methods do not return session
instances.
Bug: 162988515
Test: make docs
Change-Id: Icc72c046b3ee337af8242ecb823cf8897e3eff5c
Change aidl vibrate API to use VibrationEffect.
Handle default amplitude in InputManagerService.
Set both channels for vibration amplitudes.
Bug: 136215622
Test: Connect game controller with rumble support and play game for
force feedback effect.
Change-Id: Ib25dc4ea1b25031707c728ad947c6d8238480e30
If a device has an active proximity wakelocks while proximity
is in the "near" state, a press of the power button will temporarily
ignore proximity sensor allowing the screen to turn back on.
It will stop being ignored where there is a change to the
proximity sensor state.
Bug: 162443904
Test: atest PowerManagerServiceTests, atest DisplayManagerTests
Change-Id: I2656cca3e643e278cd5e5fedc2d74d9cbca82c2b
Setting the target audience of the CEC <Standby> message when going to sleep
Before this change: sent to the TV only
After this change: a setting initialized by a system property determines whether to send it to the TV only (default), all devices or not at all
Test: atest HdmiCecLocalDevicePlaybackTest and manually tested that system property takes effect.
Bug: 161205654
Change-Id: I3a3ba3d40acbb4f6bf65e402c446b0683500b4dc
Add support for sending vibration amplitude(s) from OneShot and
Waveform VibrationEffects to the native layer to support variable
amplitude vibration motors in input devices such as gamepads.
Fix bug with vibration API. In N, the VibrationEffect method which
takes both timings and amplitudes states that each timing/amplitude
pair makes the vibration last for the specified duration with the
specified amplitude, 0 meaning the motor is off. If this method
is used with an input device vibrator, it turns off for every even
numbered element, regardless of the amplitude value. The method
which takes only timing values works as expected.
Test: Connect a gamepad whose driver supports FF_RUMBLE, find it
with the android input framework, and do something like this:
// waveform where rumble magnitude doubles every 2 seconds
VibrationEffect effect = VibrationEffect.createWaveform(
new long[] { 2000L, 2000L, 2000L, 2000L, 2000L },
new int[] { 16, 32, 64, 128, 255 },
-1);
inputDevice.getVibrator().vibrate(effect);
Bug: 136215622
Bug: 38511270
Change-Id: I06afd374e30d63b49aa79fa2b68e2a236b5347b2
For each modality, updates/adds getSensorProperties() to return a list
of all sensors, containing their sensorId and other properties.
Bug: 160024833
Bug: 145978626
Test: atest KeyguardUpdateMonitorTest
Test: enroll/auth on fingerprint/face devices
Change-Id: I9adc4798183f53881f3592a8e72e6bd3595fbf1e
Fingerprint authentication should not expose accept/reject/lockout
when the user is encrypted or locked out. This is possible with
IBiometricsFingerprint@2.1 since lockout is controlled by the framework.
IBiometricsFace@1.0 does not support this since lockout is controlled
in the HAL (or lower).
Bug: 79776455
Test: On fingerprint device, during encrypted or lockdown, any finger
works, lockout never occurs
Test: BiometricPromptDemo, normal path is run (e.g. incorrect fingers
are rejected)
Test: Test no effect on face device
Test: atest KeyguardUpdateMonitorTest
Change-Id: I9ded8efd80d4f8b92ce054262e721853703c6437
Merged-In: I6c9717d1f8ed3e844b3d92727396e2ce2e7fd94f
Fingerprint authentication should not expose accept/reject/lockout
when the user is encrypted or locked out. This is possible with
IBiometricsFingerprint@2.1 since lockout is controlled by the framework.
IBiometricsFace@1.0 does not support this since lockout is controlled
in the HAL (or lower). Adds enough plumbing on SysUI so that it will
work once the HAL supports it.
Introduces FingerprintDetectClient, which treats HAL accept/reject as
the same, and does not increase the framework's lockout counter.
Introduces FingerprintManager/FaceManager#getSensorProperties so callers
can determine features before invoking certain code paths, such as
finger/face detect.
Bug: 79776455
Test: On fingerprint device, during encrypted or lockdown, any finger
works, lockout never occurs
Test: Test no effect on face device
Test: atest KeyguardUpdateMonitorTest
Change-Id: I6c9717d1f8ed3e844b3d92727396e2ce2e7fd94f
Similar to I6c037f90691e4da2f88419c6f80994e8ae1565b0.
All clients (keyguard, settings) should already be checking isHardwareDetected()
before doing any face-related operation.
Test: load aosp_flame-eng, sysui does not crash
Fixes: 161232319
Change-Id: I2d394114073ef3df766e04430190e3430e7d1579
This is a pretty big change since it basically allows/requires us to
have FingerprintService not extend from BiometricServiceBase anymore
Bug: 157790417
Bug: 158481661
1) Move Fingerprint2.1-specific code into wrapper class. This will
A) Make it obvious where global dependencies still exist, and
B) Make room for new HIDLs
2) Sensor-ID is creeping in. Eventually there will be Manager-level
APIs for platform code to query functionality. Most likely all
IFingerprintService/IFaceService interfaces will have sensorId
as a parameter soon
3) Added Udfps interface and UdfpsHelper
4) FingerprintService no longer extends from BiometricServiceBase.
BiometricServiceBase will be removed soon. A lot of permission
checking is fingerprint-specific, since face operations all
require internal permission. Thus, moved canUseBiometric into
FingerprintService
5) Updated fingerprint retry logic in KeyguardUpdateMonitor. The
retry should keep going if isHardwareDetected()==false. Also
increased the retry counter, seems like HAL reload time has
increased.
Test: enroll, auth (settings), auth (keyguard), auth (BiometricPrompt),
rename, remove
Test: atest com.android.server.biometrics
Test: atest KeyguardUpdateMonitorTest
Test: Reset lockout
Test: atest AccessibilityFingerprintGestureTest
Test: Fingerprint stack recovers after HAL death, e.g.
1) Go to keyguard
2) adb shell ps | grep -i fingerprint
3) adb shell killall -9 android.hardware.biometrics...
4) fingerprint auth resumes after HAL reloads
Test: CtsVerifier
Test: adb shell dumpsys fingerprint
Test: Modify settings to not cancel auth when onPause, notice
task stack listener stopping settings auth
Test: Invoke assistant on keyguard, auth continues
Test: No effect on face auth devices (enroll, auth on keyguard,
BiometricPrompt)
Change-Id: Iffbdd841c093fe612e664195dcf79319d1d444ab
* changes:
29/n: Fix EnrollClient onClientFinished
28/n: Move authenticatorId update to RemovalClient
27/n: Slightly update/fix ClientMonitor.FinishCallback
26/n: Move ClientActiveCallbacks to its own file
25/n: Make InternalCleanupClient generics/templates more correct
24/n: Use lazy retrieval for HAL
23/n: Move LockoutResetCallback tracking to its own class
Decouples shared code in BiometricServiceBase. The code that notifies
clients (keyguard) of lockout reset will eventually also send the
sensorId that lockout was reset for. However, that will depend on
subsequent changes.
Bug: 157790417
Test: adb shell killall -9 com.android.systemui, see callback removed
Test: Lockout fingerprint, wait 30s, keyguard is notified and starts
authenticating again
Change-Id: I791ce6c146500f81638a56587e4e90d8f1933f5e
* changes:
22/n: Remove "flags" parameter from authenticate and enroll
21/n: Clean up ClientMonitor parameters
20/n: Update infrastructure to support upcoming scheduler
19/n: Remove dead code
18/n: Make more HAL operations ClientMonitors
Not used and ambiguous. Also fixed naming for hardwareAuthToken param
in areas that were previously missed.
Bug: 157790417
Test: Builds
Change-Id: I55f73d519cd3c69c4c03b6408588e793c8553869
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
API guidelines recommend adding ability to set the executor
Bug: 156046799
Test: atest HdmiControlServiceTest
Change-Id: I1f6dde6efc498a112ac7da2c61c36fcc2afa6638
Broadcast intents on below control request
Log both the request and response for 51 control request (Get Protocol)
Log both the request and response for 52 control request (Identifying information)
Log both the request and response for 53 control request (Start accessory mode)
bug: 139264039
Test: Check the broadcast intent could be received
Change-Id: I7c8db41ee05398200e235cf10dde96ba89b306e8
* changes:
Implement a bare-bones UDFPS overlay
Add interfaces for controlling the UDFPS overlay
Add isUdfps to FingerprintService
Add onFingerDown/onFingerUp to FingerprintService
1) SetFeature
2) GetFeature
3) ResetLockout
The following will be done in a separate CL
4) SetActiveUser
5) GetAuthenticatorId
Test: Enroll face, go to face settings, toggle attention setting.
Setting is persisted in the HAL and retrieved correctly to
Settings.
Test: Fingerprint/Face lockout, resetLockout
Test: Multi-user / Multi-profile enroll, auth, resetLockout
Bug: 157790417
Change-Id: I063fcc73f0129a1d31214f30928f32708e14e2ff
* changes:
Clear identity when checking BiometricService#isStrongBiometric()
17/n: Make generateChallenge/revokeChallenge ClientMonitors
16/n: Introduce ClientMonitor#FinishCallback
15/n: Combine EnumerateClient into InternalEnumerateClient
14/n: Remove the use of groupId
13/n: Remove the use of DaemonWrapper
