Do not bind IME until an IME client is recognized
This is an attempt to simplify InputMethodManagerService (IMMS) for better maintainability. Currently there are three cases where IMMS binds to the current InputMethodService. A. When the system becomes ready to run 3rd party apps. B. When the user is switched to another user. C. When an IME client is recognized while no IME is bound to IMMS The idea of this CL is to remove A and B. At a first glance, the conditions A and B seem to make sense, because it sounds like pre-warming InputMethodService to reduce the cold startup latency. However, the problem of A and B is that IMMS#mCurClient can be null. This means for instance we need to have a special fallback logic such as using default display to start InputMethodService. Also, most likely we would have the same pre-warming effect even without A and B, because once an IME client is recognized by IMMS, IMMS just starts binding to the current InputMethodService anyway even if the active IME client does not have text edit field. Therefore this CL removes A and B in favor of simplicity. Fix: 117730713 Test: manually tested on both initial boot and user switch scenarios. Change-Id: I52f6c4cd1e02be3a59e9a87e33b0a44f4ba8d80b
Loading
Please register or sign in to comment