Previously, words were pushed out of a LogBuffer one at a time. The receiving code had to keep
state to know whether a n-gram was safe to log. This patch looks at the entire n-gram and makes a
single decision based on it alone.
mult-project commit with I3c40d7e02c77943d2668094ddb1d03efb942c74f
Change-Id: Id7d90bbd551b1a2f4e0e35f38852652f68f273f8
The feedback string was not being inserted in the feedback logs. Also changed the tag to
"UserFeedback" from "UserTimestamp" to better reflect the data recorded.
Change-Id: Iccf781b25e2573168c36e729419468f5bd73903e
ResearchLogger.latinIME_handleSeparator wasn't doing anything really specific to
the separator, so its implementation has been renamed according to its role.
Change-Id: I24e8691c7dc440dd067e96d23e50463683e17cfc
- 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
Kurt Partridge
Tadashi G. Takaoka