diff options
| author | Yohei Yukawa <yukawa@google.com> | 2018-09-06 10:47:15 -0700 |
|---|---|---|
| committer | Yohei Yukawa <yukawa@google.com> | 2018-09-06 10:47:15 -0700 |
| commit | 674cc4bedd506bf5700abfdc56842f8e051091c4 (patch) | |
| tree | 1bd7b93a661d014e5a1217a3d922d2ad2601599c /tools/aapt2/java/JavaClassGenerator_test.cpp | |
| parent | 029f67f85238ba2d4a2443c5659f30f21462d672 (diff) | |
Clarify that InputMethod.attachToken() can be called at most once
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
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions