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
This commit is contained in:
Yohei Yukawa
2014-03-05 14:53:01 +09:00
parent 4b131046aa
commit 9e9fbb2639

View File

@ -73,7 +73,7 @@ interface IInputMethodManager {
boolean switchToNextInputMethod(in IBinder token, boolean onlyCurrentIme);
boolean shouldOfferSwitchingToNextInputMethod(in IBinder token);
boolean setInputMethodEnabled(String id, boolean enabled);
oneway void setAdditionalInputMethodSubtypes(String id, in InputMethodSubtype[] subtypes);
void setAdditionalInputMethodSubtypes(String id, in InputMethodSubtype[] subtypes);
int getInputMethodWindowVisibleHeight();
oneway void notifyTextCommitted();
}