There are two problems here. The first one is the tests would send
an invalid unicode character. Although we could want dicttool to
handle this more gracefully, it's fine for now.
The second problem is much more serious. If a node has more than
128 children, then the java code will crash trying to read the
dictionary back because of a bug that this change fixes. In
theory, it's possible that happens when we try to load the user
history dictionary back from the disk - native code is not affected
so there is no other point that may cause a problem.
In the practice, that means you'd need to have 129 words with a
common prefix (including empty string) but all different after
this. It's almost impossible with Google Keyboard since there are
only so many keys on the keyboard that you can make a word out
of, and then again you'd have to do it repeatedly until it
actually enters the user history dictionary, wait for it to get
saved on the disk.
The bad news is, if you manage to get this far, the keyboard will
crash every time and won't be able to get up until you clear
data for the package.
The good news is, the dictionary itself is not corrupted and only
the reading code is wrong. So updating to a newer version would
actually even recover from this situation.
All in all, considering how almost-impossible this is to trigger,
I don't think even a single user actually did hit this bug.
Bug: 8583091
Change-Id: Iabb2a7f47cbd9ed3193d2a3487318d280753e071
This uses the old suggestions. It does not try to recompute
new suggestions if there are no old suggestions yet: this is
coming in a later change.
If there are no suggestions, this shows the word itself
as a suggestion.
Bug: 8084810
Change-Id: I4c2e25df0ff3673be1825f57a0c19a9d23d47a48
Both bugs only affect debug mode. One has the wrong object tested
with equals, the other has the iteration failing in some cases.
Change-Id: Ie9100d257a3f9e3be340cf3e38116f63417bdc1a
This reverts commit c741f1f83b98293bf0040b6b81e95b75ecf3f6bc
DO NOT MERGE is ignored and this is merged anyway :(
Change-Id: Ie044cdfc6021933379ec97ad7346c5c8591f70bf
Previously handleSeparator() caused the ResearchLogger to mark the time at which a LogUnit should be
broken. However, this causes the motion data associated with a separator to be associated with the
LogUnit of the previous word. This change corrects this bug.
Change-Id: I8b4d4fa6de2a013de9e2a28bb668c446a07f1957
Upon invoking the settings of the dictionary pack with an unknown
client, we now launch an intent to ask the client to make itself known.
This change also includes the code that receives this intent and
acts upon it.
Bug: 8492879
Change-Id: I2c6496dea845646961ecafcf64e282cb93ee91dc
The important bug is in findWordInTree. The problem, which is
not obvious, is that we were calling codePointAt() with the
code point index in the string, instead of the char index.
The other bug this change fixes was harmless in the practice,
because it's in the iteration which is only used for debug and
pretty printing purposes. It's very similar in that it would
substract a length in code point to a length in chars and
truncate a StringBuilder at that length, so it would fail in a
quite similar manner. This changes the meaning of the "length"
attribute in Position, but it's clearer this way anyway.
Bug: 8450145
Change-Id: If396f883a9e6449de39351553ba83f5be5bd30f0
