- 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
Normally logUnits are committed to a log when the word that their data
corresponds to is complete. However, if the user reverts a word, or goes
back to edit it, then the system may "uncommit" the logUnit, and append
additional editing steps to the end of it. When this happens, we want to
make a note of it in the log, which is what this patch does.
Change-Id: If2bbb948469824c76facf5f06ed8a6da8ff9777c
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
>>> dictionaries/pt_BR_wordlist.combined.gz
Header :
date : 1355802839 <=> 1357790917
version : 29 <=> 30
Body :
Added: à 30
Added: é 30
Added: ò 30
Added: ô 30
>>> dictionaries/pt_PT_wordlist.combined.gz
Header :
date : 1355802856 <=> 1357790930
version : 29 <=> 30
Body :
Added: à 30
Added: é 30
Added: ò 30
Added: ô 30
>>> java/res/raw/main_pt_br.dict
Header :
date : 1355802839 <=> 1357790917
version : 29 <=> 30
Body :
Added: à 30
Added: é 30
Added: ò 30
Added: ô 30
Bug: 7966948
Change-Id: I71c0986cf616d67926d0a6a0e53099b04b0427d5
Previously, a logbuffer only held an n-gram. Data went in and out of it, FIFO, until privacy
conditions were met (i.e. data not collected too frequently), and then an n-gram was saved.
E.g., if n=2, and only 10% of data is collected, then 18 words went through the logbuffer before
it captured the next 2 words.
However, if a user then went back and edited the n-gram, these edits were not captured.
This change changes the logbuffer size to temporarily hold data about words that are not recorded,
so that if the user backs up over them, the edits to an n-gram that we do eventually capture are
stored. If the example above, instead of a logbuffer holding 2 words, it holds 20. The system
waits until all the words not needed for the n-gram have been gathered (i.e. the buffer is full),
so the user has adequate time to edit, before shifting out the n-gram. The buffer is still flushed
when the user closes the IME. See the comment for MainLogBuffer for an explanation.
multi-project commit with I45317bc95eeb859adc1b35b24d0478f2df1a67f3
Change-Id: I4ffd95d08c6437dcf650d866ef9e24b6af512334
- Now includes all historical data stored in a motionEvent
- Simpler API, refactored to move extraction code to JsonUtils
Change-Id: I52d9756ddbeaa14d1704787da59bf1aad18f0335
- 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
