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
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
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
Content recording relies upon a class describing current state.
rather than passing around details from media > display > wm.
WMService keeps track of the session in ContentRecordingController.
ContentRecordingController manages hand-off between different
DisplayContent instances, as the session details are changed.
Manually tested that fold/unfold handling when screen recording
from QS tile still works, and that taking over a screen cast
with a screen recording works.
Refactoring logic from DisplayContent into new recording
delegate will come in a future change.
Bug: 216756854
Test: atest FrameworksCoreTests:ContentRecordingSessionTest
Test: atest WmTests:DisplayContentTests
Test: atest WmTests:ContentRecordingControllerTests
Change-Id: Ib4f125dd703d362ac13fcbe469d00b345827e706
Modified SurfaceView and ViewRootImpl to provide callbacks when syncing
a transaction instead of sending transactions. This will ensure a clear
ownership of the transaction object since it will be provided in the
callback when BBQ adds a buffer into the transaction. Modified JNI to
add compatibility for native functions.
Test: Manual testing from go/wm-smoke.
Test: BLASTBufferQueueTest
Bug: 210714235.
Change-Id: I1f872d6b2846b0d64d5b33b8866d0b2ec7126c8c
Originally, View was implementing onBackInvokedDisptacherOwner, but now
only Activity and Dialog and since back event are related to the
window, it makes sense to move them into the android.window package
This follow up comment at:
ag/c/platform/frameworks/base/+/16764116/comments/e131f3ef_e3e1d2e0
Test: atest BackNavigationTests
Bug: 221401221
Change-Id: Ia2f26162beb6a41b6e162b31e599e882f8bf7320
Mark/unmark Views as keep clear areas as they gain/lose focus
with a small delay.
Test: atest KeepClearRectsTests
Bug: 218494300
Change-Id: I33c89b5d2ed6707f95eca8ec4b5604c9193aec05
Since ViewParents can be set to not clip their children, custom
keep clear areas can extend beyond the bounds of its hosting View.
If preferKeepClear is set, add the View's bounds as a keep clear area,
but also keep the custom Rects.
Bug: 221073574
Test: atest KeepClearRectsTests
Change-Id: I85a4e4a223fbba787c5afebf2689a031243808d4
