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:
@ -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();
|
||||
}
|
||||
|
Reference in New Issue
Block a user