1) Moving WMS.setInputMethodWindowLocked to DisplayContent,
each display can have its own IME window.
2) Add getDisplayIdFromWindow in WindowManagerInternal,
used for InputMethodManagerService to know which display
for given IME window token.
3) Support add / remove IME window according displayId.
4) Modify WMS.inputMethodClientHasFocus to traverse all active display
if inputMethodClient focused.
5) Add displayId parameter for IInputMethod.initializeInternal to
update context display then client can addView to right display.
Note: 1) There should be zero behavior difference as long as the target
app is running on the default display.
2) The current implementation is not final and there are still
chances that the current IME may not work well or even crash
depending on how the IME is implemented.
Bug: 111364446
Test: manual, use ActivityView & launch Messages in VirtualDisplay,
tap search icon to see if soft input keyboard shown &
app window size is adjusted by soft input.
Change-Id: I8da315936caebdc8b2c16cff4e24192c06743251
Enable proto reading on the Android Framework with a memory efficient
pull parser.
Fixes: 112269636
Test: atest CtsProtoTestCases
Change-Id: If8331edb1ec393acd724ffb5d27d6efad1a42a80
Also add the annotations to the most common implementation
of Factory2 - Activity.
BUG: 78245676
Test: make
Change-Id: I49f1cf57be240525916a624f215fdff4701f32a5
Otherwise throw an IllegalStateException.
Fix: 26885514
Test: Make the bundle length not aligned by 4 and observe the IllegalStateException.
Change-Id: I57f0d5babdf1b8f1074eb2f4f76b71926db8b93c
This reverts commit 16703c4b47.
Reason for revert:
Just realized that this was not the best approach.
We could already make LocaleUtils package-private too before this CL.
So the right approach was moving these methods to new Java class(es)
instead of moving these methods to LocaleUtils.
Bug: 77730201
Bug: 114660660
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:com.android.internal.inputmethod
Change-Id: I29c87b9692f0f5e8255835579e2fb5270bc6c9c3
This CL moves InputMethodManagerService (IMMS)
from com.android.server
to com.android.server.inputmethod
so that we can mechanically factor out inner classes from IMMS to
separate package private classes.
This is purely a mechanical refactoring of an implementation detail.
There should be no observable behavior difference.
Fix: 114660660
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:com.android.internal.inputmethod
Change-Id: I023d8f2863601ee54f304988117d8ea750770f70
With my change [1] in Android N, applications no longer need to
manually call this hidden API even when directly implementing
InputConnection interface without extending BaseInputConnection [2].
So far applications that we have confirmed to be using this hidden API
is Chromium and browsers that are supposed to be built on top of
Chromium source code [3]. Actually my change [1] was per request from
Chromium team and Chromium does not use this hidden API on Android N
and later devices [4].
Moving forward, with this CL applications that target API 29 and later
are no longer allowed to use this hidden API since we see no actual
use case of this hidden API on Android N and later devices so far.
If you have any reason to continue relying on this hidden API, please
leave a comment in Bug 114740982.
[1]: I571d6cc9c6e461d8994aa7496e7e18be13766411
159dd47db3
[2]: This scenario had not been suppored until Android N.
See also other CLs that are tagged with Bug 24688781.
[3]: https://cs.chromium.org/chromium/src/content/public/android/java/src/org/chromium/content/browser/input/InputMethodManagerWrapperImpl.java?rcl=525c72b0f4694d6b3f93bcc7797d0411c2fa683c&l=113-128
[4]: crbug.com/551193
Bug: 114159783
Bug: 114740982
Test: compile
Merged-In: I41d6419438cef92cce81cc33d9db00dd2ee89d33
Change-Id: Iac81f49413605271fccc0b8aec3e6ed95925f061
