The goal of this CL is to remove RELAYOUT_RES_DRAG_RESIZING_DOCKED and
RELAYOUT_RES_DRAG_RESIZING_FREEFORM, which is a step to make relayout an
oneway binder call.
When the resize mode is changed at the server side, the server will send
the new mode to the client via IWindow#resized, so the client doesn't
need to obtain the resize mode from the flags returned from relayout.
Bug: 161810301
Test: Perform drag-resize and drag-move on a freeform task and see if
there is any unexpected behavior.
Change-Id: I450abc113932b6c1dc0ce0e2b76bebdf85a60777
This will be used by clients such as Gboard to ensure they are
responding to translation events for the correct activity. Ideally we
would include the activity token, in case there are multiple activities
being translated in an app, but that isn't supported right now and it
requires changes to EditorInfo (in Input Method Framework) to get the
activity token.
Also fixed an issue where the callback methods are invoked twice when
the IME itself is the translated app is registering a callback for
itself. Note: This happens in UiTranslationManagerTest where the test
activity and IME have the same uid, but shouldn't happen outside of
tests.
Bug: 223979041
Test: atest CtsTranslationTestCases
Change-Id: Id99f501b065b92fe3358c2ae525175ad3ea4b119
If the fill dialog is available for the field, the FillRequest flags
will contain FLAG_ACIVITY_START. The field is hidden originally but
it needs to be get from AutofillService to avoid creating unnessary
fill dialog presentation. Rename the flag because the it's not clear
to combine the relationship with fill dialog.
Bug: 223472039
Test: manual. Build and boot pass.
Change-Id: I52c367e75100f6af2ab782f58755bc5727b1dd72
Move the callback as the last paramter to registerOnBackInvokedCallback
Test: Existing
Bug: 224562951
Change-Id: I8608a03b53baa04bedee81d2e86b2339abd6c594
We introduce a seqId and use it to replace the
RELAYOUT_RES_BLAST_SYNC flag. The server code block that
produces RELAYOUT_RES_BLAST_SYNC is guarded by
mNextRelayoutUseSync, and sets it to false when executed.
This block is the only place that sets it to false. We replace
every place where it is set to true, with incrementing a seqId
stored on the integer. We change this block to not check
mNextRelayoutUseSync but instead check if the seqId has changed
since we reached the block. This is evidentally equivalent conditions
and in these cases we send the client the seqId. In the else block
where we wouldn't have sent RELAYOUT_RES_BLAST_SYNC we send -1.
On the client side, we replace the USE_BLAST_SYNC conditional
with a check if the SeqId we received has increased. It's clear
that this will never execute in cases where the seqId is -1. Likewise
its clear that if the seqId has increased, it will execute. Since the
seqId increases in all cases where the server would have returned
RELAYOUT_RES_BLAST_SYNC this change is a noop by itself.
Bug: 161810301
Bug: 175861051
Bug: 175861127
Bug: 200285149
Change-Id: Ib2e45cae7709519251e4bfcc2b8adc689c590a00
Instead of using the count to keep track of sync information in VRI, use
the SurfaceSyncer to handle this. This also means changing SV since SV
would also increment the VRI counter. This cleans up the logic since
code that's used for the SurfaceSyncer can be re-used in VRI.
Test: seamless rotation, launching apps
Bug: 200284684
Change-Id: Ia3c1a13b42ceba29a75425295e41e543a00436a3
We've received several feedbacks that the current tapTimeout is too short,
making it very hard to initiate handwriting. To unblock us from bug bash,
this CL temporarily use long lick timeout for handwriting timeout.
Once UX decided the final value for handwriting timeout, we will create
another CL.
Bug: 217603538
Test: atest FrameworksCoreTests:android.view.stylus.HandwritingInitiatorTest
Change-Id: Icb9f49b8b2a49c6c2a13fa377c20a3d1b3bd782c
The custom close action will replace the system close action and
the button in the menu will be colored red to be able to tell it
apart.
If one of the custom actions matches the close actions it will be
removed to avoid duplicates resulting from the custom close action.
If the app doesn't close the PiP after five seconds the system will
continue to close the PiP as normal.
Bug: 218487423
Test: manual
Change-Id: Ic3c520c50ac0e3d2f0e73cf2f71d47a4f548f861
Finish stylus handwriting session when user swipes to recent.
Bug: 223748964
Test: Manually:
1. Open an app with editor
2. swipe on editor with stylus [or emulated stylus]
3. Observe ink trail drawn on screen
4. quickly sipe to recents, ink should go away.
5. repeat steps 1-3 for swipe to home
Change-Id: Id750ff55cb447247c3eca75daf37cb5aeb1d0cfa
Introduces layer mirorring of a single task, given the task is both
identified (future work - dependency on setup flow in SysUI) and the
flag is enabled (currently disabled).
Error handling (tearing down the VirtualDisplay if task recording setup failed)
will come in a future change
Bug: 216625226
Test: atest WmTests:DisplayContentTests
Test: atest WmTests:ContentRecorderTests
Change-Id: I16abd55ce75537ff8fbbb379e4970668ea02a230
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
