RichInputConnection#requestUpdateCursorAnchorInfo must make
sure to obtain the input connection before calling methods
of it.

BUG: 17299587
Change-Id: I8e0cd473a4cc32583cd47634c227d702f7c69c6c

When CursorAnchorInfo is unavailable, we shouldn't try to show
the commit indicator and set the text highlight color.

With this CL, RichInputConnection can be used to track if the
application responded that it does support CursorAnchorInfo or
not.  This result will be taken into consideration when
InputLogic needs to determine whether the commit indicator
should be displayed or not.

Change-Id: I945d70eeb02a7a5f3d9b22459b23d7028508910f

This is a groundwork for subsequent CLs where we need to
add/remove background color to/from the commited text.

In this CL, we use Spanned#SPAN_COMPOSING so that we can easily
remove such a background color by calling
InputConnection#finishComposingText. To make this operation easy
and realiable, we need to track whether we have specified the
background color to the commited text or not at one place. Here
we use RichInputConnection for this purpose.

Change-Id: I5f9bc4425c5d1b80a719a20e5baf336729ec08d2

There is a bug in ICS where the input connection won't take
any writing commands after rotation until the cursor moves.
This fixes it by wiggling the cursor position once before trying
to do anything.

Bug: 16810766
Change-Id: Ib14c70bd0550420cecfa86dea501d13a1a91e296

Bug: 14425059
Change-Id: Id37022ac6c1545d6845abfbcdb7ed47f0e250eec

...also implement the check for Hebrew and Arabic.

Bug: 15840116
Change-Id: Ia6433d7d98038ade64c171be4fe4b3f094111fac

Bug: 15840116
Change-Id: I545cc9083aa4e2fd7cbbd1fbc02e1e382482db7c

Bug: 15840116
Change-Id: I1123426fbd9d420c1be64ccc917a5f870e70e6fa

This reverts commit 1d300239 that broke the build.

Bug: 15840116
Change-Id: I0a5fa7dea2b418d19df24b2b31ed96bf192d45c0

Bug: 15840116
Change-Id: Ib3380cfc9d343c6f8953bba03af3801142bc3bdb

This reverts commit ba463c9a that broke the dicttool build.

Bug: 14425059
Change-Id: Ie1685587104d26e4416624747c97f6087c13388a

Bug: 14425059
Change-Id: I3eb24e840c165e43f68c2a60fccf9974affb57a6

Bug: 14425059

Change-Id: Ieace636334a9b2a094527341d4fcfc05958296c5

This reverts commit 2a5824a6 that broke the build.

Bug: 15840116
Change-Id: Ife11050394f3ed90e39d835b92732e1b6af83249

Bug: 15840116
Change-Id: I04b9d6bd45d9e806c268fa8ecb4653f8af729095

Bug: 15412461
Change-Id: Ibf37df4d31141a7e43b54d6342e7861eedb1c03b

Bug: 14425059
Change-Id: I2bd6a872904a44b80f638a13d91a97559217cc1a

The symptom : when text is selected and the device is rotated,
sometimes the keyboard sets the word as being composed around
the start of the selection. Upon the next rotation this ends up
with the keyboard committing some text in place of the selection.

The cause : another bug in the framework with rotation >.>
The keyboard receives a call to startInput with a wrong cursor
position, namely one that does not represent a selection. The
keyboard sets a composition according to this wrong data. When
the keyboard is rotated again, it commits the text, which takes
the place of the selection.

The solution : actually when restarting input the keyboard
realizes that the cursor position is wrong. We cancel composition
at that time.
For robustness, this change also implements two other defensive
changes : upon call to onUpdateSelection, we actually realize
that the previous values were wrong, so we also fix it at that
time, and in addition, when rotating, we finishComposingText()
instead of commitText() which is less dangerous. Implementing
this later change also allows us to let less internal variables
from InputLogic escape to LatinIME, so it's also a good change
for design.

Bug: 14140799

Change-Id: Ib10de18e53e376ac1bbc8487e13d969828483346

This fixes PunctuationTests#
testAutoCorrectionWithSingleQuotesAround.

Bug: 14119293
Bug: 15334309

Change-Id: I604c21a21e89a5fc431fd56ab7b6ad03f4736b01

This CL must be checked in together with I5cc76807e3.

Bug: 15318007
Change-Id: I61423c3377ddc299fb332e742d6626c2e47145bb

Bug: 14119293
Change-Id: I5020e5f0aa64bc3e97b3a3c2c07a60c8b765ed64

Bug: 14119293
Bug: 14425059
Change-Id: I65320920e840082b0b697bb621676716d0933e0c

Bug: 13312942
Change-Id: I6be6a558bbc6c88508150f9c25cadbd0240ff88e

Nice recipe for failure

Bug: 13387534
Change-Id: Ida1978449c1997587b2ec0955c5c94fcef336121

Bug: 13136079
Change-Id: Ieae6bafbd5339a033f0f342ba9af7dcc4ce209fa

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