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
This reverts commit 0df8812486.
The original CL is trying to reduce the dependency of PownerManager to
finish input when screen off by using display state.
However, it doesn't fully fix the original Bug 26851566 since we only
finish input connection but didn't callback onFinishInput callback for
IME client.
Also, for some scenarios, the window / view focus may not change
during screen turns off / on:
- Focusing timing when disable keyguard, then quickly screen off / on.
- Using P-sensor to turning screen off / on.
When the above scenario happens, makes input connection cannot re-start
and soft-keyboard can't be shown.
(The recovery is manually focus on next window or activity.)
As the above reason, we need to re-consider the lifecycle of
input connection, window / view focus when not only screen state but also
device inactive state when always-on-display.
Fix: 156045961
Fix: 154605805
Bug: 26851566
Bug: 156215187
Test: atest CtsInputMethodTestCases
Change-Id: If06daf71160aa44a4254ac125561974ecbdef4f2
* 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
Pre-R, the screenshot window was used just for screenshot animation. In
R, the window is also hosting tappable screenshot actions, which require
focus.
This change modifies TYPE_SCREENSHOT to no longer force it to be
unfocusable.
Test: Verify that screenshot window UI elements can work with talkback
and accessibility scanner.
Bug: 153517161
Bug: 152583784
Change-Id: If81d9f94dff801c3483a2d834e692b4c77d80d7b
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
If we cannot get flag information from the AutofillManagerService
after the timeout, we should not crash the process, we need to
handle the enabled information properly.
Also fix NPE because of null component name while calling
AutofillManagerServiceImpl.isWhitelistedForAugmentedAutofillLocked().
Bug: 151273845
Test: atest CtsAutoFillServiceTestCases
Test: manual. Copy the text from Messenger and paste on search bar,
no crash occurred and can paste text correctly.
Change-Id: I8d7ca35226052944fd68fef60a013a65a7fb57c1
If a motion event classified CLASSIFICATION_AMBIGUOUS_GESTURE, it would
multiplied the AmbiguousGestureMultiplier from configuration for the
touch slop, we have to make sure this value should be start from 1 or
the touch slop could be zero and click action may fail.
Bug: 155160957
Test: manual
Change-Id: I61e1262b4f3de61214297b678956cc14fa2f24ef
Also, make Bubbles a TYPE_TRUSTED_APPLICATION_OVERLAY!
Test: make a permission dialog appear while bubbles appear (wait for any HUNs to go away)
Fixes: 149320322
Change-Id: Ib4b93635929cf996753a21717383c327256477b3
Otherwise, mRecomputeGlobalAttributes set within the callbacks might be
cleared in the traversal.
This CL also prevents dispatching non-existing insets sources to the
client. For example, if a display doesn't have a navigation bar, the
insets state dispatched by window manager won't contain the navigation
bar source. So that WindowInsets.isVisible(ITYPE_NAVIGATION_BAR) returns
false on such display.
Fix: 155787445
Fix: 155796402
Test: atest WindowInsetsControllerTests InsetsAnimationControlImplTest
Change-Id: I3104191b34c08e14ffb31d7228c832a84629a97b
If the client didn't change any insets, we don't need to update the
requested state while receiving controls. The requested state at the
server side can still be up-to-date for free.
This CL also sends the requested state to window manager if the local
state is not the same as the dispatched state.
Fix: 155752039
Test: atest InsetsControllerTest
Change-Id: I676a88d3ef823d8717d03e80261e6e7a5f7e8c5f
