Historically, InputMethodService (IMS) has relied on
InputMethodManager's hidden methods to communicate with
InputMethodManagerService (IMMS). Because of this, InputMethodManager
(IMM) has ended up being a mixture of IPC endpoint for both IME
clients and IME itself.
There are multiple problems.
* IMM is instantiated in almost all user mode processes. This means
that unnecessary IPC endpoints have been accessible to them via
reflection. Even though those endpoints refuses request without a
valid IME window token, and even though we have tighten up use of
private APIs in the runtime level, exposing unnecessary IPC
endpoints is still questionable.
* Mixing multiple responsibilities has been caused unnecessary
complexity in IMM. In Bug 70282603, we have moved some APIs from
IMM to IMS to sort out this complexity that are surfaced in API
boundary, but in the implementation level everything remained to be
the same.
Now that Bug 70282603 is fixed, the natural next step is to start
implementing actual an IPC connection from IMS to IMMS without relying
on IMM.
Here is the new diagram that describes (most of) IPC interfaces around
IMEs.
APP---(1)---IMMS
\ |
\ |
\ |
\ |
\ |
(2) (3)
\ |
\ |
\ |
\ |
\|
IME
(1): IInputMethodManager.aidl: send requests from APP to IMMS
IInputMethodClient.aidl: send requests from IMMS to APP
(2): IInputMethodSession.aidl: send requests from APP to IME
IInputContext.aidl: send requests from IME to APP
-> this is the actual interface behind InputConnection
(3): IInputMethod.aidl: send requests from IMMS to IME
IInputMethodPrivilegedOperations.aidl:
send requests from IME to IMMS
IInputMethodPrivilegedOperations.aidl is what this CL is adding.
With that, this CL moves 5 IPC methods
from IInputMethodManager.aidl (1)
to IInputMethodPrivilegedOperations.aidl (3).
There remain some IPC methods that are intended to be used only from
IMEs in IInputMethodManager.aidl because those methods have been
unfortunately exposed via public APIs in InputMethodmanager.
Although all of those public APIs were deprecated in Android P as part
of Bug 70282603, we still need to keep maintaining those APIs until
(most of) IMEs migrate to APIs that are newly introduced in
InputMethodService. It would take several years.
IInputMethodManager#getInputMethodWindowVisibleHeight() is another
method that we cannot migrate right now because some apps have already
relied on its corresponding hidden method in IMM, as discussed in Bug
113914148.
Fix: 113177698
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I2f3ec3c5de546fb3603275a4b64000ed3f863b65
This is a mechanical code clean-up. No behavior change is expected.
Bug: 113177698
Test: Run the following command to confirm that there remains no lint
error regarding import lines:
prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/java/com/android/internal/view/IInputConnectionWrapper.java
Change-Id: Ife60e0b4234b5c8bc2d4d192b33dc97b156ea7fc
I don't know whether this comment was valid in the initial
implementation or not, in the current system InputMethod.attachToken()
is not (indirectly) exposed to the IME client process vir Binder
interface. The only Binder interface that is exposed from the IME
process to the IME client process is IInputMethodSession, not
IInputMethod that implements attachToken().
One may think that a malicious app could try to call
Context.bindService() with InputMethod.SERVICE_INTERFACE to directly
obtain IInputMethod, but it should fail because IMEs must be
protecting their InputMethodService with BIND_INPUT_METHOD so that
only the system can bind to them.
This CL clarifies this point in both JavaDoc and its implementation.
If an IME happened to receive multiple attachToken(), it is an OS bug
and worth letting people know by crashing the IME process.
Fix: 114164394
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: Ia1e1d5ce020155b906e42a222f27b76905217395
Add a service that tracks the device state properties which are
interesting to System Server telemetry services. Allows the services to
share this code and have consistent state information.
Test: Unit tests and manually tested
Change-Id: Ia5c78c45a55414a0c5c46202db2a37283b50a703
No need to create an extra field for a boolean flag. Move the recently
added ApplicationInfo.usesNonSdkApi to one bit in privateFlags.
This also solves an issue where the field was not propagated during
copying of the data structure.
Bug: 113315999
Test: phone boots
Change-Id: I09f8f39454c013a84893ac304904a4412fc542bf
InputMethodManager#getInputMethodWindowVisibleHeight() has been kind
of unintentionally exposed to all the IME client processes and we know
some apps are already relying on this hidden API via reflection, which
is bad especially because it would be getting harder and harder to
keep maintaining the semantics of this not-well-defined hidden API
once we start supporting features like multi display. Thust this CL
adds TODO comments there to warn people who are going to touch this
method.
This CL does nothing except for adding comments. Hence there should
be no behavior change.
Bug: 113914148
Test: compile
Change-Id: Id2084530bdb82deef226d8207d2f311d2e78b28d
There's a lot of places that used TypedValue.TYPE_FIRST_COLOR_INT and
TypedValue.TYPE_LAST_COLOR_INT, and I'd like to propose that it's enough
of an implementation detail that it should have a dedicated public
method to query it.
Fixes: 114126626
Test: CTS tests to be added
Change-Id: I4d2a927cc3d2e999985d7e1c9b647d513fff53fc
Renamed getStateDrawableIndex to findStateDrawableIndex
based on API review feedback.
Change-Id: If07fe279fb02bc8180a28c7f58ea84ca030773ad
Fixes: 113856171
Test: Re-ran CTS
When pointer location is enabled, a line starting from (0,0) is drawn in
both positive and negative directions. This line is used for "movement
estimates", or predicted future coordinates of pointer location using
extrapolation with polynomials.
It's unclear what it's used for, but it is annoying to see on screen
when pointer location is enabled. It also only shows up on flings
directed to the top left corner or to the bottom right corner. It does
not show up otherwise, so it's likely not working as intended anyways.
Fixes: 111195578
Test: enable pointer location, the flings in different directions to
ensure that the line originating from (0,0) is no longer present.
also try flinging with multiple fingers to ensure that no crashes are
observed and velocities are displayed for each finger.
Change-Id: I42b2cbd7deebb2cb3593172156c3d948c8d7ba4d
If the user was using the default color temperature
for nightmode BrightnessTracker would incorrectly
record it as 0.
Bug: 112626811
Bug: 113656622
Test: atest BrightnessTrackerTest
Change-Id: Ib9152f516d0f2b24e1a3f91748f7ccc1647db222
