The heuristic in RichInputConnection makes little sense
when textLength > mExpectedSelStart but we have
more than 1024 characters of text. If there are that many,
it's about 100% sure that 1024 is not the correct cursor
position. With no good guess, we'll just continue trusting
the app, even though we know it's lying : at least it will
make the problem visible to the app author.

Also, there have been a lot of confusion about initialSelStart
and initialSelEnd. The keyboard should log them so that
it helps us and editor authors debug more easily these
common problems.

Issue #65170 in AOSP and
Bug: 12772035
Change-Id: I6665a16c9f2832d33ee323f033bb38bcc092a3b4

When the cursor is moved by the user, the RichInputConnection
is told about it. However, to work around a framework bug, it
also looks at how many characters are in the buffer before the
cursor, and if that's more than the value it's been passed, it
deduces that's a framework bug and there are at least as many
characters as seen before the cursor, so it puts the expected
cursor position there.

When you move the cursor, TextView calls onUpdateSelection,
and when you move it fast, you'll get rapid-fire calls to
onUpdateSelection. This is fine, the RIC is equipped to
deal with that.

However, these calls take some time to make it to the IME. In
this instance, when the first call gets through and the IME
calls TextView (synchronously) for text before the cursor, the
cursor has already moved in the app, and TextView returns more
characters than the cursor position was declared to be in this
instance, so the RIC sets that as the expected cursor position.
Sure enough, a split second later, the second call to
onUpdateSelection arrives, with the new cursor position set
where the RIC had found it too early. The RIC takes that as an
"expected" cursor move, and the input does not get reset.

Luckily, we have a way out. As far as we know, the framework bug
only manifests itself upon rotation, which means we should only
have to adjust for it in onStartInputView. Doing it in
onUpdateSelection is too zealous (and probably too distrustful of
the app to send the correct cursor positions).

So we should just take care of the rotation case (by calling
tryFixLyingCursorPosition in onStartInputView) and remove the
compensating code in resetCachesUponCursorMoves.

Bug: 12982502
Change-Id: Ic3c1408a1ec45deaea63b01d98376a79ae567d77

Typo fixes and clarifications

Change-Id: I0f7e0b6e665232bb995172fff10521c7f17599eb

During recorrection, the cursor position when calling
commitText is not necessarily at the end of the
composing text.
Besides, RichInputConnection assumes the cursor is
always after any composing text. This is not correct,
but in the practice, it seems all code paths work.
We should fix this in the future.

Bug: 13060691
Change-Id: I15f71fff62d36e80cf6e4a022c5e78af634b199d

Bug: 11447084
Change-Id: I5bd558b9dd85d1505aa918f44e8ac3e52ec42d97

Bug: 8911672
Change-Id: I5d5635949530a67f95e5208986907251b7bce903

Change-Id: I4103541d99fe59bfcf12379a1298a0a690497846

Change-Id: I866488a47ca04ca587e805663dfd597bb7b1ebce

This just mirrors what InputLogic#tryFixLyingCursorPosition
is doing. That method will go away in the next change.

Change-Id: Ifa2827dbc1f1d20e2c642d6f2d23514a01ed9203

This test was intended only for cases without a selection, and as
a safety net for cases where the app would pretend the cursor
is at N but we can get P chars from the editor where P > N.

When there is a selection, this is wrong. In the practice it works
because these values are not used in this case, but it's still wrong.

The case where P > N is arguable, but actually I see little reason
to trust the getTextBeforeCursor() method more than the
onUpdate selection method. Plus in the practice, I don't think
we are aware of any app with this bug, and it's probably not a
great idea to be too robust about this as it may encourage wrong
values sent to onUpdateSelection.

Change-Id: I42f2065d7aee668074e6b8e40b259da7e88e16e1

Change-Id: I174c50f509ed6998b755e1a712e7f6c0f82f4425

Change-Id: I0b06e8cc75a403f7061864c5b7f3f6a2cacd60eb

Change-Id: I5cfa0d2fccc139bd6c45c5590a68c3e0c90534b8

Don't use absolute cursor positions when making edits,
this leads to race conditions.
This is a bit ugly and will need to be fixed soon. Plans are
underway to clean this up.

Bug: 12390573
Change-Id: I69c09fc41b979880d0800c55a710e39373287cff

Conflicts prevent this to be cherry-picked.

This reverts commit dd3d697a.

