diff options
author | Yohei Yukawa <yukawa@google.com> | 2014-03-05 14:53:01 +0900 |
---|---|---|
committer | Ken Wakasa <kwakasa@google.com> | 2014-03-14 11:52:09 +0900 |
commit | 51b921d0e33302b3f431dcfa15bd6588408525ea (patch) | |
tree | 66fe0dd17d6e4b2e0d9456d0085bdea14dbeca7e /rs/java/android/renderscript/ProgramFragmentFixedFunction.java | |
parent | 3217cc6ff2b3139d8854a3f681da6ae1d163ac92 (diff) |
DO NOT MERGE - Preserve the order of InputMethodManager method calls
Cherrypick of I0f8d33b0c77129f72581bc43e7f4fdc25469b520
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: I0455b176bfb3176c533ba3241881f05092b98abc
Diffstat (limited to 'rs/java/android/renderscript/ProgramFragmentFixedFunction.java')
0 files changed, 0 insertions, 0 deletions