Background:
Both SubtypeSwitcher and VoiceConnector have an instance of VoiceInput.
And VoiceConnector has a responsivity for setting VoiceInput to SubtypeSwitcher.
But in case that VoiceInputConnector already has an instance of VoiceInput
VoiceInputConnector doesn't set VoiceInput to SubtypeSwitcher.
Change-Id: I42d0220e7d84a08e03f143213cc6eff87e7e79a6
This change adds basic support for an external dictionary provider.
It adds methods for reading the dictionary itself from an asset in
the dictionary provider package directly, obtaining the file name
through the ContentProvider interface; it also adds a way of getting
the data through an InputStream and copying the file locally.
Incidentally this change also adds the code needed to listen for
updating the dictionary provider package and reloading it in time.
This change also goes hand-in-hand with Iab31db6e, which implements
the small closed part of this.
Issue: 3414944
Change-Id: I5e4fff99a59bb99dbdb002102db6c90e6cb41c8a
This changes:
* Flag initialization code in BinaryDictionary to be more unit test friendly.
* Removing unnecessary class hierarchy of LatinIME inner class WordAlternatives.
* Formatting normalized score neatly.
Change-Id: I9f10c093d4f36258fe883cf3fb10cbbda2770497
This change also corrects usage of "frequency", "priority" and "score"
* Frequency is the relative probability in dictionary.
* Score is the relative probability in suggestions.
* Priority is kind a sorted score.
Change-Id: Iafb135a4ecdb401cc505014a07c74dfcac44d699
It used to be the case that the scoring system turns up the same word
that was entered with a different capitalization, but with a lower
score than some other, more frequent word. To cope with this, there
was code that would order such candidates in the first slot no matter
what. This processing is now useless because fully matching words now
have a huge boost that ensures they will get to the top of the list,
before any non-fully matching word (which means, differing only by
capitalization or accents).
The bug that did happen with this was, if a fully-matching word got
matched by several processing passes, and the (chronologically) later
score affected to this word was weaker, it would result in the
duplicate removal pass removing the stronger score. This in turn would
mess with autocorrect.
In an effort to keep the risk at a minimum for MR1, this change does
not actually remove the useless code, but adds a check in the odd case
to avoid the bad situation. Another change will remove the code for
ICS release.
bug: 4100269
Change-Id: I18c0575332981ffec0e257e26a360995838d521e
