History log of /frameworks/base/core/java/android/util/LongSparseArray.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
9c1d2980f2c7c73f098d551499c4fd48cdc96b4d 10-Feb-2012 Dianne Hackborn <hackbod@google.com> Clean up and expose LongSparseArray.

Change-Id: I15ba98d65e790ba45391cc7714f60b6e7de6ebfc
8f1bfe1a7cef702fd74e5405443e9fdb7c5e7556 06-Mar-2010 Adam Powell <adamp@google.com> ListView#getCheckItemIds() deprecated for ListView#getCheckedItemIds().
ListView#getCheckedItemIds() now works more reliably.
fdbf6a7eac39a23e0e910c29678fe00d4eb56c99 19-Jun-2009 Romain Guy <romainguy@android.com> Fixes #1922373. Resolves a case of keys collision in Resources' cache.

The Resources class keeps a cache of known resources. The keys used by the
cache are stored as int primitives. For any given drawable resource, a key
is built thusly:

TypeValue.assetCookie << 24 | TypedValue.data

In the case of a plain color drawable, assetCookie always equals -1, that
is 0xFF once right-shifted and the data contains the color value. Which
means the key for the following two colors is the same:


Because of the int storage and the use of the (constant in this case)
asset cookie, the alpha channel of a color is ignored. That means that
if you first load an opaque black color (0xFF000000), subsequent loads
of a totally transparent black color (0x00000000) will give you an
opaque black color.

A workaround is to use a transparent color that is not black,
0x00000001 for instance. Note that this issue would arise with any color
and any opacity level.

The solution to fix this issue is simply to change the cache to use
longs instead of ints to represent the keys. A key thus becomes:

TypedValue.assetCookie << 32 | TypedValue.data

This allows us correct storage of all colors at the cost of a few bytes.
The tradeoff is that we can keep caching ColorDrawable, which is
definitely worth it.