bug: 6447900
Change-Id: I436b2b7b261b422a7edca9cb99a4689b63877fe0

Change-Id: I22305137b336c9aab019d044a517ae8bc5fefe45

Change-Id: If4f24500ead516c46e6a93a95291e0897548c2f0

Bug: 6422318
Change-Id: I5779c0e277444315191fa964a976dcb4316cc24a

Bug: 6422086
Bug: 6411272
Change-Id: Ia3c40206555353b6f0c633a529d546dc2379e9aa

Bug: 6105732
Change-Id: I92e7a9c6d6eb648f747c3b396d7993479fd8478a

Bug: 6412932
Change-Id: I9576ae5b42bcc54cfd8ede0bae5148f3b04c1978

bug: 6410653
Change-Id: I4263632e76b44abf8ecd9114a9eb185ad39201fd

This is a cherry-pick of Icb602762 onto jb-dev.

Bug: 6355745
Change-Id: Icb602762bb0d81472f024fa491571062ec1fc4e9

This change also refactors the language name selection to use text
x-scale.

Bug: 6396854
Change-Id: I31249a85bd042a93d627f40413161aef13617c87

This is a cherry pick of I14b67e51 on jb-dev

Bug: 6340915
Change-Id: Iaa512abe1b19ca640ea201f9761fd7f1416270ed

Bug: 6400718
Change-Id: Id5dce156ad397b911bfeaedeeddd4aeb21a10b3a

* Move SubtypeLocale.get{Full,Middle,Short}DisplayName() to
  LatinLeyboardView and add unit tests (SpacebarTextTests).
* Add SubtypeLocale.getSubtypeDisplayName()

This is a cherry-pick of I57420c6a from Master.

Bug: 6393865
Change-Id: I68748189c17c73984ac4ae05a5a40fb54bf46453

Bug: 4460018
Change-Id: I9a29f6a322af66f6a152fa1883b3686c5f7a3328

Bug: 6384416
Bug: 6387408
Change-Id: Ia7b0653a09410b42a55915815c887bf0ad56c856

Bug: 6384416
Change-Id: Id5fa4742ad900fafb82cc37a0bbb9f380b99254d

Bug: 6393755
Change-Id: I3a74b23f934cd52925026ad04647cc76de92ee07

Bug: 6029665
Change-Id: I4bf0f5703d0c11d76bab478da2729b0e20fc64ea

Bug: 6380724
Change-Id: Ic1d0d902dc45ecb41a1792f33a60ab85e606fcef

Partially reverts the Ia3680d84.

Bug: 6356125
Change-Id: I8faa810b833cb98ce6f0f760aa1722e63475cd45

Bug: 6371604
Change-Id: I1054685b9985b6923e3176679b3d95424d8114e0

This is not the Right fix ; the Right fix would be to read
the file in a buffered way. However this delivers tolerable
performance for a minimal amount of code changes.
We may want to skip submitting this patch, but keep it around
in case we need to use the functionality until we have a good
patch.

Change-Id: I1ba938f82acfd9436c3701d1078ff981afdbea60

The core reason for this is quite shrewd. When a word is a bigram
of itself, the corresponding chargroup will have a bigram referring
to itself. When computing bigram offsets, we use cached addresses of
chargroups, but we compute the size of the node as we go. Hence, a
discrepancy may happen between the base offset as seen by the bigram
(which uses the recomputed value) and the target offset (which uses
the cached value).
When this happens, the cached node address is too large. The relative
offset is negative, which is expected, since it points to this very
charnode whose start is a few bytes earlier. But since the cached
address is too large, the offset is computed as smaller than it should
be.
On the next pass, the cache has been refreshed with the newly computed
size and the seen offset is now correct (or at least, much closer to
correct). The correct value is larger than the previously computed
offset, which was too small. If it happens that it crosses the -255 or
-65335 boundary, the address will be seen as needing 1 more byte than
previously computed. If this is the only change in size of this node,
the node will be seen as having a larger size than previously, which
is unexpected. Debug code was catching this and crashing the program.

So this case is very rare, but in an even rarer occurence, it may
happen that in the same node, another chargroup happens to decrease
it size by the same amount. In this case, the node may be seen as
having not been modified. This is probably extremely rare. If on
top of this, it happens that no other node has been modified, then
the file may be seen as complete, and the discrepancy left as is
in the file, leading to a broken file. The probability that this
happens is abyssally low, but the bug exists, and the current debug
code would not have caught this.
To further catch similar bugs, this change also modifies the test
that  decides if the node has changed. On grounds that all components
of a node may only decrease in size with each successive pass, it's
theoritically safe to assume that the same size means the node
contents have not changed, but in case of a bug like the bug above
where a component wrongly grows while another shrinks and both cancel
each other out, the new code will catch this. Also, this change adds
a check against the number of passses, to avoid infinite loops in
case of a bug in the computation code.

This change fixes this bug by updating the cached address of each
chargroup as we go. This eliminates the discrepancy and fixes the
bug.

Bug: 6383103
Change-Id: Ia3f450e22c87c4c193cea8ddb157aebd5f224f01

Bug: 6355346
Change-Id: I96933719cc94f25e6c7ecb1d6345c11b6acc4134

Bug: 6384416
Change-Id: I878071b8b78acce51649f9637b59830ab681c696

Change-Id: I70d2627318d21eb612c3c3fee2ce8e80555dba12

Bug: 6378291
Change-Id: Id2453333ae16146f816faf0eb68baa8ea1dd106a

This would end up in TextView sometimes calling onUpdateSelection
multiple times (this is the correct behavior for TextView). We now
commit the space and the word in a batch edit, and we only get
onUpdateSelection once.

Bug: 6300527
Change-Id: I9579f3d8f5320c1cc24a7a42f19db8e105eb090d

We need to get the bigrams during the call to getSuggestions for
bug#6313806. We already give an int[] to getSuggestions and we
wanted to get rid of char[]'s anyway because it doesn't work with
surrogate pairs, so here we go.

Bug: 6313806
Change-Id: I56ce99f1db6b3302cdf42f0527343bded837091e

Change-Id: I80626591574aa9995011202cf868f9c2c5168303

Bug: 6327270
Change-Id: I5a0e732c8a3fd55fd8ac3c8fe1c58e7f91555d97

Bug: 6363029
Change-Id: I71a1ed5b88f54fcc15bfaf89d3645b8f17ebb821

Change-Id: I1a82bf2202d436efa4c5135d705a048fe45a0257

Change-Id: I3abbf6462c31b11167e356fe77b8afca2514a869

Change-Id: I5c4e230500f058f7db86c05d554be45411004ffc

Bug: 6370179
Change-Id: I061559ea5d0cb11a059de4b6e741f9c17ee69a27

Bug: 4460018
Change-Id: Ia03ec826fb3853ea814d9764686903dbe31a6507

Change-Id: I73a4df3a83e49be6e8d3a7d14eb027cfe10f1a23

Bug: 4460018
Change-Id: I08a9b556720f6c4f7089a8838c0869c9f88f479c

Bug: 6347202
Change-Id: I30b53256e83c534436b0f0ff594fd4aaabf4558c