This will allow to reuse the logic around onEnrollmentsChanged for face.
Face doesn't have a mechanism to cache the enrollment state, and there
is nothing fingerprint-specific in FingerprintStateListener, so it's an
obvious choice the refactor this class to support all biometrics.
Bug: 221037350
Test: atest com.android.server.biometrics
Test: atest com.android.systemui.biometrics
Test: atest KeyguardUpdateMonitorTest
Test: com.android.server.biometrics
Change-Id: Id039136c8fb01627de5a0f3e92d2f9fd89500539
If the physical camera settings map doesn't contain a key for the
logical camera id, throws an exception.
Test: LogicalCameraDeviceTest
Bug: 220730433
Change-Id: I716fa4b81a6e48538aebfac41b96d5d21fdb6a2e
Previously, any app could inject input events into the system via the
IInputManager#injectInputEvent API. The injection was only allowed if
the input event targeted a window owned by the same UID as that of the
process calling the API. This had drawbacks metioned in the bug.
Here, we change the input injection security model so that the signature
permission INJECT_EVENTS is required to inject events. This permission
is given to the system and the shell, so input injection can still be
done through the 'adb shell input' command. We also allow injection from
instrumeted processes where the instrumentation source has the
permission. For exmaple, running a test from the shell allows for the
test to inject events.
We also add support for a targeted injection mode, where the input
injection succeeds only if the target window for the event is owned by
the provided UID. This allows us to support injection from the
Instrumentation class, which only allows for injection into windows
owned by the same UID. In contrast to this, injection from the
UiAutomation class will target all windows, including system and spy
windows.
Bug: 207667844
Bug: 194952792
Test: atest inputflinger_tests
Test: atest WindowInputTests
Test: manual with test app: app cannot inject navigation gestures
Change-Id: Ib0d66eff3fc2f061e7c0d3b7e139a841a9bcebc7
The API 'getDevice' can return null. Let's make sure null isn't
dereferenced. Also, add nullability annotations to make it easier to
follow.
Bug: 227733127
Test: build only
Change-Id: Ice514f27d4347528d009969174f09078dfa2afac
This will force the new to user start on the scheduler, open a new session, and close the old user's session in the HAL.
Add a similar user swtich hook to keyguard to refresh the lockout state. Note that lockout behavior is still ill-defined (b/225986544) and HALs may not support a lockout state per user.
Bug: 205908931
Test: manual (unlock, cause lockout, & switch users)
Test: atest KeyguardUpdateMonitorTest
Change-Id: I89d3d7454894bc5caa0cac33e96d7fd0d61e9083
Removing GHBM logic from codebase since it has been replaced by LHBM.
This will simplify the current implementation, and assist with future
refactors and the transition to Kotlin.
Fixes: 227229729
Test: atest UdfpsViewTest
Test: atest DisplayModeDirectorTest
Change-Id: I0d1e7ffb610154f4d56afab8385883a0389f89db
* changes:
Only invoke listener once physical address becomes known
Don't remove devices on onHotplug()
Assign local device portId 0
Set device type on first message received
Since we already have IWindowManager#syncInputTransactions, we can
remove the need to have an input injection API in the window manager
interface.
Bug: 227356680
Test: presubmit
Change-Id: I730d05eec85978d8813e0924ddb4dba26922ea9f
This CL affects TV panels and Audio Systems only.
Before HdmiCecNetwork existed: devices were removed when
HotplugDetectionAction detected a hotplug out, and TIF was informed.
Before this CL: devices were removed from the CEC network onHotplug,
but the listener to inform TIF wasn't invoked. This was causing
multiple issues.
After: on TV panels and Audio Systems, only remove devices when
HotplugDetectionAction detects a hotplug out,
just like before HdmiCecNetwork existed.
Test: atest
Bug:213417037
Change-Id: I4181b4650b70101da44fd205e4df9eb566f74496
FingerprintManager picks up the client app's attribution tag and sends
it to FingerprintService, which uses it in calls to
AppOpsManager#noteOp.
Bug: 226171374
Test: FingerprintManagerTest
Test: FingerprintServiceTest
Change-Id: Ieb2393b5d8d2f9103f044bd598e9a401ad7ef4c1
This adds an API to disable/restore doze settings.
This is needed by CTS in order to have a known doze
state when running certain tests.
Test: atest ActivityVisibilityTests
Test: atest InputMethodStartInputLifecycleTest
Bug: 140367074
Bug: 216182288
Change-Id: I112c37a90c5b528c4e64e18b06e57024ea277287
Clarify that 3A regions need to consider additional crop for preview
stream due to aspect ratio mismatch.
Test: Build
Bug: 226939029
Change-Id: I660e83bb4aae088dc231827bd9a075879c573538
Operations that wait for cookies (authentication) do not set their lifecycle callback until started. This leaves a small window when failures are not propogated to callers (i.e. fast/immediate failures).
This also adds some additional checking for stale UI events (point up/down) that are delivered after the operation has ended.
Fix: 216071532
Test: atest com.android.systemui.biometrics com.android.server.biometrics
Change-Id: I7f7500db0a42b2ea97e171e26148ee68b15f5ae8
Previously we only stopped HBM if we receive onAcquired with
info=FINGERPRINT_ACQUIRED_GOOD.
Update the onAcquiredGood method to be more generic (onAcquired,
with an acquiredInfo parameter) so the UdfpsOverlay can turn
off HBM for the appropriate acquiredInfo messages.
Bug: 222117182
Test: manually test on Lock Screen, enroll and biometric prompt
Test: atest SystemUITests
Change-Id: I6b21fbf65a6f38660fe8beab617d17cef3ad50ba
The standard dynamic range profile will always be present as part of the
advertised profiles. Additionally the same profile must never advertise
extra latency due to the format selection.
Bug: 215396395
Test: Camera CTS
Change-Id: I0ad7dd23a1b1f742293b4c52a48a8fca98b7925c