Change-Id: Ib97fae2234633b4bb27d611f48a79060db9ab16f

Don't use absolute cursor positions when making edits,
this leads to race conditions.
This is a bit ugly and will need to be fixed soon. Plans are
underway to clean this up.

Bug: 12390573
Change-Id: Ib42d4149343c642b1b5c1937b424e8afdbd4cc1f

This old method doesn't even re-read the old suggestions. It used to
recompute them without the coordinates.
Re-using the recorrection code, which is much more advanced, is
the right thing to do here.

Also, refining the test. It's no use trying to resume suggestion
if we don't have a suggestion strip, since we aren't going to
auto-correct anything anyway.

Not the motivation for this change, but this also fixes
Bug: 11620256
Change-Id: Id49efa32e293c49837c61fdc752c86bbac1d2c88

The bulk merge from -bayo to klp-dev should not have been merged to master.

Change-Id: I527a03a76f5247e4939a672f27c314dc11cbb854

This should take into accounts word connectors.

Change-Id: Ic7fa5c837cd65a43ba43d7ae9d299b8d20019892

Change-Id: I299c7622db291ea411e2b48dfdb622b407912ea6

Bug: 11846748
Change-Id: Ieda55477201c11fb31b0f84e70ecd081211c78fc

Change-Id: Ie5cffe03b676dcde83896cda139b42f3829eb528

Change-Id: If23d8bd73fe464f12f473e093dc87ed68756e1ec

...the interaction of which results in a very bad bug.

Bug: 11648854
Change-Id: I774489e384388f187e72b9ac091ab387c5e1a79a

...the interaction of which results in a very bad bug.

Bug: 11648854
Change-Id: I774489e384388f187e72b9ac091ab387c5e1a79a

Change-Id: Ibdaa9553cafeded15f800077606378b06af755cb

This returns the wrong string, but since it's used for getting the
previous word for bigrams, it only results in slightly worse
suggestions quality.

Bug: 11273655
Change-Id: I6ce5de2f76effc453ca691a654ab6bf17445b9e7

This returns the wrong string, but since it's used for getting the
previous word for bigrams, it only results in slightly worse
suggestions quality.
Cherry-pick of I6ce5de2f

Bug: 11273655
Change-Id: I17fb6d74f18fb31bd8f8518f80456d74ae30a2c3

This returns the wrong string, but since it's used for getting the
previous word for bigrams, it only results in slightly worse
suggestions quality.

Bug: 11273655
Change-Id: I6ce5de2f76effc453ca691a654ab6bf17445b9e7

This will help handing correctly the armenian full stop.

Bug: 10082781
Change-Id: Id7bb219ebd89daba203216eab362d1cc26a65a36

Followup to If4e44eca3cdc5bb02cf2e0c8c44ecd4bf27fae57

bug: 10622489
Change-Id: If98b2c75725f8692f0c2b41c33e448086404479b

The PARAGRAPH type of span is dangerous, as concatenating
CharSequences that contain it may crash. We also don't use
other spans than SuggestionSpans, so we don't copy them.

Bug: 10622489
Change-Id: If4e44eca3cdc5bb02cf2e0c8c44ecd4bf27fae57

...and do a best effort to fix it.

Bug: 10323080
Bug: 10252066
Change-Id: Icb3c9fe85005406bdfce0b7bb143ba0a910a0ddb

It's unclear what the concrete effects of this are, but they are not
very strong. This only happens in corner cases, when the input
connection is not active - while rotating, for example.

Change-Id: I1d22459a6e94a8ecccb53cfcbc2d301b1d502204

InputConnection#finishComposingText() should not change the position of the cursor,
so neither should it change its internal expectation of the cursor's position.

Change-Id: Ib3d39a5743cd1e8e356f438b04a5c30279430b2a

Bug: 8911898
Change-Id: Ifb4bb63c14dc960d0a53f1511908830093cca012

Change-Id: I4d36a23567415c3a293a588b51b46006256c148f

Bug: 8864306
Change-Id: Ic8eecd64eff6a1150a90b9f5ec9ebbc5f1d2a6a9

Bug: 8864306
Change-Id: Ia146f711f1de4336d7e3363208ab92eba856f5e1

This reverts commit f712dc9a.
It turns out this refactoring is not useful after all.

Change-Id: I0145c907b3cc5ac9a30a59abcd719cb546c9bd3a