Emit a trace when a new dictionary is copied to LatinIME
successfully, not just when it fails. That will help diagnosing
some problems by being able to ensure this step succeeded
looking at the log.
This does not happen often (like, maybe 3 times at device
activation, and once every few weeks afterwards), so I think
the extra line in the log is more than acceptable.
Change-Id: I1674bc22d950a7be801076c5aa7e8bbebccab14b
There is no reason not to contact the dictionary provider
when we don't have internet permission or when the URL
is empty. It knows how to handle both these cases.
Bug: 9388602
Change-Id: I30c4540551ad2f5e527d3acd1842bbd749feca89
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
Improve a slew of logging statements, and put commands that we don't
expect to need protecting against exceptions out of a try {} block.
This is a followup to Id3dc510a
Change-Id: Idc6f419ac095b5b0f2d6862d58926ef888cb34e6
This creates a new DictionaryInfoUtils class and moves a bunch
of static methods there for later usage.
Change-Id: Iecb0643e6029a7be36bd6cb36aa918c40e6d8c6a
In this kind of series of calls, it's possible that an outer call to a
constructor fails, but the inner succeeded.
Example:
try {
is = new A(new B());
} finally {
if (null != is) is.close();
}
In this case, if new B() succeeds but new A() throws an
exception, is stays null and the intermediate object is never
closed. This is what was happening in this instance.
Bug: 7377336
Change-Id: I3fae9fec1135244982fcf5098c76d93f3e0f2add
This introduces a new textual format for the dictionary that combines
words, bigrams and shortcuts to avoid complexity. It is also extensible
to n-grams to fool-prof for the future, and easier to read than XML.
Bug: 7388540
Change-Id: I942bbad51bd0c905a5a54c278667563fd6dd66ec
When a dictionary changes locale, we need to remove the file
that corresponds to the old version. It has a different path
than the new one, so we have to search for it explicitly.
Bug: 6540631
Change-Id: Ie9d63ba636651fe90f8fbb9627b7265ac7b34ccd
Also, optimize quite a bit the code that decides whether we have
a default dict or not.
Bug: 5705834
Change-Id: Ied20fbcbbc42cbe8c01759d11b1804d1156c6960
Checking the magic number of a file upon decoding is necessary,
because if the file is corrupt and we don't check it, we will
fall back to a simple copy of the corrupted file. Latin IME
would realize this and would not crash, but would not use the
corrupted dictionary. If this happened to be a main dictionary,
then the user would lose the ability to use the correct
built-in dictionary.
Not the same, but kinda similar to
Bug: 5223031
Change-Id: Ic2783dc9dd5f3dcf2865623d9452765fe3778db7
The message this removes gets printed under normal conditions.
Normally dictionary files are compressed then crypted, but not
compressed a second time; however LatinIME tries to open a
compressed-crypted-compressed file first, because it could not
do it afterwards and we want to support this case. So under
normal operations, the first method LatinIME tries is actually
expected to fail.
Also, if we decide to stop compressing or/and encrypting dicts
LatinIME supports it as a valid use case. It should not print
errors to the log.
If the file cannot be open at all, then it is an unexpected
case, and Latin IME still reports to the log.
Change-Id: Ic5228c51365a101af1d03e2c893484d3050b5a1c
Now that the dictionary pack can return several files, it's better
to handle IO exceptions for each file rather than globally. This
also will help with next implementation steps.
Bug: 5095140
Change-Id: I5ed135ad2ad4f55f61f9b3f92c48a35d5c24bdb2
