When IME window switches from current display to another display and back quickly,
system will re-bind InputMethodService to re-attach window token for each moving,
the IME service lifecycle will be onBind -> onUnBind -> onDestroy -> onBind.
Ideally, system will deliver window token when onServiceConnected and system should
only receive one onServiceConnected when the last service bound.
But due to user switch display very quick, before unbind service callbacked from client,
the next bind service request comes, caused the connection exists in system side and
client will then callback 2 onServiceConnected to system.
Since CL [1] introduced InputMethodPrivilegedOperationsRegistry to deal with token
registraction singleton-ness, the exception will be thrown for above case due to
the duplicate window token passed to client.
Add InputMethodPrivilegedOperationsRegistry#isRegistered to check if the token
already registered, if so, skip this duplicate initialization request.
[1]: I4a61470f06ffac5f7a512536f8431489db0108f4
Fix: 133624278
Test: manual as below steps:
1) Settings > Developer options, enable "Simulated display" & "force desktop mode"
2) Reboot device.
3) Launch app from simulated display.
4) Launch app from primary display (i.e. contacts), focus EditText to show IME.
5) Tapping primary & simulated display repeatly & quickly.
6) See if any exception log from IME application. (i.e. Gboard)
Change-Id: Ie6bfbae735724fe744590e715124d2737d2b665d
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
For packages:
android.companion
android.filterfw
android.hardware.camera2.utils
android.inputmethodservice
android.net.nsd
android.os
android.preference
android.security.keymaster
android.service.dreams
android.telecom
android.telephony.ims.compat.feature
android.telephony
android.util
android.view.accessibility
android.media.effect
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: I9c2f8347952f3cc65759472b0e1a2717b285e44e
With this change, InsetsController.show/hide now links to IME. This also
takes care of animating IME along with other types.
Insets API are reactive i.e. they remain in sync with state of IME.
Test: atest InsetsControllerTest
Test: atest ImeInsetsConsumerTest
Bug: 118118435
Change-Id: Ib3997487bd19351d1d23bc70173fc9bdfd23a704
Add a IME state changes callback that pipes IME state into the Inset
consumer.
Bug: 118599175
Bug: 118118435
Test: atest InsetControllerTest
Test: atest InsetSourceConsumerTest
Test: atest ImeInsetsSourceConsumerTest
Change-Id: Id878226418e19cdf0499a0094f1d5c47fea33125
Pre-render input method views and window when EditText receives focus.
This is a pre-requisite for implementing better IME transitions.
Strategy:
Once EditText receives focus, startInput is called. If optimization is
available, IME views and window (SoftInputWindow) are created and
rendered. Until user taps on EditText or showSoftInput() is called, IME
window remains invisible. This pre-rendered window is kept around until
EditorInfo changes or new connection is started (onStartInput).
IME window's visibility will be set using new Insets controller API
rather than conventional client-side dialog.show().
Behavior:
- This is just IME side preparation CL. No performance improvements yet.
- There should be no user perceptible behavior change.
- As long as IME developers were following official lifecycle, they
shouldn't perceive any behavior change.
Availability:
This optimization, once fully implemented, will be available when:
- Device is not "Low memory"
- AND Master flag DebugFlags.FLAG_PRE_RENDER_IME_VIEWS is set.
- ViewRootImpl.USE_NEW_INSETS_API is enabled
Bug: 118599175
Bug: 111084606
Test: atest CtsInputMethodTestCases
Test: atest CtsInputMethodServiceHostTestCases
Test: atest ActivityManagerMultiDisplayTests
Test: Tested with 4 IMEs and didn't preceive any behavior change.
Scenarios tested:
1. With and without hardware keyboard
2. Screen rotation w/ fullscreen mode.
3. split-screen
Change-Id: I1a6300fe167eb205ee2b4214a6e270a52ebae062
This CL marks InputMethodService#onViewClicked() deprecated. There is
no actual implementation change at this moment, but developers should
avoid relying on this callback in general not only on futuer versions
of Android but also on existing devices.
Since this API was implemented in Android 4.0 ICS [1] it never worked
well for WebView and any other UI libraries that expose themselves as
a giant "Canvas", which can host their own UI hierarchy and sub focus
state.
If IME developers want consistent and reliable user interaction across
devices and applicactions, implementing IMEs' own UI on top of
CursorAnchorInfo API would be a good choice.
If IME developers just want to be notified an existing input
connection is interrupted, they can just monitor
InputMethodService#onFinishInput().
[1]: Ia71ad325e50a20e9e1001def662ef992bb50a9d0
863fcd6217
Fix: 123245358
Test: make -j checkbuild
Change-Id: I37a6c6d82d4a424f0df84633b09bca4881efbf02
Since its bettining [1] notifyUserAction() has been implemented as an
async IPC method. This wasn't changed when I recently moved it from
IInputMethodManager to IInputMethodPrivilegedOperations [2].
However, mixing sync and async methods into the same Binder object is
known to be an anti-pattern. Although sending some signals in an
asynchronous manner would make sense, it should be done by converting
all the methods to async (with some result callbacks for operations
that need to receive responce) like we do so in IInputContext.aidl.
As for IInputMethodPrivilegedOperations, I think converting
notifyUserAction() from async to sync is acceptable because there are
already similar sync methods such as:
* setImeWindowStatus
* reportStartInput
* reportFullscreenMode
* updateStatusIcon
[1]: I11ed9a767588f8080753cd9bce011dac7db579ad
d7443c83ce
[2]: Icc1f9c7f530f0144ecfd460e86114e109ae0044e
c07fd4c284
Bug: 114159783
Test: Manually verified as follows
1. Build and flush aosp_taimen-userdebug into Taimen
2. make -j SoftKeyboard
3. adb install -r $OUT/system/app/SoftKeyboard/SoftKeyboard.apk
4. adb shell ime enable com.example.android.softkeyboard/.SoftKeyboard
5. Open AOSP Keyboard settings
6. Enable "English (US)", "French", and "German"
7. Open SoftKeyboard settings
8. Enable "English (United States)", "English (GB)"
9. Open the Dialer app and tap the top edit field.
10. Make sure that the IME layout rotation order when tapping the
globe key will be updated only when you tap the keyboard to enter
some character.
11. Also confirm it with "adb shell dumpsys input_method" by checking
"mSwitchingController:" section there.
Change-Id: I9d41f19e30f205acd4d257a105e285bd32288130
Members modified herein are suspected to be false positives: i.e. things
that were added to the greylist in P, but subsequent data analysis
suggests that they are not, in fact, used after all.
Add a maxTargetSdk=P to these APIs. This is lower-risk that simply
removing these things from the greylist, as none of out data sources are
perfect nor complete.
For APIs that are not supported yet by annotations, move them to
hiddenapi-greylist-max-p.txt instead which has the same effect.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Change-Id: I020a9c09672ebcae64c5357abc4993e07e744687
This CL deprecates the following two classes.
* android.inputmethodservice.Keyboard
* android.inputmethodservice.KeyboardView
Most likely having these classes in the Android Framework does not
make much sense anymore, because basically it is just one
implementation of how keyboard-like UI can be implemented on top of
public Android APIs. Source code of these classes have been available
as part os AOSP. Thus it should not be that difficult for app
developers to have their own copy of these classes in their project or
re-implement a similar widget by themselves.
Fix: 116815596
Test: make -j checkbuild
Change-Id: Ie0cb0456c2cc4eacd4b188514508021774f60591
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
Currently IInputMethodSession#finishInput() is called nowhere.
Let's remove this IPC method exposed from InputMethodService to IME
client for now until we fully understand what is the right approach on
how and when InputMethodService#finishInput() should be called.
Note that we cannot simply remove InputMethodSession#finishInput()
because it is already published as a public API. In Bug 9216494
hopefully we can also discuss whether InputMethodSession#finishInput()
should be deprecated or can be reused for some actual use cases.
Bug: 9216494
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I9e378111c9df40cb6821583d1e6ae8f9fe38f2b1
Several java files had the typo {#link (for cross-references to other
Javadocs) instead of the proper {@link format. This was confusing the
new doc publish tool (Mivi) since that's the format used for {# Django
comments #}.
Fixed a couple of links that had other errors (which prevented building
once the {# -> {@ was done) and other typos.
Replaced throughout the frameworks/base project; I'll need a separate CL
for the AndroidX fixes.
(Other files were not in the public Javadocs.)
Bug: 111925950
Test: make ds-docs
Change-Id: Ia06e1fffd814671289a1caebd5962aedc18a28d7
Original Change-Id: Ia06e1fffd814671289a1caebd5962aedc18a28d7
Exempt-From-Owner-Approval: Docs-only change
InputMethodService#getInputMethodWindowRecommendedHeight() was added
with an assumption that some IMEs may want to call this API in
InputMethodService#onCreate() to adjust its IME window height to be
the same as the previous IME's window height [1], but in reality for
IME developers this API is quite difficult to use because relying on
this API means user-visible behavior is no longer deterministic.
Basically "Recommended" is too vague to rely on.
Let's deprecate this API before we end up having to define what is the
"recommended" height for more complicated scenarios such as
multi-displays and multi-profiles.
With this CL, IMS##getInputMethodWindowRecommendedHeight() always
returns 0. Basically doing this would not likely to cause
compatibility issues because the possibility of returning 0 has been
clearly mentioned in the API document. In practice this must have
returned 0 when the previous IME did not show the software keyboard
(e.g. AOSP keyboard with a hardware keyboard). Therefore IMEs that
have correctly used this API should be able to fall back to a safe
default behavior even if this API returns 0.
[1]: I0e920ee79c526c3aea6872b063cf294e2ab081c8
658c7b896a
Fix: 116502957
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: Ia2cde031a0e67d45a3631e54226f9b5a0698dd61
This CL effectively reverts the following 3 CLs.
* Reduce window resizing during IME transition
I5723f627ce323b0d12bd7b93f5b35fc4d342b50c
792faa2c16
* Clear the inset of previous IME when necessary
Ib04967f39b2529251e4835c42e9f99dba2cf43f2
2977eb7b6c
* Make IMS#clearInsetOfPreviousIme() reliable
Ib567daa009c1139858dccadcfc6a04465ebecf36
833bdcedce
The main idea behind the first CL is that the target application can
skil avoid layout resizing if the following two conditions are met.
A. WindowManagerService (WMS) can remember the last IME's inset until
the next IME's window is fully shown.
B. Both the last IME and the new IME have the same inset.
Basically the first CL implements the above A part with an assumption
that some IMEs would do the B part. However, in reality it is quite
unlikely that two random IMEs have the same inset size. At the same
time, maintaining this kind of special optimization is getting harder
and harder as more and more use cases and form factors need to be
supported.
Let's remove this optimization given that no one is benefited by it.
Fix: 116492038
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: do not see any noticeable visual difference
Change-Id: I8ffbf9bf7c3a8be54df0ca8eac1a1f041ef7d3c9
This is a preparation to allow InputMethodManager to have per-display
instances rather than the current per-process singleton instance.
When I introduced InputMethodPrivilegedOperationsRegistry [1], there
was an assumption that InputMethodManager was a per-process global
singleton object.
Now that we are going to break up that global per-process instance
into multiple per-display instances, having multiple
InputMethodPrivilegedOperationsRegistry instances probably does not
make much sense, because it would likely to increases the risk of
compability issues in existing IMEs. Although IME developers soon
really need to use the right Context to obtain the right instance of
InputMethodManager anyway, unnecessarily introducing compatibility
pitfalls that can be avoided in the Framework side is not my
intention.
With this CL, following 9 methods can continue to work no matter
whether InputMethodManager is a per-process singleton or not.
This is fine because those APIs had been mistakenly exposed in
InputMethodManager and already deprecated in favor of newly added ones
in InputMethodService.
* InputMethodManager.hideSoftInputFromInputMethod
* InputMethodManager.hideStatusIcon
* InputMethodManager.setInputMethod
* InputMethodManager.setInputMethodAndSubtype
* InputMethodManager.shouldOfferSwitchingToNextInputMethod
* InputMethodManager.showSoftInputFromInputMethod
* InputMethodManager.showStatusIcon
* InputMethodManager.switchToLastInputMethod
* InputMethodManager.switchToNextInputMethod
[1]: If762714b2003fa6477e1318110f63e13968c1d7e
eec552e9e9
Bug: 115893206
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I4a61470f06ffac5f7a512536f8431489db0108f4
Based on some analysis, these fields/methods are likely false positives.
Set maxTargetSdk=P so that any apps using them are required to migrate off
them in future. See the bug for more details.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Change-Id: I719b5c94e5b1f4fa562dd5d655953422958ad37e
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
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
This CL re-implements the way to propagate user action on an IME to
InputMethodManagerService (IMMS) so that we can dynamically update IME
Subtype rotation list discussed as requested in Bug 7043015.
It turns out that my previous CLs [1][2][3][4] are unnecessarily
complex because I tried to monitor user behavior in the IME client
process rather than in the IME process. In the end, I ended up
introducing a sequence number protocol for the sake of performance
with a ton of complexity.
This could have been implemented in a much safer and simpler way by
sending user action signals from the IME process to IMMS, because
A. IME already knows when it switches to a new subtype. IME needs to
send a signal only once per subtype change. There is no need to
use sequence counter.
B. Malicious IME client is unable to disturb IME rotation list by
sending a fake signal because the IPC endpoint is no longer exposed
to IME client processes.
In case there remain some applitations that still call this hidden API
via reflection without gracefully handling exceptions, this CL keeps
InputMethodManager.notifyUserAction() as a stub method so as not to
break such applications.
[1]: I11ed9a767588f8080753cd9bce011dac7db579ad
d7443c83ce
[2]: I7f3e13a7226ef0dceee82b67e8a0d8536f7e9807
2a6a8d2fbb063c84e388c185402c4ca788618c72
[3]: I19ad8542659bc092b92ee13eb9f1d68ddd4b815a
b56c6c721fc01fba8e36632d8e28f5123831abc5
[4]: I03fa436df0a5e348b3f93170aab3a8ac5a7e1677
c21ccc151631663d71230a3c1c756d94b575ab9e
Bug: 113177698
Fix: 114159783
Test: Manually verified as follows
1. Build and flush aosp_taimen-userdebug
2. make -j SoftKeyboard
3. adb install -r $OUT/system/app/SoftKeyboard/SoftKeyboard.apk
4. adb shell ime enable com.example.android.softkeyboard/.SoftKeyboard
5. Open AOSP Keyboard settings
6. Enable "English (US)", "French", and "German"
7. Open SoftKeyboard settings
8. Enable "English (United States)", "English (GB)"
9. Open the Dialer app and tap the top edit field.
10. Make sure that the IME layout rotation order when tapping the
globe key will be updated only when you tap the keyboard to enter
some character.
11. Also confirm it with "adb shell dumpsys input_method" by checking
"mSwitchingController:" section there.
Change-Id: Icc1f9c7f530f0144ecfd460e86114e109ae0044e
This is one further step towards deprecating 8 IME APIs that were
accidentally defined InputMethodManager (IMM) instead of
InputMethodService (IMS).
With this CL, API calls to those 8 deprecated ones in IMM will be
forwarded to IMS so that we can completely remove corresponding IPC
methods from IInputMethodManager.aidl. This guarantees that processes
that have no InputMethodService running there become unable to access
IPC methods behind such IME APIs that are intended to be used only
from IMEs.
One tricky thing is that the following 4 public APIs have been allowed
to processes that have WRITE_SECURE_SETTINGS permission, even if such
a process does not have active InputMethodService.
* InputMethodManager.setInputMethod
* InputMethodManager.setInputMethodAndSubtype
* InputMethodManager.switchToLastInputMethod
* InputMethodManager.switchToNextInputMethod
In general, user mode apps should not have WRITE_SECURE_SETTINGS
permission. Thus it might be not that difficult for us to simply
deprecate such a special rule. Bug 114488811 is tracking that effort.
For now, this CL preserves the existing behavior when a null IME token
is specified to those 4 APIs.
Bug: 114418674
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: If762714b2003fa6477e1318110f63e13968c1d7e
This is a follow up CL to previous CLs [1][2][3] that made sure that
APIs that are exposed only to IMEs should live in InputMethodService
instead of InputMethodManager.
Now that we have a dedicated Binder inferface [4] that allows
InputMethodService (IMS) to directly send IPCs to
InputMethodManagerService (IMMS) without relying on
InputMethodManager (IMM), it is natural for the above public APIs in
IMS to stop relying on IMM.
This CL also addresses a small concern that it is no longer obvious
when those APIs become available. Previously, it was a bit more
obvious that passing null IME token doesn't work so IME developers
could imagine that those APIs were unavailable until attachToken() is
called.
With this CL, InputMethodPrivilegedOperations starts showing warning
messages when called too early, which we hope help IME developers
understand why those APIs do nothing when called too early.
[1]: I3163f3cbe557c85103ca287bee0874a3b4194032
d8d03a8e1b
[2]: If6a786c5774805d041ea9672ef2721e4a38df7fc
fbc2f7acd5
[3]: I6efd5ca473e33e6faeadb7eea7772b9d2b8ca12b
164cfba536
[4]: I2f3ec3c5de546fb3603275a4b64000ed3f863b65
c54c117164
Bug: 114418674
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I995c4b922f91b94438c1292392b2c3030598594f
This is a mechanical refactoring to split out boilerplate code around
IPCs from InputMethodManager to another file.
Bug: 114418674
Bug: 113177698
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I9ca251482867daea84c2777f74fd9b8a2b0f29cd
Historically, InputMethodService (IMS) has relied on
InputMethodManager's hidden methods to communicate with
InputMethodManagerService (IMMS). Because of this, InputMethodManager
(IMM) has ended up being a mixture of IPC endpoint for both IME
clients and IME itself.
There are multiple problems.
* IMM is instantiated in almost all user mode processes. This means
that unnecessary IPC endpoints have been accessible to them via
reflection. Even though those endpoints refuses request without a
valid IME window token, and even though we have tighten up use of
private APIs in the runtime level, exposing unnecessary IPC
endpoints is still questionable.
* Mixing multiple responsibilities has been caused unnecessary
complexity in IMM. In Bug 70282603, we have moved some APIs from
IMM to IMS to sort out this complexity that are surfaced in API
boundary, but in the implementation level everything remained to be
the same.
Now that Bug 70282603 is fixed, the natural next step is to start
implementing actual an IPC connection from IMS to IMMS without relying
on IMM.
Here is the new diagram that describes (most of) IPC interfaces around
IMEs.
APP---(1)---IMMS
\ |
\ |
\ |
\ |
\ |
(2) (3)
\ |
\ |
\ |
\ |
\|
IME
(1): IInputMethodManager.aidl: send requests from APP to IMMS
IInputMethodClient.aidl: send requests from IMMS to APP
(2): IInputMethodSession.aidl: send requests from APP to IME
IInputContext.aidl: send requests from IME to APP
-> this is the actual interface behind InputConnection
(3): IInputMethod.aidl: send requests from IMMS to IME
IInputMethodPrivilegedOperations.aidl:
send requests from IME to IMMS
IInputMethodPrivilegedOperations.aidl is what this CL is adding.
With that, this CL moves 5 IPC methods
from IInputMethodManager.aidl (1)
to IInputMethodPrivilegedOperations.aidl (3).
There remain some IPC methods that are intended to be used only from
IMEs in IInputMethodManager.aidl because those methods have been
unfortunately exposed via public APIs in InputMethodmanager.
Although all of those public APIs were deprecated in Android P as part
of Bug 70282603, we still need to keep maintaining those APIs until
(most of) IMEs migrate to APIs that are newly introduced in
InputMethodService. It would take several years.
IInputMethodManager#getInputMethodWindowVisibleHeight() is another
method that we cannot migrate right now because some apps have already
relied on its corresponding hidden method in IMM, as discussed in Bug
113914148.
Fix: 113177698
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I2f3ec3c5de546fb3603275a4b64000ed3f863b65
I don't know whether this comment was valid in the initial
implementation or not, in the current system InputMethod.attachToken()
is not (indirectly) exposed to the IME client process vir Binder
interface. The only Binder interface that is exposed from the IME
process to the IME client process is IInputMethodSession, not
IInputMethod that implements attachToken().
One may think that a malicious app could try to call
Context.bindService() with InputMethod.SERVICE_INTERFACE to directly
obtain IInputMethod, but it should fail because IMEs must be
protecting their InputMethodService with BIND_INPUT_METHOD so that
only the system can bind to them.
This CL clarifies this point in both JavaDoc and its implementation.
If an IME happened to receive multiple attachToken(), it is an OS bug
and worth letting people know by crashing the IME process.
Fix: 114164394
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: Ia1e1d5ce020155b906e42a222f27b76905217395
After several attempts [1][2], this is our latest attempt to
gracefully ignore BadTokenException an IME that is being destroyed is
still handling pending showSoftInput() requests.
The point is that SoftInputWindow is a hidden API. This means that
instead of adding a bunch of try/catch blocks around mWindow.show() in
InputMethodService we can always override SoftInputWindow#show() to
inject our own code around mWindow.show().
With this CL, we can now fully track the internal lifecycle of
SoftInputWindow in SoftInputWindow#mWindowState. It enables us to
easily sort out cases like double fault cases discussed
in Bug 113159114, where showSoftInput() requests were queued multiple
times and still IMEs crash because what mWindow.show() throws for
the 2nd failure is IllegaStateException not BadTokenException.
[1] Id1e5f236f48c8ef01b7f157ba3f6e7ab2c26b135
6fcbb56290
[2] I2c21573cf972145ab08e66604cdb9344139a3f31
e4bbb1cc45
Fix: 113159114
Test: Manually verified IME switching scenario as follows.
1. Build and flush aosp_taimen-userdebug
2. make -j SoftKeyboard
3. adb install -r $OUT/system/app/SoftKeyboard/SoftKeyboard.apk
4. adb shell ime enable com.example.android.softkeyboard/.SoftKeyboard
5. Open the Dialer app and tap the top edit field.
6. Make sure that AOSP Keyboard is shown.
7. Tap the globe button on AOSP Keyboard.
8. Make sure that AOSP Keyboard is dismissed and SoftKeybaord is
shown.
9. Tap the globe button on SoftKeybaord.
10. Make sure that SoftKeybaord. is dismissed and AOSP Keyboard is
shown again.
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I1f51ed29df6b22b003ca285698e06b8f3ee5106a
For packages:
android.inputmethodservice
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: Ia0c5584247aa586cb30a4e4dd2618ec7f92f90ed
For packages:
android.inputmethodservice
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: I4b417b8257486fbdaa3b0f54a02ab70696d199e0
Previously, there was a time window between when an IME starts new
input and when the IME issues an IPC IMM#setImeWindowStatus() so that
WindowManagerService (WMS) can be notified about the new IME target
window.
With this CL, it is now guaranteed that WindowManagerService (WMS) is
always notified about the new IME target window before IME starts
interacting with that window.
Note that WMS is not using notified IME target window yet hence there
should be no user-visible behavior change.
Bug: 110531072
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I032b91ce722a16b17518a5d88015c574d7d3e51b
KeyboardView relies on deprecated Canvas#clipRect(Rect, Op.REPLACE).
This method is now unsupported and throws runtime exception.
Operations other than Difference and Intersect are unsupported.
This method call can be replaced by saving initial Canvas and calling
intersect operation of Canvas#clipRect(Rect).
Saving initial state can be achieved using Canvas.save() and
Canvas.restore().
Fixes: 79777033
Test: Manually verified with SoftKeyboard (which uses KeyboardView)
1. m SoftKeyboard
2. Set current keyboard to SoftKeyboard
3. SoftKeyboard runs fine
Test: Tested Canvas.getClipBounds() is consistent across save() &
.restore() operations
Change-Id: Id34c289f152b2ec06f37fffa9f940a909153447c
This is a follow up CL to our previous attempt [1] to make
InputMethodService#setBackDisposition() work and make sense.
Based on the feedback from several IME developers, we learned that
InputMethodService#setBackDisposition() is still confusing.
My conclusion is that trying to reuse existing flags was a mistake.
Here are the rationale for deprecating those two flags.
* BACK_DISPOSITION_WILL_NOT_DISMISS
This flag had never been used until we started using it in our
previous CL [1]. However, it turns out that what this flag means
is hard to understand because its JavaDoc only says
"This input method will not consume the back key."
To address the original goal of Bug 38513361, we can (and should)
introduce a new flag rather than reusing this confusing flag.
Deprecating this flag should have no impact because it had never
been used.
* BACK_DISPOSITION_WILL_DISMISS
On pre-P devices IME could abuse this flag to override the back
button to "dismiss" mode even after IME lost the focus. On the
other hand, as far as we know there is no good use case for this
flag. Hence rather than trying to fix such an abuse scenario, we
should just deprecate this flag.
Instead, a newly introduced flag BACK_DISPOSITION_ADJUST_NOTHING
should be sufficient to achieve the original goal of Bug 38513361.
This flag does not rely on the concept "dismiss" and key event
handling hence it would be much easier to maintain.
[1]: I99e7c413fe1a93f8d8cff897b5c5f0947690d2c0
3fecef119e
Fix: 74403102
Test: atest CtsInputMethodTestCases
Change-Id: I064209c40da79fffb2627e8f580818a793017b1f
d8d03a8e1b added new methods to
InputMethodService.
Allowing IME developers to override some of these methods would introduce
unnecessary complexity. Making these methods final makes sure developers
cannot inject some unexpected behavior when called by system.
Bug: 73701052
Test: atest InputMethodServiceTest
Test: atest CtsInputMethodServiceHostTestCases
Change-Id: I1af4ed05a0b7306d840a21129e921a57b4a5fc33
Display id is now part of MotionEvent.
Test: atest view.MotionEventTest view.KeyEventTest
Bug: 64258305
Change-Id: Ifadd6b34f4dd5a91669baf146daa62944d1de974
onWindowShown is more like it should called after mWindow.show()
in InputMethodService. Considering the compatibility problem, just
make its javadoc clearer to the IME developers rather than
change the calling order.
Bug: 72922821
Test: N/A
Change-Id: Ibfe20f40a65475f39c8e79d10e2c494e212cf054
Signed-off-by: tiansiming [田思明] <tiansiming@xiaomi.com>
InputMethodService.setBackDisposition() has been broken from a long
time. This is how setBackDisposition() is supposed to work
1. BACK_DISPOSITION_WILL_DISMISS:
When Keyboard is visible back button will show as down arrow (in
navigation bar) and tapping it will dismiss keyboard.
2. BACK_DISPOSITION_WILL_NOT_DISMISS:
When keyboard is visible, back button will be shown as BACK arrow and
tapping it will send the back event to current activity. If activity
doesn't handle onKeyDown() for back button, activity will finish and
keyboard will hide.
Note: backDisposition flags reset when finishInput() is called.
Bug: 38513361
Test: Manual with apk attached in bug
Test: atest InputMethodServiceTest
Change-Id: I99e7c413fe1a93f8d8cff897b5c5f0947690d2c0
This is a follow up CL to a recent CL [1], which aimed to move several
APIs only for InputMethodService from InputMethodManager to
InputMethodService.
This CL removes InputMethodService#hideSoftInputFromInputMethod(),
which is exactly the same as InputMethodService#requestHideSelf() that
is already available as a public API for IME developers.
This CL also virtually renames
InputMethodService#showSoftInputFromInputMethod() to
InputMethodService#requestShowSelf(), which has existed as a
private method but not been exposed to IME developers yet.
[1]: I3163f3cbe557c85103ca287bee0874a3b4194032
d8d03a8e1b
Bug: 70282603
Test: atest CtsInputMethodTestCases
Change-Id: If6a786c5774805d041ea9672ef2721e4a38df7fc
This is a safe refactoring that should have no behavior change in
terms of semantics and performance characteristics.
Test: make -j checkbuild
Change-Id: I30b40c483e490ff42c1c707233ca5cc7b67da28f
