| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Bug: 8084810
Change-Id: I1743c09c43ca6835bb2f607684b037bf17d36335
|
|
|
|
|
|
|
|
| |
Conservatively reduce the number of unigrams to test from 1000
to 100.
Bug: 8583091
Change-Id: I48621ec44ff5f0590640d7c6b174ab5a6d267aaf
|
|
|
|
| |
Change-Id: I27b925be030e9e6ee8ae49dc13f39accec996d7e
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| | |
Bug: 8601979
Change-Id: Icf584f3b35adce69cc3dfc46f3aacfef05e5dd2a
|
|/
|
|
|
|
|
|
| |
RichInputConnection#getWordRangeAtCursor may now returning
either a SpannableString or a String. We can't test that with
String#equals(), but TextUtils#equals() does the job for us.
Change-Id: I59ebe54207e92f4d90b49476b64f1e12fd4929cb
|
|
|
|
|
|
|
| |
There was a much, much simpler way of achieving the same thing.
Bug: 8583091
Change-Id: I8882f389312caad3b17335672892a31d30cd00bc
|
|
|
|
|
| |
Bug: 7657025
Change-Id: I4889721b5348c77ed56c5157557e9988dea48a02
|
|
|
|
| |
Change-Id: I5c03cea41e9b6e936e8f93b7d756f0fc9520002d
|
|
|
|
| |
Change-Id: Ic220129dc59f585164dbf63591cd1c96de17fe6f
|
|
|
|
|
| |
Bug: 8582061
Change-Id: Iac8f65defdd92d7df533bdf0e2937ad897d96363
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
That includes gestures, which used not to work.
Bug: 8532637
Change-Id: I04606565d7000faadf954c4a806c39d4d162a2c1
|
|/
|
|
| |
Change-Id: I6b56b91ace57f4a49584b5dceb71b145859f839e
|
|
|
|
|
|
|
|
| |
Yes that's even harder to understand. The old technique doesn't work
any more, so I have to drill a new hole in this class.
Bug: 8303100
Change-Id: I70a41b5094dab2bb56a17eaf55b2a2df853e4bb6
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test was not passing the correct input type when it was
creating the text view, resulting in mismatched types seen from
TextView and LatinIME with some bad results. The test would
even go as far as restoring it after it's been fixed by TextView.
Additionally, since we want to enter litteral carriage returns,
the input type should be MULTI_LINE. If not, TextView does
not allow carriage returns.
Bug: 8302690
Change-Id: I1c20bcf6ca554ad981048ec181e19c649f6c742e
|
|
|
|
|
|
|
| |
There is the boolean flag to kill interpolation.
Bug: 7167303
Change-Id: Iac7e4cb88cf437c2ee77c003c9cddb92416025c7
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Bug: 6789579
Change-Id: I062c076f0ca16cc39274e20955aa83d667b7380d
|
|
|
|
|
|
|
| |
This is a cleanup change, but it's also necessary for
Bug: 8152758
Change-Id: Id6ba06243f573fdb856f87d1df03277c9f2e5e71
|
|
|
|
| |
Change-Id: Ie7acdf6895a9769eb43ea8a1c70c0d13b32ed349
|
|\ |
|
| |
| |
| |
| | |
Change-Id: I32700c434b296bb3fd39e040c2dda1fe90667daf
|
|\| |
|
| |
| |
| |
| | |
Change-Id: I602f33991ca57b6057ec2defe01573552b322857
|
|/
|
|
|
|
| |
Follow-up to Idc6f419a
Change-Id: I4aae8f4e19f27a0a309879dc19af6e40906d58c5
|
|
|
|
|
|
|
|
| |
The test is wrong - it checks a struct that contains a string
instead of checking the string itself.
Bug: 8149360
Change-Id: Ifb93d61f25a64a64e1c1e689de792f27994487b6
|
|
|
|
|
| |
Bug: 8131968
Change-Id: Ibca5a0d63a492134b8af401a62ca3a5748e003cf
|
|
|
|
| |
Change-Id: Ib398ea61ff048b1a4ac3b7f7b4a772e173a7b294
|
|
|
|
|
|
|
|
| |
That helps tests know when to wait and when to declare the
dictionary actually not usable.
Bug: 7925814
Change-Id: Ic963c1206c43e3cde39ac4214a0d601f4fc6c03b
|
|
|
|
|
| |
Bug: 8056376
Change-Id: I33f07e7a044c2b5fc20de40c7a9777dab493e41c
|
|
|
|
|
| |
Bug: 8032166
Change-Id: Ib9a6b63c4d540ce377892fb865e53abdd8adec16
|
|
|
|
| |
Change-Id: Ia667bc2d406d66c87215dd3b9569f36f4642cfe0
|
|
|
|
| |
Change-Id: I4600c808f2ec31c18d3698a43afa7f4be9407e3e
|
|
|
|
|
|
|
|
|
|
|
| |
Tests have been broken again by recent changes to subtype
choice within Latin IME. This fixes the problem and all tests
pass again.
This change also includes a small fix to one test that was
checking for something irrelevant.
Change-Id: I6a03dea24f99b0d2ad84c4161a8413f3060bb811
|
|
|
|
|
|
|
| |
And add a test to make sure it stays not-broken.
Bug: 7946604
Change-Id: I996da3d5507d591ec25a13fb57434f39843f1df5
|
|
|
|
| |
Change-Id: I16a27f2ed6ea66184bfdc9903180372cd7ea2fd1
|
|
|
|
|
| |
Bug: 7675452
Change-Id: I2121f56964b6d25e8d40f5b8ec67eeae527b2117
|
|
|
|
|
| |
Bug: 7594188
Change-Id: I1977acb7189f8eb186b9b20a3e5b64b4aaabf191
|
|\
| |
| |
| |
| |
| |
| | |
shift-chording input
* commit '7ba02315abf3f6fe2e40fcb248ccf1cab8dee179':
Request update shift state after shift-chording input
|
| |
| |
| |
| |
| | |
Bug: 7529860
Change-Id: Iec82459348722be358ae2ded15deafac21749dcd
|
| |
| |
| |
| |
| | |
Bug: 7594165
Change-Id: I7849d763e49b57716e8418fb8b6f90eca3a5d2ec
|
|\|
| |
| |
| |
| |
| |
| | |
the space strippers" into jb-mr1.1-dev
* commit '82cc7349254e1ca3722ead1f108b6c53820432d5':
Correctly add double quote to the space strippers
|
| |
| |
| |
| |
| |
| |
| |
| | |
...without removing space, this time.
Also add a test to make sure it is working.
Bug: 7531719
Change-Id: I3afcc433c6cdc2774e7deeb6d358356db5035d35
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The subtype locale name on the spacebar will be suppressed when only
one subtype is enabled and
- Subtype locale is equal to the system locale.
or
- Subtype language is equal to the system language but the subtype is
implicitly enabled.
Thus the "es_ES" system locale chooses "es" subtype keyboard
implicitly but the keyboard doesn't have the subtype name on its
spacebar.
This change also removes Spanish Latin America keyboard.
Bug: 7531804
Change-Id: Ib929e8235d643c0ba039eb010e18ab721a734e15
|
| |
| |
| |
| | |
Change-Id: I6ff86ee819a446dd3ed5f9c3400d23564027b020
|
| |
| |
| |
| | |
Change-Id: Iee01d4d2b916d0b584531104ac865ae6e6370a3d
|
| |
| |
| |
| | |
Change-Id: Idb7addede891a5c672d7fc09ddfe4d2585f8d647
|
| |
| |
| |
| | |
Change-Id: Idc478f901185ee1b4912acc82d0cbc54fee4e991
|