This is a follow up CL to my previous CL [1], which added
InputConnectionCommand class with parcelling support.
A Parcel object may contain multiple primitive and Parcelable values.
Neither shallowing exceptions nor early-returning null solves the
fundomental problem that any subsequent read from the same Parcel
object is at risk.
Just let the higher layer decide how to deal with it.
[1]: I86eba7185b4b0664c1b0b3da794dfc5eeddc725c
2757c24880
Bug: 194151409
Fix: 194567417
Test: atest CtsInputMethodTestCases:InputConnectionEndToEndTest
Test: atest FrameworksCoreTests:InputConnectionCommandTest
Change-Id: Icd2b40e63771085cb8d88721fbdca7a089256b28
InsetsState contains much more information than visibilities, such as
display frame, display cutout, rounded corners, privacy indicator
bounds, and frames of of insets sources. The control target only needs
to send the requested visibilities to WMS, so it can be too heavy to use
InsetsState.
This CL introduces an new class, InsetsVisibilities, which only contains
which type has which visibility. So it uses less memory, and it is more
efficient on copying and checking the equality.
Fix: 194186241
Test: atest InsetsVisibilitiesTest WindowAddRemovePerfTest
InsetsControllerTest RegisterStatusBarResultTest
CommandQueueTest LightsOutNotifControllerTest
ActivityRecordTests DisplayContentTests
DisplayPolicyLayoutTests InsetsPolicyTest
InsetsSourceProviderTest InsetsStateControllerTest
WindowFrameTests WindowManagerServiceTests WindowStateTests
Change-Id: I86c1b26b4383bfa3b924726d580e5706e13ba735
This is a mechanical refactoring CL that does nothing but remaning
IIInputContentUriTokenResultCallback
to
IInputContentUriTokenResultCallback.
There should be no observable behavior change in this CL.
Bug: 173340613
Bug: 194308519
Test: presubmit
Change-Id: Id37fd7c44145934aea42d7944e5b212c6ff543f6
This is hopefully the last follow up CL to my previous CL [1], which
aimed to logically revert IInputMethodManager from emulated sync IPCs
to truly sync IPCs.
It turns out that my previous clean-up CL [2] forgot to take care of
the following class
com.android.internal.inputmethod.Completable,
where several unused methods and classes still existed.
Since those methods and classes are not used right now, there should
be no user/developer visible behavior change in this CL.
[1]: If16ac0de536d9089eb04f6e07b1ee47378124658
662b48b72d
[2]: I8666ac1399058b980e51e2459122b2f5f36c77b5
b1fb07a83b
Bug: 192412909
Test: presubmit
Change-Id: Id5d5a4abeff8291b40baf95d425f4035d3cddffe
* changes:
Add the log for new supported accessibility button type 'Accessibility Gesture'
Update the supported type in ACCESSIBILITY_BUTTON_MODE according to navigation gestural mode or button mode
Add a supported type 'gesture' under ACCESSIBILITY_BUTTON_MODE
This CL introduces a new parcelable class InputConnectionCommand so
that any of existing and future InputConnection APIs can be marshalled
into a standard Java object, which itself can be a subject of other
useful operations.
Historically each InputConnection API has had a corresponding IPC
definition in IInputContext binder interface, which is indeed a widely
used design pattern in the Android OS [1]. Instead of continuing
doing so, this CL reimplements everything by a single unified IPC
method with a single unified Parcelable data object existing and
future InputConnection APIs. Although doing so would introduce some
complexity, it also gives us huge flexibility and opportunities to
abstract out common data structure and operations across all the
InputConnection API calls.
For instance, here are code snippets we can now simply write.
ArrayList<InputConnectionCommand> pendingTasks;
void dumpToProto(@NonNull InputConnectionCommand command) {
...
}
void cancelPendingTasks(Predicate<InputConnectionCommand> cond) {
...
}
to do more complex abstractions as needed.
Other than rewriting InputConnection remote execution in a different
manner, this CL changes nothing. There should be no developer/user
visible behavior changed in this CL, which can also be verified with
CtsInputMethodTestCases:InputConnectionEndToEndTest.
[1]: This is not a hard requiement though. In fact there is already
android.os.Messenger that has been used in several places in the
system. What android.os.Messenger does is semantically the same
as what IInputConnectionWrapper is going to do with this CL.
Fix: 194151409
Test: atest CtsInputMethodTestCases:InputConnectionEndToEndTest
Test: atest FrameworksCoreTests:InputMethodDebugTest
Change-Id: I86eba7185b4b0664c1b0b3da794dfc5eeddc725c
Since the current max can change for brightness due to
high-brightnes-mode (HBM), make it so that 255 is always mapped
to the current max, which can be different when in HBM or normal
brightness mode.
Bug: 187784093
Test: atest HighBrightnessModeControllerTest
Test: manually verify 255 is used for max when in HBM or not.
Change-Id: Ib0631fc12de0e8e4c7c638901d82c362e79944c3
