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
Because "TRHEE DOT LEADER" glyph of Roboto font is broken, we decide
to use "..." instead.
Bug: 5344295
Change-Id: I0fa5eefc00baf80747ff5215c018619a7e15a58e
This change also separates controlling visibility of "key preview
backing view" from suggestions strip visibility.
Bug: 5315001
Change-Id: I190a71f7956c804e5d89d2d5bacecc62d565ac2c
This is a follow up change of If6c0edef.
This is a cherry-pick of Idb415f53 from Master.
Bug: 5328922
Change-Id: I36d8bda9fb95e4809598296226c598a9f08bd8bb
This should not be used lightly, as it violates the general
contract of locale, and does kill some legitimate (albeit
alledgedly rare) use patterns.
Currently, the spell checker uses this because it uses a
negative logic: it should match broadly, and when in doubt,
match even more broadly, which is almost never the case of
something that uses the locale.
In other words: don't use this option unless you are
very, VERY sure that's what you want. Hint: it isn't
Bug: 5280929
Change-Id: Ib3cae319c692161d653630038c5bcde1f4340c05
There is no definite path known for this to end up being
touched by other classes, but we could imagine through
some way or some other it ends up shoved in the stringbuilder
pool, leading to catastrophic results.
Hopefully related to
Bug: 5248688
Change-Id: Ib8abfc31263cbf31d515ed607ced5d8253971938
If the spellchecker encounters a bug and happens to crash,
it may be sensible to avoid killing the keyboard in response.
This is a possible way to do it, which comes with the big
drawback of making bugs in the spell checker harder to find.
Change-Id: Idb26fb592b9718e1dbdadeda8fbd1a8a1d805c28
Note that this affects only the results of the spell checker if
actually passed such a word. For example, the spell checker will
not flag "http://oju" as a typo, because it looks like a URL.
But in the current implementation, TextView passes "http" and
"oju" separately, so "oju" is still flagged as a typo.
Bug: 5281875
Change-Id: I9d721fd3af34edc51b11908cf2e8fe994b164242
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
Autotext correction would check whether the first suggestion
so far was the same as what Autotext would return, and if it
was indeed the same, would not send its result as
autocorrect. However, the first suggestion is not guaranteed
to have a high enough score to trigger autocorrection, and
there would be cases where a word in autotext would not get
autocorrected because the word came out of bigram
suggestions. These occurrences would be extremely rare, as
they would require concomitant insert between autotext for
one char and bigram suggestion. It is, in fact, probably
limited to the capitalization of "I".
This did not happen in gingerbread because gingerbread would
not register 1-letter words as valid bigrams.
This fix works by just always sending the result of autotext
regardless of whether it is already the first suggestion or
not. This is okay because duplicates are removed afterwards
anyway - and this processing is absolutely necessary because
the autotext'd word may actually be somewhere else in the
suggestion, so it made really no sense checking for only the
first one.
Please note that there is also a race condition that can
result in "i" not being converted to "I": at the moment,
Latin IME relies on having the suggestions evaluated
at the time autocorrection is performed, but when typing
very, very fast, those messages may have been canceled.
This is not limited to the autocorrection of "i", but
affects all autocorrections. It requires a nearly
inhumane typing speed to trigger, but hitting "i" and
space in turn as fast as one can it's possible to
reproduce occasionally.
Bug: 5135113
Change-Id: I530ea6212487300001a2c0fc5b25a5c7716bdf63
Checking the magic number of a file upon decoding is necessary,
because if the file is corrupt and we don't check it, we will
fall back to a simple copy of the corrupted file. Latin IME
would realize this and would not crash, but would not use the
corrupted dictionary. If this happened to be a main dictionary,
then the user would lose the ability to use the correct
built-in dictionary.
Not the same, but kinda similar to
Bug: 5223031
Change-Id: Ic2783dc9dd5f3dcf2865623d9452765fe3778db7
This fixes a race condition that would end up with the spell
checker not finding some words in the user dictionary when it
just booted.
Bug: 5194627
Change-Id: I1ba911cc53e6ae3b111d54a6f91d1d5feef3f5de
The message this removes gets printed under normal conditions.
Normally dictionary files are compressed then crypted, but not
compressed a second time; however LatinIME tries to open a
compressed-crypted-compressed file first, because it could not
do it afterwards and we want to support this case. So under
normal operations, the first method LatinIME tries is actually
expected to fail.
Also, if we decide to stop compressing or/and encrypting dicts
LatinIME supports it as a valid use case. It should not print
errors to the log.
If the file cannot be open at all, then it is an unexpected
case, and Latin IME still reports to the log.
Change-Id: Ic5228c51365a101af1d03e2c893484d3050b5a1c
This change also tweaks more_suggestions_hint drawables to eliminate
unnecessarily padding at the bottom.
Bug: 5204563
Change-Id: If5ec731c9a490da0116a020e8fd405c7d025d707
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
LatinIME has several fallbacks to ensure a dictionary is used.
However, it should now be possible to deactivate the main dictionary
through the dictionary pack settings. In this case, Latin IME should
not fallback to the built-in dictionary.
Change-Id: Ibd992ad89793169f04a968b40781fce819b87b6f
This also adds some optional debug code to detect more easily possible
future occurrences of the same problem.
Bug: 5195017
Change-Id: I2558b468e46f7090de868f1ec2dc9e24895d670f
The new behavior is as follows:
- If the word in the dictionary is not fully lower case, then the
exact case is required to match.
- If the word in the dictionary is fully lower case, then any of
the following patterns match:
- fully lower case
- only the first char capitalized
- all caps
Any other capitalization is rejected.
This is probably what people want. If you type a name in all lower
case, it should be marked as a typo, but if you type a word with a
capital for emphasis or just because it's the start of the sentence,
it should match a lower case word in the dictionary. If you have
a spurious capital letter in the middle of a word because of a typo,
it should be marked as such.
Accents are not affected, and should not be. An accented letter
is a different letter and a missing accent should be reported.
We should maybe consider again for some common transpositions
like the "ue" digraph for German, which is now considered a typo,
but will suggest the correct diacritics as the first suggestion.
Bug: 5145751
Change-Id: I651e24f13c90fb94700a1674ad380e95336e7dca
by ignoring its preference value, when the "show settings key option" in
the settings is disabled.
Change-Id: I934be2d9eb0bf6bf731e03f5d9b752de4a7a1c7c
This change refactors the dictionary selection code so that the
cached dictionary files list and the settings tests are more
cleanly separated.
This will also help with future refactorings that will test for
the presence of the main dictionary and insert the fall back if
it's not supplied by the dictionary pack.
Bug: 5095140
Change-Id: I8d7caad7c054031df71fe78b043801a774d50f65
The next step is to move this over to the Utils class.
The ultimate goal is to make use of the duplicate removal code
also in the spell checker as per
Bug: 5175740
Change-Id: Ica36691b843b0713b832c56ffc65e5b2ec427c4a
Now that the dictionary pack can return several files, it's better
to handle IO exceptions for each file rather than globally. This
also will help with next implementation steps.
Bug: 5095140
Change-Id: I5ed135ad2ad4f55f61f9b3f92c48a35d5c24bdb2
The dictionaries and proximities are not thread-safe. In order to
be able to check spelling in parallel, make a dictionary pool to
call upon when a spelling check is necessary.
Bug: 5156851
Change-Id: Ie3796164187dd7b7abf5ccd5d014073d43d74408
Until the dictionary itself is re-entrant, unfortunately we have
to synchronize accesses to it.
Bug: 5156851
Change-Id: I1629a160d707e6fa1ad80cba828798abb24b68b1
Fabrice Di Meglio
Gilles Debunne
Tadashi G. Takaoka
Ken Wakasa
Jean Chalard
satok