Change-Id: Id46898c5cae268f05850d79938929b7707f27320

Bug: 9070153
Change-Id: I66e55dd2f30fddfeb849edb97bc1cbda6b126d92

This change utilizes the no panel auto more key feature to implement
long press shift key for shift lock.

Change-Id: I3995d25dc35aea3c67b5aa29299815462eff9cad

Change-Id: I8fc2c90cf8d3dce11740f8e61edf6dfde9b1c116

Change-Id: Id03bf0910708d07b45286dccf8f2bfc97a362ba0

Bug: 9112465
Change-Id: I4fe39bebf130799397485dbe6d23199a29a8641e

Change-Id: I16e3f3ebc43772cfd96c824afeddfd225404b857

This is a follow up of I5a32882a08.

Change-Id: I9f0cda2167811f6bba2af042fbde0a821b4cfecd

This change also fixes a regexp error of Galaxy S III.

Change-Id: I42a4780bbfd2b083f4e27e61ec513aa875907344

Change-Id: I5a32882a088e4ff5bfe973a86465d6ff839113d9

Bug: 8556775
Change-Id: I7e0516b344937b84b7d57cc4e5009b7f88e7dc98

Bug: 9112465
Change-Id: I6cd63007287b5a1a57cfbabff35d53f66fc5620e

Change-Id: Idd3647bb1a1d40df8bb89eda715d45427a58d0cd

* commit 'f1dcf725':
  Don't process recorrection or resets when not shown

Bug: 8954116
Change-Id: Ica27dbfc570643bb81e6cdf34cc7c796ea080d71

Bug: 8915171
Change-Id: Iabdeb7920f67f89246087c3ee06240406ecfbc3d

Change-Id: If353869720895ee5355079c15c724132762dd70c

Bug: 8556975
Change-Id: Iffc53d6a40dd77860434c5f7f4f59af5cd1ba92b

Bug: 8556975
Change-Id: I29d3a305b6ac3d8e3620c6d8592d85047d62bf48

Bug: 8556975
Change-Id: I275c99db8a0d10594a5a8c0c27ebc1a87495c307

Bug: 8734294
Change-Id: Ib2bc262aacedf786a318c2fe1bd4420a21e7d847

Change-Id: Iaa0a691903526f57510a0305c02cc42cf8d90f9e

Change-Id: Ib9373b26b04b0f4789b3cd6a7af64e4bcd2c4b9c

Bug: 8613307

Change-Id: Ief04a4abb6dc1f79660a2e419c9c5e271802b5a1

Bug: 8650846
Change-Id: Ice5ef07d6833422906b0b756206e097f75d1f2db

This is about as ad-hoc as it gets, but then again, what we want
is probably as ad-hoc as it gets.
All URL boxes I know of double as search bars, and not adding
automatic spaces there sucks (e.g. in Chrome URL bar).
And in other boxes actually you don't want to add a space if
it looks like a URL. QSB isn't even a search box, and it behaves
like this.

So I think this is actually the right answer to the problem.

Bug: 7062925
Change-Id: Ib09472b34644fd5bf2dc84bb97cedeeba28bcd02

Bug: 7657025
Change-Id: I2f8fe7fc4596a498322ba5ccabbd0c18a2bc36cf

Change-Id: Ib4d002f90cd3a0e9ad4c04b883b0c1f05ada3ccf

Bug: 8583091
Change-Id: I9195d68e44e9a282e25ccd2978d7b4088f600170

Upon pressing Shift, if there is currently a selected string, have
Latin IME change its capitalization.
This does not yet have the keyboard mode follow the mode - the change
is complicated enough as is.

Bug: 7657025
Change-Id: I54fe8485f44e04efd72c71ac9feee5ce21ba06f2

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