Ensures changing configurations mask is propagated to the host drawable
so that it can be properly cleared from cache on configuration changes.
Also fixes constant state handling of the mask in the Inset and Rotate
drawables.
Hides new ColorStateList methods related to theming, since they should
only be used during preloading or internally by framework drawables.
Fixes bug where the cached versions of themeable ColorStateLists were
modified by calling applyTheme() on the host drawable.
Also cleans up some docs and naming in GradientDrawable.
Bug: 19966397
Change-Id: I8c8d3cabbaf94b488c2b8fe9fd423e07d824c19c
Removes all implementations of three-arg ConstantState constructor, since
we handle mutation and applyTheme() in Resources now. Moves progress bar
tinting to android:tint attribute. Correctly implements applyTheme() and
canApplyTheme() in all drawable wrapper and container classes.
Change-Id: Ic9cb43d0d6228aa4914f3124bed234b837beaa41
This ensures that drawables are completely separated from their cached
constant states before applying a theme. After this, we can remove the
implicit (and incomplete) mutation in the clone constructors.
Also implements missing mutate() method on ClipDrawable.
BUG: 17646144
Change-Id: If0d66b0a85724d76e0a4f506758c7ba3c0aa3410
Adds a missing JNI binding to AssetManager, ensures drawables have
default tint modes as documented, and updates vector tint appropriately
when state changes.
BUG: 17385604
Change-Id: Ice92885989ebc13b95952f5dc3b7904cc956da12
Previously, calling setLocalMatrix updated any Paint that had the
Shader attached. This depended on deprecated behavior in Skia. Use
new Skia APIs, and do not modify any Paints that use the Shader.
In addition, update callers to call setShader (again) after modifying
the Shader.
Sample app at ag/499573 for testing.
Depends on I673801444f0a8fd4f192b5b7effdde1aa83e702b in external/skia.
BUG:14315916
Change-Id: I3c3316377874e89fccc85afb864bc038b0ef3890
Adds themeable attribute support to InsetDrawable, adds support
for attribute configuration changes to all themable drawables.
BUG: 16045735
Change-Id: I3dc62d28801760ac69d303be81b6c78bb9bb5aca
Add optical inset support to BitmapDrawable with gravity. Fix optical
inset support in DrawableContainer. Fix visibility change support in
AnimatedStateListDrawable. Adds a whole bunch of missing drawable
support to CheckedTextView.
BUG: 15127013
BUG: 15126976
BUG: 15125529
BUG: 15025806
BUG: 14597955
BUG: 14594498
BUG: 15152746
Change-Id: Id2d99e10838d25b6f927ca1e49996c8da8e78ab1
When Drawables are inflated during preload (or otherwise without a theme)
they cache their themeable attributes in their constant state as an array
keyed on attribute index. Drawables inflated with a theme will simply
resolve theme attributes as part of normal inflation, and they will not
cache any themeable attributes.
Drawables obtained from Resources are pulled from theme-specific cache
when possible. If an unthemed Drawable exists in the preload cache, a
new constant state will be obtained for the Drawable and the theme will
be applied by resolving the cached themeable attributes and overwriting
their respective constant state properties. If no cached version exists,
a new Drawable is inflated against the desired theme.
Constant states from themed drawables may be cached if the applied theme
is "pure" and was loaded from a style resource without any subsequent
modifications.
This CL does not handle applying themes to several Drawable types, but it
fully supports BitmapDrawable, GradientDrawable, NinePatchDrawable,
ColorDrawable, and TouchFeedbackDrawable.
BUG: 12611005
Change-Id: I4e794fbb62f7a371715f4ebdf946ee5f9a5ad1c9
Cleans up APIs a little, since I think we may want to add tinting
modes beyond what Porter-Duff can provide. Plus we don't actually
support some of the Porter-Duff modes in hardware.
Change-Id: I2cea1b737cc93607a24842c54eb9f0d8346b29d4
Plumb through the necessary API features through Drawables and
ImageView but leave it hidden for now pending future API review and
plumbing through the rest of the framework Drawable implementations.
Update SeekBar assets used for keyguard transport control.
Set selected status directly instead of finding views by id.
Bug 10531608
Bug 10784913
Change-Id: Ia38bd04ad1bc26e9e6da1dda8a374c9ba3ceccb3
- default value is "no mirroring"
- introduce android:autoMirrored as a new attribute for Drawable,
BitmapDrawable, LayerDrawable, StateListDrawable and NinePatchDrawable
- setting android:autoMirrored="true" means that the drawable will
be mirrored when the layout direction is RTL (right-to-left)
- also fix an issue with ImageView drawable layout direction not
updated correctly when RTL properties were changed
See bug #7034321 Need Drawable RTL support
Change-Id: If595ee5106c786f38e786d3a032e182f784a9d97
When the Android runtime starts, the system preloads a series of assets
in the Zygote process. These assets are shared across all processes.
Unfortunately, each one of these assets is later uploaded in its own
OpenGL texture, once per process. This wastes memory and generates
unnecessary OpenGL state changes.
This CL introduces an asset server that provides an atlas to all processes.
Note: bitmaps used by skia shaders are *not* sampled from the atlas.
It's an uncommon use case and would require extra texture transforms
in the GL shaders.
WHAT IS THE ASSETS ATLAS
The "assets atlas" is a single, shareable graphic buffer that contains
all the system's preloaded bitmap drawables (this includes 9-patches.)
The atlas is made of two distinct objects: the graphic buffer that
contains the actual pixels and the map which indicates where each
preloaded bitmap can be found in the atlas (essentially a pair of
x and y coordinates.)
HOW IS THE ASSETS ATLAS GENERATED
Because we need to support a wide variety of devices and because it
is easy to change the list of preloaded drawables, the atlas is
generated at runtime, during the startup phase of the system process.
There are several steps that lead to the atlas generation:
1. If the device is booting for the first time, or if the device was
updated, we need to find the best atlas configuration. To do so,
the atlas service tries a number of width, height and algorithm
variations that allows us to pack as many assets as possible while
using as little memory as possible. Once a best configuration is found,
it gets written to disk in /data/system/framework_atlas
2. Given a best configuration (algorithm variant, dimensions and
number of bitmaps that can be packed in the atlas), the atlas service
packs all the preloaded bitmaps into a single graphic buffer object.
3. The packing is done using Skia in a temporary native bitmap. The
Skia bitmap is then copied into the graphic buffer using OpenGL ES
to benefit from texture swizzling.
HOW PROCESSES USE THE ATLAS
Whenever a process' hardware renderer initializes its EGL context,
it queries the atlas service for the graphic buffer and the map.
It is important to remember that both the context and the map will
be valid for the lifetime of the hardware renderer (if the system
process goes down, all apps get killed as well.)
Every time the hardware renderer needs to render a bitmap, it first
checks whether the bitmap can be found in the assets atlas. When
the bitmap is part of the atlas, texture coordinates are remapped
appropriately before rendering.
Change-Id: I8eaecf53e7f6a33d90da3d0047c5ceec89ea3af0
Drawable has setAlpha(int), but no getAlpha() (although some subclasses have added the
method). This makes it more tedious to use the property. For example, animations that wish to
animate this property must explicitly give it a start value since this value cannot be queried
from the object.
The trick is that setAlpha(int) is abstract, only implemented by subclasses. We cannot take this
approach for getAlpha(), as we would break all subclasses of Drawable until they implemented the
method. Instead, we'll add a default method which returns an invalid value, making it easier for
clients of the method to detect whether the value is valid.
All subclasses of Drawble in frameworks have been changed to add an override of getAlpha() when
appropriate.
Issue #7485875 Drawables is missing getAlpha()
Change-Id: I06b6e35f1a56d202838eca44759c85c82595020a
This attribute can be used to enable/disable mipmapping on bitmaps.
See Bitmap.setHasMipMap() for details.
Change-Id: I13cc800a258b6876a94e2a9605dcec4ea4f1ea48
Bug #7117785
Draawables created from the ConstantState cache found in Resources must be
mutated before they can be safely modified by apps. Failure to do so results
in all drawables sharing the same constant state to be affected by the
modification.
In the case of the bugreport above, the status bar code plays tricks with
a background drawable and modifies its color to implement a fade in/out
effect. This drawable comes from a cached resource (color 0x0) and the
modifications made by the status bar apply to other clients of this drawable,
most notably the recents panel.
This change fixes several things:
- Simplifies colors caching by removing the assetCookie from the key. This
should result in better reuse of cached drawables
- Makes View.setBackgroundColor() honor the mutate() contract
- Ensure StateListDrawable properly mutates its children before modifying
them
- Optimize Bitmap/ColorDrawable to mark them mutated when they are not
created from an existing ConstantSate. The same optimization should be
applied to other drawables in the future
Change-Id: I54adb5d5b914c7d8930bf9b46f7e3f9dcbf4bcab
