tree b43ddd2d98028b70e6dce85dc168568d82daffee
parent 19b955eb5651da67713ab96312a1e040588f62aa
author Yohei Yukawa <yukawa@google.com> 1712781493 -0700
committer Yohei Yukawa <yukawa@google.com> 1712781493 -0700

Introduce IInputMethodManagerImpl

This is a preparation before instantiating InputMethodManagerService
in a worker thread.

As shown in ZeroJunkProxy introduced for Bug 293640003, proxying then
forwarding Binder IPCs is a common technique. However creating a
wrapper objects among

  IInputMethodManager.Stub

can be a bit confusing, because not all the Binder methods are
forwarded. For instance, if you introduced

  @Override
  protected boolean onTransact(int code, @NonNull Parcel data,
                               @Nullable Parcel reply, int flags) {
  }

into InputMethodManagerService but not into ZeroJunkProxy, it would be
called when and only when ZeroJunkProxy is not used. In general
creating a Binder wrapper that does "perfect forwarding" is not a
trivial task.

Instead of relying on IInputMethodManager.Stub, this CL introduces

  IInputMethodManagerImpl

for better readability and code maintainability in the following
sense.

 * Boilerplate code to implement IInputMethodManager.Stub can be
   encapsulated into IInputMethodManagerImpl
 * IInputMethodManagerImpl.Callback clearly defines what method
   calls can be intercepted (then forwarded).

This is a mechanical refactoring CL. There must be no user observable
behavior change.

Bug: 333593182
Test: atest CtsInputMethodTestCases
Test: atest CtsInputMethodInstallTestCases
Test: atest FrameworksInputMethodSystemServerTests
Change-Id: Ie678ad23cd761337b64b23bd53c17b85c6316fce