Previously, when InputManagerService requests for PointerController to
change the pointer display, there was no way to know when the request
was completed or whether it succeeded. This could lead to a few issues:
- WM's MousePositionTracker's coordinates would not be updated until the
next mouse event was generated, meaning the position would be out of
sync.
- The creation of a virtual mouse device moves the pointer to a specific
displayId. In order to test this behavior, we would need to sleep in
the test code to wait for the system to update the pointer display and
position, resulting in generally flaky tests.
Here, we add a way to synchonize changes to the pointer display so that
InputMangerService can know the current pointer display with certainty.
PointerController, which is updated in the InputReader thread, is the
source of truth of the pointer display. We add a policy call to notify
IMS when the pointer display changes.
When the pointer display is changed, the cursor position on the updated
display is also updated so that the VirtualMouse#getCursorPosition() API
is synchronized to the pointer display change.
Bug: 216792538
Test: atest FrameworksServicesTests:InputManagerServiceTests
Test: atest PointerIconTest
Change-Id: I578fd1aba9335e2e078d749321e55a6d05299f3b
Merged-In: I578fd1aba9335e2e078d749321e55a6d05299f3b
Capture results can be present and can be safely passed back to
client in case of frame drops within the source image reader.
Detect cases where results will get discarded, filter the tags
and notify clients accordingly.
Bug: 230790669
Test: Camera CTS
Change-Id: Ia3f77d9398165663073c01bdf8d3421fd86a67c4
UDFPS position and assets are configured in pixels in native
resolution. This CL adds a mechanism to detect a runtime resolution
change and scale the UDFPS coordinates accordingly.
Bug: 223342274
Test: atest SystemUITests:com.android.systemui.biometrics
Change-Id: Iaa1f3d633b50019d06bdecb5063490ad6eb11272
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
Allow camera clients to query for any orthogonal camera parameters that
can be applied during advanced extension capture sessions.
Enable capture result callbacks in the same scenario as well as single
catpure requests to the preview client surface.
Bug: 198447410
Test: Camera CTS
Change-Id: Ia51cc0813a93963d628ea73beb54ed080f4696e7
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
