When creating a VirtualDisplay for a VirtualDevice, we need to do some
extra work like setting up for input injection, creating a
DisplayWindowPolicyController, and grabbing a wakelock to keep the
display awake. Some parts of this extra work end up calling back into
the DisplayManagerService from another thread, but since we're already
holding the mSyncRoot lock we sometimes get into situations where
those threads get blocked trying to acquire mSyncRoot, while holding a
lock that another thread ends up needing like the global window
manager one, so we get deadlock.
The fix in this CL is to break up the extra work the
VirtualDeviceManagerService needs to do into two parts: one part that
happens before the VirtualDisplay is created, and one part
after. Neither of these needs mSyncRoot to be held.
Fixes: 230544802
Test: atest CreateVirtualDisplayTest
Change-Id: I6a6e03f816567579510b3f1ef0705375549a3c88
Add a category for DisplayManager#getDisplays() that includes
disabled/inaccessible/temporary displays in the set of returned
Displays.
Bug: 221071695
Test: adb shell cmd display get-displays \
android.hardware.display.category.ALL_INCLUDING_DISABLED
Change-Id: If06f7f8b7f9ba4779a19d24d76fb49e95a908afc
In Android 13, this sensor type is generally not expected to be used by
apps.
Bug: 224619073
Test: compile; comment change only
Change-Id: Ic6f56b6d354777dcf608d34314d6e4e7b7af36b8
Describe the tradeoffs of preview jitter reduction, and mention that
the application can turn off jitter reduction for better latency.
Test: Build
Bug: 195025014
Change-Id: I68f99efe6a35ae9db0f4cdf75ef31879f8550ff8
This reverts commit 6b3c6cae3f.
Changes from revert:
- Explicitly maintain the same behavior as previous versions of Android,
where injection is allowed into all window if the caller has the
INJECT_EVENTS permission, even if it is targeting a certain uid. This
fallback will be removed separately in b/228161340.
- Clear the calling identity before checking if the injection source has
a permisssion to avoid hitting blanket-checks in PackageManager that
denys permissions in some cases, such as if the permission check call
is coming from an instant app (b/228319794).
- Leave the existing IInputManager#injectInputEvent method signature
unchanged, and add a new input method injectInputEventToTarget to
perform targeted injection. This makes it so that tools or apps
relying on the @UnsupportedAppUsage injection method will not be
broken by a change in the method's signature (b/228583652).
Bug: 207667844
Bug: 194952792
Test: Run tests affected by b/228319794 and its duplicates using
cts-tradefed, so that they are also run as instant apps.
Test: Test scrcpy tool works locally
Change-Id: I503e4f087501e3aecf2c18b4b1d27e51ecda59ac
Merged-In: I503e4f087501e3aecf2c18b4b1d27e51ecda59ac
Shared outputs are not expected to be part of the main output
configuration list. Expect to receive the shared surfaces only
as part of the corresponding shared list.
Bug: 231636379
Test: Camera CTS
Change-Id: I67547a38ed97d55c8270196403d4af5d62795351
Make sure a consistent and comprehensive set of tests run when parts of
the input pipeline are changed.
Bug: 231623960
Test: presubmit
Change-Id: I08cd9966d436d21694e26b81aaf9c141cea47595
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
