A windowless SurfaceControl could grant input via
IWindowSession.grantInputChannel, but other window may receive the
obscured events because of the type value of input window is always 0.
The obscured or partially obscured flag indicates that the window
received this motion event is wholly or partially obscured by another
visible window above it.
We have to filter out the trusted overlap so the motion event could
properly dispatch to the view if it is a security sensitive application.
Bug: 156063505
Test: enter split window mode and check the motion event
Change-Id: I10f63ea131a70ee8cc7d5c4b3e5ca4e5f06fdbad
* Imagine this event sequence:
1) the IME tries to re-attach an inline suggestion view to the
window (e.g. because IME layout changes), it calls into the system
server which causes recreating the backing view because it was
destroyed earlier due to 0 ref-count (this happens under the hood
without IME knowing it happens, so the view is still attached to
the window).
2) the IME receives a new inline suggestion pointing to the same
backing view (perhaps due to filtering kicks in).
3) the recreation from step 1 finishes, but now it will callback
to the new inline suggestion, therefore the old view doesn't receive
the new SurfacePackage. See RemoteInlineSuggestionUi for why.
4) the view in step 1 is detached from window, since it never
receives a SurfacePackage from the remote view, its detach shouldn't
cause a reference count down on the remote view.
Test: atest android.autofillservice.cts.inline (sanity test)
Bug: 154683107
Change-Id: I2e6814ef3889de603f6e170efcb795b69ec9febe
positionLost can be called from CanvasContext::destroyHardwareResources
which runs asynchronously to the UI thread. This means we could be
simultaneously executing releaseSurfaces on the UI thread. We need
to expand the scope of mSurfaceControl lock in positionLost. While
we are here we add a block comment explaining the previously
undocumented locking strategy.
Bug: 156264048
Test: Existing tests pass
Change-Id: I9cdb6a0f7aeffd878f1755f240e8896f0fb8bf01
Anecdotally this should cover typical messaging first screens
whereas 100 events seems to be small.
Test: make -j
Test: Manually start WhatsApp - check for lost events
Bug: 154777879
Change-Id: I3090584ec03714656948045189e0e0c068740c82
In the test we trigger the manual autofill request programmatically,
because the focus isn't on the field, we will not get the callback
from IME.
It would be better not to ask IME for inline request if the request
is manual and the view is not focused because it's a simpler/safer
approach and manual request without focus should be rare.
Bug: 154661868
Test: atest CtsAutoFillServiceTestCases
Change-Id: I783b2542094cdea547ebd58ce89f30d9cd421708
* changes:
Send fixed rotation adjustments to the associated client
Add support to override display adjustments by token
Add fixed rotation display adjustments
The transform hint is used to prevent allocating a buffer of a
different size when a layer is rotated. The producer can choose to
consume the hint and allocate the buffer with the same size.
Provide the graphic producer a transform hint if the layer and its
children are in an orientation different from the display's
orientation. The caller is responsible for clearing this transform
hint if the layer is no longer in a fixed orientation.
Bug: 152919661
Test: atest VulkanPreTransformTest
Test: confirm with winscope trace, buffers are allocated taking into
account the transform hint in fixed orientation scenarios
Test: go/wm-smoke
Change-Id: I2ccc21ed8af015716e6cdfde1e3cec67c99f3339
So the real information of display can be adjusted according
to the adjustments for the application started with fixed
rotation transform.
The enabling adjustments may be sent in different ways:
- Launch activity
The information is bundled with LaunchActivityItem.
- Resume activity or update non-activity window
Send a standalone FixedRotationAdjustmentsItem.
The disabling adjustments (null) are always sent by
FixedRotationAdjustmentsItem.
Bug: 147213487
Test: AppConfigurationTests#testRotatedInfoWithFixedRotationTransform
TransactionParcelTests#testFixedRotationAdjustments
Change-Id: I5238888a5c8352db83fc12749f4de2bfabf46026
If an activity is launched with fixed rotation transform,
its window layout and configuration will be rotated. But
if it gets real information from the display, the values
(getRotation, getRealSize, getRealMetric, getCutout) are
inconsistent with the actual appearance.
This change provides the basic information to adjust the
returned values.
Bug: 147213487
Test: atest DisplayAdjustmentsTests#testFixedRotationAdjustments
Change-Id: I864d5759f41209d5f93c4a9011b720675c25e765
Remove and re add divider view as needed so we do not allocate memory
while split screen is not active. Also release surface reference from
server when we are done with the SurfaceControl so we don't have to rely
on GC to remove the last reference.
Fixes: 150190730
Test: test split screen manually, check for offscreen or onscreen
divider layers in winscope
Change-Id: I1a6a1c1d4346aafeae85aaf61ec4df23722e75ab
