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
