In order to avoid layering violation, LocaleList needs to be moved from
android.util package to android.os package [1]. This CL follows up that
package change.
No behavior change is intended.
[1]: Ia8de2ee9df3dd0a42b1fe84574439519b680fe18
Bug: 28819696
Change-Id: Ie795c191e299358c7c463693823f309ce61cc985
LatinIME checks hardware keyboard presence and software keyboard
visibility to decide whether to start full screen mode.
This doesn't work well with the recent update on "Show input method"
(Bug: 22517687, Id4d332e3909590c68345e).
On the first tap, software keyboard is not shown and hardware keyboard
is connected; so full screen mode is not started. However,
onEvaluateInputViewShown may return true ant software keyboard may be
brought up.
In this care, on the second tap, software keyboard is visible so full
screen mode will be started regardless of hardware keyboard presence.
This CL checks onEvaluateInputViewShown to decide whether to start
full screen mode.
Bug: 27234709
Change-Id: I587262cc36e5fccc59620b4bd2d2c3c05c72232f
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
