See https://source.android.com/setup/contribute/respectful-code for reference

Bug: 161896447
Change-Id: I171bc299e660f96f20041a67a3052bd8a2ed781c

FileUtils is being used for other non android projects
and hence breaks when built. Instead use the log statements
at caller to record Log.e messages. Hence there is no side
effect here.

Bug:22042371
Change-Id: Ieb100006ff38e013bc30542637465f58bfc0f2f2

This will ensure that a new (or upgraded) keyboard instance will know which
dictionaries are available for download so it requests missing dictionaries.
In addition, we increment the database version number to ensure upgrades of
existing Fava instances start with a clean slate.

Bug 22069694.

Change-Id: Id71310412682543a3931f9c5c03cb0369fa7b9ac

Change-Id: I2ca37bd691abcc036ead8071045d37d72b2d088d

Bug: 20641948
Change-Id: I6639c995b12c033bc30241cd219201dd483ee516

Change-Id: I0ec4aa69d9b5f013ae926cc368e25225d9d3073b

Change-Id: If16ef50ae73147594615d0f49d6a22621eaf1aef

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

Bug: 13125743
Change-Id: I5d111336e6a0f5ab4e93ff333654a7a1f8f46480

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

The bulk merge from -bayo to klp-dev should not have been merged to master.

Change-Id: I527a03a76f5247e4939a672f27c314dc11cbb854

This implements the skeleton implementation, and enables a
fallback implementation in the case the file is coming from the
dictionary provider.
- A better scheme should be used for provider-supplied dicts.
- This does not implement the solution for device-generated
    dicts yet. This will come in a future change.
- This does not implement the checking process on the native
    side yet. This will come in a future change.

Bug: 11281748
Change-Id: Ifa6e237d19dfbffe503e3674915480ea867b0ddf

Change-Id: I44ac89edaba2e57bd1b7e091ff74b77a5e598f2f

Change-Id: Id170dbfe2dcfc93130b7be4a84615940403ec37f

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

Change-Id: I1c5b27c8edf231680edb8d96f63b9d04cfc6a6fa

This change catches a SecurityException if the DictionaryProvider is
unavailable.

Change-Id: I4f2d87327c40765383d8847fd4e934b3cf799488

Bug: 9052555
Change-Id: I86e90488679a78a9f6e901b640025619293765a0

Change-Id: I974964aa3cc24b5480e57bd38c197fe7a49acaa4

Bug: 8651863
Change-Id: I748f35726d72ede926d5b06ed87ff029317f1ac3

Bug: 8376173
Change-Id: Icaac8ad412e0180c44e6a955943e3b208981b2ea

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

Change-Id: Ia9a2e8f0672b3f72943f26fb15de1d3c7c5ce7f1

This also does it for deleting them
Bug: 8167342
Bug: 6789534
Change-Id: I1823f98508881f109a667146d3608003f87aa4cb

...for query.

Bug: 8167342
Change-Id: Ieb8e5b31c4b62bf507593c4631e31799aad5f267

This method is much cleaner and much more readable.

Change-Id: I8055c169ef7c4453ab45c463704bd56a6080da4f

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

Bug: 8173622
Change-Id: Id3dc510ae3535169b5290e87075cb2f433a1f603

This is a cleanup followup to Id3dc510a

Change-Id: Ie64395eb4b6218fd8c73cacddeed2fba1df65d26

Bug: 8173622
Change-Id: Id3dc510ae3535169b5290e87075cb2f433a1f603

Bug: 7005813
Change-Id: Ic3ef69510d2b385d0d403191b2f701b6527d0166

Bug: 7601410
Bug: 7595195
Change-Id: I78cf04dce7c1e64de6725d32317de288a83bd39d

Bug: 6789534
Change-Id: Ie3ea75b19ae4da2dea531e0077c58742a9502bc6

Change-Id: I0ffdbcf6bede86a3cdcb3a0e4ec263398502617c

This creates a new DictionaryInfoUtils class and moves a bunch
of static methods there for later usage.

Change-Id: Iecb0643e6029a7be36bd6cb36aa918c40e6d8c6a

Change-Id: Ic56167f952a7f4449da366e1e81610e72c966086

This finally makes it work.

Bug: 7702011

Change-Id: I3508c88567f79598e4d1dff561b6ba7dc5c3808f

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