Does the following
1. Uses dictionaries from the files/ directory while populating the
entries into the pendingUpdates table. So that a download happens only
if the metadata.json says so.
2. Delete an unusable dictionaries from the files/ directory.
Bug: 20142708
Change-Id: Ibd738793585c39735868e324b8ad682dff0eba34
This CL fixes the following compiler warnings.
- Indirect access to static member
- Access to a non-accessible member of an enclosing type
- Parameter assignment
- Method can be static
- Local variable declaration hides another field or variable
- Value of local variable is not used
- Unused import
- Unused private member
- Unnecessary 'else' statement
- Unnecessary declaration of throw exception
- Redundant type arguments
- Missing '@Override' annotation
- Unused '@SuppressWarning' annotations
Bug: 18003991
Change-Id: Icfebe753e53a2cc621848f769d6a3d7ce501ebc7
1. Add retry count column within metadata in dictionary pack.
2. Attempt a retry for download and installation by running StartDownloadAction.
3. If the number retrial are at the threshold, we don't attempt it again.
Bug: 15150487
Change-Id: I70720353e5803fccf4728c2aa798883ba75c61e5
This should make IDEs happy with appropriate source code directory
selection.
Change-Id: Ic734bd4d20aa050c688a3158b1a382ae0ac18991
(cherry picked from commit fb74ab15c1)
If it doesn't match, mark it broken. It means the dictionary pack
will try to install it again next time it updates. We may want to
rethink this.
Bug: 13125743
Change-Id: I0eb547aa7066bed8cb00c009debbafe9181c37ad
Some were never closed, other closed twice. This change
makes all Cursor instances behave, having the #close()
call in a finally{} clause, and puts the burden of closing
the cursor squarely on the creator rather than in the
called methods.
There is however one exception that is beyond the scope
of this change: UserDictionarySettings have a Cursor
member, it's never closed, and fixing the problem is not
obvious. This change adds a TODO for now.
It's not very clear if this change actually helps with
bug#12670151, but it may be related and it's a good
think to do anyway.
Bug: 12670151
Change-Id: I87cc44387e7dee3da1488671b93a28d9d73f7dc0
I'm not sure when this can happen, but it seems it does
at least on older versions of the platform. Let's avoid
crashing.
Bug: 11618402
Change-Id: If730b5bd8f20e0f60b884eab5900099116afc5f0
There are many ways to fix this problem but this is the most
direct way. Removing a view from the cache when any animation
is started will ensure it won't be used again, and will be garbage
collected when it's possible. Since views are created on demand
anyway, a new one will just get created when needed, and that's
it.
Bug: 9400128
Change-Id: I4945d2859d642e79694d51ae90cf4f5bde9a5f1d
