This CL works around Animator's lack of support for applying a theme
after inflation by postponing Animator inflation until a theme is
available, either in inflate() or applyTheme().
Includes a workaround for AVDs that don't reference any theme attrs
in their animators and this don't require a call to applyTheme().
We'll follow up with real support for applyTheme() in Animator, at which
point we can remove this workaround.
Bug: 20817800
Change-Id: I5a378a76e3625b9d754cb74ae98c07ba7c5698e5
And you may ask yourself: what is that beautiful icon?
And you may ask yourself: where does that API go to?
And you may ask yourself: is it a resource? is it a Bitmap?
And you may say to yourself: my god, what have I done
(This patch fixes a number of bugs in the initial
implementation, but other than that, it's the same as it
ever was.)
Bug: 18568715
Bug: 21141842
Change-Id: I1d3f9427abd7f0bb57e533fcfac708851ff644b6
This CL fixes the issue where when start is called, we run the next frame
of the animation drawable while mCurFrame is already set to 0. The result
is that the first frame of the AnimationDrawable is then skipped.
Bug: 21168854
Change-Id: I2b77ae017d3debd0f8cfec81ea86d1120e78bb55
This works around situations where corrupted packages cause
Resources.getResourcePackageName to return something that
does't actually work.
Bug: 21144636
Change-Id: I271518599a8eb89d493f1ceda6cb2e47fb38a4ff
This reverts commit 08a04c15245c970856022d0779aa27d4d63cdee3.
This also reverts commit 5bcbf857d129f4513e562801a4e88077b2655ade.
Change-Id: Ia0b0a5339d523581c877822a3a1feec97ae4b73d
And you may ask yourself: what is that beautiful icon?
And you may ask yourself: where does that API go to?
And you may ask yourself: is it a resource? is it a Bitmap?
And you may say to yourself: my god, what have I done
Bug: 18568715
Change-Id: I4377b311c538bd1cf36b3fba22326bae81af40c9
- Reorder parameters to loadDrawableAsync()
- New version of createWithResource that takes a package
name instead of a Resources
- Add loadDrawableAsUser() for INTERACT_ACROSS_USERS clients
like SystemUI
- Docs cleanups
Bug: 21089268
Bug: 21031774
Change-Id: I465d2b865e35e12094b564f994e59d55e522f65a
Use the dedicated flag mRunning to check whether the DrawableAnimation
is running, rather than comparing mCurFrame with -1. This CL aims to
simplify the use of mCurFrame.
Bug: 17112962
Change-Id: I15f9e4c102f504b8c806f029949fe9ec872479a5
Bug: 20940526
Rather than throwing an exception on accessing a recycled()
bitmap let certain operations succeed and just return dummy
values. Apps appear to be relying on this.
Change-Id: I74df2efdc29d93facd8553ed31cda3addf0b28eb
We are passing the wrong parameters for setting hotspot bounds.
Bottom and right are in the wrong order, correct it.
Change-Id: I2762fc3a4c29f05ba8b7e71a5c6cad0be16c2ae0
We are passing the wrong parameters for setting hotspot bounds.
Bottom and right are in the wrong order, correct it.
Change-Id: I2762fc3a4c29f05ba8b7e71a5c6cad0be16c2ae0
Fix the issue where Bitmap requires two GC passes
to release its byte[] by using some questionable
ref-counting hacks to manage whether or not
native has a strong or weak ref to the byte[]
Change-Id: Ia90a883579f61c0b1904b5549a66bd0ef34b32c5
The docs are now really explicit about the layer's ID and how to set
or update the mask layer from code.
Bug: 20493831
Change-Id: I801f10cd08fd1b4bb226c63a1bdf3271229928ea
Binder APIs which wish to consume Bitmaps *and* drawable
resources can now do so by using Icon, a kind of union type
that accommodates each of these. Icon also accepts byte
arrays holding compressed Bitmaps (PNG, JPEG, etc), which
saves clients the additional memory cost of decoding and
sending full uncompressed bitmaps through Binder interfaces.
Receiving clients can call loadDrawable{,Async} and then
getDrawable to start immediately using the image in an
ImageView or other Drawable-hosting container.
Bug: 19609468
Change-Id: Ic1343711c2ac0b15876b46f0b6008b0108a49470
Switch a few places to using android::canvas
instead of SkCanvas as well which eliminated
some JNI
Change-Id: I8f98b56442a06362b82b984cd1bd3a92398d8dbc
Stop assuming that a Java Bitmap has a SkBitmap* that
has some externally managed lifecycle, and instead switch
a bunch of users to accessing the bitmap by providing
their own SkBitmap* on which to set the (ref counted!)
SkPixelRef* instead
Attempt #2 to land this, original issue was in getSkBitmap
and should be fixed
Change-Id: I0fd9e193968b41e5597784140d56b4885906864a
The developer used to be responsible for this and automatically
propagating the values breaks some use cases (ex. in Camera).
Bug: 20696311
Change-Id: Ia8ddc132c6d629bcc27d66f654baf30d9f078568
