Tell IMS about missing InputConnection methods.
Summary:
This CL introduces a unified mechanism to deal with the situation
where the application directly implements InputConnection but some of
methods are not implemented. Note that there should be zero overhead
when the application extends BaseInputConnection or
InputConnectionWrapper.
Background:
When ever we add a new method to InputConnection, there has been a
risk that existing applications that directly implement
InputConnection can get java.lang.AbstractMethodError exception at
runtime, because older SDKs do not require the application developer
to implement the methods that are newly added in later SDKs. Because
of this we strongly discouraged developers to directly implement
InputConnection interface, and encouraged them to subclass
BaseInputConnection or InputConnectionWrapper instead. That said, as
requested in Bug 26945674, there is a certain demand to be able to
implement InputConnection without depending on BaseInputConnection.
The goal of this CL is to provide a reliable and sustainable solution
to above missing method scenario in InputConnection.
One of the reasons why dealing with missing InputConnection methods is
so difficult is that what InputMethodService receives to communicate
with the target application is actually a proxy class
com.android.internal.view.InputConnectionWrapper
that runs in the IME process and immediately returns true for most of
methods in InputConnection such as #commitText() and
#finishComposingText(). Because of this asynchronous nature, it is
too late to change the actual return value that the IME receives when
the application receives those one-way asynchronous IPC calls.
Solution:
To handle those cases, this CL checks the availability of
InputConnection methods that did not exist in the initial release
before the target application calls startInput(), and let the
application to send its availability bits to IMMS so that
InputConnectionWrapper running in the IME process can be initialized
with such availability bits. Note that we do know that
BaseInputConnection and its subclasses support all the InputConnection
methods, hence for most of applications we can just assume that all
the methods are available without reflection.
With such availability bits, InputConnectionWrapper is now able to
gracefully return failure code to the IME because the availability of
those methods is immutable, except for a tricky case where the
application relies on a proxy object that dynamically changes the
dispatch target.
Here is the list of APIs that we start checking the availability in
this CL.
[API Level 9+]
- InputConnection#getSelectedText(int)
- InputConnection#setComposingRegion(int, int)
[API Level 11+]
- InputConnection#commitCorrection(CorrectionInfo)
[API Level 21+]
- InputConnection#requestCursorUpdates(int)}
[API Level 24+]
- InputConnection#deleteSurroundingTextInCodePoints(int, int)
- InputConnection#getHandler()
Ideas alternatively considered: Default methods in InputConnection
We once considered having default methods in InputConnection but
abandoned this idea because it does not directly solve the problem
about how to tell the that the API does not take effect.
Also having default methods would make it difficult for application
developers to be aware of newly added methods in InputConnection.
Bug: 27407234
Bug: 27642734
Bug: 27650039
Change-Id: I3c58fadd924fad72cb984f0c23d3099fd0295c64
1 file changed