The life span of this object is actually the life span of the interface.
It should not be static.
Also, we'll have a few other things to store in there soon.
Bug: 7600384
Change-Id: I708019e9ee53653e83a1e52c8e76326c3e39bcf3
This preference is not a DialogPreference any more, as it doesn't
ever display a Dialog.
Bug: 7600384
Change-Id: Ia5965617c83d3cb964010f9b40d833065dccef60
LogUnits have been annotated with the autocorrected words, but
until now this was assumed to be a single word without spaces.
But spaceless typing can result in spaces in the LogUnit label. With this
change, the LogUnit inspects the autocorrected text to determine how many
words were inserted, and counts them accurately.
This change corrects a privacy problem, which was that if the word sampling
algorithm chose a LogUnit that actually contained multiple words, then more
than two successive words would be included in the log.
Change-Id: I7c01c3dd3ac33d7e96c00836256bae9c14b124ed
This is a preliminary implementation because the welcome screen video
is just a placeholder.
Bug: 8159728
Change-Id: I6a2459a266babec2f078fc393b18c77b0b7992a8
Also, theoretically, we don't want to retrieve older suggestions if
there are no results for a recorrection - that would look random.
This bug addresses this too.
Bug: 8657919
Change-Id: I44f36d34a708a968ab71fa0592da57f4c97d4b7f
What do you mean "Can't happen"?
It happens all the time - the empty string is the default ID, and it
needs to be updated like everyone else.
Bug: 8651858
Change-Id: I5a2f2ebb5b2ef08b27f26be8fb2c3d2f231ebcfc
Previously MainLogBuffer#shiftOutWords() assumed it wouldn't be called if
mNumWordsUntilSafeToSample was 0. This relaxes this assumption (which is in fact
false in the current code).
Change-Id: I8723248095e84a0d9d6f4639b4742cc7dda9716b
Clicking the "include recording" checkbox in the user feedback dialog did nothing.
The code was relying on the state of the checkbox, rather than keeping its own state.
Fixing this addresses the bug.
Change-Id: I559d57a4e11f869f6e6f5e5de7878f765531a203
Previously only a commitText would cause a LogUnit to be
labeled with the word that the data generates. In the case
of gestured text, this information is available when
LatinIME#onEndBatchInput is called. Labeling the LogUnit
at this time means that the Log will have labeled words even
if stop() is called before commit.
Change-Id: Idb2f99a9c159a1b1aa00448a2ecddeca6c351c3e
System is fast enough that sometimes SystemClock.currentTimeMillis() is duplicated
when used to make a unique filename.
Change-Id: I9454fbb5e10265d36b8e17cba183a1591d52cc7b
This is about as ad-hoc as it gets, but then again, what we want
is probably as ad-hoc as it gets.
All URL boxes I know of double as search bars, and not adding
automatic spaces there sucks (e.g. in Chrome URL bar).
And in other boxes actually you don't want to add a space if
it looks like a URL. QSB isn't even a search box, and it behaves
like this.
So I think this is actually the right answer to the problem.
Bug: 7062925
Change-Id: Ib09472b34644fd5bf2dc84bb97cedeeba28bcd02
The only place where it's used is checked for nullity.
Also, it's possible, also difficult, to match a different
recapitalize with the old code, triggering a bug that
this fixes.
Change-Id: I717d6df489025c75d1caca290a9086c3b39a9306
Upon pressing Shift, if there is currently a selected string, have
Latin IME change its capitalization.
This does not yet have the keyboard mode follow the mode - the change
is complicated enough as is.
Bug: 7657025
Change-Id: I54fe8485f44e04efd72c71ac9feee5ce21ba06f2
If the user gestures a word, then hits backspace in
disapproval, and gestures about the same thing again,
make sure that we don't suggest the same thing again.
Bug: 7549311
Change-Id: I793bc4df7c3841fa8f2f4146707c26e873f374c1
There are two problems here. The first one is the tests would send
an invalid unicode character. Although we could want dicttool to
handle this more gracefully, it's fine for now.
The second problem is much more serious. If a node has more than
128 children, then the java code will crash trying to read the
dictionary back because of a bug that this change fixes. In
theory, it's possible that happens when we try to load the user
history dictionary back from the disk - native code is not affected
so there is no other point that may cause a problem.
In the practice, that means you'd need to have 129 words with a
common prefix (including empty string) but all different after
this. It's almost impossible with Google Keyboard since there are
only so many keys on the keyboard that you can make a word out
of, and then again you'd have to do it repeatedly until it
actually enters the user history dictionary, wait for it to get
saved on the disk.
The bad news is, if you manage to get this far, the keyboard will
crash every time and won't be able to get up until you clear
data for the package.
The good news is, the dictionary itself is not corrupted and only
the reading code is wrong. So updating to a newer version would
actually even recover from this situation.
All in all, considering how almost-impossible this is to trigger,
I don't think even a single user actually did hit this bug.
Bug: 8583091
Change-Id: Iabb2a7f47cbd9ed3193d2a3487318d280753e071
This uses the old suggestions. It does not try to recompute
new suggestions if there are no old suggestions yet: this is
coming in a later change.
If there are no suggestions, this shows the word itself
as a suggestion.
Bug: 8084810
Change-Id: I4c2e25df0ff3673be1825f57a0c19a9d23d47a48
Calls to LatinIME#onStartInputViewInternal log important information
about the context in which an IME is used. This is reported as a
single LogStatement. Previously, this was not placed into a separate
LogUnit, and was mixed in with general word data. This change wraps
this LogStatement in its own LogUnit.
Change-Id: I0fecd41c8a1de622a764cc4b5d6902336697046c
The ResearchLogger reports whether a build is a release build or not
to avoid polluting data with IME debugging work by developers.
Previously this was done by checking a constant flag, which was also
serving the dual purpose of masking out debug code in release builds.
This change introduces a heuristic to determine whether a build was
created by a developer (using the package versionName), and annotating
the data sent to the server appropriately.
Change-Id: Icbad17c66b703cabf6d23d05e2c7c41bcceaae45
Both bugs only affect debug mode. One has the wrong object tested
with equals, the other has the iteration failing in some cases.
Change-Id: Ie9100d257a3f9e3be340cf3e38116f63417bdc1a
Previously logging was disabled during replay. This makes it impossible to use logged data as a
regression test, since the new log was unavailable. This change corrects this problem.
Change-Id: I19dc31def2f2f87fd219dc561c739d18e4ab9c9c
Previously handleSeparator() caused the ResearchLogger to mark the time at which a LogUnit should be
broken. However, this causes the motion data associated with a separator to be associated with the
LogUnit of the previous word. This change corrects this bug.
Change-Id: I8b4d4fa6de2a013de9e2a28bb668c446a07f1957
Upon invoking the settings of the dictionary pack with an unknown
client, we now launch an intent to ask the client to make itself known.
This change also includes the code that receives this intent and
acts upon it.
Bug: 8492879
Change-Id: I2c6496dea845646961ecafcf64e282cb93ee91dc
The important bug is in findWordInTree. The problem, which is
not obvious, is that we were calling codePointAt() with the
code point index in the string, instead of the char index.
The other bug this change fixes was harmless in the practice,
because it's in the iteration which is only used for debug and
pretty printing purposes. It's very similar in that it would
substract a length in code point to a length in chars and
truncate a StringBuilder at that length, so it would fail in a
quite similar manner. This changes the meaning of the "length"
attribute in Position, but it's clearer this way anyway.
Bug: 8450145
Change-Id: If396f883a9e6449de39351553ba83f5be5bd30f0
Previously an autocorrection caused a new LogUnit to be started,
splitting off the previous LogUnit right at the autocorrection method
time. This change causes the split to happen before the MotionEvents
that led to the autocorrection being called.
Change-Id: I2504df8eb47ee77e5f46bac34a8450636c03fd9f
Previously, ResearchLogger#onWordFinished() was called with an outdated parameter value for
isBatchMode, causing it to report false even for gestures. This changes fixes this problem.
Change-Id: Ifcabee236ba5fe20376ad882155d3f3142cd7613
- Move scheduling logic from ResearchLogger.java to
UploaderService.java
- Switch to a one-shot timer. Previously the uploader was scheduled
on an inexact repeating schedule. It's better to reschedule the
next upload after the current one is finished to reduce the chances
of multiple uploads happening at the same time.
- Avoid double-execution
- Previously a scheduled upload might run right after an explicit
one if they occured at the same time. This change reduces the
chances of this.
- Some method extraction and naming
Change-Id: I9efda11be77d334c7f61bd40a36d65f0421ebde4
Previously, ResearchLogger#stop() was called both in
LatinIME#onFinishInputView() and in LatinIME#onWindowHidden(). This
resulted in multiple logs being written.
Since onFinishInputView is the more reliable of the two (it is called
in InputMethodService#onDestroy; onWindowHidden is not), the code now
uses onFinishInputView as a stopping signal.
Change-Id: Iae4b8c3bdab226027624eeab19b3737367e4a108
