Fix another deadlock between IMMS and TSMS
Bug 31247871 and Bug 31273203 are the same in terms of that both can be
triggered by calling TSM##getCurrentSpellCheckerSubtype() but different
in terms of what lock objects are involved.
To summarize
Bug 31273203: between IMMS#mMethodMap and IMM#H
A. OnClickListener.onClick() running in the IMMS locks IMMS#mMethodMap
then does some View operations, which can be blocked until
IMM#H is unlocked (e.g. IMM#onViewDetachedFromWindow()).
B. TSMS#getCurrentSpellCheckerSubtype() internally calls
IMM#getCurrentInputMethodSubtype(), which locks IMM#H then can be
blocked until IMMS#mMethodMap is unlocked.
The tricky point here is that IMMS and TSMS are running in the same
process hence IMM#H are actually shared between them.
Bug 31247871: between IMMS#mMethodMap and TSMS#mSpellCheckerMap
C. IMMS locks IMMS#mMethodMap then calls
InputMethodUtils#setNonSelectedSystemImesDisabledUntilUsed(), which
can be blocked until TSMS#mSpellCheckerMap is unlocked.
D. TSMS#getCurrentSpellCheckerSubtype() locks TSMS#mSpellCheckerMap
then may call IMM#getCurrentInputMethodSubtype(), which can be
blocked until IMMS#mMethodMap is released.
This CL aims to remove the layered lock in D to close Bug 31247871,
while the previous CL [1] took care of B to close Bug 31273203.
Note that A and C are still concerning and should also be taken care of
as a part of Bug 31273203.
[1]: I20cf2c20f49b1b02c0f7a18257b49d4bcc081b5d
fa1886feea55785f413f5efcd86bccca92f26759
Bug: 31247871
Bug: 31273203
Change-Id: I26479e7aa306e0df91d9911891d5625dd5f99678
1 file changed