We don't need the optimization of storing the old words now
that the RichInputConnection can supply it without IPC.
Bug: 13703802
Change-Id: I37ccb8d5fba879fb04b4f23d33571849736d897c
The logic to determine when the suggestions strip (a.k.a. the
contextual strip) should be shown is already complex. In addition to
that the voice input key get shown on the strip as well. There are a
several factors to be considered and a few things to control.
- The password input field shouldn't have the strip.
- Show voice input key on the strip or not.
- User preference settings "Show Voice Input Key".
- A voice IME exists and is enabled.
- The input field may have a private IME option to prevent the voice
input key from being displayed.
- Application can specify auto completions.
- Full screen mode or not.
- User preference settings "Show correction suggestions".
- Always show, Show in portrait mode, Always hide.
- The input field may have flags to prevent showing suggestions or
auto corrections.
- Suggestions is empty or not.
- An important notice may be shown.
Bug: 14981852
Bug: 15436479
Change-Id: I3050fd53ee6271fc64a8f17b6b12d9581d37b750
This change also includes a fix that has suggestions re-computed
when the typed word is included but no prior suggestions were
found in spans.
Bug: 2349475
Change-Id: Ic06e6ac492507126ffc1e96a5f396c971b567272
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
When
1. The important notice message is shown on the suggestions strip.
2. And the "Show correction suggestions" settings is off.
we will keep showing the important notice message on the suggestion
strip.
Bug: 13741460
Change-Id: I411007ab1e5e6959b6cdba7a6601a84635259313
This CL fixed the breakage caused by DistracterFilter.
It should be checked in together with I8f53e9481c0f
Bug: 14911612
Bug: 13142176
Change-Id: I33c3526165cea58926d10404552f1fadc385c2e5
With this CL, the implementation of StatsUtils no longer
needs to know how to read settings from the system.
Insted, the LatinIME class is now responsible for notifying
StatsUtils whenever the settings is changed.
BUG: 14324207
Change-Id: Ic3d26ec31c8d2c082d3e7487b578b323aad2f960
This CL also renames AccessibleKeyboardViewProxy and
AccessibilityEntityProvider to MainKeyboardAccessibilityDelegate and
MainKeyboardAccessibilityNodeProvider.
Change-Id: I2b0ec091a11aa8a495794d633efecb6d8b818f42
With this CL, LatinIME starts using
InputMethodManager#shouldOfferSwitchingToNextInputMethod when
available and API level is higher than 19 (KitKat).
Note that relevant settings of LatinIME will be ignored if
InputMethodManager#shouldOfferSwitchingToNextInputMethod is
considered to be available at the moment. We will revisit
here to reorganize the user visible settings before the
new global IME switching mechanism becomes publicly
available.
BUG: 12965588
Change-Id: I0188fa56cba8e983c61cef3ae3400a0e3821f718
It was implemented according to the Plan B in the
design doc:
http://go/ime-misspelling-filter
This CL is to create a DistracterFilter instance
and pass it to PersonalizationDictionarySessionRegistrar.
This patch should be checked in together with
Id633b4fd45693
Bug: 13142176
Change-Id: Ia4957e64218c9619fcf9bb91795a187617c72a2e
With this CL, LatinIME starts calling
InputMethodService#setCursorAnchorMonitorMode in #onStartInput()
when ProductionFlag.USES_CURSOR_ANCHOR_MONITOR flag is explicitly
set to true.
BUG: 13891796
Change-Id: Ib2fb0c3521b61859d4cc530155ccaaee7ee16cbc
In tests, we create many instances of LatinIME, but we never
destroy them. That means we never close the dictionaries nor
the handlers.
This change calls onDestroy, which closes all dictionaries, and
adds some code to finish the handlers.
Change-Id: I942517a2a940c54256b08763f6b38f5b55809f55
We want to remove all calls to this as it lets internal values
escape, but there is some refactoring to do to finish this.
Bug: 8636060
Change-Id: Iedba6afe4719bc0add868714a1ee5a04b7ead33e
Make mSuggest final and give DictionaryFacilitator the
responsibility to manage dictionary loading state.
This can simplify the logic to decide how to deal with
additional dictionaries when loading settings or language
switching.
Bug: 13273534
Change-Id: I9f3d328272f25addfa186fbeedaaf8417455ba99
The event interpreter should intervene later, after decoding.
Decoding should happen first, and then the Event should
be passed to the InputLogic.
For the time being, we will leave the (unused) EventInterpreter
class and its friends, because we'll use them again later.
Bug: 13406701
Change-Id: I7582d486724311e39e6692e606cca50c78800643
We should not test punctuation with this equality test any more.
Also, whether the suggestion strip is displayed or not, or whether
the hint is displayed or not, has nothing to do with this method
and should be handled elsewhere rather than here -- and as a
matter of fact, it is, which makes this useless.
Bug: 8636060
Change-Id: I6a54ee87e4e9f81bc33158acf4a264c3abd5829d
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
Tadashi G. Takaoka
Jean Chalard
Keisuke Kuroyanagi
Yohei Yukawa
Xiaojun Bi
Ken Wakasa