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
We are mostly confident that this @UnsupportedAppUsage was a false
positive.
Bug: 170729553
Fix: 194299196
Test: presubmit
Change-Id: I0967db5742dcfa1ef55046cac283a683f1a56a94
As already mentioned in Bug 115609023 and confirmed in Bug 194297014,
we are mostly confident that this @UnsupportedAppUsage was a false
positive.
Bug: 115609023
Fix: 194297014
Test: presubmit
Change-Id: Ie70099c2f5f926ce64324998a61eb54649e553f9
* Mainline APEXes can only be updated by a modulesInstaller (an entry
in whitelisted-staged-installer.xml with isModulesInstaller="true")
* The whitelisted-staged-installer.xml file can have only one entry with
isModulesInstaller="true"
* Vendor APEXes can only be updated by an installer defined in the
corresponding entry in vendor-apex-allowlist.xml.
BYPASS_INCLUSIVE_LANGUAGE_REASON=existing occurrences
Test: atest StagedInstallInternalTest
Test: atest GtsStagedInstallHostTestCases
Test: atest CtsRollbackManagerHostTestCases
Test: atest CtsStagedInstallHostTestCases
Bug: 190802380
Change-Id: I729abb5153df079fb6885016a4b41d0acc827e3c
Uses LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS to let the pointer location
window could be allowed to extend into the cutout areas so we could
draw the trace points on whole screen.
This CL would also apply the waterfall insets in pointer location view,
so we could layout the label properly when apply such cutout.
Bug: 193206093
Test: atest DisplayPolicyLayoutTests
Test: atest DisplayPolicyInsetTests
Change-Id: I62f0de44820d154383f92632fdd1c86fceaae10c
This is a follow up CL to my previous CL [1], which introduced
ResultCallbacks in a bit conservative way, that is, to always wrap
Completable.* with WeakReference in case the target app fails to
respond for some reasons.
Using WeakReference would make sense if otherwise we would put more
stress on the memory than holding WeakReference object itself. In our
case the expected memory stress on extending lifetime of Completable.*
objects is still comparable with the memory cost of holding
WeakReference objects instead. Let's remove WeakReference from
ResultCallbacks in favor of simplicity.
This change should be completely transparent to other layers since
there is no change in the semantics (except for the lifetime itself of
Completable.* object, which is technically observable with APIs such
as java.lang.ref.Cleaner).
[1]: Ic65a95eb5d0fd56f505a02fd9083bcf6694b6734
f87f750888
Bug: 192412909
Test: atest -c CtsInputMethodTestCases
Change-Id: I43966494ccb4fceb8e7f8c60bd6ce3cc7fbfdd82
If begin and end invocations are at the same frame, the end vsync id
will be smaller than the begin vsync id, results in zero size jank info
array, the finish call will be missed as well, a leak happens.
Bug: 192140966
Test: atest FrameTrackerTest InteractionJankMonitorTest
Change-Id: I388558e60bdb84ad248a9afabe7776c4e6e67c57
This is a small code clean up in IInputContext, which should have no
observable behavior change for app/IME developers.
In the following two methods we have used IIntResultCallback to return
a boolean value in a synchronous manner by using 0 to represent false
and 1 to represent true.
* IInputContext#requestCursorUpdates
* IInputContext#commitContent
Now that we have IBooleanResultCallback, we can just use true and
false without any conversion.
Bug: 192412909
Test: presubmit
Change-Id: Id6beaf3c9350b70138eb77f406be86fe2c8b679f
This is a follow up CL to my previous CL [1] in Android L, which
renamed
InputConnection#requestUpdateCursorAnchorInfo()
to
InputConnection#requestCursorUpdates()
per API council feedback before that API was finally published.
Although its API surface has been correctly renamed, there have been
several uses of its older name in our internal code. This CL also
updates such internal uses to avoid confusions.
As this is a purely mechanical renaming, there should be no behavior
change in this CL.
[1]: I772c48ff18918e48a81e807b48ff907614485c09
d8636ea7ca
Bug: 192412909
Test: atest
Change-Id: I75701a5a32d52283497208013c28ceb75c1adfa9
This is a follow up CL to my previous CL [1], which logically reverted
IInputMethodManager from emulated sync IPCs to truly sync IPCs.
There are several methods and classes that are no longer actively used
after that revert CL. This CL also removes those unused stuff until
we we actually start using them again.
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
Bug: 192412909
Test: presubmit
Change-Id: I8666ac1399058b980e51e2459122b2f5f36c77b5
