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
