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
e985c240e3
Bug: 27129703
Bug: 27425459
Change-Id: Icd86cad955bf827a1eb41255f57fdf4ec315b93b
There was previously no public API for clearing the keyguard wallpaper
versus the system wallpaper, or both. Now there is.
Bug 27400185
Change-Id: If1789dd430040acdf16d77413c0e4b46bf3789f3
It allows badging an image regardless of of the user (no
user id parameter). The styling for managed users is applied.
This is useful for new cases where the existing functions
wouldn't badge the icon, but we need it.
Bug: 25192539
Change-Id: I2fd2f226f626fb2e6cda1cfe072013350e12b41c
May also return true if the keypair didn't exist in the first place
which is a small reduction in the amount of information leakage, but
more importantly lets a caller be sure about keystore state at the end
of their call.
Bug: 27335182
Change-Id: I5e6d4c599b74f031e3f6d17cb7540898ffaf2571
Devices that have the config set to false will not allow any multi-window
operation.
Also, added ActivityManager.supportsMultiWindow that checks the new config
and also returns false if the device is a low RAM device.
Bug: 27419483
Change-Id: I8dd85c17d290a5a752de3253beb3b34c17d7736d
am: 1856df512f
* commit '1856df512fc3d69096505491512fa26fb8ffdc09':
Speed up ConnectivityServiceTest.
Make it easier to test code that uses WakeupMessage.
Code that uses WakeupMessage uses the AlarmManager. Testing such
code is slow because AlarmManager.MIN_FUTURITY ensures that
alarms must wait at least 5 seconds before firing.
This change makes WakeupMessage's fields protected so that test
code can subclass from it and override schedule() and cancel()
with implementations that do not use AlarmManager, for example
by making schedule() call sendEmptyMessageDelayed and making
cancel() call removeMessages.
Change-Id: I51096b182d9eb87cc7bd46c3c91906f18356b354
am: b7ffb76437
* commit 'b7ffb764370805aa0734d2f31bc2def34df04d86':
Move PinningNetworkCallback out to a new NetworkPinner class.
Use MessageUtils in ConnectivityManager.
