Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Skip to content
Commit 9e9fbb26 authored by Yohei Yukawa's avatar Yohei Yukawa
Browse files

Preserve the order of InputMethodManager method calls

This CL allows the Framework class InputMethodManager to behave
in a more deterministic way, that is to say, with an I/O barrier.

InputMethodManager#setAdditionalInputMethodSubtypes is internally
implemented as a RPC to the corresponding counterpart in
InputMethodManagerService. The problem here is that this RPC is
marked as "oneway". As a consequence, this public API call
returns immediately without waiting the additional subtypes are
actually added. This behavior is also not documented so far
unfortunately.

See the following demo code:

  Final InputMethodManager imm = ...;
  imm.setAdditionalInputMethodSubtypes(id, subTypes);
  Final List<InputMethodInfo> ims = imm.getInputMethodList();

Currently, it is not guaranteed that the InputMethodInfo returned
from #getInputMethodList reflects the result of the previous call
of #setAdditionalInputMethodSubtypes because of its undocumented
asynchronous nature.

With this CL, InputMethodManager#setAdditionalInputMethodSubtypes
behaves as if it has I/O barrier. This change should make it easy
for IME developers to use additional subtype mechanism.

BUG: 13033954
BUG: 13291370
Change-Id: I0f8d33b0c77129f72581bc43e7f4fdc25469b520
parent 4b131046
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment