Clarify how IMMS#executeOrSendMessage() works
This CL attempts to clarify how
InputMethodManagerService#executeOrSendMessage()
has been actually working, that is, probably to emulate oneway Binder
IPC semantics in case the target IInterface object is an in-process
Binder object, which is quite important to avoid dead-locks.
However, using it for IInputMethod objects is overkill because we have
never officially supported IMEs running in the system_server process.
There is no reason to define MSG_* for those cases.
As the initial step towards cleaning up those unnecessarily defined
switch cases, this CL introduces a new overload method
InputMethodManagerService#executeOrSendMessage(IInputMethod, Message)
to make it clear that it always immediately invokes
InputMethodManagerService#handleMessage()
if the target is IInputMethod.
The actual removal of
InputMethodManagerService#executeOrSendMessage(IInputMethod, Message)
will be done through subsequent CLs.
To summarize, there should be no observable behavior change unless
someone is surprisingly running InputMethodService in the
system_server process.
Bug: 215609403
Test: presubmit
Change-Id: I0c4aab9a0974857e531be4fb1fc75980b36f4443
1 file changed