| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
Design doc: go/multi-session-ime-removal
We no longer require this mechanism to support
multi-clients IME, remove it completely.
Bug: 173341412
Test: atest CtsInputMethodTestCases
Change-Id: I0bdc8fe3d32ccabc8ea7996fc689543c3f99331a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As previously InputMethodManager#toggleSoftInput is designed to tell
InputMethodService directly through IInputMethodSession to toggle
soft-keyboard visibility, this could be happened some unexpected IME
visibility issues that when the app calling this method in the wrong
state like the app toggling IME visibility when the app is off-screen
but unexpectedly it ends up showing soft-keyboard when the IME is in
invisible state.
To minimize the app compatibility without changing the public API
surface and reducing unexpected IME visibilty been toggled behavior
especially happens when switching the apps, changed the internal IPC
protocols to call IMMS#showSoftInput or IMMS#hideSoftInput directly
according the previous IME consumer requested visibility state,
so that in IMMS side can validate to see if the token user is
still focused and ready to toggle the IME visibility to show or hide.
As the result, we deprecated toggleSoftInput and
toggleSoftInputFromWindow to state the reason as the above, and
recommand to use showSoftInput or hideSoftInputFromWindow instead,
so that framework side no longer has to call {InputMethodSessionWrapper,
InputMethodSessionImpl}#toggleSoftInput.
Bug: 182071625
Test: m checkapi doc-comment-check-docs
Test: atest KeyboardVisibilityControlTest#testToggleSoftInput
Change-Id: I390dc029e7bcc30c200926a9bfbbbd0268a1f714
|
| |
|
|
|
|
|
|
|
|
| |
MSIME doesn't work when existing InputConnection is restored. The fix is
to allow MSIME to activate connection when window gains focus and set
inactive when window loses focus. This mimics single session IME.
Bug: 128751901
Test: Manually tested using steps in bug.
Change-Id: I22cef6c1dacb0ca402840da94a2bf02b989da447
|
|
|
An advanced multi-display support is requested for certain Android
form-factors so that user(s) can type text on each display at the same
time without losing software keyboard focus in other displays. This is
not possible in existing Android IMEs that are built on top of
InputMethodService class, because the assumption that a single IME
client can be focused at the same time was made before Android IME
APIs were introduced in Android 1.5 and many public APIs in
InputMethodService have already relied heavily on that
assumption. Updating InputMethodService class to support multi-client
scenario is, however, quite challenging because:
1. doing so would introduce an unacceptable amount of complexity into
InputMethodService, which is already hard to maintain,
2. IME developers still need to update their implementation to be
able to support parallel requests from multiple focused IME
client, which may require non-trivial redesign in their side
(e.g. input decoder, typing history database, ...), and
3. actual use cases for multi IME clients are expected to be evolved
rapidly hence the new protocol is not yet stable and not yet ready
to be exposed as public APIs.
This is why a new type of IME needs to be designed and developed
specifically for such special multi-display environments, rather than
reusing existing InputMethodService public class.
Note that there must be no behavior change unless multi-client IME is
explicitly enabled with 'adb shell setprop', which requires root
permission.
See multi-client-ime.md for details.
Fix: 114662040
Test: Manually verified as follows:
1. make -j MultiClientInputMethod
2. adb install -r $OUT/system/priv-app/MultiClientInputMethod/MultiClientInputMethod.apk
3. adb root
4. adb shell setprop persist.debug.multi_client_ime \
com.example.android.multiclientinputmethod/.MultiClientInputMethod
5. adb reboot
6. Try multiple text input scenario
Change-Id: I41dfe854557b178d8af740bc2869c936fc88608b
|
