OSDN Git Service

Fix a regression in InputMethodUtils.
authorYohei Yukawa <yukawa@google.com>
Thu, 3 Mar 2016 08:34:27 +0000 (00:34 -0800)
committerYohei Yukawa <yukawa@google.com>
Thu, 3 Mar 2016 09:05:11 +0000 (09:05 +0000)
commit42275bc8b32f342cad7778d28ade59eea12a983c
tree6fbac4ba5710383d7f2da5775f663b4da657e5d8
parent25b86cca0f97b644379a311769632ebb18c6f8fe
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
core/java/com/android/internal/inputmethod/InputMethodUtils.java
core/tests/coretests/src/com/android/internal/inputmethod/InputMethodUtilsTest.java