- 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
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
Previously, LOG_EVERYTHING logged both all bigrams and also the entire TextView at the end of a
session. Now, use a separate flag, LOG_FULL_TEXTVIEW_CONTENTS to determine whether the TextView
contents are recorded.
Change-Id: I0c7a90a8ff88aa65d057f3b2d3dd5adc3893504a
- count how many times a gesture is deleted
- count num chars entered by gesture
- change name of fns to reflect capturing gesture information when setting composing text
Change-Id: I1b8ebf9cfcf304e0efd827c8b8e28a4010199728
