9c372194f82310c4c4a09caa4d8f79868598cbb1 |
|
21-Mar-2018 |
Yohei Yukawa <yukawa@google.com> |
Make sure at least one non-aux IME is enabled Imagine the scenario where three IMEs are installed, and only the last two are enabled: IME A: * a pre-installed IME * has a subtype [mode="keyboard" && isAuxiliary=false] * disabled by user (hence not included in ENABLED_INPUT_METHODS) IME B: * a pre-installed IME * has a subtype [isAuxiliary=true] * currently enabled (included in ENABLED_INPUT_METHODS) IME X: * not a pre-installed IME * has a subtype [mode="keyboard" && isAuxiliary=false] * currently enabled (included in ENABLED_INPUT_METHODS) In this scenario, when the IME X is uninstalled, the current implementation of InputMethodManagerService (IMMS) does not try to hard reset enabled IMEs because there is still one enabled IME, even though it is an auxiliary IME. This can, however, be problematic because an auxiliary IME is just a supplemental IME and user may not be able to easily access the UI to re-enable non-auxiliary IME such as IME A. For instance, on the lock screen there is no way to manually re-enable the IME A. With this CL, every time the available IME list is updated, IMMS ensures that at least one non-auxiliary IME is enabled. If no non-auxiliary IME is enabled, then IMMS tries to pick up one from the pre-installed IME by using the same logic when choosing the default enabled IMEs for the hard-reset scenario. Bug: 71509065 Fix: 71509065 Test: atest FrameworksCoreTests:com.android.internal.inputmethod.InputMethodUtilsTest Test: Manually verified in the above scenario Change-Id: I88c69f548526b35f0e4ba37489365b2433373b04
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
cf68d52ce8f21ab85468e6bc7e977aa68b7ab32d |
|
12-Dec-2017 |
Yohei Yukawa <yukawa@google.com> |
SoftInput flag requires focused View to show IME Historically SOFT_INPUT_STATE_VISIBLE/SOFT_INPUT_STATE_ALWAYS_VISIBLE have not required focused editor View [1] to work. This is easy to use, but also easy to tell IMEs to connect to InputConnection, which is often recognized as a bug by users because often nothing happens when the user taps the software keyboard. This would become more obvious when we start allowing nothing to have focus (Bug 68841055) in Android P. Although how we should deal with "dummy InputConnection" is still an open question, ignoring these SoftInput flags for apps that target P+ when there is no focused editor view is probably better than the current behavior, where non-functional software keyboard is likely to be shown. The user is still able to show the IME by explicitly tap the edit field. As an implementation note, this CL trusts the targetSdkVersion reported from the target application process, which is in general unsafe. That said, for this particular purpose it is acceptable. [1]: focused View that returns true from View#onCheckIsTextEditor(). Bug: 69256929 Test: atest CtsInputMethodTestCases Test: atest FrameworksCoreTests:com.android.internal.inputmethod.InputMethodUtilsTest Change-Id: I56682c7dee71d461687b9e80ab746d382fd55e0c
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
89a6c48a8b2e54f9b93211c20a126edab0eefe35 |
|
21-Nov-2017 |
Tarandeep Singh <tarandeep@google.com> |
Add support for VR InputMethod. This change adds support for VR-only IMEs in InputMethod framework. In order to set this VR IME, setVrInputMethod(ComponentName) should be called by VrManager. When VrManager calls setVrInputMethod(), IMMS changes updates the selected input method in a transient way i.e. it doesn't update the Settings or input history. Once VR mode finishes, it restores last input from settings. Bug: 63037786 Test: Manually using the sample app in bug. Change-Id: I1db7981b5198e7e203d4578cae7e5b6d20037d0d
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
af5cee8d2631255d9aa3cc1ebdaef998be307164 |
|
24-Jan-2017 |
Yohei Yukawa <yukawa@google.com> |
Remove a redundant param in getDefaultEnabledImes With the previous CL [1], systemReady parameter in InputMethodUtils.getDefaultEnabledImes() is guaranteed to be true. Hence this CL removes that parameter. There should be no behavior change in this CL. [1]: I5b37c450db4b25b3e635b6d634293a34eec8b9d4 7924782c000733b2d7a180701b74988f0154adee Test: adb shell am instrument -w -e class com.android.internal.inputmethod.InputMethodUtilsTest com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner Bug: 32343335 Change-Id: Ia14d12a4e21d0e2e22bfe0bd8d496f48058c5525
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
7924782c000733b2d7a180701b74988f0154adee |
|
24-Jan-2017 |
Yohei Yukawa <yukawa@google.com> |
Delay tasks from IMMS constructor to later phase This is a preparation CL for Bug 32343335. This CL basically addresses the concern raised in a previous CL [1] that added several synchnonized blocks in the constructor of InputMethodManagerService (IMMS). After hours of code reading and investigation, it is concluded to be safe IMMS to behave as if there was no IME available until SystemService.PHASE_ACTIVITY_MANAGER_READY phase. This allows IMMS to register callbacks not in the constructor but in the later phase to addresses the concern that object references to IMMS could be leaked into different threads before IMMS object is properly constructed. As far as performance is concerned, basically the amount of tasks to be done in the main thread remains same, or could be reduced a bit if some unnecessary callback events were skipped. To confirm this, we can check the total number of the following performance metrics. - StartInputMethodManagerLifecycle - StartActivityManagerReadyPhase [1]: I9d4d3d7232c984432185c10c13fb726a6158cac8 8f202f82fd86a3b40bc5e7d62779eddff21096b1 Bug: 32343335 Test: Manual: pre-installed IME on Direct-Boot disabled device Test: Manual: pre-installed IME on Direct-Boot enabled device Test: Manual: user-installed IME on Direct-Boot enabled device Test: Manual: user-installed IME on Direct-Boot disabled device Test: Manual: user switching scenario on Direct-Boot enabled device Test: Manual: user switching scenario on Direct-Boot disabled device Test: Manual: device unlocking scenario on Direct-Boot enabled device Change-Id: I5b37c450db4b25b3e635b6d634293a34eec8b9d4
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
ccb024aa2b985ddc7f65b53191a84f1891f31cf2 |
|
14-Jun-2016 |
Yohei Yukawa <yukawa@google.com> |
Quick workaround for a performance regression in IME APIs. It turns out that the performance of InputMethodManager#getCurrentInputMethodSubtype() is regressed from ~1ms to ~20ms when - Settings.Secure.SELECTED_INPUT_METHOD_SUBTYPE == -1 and - The active IME supports many subtypes (~100) because we try to find a fallback subtype based on the system locales every time when IMM#getCurrentInputMethodSubtype() is called. This could be contributing UI janks because spell checker clients running in the UI thread indirectly depend on that method. Fortunatelly the critical path is in InputMethodUtils#getImplicitlyApplicableSubtypesLockedImpl(), which is basically a state-less method. We can easily and safely cache its result by using LocaleList and InputMethod as cache keys. With this CL the performance basically recovers to the Android M level. Bug: 28889203 Change-Id: I5ed16c7f14cc18052854f4fd6c9bae8550c332ee
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.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/core/java/com/android/internal/inputmethod/InputMethodUtils.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/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
e771d58733064508341a08cbe77512baf12997a8 |
|
17-Mar-2016 |
Yohei Yukawa <yukawa@google.com> |
Remove an unused constructor of InputMethodSettings. The last caller of the deprecated constructor of InputMethodSettings was just removed [1]. Since it is not a public API, we can now safely remove it. [1]: I09cba4066b95c4a9e89a3e4f83d75b97882502dc 143a6869476a4be5962d4bba3b222d078f46b9a0 Bug: 26279466 Change-Id: I9035c417d6a8166c0ef4e4c7a00c151ffdd5fb49
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
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/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
238faad984786f0227fe6c0cf6ea2a5ecff3a4bc |
|
11-Mar-2016 |
Yohei Yukawa <yukawa@google.com> |
Use LocaleUtils#filterByLanguage for non-keyboard subtypes. With this CL, we expand the target of Bug 27129703 and Bug 27348943 to non-keyboard subtypes. Suppose there is a handwriting IME (mode == "handwriting") that supports the following 5 subtypes. - en-US - en-GB - fr - sr-Cyrl - sr-Latn Also suppose the system languages are configured as follows. 1. sr-Latn-RS 2. ja-JP 3. fr-FR 4. en-GB 5. en-US In this case we want to enable [sr-Latn, fr, en-GB] by default when "use system language" is checked in the subtype enabler. See previous commits [1][2] about how we addressed those issues for keyboard subtypes. [1]: Iaf179d60c12b9a98b4f097e2449471c4184e049b e985c240e3feb62ea38d5b4e386be083ca0f215b [2]: I8fc774154f5175abff2f16e8f12a4847bf5f5b7c 072a95a3094af2ced4f009ad62c4553c28e3f830 Bug: 27560993 Change-Id: I416b5671602c550805ed6267dd210968aa1de83c
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
80861ff1c0b3ca2c6cdf6fb4a224f3a015bd44bd |
|
11-Mar-2016 |
Yohei Yukawa <yukawa@google.com> |
Make sure to compare subtype language with system language. This CL addresses a regression introduced by a recent CL [1] that non-keyboard subtypes are no longer implicitly enabled based on the system language (a.k.a. "use system language" in the subtype enabler) due to a type mismatch in comparison. Here is the original logic: if (language.equals(systemLanguage) && systemLocale.startsWith(locale)) And here is the logic replaced by [1]: if (locale != null && locale.equals(systemLanguage)) { The new logic is simply broken, because locale is a Locale object while systemLanguage is a String object. It never matches. With this CL we will compare the system language with the locale language again, with several test cases that should have been included in [1], as a temporary solution until we start relying on LocaleUtils#filterByLanguage() for non-keyboard subtypes. [1]: Iaf179d60c12b9a98b4f097e2449471c4184e049b e985c240e3feb62ea38d5b4e386be083ca0f215b Bug: 27560993 Change-Id: If2d1710174853180465832e6ecbbb91235b76210
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
42275bc8b32f342cad7778d28ade59eea12a983c |
|
03-Mar-2016 |
Yohei Yukawa <yukawa@google.com> |
Fix a regression in InputMethodUtils. It turns out that my previous CL [1] unexpectedly changed the behavior of InputMethodUtils#getImplicitlyApplicableSubtypesLocked() in terms of when "EnabledWhenDefaultIsNotAsciiCapable" extra value is taken into account. Suppose if an IME X has the following three subtypes: A. locale: en_US mode: handwriting extraValue: B. locale: hi mode: keyboard extraValue: C. locale: en_US mode: keyboard extraValue: AsciiCapable D. locale: zz mode: keyboard extraValue: AsciiCapable, EnabledWhenDefaultIsNotAsciiCapable Given the above subtypes, here are results of what subtypes are enabled by InputMethodUtils#getImplicitlyApplicableSubtypesLocked() I) before the CL [1] and II) after the CL [1]. - system language: hi: I: B, D II: B, D - system language: hi-IN: I: B, D II: B, D - system language: en-US I: A, C II: A, C - system language: en-GB I: A, C II: A, C - system language: ja-JP I: B II: D What my previous CL actually broke is the the last one, and it's broken because we accidentally started using "EnabledWhenDefaultIsNotAsciiCapable" even when there is no subtype that matches to the requested language. Previously that attribute was used if and only if 1) there is a subtype that matches the requested language and 2) that subtype is not marked to be AsciiCapable. If there there is no subtype that matches to the requested language, what we had relied on is actually the result of InputMethodUtils#findLastResortApplicableSubtypeLocked() called with canIgnoreLocaleAsLastResort = true, which means that we had just picked up the first keyboard subtype as the last fallback candidate regardless of it's locale. This is why the subtype B should be picked up in the last case where system language is ja-JP. This CL fixes the above unexpected behavior change regarding "EnabledWhenDefaultIsNotAsciiCapable" so that the previous behavior can be preserved. [1] Iaf179d60c12b9a98b4f097e2449471c4184e049b e985c240e3feb62ea38d5b4e386be083ca0f215b Bug: 27129703 Bug: 27425459 Change-Id: Icd86cad955bf827a1eb41255f57fdf4ec315b93b
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.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/core/java/com/android/internal/inputmethod/InputMethodUtils.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/core/java/com/android/internal/inputmethod/InputMethodUtils.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/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
8752367042cb690f78953557433c16ac77eeea45 |
|
13-Feb-2016 |
Yohei Yukawa <yukawa@google.com> |
Have unified setter/getter for Secure Settings. In order to make InputMethodManagerService encryption-aware, we are going to introduce a new state where any read/write access to Secure Settings from IMMS is virtualized so that we can temporarily enable only encryption-aware IMEs until the user unlocks the device then revert any changes made before the device enters into an unlocked state. To do that, it would be convenient if InputMethodUtils has unified getter/setter methods to access (Secure) settings. In subsequent CLs we will rely on those getter/setter methods to switch between the on-memory data store and the actual Secure Settings. Note that because of multi-user support such a switch can occur multiple times. This is still a preparation code. Behavior change is not intended yet in this CL. Bug: 26279466 Change-Id: I0f79243e5cc1556764da37fa38078e075a27d42b
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
622b44d00fdbddf6717fd8bc9515111fec71115b |
|
11-Feb-2016 |
Yohei Yukawa <yukawa@google.com> |
Use Java7 diamond operator in InputMethodUtils. This CL changes nothing except for deleting redundant type parameters by using diamond operator. No behavior change is intended. Bug: 26279466 Change-Id: I276c7eb0136d373464ba6e997685d440beaca674
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
0eae0eb5a6bc11ca0f3e24f815d11a27fb08a398 |
|
03-Dec-2015 |
Yohei Yukawa <yukawa@google.com> |
Merge "Fix special handling of a fake language code "tl"." am: 9fd2af6b32 am: 30e321b54a am: d42df4f68e * commit 'd42df4f68e16bc3800d4d944caddbcbe79986fe8': Fix special handling of a fake language code "tl".
|
ed65bc0c62ca99a118057db7ad54c4ccc14d52d0 |
|
03-Dec-2015 |
Yohei Yukawa <yukawa@google.com> |
Fix special handling of a fake language code "tl". My previous CL 92280cd309b0f5967dd253280962d8581844db89 [1] had a silly mistake that "tl" is converted to "fil" but "tl_PH" is not. [1] I94f203bddceb9c87710cb187cc3cc0ee6d9092a5 With this CL, the compatibility rewrite-rule from "tl" to "fil" starts working regardless of the existence of countly/variant subtags in locale string. So far the only affected platfrom is API Level 23. Bug: 20696126 Change-Id: Ica9cd2baac002c406f92331aadd7725d7424046a
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
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/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
c8e6c7996f440655a5b2338faab358adc6d66435 |
|
17-Aug-2015 |
Seigo Nonaka <nona@google.com> |
Merge "Remove duplicate separator definition."
|
ce2c7849a0d73cc9eee22237024e52ec64b97201 |
|
17-Aug-2015 |
Seigo Nonaka <nona@google.com> |
Remove duplicate separator definition. INPUT_METHOD_SEPARATOR and INPUT_METHOD_SUBTYPE_SEPARATOR are defined in both InputMethodUtils and InputMethodSettings with same value. This CL removes definitions in InputMethodSettings and use SEPARATOR instead of SEPARATER. INPUT_METHOD_SEPARATOR and INPUT_METHOD_SUBTYPE_SEPARATOR in InputMethodUtils are originally introduced to IMMS by If0104151b3526da6ecc669adde3119a239ecafeb and they are moved to InputMethodUtils by I01f5fafbbcfe3e3f5313829162ec011eaf2ad991. INPUT_METHOD_SEPARATER and INPUT_METHOD_SUBTYPE_SEPARATER in InputMethodSettings are originally introducced to IMMS as a part of IMMS.InputMethodSettings by Icd0f13de396ce286ff6563e8c2775d53bcdacbf3 and InputMethodSettings is moved to InputMethodSettings by I0bc9954f163a3ec38d08b9ba842a8a31176eb6a6 Bug: 22285167 Change-Id: I3601c10902b44bb639581e3b816a3fc0a4851957
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.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/core/java/com/android/internal/inputmethod/InputMethodUtils.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/core/java/com/android/internal/inputmethod/InputMethodUtils.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/core/java/com/android/internal/inputmethod/InputMethodUtils.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/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
174843afb629c57af19e14ee3ec4a91358061dd9 |
|
27-Jun-2015 |
Yohei Yukawa <yukawa@google.com> |
Check system locale when picking up an initial SpellChecker. Since Ia25e7b4f308778891929e31b8cbd741f6848cce4, the TSMS has picked up the first found spell checker no matter regardless of the system locale. The primary goal of this CL is to introduce a low-risk fix for the situation where two or more spell checker services are pre-installed but they are well different from each other in terms of supported languages. Solving the problem in more ambiguous and complicated situation is beyond the goal of this CL. With this CL, we still pick up the first found spell checker but also require the spell checker supports a certain locale. We will try several locales starting with the system locale to some fallback locales until we find one appropriate spell checker. If no spell checker is picked up in this process, we simply pick up the first one as we have done. Examples about what locales will be checked are: A. System locale: en_US 1. en_US 2. en_GB 3. en B. System locale: en 1. en 2. en_US 3. en_GB C. System locale: en_IN 1. en_IN 2. en_US 3. en_GB 4. en D. System locale: ja_JP 1. ja_JP 2. ja 3. en_US 4. en_GB 5. en E. System locale: fil_PH 1. fil_PH 2. fil 3. en_US 4. en_GB 5. en F. System locale: th_TH_TH 1. th_TH_TH 2. th_TH 3. th 4. en_US 5. en_GB 6. en Bug: 22042994 Change-Id: I094f1c33430f7904a1dac6167431d6df64a07212
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
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/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
92280cd309b0f5967dd253280962d8581844db89 |
|
03-Jun-2015 |
Yohei Yukawa <yukawa@google.com> |
Convert subtypes whose locale is "tl" to "fil". On Android, "tl" is a historic hack for what should really be "fil". Now that we properly support 3-letter language codes, we should be using "fil" throughout. Given this historical usage, IMEs that really want to support Tagalog (and not Filipino) should use the ISO-639-3 code for Tagalog, which is "tgl". For backward compatibility reasons, this CL uses the similar approach to I26e3aa0333aa3c76c80a3c1c9090cc2b368c8e10. InputMethodSubtype.getLocale() continues to return the "locale" string parameter passed to the constructor as is, but in the Android framework we do normalizations/conversions whenever we need a valid ISO-639-3 code. In I26e3aa0333aa3c76c80a3c1c9090cc2b368c8e10, we rely on the conversion in the Locale constructor. In this CL, we do replace "tl" with "fil" by ourselves. This CL also adds InputMethodSubtype#getLocaleObject() a hidden API so that we can start relying on the Locale object at least in the framework. This CL is based on the investigation by Narayan Kamath and his patch. Bug: 20696126 Change-Id: I94f203bddceb9c87710cb187cc3cc0ee6d9092a5
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.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/core/java/com/android/internal/inputmethod/InputMethodUtils.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/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
9c83ff471d482adabb8058dbd2a80c1e520765c8 |
|
12-Mar-2015 |
Yohei Yukawa <yukawa@google.com> |
Expose isSystemImeThatHasSubtypeOf to Settings 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 In the avobe CLs, an internal (hidden) method InputMethodUtils.isValidSystemDefaultIme was marked as deprecated and we decided to migrate to InputMethodUtils.isSystemImeThatHasSubtypeOf. To finish this refactoring, this CL make the new method visible to the settings app. InputMethodUtils.isValidSystemDefaultIme remains to be an internal method. No behavior change is intended. Change-Id: I8cb9ca40d15af099c3d1ded46797fb57f14fb9e8
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
f487e0e395a4e49f28c6448339d57357667756c6 |
|
20-Feb-2015 |
Yohei Yukawa <yukawa@google.com> |
Normalize deprecated 2-letter language code when necessary. This is a follow up CL for I7d932e60311b80c05be8f02c9e803f18da0e0054, which revealed that we could not use deprecated 2-letter code like "in" to query subtype which has new language codes like "id". This CL addresses the above issue by normalizing the language code with Locale#Locale(String, String) before comparing one to another. Change-Id: I26e3aa0333aa3c76c80a3c1c9090cc2b368c8e10
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
e72d1c82743c4d573e529d4da3866c1fcea35c77 |
|
20-Feb-2015 |
Yohei Yukawa <yukawa@google.com> |
Add tests for Ibb9eb9f65323795d139 and I6571d464a46453934f0 This CL adds several unit tests for following CLs, both of which enabled InputMethodUtils (and dependent IMF logic) to handle 3 letter language codes and conversion from deprecated two-letter codes to new ones correctly. - Ibb9eb9f65323795d139b16d76b7e7e36a4e0568c - I6571d464a46453934f0a8f5e79018a67a9a3c845 As described in tests, the input method framework has already been able to recognize 3 letter language codes. However, there remain inconsistencies when we use deprecated 2-letter code to query subtype like "in" but the subtype has new language codes like "id". Subsequent CLs are supposed to address remaining issues. bug: 10090157 Change-Id: I7d932e60311b80c05be8f02c9e803f18da0e0054
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
b21220efae92a56ff7b4b781fa614a6e3a8a3007 |
|
01-Nov-2014 |
Yohei Yukawa <yukawa@google.com> |
Minimize the number of default enabled IMEs part 4 This is a follow up CL for recent attempt to minimize the number of default enabled IMEs. - part1: I831502db502f4073c9c2f50ce7705a4e45e2e1e3 - part2: Ife93d909fb8a24471c425c903e2b7048826e17a3 - part3: I6571d464a46453934f0a8f5e79018a67a9a3c845 It turned out that the changes made in part2 and part3 are a bit overkill, and users will see no software keyboards in some particular situations. The problem we missed in the previous CLs is the fact that InputMethodInfo#isDefault is indeed a locale-dependent value, hence it may vary depending on the system locale. Existing unittests also failed to abstract such locale-dependent nature. In order to addresses that regression, the selection logic is a bit widely reorganized in this CL. Now the logic is implemented as a series of fallback rules. Also, unit tests are updated to be able to 1) test the order of the enabled IMEs, and 2) emulate the locale-dependent behavior of InputMethodInfo#isDefault to enrich test cases. BUG: 17347871 BUG: 18192576 Change-Id: I871ccda787eb0f1099ba3574356c1da4b33681f3
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.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/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
dc489241cfb3691a87942344cf55efd3d98c1107 |
|
13-Sep-2014 |
Yohei Yukawa <yukawa@google.com> |
Minimize the number of default enabled IMEs part 3 With this CL, the behavior of getDefaultEnabledImes() changes as follows: - Previously system IMEs are always enabled by default as long as it is a software keyboard that supports En_* subtype. With this CL, getDefaultEnabledImes() relies on the locale returned from getFallbackLocaleForDefaultIme() instead of calling isSystemImeThatHasEnglishKeyboardSubtype() to minimize the number of enabled IMEs. - Previously default enabled system IMEs are chosen in a country-agnostic way. As a result, "en_IN" is enabled even when the system locale is "en_US". With this CL, the system first tries to find IMEs with taking the coutnry into account, and use the country-agnostic way when and only when fallback logic is required. BUG: 17347871 Change-Id: I6571d464a46453934f0a8f5e79018a67a9a3c845
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
68c860bb29861e54fd9b868bd5af701b054a1dc0 |
|
13-Sep-2014 |
Yohei Yukawa <yukawa@google.com> |
Minimize the number of default enabled IMEs part 2 Previously the system tried to enable at least one auxiliary IME even when the system is not ready. However, this doesn't make much sense because the user should be able to set up their phone without auxiliary IMEs. Also, IMEs enabled before the system becomes ready are kept to be enabled after the system becomes ready. Thus, we should minimize the number of enabled IMEs until the system becomes ready. BUG: 17347871 Change-Id: Ife93d909fb8a24471c425c903e2b7048826e17a3
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
5e5c60a43a93a0b5f16680042f2fecf6e0ecd0d7 |
|
12-Sep-2014 |
Yohei Yukawa <yukawa@google.com> |
Minimize the number of default enabled IMEs part 1 Basically this CL does following clean-ups as groundwork. - Embed isDefaultEnabledIme into its only one caller - Fix a typo in isSystemAuxilialyImeThatHashAutomaticSubtype() - Use exit-early style in getMostApplicableDefaultIME() No behavior change is intended by this CL. BUG: 17347871 Change-Id: I831502db502f4073c9c2f50ce7705a4e45e2e1e3
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.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/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
77cbcb6637e3733e9b80a93d37745f27ec4d4561 |
|
12-Jul-2014 |
Tadashi G. Takaoka <takaoka@google.com> |
Make InputMethodUtils.getLanguageFromLocaleString public Change-Id: I3e26eded21e59106a3b0edcf9ad05afbe9a30670
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
4d8c132609c9a87d8e05cba65bf6832b38afd1ff |
|
11-Jul-2014 |
Narayan Kamath <narayan@google.com> |
Allow 3 letter language codes in InputMethodUtils. Replace locale.substring(0, 2) with a function that always returns the first component of the locale (assumed to be the language). bug: 10090157 Change-Id: Ibb9eb9f65323795d139b16d76b7e7e36a4e0568c
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
f4824a06884e096beef921646cba4be29d7f36fc |
|
02-Apr-2014 |
Kenny Guy <kennyguy@google.com> |
Fix issue with not allowing activities for current user. Change-Id: Ic2e30c3f4990a03aac9801ee9bf5f270a5e90ef8
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.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/core/java/com/android/internal/inputmethod/InputMethodUtils.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/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
d787f6953371c4520bd51d6bf8eccc59f1d0f945 |
|
25-Oct-2013 |
Satoshi Kataoka <satok@google.com> |
Refactor InputMethodAndSubtypeCircularList Change-Id: I452bb01d4af7097d214f2c2e7ed58bf1ca9fa219
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
7ce7f32257a1e49493d38b96f503069226e98c9a |
|
05-Aug-2013 |
Satoshi Kataoka <satok@google.com> |
Open an internal utility of InputMethodUtils Change-Id: I240e914bc21efce8554145619c403d547a17ad19
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
87c291421544821fe9d10a08ee4e9f31b62d5052 |
|
31-Jul-2013 |
Satoshi Kataoka <satok@google.com> |
Add a debug utility for InputMethodUtils Change-Id: I59f6001bf20640e36e19b09cf117b8579120ba7d
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
0766eb045c0e2ecbc4317743b025618654ddea38 |
|
31-Jul-2013 |
Satoshi Kataoka <satok@google.com> |
Small refactor on InputMethodUtils Change-Id: Ie4f797508c02abb13c7fe1be162ec4dc18829925
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
eb219ee190b4ceb662b81a93e6d4369bcd5e7dc0 |
|
29-Jul-2013 |
Satoshi Kataoka <satok@google.com> |
Change visibility of the hidden input method utility Change-Id: I66303bc9e056388fef8cc884d7d98b0660ccdd15
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
b282726d8604dad3ac06e9d8bf167f19332a05d7 |
|
04-Jul-2013 |
Satoshi Kataoka <satok@google.com> |
Consolidate InputMethodUtils Change-Id: Ib5a5f3af8ea9eaaa81697d13c20abe28121e7373
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
ed1cdb24ba986231629fbfb244ed758fc2add0fc |
|
17-Apr-2013 |
Satoshi Kataoka <satok@google.com> |
Change the initial disabled state of disabled IMEs Bug: 8365223 This change is a supplement for I77f01c70610d82ce9070d4a The disabled state of disabled pre-installed imes should be changed to ENABLED_STATE_DISABLED_UNTIL_USED on boot or user switch. Change-Id: If8ff1b2b95c36d33148def2ab87bd006aa520cc0
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
f1367b7e903a2a69a8f833bb272e91d77abd57c6 |
|
25-Jan-2013 |
Satoshi Kataoka <satok@google.com> |
Do not turn on imes unexpectedly with unit tests Bug: 7872918 Change-Id: Ie1d74c9fac27de140e7aa85f2eaefcb89aa06ea7
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
fd7adedebf88427162a3ce27fcc9cfd3893c869d |
|
23-Jan-2013 |
Dianne Hackborn <hackbod@google.com> |
Add new disabled state for "optional" built-in apps. The disabled state allows you to make an app disabled except for whatever parts of the system still want to provide access to them and automatically enable them if the user want to use it. Currently the input method manager service is the only part of the system that supports this, so you can put an IME in this state and it will generally look disabled but still be available in the IME list and once selected switched to the enabled state. Change-Id: I77f01c70610d82ce9070d4aabbadec8ae2cff2a3
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|
8e303cc5dd4860b6050d5725ce60ca7e6fb00c7b |
|
11-Jan-2013 |
Satoshi Kataoka <satok@google.com> |
Refactor utilities for InputMethodManagerSerivce that we want to share with the Settings application Bug: 7872918 Change-Id: I0bc9954f163a3ec38d08b9ba842a8a31176eb6a6
/frameworks/base/core/java/com/android/internal/inputmethod/InputMethodUtils.java
|