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
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
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
The CL fixes a race condition introduced by
I2799229bee7acfbd6236089487a5766f46605366, which caused apps to crash
when, for example, the following happened:
1. #show(xc, yc, xm, ym) is called on the main thread, and the
arguments are stored in mPrevShow[Source/Window]Coords
2. #show(xc, yc, xm', ym') is called on the main thread (note that only
the window position is different from the previous call), and we
post a job to the pixel copy handler thread to only update the
expected position of mWindow (without doing pixel copy)
3. the job starts and checks that mWindow != currentWindowInstance is
false
4. #dismiss() is called on the main thread, mWindow is set to null
5. the position update job at step 3 continues, grabs mLock but now mWindow is null
and the crash happens
Bug: 113272299
Test: manual testing
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: Ibc815888f4eeaf077fa1a9ddfb1d4d401382623a
Adds LooperStats and LooperStatsService which set a static
Looper.Observer to record the count of dispatched messages and
cpu/latency information. The aggregated stats are collected by
Westworld as pulled atoms.
The collection is disabled by default and requires a manual call to
enable:
adb shell cmd looper_stats enable
Test: Unit tests and tested manually that the collected data seems
reasonable.
Change-Id: I7162fbca4e324f62887f95df3405205cbe4416ca
For both key-value and full-backup. This makes the tasks wait for the
quota exceeded call, allowing the agent to complete before being torn
down (as described in bug). Also added a short time-out (3s) in case of
misbehaving agents.
Bug: 68762178
Bug: 110082831
Test: atest FrameworksServicesRoboTests
Test: 1. while true; do atest FullBackupQuotaTest; done
2. Stop after ~50 executions, verify all succeeded.
Test: 1. while true; do atest KeyValueQuotaTest; done
2. Stop after ~50 executions, verify all succeeded.
Test: CtsBackupTestCases
Change-Id: Ib582e75a4d317ab53a6df8cb261966a04ef085fb
