When WindowManagerService.mInTouchMode is changed, we will set the new
mode to InputManagerService, and clients will be notified via
ViewRootImpl.WindowInputEventReceiver#onTouchModeChanged. We don't need
the flag to bring the information to the client.
This is also a step to make relayout an oneway binder call.
Bug: 161810301
Test: Invoke View#requestFocusFromTouch on one window and see if another
window can receive OnTouchModeChangeListener#onTouchModeChanged.
Change-Id: Ic149c95bee89b2be83a85eb4858131224b63a7c8
Handwriting initiator accidentally changes the View's handwriting area.
As a result, it stops working after startHandwriting is called for the
View once. This CL fixed the issue by not exposing the internal
handwriting area Rect object in the View.
Bug: 222117485
Test: manually tested
Change-Id: I5cb6231361fbd7566edddb1aebf7b99330c3a8d8
(cherry picked from commit b1ba2dae29)
We would like to make relayoutWindow a non-blocking call,
and of course why not, who likes blocking. However it functions
as a critical path of BLASTSync. To understand why examine the
Guarantee described in BLASTSync.md.
In order to implement this guarantee we need to know
“Which frame has the client finished drawing” when it calls
finishDrawing. The current answer to this question is
“The frame reflecting the state observed in the last call
to relayoutWindow”. The comments on mPending and mCurrentDrawHandlers
also have a lot more context on how this works currently. Since
relayoutWindow has a critical section, it also ensures that changes
to syncable state and preparation of sync will be observed atomically
(since they are both observed over relayoutWindow, which is always
called before any frame drawing updated syncable state).
We design a new protocol described in BLASTSync.md, which uses a seqId
to track which call to finishDrawing reflects which syncable state.
We implement this seqId based system. Unfortunately the WindowManager
doesn’t quite conform to the requirements specified by the protocol,
and a follow up CL ensures that syncable state changes will
always be sent with the seqId.
This CL simply adds the protocol specification and makes some required
interface changes. It can be seen to be a no-op.
Bug: 161810301
Bug: 175861051
Bug: 175861127
Bug: 200285149
Change-Id: If2dea07121fe7de5d2524c5b63678dddf955d4b7
This is a step to move the window layout to the client side.
ClientWindowFrames is used to carry window frames dispatched from the
server to the client for now. Later, the window frames will be computed
at the client side, and the frames will be sent to the server side via
ClientWindowFrames.
Bug: 161810301
Test: presubmit (no behavior change but only code refactors)
Change-Id: I83d8cfff2432e09759ef5b3d5f3b21731fc71bff
When rotation, it will re-init the split divider for new rotation on
DAinfoChanged callback, but when shell transition, we should do it on
startAnimation to make transition smooth and make didider could release
by specfic Transcation to avoid it hide immediately but didn't sync with
transition.
Fix: 222158856
Test: manual
Test: pass existing tests
Change-Id: I797ffd0ea35d89b4ec1e3ef4828ce36e18c860be
A new interface in WindowManagerProxy was introduced to let the shell be
able to set insets with a given frame. The interface won't work for
caption as we applied special logic to assemble the caption frame with
the attached task frame. To make it work with caption insets, we need to
disable all the special logics to make use of the shell interface.
A flag CAPTION_ON_SHELL is introduced to disable the calling path and
enable the above client owned logic. Turn the flag to true when the
caption is moved to shell.
Test: InsetsControllerTest, WindowContainerInsetsSourceProviderTest
Bug: 189998209
Change-Id: I989b319001a118d1f1ff8e34761b39ee18fde335
This CL fixes a bug that could happen when animating a dialog out at the
same time as hiding the SystemUI shade, and that would make the phone
unusable until the shade is swiped down again. See b/223387276 for more
info.
Bug: 223387276
Test: Manual, see b/223387276#comment1
Change-Id: If251b00558a5ca9a927d1be2bb015f1c0acb2d57
We expected `onKeyDown` and `onKeyUp` should be used for the key event
delivery from input, but some apps may misuse it and pass a null
key event, that would cause app itself crash if it didn't override
onKeyDown and onKeyUp properly.
To prevent this, we swap the conditions that first check the confirm
key code then access the other states of the key event.
Bug: 219708835
Test: manual
Change-Id: I612ca560d768134bdcaa688c83217738b5254b5a
They are now public API, so they should perform the same checks as in
respective calls with ASurfaceTransaction.
Bug: 210837722
Test: atest SurfaceControlTest
Change-Id: I1f17f8402dc116a419189f31faf351ffa967ecda
This CL reworks my previous CL [1], which let
InputMethodManagerService report whether the IME switcher icon needs
to be shown or not to the IME process by using IInputMethod IPCs.
It turns out that we need to propagate one more boolean value in order
to address Bug 219820813. It'd be much clearer if we use bit flags
rather than adding a new boolean parameter to each IPC method. Thus
this CL rewrites my previous CL by using a bit flag defined in a newly
introduced InputMethodNavButtonFlags.
This is a purely mechanical refactroing. There should be no behavior
change.
[1]: I5de9ac0dc8670842edf66306bb4c281c77cea376
75b935a12b
Bug: 215551357
Bug: 219820813
Test: Manually verified with for the following scenarios:
* Enabling/disabling multiple IMEs
* Attaching/detaching a hardware keyboard
* Showing/hinding the IME switcher
* Showing an IME on the lock screen
Change-Id: I81cb062a08d484ec8ce5d7b2fea64ce19028f82e
This reverts commit 3ccd2488c5.
Reason for revert: Blocking issues have been addressed,
ready to reland. See bug.
Bug: 213425347
Change-Id: I91a29949f87a0d27188b323bf302400ee19e964d
Fix: 217730256
Bug: 222537368
Test: Added test in EditTextTest (will merge later when reviewed).
Merged-In: I78354a0f1d955c5b7c1ead044ea49086b3479841
Change-Id: I78354a0f1d955c5b7c1ead044ea49086b3479841
(cherry picked from commit e1f392d171)
This reverts commit 0de71ca543.
Reason for revert: Don't yet have a use for the definitions,
and will likely reimplement them differently. This is an adjusted
revert to account for a resource finalization error
Test: Is a reversion.
Bug: 222537368
Merged-In: I99a71551069069d117039af4708030772b741cea
Change-Id: I99a71551069069d117039af4708030772b741cea
(cherry picked from commit 65e5bf07c2)
These warnings triggered on ag/16873530. The warnings are like:
[AndroidFrameworkRequiresPermission] Method addKeyguardLockedStateListener() annotated {allOf=[android.permission.SUBSCRIBE_TO_KEYGUARD_LOCKED_STATE]} but too wide; only invokes methods requiring [none]
public void addKeyguardLockedStateListener(@NonNull @CallbackExecutor Executor executor,
^
If calling an AIDL interface, it can be annotated by adding:
@JavaPassthrough(annotation="@android.annotation.RequiresPermission(...)")
Bug: 216630470
Test: n/a
Change-Id: I479063de6b591da44c474e4aa93e0466104d2a9a
This allows tests to check the behavior of automatically reporting the
focused View as a keep clear area.
Test: atest KeepClearRectsTests
Bug: 218494300
Change-Id: I602406572a540c4b5f77164efab28376faec2701
Use the android.os.InputConfig flags to control input window behavior in
InputWindowHandle. This consolidates the old boolean flags and
inputFeatures flags into one set of flags so that the InputConfigs are
the sole set of flags that change change how an input window behaves.
After this change, InputFeatures and LayoutParamsFlags are specific to
WM, which is responsible for converting them into InputConfig flags.
Trivial conversions between these flags are done in InputConfigAdapter.
The LayoutParams type and flags are still part of the this API to send
these attributes to native code. However, they are no longer used by
input.
Bug: 216806304
Test: manual: verify touch functionality
Test: atest WindowStateTests
Change-Id: I5b384770272c111680783ee8ab01ecd6e03f42be
The feature is punting to QPR1, disable feature by flag first. The
feature will strip from the build in the follow up change.
Bug: 190030331
Test: manual. Clear flag and make sure the feature is disable.
Change-Id: Id5e0efeff0465890a5d26ef10b6e54359f569317
InputFeatureFlags are now a WM-only flag, but is temporarily used by
InputWindowHandle until the cleanup is completed.
Bug: 216806304
Test: atest libgui_test
Test: atest inputflinger_tests
Change-Id: I1260431e99d2c50261dc8b0356dc3e21ba76d39f
Re landing with the following changes:
We initially cloned the SurfaceControl handle to avoid locking when
accessing the SurfaceControl from the position listener callbacks
running from RT workers. But this meant the last reference to the
layer handle would only be released by GC. If SurfaceViews are
created and destroyed rapidly, we would be at the mercy of GC to
release buffers.
Original change:
There are three transaction queues that can submit SurfaceView
changes.
1. Buffer updates via BBQ apply token
2. SCC apply token
3. ViewRootImpl BBQ apply token
It makes sense for most SurfaceView changes to be synchronized with
ViewRootImpl draws since the caller can optionally synchronize the
change with main window content.
This change eliminates the tmp transaction that is applied directly
via the SCC apply token and instead applies them with the ViewRootImpl
draw transaction.
Also take the opportunity to scope down mSurfaceControlLock usage.
Test: atest SurfaceViewSyncTest
Test: go/wm-smoke
Test: run mem tests via forrest
Bug: b/217973491, b/221631942
Change-Id: Idba712d146e62d7346920dc4f060cba92d47fada
