diff options
| author | Yohei Yukawa <yukawa@google.com> | 2018-10-24 16:05:09 -0700 |
|---|---|---|
| committer | Yohei Yukawa <yukawa@google.com> | 2018-10-24 16:05:09 -0700 |
| commit | cb768bcbbf2024c3670795a3c8d8b9d71f30081e (patch) | |
| tree | a9643c55a8d1dbebd9b480003496bac28274c267 /rs/java/android/renderscript/ProgramFragmentFixedFunction.java | |
| parent | f682b1a5c459c99f257c7d10fb71cf9ca077199d (diff) | |
Fix local Binder call scenario of IMMS#addClient()
This is a follow up CL to my previous CL [1] that enabled per-display
InputMethodManager (IMM) instance.
One thing I mistakenly assumed in my previous CL is that there is
always a process boundary between IMM#createRealInstance() and
IMMS#addClient(), which is not true when IMM is being instantiated in
the system server process. This means that IMMS may associate an IME
client to wrong PID/UID/DisplayID when certain conditions are met.
With this CL, IMM#createRealInstance() always clears calling identity
so chat IMMS#addClient() can work correctly even for local Binder call
scenarios.
[1]: I78ad7cccb9586474c83f7e2f90c0bcabb221c47b
4052a10f2970f83d40bf5a45f3632cd63d084e51
Bug: 115893206
Bug: 117594679
Fix: 118335706
Test: atest ActivityManagerMultiDisplayTests
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:android.view.inputmethod.InputMethodManagerTest
Test: Manually tested with manually simulating the problematic scenario
Change-Id: I318d32d8997b0acb4fb193fe46831bdc9a4dd083
Diffstat (limited to 'rs/java/android/renderscript/ProgramFragmentFixedFunction.java')
0 files changed, 0 insertions, 0 deletions