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

0 files changed, 0 insertions, 0 deletions