| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow up CL to our previuos CL [1], which enabled
AccessibilityService to use a subset of InputConnection APIs.
In that CL we have reused existing AIDL interfaces that were designed
and maintained for IMEs for simplicity, where a non trivial amount of
unnecessary IPC endpoints were included.
From the security and maintainability viewpoints, however, exposing
unnecessary IPC endpoints is discouraged in general. To address such
concerns this CL introduces a set of dedicated IPC definitions for
A11yIME so that we do not need to reuse IPCs for IMEs.
This CL also stops passing InputBinding object to A11yIME process as
it contains IInputContext Binder Proxy, which can still be used to
directly invoke fallback InputConnection. This is doable now because
A11yIME no longer relies on fallback InputConnection [2].
This CL is should not have any observable changes in the semantics.
End-to-end CTS tests guarantee that everything is still working as
intended now and in the future.
[1]: Ia651a811093a939d00c081be1961e24ed3ad0356
fb17e5ae7a9e1a095d114d8dde76f14578b6c233
[2]: I2af3cd50444d8ddf25aa0f6479238156914e6fff
dc635efb687ac04045f2756b02c5ca2435762956
Fix: 215633021
Fix: 215636776
Test: atest CtsInputMethodTestCases:AccessibilityInputMethodTest
Test: atest CtsAccessibilityServiceTestCases:AccessibilityInputConnectionTest
Test: atest CtsAccessibilityServiceTestCases:AccessibilityImeTest
Change-Id: I5ff2e804cbcf90828370a0612ff54111130bdff4
|
| |
|
|
|
|
|
|
|
|
|
|
| |
1. Use intDef for CurosrUpdateFilter
2. overload requestCursorUpdates(mode, filter)
3. additional details in javadoc
Fix: 218314883
Bug: 210039666
Test: atest CtsInputMethodTestCases
Change-Id: I1dc5acac4f968b2a2d1780f2ee6c0145c7dcbbaa
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
InputMethodService is the primary and a11y is the secondary.
InputMethodService is not
affected by a11y status. When the session from input method is
established, app can start input (pass input context to input method).
When an a11y session comes back, it will be passed to the app. When
InputMethodManagerService binds to/start input with
InputMethodService, it does the same to a11y services which
requested IME functionalities.
It is possible that input method can edit text before ally sessios are
established. So the EditorInfo passed to a11y could be stale.
So when an a11y session is passed to client, client will send
a notification (input method doesn't have this extra notification) for
the current selection. I think since the time for a11y session establish
shouldn't be long, and we get the current state later, it should be fine
for a11y services.
When input method is disconnected from app (client) (even for input
method switching), we cleared a11y and sessions too. When
input method request sessions, we must rerequest sessions for a11y. This
is mainly because when we unbindCurrentClientLocked(SWITCH_IME), we set
active to false for the current client. Suppose we don't want to
change the current structure of input method, an inactive client
probably should clear accessibility sessions too.
When we switch to a client which already has a session with input
method, there might be some a11y sessions with this client, and
some a11y services might be disabled or enabled while the client was
switched out. We pass unchanged a11y
sessions to client, and request sessions for newly enabled a11y services.
When an a11y service is disabled, it removes its session
from all clients in InputMethodManagerService.
Test: type word through modified "switchToInputMethod". Tested session
notification through logs. Tested client switching, input method
switching, a11y service enabled/disable, multiple a11y services,
a11y service enabled before device reboot.
Also tested work profile.
Bug: 187453053
Change-Id: Ia651a811093a939d00c081be1961e24ed3ad0356
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Historically TextView#setText() has internally called
InputMethodManager#restartInput(View)
simply because the text seen from the IME is going to be out-of-sync.
Although this behavior is semantically helpful for IMEs, especially
after the initial surrounding text information became available in
EditorInfo, issuing a sync IPC from the calling thread (UI thread
actually) is not plausible from the performance perspective.
This CL fills this gap by adding a new API
InputMethodManager#invalidateInput(View)
for the scenario where apps independently modify the text with keeping
other text metadata such as input-type to be the same.
All the observable behaviors from the IME remain to be the same as
InputMethodManager#restartInput(View).
For instance, any pending tasks that are already issued with
InputMethodService#getCurrentInputConnection()
will be effectively cancelled by using a recently added mechanism [1].
[1]: I383c3958d2ac1a8d217706509fa12a92b381bbb3
Fix: 203086369
Test: atest -c CtsInputMethodTestCases:InputMethodStartInputLifecycleTest
Change-Id: I3161755779080f98bcef0e47dd0c5247d8a3a256
|
| |
|
|
|
|
|
|
|
|
| |
Add the TextAttribute class and variant of setComposingText(),
setComposingRegion(), commitText() to support IME to take extra
information to editor.
Bug: 198732184
Test: atest CtsInputMethodTestCases:InputConnectionEndToEndTest CtsInputMethodTestCases:TextAttributeTest
Change-Id: Ic9c917b70726ca32c2097b0374951c20af9624c4
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow up CL to our previous CL [1], which introduced
early-exit paths to some RemoteInputConnection methods to protect
innocent IME clients from unexpected process crashes when an IME is
calling InputConnection APIs with invalid parameters.
Although protecting IME clients from crashes still makes much sense,
implementing it as an early-exit style in RemoteInputConnection may
expose observable inconsistency to IME developers in terms of the fact
that InputConnection#getText{Before,After}Cursor() can also work as a
fence operation that would not return until all the previously issued
InputConnection API invocations are handled in the IME client side.
With this CL, the following methods start behaving as a fence
operation even when an invalid parameter is passed, by checking the
parameters in the IME client side.
* RemoteInputConnection#getTextAfterCursor()
* RemoteInputConnection#getTextBeforeCursor()
* RemoteInputConnection#getSurroundingText()
There should be no performance impact for IMEs that do not make such
an invalid (and unnecessary) API calls.
[1]: I95169735198f8363c981a61e20234dfebfd645b1
1e72ef28933823594bf2b1993fed2d4895b20a67
Bug: 169114026
Fix: 194110780
Test: atest CtsInputMethodTestCases:InputConnectionEndToEndTest
Change-Id: Ie0c18d0c9b8bf8f02f2fcdca5aac7e580c6bf2cd
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL effectively replaces my previous CL [1], which made
unimplemented methods in InputConnection not fatal errors, with a
simplified implementation that still gracefully take care of
unimplemented methods without causing app crashes.
Instead of propagating missing method information from the IME client
to the IME process, this CL will simply catch AbstractMethodError in
the IME client process. Doing so enables us to
1. preserve the strict invocation order of InputConnection APIs, and
2. achieve the same goal with fewer lines of code.
The additional cost of throwing (and catching) AbstractMethodError
every time the IME calls an unimplemented InputConnection API can be
justified as it is really an exceptional scenario, and avoiding it
would require extra maintenance cost as seen in
InputConnectionInspector.
The above overhead (and complexity) due to AbstractMethodError can be
avoided by adding default implementations to those InputConnection
APIs, but doing so requires API signature update hence API council
approval to go ahead, which is to be discussed in Bug 199934664.
[1]: I3c58fadd924fad72cb984f0c23d3099fd0295c64
19a80a1e807acd00bec999eaac7812da6ffce954
Bug: 27407234
Bug: 27642734
Bug: 27650039
Bug: 194110780
Test: atest CtsInputMethodTestCases
Change-Id: I9e801e92496a6e16cee37664870c97ed096f1413
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow up CL to my previous CL [1], which used
MissingMethodFlags mechanism [2] to let that API fail when the IME and
the target app are not running on the same display.
As discussed in Bug 194110780, however, there is a problem in the
MissingMethodFlags mechanism that it could have caused unexpected task
reordarings from the IME developer when sync InputConnection APIs
immediatelly fail without waiting for those tasks to be scheduled to
the target app then handled.
As a preparation to fully deprecate MissingMethodFlags, this CL
enables InputMethodManagerService to stop lying about
MissingMethodFlags.REQUEST_CURSOR_UPDATES
when the IME is rendered on a diffirent display than the target app.
Such check is now explicitly implemented in
RemoteInputConnectionImpl.
Other than that, there is no observable behavior change.
[1]: Ie2f7a5117cff3a13ad5c5806fd4b3abef7569549
3d2cc0fffd13f46923d0fcfdd73d375ebbe955ce
[2]: I3c58fadd924fad72cb984f0c23d3099fd0295c64
19a80a1e807acd00bec999eaac7812da6ffce954
Bug: 131368625
Bug: 194110780
Test: atest CtsInputMethodTestCases
Test: atest MultiDisplaySystemDecorationTests#testCrossDisplayBasicImeOperations
Change-Id: Iec12733d37e112b7271436bba15094ae2a55a450
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL consolidates weak-ref handlings in RemoteInputConnection so
that IME developers can find more useful messages in logcat when they
are using RemoteInputConnection after InputMethodService#onDestroy().
RemoteInputConnection has been designed to not hold a strong reference
to its parent InputMethodService instance.
While IME developers can manually keep a strong reference to
(Remote)InputConnection object that they obtained from
InputMethodService#getCurrentInputConnection(), doing so does not
prevent the system from garbage-collecting InputMethodService
instance.
With this CL, an error message will be shown in logcat if somehow
RemoteInputConnection object is still touched after InputMethodService
is destroyed, which hopefully can help IME developers realize they
might be doing something unexpected.
Other than showing error messages in logcat, there is no behavior
change in this CL.
Bug: 192412909
Bug: 194110780
Test: atest CtsInputMethodTestCases
Change-Id: I514630d27c8953f62fdb34cd3133a662b3fbbf76
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL converts our inhouse Completable class with CompletableFuture.
One of downsides of switching into CompletableFuture is performance.
It creates much more objects, especially in unsuccessful cases
including timeout scenarios:
* CompletableFuture#cancel() always creates a CancellationException
object with full stack trace. This is going to be problematic when
we start cancelling pending InputConnection tasks in Bug 195115071
from the IME client side.
* Timeout cases always creates a TimeoutException object with a full
stack trace.
* Exception cases always creates a ExecutionException object with
full stack trace.
Also, none of its getter methods directly fits our existing use cases
in the input method framework world. We must always use
CompletableFutureUtil to retrieve the result value so as not to
accidentally break existing APIs.
Other than above, there should be no observable semantic behavior
changes in this CL.
Bug: 192412909
Bug: 195699814
Test: presubmit
Test: atest -c FrameworksCoreTests:CompletableFutureUtilTest
Change-Id: I215bbc870f952effa262fa431064b36ace28e8f4
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a mechanical refactoring CL that renames
com.android.internal.view.IInputConnectionWrapper
to
com.android.internal.inputmethod.RemoteInputConnectionImpl
with no observable behavior change.
Bug: 192412909
Test: presubmit
Test: No lint error under core/java/com/android/internal/inputmethod
Change-Id: I171106ad0b46fbb495a6bf08d10f33915c2d29ac
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |\|
| |
| |
| | |
requestCursorUpdates()"
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
d8636ea7ca78df83d6b04088eab7853f15f3e999
Bug: 192412909
Test: atest
Change-Id: I75701a5a32d52283497208013c28ceb75c1adfa9
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow up CL to my previous CL [1], which aimed to put an
early-exit check for
InputConnection#commitCorrection(CorrectionInfo)
but mistakenly put it in
InputConnection#commitCompletion(CompletionInfo).
With this CL the early-exit check will be placed at the right place.
[1]: I3c58fadd924fad72cb984f0c23d3099fd0295c64
19a80a1e807acd00bec999eaac7812da6ffce954
Fix: 193907158
Test: atest CtsInputMethodTestCases:InputConnectionEndToEndTest
Change-Id: I497628165072c73d0e279f89afe0d8730531ecfc
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 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
|
|
|
This is a purely mechanical refactoring with no behavior change.
An existing non-API class
com.android.internal.view.InputConnectionWrapper
has been used only from another non-API class
android.inputmethodservice.IInputMethodWrapper.
By moving it to android.inputmethodservice package we can make it a
package-private class, which is what this CL is intended
to achieve.
Furthermore, there is another public API class with the same name:
android.view.inputmethod.InputConnectionWrapper
, which has been confusing with this internal one. To avoid such a
confusion, this CL also renames this internal one to
RemoteInputConnection.
Other than those mechanical changes, there should be no observable
behavior changes.
Bug: 192412909
Test: atest CtsInputMethodTestCases
Change-Id: Ic0babecd34a6bc80b917050370abc2db5c03d84e
|
