Serbian-Latin is one of subtypes that our APIs could not easily deal
with their locale.
Now we can safely rely on BCP 47 language tag hence we should do. See
my previous CLs [1][2][3] for details.
Note that this CL is supposed to have no effect on the behavior of
LatinIME because we internall remap "sr-Latn" to "sr_ZZ" [4].
[1]: I77db5b99a7cf745d800db75baf135bb60ad04820
8d6eeb01df72891acd3aa75e64aa1595a41cc96e
[2]: I251d3d999afd13c0d618f2cb59e8ed3d47f21c98
b8456a6a483ce62c81b92f613561fb761be0f3e8
[3]: I37cb9ce196f2e23589e60ce34475504405778bbb
f6997344e6
[4]: I93ff0c75b3687bb1b913f451b9eb5f2820beefbc
31a3f07c21
Bug: 27348943
Change-Id: Icd0667c40c6f1310699f3deb1234b7861ec2fa24
We want to expose Serbian (Latin) layout as "sr-Latn" to the system,
while our internal logic may not be ready to deal with "sr-Latn" yet.
As a temporary workaround, we remap "sr-Latn" into "sr_ZZ" for our
internal use.
Bug: 27348943
Change-Id: I93ff0c75b3687bb1b913f451b9eb5f2820beefbc
This reverts commit 3e2670265e.
It turns out that the behavior change in libcore was unintentional, and
it was already fixed [1]. Let's revert our workaround back to see if
the existing code is compatible with N.
[1]: Ibacb192abc37870c74a2500d65b94d68f9c2318e
5e7b572c2b494ab86ddd2baca3883a40a6064c1e
Bug: 26239281
Change-Id: I6cd2340492d93251231e7ee37c3d4f82c1721293
This is a follow up CL to the previous CL [1], in which we started
calling Window#setNavigationBarColor(int) when the window visibility is
changed.
One thing we missed is that calling Window#setNavigationBarColor(int) on
KitKant or prior devices would result in a runtime crash. Hence with
this CL we do not call that method unless the OS version is N or leter,
because specifying Color.TRANSPARENT would make sense on N+ devices.
[1]: I14d9490e00caa852035a05830e76114cbe6af8f2
6c04339c5a
Bug: 22564251
Bug: 27302540
Change-Id: Ib7299dd8c3dad4271f8fac453e690c83bda4a954
This follows up to a recent CL [1] that removed #getPrimary() method
from LocaleList class.
[1] I75f77aea6b75e38793ed8477e5e5a4420d5e6d85
fee44846376c212114223fc4259382921e6dca7a
Bug: 26984092
Change-Id: Ied4678d35c4dcb380ce24e9bce9336dbbf6c16b8
With this CL, LatinIME switches the current subtype from its enabled
subtypes based on the first locale in EditorInfo#hintLocales.
This functionality is still experimental, and will be triggered only
when EditorInfo#hintLocales is specified by the application.
Bug: 22859862
Change-Id: Ibd0559b370d8aa0d50d1bada8ecfdac0ed8db898
This CL updates LatinIME's compatibility library so that we can access
EditorInfo#hintLocales without directly depending on unreleased SDK.
Bug: 22859862
Change-Id: I4ba7d294bc314002c3abf8842f097a4249783364
With this CL, RichInputMethodSubtype#getLocale() starts returning
a Locale object that is initialized with "languageTag" when it is
specified. No behavior change is intended when "languageTag" attribute
is not available or specified.
Bug: 22858221
Change-Id: I23f2e479b8e284ce589c6950b071ba84c5dd8ce1
With previous CLs [1][2], now we can associate a BCP 47 language tag for
each InputMethodSubtype in XML resource file by "languageTag" attribute.
In order to test that the functionality, we start using "languageTag"
for some subtypes.
Note that specifying "languageTag" for all the existing subtypes is
beyond the goal of this CL, which should be handled in subsequent CLs.
Here is the list of subtypes that start having "languageTag" attribute.
- android:imeSubtypeLocale="en_US" -> android:languageTag="en-US"
- android:imeSubtypeLocale="en_GB" -> android:languageTag="en-GB"
- android:imeSubtypeLocale="fr " -> android:languageTag="fr"
- android:imeSubtypeLocale="fr_CA" -> android:languageTag="fr-CA"
- android:imeSubtypeLocale="fr_CH" -> android:languageTag="fr-CH"
- android:imeSubtypeLocale="tl" -> android:languageTag="fil"
[1]: I77db5b99a7cf745d800db75baf135bb60ad04820
8d6eeb01df72891acd3aa75e64aa1595a41cc96e
[2]: I251d3d999afd13c0d618f2cb59e8ed3d47f21c98
b8456a6a483ce62c81b92f613561fb761be0f3e8
Bug: 22858221
Change-Id: I37cb9ce196f2e23589e60ce34475504405778bbb
Starting in N, we are going to have new APIs to officially support the
situation where apps need to run before the user has unlocked their
device for the first time. For IME developers those APIs would be
important not only because IMEs developers may want to support other
apps that support that feature but also because IMEs developers have
already needed to pay attention to the same situation where the IME is
running so that the user can enter the initial password (e.g. for an
encrypted device).
Bug 11270326 is a perfect example of this scenario. Now we can disable
settings-key until the device is unlocked by using the new API when
running in Android N devices.
Bug: 11270326
Change-Id: Ie1c6efa63b60b91430f1a78dde624d0f3dff3c69
