IME is called back four methods for each input field as a IME life
cycle. The four methods are onStartInput, onStartInputView,
onFinishInputView and onFinishInput.
After orientation changed, Those quartet methods will be called back
twice. This behavior of the framework might be a bug.
In order to restore the previous keyboard layout, we should skip
onFinishInputView and onFinishInput of the first quartet and
onStartInput and onStartInputView of the second quartet.
Bug: 4311428
Change-Id: I450ddc0cce5d00abc971ffd42a507a8a86682548
CL https://android-git.corp.google.com/g/#/c/136474 refactored
the fullscreen test, but ithe IME_FLAG_NO_EXTRACT_UI test was
lost in the process.
Note that there is still a problem (orthogonal to that change
with key_preview_backing, which appears opaque and black sometimes.
I'll re-open 5315001.
Change-Id: If3a73179d21eaca10bdc948db7bac4b4f7a88d34
This change also separates controlling visibility of "key preview
backing view" from suggestions strip visibility.
Bug: 5315001
Change-Id: I190a71f7956c804e5d89d2d5bacecc62d565ac2c
The locale is specified by KeyboardLocale extra key in method.xml,
LatinIME will use the specified locale for keyboard layout.
Bug: 5238658
Change-Id: I8e6cb66c73a7ac1bf611d9910b42fa9cff38eba0
This change also introduces "AsciiCapable" extra value for subtype
that indicates the subtype can input any ASCII code point from its
keyboard layout.
Only if the input field has "forceAscii" private IME option and the
current subtype doesn't have "AsciiCapable" extra value, the en_US
keyboard layout will be used for the input field.
Bug: 3384942
Change-Id: I25e2553e37ecb5002df1164e45f6273845fe463b
A recent change had the contacts reloaded every time a new field
is touched. This change not only fixes the problem, but also removes
reloading contacts when changing language, which should make language
switch within LatinIME lighter.
Bug: 5125034
Change-Id: Ia61c4f75a8617113cdce88a2e2c6fdf073146a2d
This does not really fix the underlying bug, but it does fix
the apparent symptoms.
When the user presses space and a letter quick, the
onUpdateSelection handler may be called after the letter has been
actually committed. The keyboard then happily proceeds to clearing
the composition because it thinks space was pressed (or the user
moved the cursor, since it can't guess which happened).
This change removes this behavior when we are expecting an update
event from a keypress. This means the bug still exists if the user
presses space twice and a letter, and all events come after the
letter, but it is very very hard to reproduce this. There may be
other collateral damage when the user moves the cursor in the form
of race conditions, but likewise, they should be really hard to
reproduce.
Bug: 5100521
Change-Id: Ib05328c9b451bf6fe288ae00296fd283a9a4e863
The "deleteChar" argument of this method is acutally always true in the current code path.
Also, in this method, textToTheLeft virtually never has a punctuation letter as its initial
character. This change is one of preparatory changes for bug:4983945.
Change-Id: I531a32570a35634c21c1d74b2b461e40a1b7f660
