tree 94faa20a39ae56970d86da97955277f398ec422c
parent 111b763d85b2a4efd47b195756b42c48f2935bda
author Yohei Yukawa <yukawa@google.com> 1536092640 -0700
committer Yohei Yukawa <yukawa@google.com> 1536092640 -0700

Re-introduce event order guaranee in IME client registration

This is a follow up CL to my previous CL [1], that may have slightly
changed event order guarantee about how an IME client
(InputMethodManager instance running in the IME cliernt process) will
be recognized by the system.

In short, IME client is recognized by InputMethodManagerService (IMMS)
as follows.
 1. The client process internally calls IWindowManager.openSession()
    with a callback Binder object IInputMethodClient.
 2. WindowManagerService (WMS) does in-process method call to let IMMS
    know about this client.
 3. Now the client process can start calling InputMethodManager APIs
    that internally relies on IInputMethodClient as the identify of
    the client.

Before the previous CL [1], both the step 1 and step 2 were executed
synchronously.  The client process was blocked until the step 2 were
fully executed in IMMS.

With the previous CL [1], now the step 2 is asynchronous and it is no
longer guaranteed that the client is actually registered even after
IWindowManager.openSession() is done.

With this CL, the step 2 becomes synchronous again to recover the
original strong guarantee about event order in IME client setup
process.

For consistency, this CL does the same thing for removeClient()
callback from WMS to IMMS, which had also been done in a synchronous
manner.

 [1]: I453200fd5847e9a78876affb6a1caec221525e1d
      e24ed79edb937c743b96b3f9baddc689fb694be1

Bug: 112670859
Fix: 113877122
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: Id91dd600120e4981aa1d9005ce644728968430c9