Bug: 17167221
Bug: 17128331
Change-Id: I6a045fd2398f40dbdc10c9d20993f7513e1f2cff

This should make IDEs happy with appropriate source code directory
selection.

Change-Id: Ic734bd4d20aa050c688a3158b1a382ae0ac18991
(cherry picked from commit fb74ab15)

Change-Id: If16ef50ae73147594615d0f49d6a22621eaf1aef

Bug: 15065819

Change-Id: Ie43660109002fdb25ce68d7e64506ada0e15e621

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

Bug: 13125743
Change-Id: I082aa9df1dd4a10cdb3f97ee0692f2d72f6c8e7e

Bug: 13632164
Change-Id: Iba333db63558254d760fc80244b3c9753c26b069

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

This also abstracts away the "package deactivated" case for
simpler and safer code.

Bug: 11072561
Change-Id: Idaaf2ae8d8d5b2c4a15de641bbf2f8c5c7cc9410

Bug: 12788164
Change-Id: If0d815518824a8e57b15e80111c5e6e08e93ba7e

Change-Id: I5cfa0d2fccc139bd6c45c5590a68c3e0c90534b8

Bug: 10118761
Change-Id: I63501d6c2b5f561d7ab8b7362498665d805d5e1e

Bug: 10118761
Change-Id: I63501d6c2b5f561d7ab8b7362498665d805d5e1e

Bug: 10118761
Change-Id: Ia7d1c6c526dae849f447c26387e96a4fb4d6042f

Change-Id: I7290cd1fb675a1b85b9b6ac2d464c932b5bca1dd

Bug: 9715797
Change-Id: I1eda4d2f0056f70cfb8a92d658e0875706efc170

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

This resulted in downloads not being correctly canceled.

Bug: 9715797
Change-Id: I786d869977df225f85cb69ec7ea9c96b039258fe

Change-Id: I7294d1547def5dcfcae9d1d53b277cb3cc9f2d18

Bug: 9550800
Change-Id: I087205530a5dbcff4bf08f48f4aa7068aae93215

This patch does two things:
- If there is no URL to download new data from, then the
Refresh button is not shown.
- Even if for some reason refresh starts for a client for
which there is no URL, loading correctly finishes.

Bug: 9388602
Change-Id: I3fd9214da50faa4b59d0bd3e775293dd34f07547

Change-Id: If2f7bd1346cc5085bf57645830f0faac44d017e4

Change-Id: I1c5b27c8edf231680edb8d96f63b9d04cfc6a6fa

This is to avoid confusion if multiple IMEs are installed with
dictionary pack components

Change-Id: Ibc91951e4fdd5db13f681e4cb06197da98527bbc

This is a bit of a shot in the dark, as I really don't see how this
can happen, but this should fix it in the correct way no matter
how it's actually happening.

Bug: 9301836
Change-Id: I472865b7a78883942c9fd46773238c23788674f8

Bug: 9166225
Change-Id: I7490593d88a5854b9e675b9ead89d2ea9b49315c

Bug: 9052555
Change-Id: I86e90488679a78a9f6e901b640025619293765a0

It turns out giving them in the right order is not enough, you
also have to actually give them a numeric priority.

Bug: 9165928
Change-Id: I2ecff38f65b70746feeeeb0ed2cc86a586a35363

The default implementation for preferences refuses to
cache the views for custom preferences at all. We can
do it, but the system won't do it for us, so this does it.
This makes the screen scrolling smooth again.

Incidentally it also fixes the bug where the button may
not animate on the first element.

Bug: 8882722
Bug: 8883108
Change-Id: I9b2306ac4bf93761a808ebfee3477a65f017cddf

Bug: 9112465
Change-Id: I6cd63007287b5a1a57cfbabff35d53f66fc5620e

This is an optimization. It also happens to work around what
seems to be a framework bug in JB MR1 / MR1.1.

Bug: 8771179
Change-Id: I62cc7acdc8656d75f8a50c068c4e9d8c6ceb74a0

Bug: 7600384
Change-Id: I33ea155c0c97c7ead07686c4d2a9e0d98be9929c

Bug: 7600384
Change-Id: Iaa8f3a59243a15d2a01aaf6017ed85c52b6482a6

This ensures the thread does not run uselessly (it is even terminated when
the progress bar exits the screen).

Bug: 7600384
Change-Id: I09117a6f763b574b9b3266f36ba3da4720dc9224

Bug: 7600384
Change-Id: I55b51152dd9968a359af091bf309f0d406f63ec4

The progress bar is showing but doesn't show progress yet.

Bug: 7600384
Change-Id: I80debd3f4368e82e4184a6c638bdcc8e48ed2305

Clicking on a button that is animating-out is only done by
mistake. Better make them unclickable.
Also, interrupt an out-in animation if it has been preempted.

Bug: 7600384
Change-Id: Ic4700cda46a894ea580bc67ee7bef885ecf1d3bc

Bug: 7980985
Change-Id: I4c9165e6102cb12fa1249074297e94013439ea3b