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
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
6c04339c5aadb5118b0e0a8178b3d569956bbad7
Bug: 22564251
Bug: 27302540
Change-Id: Ib7299dd8c3dad4271f8fac453e690c83bda4a954
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
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
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)
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)
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
When the DEBUG setting is on, log from this critical class.
This will make it easier to diagnose issues.
Bug 19632709.
Change-Id: I5e14b3705f50cd021ad3d64af106ad28dc8b9321
When the LatinIME does not have an active InputConnection, it will not try
to toggle the Emoji keyboard.
Bug 19513415.
Change-Id: I31f928cd7db1cddd771c548cd3dc42f8af64d0e2
Simplify interfaces by passing Keyboard instead of
KeyboardLayout and ProximityInfo directly. Also require
the Keyboard passed be non-null and change the SpellChecker
to bail out if there is no keyboard for the locale.
Change-Id: I960f15ff60171f55d3e0a96fd6469b7dc3a045e2
Removes the feature that adds strings to the user dictionary,
aka the "green highlight with a plus sign".
Bug 19237189.
Change-Id: I2387129a3add2d69d625f2ff16ed8cab3f10a735
implementation DictionaryFacilitatorImpl.java and add a java-overridable
factory DictionaryFacilitatorProvider.java used to create a
DictionaryFacilitator.
Change-Id: Id4a58ae31feaa4d12a048a772c8d76ff82fdee45
Attempt to use dictionary facilitor without invoking
preference manager. Instead use account from settings only when
things are being reset/changed. Discussion forked from ag/591663
Overall, the idea here is to maintain an account information
inside dictionary groups. Reset the dictionary groups if
account changes (the way we do for locale). Since only user
history dictionary is currently affected, the check to reset user
history dictionary also includes the check to verify the account.
For other things remain the same.
SettingsValues holds the current account (and is updated if prefs change
due to change in account settings). The updated settings are then
propagated to dictionary facilitator via LatinIME#loadSettings.
Bug:18104749,18469539
Change-Id: I553e776e7ea125d0fb7a1fe70a4c7eb0b2277fb8
