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
So Settings DevelopmentTiles doesn't need to create direct
IInputMethodManager dependency to access system API.
Bug: 175742251
Test: Manually test ime winscope works properly
Test: make RunSettingsRoboTests ROBOTEST_FILTER="WinscopeTraceTest"
Change-Id: Ie37790c7479f6b9064afd7fbcee7fd6f712d1a75
This is a mechanical refactoring CL that has no behavior change.
This CL removes the direct dependency on AbstractInputMethodService
from whenever possible. As a result, the following classes no longer
directly depend on AbstractInputMethodService.
* android.inputmethodservice.IInputMethodWrapper
* android.inputmethodservice.RemoteInputConnection
* com.android.internal.inputmethod.ImeTracing
* com.android.internal.inputmethod.ImeTracingClientImpl
* com.android.internal.inputmethod.ImeTracingServerImpl
This is still a purely mechanical refactoring. There should be no
observable behavior change.
Bug: 192412909
Test: atest CtsInputMethodTestCases
Test: Manually verified that IME tracing still works
Change-Id: I2aeeeacd27195ce10059d6590e098a4a969e774d
This is partially a followup of
I80dabaf6ae0e781028dde16ead3321fbff319542 which removed these operations
from the SoundTrigger layer when the HotwordDetectionService is used.
Also fixes a race condition where the DSP event can go directly to the
Interactor if the DetectionService isn't connected.
Bug: 186164881
Test: atest HotwordDetectionServiceBasicTest
Test: manual - DSP and non-DSP
Change-Id: Iee3b00c6c08597ad1993fae677e9f8ae2f60744c
This is a mechanical refactoring CL that has no behavior change.
Currently all the utility methods defined in
InputConnectionProtoDumper return ProtoOutputStream, while the
returned instances will always be converted into byte[] eventually.
With this CL, those utility methods return byte[] instances directly,
which is expected to make it easier for ART/dexpreopt to do more
optimizations such as code inlining because instances of
ProtoOutputStream will no longer be escaped from those methods.
Bug: 192412909
Test: atest CtsInputMethodTestCases
Test: Manually verified that IME tracing still works
Change-Id: I7b24aee5428da312972aa86b8658429b421490f8
This CL renames classes related to IME tracing as follows
* android.util.imetracing.ImeTracing
=> com.android.internal.inputmethod.ImeTracing
* android.util.imetracing.ImeTracingClientImpl
=> com.android.internal.inputmethod.ImeTracingClientImpl
* android.util.imetracing.InputConnectionHelper
=> com.android.internal.inputmethod.InputConnectionProtoDumper
Other than those renamings, there should be no observable chagnes.
Fix: 175761228
Test: presubmit
Test: Manually verified that IME tracing still works
Change-Id: I6518d946e1832037f240f57aa900d3447083f1fa
EditableInputConnection has been one of the most important and widely
used InputConnection implementations. While having it under
com.android.internal.widget
would still make some sense, it'd become more easier for the IMF team
to keep improveing it if EditableInputConnection is moved into
com.android.internal.inputmethod
Anyway, EditableInputConnection has never been a public API hence just
moving its package should have no impact on app compatibility.
Bug: 192412909
Test: atest CtsInputMethodTestCases CtsWidgetTestCases:TextViewTest
Change-Id: I87974f779dbda60dfb79331cbe1ec975c475c695
