| 3c5d0f104109048ba55308f81ca0ce7fa1afb626 |
|
25-May-2016 |
Jorim Jaggi <jjaggi@google.com> |
Close IME when attaching dock stack
So we don't end up with animation weirdness.
Bug: 28905720
Change-Id: I04124995dd99fa26d2e9be467c5976d7b20810a7
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 23cbe85610f780134cc77dd4a54732a22ed6e86e |
|
18-May-2016 |
Yohei Yukawa <yukawa@google.com> |
Move LocaleList to avoid layering violation.
Since LocaleList needs to depend on android.os.Parcelable, we cannot let
that class belong to "android.util" package, which causes layering
violation.
Bug: 28819696
Change-Id: Ia8de2ee9df3dd0a42b1fe84574439519b680fe18
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 833bdcedceee60a873694a77587393abfc830eb5 |
|
16-May-2016 |
Yohei Yukawa <yukawa@google.com> |
Make IMS#clearInsetOfPreviousIme() reliable.
This is a follow-up to my previous CL [1] for Bug 15922840 so that we
can clear the following variables in a more reliable way.
- PhoneWindowManager#mLastInputMethodWindow
- PhoneWindowManager#mLastInputMethodTargetWindow
The idea behind CL [2] is that when InputMethodManagerService (IMMS) is
switching from an IME to another IME, IMMS can send a signal to
WindowManagerService (WMS) to remember the current IME's inset so that
the system can continue using it to reduce jank until the new inset is
specified by the next IME. As summarized in Bug 28781358, however, if
the next IME does not show the window after the IME switch, WMS (or
PhoneWindowManager to be precise) keeps using the previous IME's inset
unexpectedly until the new IME shows its window. All we have seen in
Bug 15922840 and Bug 26663589 fall into this category.
The idea of this CL is just adding a hidden API to InputMethodManager so
that InputMethodService#clearInsetOfPreviousIme() can surely terminate
the IME transition state managed in PhoneWindowManager, rather than
relying on a hack of calling SoftInputWindow#show() and
SoftInputWindow#hide(), which actually does not work for Bug 26663589.
[1]: Ib04967f39b2529251e4835c42e9f99dba2cf43f2
2977eb7b6ce82309a1bb1ba4ab698f503cb0388a
[2]: I5723f627ce323b0d12bd7b93f5b35fc4d342b50c
792faa2c16d319e874a1d633f964a78266d5f3f2
Note that addressing all the corner cases in [2] still requires lots of
non-trivial change. Hence this CL focuses only on Bug 26663589 (and
the case we handled in Bug 15922840).
Bug: 26663589
Change-Id: Ib567daa009c1139858dccadcfc6a04465ebecf36
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| ce18c8167766f92856f94a8e88e19de4698960e6 |
|
28-Apr-2016 |
Jeff Sharkey <jsharkey@android.com> |
Introduce "unlocking" vs "unlocked" nuance.
There is a narrow window of time during user unlock where we're
reconciling user storage and dispatching the "unlock" status to
various internal system services. While in this "unlocking" state,
apps need to be told that the user still isn't actually "unlocked"
so they don't try making calls to AccountManager, etc.
The majority of internal services are interested in merging together
both the "unlocking" and "unlocked" state, so update them.
Clarify naming in AccountManagerService to make it clear that a local
list is being used, which mirrors the naming in MountService.
To match UX/PM requested behavior, move PRE_BOOT_COMPLETED dispatch
after the user is unlocked, but block BOOT_COMPLETED dispatch until
after all PRE_BOOT receivers are finished to avoid ANRs.
Bug: 28040947, 28164677
Change-Id: I57af2351633d9159f4483f19657ce0b62118d1ce
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| a09b4d2a611a7606e8fc8c73a24bd941b6fc173f |
|
15-Apr-2016 |
Narayan Kamath <narayan@google.com> |
Remove unnecessary allocation+unboxing of objects.
Transforming String->int can be done with 0 allocations
using Integer.parseInt.
bug: 28078871
Change-Id: I8d9f322d7154728849dde61ef282046032858d60
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| b2f901ab222b8a7193f9a17cb06232f73cf20518 |
|
12-Apr-2016 |
Yohei Yukawa <yukawa@google.com> |
Make sure that Toast is always shown by Meta-Space.
It turns out that my previous CL [1] does not always show Toast when
Meta-Space is hit multiple times in a short period. With this CL, we
attempt to make sure that the Toast is shown every time when Meta-Space
rotates the current IME subtype.
This CL also removes a rule that we do not show Toast when the IME
window has InputMethodService.IME_VISIBLE bit as it turns out to be
confusing. In Android N, we just provide a consistent behavior
no matter the IME window is visible or not.
[1]: If3fe17adbffe4c1125783fc77fed3cfe78fc7933
ebda7d7ae14b09bf15cc5f601ea44f903c782a9a
Bug: 27547054
Bug: 28127795
Change-Id: I551c51cd672dba6e7693d23cb181007f51b0de9d
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 4c74334c4425e43dfb53bc2ef707eebb1bef7d5b |
|
11-Apr-2016 |
Fyodor Kupolov <fkupolov@google.com> |
Merge "Added getProfileIds method returning array of userIds" into nyc-dev
|
| 063fe652be5ac01f1d4ffe621dc2a5f7e2170198 |
|
11-Apr-2016 |
Yohei Yukawa <yukawa@google.com> |
Merge "Make additional IME Subtype ID persistent." into nyc-dev
|
| 66baf69042720e15c97a125cd034010ac456fc44 |
|
11-Apr-2016 |
Yohei Yukawa <yukawa@google.com> |
Make additional IME Subtype ID persistent.
It turns out that IME subtypes specified to
InputMethodManager#setAdditionalInputMethodSubtypes() are stored in the
presistent storate without subtype IDs. As a result, when the system is
rebooted, the system would no longer consider those additional subtypes
as enabled due to subtype ID mismatch, until the IME re-adds those
additional subtypes again with the original subtype IDs.
Bug: 28104337
Change-Id: I1445213e0b83d76631a839b974ec1ab9b28ad7d2
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| d39ae854820edebe3f1cb8580117c451ffa5c4ec |
|
11-Apr-2016 |
Yohei Yukawa <yukawa@google.com> |
Shift+Meta+Space should reverse-rotate subtypes.
This is a follow up CL to my previous CL [1], which added a new key
binding Meta+Space to rotate enabled IME subtypes. With this CL,
Shift+Meta+Space starts reverse-rotating enabled IME subtypes as
originally planed.
[1]: I4005692215edfcf8bed3e86b1e07000148f986f5
ae61f7118a92e097e854c840d5726c0920f5db0e
Bug: 25753404
Bug: 28103839
Change-Id: I3694edd80be6dfe18b90360e24ae4d451b331928
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 7f98aa4aa93497692f200c553d2d6fff402e3de2 |
|
07-Apr-2016 |
Fyodor Kupolov <fkupolov@google.com> |
Added getProfileIds method returning array of userIds
Previously many usages of UserManager.getProfiles and getEnabledProfiles
were only using ids of returned users. Given that the list of users needs
to be parceled and unparceled for Binder calls, returning array of ids
minimizes memory usage and serialization time.
A new method getProfileIds was introduced which returns an array of userIds.
Existing method calls were updated where appropriate.
Bug: 27705805
Change-Id: Ic5d5decd77567ba0f749e48837a2c6fa10e812c0
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| fa0e47e0d439b8ecc28efacca92bb16e115e1e6e |
|
05-Apr-2016 |
Yohei Yukawa <yukawa@google.com> |
Add an overlayable config for IME switcher visibility.
Seems that there are two mutually exclusive requests about how IME
switcher visibility should be controlled.
A. Requests like Bug 19496012. We should show the IME switcher
as a quick access to "Show input method" setting when a physical
keyboard is attached via wireless connections that do not have
clear connection/disconnection affordance (e.g. Bluetooth
keyboards).
B. Requests like Bug 25432652. We should not have a rule like A
when a physical keyboard is attached with clear
connection/disconnection affordance (e.g. USB wired keyboards,
2-in-1 convertible tables w/ magnetic contacts).
Currently satisfying both requests at the same time is really difficult
because InputDevice does not have such an attribute. Even with such an
attribute, it's still an open question about how to deal with two or
more keyboards. As a short term solution, this CL add an overlayable
config so that each device can configure which strategy to apply as the
default behavior.
Bug: 26245853
Change-Id: Id2aef6597916422ea63435ae9c31a9a9b5ddf5b8
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| ebda7d7ae14b09bf15cc5f601ea44f903c782a9a |
|
03-Apr-2016 |
Yohei Yukawa <yukawa@google.com> |
Show toast when subtype is rotated by Meta-Space.
This follows up to my previous CL [1], with which we changed global
hardware key combinations regarding how multilingual user can manage
multiple keyboard layouts / input methods. Now we offer Meta-Space to
rotate input method (subtype), while we offered Shift-Space to rotate
hardware keyboard layouts previously.
One thing that is lost during above transition is an indication when the
such a key combination takes effect. Actually there was a toast that
shows new keyboard layout name, which is now lost.
With this CL, we bring back a toast so that we can show the new input
method (subtype) name. Note that the toast will be shown if all of the
following conditions are met.
- The input method (subtype) is rotated by a hardware key combination.
- IME window does not have IME_VISIBLE bit. Otherwise, showing a toast
is likely to cause UI overlap with the current IME's window.
[1]: I4005692215edfcf8bed3e86b1e07000148f986f5
ae61f7118a92e097e854c840d5726c0920f5db0e
Bug: 27547054
Change-Id: If3fe17adbffe4c1125783fc77fed3cfe78fc7933
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| a102dbddaa17d824f5941d27804b9b19c754e4af |
|
30-Mar-2016 |
Yohei Yukawa <yukawa@google.com> |
Remove "Other keyboards" from IME switcher dialog.
Per comment from UX team, we remove "Other keyboards" button from the
IME switcher dialog because it now points to a stale location, and is
not really needed.
Bug: 27924222
Change-Id: I23b20de3ee0efbb67b7ccac2f9e458b6689dd4ed
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 8939838d5d3ee8324d156ce60af4c7feacbb22a2 |
|
29-Mar-2016 |
Yohei Yukawa <yukawa@google.com> |
IME switcher should not always require IME_VISIBLE.
When one ore more physical keyboards are attached, we should not require
InputMethodService.IME_VISIBLE to show the IME switcher because some
IMEs such as LatinIME shows no software keyboard w/ physical keyboard.
Bug: 26245853
Change-Id: I8aac9f5989ebaf544ace06a3ba0993b3a834869d
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 6090c265e5703601e197b41c3caa49749b510411 |
|
25-Mar-2016 |
Griff Hazen <griff@google.com> |
Fix a status bar NPE in InputMethodManagerService
Change-Id: I27f43acd7fd46b7c4f12c6c860b98ebf55335e51
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 74750f209acccdd04e96dda890010245cbbd1c99 |
|
22-Mar-2016 |
Yohei Yukawa <yukawa@google.com> |
Explicitly handle null rather than relying on NPE.
IInputMethodManager is an actual IPC interface with which application
processes can communicate with InputMethodManagerService (IMMS).
Although this has never been a public API, it is actually exposed to the
application process hence we parameters passed to that interface methods
should be considered untrusted.
In Android L-MR1 and prior, calling IInputMethodManager#startInput()
from the application process via reflection with null EditorInfo can
result in NPE in the IME process, which is not great.
In Android M, doing that causes NPE in the IMMS process but the
exception is just sent back to the application process via Binder call,
which is no longer so harmful.
In Android N, we want to make sure that such an invalid internal API
call is clearly under our control, rather than relying on NPE, by having
an explicit null check.
Bug: 26866030
Change-Id: Ica812177d9ca454dd16e3dd6854f3053c329b344
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 1064d35307cff0601a22c8401cb72f628883489d |
|
19-Mar-2016 |
Yohei Yukawa <yukawa@google.com> |
Merge "Tell IMS about missing InputConnection methods." into nyc-dev
|
| 7b574cb8a1a3d0943392f2bf7180687eff8448ae |
|
17-Mar-2016 |
Yohei Yukawa <yukawa@google.com> |
Add more @NonNull/@Nullable to InputMethodSettings.
This follows up to a previous CL [1] for Bug 26279466.
It turns out that we have not clearly defined how nonexistent key should
be handled in InputMethodSettings#getEnabledInputMethodsStr(), e.g. it
returns "" for when mCopyOnWrite is true but returns null when
mCopyOnWrite is false.
Also, since InputMethodSettings now can revert changes made during
mCopyOnWrite is true, the caller may also start receiving null in the
following scenario.
1. call mSettings.switchCurrentUser(userId, true).
2. call mSettings.putEnabledInputMethodsStr(str) where str is non-null.
3. call mSettings.switchCurrentUser(userId, false).
4. call mSettings.getEnabledInputMethodsStr().
If the caller of getEnabledInputMethodsStr() has assumed that it would
never return null, then it would start crashing due to NPE.
With this CL, getEnabledInputMethodsStr() is marked to be @NonNull we
should no longer see such kind of NPE.
[1]: I9c6f9bb3d51174198e5f73588637f87ea0d90e11
68645a638ad1bfb734b2b0f56b17fe206bb891c5
Bug: 27687531
Change-Id: I169ad4957e68b65c64251b0849056195b8ca4911
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 19a80a1e807acd00bec999eaac7812da6ffce954 |
|
15-Mar-2016 |
Yohei Yukawa <yukawa@google.com> |
Tell IMS about missing InputConnection methods.
Summary:
This CL introduces a unified mechanism to deal with the situation
where the application directly implements InputConnection but some of
methods are not implemented. Note that there should be zero overhead
when the application extends BaseInputConnection or
InputConnectionWrapper.
Background:
When ever we add a new method to InputConnection, there has been a
risk that existing applications that directly implement
InputConnection can get java.lang.AbstractMethodError exception at
runtime, because older SDKs do not require the application developer
to implement the methods that are newly added in later SDKs. Because
of this we strongly discouraged developers to directly implement
InputConnection interface, and encouraged them to subclass
BaseInputConnection or InputConnectionWrapper instead. That said, as
requested in Bug 26945674, there is a certain demand to be able to
implement InputConnection without depending on BaseInputConnection.
The goal of this CL is to provide a reliable and sustainable solution
to above missing method scenario in InputConnection.
One of the reasons why dealing with missing InputConnection methods is
so difficult is that what InputMethodService receives to communicate
with the target application is actually a proxy class
com.android.internal.view.InputConnectionWrapper
that runs in the IME process and immediately returns true for most of
methods in InputConnection such as #commitText() and
#finishComposingText(). Because of this asynchronous nature, it is
too late to change the actual return value that the IME receives when
the application receives those one-way asynchronous IPC calls.
Solution:
To handle those cases, this CL checks the availability of
InputConnection methods that did not exist in the initial release
before the target application calls startInput(), and let the
application to send its availability bits to IMMS so that
InputConnectionWrapper running in the IME process can be initialized
with such availability bits. Note that we do know that
BaseInputConnection and its subclasses support all the InputConnection
methods, hence for most of applications we can just assume that all
the methods are available without reflection.
With such availability bits, InputConnectionWrapper is now able to
gracefully return failure code to the IME because the availability of
those methods is immutable, except for a tricky case where the
application relies on a proxy object that dynamically changes the
dispatch target.
Here is the list of APIs that we start checking the availability in
this CL.
[API Level 9+]
- InputConnection#getSelectedText(int)
- InputConnection#setComposingRegion(int, int)
[API Level 11+]
- InputConnection#commitCorrection(CorrectionInfo)
[API Level 21+]
- InputConnection#requestCursorUpdates(int)}
[API Level 24+]
- InputConnection#deleteSurroundingTextInCodePoints(int, int)
- InputConnection#getHandler()
Ideas alternatively considered: Default methods in InputConnection
We once considered having default methods in InputConnection but
abandoned this idea because it does not directly solve the problem
about how to tell the that the API does not take effect.
Also having default methods would make it difficult for application
developers to be aware of newly added methods in InputConnection.
Bug: 27407234
Bug: 27642734
Bug: 27650039
Change-Id: I3c58fadd924fad72cb984f0c23d3099fd0295c64
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 1e1a447000263151822b67a4981cd854fa8cb3c5 |
|
11-Mar-2016 |
Yohei Yukawa <yukawa@google.com> |
Persist isAsciiCapable attribute of additional subtypes.
This was somehow missed in the previous commit [1] that added
isAsciiCapable attribute to InputMethodSubtype.
For devices from API level 14 to 23, IME developers might be able to
work around this issue by specifying "AsciiCapable" [2] in
imeSubtypeExtraValue, which is not coverted by CTS though.
[1]: Ic3ace4b6e0432d56696bcbc0be336aec1dc744a5
dc8abf6cee0bcf44e2cad8155f0c151105d46471
[2]: I0bc9954f163a3ec38d08b9ba842a8a31176eb6a6
8e303cc5dd4860b6050d5725ce60ca7e6fb00c7b
Bug: 27603986
Change-Id: Ifb6bc83e782ac05df180dfe0d689897d07441a0c
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 7b18aec947a0b004d019dd95894063070d3b8433 |
|
07-Mar-2016 |
Yohei Yukawa <yukawa@google.com> |
Rely on SystemService#onSwitchUser() in IMMS.
SystemService class has already provided SystemService#onSwitchUser()
callback event. We do not need to set up SynchronousUserSwitchObserver
separately in InputMethodManagerService.
Bug: 25816558
Bug: 26279466
Change-Id: I8ce2ba1335ae4caa35f9a21d87b751bfb4614033
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 15e931273ee8d163f1250d40234cab7f1474e7a6 |
|
04-Mar-2016 |
Dianne Hackborn <hackbod@google.com> |
Don't need this "feature" any more.
Change-Id: I3ec4550e508656ae6da3112fd78f111214972a60
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| e985c240e3feb62ea38d5b4e386be083ca0f215b |
|
25-Feb-2016 |
Yohei Yukawa <yukawa@google.com> |
Use LocaleList for implicitly enabled subtypes.
There are two major changes in this CL:
1. Now IMMS resets its internal state whenever the system locale list
is changed, rather than just checking the primary system locale.
2. For software keyboard subtypes,
InputMethodUtils#getImplicitlyApplicableSubtypesLocked() now takes
the entire system locale list into account when determining what
subtypes should be enabled by default when the user does not
explicitly enable one or more subtypes.
Bug: 27129703
Change-Id: Iaf179d60c12b9a98b4f097e2449471c4184e049b
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 05c25f8a3a033816ac25aa5cd7db5b1ab495bc3f |
|
22-Feb-2016 |
Yohei Yukawa <yukawa@google.com> |
Unify windowGainedFocus() and startInput().
This is a safe refactoring that changes nothing.
In order to improve the keyboard dismissal lags [1][2], we have used
IMMS#windowGainedFocus() as a combined event to do startInput() in
certain situations.
To make the intent of those CLs clear, this CL renames
IMMS#windowGainedFocus() to IMMS#startInputOrWindowGainedFocus(). Note
that these are @hide internal IPC protocols. Hence this change is never
observable to application developers.
[1] I8494cbd6e19e2ab6db03f2463d9906680dda058b
a82ba54b0bbc3ff41f29db3998806cb45b261d58
[2] Icb58bef75ef4bf9979f3e2ba88cea20db2e2c3fb
7663d80f6b6fd6ca7a736c3802013a09c0abdeb9
Bug: 25373872
Change-Id: I56934f18e30d90fcdf77bcbb0c35a92a5feb1b82
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| ed4952ad0f76a70549777472cd9cefcbc8705917 |
|
17-Feb-2016 |
Yohei Yukawa <yukawa@google.com> |
Reset IMMS when the device is unlocked.
With File-Based Encryption (FBE), now we have yet another runteime event
to reset IMMS state in order to keep the list of available IMEs updated
and make sure one IME is enabled. Here is the full list of such runtime
events.
1. Boot phase reaches SystemService.PHASE_ACTIVITY_MANAGER_READY.
2. One or more packages that contain InputMethodService are updated.
3. The current user is switched.
4. The device locale is changed.
5. The device is unlocked by the current user.
Now we are adding the rule 5 in this CL.
We also apply Copy-On-Write (COW) settings mode, which was added in a
recent commit [1], until the deivice is unlocked. This allows us to
temporarily update the settings when the device is locked, without
messing up actual SecureSettings.
[1] I9c6f9bb3d51174198e5f73588637f87ea0d90e11
Here are some examples of what users would see in FBE-enabled devices.
Suppose we have following 5 IMEs installed.
- IME A: Encryption Aware, pre-installed, ASCII-capable
- IME B: Encryption Unaware, pre-installed, ASCII-capable
- IME C: Encryption Unaware, not pre-installed, ASCII-capable
- IME D: Encryption Aware, not pre-installed, ASCII-capable
Case 1)
Before boot:
Enabled: IME A
Selected: IME A
Device Locked:
Available: IME A, IME D
Enabled: IME A
Selected: IME A
Device Unolcked:
Available: IME A, IME B, IME C, IME D
Enabled: IME A
Selected: IME A
Case 2)
Before boot:
Enabled: IME A, IME B
Selected: IME B
Device Locked:
Available: IME A, IME D
Enabled: IME A
Selected: IME A
Device Unolcked:
Available: IME A, IME B, IME C, IME D
Enabled: IME A, IME B
Selected: IME B
Case 3)
Before boot:
Enabled: IME B, IME C
Selected: IME B
Device Locked:
Available: IME A, IME D
Enabled: IME A
Selected: IME A
Device Unolcked:
Available: IME A, IME B, IME C, IME D
Enabled: IME B, IME C
Selected: IME B
Note: in this case, IMMS can rely on an existing rule to support
the situation where enabled/selected IMEs were already uninstalled.
Case 4)
Before boot:
Enabled: IME B, IME C, IME D
Selected: IME B
Device Locked:
Available: IME A, IME D
Enabled: IME D
Selected: IME D
Device Unolcked:
Available: IME A, IME B, IME C, IME D
Enabled: IME B, IME C, IME D
Selected: IME B
Following things should be taken care of subsequent CLs.
- Add CTS to ensure that at least one encryption-aware IME is
pre-installed if the device supports FBE.
- Consider an accidental case where there is no encryption-aware IME.
This includes the case where all the encryption-aware system IMEs are
overwritten by encryption-unaware IMEs that have higher versions.
Bug: 26279466
Change-Id: Ifa2225070bf8223f8964cf063c86889e312c5e9a
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 5eb148bab6ea49c4c646649692ae6769b9c4e54c |
|
19-Feb-2016 |
Yohei Yukawa <yukawa@google.com> |
Merge "Stop granting default Contacts permission to IMEs." into nyc-dev
|
| 726c45970e35e3fff3eeb4d86c3b772db73adcc7 |
|
18-Feb-2016 |
Yohei Yukawa <yukawa@google.com> |
Stop granting default Contacts permission to IMEs.
This partially reverts the previous commit [1], which allowed special
components to be granted some pre-configured default permissions.
With this CL, we no longer grant Contacts permissions to pre-installed
IMEs. Rationals are:
1. Even without this CL, not the all pre-installed IMEs are granted
Contacts permission by default, because it was done during the boot
time where InputMethodManagerService is not yet completely
initialized. The current behavior is confusing not only for users
but also for developers.
2. In almost all the cases, IMEs are supposed to be able to work
without Contacts permission. Hence it is not too late to ask users
to grant the permission to the IME after the initial setup is
completed.
3. It is difficult to add new features such as File-Based Encryption
(FBE) with keeping the current implementation, because currently we
dynamically call mSettings.setCurrentUserId(userId) just to
enumerate what IMEs will be enabled for a given user. Adding
another condition (whether the user has already unlocked the device
or not) would make things more complicated.
Note that LatinIME has already support the case where Contacts
permission is not granted by default. It does not ask users for
anything until Setup-Wizard is completed, and requests Contacts
permission only when the user taps a message in the suggestion strip
that suggests users to use contacts name for typing suggestions.
[1] If8b8cadbd1980ffe7a6fc15bbb5f54a425f6e8f9
adc1cf46045ae756d3a9ccbccf6b0f894e4c1edd
Bug: 24756974
Bug: 26743676
Change-Id: Ief2a40b5971b3eb97d765f934d20ce7f2ef25665
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| c2393ac3bf2ec44aa46186408aa4636e8c7c4a4b |
|
18-Feb-2016 |
Yohei Yukawa <yukawa@google.com> |
Fix bugs in logic to find a default selectd IME.
With this CL, InputMethodManagerService#resetDefaultImeLocked()
picks up the default selected IME with the same logic to find the
default enabled IMEs [1]. It should make sense because the default
selected IME should be one of the default enabled IMEs. The previous
code is problematic because it does not check whether the IME is enabled
or not. There was a chance that unusable IME could be picked up.
This CL also fixes the same problem to Bug 17347871 that only language
part of the locale is taken into account.
[1] See the following series of CLs.
- part 1: I831502db502f4073c9c2f50ce7705a4e45e2e1e3
ed20f8d750ef0b6347448265a14ef2a2c7e1af5c
- part 2: Ife93d909fb8a24471c425c903e2b7048826e17a3
745e7bca8a622ffdf0d0a8e8e2485eab98182ede
- part 3: I6571d464a46453934f0a8f5e79018a67a9a3c845
d0dbd81fe2cd34c9a83e2f5217374d3e1a79f950
- part 4: I871ccda787eb0f1099ba3574356c1da4b33681f3
b21220efae92a56ff7b4b781fa614a6e3a8a3007
Bug: 27197621
Change-Id: Ia0f52c1fb9f5a68230284a1ec4829a2337b60bdd
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 859df05cc081f9390c3c0f4e816b39a8aadd8fd7 |
|
17-Feb-2016 |
Yohei Yukawa <yukawa@google.com> |
Make sure at least one IME is enabled.
It turns out that there still exists an edge case where the device can
be fallen into a state where IMMS would pick up no IME at the boot
phase. Suppose the following case:
Selecte IMEs : IME X
Enabled IMEs : IME X, IME Y, IME Z
Available IMEs: IME A, IME B
IMMS has already taken care of the case where the selected IME X is no
longer available at the boot phase for some reasons, which is good, but
what it does in InputMethodManagerService#chooseNewDefaultIMELocked() is
just picking up the best-looking IME only from the "Enabled IMEs"
without considering the case where all the enabled IMEs are unavailable
and we have to enable some IMEs as if it was the first boot.
This issue was found when making IMMS File-Based Encryption (FBE), where
it is relatively easy to see such a situation, e.g. only IME A and IME B
are encryption-aware, but subtle but critical details in storage layer
could cause the same situation. Bug 6685037 is an example.
As a tentative workaround, this CL introduces a recovery logic in
IMMS#buildInputMethodListLocked() as a workaround. In future we really
should sort out those initialization code though.
Full FBE support will be added in the next CL [1].
[1] Ifa2225070bf8223f8964cf063c86889e312c5e9a
Bug: 26279466
Change-Id: Ibd53ef8db7afcfac681b401912876d2a52c743d5
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 68645a638ad1bfb734b2b0f56b17fe206bb891c5 |
|
17-Feb-2016 |
Yohei Yukawa <yukawa@google.com> |
Add Copy-On-Write mode to InputMethodSettings.
This is a preparation for File-Based Encryption (FBE) support in IMMS.
In order to support File-Based Encryption (FBE), IMMS needs to reset
its internal state exactly when the device is unlocked by user first
time. This is important because IMMS would recognize only
encryption-aware input method services until the the device is unlocked
by the current user.
Even if we reset the internal state when the device is unlocked by the
current user, there are still two tricky points.
1. Except for the initial boot, IMMS uses Secure Settings to determine
what IMEs are enabled and what IME is currently selected. These
persistent state may not be suitable for the situation where the
device is not unlocked yet, because some of IMEs referenced there
may or may not be encryption-aware. Depending on the situations,
we may need to enable at least one encryption-aware IME to ensure
that the user is able to type password to unlock the device, even if
such an IME is not Settings.Secure.ENABLED_INPUT_METHODS. We have
to be careful when doing this because we don't want non
pre-installed IMEs to be enabled until the user approves it.
2. IMMS tends to save its internal state into Secure Settings.
However, because of the point 1, we may need to automatically enable
a certain IME to make sure the user is able to type even when the
device is not unlocked yet. We don't want such a temporary state
to be persistent in Secure Settings.
The basic idea of this CL is to implement Copy-On-Write (COW) mode in
InputMethodSettings so that we can later discard any changes made before
the device is unlocked. As the initial step, we start using this COW
mode until the the ActivityManager becomes ready. With this change we
can revert a previous commit [1] for Bug 6685037, where forward-locked
encrypted apks need to be taken care of an early boot phase.
[1] Ifb311f85154beadd4787ec73669bedfdf1f5172d
4c0e7152e74d091eb78af8baacd38287ba95a1a1
Bug: 26279466
Change-Id: I9c6f9bb3d51174198e5f73588637f87ea0d90e11
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 94e3330e639e1b96f5bd000f4c0f743b3cc174fc |
|
13-Feb-2016 |
Yohei Yukawa <yukawa@google.com> |
Remove redundant arguments.
The "list" and "map" arguments of IMMS#buildInputMethodListLocked() are
nothing more than synonyms of IMMS#mMethodList and IMMS#mMethodMap,
respectively. There is no reason to pass them as parameters. We can
access them directly as we have done there for other member fields.
This is kind of a mechanical refactoring. No behavior change is
intended.
Bug: 26279466
Change-Id: Ia27e19f9358ba33abbb1e5a27cebe7c9953c998f
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| d34e1486ee70ed433b86fa4815eded105f95887a |
|
11-Feb-2016 |
Yohei Yukawa <yukawa@google.com> |
Use Context#getSystemService(Class<T>) in IMMS.
This is a mechanical replacement of
Object Context#getSystemService(String)
with
T Context#getSystemService(Class<T>)
in InputMethodManagerService.java.
No behavior change is intended.
Bug: 26279466
Change-Id: Iec6b89f0367140f98d3ca4caa1dae7375e27f3ad
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| f3e5d1d483231d615f5e77032f787fcd8047488b |
|
29-Jan-2016 |
Anna Galusza <agalusza@google.com> |
Merge "Add API for IME control by Accessibility Services."
|
| 9b278112467581e2b8d99f29cf48b9fbef9cc53f |
|
04-Jan-2016 |
Anna Galusza <agalusza@google.com> |
Add API for IME control by Accessibility Services.
Change-Id: I3bb806cf420e0551a2c9ef97d95613f73e362df9
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 1e33dc8fdf3f722ecd32cc586b2a9515de24a242 |
|
21-Jan-2016 |
Fyodor Kupolov <fkupolov@google.com> |
Use SystemService lifecycle API in input method service
Change-Id: Ic17667df60b30e5355b61a3601ad27a000cab3a3
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 24bf3279f7f0f4bef8c8dcbbc7185a015a10ce5d |
|
20-Jan-2016 |
Jason Monk <jmonk@google.com> |
Merge "SysUI Tuner: Status bar work"
|
| 18f3d9a39e17f4d434542f0a22bc11ef827187b1 |
|
20-Jan-2016 |
Yohei Yukawa <yukawa@google.com> |
Merge "There should be a way to clear additional subtypes."
|
| 3e189877aba0285d79ce55349afae60457d95d6f |
|
12-Jan-2016 |
Jason Monk <jmonk@google.com> |
SysUI Tuner: Status bar work
Improve general status bar goodness, more exactness, less breakage.
Extra extra icons, disabled by default.
Control all the status bar things!
Probably other stuff (10000).
Change-Id: I5d6282a4dcbcefea9f0880042cdf6293cb693712
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 70f5c48e8e0403abe7e0f489b30890e46aac0d8b |
|
05-Jan-2016 |
Yohei Yukawa <yukawa@google.com> |
There should be a way to clear additional subtypes.
InputMethodManager#setAdditionalInputMethodSubtypes() is the only API
that allows IMEs to add and remove additional subtypes. However, due to
a bug, there is no way to clear the last entry of additional subtypes
because the API in question does nothing if the given array is emptry.
With this CL, an empty array is treated as a valid input.
This CL also adds a JavaDoc comment about a possible way to work around
this limitation in Android M and prior devices.
Bug: 26298984
Change-Id: I3731f84531247d071d9d88861e9079afc244a4e8
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 41f3427381d77fa9fcd12ed820716ebff7011c16 |
|
15-Dec-2015 |
Yohei Yukawa <yukawa@google.com> |
Fix IMM#showInputMethodAndSubtypeEnabler().
At least on AOSP InputMethodManager#showInputMethodAndSubtypeEnabler()
has been broken since its beginning. As of Android M, there are three
separate issues:
1. Type mismatch in message dispatching layer.
2. It does not correctly reject API calls from clients that do not
have IME focus.
3. Context#startActivityAsUser(intent, null, UserHandle.CURRENT) ends
up with java.lang.SecurityException:
Permission Denial: startActivity asks to run as user -2 but is
calling from user 0; this requires
android.permission.INTERACT_ACROSS_USERS_FULL.
Given that we have a good alternative to achieve the same result, it
would make sense to deprecate that method and encourage developers to
use Intent-based solution instead.
Before doing that, this CL fixes the issues just for the record.
Bug: 26189558
Change-Id: Ic7a0df3203fee19542a3143abba9bc31baf9698a
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| c18a05faf15111b6018e2599265853f0b21c66cb |
|
14-Dec-2015 |
Yohei Yukawa <yukawa@google.com> |
Merge "Rotate IMEs (subtypes) by Meta+Space."
|
| 026688070c8002911dc0a8f1fb487bf5bfed52d4 |
|
11-Dec-2015 |
Yohei Yukawa <yukawa@google.com> |
Merge changes If80df0bc,I4e91b2d7,If3aef820
* changes:
Apply Java 7 diamond operator.
Remove a redundant method overload.
Remove unnecessary parameter that is always true.
|
| 5f8e731f18c5cbfd345236c691db0b09aceb7c5d |
|
10-Dec-2015 |
Yohei Yukawa <yukawa@google.com> |
Remove unnecessary parameter that is always true.
This is a mechanical refactoring that removes an unnecessary parameter
that is always specified to 'true'.
No behavior change is intended.
Bug: 22859862
Change-Id: If3aef8209a355af1432ca2600bcc3a0027a6c24c
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| ae61f7118a92e097e854c840d5726c0920f5db0e |
|
09-Dec-2015 |
Yohei Yukawa <yukawa@google.com> |
Rotate IMEs (subtypes) by Meta+Space.
With this CL, PhoneWindowManager starts monitoring Meta+Space to trigger
input method rotation.
Note that InputMethodManagerService currently supports only one way
rotation. Currently there is no difference in the behavior between
Meta+Space and Shift+Meta+Space. Reverse rotation will be supported in
a subsequent CL.
Bug: 25753404
Change-Id: I4005692215edfcf8bed3e86b1e07000148f986f5
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 868d19b93b1e20c802a001c7304f8bcac5fe5114 |
|
08-Dec-2015 |
Yohei Yukawa <yukawa@google.com> |
Use BCP-47 LanguageTag in IME/Spell-Checker.
The primary goal of this CL is to make it clear that BCP-47 is the
expected format to annotate locale information for each
{InputMethod, SpellCkecker}Subtype. In order to avoid possible
compatibility issues, this CL introduce a new "languageTag" attribute
instead of reusing existing "imeSubtypeMode" and "subtypeLocale"
attributes.
For IME developers, this CL changes nothing unless "languageTag"
attribute is specified. To summarize:
A: If only legacy locale-string is specified
(existing IMEs/Spell-Checkers fall into this category):
-> The system uses locale-string.
B: If only LanguageTag is specified:
-> The system uses LanguageTag.
C: If both locale-string and languageTag are specified:
-> The system uses LanguageTag. Legacy locale-string is ignored.
For application developers, there should be some follow-ups CLs because
even with this CL most likely they would still have to take care of
previous versions of Android where:
- Locale#forLanguageTag() (N/A in API Level 20 and prior)
- Locale#toLanguageTag() (N/A in API Level 20 and prior)
- InputMethodSubtype#getLocale() (Deprecated in N)
- SpellCheckerSubtype#getLocale() (Deprecated in N)
- InputMethodSubtype#getLanguageTag() (N/A in M and prior)
- SpellCheckerSubtype#getLanguageTag() (N/A in M and prior)
One idea would be is in the official support library to provide a utility
method that takes care of above tasks and just returns a Locale object.
If we had a utility method in the support library, probably not
returning a Locale object from #getLanguageTag() would make sense.
From performance point of view both existing legacy locale-string
attribute and new LanguageTag attribute are just String objects that
travel from XML manifest to system services to applications via IPCs.
Hence there are no performance implications except for having one more
String objects.
Bug: 22858221
Change-Id: I6db107ad2afc7709167f7c4e5d24bd589ac8bd70
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 6005b3f87b063ee7ab7e8877a6a8c90b480f3341 |
|
24-Nov-2015 |
Fyodor Kupolov <fkupolov@google.com> |
Added SynchronousUserSwitchObserver
This class provides a synchronous version of onUserSwitching, which does not
require notifying a callback.
Bug: 25816558
Change-Id: Id31bb79bf10b5afd72dfca28cf4bea817e726f6f
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| b097b8262ba22040d46d6e212a31b758b7023307 |
|
01-Dec-2015 |
Yohei Yukawa <yukawa@google.com> |
Plumb IME subtype change from IMMS to IMS.
This is a plumbing CL from IMMS to IMS to notify when the current input
method subtype is changed. Those events are supposed to be used to
change physical keyboard layout depending on input method subtype, which
is to be implemented in subsequent CLs.
Bug: 25753054
Change-Id: I58e71ffce9ac9131551a00dd35e24235dadfef87
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 35d3f37bd51268cc99d81a3f537ac364d178e851 |
|
25-Nov-2015 |
Yohei Yukawa <yukawa@google.com> |
Tell the reason why IMM called startInput().
As a preparation to fix Bug 25373872, this CL introduces an additional
int parameter into the following two methods
- IInputMethodManager.startInput()
- IInputMethodManager.windowGainedFocus()
so that IMMS can know why IMM needs to start input. Currently the
"startInputReason" parameter is used only for debug message only when
the OS is rebuilt with flipping IMMS#DEBUG to true. Basically this
should have no impact in production builds except for a tiny overhead
of having one int parameter in some internal IPC calls.
Note that since 7663d80f6b6fd6ca7a736c3802013a09c0abdeb9 [1] basically
IMMS#windowGainedFocus() has been a superset of IMMS#startInput().
Hence we should pass to "startInputReason" parameter to
IMMS#windowGainedFocus() as well as IMMS#startInput().
[1]: Icb58bef75ef4bf9979f3e2ba88cea20db2e2c3fb
Bug: 25373872
Change-Id: Ia1fe120af7d71495c5f3a4fc0ec6390efb8240ca
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| e39d4edca74b810038810221a458fb5abb364d86 |
|
19-Nov-2015 |
Yohei Yukawa <yukawa@google.com> |
Track by which client the last focused window was reported.
To diagnose race conditions like issue #25373872, we want to track
which input method client corresponds to IMMS#mCurFocusedWindow.
Note that IMMS#mCurClient does not always correspond to
IMMS#mCurFocusedWindow, because input method clients can report the
window focus gain only, without requesting to be bound to IME.
Bug: 25373872
Change-Id: Iad121669c0f3db4461245dc80ff3fdee469abb79
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 072b1b5183bf3e193b20902b967fb3ecbbb175a3 |
|
19-Nov-2015 |
Yohei Yukawa <yukawa@google.com> |
Clear IMMS#mCurClient when it is dead.
Suppose the following case:
1. Launch an activity.
2. Focus in an EditText on the activity. IME is shown up.
3. Kill the activity process in a not graceful way, e.g.,
'adb shell kill'
After step 3, IMMS#removeClient(client) is immediately called back from
com.android.server.wm.Session, which is good, but we forgot to clear
IMMS#mCurClient to null.
Basically not clearing IMMS#mCurClient there is not so critical, because
1) we already have bunch of RemoteException check for the case where
IPC target is already dead, and in theory we cannot avoid this kind of
runtime error anyway, and 2) in most of cases new input method client
gains focus.
That said, in conjunction with other focus-related issues such
as bug #25373872, not cleaning that can result in the following error
message in 'input_method:' section of bugreport, which might be a bit
confusing.
Input method client dead: android.os.DeadObjectException
The primary goal of this CL is to make bugreport less confusing. Any
user/developer-visible changes beyond that is unintentional.
Bug: 25373872
Change-Id: Iee001ad9cce0c8c6324e3c0984be1e6f0e641d05
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 33e81798fa85947f934e262174184b11f97ca7a3 |
|
18-Nov-2015 |
Yohei Yukawa <yukawa@google.com> |
Tell the reason why IMMS unbinds IME client.
As a preparation to fix Bug 25373872, this introduce an additional
parameter to IInputMethodClient.unbind() so that the IME client
that is running in the application side can know why IMMS needs
to unbind the connection.
In future the "unbindReason" parameter is supposed to be used to
optimize the behavior of IMM runtime running in the application process,
but for now it is not used unless we build the sytem with debug message
enabled. Hence there should be no user-visible change with this CL.
Bug: 25373872
Change-Id: I74e83c8ca9d1d53e31e9c7b5bda1dec6274e59c8
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| bc7b5260431f0b34998a86a0da3227734b84388f |
|
18-Nov-2015 |
Yohei Yukawa <yukawa@google.com> |
Factor out IMMS#resetCurrentMethodAndClient().
As a preparation to fix Bug 25373872, this CL does a mechanical
code clean-ups in InputMethodManagerService.
As a follow up of I6c3186050592526fc95c5b27f18e2155acff5ebc, this CL
introduces IMMS#resetCurrentMethodAndClient() to make it clear when we
are resetting both IMMS->IME and IMMS->Apps connections.
This is literally mechanical. No behavior change is intended.
Bug: 25373872
Change-Id: Ia4161854d9da71783fd028fcb79407e4b9463aee
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| e13a20faccf6f33aa43c9c1fa4c4ec2a79b86cfb |
|
01-Oct-2015 |
Yohei Yukawa <yukawa@google.com> |
Unbind IME client when unsetting the current IME.
This follows up Ia70b870723acf647e0c27f24aff91b40d6f85543.
In certain scenarios, only IMMS#mCurMethodId is cleared with null
while IMMS#mCurClient is still pointing to the last application.
This is problematic when IMMS#mCurClient matches
SystemConfig#getFixedImeApps(), because it means that the current
IME is to be fixed to null.
With this CL, IMMS#unbindCurrentClientLocked() is always called
every time when IMMS#mCurMethodId is cleared to null. Note that
clearing IMMS#mCurMethodId to null is a kind of hard-reset, where
unbinding IME client should make much sense in terms of robust
and predictable state management.
Bug: 18056075
Change-Id: I6c3186050592526fc95c5b27f18e2155acff5ebc
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 70125f70dc058f0a79485ef473783e1fc6adbfc9 |
|
17-Sep-2015 |
Seigo Nonaka <nona@google.com> |
Merge "Move buildInputMethodsAndSubtypesString to InputMethodUtils"
|
| 2a099bcd6fe974bad47363c214a7bb327484aff8 |
|
15-Aug-2015 |
Seigo Nonaka <nona@google.com> |
Move buildInputMethodsAndSubtypesString to InputMethodUtils
This CL is mechanical code moving and does not change any existing
behavior.
buildInputMethodsAndSubtypesString is introduced by
If0104151b3526da6ecc669adde3119a239ecafeb for addressing Bug 19822542.
This code moving is one of the TODOs in above change.
Bug: 22285167
Change-Id: Ie63cf593794c9062919887e04a64208a900b1b8b
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 7c69636c9a406265e1da368f3edfd8fb9651132c |
|
16-Sep-2015 |
Xiaohui Chen <xiaohuic@google.com> |
Cleanup USER_OWNER in various services
Bug: 19913735
Change-Id: I980370bab18e1b9ccf4043eed2b9fd721a940f72
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 6ab1a8214195069f58692936914f66d8417b89c4 |
|
25-Aug-2015 |
Yohei Yukawa <yukawa@google.com> |
Organize import lines in InputMethodManagerService.java.
This CL changes nothing except for organizing the import lines
with the following style rule.
development/ide/intellij/codestyles/AndroidStyle.xml
No behavior change is intended.
Bug: 22285167
Change-Id: I029baa5e5609207ecc1023ece25fe803f676c377
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 7309b123c423504bb18e3d78dd22a36f7271676a |
|
18-Aug-2015 |
Seigo Nonaka <nona@google.com> |
Leverage WindowManagerInternal for private communication.
This CL changes following four methods from direct calling of
WindowManagerService to calling via WindowManagerInternal.
- getInputMethodWindowVisibleHeight
(introduced by I0e920ee79c526c3aea6872b063cf294e2ab081c8)
- saveLastInputMethodWindowForTransition
(introduced by Idf7700271cf882dfbf35c9d16f0f173a791221bc)
- isHardKeyboardAvailable
(introduced by I8a6a4a7efce50bfaec114117e33f97f27b1ef950)
- setOnHardKeyboardStatusChangeListener
(introduced by Ica768083f95c33dc1e494a28ba7d8b6eb989b0ef)
This CL does mechanical code moving and does not change any behaviors.
Bug: 22285167
Change-Id: I08e506050a0e495d62236b46e487848c967d185d
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| e27dc2b09d738e3a51232724724a559eec7e45b7 |
|
15-Aug-2015 |
Seigo Nonaka <nona@google.com> |
Use android.os.Debug.getCallers instead of self implementation.
This changes debug message format but does not change any other behavior.
Maintaining InputMethodUtils.getStackTrace() doesn't make much sense
because we already have a similar method in android.os.Debug.
since there is already utility function in Android. The length 10 is
sufficient for identifying caller modules.
getStackTrace() is introduced by
Ib23849d352db33f0747aa9d5a178f00ac726c13b just for debugging purpose as a
part of Bug 6931482.
Bug: 22285167
Change-Id: If3a6c0d2f51dc3774eef14b4f496b5b59ddcf5a6
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 2028ddaa5024dfc9844376f2032115aee360155a |
|
06-Jul-2015 |
Seigo Nonaka <nona@google.com> |
Move parseInputMethodsAndSubtypesString to InputMethodUtils.
This CL is mechanical code moving and does not change any existing
semantics.
parseInputMethodsAndSubtypesString is introduced by
If0104151b3526da6ecc669adde3119a239ecafeb for addressing Bug 19822542.
This code moving is one of the TODOs in above change.
Bug: 22285167
Change-Id: I01f5fafbbcfe3e3f5313829162ec011eaf2ad991
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 5894b434aaf30933c26eb44689970926d274ed19 |
|
11-Aug-2015 |
Yohei Yukawa <yukawa@google.com> |
Use try-with-resources and multi-catch exceptions in IMMS.
This CL applies new Java 7 language features try-with-resources
and multi-catch exceptions to InputMethodManagerService.
Basically this is a compile-time replacement hence there should
be neither behavior difference nor performance impact.
Bug: 22285167
Change-Id: I971bd12b63649802859410ee6a91351b1261f055
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 59bc6e03a47044a0f6903787403ae6779024c26d |
|
11-Aug-2015 |
Yohei Yukawa <yukawa@google.com> |
Delete unused code from IMMS and its utility library.
This CL changes nothing except for deleting unused code and
methods from InputMethodManagerService and InputMethodUtils.
No behavior change is expected.
Bug: 22285167
Change-Id: I3bd814c8b5892b4ef28d6d5622014463df8f1c2b
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 012d014c43c5fecb8f6e034089c22900c8755846 |
|
11-Aug-2015 |
Yohei Yukawa <yukawa@google.com> |
Merge "Use Java7 diamond operator in IMMS/IMS."
|
| 7c0832cb1cc1920efcc3fd266b3479d728d9b207 |
|
11-Aug-2015 |
Yohei Yukawa <yukawa@google.com> |
Remove unnecessary import lines from IMM and IMMS.
This CL changes nothing except for deleting unnecessary import
lines from IMM and IMMS.
Bug: 22285167
Change-Id: I86d250299fa1a8dc8f78343d6c141248c047255e
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| b0377bbf4e4e2b9b64a25223cd3b0c6386b3a0b7 |
|
11-Aug-2015 |
Yohei Yukawa <yukawa@google.com> |
Use Java7 diamond operator in IMMS/IMS.
This CL changes nothing except for deleting redundant type
parameters thanks to diamond operator.
Bug: 22285167
Change-Id: I12807f147bd0ca72c243e6fff87250d8f32d556b
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| df5af484f882ede16931a61a866f2ffefbe491ab |
|
05-Aug-2015 |
Yohei Yukawa <yukawa@google.com> |
Reduce log spam for the ease of debugging Bug 22857361.
Now InputMethodManagerService generates the following log
Couldn't create dir.: /data/system/inputmethod
not only when it fails to create the directory but also when
/data/system/inputmethod already exists, which makes it
difficult for us to figure out the root cause of boot failure
on emulator environments (Bug 22857361).
With this CL, IMMS no longer shows the message when the
directory already exists. Basically this is no risk change,
which changes only the condition to show the logging message.
Bug: 22857361
Change-Id: I09aaf501b19845c8309b09b57c23077f1757cd1a
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| fa6e0a80e20a4917b403fd330e01a9edd021aabc |
|
24-Jul-2015 |
Yohei Yukawa <yukawa@google.com> |
Don't rely on broadcast intent for waking up input method.
Basically this is a copy of Iabef96921dd554ce3768fb18619cefc
for InputMethodManagerService.
As described in JavaDoc of Intent#ACTION_SCREEN_OFF and
Intent#ACTION_SCREEN_ON, one can use those Intents to be
notified when the device becomes non-interactive and
interactive. IMMS has relied on them to enable and disable
InputConnection between the IME and the application so as not
to allow IMEs to update text when the user does not present.
This is actually our design goal as documented in JavaDoc of
InputMethodManager.
An IME can never interact with an InputConnection while
the screen is off. This is enforced by making all clients
inactive while the screen is off, and prevents bad IMEs from
driving the UI when the user can not be aware of its
behavior.
The goal of this CL is to improve the timeliness of above
mechianism by introducing a direct communication channel from
PowerManagerService to InputMethodManagerService via Notifier.
Actually this is what InputManager has been doing since
Iabef96921dd554ce3768fb18619cefc3230b5fb0.
Reasons behind this change are:
1. There are several bugreports that imply those Intents can
dispatch tens of seconds after it is enqueued. This is
indeed problematic because the user cannot type password
to unlock their devices until queued
Intent#ACTION_SCREEN_ON is dispatched. This CL addresses
such an issue without waiting for figuring out the root
cause of the delay.
2. Intent#ACTION_SCREEN_OFF and Intent#ACTION_SCREEN_ON are
sent as a ordered broadcast, which may not be suitable for
tasks that require a certain level of timeliness, and what
IMMS wants is to enable users to start typing immediately
after the system.
This CL was originally authored by Seigo Nonaka.
Bug: 22423200
Bug: 22555778
Change-Id: I747c37ff6dd8f233faef43f2b5713a4320e848eb
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 648abe156596a5f76e6bd883c4d25d0380bbd469 |
|
22-Jun-2015 |
Yohei Yukawa <yukawa@google.com> |
Merge "Set DISABLED_UNTIL_USED for the correct user in IMMS." into mnc-dev
|
| 094c71fd5c0b6b7ce4cd71d097d226a6a1acfc90 |
|
20-Jun-2015 |
Yohei Yukawa <yukawa@google.com> |
Set DISABLED_UNTIL_USED for the correct user in IMMS.
This CL makes If8ff1b2b95c36d33148def2ab87bd006aa520cc0
multi-user aware.
It turns out that DISABLED_UNTIL_USED has not been correctly
set to IMEs seen from secondary users because we have used
IMMS#mContext.getPackageManager(),
which always returns the PackageManager with the primary
users' context, when specifying
COMPONENT_ENABLED_STATE_DISABLED_UNTIL_USED.
We should use IPackageManager instead as we have already done
in many places of IMMS since Ib23849d352db33f0747aa9d5a178f00.
Bug: 8148605
Bug: 8365223
Bug: 21953608
Change-Id: I4b9d6510bf965204bb1f68c8b527d1a4df23fac4
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 1e575a0f32a00fc6a2f9a71fe1d1eb4426c71787 |
|
20-Jun-2015 |
Svet Ganov <svetoslavganov@google.com> |
Merge "Only grant runtime permissions to special components." into mnc-dev
|
| adc1cf46045ae756d3a9ccbccf6b0f894e4c1edd |
|
16-Jun-2015 |
Svet Ganov <svetoslavganov@google.com> |
Only grant runtime permissions to special components.
Now runtime permissions are granted only to components that are
part of the system or perform special system operations. For
exmple, the shell UID gets its runtime permissions granted by
default and the default phone app gets the phone permissions
granted by default.
bug:21764803
Change-Id: If8b8cadbd1980ffe7a6fc15bbb5f54a425f6e8f9
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| ec928651cc3e72c2e8ff6102a6c037c5119617ee |
|
10-Jun-2015 |
Seigo Nonaka <nona@google.com> |
Allow apps to hide the soft keyboard even in a transient state.
Since I69b88989ae4d0fe056e9ab8d67d0a955dd10e6d9, we have
asserted that the following test cases can pass with CTS.
assertTrue(imm.showSoftInput(
view, InputMethodManager.SHOW_IMPLICIT));
assertTrue(imm.hideSoftInputFromWindow(token, 0));
This CL fixes the test failure caused by
I33dc6278fd892f26e56352722bf9449b8b102030 in the above
CTS case.
Note that the test failure occurs only when the application
tries to close the software keyboard during IMMS#mInputShown
and IMMS#mImeWindowVis are in a transiently inconsistent
state.
Bug: 21727232
Change-Id: I195a9f9644583cb1172f48801e87273ad8def850
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 1ce4b6d3c6cb5b2eb9c9d00472be12245db92427 |
|
11-Jun-2015 |
Chris Wren <cwren@android.com> |
remove usage of deprecated method setLatestEventInfo
Bug: 18510449
Change-Id: I56a77991c729990e501f402e007dfa79ee57621e
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| d57ba675b1f767885e6d3ccd4d0f7037e634648b |
|
09-Jun-2015 |
Yohei Yukawa <yukawa@google.com> |
Do not accept an empty string in EditorInfo#packageName anymore.
In the previous CL Ib871141e3381e45c2623c5f4d692da7a7e78fcc5,
a null or empty EditorInfo#packageName was still allowed in case
there might be applications that simply forgot to set it.
However, after checking the code again, it would be safe to say
that having a null or an empty string in EditorInfo#packageName
would never happen unless the application intentionally clears it
in View#onCreateInputConnection. If there were such applications,
probably we could ask developers to stop doing that.
With this CL the system no longer accepts such an empty package
name. IME developers do not need to handle such an exceptional
case in their side.
Bug: 18931038
Change-Id: I10d579b48b59fa8ada796e92d58517c6cc5f2230
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 81482971431c91bbf63e8ad70c9f720e6bdf10b3 |
|
04-Jun-2015 |
Yohei Yukawa <yukawa@google.com> |
Make IMMS#mSettingsObserver multiuser-aware.
It turns out that IMMS#SettingsObserver has monitored
only main user's the secure settings. As a result, when the
secondary user changes enabled IMEs in the settigs app,
IMMS only updates internal enabled IME lists only when
the user is switched for secondary users. If a secondary
user enables or disables IMEs at the settings app, such
changes are not correctly notified to IMMS.
This CL addresses above inconsistency by explicitly
specifying the user ID when calling
ContentResolver#registerContentObserver().
This CL also allows dumpsys to contain internal state of
IMMS#mSettingsObserver in case we need to diagnose
problems only with bugreports.
Bug: 19340792
Bug: 19587437
Bug: 21612582
Change-Id: I34b437928c147e9fdbe935f725624cc97c816cb3
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| d724886cc13990ebcf55134455ef0fa223054ae8 |
|
04-Jun-2015 |
Yohei Yukawa <yukawa@google.com> |
Include InputMethodSubtypeSwitchingController in state dump.
In order to diagnose IME issues in multi-user / multi-profile
environment, internal state of
InputMethodSubtypeSwitchingController needs to be included in
the bugreport.
Bug: 19340792
Bug: 19587437
Bug: 21612582
Change-Id: I34aca2c1a4330ec08b5e40441e631809a8bb844e
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 90bf7084bf4f681383bf3329b0935de55330e782 |
|
04-Jun-2015 |
Yohei Yukawa <yukawa@google.com> |
Show more logs when switching users and IMMS#DEBUG==true.
This CL changes nothing but adds more logging points in IMMS when
switching users and IMMS#DEBUG==true.
No impact in production code.
Bug: 19340792
Bug: 19587437
Bug: 21612582
Change-Id: Ibaeb77ae50d246fc322cb023da7750d7415a58ab
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| d9eb911bb99df4d092dea00e52bcb9a1feac39a7 |
|
26-May-2015 |
Seigo Nonaka <nona@google.com> |
Hide the software input based on its state.
This is a 2nd trial of I20ae2749a which is reverted due to a regression.
The goals of this CL are two:
- Split setImeWindowStatus method into two: keeping IMS status and
updating system UI e.g. NavBar icon state.
- Hide software keyboard based on a realistic IMS status.
IMMS#mImeWindowVis has been used for two purpose, keeping IMS status and
updating the NavBar icons, e.g. keyboard icon.
However, to update NavBar icon, sometimes IMMS#mImeWindowVis value is
updated without any notification from IMS. As the result, the status
value becomes incosistent with the real IMS state.
This patch extracts NavBar update logic into separate method and keeps
IMMS#mImeWindowVis as notified status. Then, use it for hiding software
input correctly in IMMS#hideCurrentInputLocked.
This CL also removes refreshImeWindowVisibilityLocked method including
workaround for fixing Bug 11186297. That issue is no longer
reproducible with latest lock screen and almost no effect for existing
users and developers. So simply remove them in this CL.
BUG: 21446788
BUG: 20764441
BUG: 18722991
Change-Id: I33dc6278fd892f26e56352722bf9449b8b102030
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 54d512c9acc44484b7baa8d8cf02067d175dde11 |
|
20-May-2015 |
Yohei Yukawa <yukawa@google.com> |
Invalidate IMMS#mCurrentSubtype when upgrading the current IME.
Whenever the package to which the current IME belongs is
modified, IMMS#mCurrentSubtype needs to be invalidated.
Otherwize, InputMethodManager#getCurrentInputMethodSubtype()
continues to return the previously selected subtype.
One example scenario would be to update metadata of a subtype
in a new version of an IME with keeping the same subtypeId.
Suppose imeSubtypeExtraValue was updated from "ABC" to "XYZ".
In this scenario, the subtype in question retrieved with
IMM#getInputMethodList() then InputMethodInfo#getSubtypeAt()
has imeSubtypeExtraValue "XYZ", while the subtype returned
from InputMethodManager#getCurrentInputMethodSubtype() still
has imeSubtypeExtraValue "ABC".
With this CL, IMMS#mCurrentSubtype will be invalidate when
the active IME package is modified.
Bug: 21310194
Bug: 20708002
Change-Id: Ifbb35034d9c8e477ebb5353d2a470dfc1627bbd5
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 6640d21b2e8d16190fdf79cb3ec4b7694a1ea90b |
|
15-May-2015 |
Yohei Yukawa <yukawa@google.com> |
Revert "Fix IMMS#mInputShown state inconsistency."
This reverts commit 8d4a9117fbd0aaf03b8486ef920c73894a12cfcd.
Because of a regression Bug 21161785.
Bug: 21161785
Bug: 18722991
Bug: 20763994
Bug: 20764441
Bug: 20926844
Change-Id: If58612eda08764be0226832c0a73f03683889cdb
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 9e9e2e73c6ec7bece20268196dc89ad0c8bafad4 |
|
08-May-2015 |
Wojciech Staszkiewicz <staszkiewicz@google.com> |
Pass charset to XmlPullParser.setInput instead of null
Passing null to XmlPullParser.setInput forces it to do additional
work, which can be easily avoided if we know the charset beforehand.
bug: b/20849543
Change-Id: Iaff97be9df2d0f99d7af8f19f65934439c9658e2
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| c6c7cd2736fc3b6511e329a969409622750f2a58 |
|
13-May-2015 |
Yohei Yukawa <yukawa@google.com> |
Show IME switcher also when hardware keyboard is connected.
As per discussion with UX team, we start showing IME switcher UI
not only when there are multiple IMEs are enabled but also when
a hardware keyboard is connected.
This CL also simplifies needsToShowImeSwitchOngoingNotification()
by renaming it with shouldShowImeSwitcherLocked() and unifying
related condition checking into that method.
Bug: 19496012
Change-Id: Id44724a2a46190382c283a52ece8edffb740807d
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 8d4a9117fbd0aaf03b8486ef920c73894a12cfcd |
|
15-Apr-2015 |
Seigo Nonaka <nona@google.com> |
Fix IMMS#mInputShown state inconsistency.
The goal of this CL is to keep IMMS#mInputShown consistent with the
actual visibility of the software keyboard. Doing it indeed fixes many
user-visible inconsistency, especially when a physical keyboards is
attached.
It turned out that there are much more cases where IMMS#mInputShown
should have been updated. Basically every time when the software
keyboard is shown or hiden by non-user actions, IMMS#mInputShown was not
updated to the new state. Typical cases are:
- the IME shows its Emoji keyboard when the ALT key is pressed.
- the system hides software keyboard when physical keyboard is
connected.
With this CL, all known issues will disapper by updating
IMMS#mInputShown in IMMS#setImeWindowStatus().
Note that this CL depends on following preparation CLs directly or
indirectly.
- I7002ff063e490928309e9a9a0f6557ce3d12e6aa
- I1e50ee42838a1bf64a612da4904aa93458d44ea4
- I3decaf37198e5864a1763a059df4a36ebc70c5a7
- Id156c85535a221235737ea6dcc15a67f1c4b9f71
- I9f797d07ba02363fab58ceb9aecb3cc11fbc407e
- I60963f1474457ff37cca85e262460dca8105acff
Simply cherry-picking this CL into L branch is supposed to be
insufficient to fix all the issues and would result in different
regressions indeed.
BUG: 18722991
BUG: 20763994
BUG: 20764441
BUG: 20926844
Change-Id: I20ae2749a93bc33840df560aa71d4635e9ec849a
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 14e139179be7daab6ed452105387a3922752c219 |
|
07-May-2015 |
Seigo Nonaka <nona@gogole.com> |
Retry "Always show auxiliary subtypes from NavBar keyboard icon."
This CL relands I1e50ee42838a1bf64a612da4904aa93458d44ea4, which was
reverted by I3decaf37198e5864a1763a059df4a36ebc70c5a7 due to the build
breakage in 'layoutlib' target, with a proper fix.
Hereafter the original CL description is repeated.
The auxiliary subtypes should be listed if the input method picker is
opened from NavBar keyboard icon. However there is only
IMM#showInputMethodPicker() API to open input method picker and this is
also used from LockScreen or Settings UI. Auxiliary subtypes should not
be listed there(Id7cf5d122). Thus framework shows auxiliary subtypes
based on IMMS#mInputShown and LockScreen state, but it is not a perfect
solution. If a physical keyboard is connected, the soft input may be
gone. As the result, auxiliary subtypes won't be listed even if it is
opened from NavBar keyboard icon.
To fix this issue, this CL introduces IMM#showInputMethodPicker(boolean)
to be able to decide showing auxiliary subtypes by caller.
Note that IMM#showInputMethodPicker(boolean) is still hidden with @hide.
There is no public API change in this CL.
Bug: 20763994
Change-Id: Id156c85535a221235737ea6dcc15a67f1c4b9f71
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 1b0888fe8e70ddb92090edbaea545f2766ee404e |
|
07-May-2015 |
Bart Sears <bsears@google.com> |
Merge "Revert "Always show auxiliary subtypes from NavBar keyboard icon."" into mnc-dev
|
| d130bdc462b163f9afcaf144b477be80959e04d6 |
|
07-May-2015 |
Bart Sears <bsears@google.com> |
Revert "Always show auxiliary subtypes from NavBar keyboard icon."
CL is breaking the build. Discussed with Seigo and verting until he can take a look at it.
This reverts commit 80ff4ed6bb8dbdad7192d679a01096aa888e090b.
Change-Id: I3decaf37198e5864a1763a059df4a36ebc70c5a7
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 7afd01e2f1c0235f5d5a95744200d6739d6fcaa4 |
|
07-May-2015 |
Seigo Nonaka <nona@google.com> |
Merge "Do nothing if hideSoftInput is called from not focused client." into mnc-dev
|
| ccee75966ae00e9a2426df09c0aa8610e145ad72 |
|
06-May-2015 |
Seigo Nonaka <nona@google.com> |
Do nothing if hideSoftInput is called from not focused client.
IMMS#hideSoftInput calls IMMS#setImeWindowVisibilityStatusHiddenLocked
if it is called from not focused client. However this function changes
IMS visibility state and also changes the back key indicator wrongly.
IMMS should just ignore IMMS#hideSoftInput from not-focused client.
As a preparation to fix b/20764441, this CL partially reverts
Ife3a8733b1a1bf43b195ecf4b8c5082b6538d0a0 but shouldn't have any
user-visible UX regressions.
Bug: 20764441
Change-Id: I60963f1474457ff37cca85e262460dca8105acff
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 80ff4ed6bb8dbdad7192d679a01096aa888e090b |
|
04-May-2015 |
Seigo Nonaka <nona@google.com> |
Always show auxiliary subtypes from NavBar keyboard icon.
The auxiliary subtypes should be listed if the input method picker is
opened from NavBar keyboard icon. However there is only
IMM#showInputMethodPicker() API to open input method picker and this is
also used from LockScreen or Settings UI. Auxiliary subtypes should not
be listed there(Id7cf5d122). Thus framework shows auxiliary subtypes
based on IMMS#mInputShown and LockScreen state, but it is not a perfect
solution. If a physical keyboard is connected, the soft input may be
gone. As the result, auxiliary subtypes won't be listed even if it is
opened from NavBar keyboard icon.
To fix this issue, this CL introduces IMM#showInputMethodPicker(boolean)
to be able to decide showing auxiliary subtypes by caller.
Note that IMM#showInputMethodPicker(boolean) is still hidden with @hide.
There is no public API change in this CL.
Bug: 20763994
Change-Id: I1e50ee42838a1bf64a612da4904aa93458d44ea4
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| d4474cb9454c7a8b907c0be07236ffed4ecf3fd8 |
|
05-May-2015 |
Seigo Nonaka <nona@google.com> |
Remove dead code from IMMS.
MSG_SHOW_IM_PICKER is no longer used. Also by removing that message, we
can simplify showInputMethodMenu/showINputMethodSubtypeMenu.
Change-Id: I7002ff063e490928309e9a9a0f6557ce3d12e6aa
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| d69e4c1460017062e7c36be55801cb434ad19d97 |
|
24-Apr-2015 |
Dianne Hackborn <hackbod@google.com> |
Update use of procstate for services.
Now that we have a separate foreground service proc state
(above a sleeping top app), update various system services
to put their bindings into this state when appropriate.
There are two new bind flags for this -- one that just always
makes it a foreground service, another that only does it when
the device is awake (useful for things like the wallpaper).
And with all of that, tweak network policy manager to only
include apps that are at least foreground service state when
in power save and device idle modes. This will allow us to
further reduce the set of apps that have network access
(in particular not giving access to the current top app when
the screen is off), hopefully leading to even better battery
life.
Change-Id: I91d85a5c5ed64e856149e9a5d94a634a7925ec7f
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| e13b15c8101471c2aae1fbdcd55da9b2d7bbf7b1 |
|
13-Apr-2015 |
Kenny Guy <kennyguy@google.com> |
Merge "Add foreground profile changed to user switch observer."
|
| 429796226a8831af63a6303a58329f6b68f7b100 |
|
13-Apr-2015 |
Kenny Guy <kennyguy@google.com> |
Add foreground profile changed to user switch observer.
Called when the focused activity changes from one profile
to another to allow sys ui to vary display based on the
current profile.
This reverts commit 735a3f90598be31bca5d551d781280a205a5f27f.
Resubmitting with fix for build break in another package.
Bug: 19531782
Change-Id: I98cd2968ade3b1d23feb90d98057f306695d569e
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 48a09a0678752eca242a5379b024da78eb36144f |
|
13-Apr-2015 |
Kenny Guy <kennyguy@google.com> |
Merge "Revert "Add foreground profile changed to user switch observer.""
|
| 735a3f90598be31bca5d551d781280a205a5f27f |
|
13-Apr-2015 |
Kenny Guy <kennyguy@google.com> |
Revert "Add foreground profile changed to user switch observer."
This reverts commit 99b9030a3ececd9b88e5011c98be0a5b9499c776.
Change-Id: If152904f298ecd9e6fd5d038797d061a5c85eec8
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| d10bd4852291f1c99d2fc011606a695d631504fe |
|
13-Apr-2015 |
Kenny Guy <kennyguy@google.com> |
Merge "Add foreground profile changed to user switch observer."
|
| 99b9030a3ececd9b88e5011c98be0a5b9499c776 |
|
01-Apr-2015 |
Kenny Guy <kennyguy@google.com> |
Add foreground profile changed to user switch observer.
Called when the focused activity changes from one profile
to another to allow sys ui to vary display based on the
current profile.
Bug: 19531782
Change-Id: I1f98398f4b37ce77077394546906ef4dff06cd47
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| a0f3ad1b5aabe04d9eb1df8bad34124b826ab641 |
|
07-Apr-2015 |
Yohei Yukaw <yukawa@google.com> |
Verify that EditorInfo.packageName and uid are consistent
Currently EditorInfo.packageName is filled in the application
process and passed to the IME without any verification.
With this CL, the system makes sure that the provided package
name and application's uid are consistent before establishing
the input connection. In other words, the risk of spoofed
EditorInfo.packageName will be mitigated with this change.
This should be beneficial especially when an IME wants to have
per-application settings and/or dictionaries.
Bug: 18931038
Change-Id: Ib871141e3381e45c2623c5f4d692da7a7e78fcc5
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 7b9a28c7f0a7b88ed1ea777edc05002d2d2b38b7 |
|
18-Mar-2015 |
Christopher Tate <ctate@google.com> |
Back up and restore the set of enabled IMEs
The restored set of enabled IMEs/subtypes is merged into the
current state of the system, rather than simply replacing it.
This is because we do not want to accidentally disable or
reconfigure something that the user is currently relying on.
There's a certain amount of repetitive activity here, rebuilding
the enabled-state data structures in a different format, but it's
important for maintainability that the restore code be able to
rely on the core InputMethodUtils implementation of reading/writing
the settings element.
Bug 19822542
Change-Id: If0104151b3526da6ecc669adde3119a239ecafeb
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 4a357cd2e55293402d7172766f7f9419815fc1e8 |
|
19-Mar-2015 |
Alan Viverette <alanv@google.com> |
Replace usages of deprecated Resources.getColor() and getColorStateList()
Change-Id: I8f64fe6c4c44a92ff6d07250223ba590a1d691b0
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 6aa037887800e34bd057585106609236c950ca22 |
|
20-Feb-2015 |
Yohei Yukawa <yukawa@google.com> |
Remove deprecated hidden public methods from InputMethodUtils.
This is a follow up CL for a recent attempt to minimize
the number of default enabled IMEs.
- part1: I831502db502f4073c9c2f50ce7705a4e45e2e1e3
- part2: Ife93d909fb8a24471c425c903e2b7048826e17a3
- part3: I6571d464a46453934f0a8f5e79018a67a9a3c845
- part4: I871ccda787eb0f1099ba3574356c1da4b33681f3
This CL removes following deprecated hidden public methods
from InputMethodUtils as planned.
- isSystemImeThatHasEnglishKeyboardSubtype(InputMethodInfo)
- isValidSystemDefaultIme(boolean, InputMethodInfo, Context)
- containsSubtypeOf(InputMethodInfo, String, String)
This is a pure code refactoring with preserving the current
logic. Hence no behavior change is intended.
Change-Id: I1ff994cbbdef83e1e907a0d88aa9ae09d45263b4
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 505e3abb8dd0d8f594280b9510adef74623630d7 |
|
25-Nov-2014 |
Alan Viverette <alanv@google.com> |
Update IME selection dialog layout for Material
Also cleans up simple_list_item_2.xml formatting.
BUG: 18314215
Change-Id: I12b6ff19fca891524da7137b85dd576f85ee266a
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 5baaaac7c75dbcbd1de8e4f24820f231d2077231 |
|
27-Oct-2014 |
Hyejin Kim <hyejin.kim@lge.com> |
Fix not to show a log with empty default ime
It'll make reboot to show a log with empty defualt ime.
Bug: 18165757
Change-Id: I7a0d55bc0da0566a60abb24123c1dbcdd03be9ed
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| e63b5fae8d099d2f5d4d5a5cf7a8d5a86266c0fe |
|
19-Sep-2014 |
Yohei Yukawa <yukawa@google.com> |
Work on issue #17506095: Plumb a new configuration to IMMS
This CL makes a plumbing from SystemConfig to IMMS.
Change-Id: Ia70b870723acf647e0c27f24aff91b40d6f85543
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 443c2bafd824779a75cd4b922b6839a8df9795e9 |
|
10-Sep-2014 |
Yohei Yukawa <yukawa@google.com> |
Use public APIs to instantiate InputMethodSubtype
This is a groundwork for subsequent CLs that are
supposed to improve default input method selection
logics.
Historically we have had a @hide constructor of
InputMethodSubtype. However, this contructor is
a bit obsolete because we can not specify some
parameters that were added in recent platform
releases. We should use InputMethodSubtypeBuilder
instead.
BUG: 17347871
Change-Id: I72ad79682a58344e14380eb20e26edf98aee37cd
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 080fa34577ea4d461c91631986ede4a25877b305 |
|
01-Sep-2014 |
Yohei Yukawa <yukawa@google.com> |
Fix illegal cast in a logging code
This is a follow up CL for I19ad8542659bc092b92ee13eb9,
which introduced a ClassCastException error in the logging code
of MSG_SET_USER_ACTION_NOTIFICATION_SEQUENCE_NUMBER handler.
With this CL, the protocol in question looks like:
- what: MSG_SET_USER_ACTION_NOTIFICATION_SEQUENCE_NUMBER
- arg1: sequence number to be passed to
#setUserActionNotificationSequenceNumber(int)
- arg2: not used
- obj: ClientState
BUG: 16238154
BUG: 7043015
Change-Id: I08d52d4564bae9e042a2eff359e92549a66e837b
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 255dd04271088590fedc46c8e22b2fd4ab142d39 |
|
19-Aug-2014 |
Selim Cinek <cinek@google.com> |
Added notification color to all system notifications
Bug: 17128331
Change-Id: I81a94510ef51b99916f314c0dd65852426a1fbeb
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 7b5a96ba8364d5c180780b2f878f5a2b949cfdac |
|
10-Aug-2014 |
Michael Wright <michaelwr@google.com> |
Persist Show IME option.
Add a new setting to persist whether to show the IME when a hard
keyboard is connected.
Bug: 14066881
Change-Id: I2237ded850a0d4ab43ca441d0b7df13e0958e630
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 665366a3055c7baa36242b8c92c5ff85b1c3394b |
|
08-Aug-2014 |
Michael Wright <michaelwr@google.com> |
Change 'disable hardware keyboard' to 'show input method'
Previously it implied that the hardware keyboard would be disabled,
but really the toggle would just enable showing the IME even if a
hardware keyboard was present. Changed the string and swapped the
semantics to be more clear about the behavior.
Bug: 14066881
Change-Id: I9c8a7eb98b5277f1d09cc19fa7402e9b4cf51d92
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 8c6d477d30e64f3dfae20250b8274ffb37ef7bfa |
|
05-Aug-2014 |
Tadashi G. Takaoka <takaoka@google.com> |
Fix unnecessarily non-static inner class to static inner
Change-Id: I0c8efda6ef0bede6b5871cd651f42db82dbfbd39
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| d130b803b0787131208bea99926dc655b124f006 |
|
01-Aug-2014 |
Tadashi G. Takaoka <takaoka@google.com> |
Fix input method picker using Material design language
Note that the button text color will be fixed in the future change.
Bug: 14860252
Change-Id: I8a6a4a7efce50bfaec114117e33f97f27b1ef950
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 0023d0e0c4f5339b299d1eacbd4e7181c2fd271f |
|
10-Jul-2014 |
Yohei Yukawa <yukawa@google.com> |
Polish new IME API for L part 2: CursorAnchorInfo
This CL addresses feedbacks from internal customers for new
input method APIs that are mainly used for physical keyboard
support in L.
For performance reasons, #onUpdateCursorAnchorInfo is not called
back by default and each input method has to enable this
event notification explicitly whenever fine-grained character
locations are needed.
In L-preview, InputMethodSession#setCursorAnchorMonitorMode was
introduced for this purpose. However, we got several feedbacks
to be addressed.
- The effect of #setCursorAnchorMonitorMode is not preserved
during focus change. IMEs need to call
#setCursorAnchorMonitorMode every time when #onStartInput is
called. This is tricky and hard to understand.
- As #onUpdateCursorAnchorInfo is a new API, not all
applications/text editors have supported it. Therefore IMEs
can't always rely on　it. However, there is no way to query
if the attached target is supporting this new API or not.
It would helpful for IME authors if we can provide a
reliable way to query if the attached input target is
supporting the new API or not.
In order to address these issues, the triggering method has
moved from InputMethodSession to InputConnection in this CL,
as an analogy of existing InputConnection#getExtractedText API,
which has provided similar functionality including optional
reactive event callbacks from the application to the IME.
BUG: 15812658
BUG: 16118603
Change-Id: I3c6b69bd9d79b199afe68d838f25effa6048e5cc
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 3d1e8129ebd69db49d80e5d598f608c59b884cdf |
|
06-Jun-2014 |
Yohei Yukawa <yukawa@google.com> |
Introduce a sequence number to avoid redundant IPCs
This CL introduces a sequence number to avoid redundant IPCs
between IMM and IMMS. The basic concept is that:
1. IMMS maintains a sequence number for #notifyUserAction.
2. IMMS increases the sequence number whenever the current
IME/subtype is changed.
3. IMMS notifies the new sequence number to IMM.
4. IMM maintains the last sent sequence number and the next
sequence number. IMM should call #notifyUserAction only
once per particular sequence number.
5. IMMS ignores #notifyUserAction if the specified sequence
number is not the expected one.
BUG: 7043015
Change-Id: I19ad8542659bc092b92ee13eb9f1d68ddd4b815a
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 0297051162193ef2b7d906409868e404f77e4c31 |
|
05-Jun-2014 |
Yohei Yukawa <yukawa@google.com> |
Trivial method renaming for notifyTextCommitted
This CL does not change existing behavior but only renames
notifyTextCommitted with notifyUserAction so that we can use
not only text commit but also other actions such as just typing
a character will be used as a trigger to update the IME
rotation order for better IME switching experience.
BUG: 7043015
Change-Id: I7f3e13a7226ef0dceee82b67e8a0d8536f7e9807
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| a07557471e43226fd23f6447c1e61177726524c9 |
|
04-Jun-2014 |
Yohei Yukawa <yukawa@google.com> |
Hardening token validation in InputMethodManagerService
This CL adds missing token validations in
InputMethodManagerService#switchToNextInputMethod and
InputMethodManagerService#shouldOfferSwitchingToNextInputMethod.
This CL also fixes a possible race condition when validating
the token in InputMethodManagerService#updateStatusIcon.
BUG: 15420379
Change-Id: I043aa30a19c821f33effd57dfd6590b0e3ed817b
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 22c97be73b2686a4a06cf31d0b211f47e7b92595 |
|
04-Jun-2014 |
Yohei Yukawa <yukawa@google.com> |
Remove code duplication in InputMethodManagerService
This is a groundwork for the subsequent fix. It should not change
existing behavior.
BUG: 15420379
Change-Id: I106b3f50731c799e06b26d1eab9c6a406c06d78c
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 4e02bc6f8fa64d8a8398371836e2e9abf3be3070 |
|
04-Jun-2014 |
Yohei Yukawa <yukawa@google.com> |
Remove redundant synchronization blocks from IMMS
This is a groundwork for the subsequent fix. It should not change
existing behavior.
BUG: 15420379
Change-Id: I6f81ec77e748a8c7c26ffa1f5faf39684b210ae4
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 3d46bab02978df14354379c4b10d7f68c3b80771 |
|
30-May-2014 |
Yohei Yukawa <yukawa@google.com> |
Rebuild the enabled IMEs list when changed in Settings page
With this CL, the input method switching controller is notified
even when the list of enabled IMEs is changed by System
Settings.
Ideally we should hook every setter method in
InputMethodSettings to ensure that InputMethodSettings and
InputMethodSubtypeSwitchingController can share the same list.
Until then, most of user visible weirdness should disappear
with this CL.
BUG: 15299968
Change-Id: Ie41da226d71b58d2e12057f85e4793b35e8b9f23
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 5a647b69be8ac8d40c33ed9abe63e41514699e5b |
|
21-May-2014 |
Yohei Yukawa <yukawa@google.com> |
Remove unnecessary internal lock
Previously, InputMethodSubtypeSwitchingController has relied on
its own internal lock for #getNextInputMethod and
class has to be invalidated whenever
InputMethodManagerService#mMethodMap is updated, any method of
InputMethodSubtypeSwitchingController should be called under
the global lock of InputMethodManagerService#mMethodMap.
As a consequence, we can conclude that
InputMethodSubtypeSwitchingController does not need its own
internal lock.
This CL also adds additional synchronization blocks into
the constructor of InputMethodManagerService to address the
existing inconsistency that methods with *Locked suffix are
called without the lock actually.
BUG: 7043015
Change-Id: I9d4d3d7232c984432185c10c13fb726a6158cac8
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| c834a2590cc7ac478ba2ef5a6d8eb7ce471df132 |
|
21-May-2014 |
Yohei Yukawa <yukawa@google.com> |
Update InputMethodSubtypeSwitchingController correctly
User visible behavior is supposed to be identical with and
without this CL.
Previously, there is some corner cases where
InputMethodSubtypeSwitchingController#resetCircularListLocked is
not called but the list of enabled input method is updated.
Fortunately, this corner cases are not observable for a user
because we have not updated the the rotation order dynamically.
However we should fix this before implementing smarter rotation
algorithm that changes the rotation order dynamically.
BUG: 7043015
Change-Id: I145a514dc4cde369ba50431c408c916046ab0c6e
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| d4e6d467cd61d6bec1ae25744a415a96f0a0f760 |
|
17-May-2014 |
Dianne Hackborn <hackbod@google.com> |
Delay the dispatching of non-wakeup alarms.
When the screen is off, there are no guarantees about when
non-wakeup alarms will be dispatched. Historically they are
dispatched any time the device wakes up. With this change,
we will delay the dispatch until sometime later.
The amount of delay is determined by how long the screen has
been off. Currently there are three possible delays: up to
2 minutes if the screen has been off for less than 5 minutes;
up to 15 minutes if it has been off for less than 30 minutes;
and otherwise up to an hour.
When the screen is turned on or a wakeup alarm is dispatched,
all delayed alarms will also be dispatched.
Note that one of the things this delays is TIME_TICK, which
means the in many cases we won't deliver TIME_TICK until the
screen is in the process of waking up. The current
implementation causes this to be delayed until the SCREEN_ON
broadcast is sent; we probably want to improve this to have
the power manager tell the alarm manager about the screen
turning on before it sends that broadcast, to help make sure
things like the lock screen can update their current time
before the screen is actually turned on.
In addition, switch all of the alarm stats to use the new
PendingIntent "tag" identifier for its operations, instead
of the old code to try to construct a pseudo-identifier
by retrieving the raw Intent.
Also add a new package manager command to immediately write
packages.xml.
Change-Id: Id4b14757cccff9cb2c6b36de994de38163abf615
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 9d91b43c8d0fa233905ecf132c6e6ee664904694 |
|
19-May-2014 |
Yohei Yukawa <yukawa@google.com> |
Do not pass null to IInputMethod#setSessionEnabled
It doen't make sense to pass null as IInputMethodSession
for IInputMethod#setSessionEnabled. If we do this, it
causes NPE.
BUG: 14980068
Change-Id: Ide48d098d5e7640890257e31f8872e79b9821eb2
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 807ef76e23e08405532a0e7e2d71e7433bf7ae9a |
|
08-May-2014 |
Jason Monk <jmonk@google.com> |
Don't show switcher button when IME switcher shown
This keeps track of when the switcher is being shown and disables
the IME switcher button/notification when it is up.
Bug: 14631536
Change-Id: I4adf24bc5fa6377645915419583d60596b3bdde0
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| b605fecd9e4282823af754b3968b21205d64554a |
|
02-May-2014 |
Jason Monk <jmonk@google.com> |
Only show IME in navigation bar when it should
Add a flag to indicate that the IME should be shown. This follows
the continuous ime notification boolean, and if there are multiple
input methods to choose from enabled. This way the notification
and navigation button show up under the same circumstances (but
not on the same devices).
Change-Id: Ia6a2253061f1876f4bcc511de48c1078e9d96be5
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| e463c745ef6901121837e88ca8597d062843b9dd |
|
02-May-2014 |
Jason Monk <jmonk@google.com> |
Don't show IME Switcher not. if nav bar exists
Since the navigation bar now has IME switcher icon no need for a
notification about it when it is present.
Bug: 14257632
Change-Id: I5511fee0dee45475d5b7949f63696b1d29acf9cc
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| b7b7907fb5e4b2252b3c594a6bc4402217fe662a |
|
25-Mar-2014 |
Yohei Yukawa <yukawa@google.com> |
Allow IMEs to start/stop receiving onUpdateCursor callback
This CL introduces an API which allows IMEs to start/stop
receiving onUpdateCursor callback upon their request.
BUG: 13388665
Change-Id: I987326872def181dda5d9d701b762f088e0d9c39
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 2a764949c943681a4d25a17a0b203a0127a4a486 |
|
02-Apr-2014 |
Kenny Guy <kennyguy@google.com> |
Rename related users to profiles.
Rename the related user concept as profiles.
When returning profiles of a user include the
user as a profile of itself.
Change-Id: Id5d4f29017b7ca6844632ce643f10331ad733e1d
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 6b6b3fdbf5547417fde3ce56d9eb883963a54b58 |
|
24-Mar-2014 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #13564072: Back button no longer dismisses IME after voice usage
Calling identity wasn't being cleared in an incoming code path.
Change-Id: Ib32060a91bf81531de049fafde69835b5382a25f
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| fd7f1e00399e53a392941928ed5a55ca77b1b721 |
|
18-Mar-2014 |
John Spurlock <jspurlock@google.com> |
Unhide notification category.
Rename @hidden Notification.kind -> category, and flesh out
shared values. Now a single value.
Update framework references, remove unused SystemUpdateService
magic value unused since 2012.
Change-Id: If06d19ff3a8c3125fca1457f5d3c665e2939c66c
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| f0f94d129b6eb3c48624e915898d86d4f2de59ff |
|
18-Mar-2014 |
Dianne Hackborn <hackbod@google.com> |
Treat IME processes as hosting activities
When we stop using an IME process, we still treat that
process as if it is hosting activities (in the activity part
of the LRU list), to try to keep it around. This is intended
to help the experience of switching between IMEs, reducing
the chance of your previous IME process being killed and thus
requiring much more time to switch.
Change-Id: Ie5793fd9b40d980fa18f80246326511ed6ae0597
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 734983fff35d9ed2b7a9848bdfbca401887d0dd8 |
|
05-Mar-2014 |
Amith Yamasani <yamasani@google.com> |
Allow related users to show activities on primary user
Make ActivityManager and WindowManager understand related users.
Task stack will now contain interleaved tasks for related users,
but still group regular users separately from groups of related users.
InputMethodManagerService permits related users to invoke IME and receive
key events.
Change-Id: I3bd87b32aec69c3f8d470c8b29b144f4e849c808
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|
| 49782e46c0eb85a25ae2abcf80880c48dbab5aea |
|
20-Dec-2013 |
Amith Yamasani <yamasani@google.com> |
am 9158825f: Move some system services to separate directories
* commit '9158825f9c41869689d6b1786d7c7aa8bdd524ce':
Move some system services to separate directories
|
| 9158825f9c41869689d6b1786d7c7aa8bdd524ce |
|
22-Nov-2013 |
Amith Yamasani <yamasani@google.com> |
Move some system services to separate directories
Refactored the directory structure so that services can be optionally
excluded. This is step 1. Will be followed by another change that makes
it possible to remove services from the build.
Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85
/frameworks/base/services/core/java/com/android/server/InputMethodManagerService.java
|