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
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
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
The opaque navigation bar guard view does not make much sense when the
IME does not show software keyboard at all. LatinIME does not show
any UI when the hardware keyboard is connected.
With Iea77915ecc55eedaf19899e72c44f704ba9d852c, input method can change
the navigation bar visibility. This CL changes navigation bar invisible
when the hardware keyboard is connected.
Bug:22564251
Change-Id: I14d9490e00caa852035a05830e76114cbe6af8f2
When upgrading to a new version of APK we may find that the stored Emoji
category ID is no longer applicable. For example it happened when we
brought in the new Unicode 8.0 Emojis.
Also restore the "Symbols" emoji category on pre-kitkat devices which
was accidentally dropped when bringing in Unicode 8.0 Emojis.
b/25972978
Change-Id: I91c044603b0aac8757cb8597d3af995f84b822f3
Change the way we decide whether we want to show on-screen keyboard by
not only paying attention to modifiers, but also keeping track whether
the key sequence started in the right state.
We are still misfiring if user presses a non-modifier key and then our
modifier hot-key, but such sequence is unlikely. Given the fact that we
do not want to store too much state I believe this deficiency is
acceptable.
Bug: 25087681
Bug: 24142161
Change-Id: I1a6b5e8e903c27a87134a6c9a7cd474a0607d5c8
(cherry picked from commit 7c513455918a52bd28c1c8181cb2880db0973b4b)
If user has not used emojis we should not bring recents emoji tab on the
first invocation of the on-screen keyboard as it is confusing to see an
empty tab.
We will still be showing recents tab even if it is empty if user
actively switched to it when using on-screen keyboard.
Bug: 24497650
Change-Id: I68b4bf64441590858d246168cc4733a2875a1357
(cherry picked from commit 24d67eba27cb23c0d3aca44236247ec12380daa5)
Out of the box, we want Alt-Left to toggle Emojis, while Alt-Right
toggles the shifted symbols layout.
Bug: 23954008
Bug: 24369173
Change-Id: I93dd66fb469e5d0a831359ff3a786fe68e1d73ea
(cherry picked from commit 411841b374aa04e333ea5a438dfd539f49ec589a)
Check to see if setup wizard is running before showing toast to
inform user that a download was started. Note that this will only
affect the device owner; when adding new users later, the toast
will still appear. (The USER_SETUP_COMPLETE flag is hidden from
the SDK, while DEVICE_PROVISIONED remains available.)
Bug: 22594336
Change-Id: I57c42d6f821714b71cbb066e82bba2a1dbab4951
This build has been compiled against API 23
This build is approved to go out with the M OTA, but may NOT be released
to the public until the Play Store has enabled API level 23 apps
Version: 4.1.2300x.build_id
1. Disable the settings.
2. Disable the feature.
3. Force reload the facilitator.
Bug: 22564048
Change-Id: Ic09742786c3e4efc034bceee836ae6a1e07307a1
(cherry picked from commit 031d04192080f0368f21c3371d1ec6af87375357)
This build has been compiled against API 23
This build is approved to go out with the M OTA, but may NOT be released
to the public until the Play Store has enabled API level 23 apps
Version: 4.1.2300x.build_id
1. Replaces the personalization is on information with the suggest
contacts.
2. Enables "Use Contacts" only if the app has permission to read
contacts.
3. Disables the contacts dictionary in the Facilitator.
4. Do not register/read the contacts in the contact observer.
Bug: 22236416
Change-Id: I9674e13d0d0f4a2014c5024fde0178de684c07e7
FileUtils is being used for other non android projects
and hence breaks when built. Instead use the log statements
at caller to record Log.e messages. Hence there is no side
effect here.
Bug:22042371
Change-Id: Ieb100006ff38e013bc30542637465f58bfc0f2f2
This will ensure that a new (or upgraded) keyboard instance will know which
dictionaries are available for download so it requests missing dictionaries.
In addition, we increment the database version number to ensure upgrades of
existing Fava instances start with a clean slate.
Bug 22069694.
Change-Id: Id71310412682543a3931f9c5c03cb0369fa7b9ac
The initial reloadTextCache() operation needs to read 1k characters, and it
could be slow on low-end devices. Also, the initial load is not blocking key
strokes, so it can take a little longer.
Bug 22062102.
Change-Id: I134424e8910c0d6131c311a862bdc87eccd3af44
1. Add mechanism to detect a slow or non-resonsive InputConnection (IC)
2. When IC slowness is detected, skip certain IC calls that are known
to be expensive (e.g., getTextAfterCursor).
3. Similarly, disables learning / unlearning on a slow IC.
4. IC slowness flag is reset when starting input on a new TextView or
when a fixed amount of time has passed.
Note: These are mostly temporary workarounds. The permanent solution is
to refactor RichInputConnection so that it is less sensitive to IC
slowness in general.
Bug: 21926256
Change-Id: I383fab0516d3f3a8e0f71e5d760a8336a7730f7c
Users rarely tap on committed words, and the cost of sending the spans back
through the input connection, back and forth to the target app, is too high.
Bug 21926256.
Change-Id: I8e55b57ce2148ed313dc927425b6d9c958634958
This is causing issues we can't deal with in a safe and timely manner.
Furthermore, users who need downloaded dictionaries already have them by now.
Bug 21797386.
Change-Id: I97e5fd84edcf2b16f04db57b7ae4a13fa9ce993f
We never delete text after the cursor, so constrain the API accordingly.
Define the number of characters to read before and after.
Set them to reasonable values.
The next CL will start caching text after the cursor.
Bug 21926256.
Change-Id: Idd58daf68614de4a69344aa3c8a4323720c5d3a0
Yohei Yukawa
Keisuke Kuroyanagi
David Riley
Seigo Nonaka
Dmitry Torokhov
Chieu Nguyen
Ian Pedowitz
Dan Zivkovic
Russell Brenner
Mohammadinamul Sheik
Jatin Matani
Tom Ouyang