* changes:
Demote AlwaysOnHotwordDetector to SystemApi
Sessionize VoiceInteractionManagerService
Sessionize the SoundTriggerService layer.
Use standard API in SoundTriggerTestApp
Fix bug in dumpsys
Require identity information in SoundTrigger.java
Associate an originator identity to sessions
Extract permission checking as a separate aspect
Correctly handle HAL death
The added test API is used to ignore all votes in
DisplayModeDirector app votes. This way only the app
requested display mode will be picked. The API will be
used for testing app mode switch requests.
Bug: 159113268
Bug: 158316271
Test: m
Change-Id: I257636ae2a6ed74044e71e49a99024682c3a92c5
Add support for 10bit opaque and private RAW_DEPTH10 image format
which is similar to RAW_DEPTH.
Bug: 167250258
Test: Manual using camera application.
Change-Id: Ib2ee11570429d7a9a53e9dd6bc2042a1f5eaa760
When calling NativeAllocationRegistry for HardwareBuffer, it needs the
correct size so GC knows how much memory has been allocated and when to
run. The current behavior uses a fixed size so it's likely the buffer is
actually consuming more memory than what GC thinks.
Test: atest ContentCapturePerfTests:LoginTest
Bug: 168149157
Bug: 168154840
Change-Id: Ife174478b2b76214b438de2757289a973330c979
This change establishes a connection between the AOD interrupt and the fingerprint sensor.
Bug: 165267247
Test: manual - enter device from AOD with fingerprint
Test: manual - On AOD, fail fingerprint auth, check that HBM turns off
Change-Id: Ia8ca9a145590d8b5629a584807e110ca3600b813
Bug: 152242790
Bug: 162341940
Test: On fingerprint/face devices, enroll max number, notice
enrollment shows the "max enrolled" string and prevents the
user from enrolling additional templates.
Change-Id: I50c3b5810b0868d2ba9f1e923318585302b5776d
Deprecate the way to attach to SoundTrigger that doesn't include
identity information. Plumb that up to the SoundTriggerService layer,
where it is temporarily provided in a backward-compatible way instead
of with the actual identity.
Change-Id: Icc2bf3b80300bd2b75c81d253986b4e1582737ca
Bug: 163865561
This change formalizes the permission enforcement patterns in the
sound trigger middleware layer. Every sound trigger session is
associated with an originator identity, established during attachment.
This identity is the used to authorize any operations performed on
this session, including data deliver via callbacks.
Temporarily, for b/w compatibility the existing SoundTrigger.java API
is preserved. Follow up changes will use the newer API, which requires
an identity to be provided.
Logging / dumpsys aspects have been modified to include the originator
identity associated with every call / session.
Change-Id: If83b151bd182af5a0dd98ff23dce252018de936b
Bug: 163865561
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
