- Normal delete events are recorded
- Includes number of characters deleted for both batch and normal delete
Change-Id: I422da3ddc94fa0ccd6c7586eaacf14c62dd16679
- Fix function calls to happen at more resilient times
- In the case of phantom spaces, ensure that the logStatement goes to the
correct logUnit
Change-Id: Ida8f6eba1e4f33d9f9b4735316e3c6316ed316c0
Remove the subtypes that don't get a dictionary any more in AOSP.
Also prepare for all downloadable-dictionary supported subtypes.
Bug: 7673670
Change-Id: I5b754a791233c270237b8f7e5e2208f7282ad294
This change moves dismiss timer of gesture floating preview text from
PreviewPlacerView to KeyboardView.
Bug: 7967461
Change-Id: I0ca5beddc93cb4bc4a405f914d217d37b997402b
Tests have been broken again by recent changes to subtype
choice within Latin IME. This fixes the problem and all tests
pass again.
This change also includes a small fix to one test that was
checking for something irrelevant.
Change-Id: I6a03dea24f99b0d2ad84c4161a8413f3060bb811
- Default keypress volume is set to 0.2f in resource.
- Default keypress vibration duration is set to 10 msec in resource.
Bug: 7055329
Change-Id: I83bd6288d171d9787d52e2b02e4e5305f1435681
It's useless to setAutoCorrection(getTypedWord()). Every time the
contents of the word composer are altered, the auto-correction is
reset, and at use time if it's null then the typed word is used
anyway.
Change-Id: I0870657a1ab3f456f376995b27e70703f7a5d23a
Essentially this does activate auto-correction with a hardware
keyboard, although a lot of things are still left to implement.
No proximity is used yet which means only missing and excessive
letters are considered. Dead keys are not handled. No combiner
is supported. No suggestions are displayed. Resuming suggestions
does not work correctly with a hardware key (because the view
holds a temporary hardware event 'onKeyPreIme' and the event
from the IME won't be handled until this is handled which won't
happen until after the IME said that it did handle the event).
Bug: 5037589
Change-Id: Idcb5c7b26d56717ed772d53c062362807f11cdae
In this test, it's impossible that start < 0 so the test is useless.
I'm not sure what the cursor test was for, but it's very old code, and
it seems the assumption was either misled or doesn't hold any more:
testing for the absolute cursor position against the length of the
word against the cursor makes no sense.
The net result of this was that when the cursor index got large
enough, resuming suggestion would not work any more.
Bug: 7586467
Change-Id: I3462082374fe9579bec7698f4d424de6ff5f2ded
