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
As part of the move to make all HAL operations a ClientMonitor,
this change makes generateChallenge return the challenge via a
callback.
Added generateChallengeBlocking() so that existing synchronous clients
can continue to work with minimal changes (only renaming is necessary),
and so that it's explicit that the call may take some time (up to
hundreds of milliseconds on some devices).
1) LockSettingsService#resetLockout path
2) Fingerprint/Face enroll path
Bug: 157790417
Test: Enroll on fingerprint/face devices
Test: ResetLockout on fingerprint/face devices
Change-Id: I99efc1c72c8ac994c56d6d2deaf3e0131e5b2dac
Upstream AOSP change doesn't have a newline at the location
this change addresses, causing a merge conflict
Test: Build, presubmit
Bug: 159464174
Merged-In: I957dfe35aacc3e397611d8ab0b9ad19a1130a3dd
Change-Id: I7614d420ad55129b04e0dfa9310e39d715ed2da7
Update the GeomagneticField coefficients according to the World
Magnetic Model 2020-2025 values and specify the base time in UTC since
calls to System.currentTimeMillis() will return a UTC based time.
Signed-off-by: Cory Hockenbury <chockenbury@gmail.com>
Change-Id: I7614d420ad55129b04e0dfa9310e39d715ed2da7
GroupId was never used. FingerprintService#enroll sets groupId to
always be the same as userId. This change removes it from (almost)
everywhere.
We should update BiometricUtils and subclasses so that new HIDLs
do not take space for groupId. Since the framework persists the
info and we do not want to deal with database migration, let's
leave it there until the devices which shipped with groupId are
EOL.
Bug: 157790417
Test: Enroll fingerprints with a build before this change. Update
to a build with this change - still able to authenticate, rename,
remove previously enrolled fingerprints
Change-Id: I21391f5ffb71b27d7f9d4cfd4e6253b6001276dc
Update the GeomagneticField coefficients according to the World
Magnetic Model 2020-2025 values and specify the base time in UTC since
calls to System.currentTimeMillis() will return a UTC based time.
Test: CTS test passes
Signed-off-by: Cory Hockenbury <chockenbury@gmail.com>
Merged-In: I7614d420ad55129b04e0dfa9310e39d715ed2da7
Change-Id: Ica9182053359e5387da57bb0b3b93347040160ed
