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
3 files changed