It turns out we were not returning the density for anything retrieved from a
TypedArray... which basically means any bitmap references from a layout or style...!!!
This is now fixed.
Also fiddle with the density compatibility mode to turn on smoothing in certain situations,
helping the look of things when they need to scale and we couldn't do the scaling at
load time.
An issue with the density API is that bitmaps assumed the old default density,
so new programs would have to explicitly set the correct density for every bitmap
they create.
This is an attempt to fix that situation, by define the default density of bitmaps
to be the main screen's density, except for old apps where it is the original default
density.
Actually implementing this is not so great, though, because the Bitmap constructors
can't really know anything about who is calling them to know which density to use.
So at this level the compatibility mode is defined per-process -- meaning the initial
package loaded into a process defines the default bitmap density, and everyone else
loaded in later on has to live with that.
In practice this shouldn't be much of a problem, there shouldn't be much mixing of
old vs. new apps in a process. It does mean that, going forward, if a developer is
going to use shared user IDs for this, they will need to make sure either that all of
their apps are in the same compatibility mode, or that their code explicitly sets the
density of bitmaps it receives. This isn't all that great, but I think it is worth
the benefit of allowing people who write modern apps to not have to deal with bitmap
densities.
This change also does some cleanup of the density management (making sure to always
copy over bitmap densities, etc) and adds java docs to explain the various ways
density is set and used by the system.
This change allows us to use drawables that match the current screen
density even when being loaded in compatibility mode. In this case,
the bitmap is loaded in the screen density, and the bitmap and
nine-patch drawables take care of accounting for the density difference.
This should be safe for existing applications, for the most part, since
they shouldn't really be pulling the bitmap out of the drawable. For
the small rare chance of them breaking, it worth getting the correct
graphics. Also this will only happen when there is actually a resource
of the matching density, and no existing apps should have resources for
anything besides the default density (though of course all of the
framework resources will be available in the native density).
As part of this, the bitmap density API has been changed to a single
integer provider the DPI unit density.
Before this change, DrawableContainer would always return true from getPadding(Rect)
even if all of its children were returning false from getPadding(Rect). This change
modifies this behavior to respect getPadding(Rect): mConstantPadding is kept null
when getPadding(Rect) returns false for all of the children and a flag is set
to avoid recomputing that value every time getConstantPadding() is invoked.
The Bitmap functions to get the scaled width/height couldn't actually
do the right thing because they didn't know the destination they would
be drawing to. Now there are two forms of them, taking an explicit
parameter specifying the destination.
ShapeDrawable.inflateTag() handles the 'padding' tag with the standard
attributes android:left, etc. The attribute values for these standard
attributes should be dimension specifications, e.g. '4dp'.
ShapeDrawable.inflateTag() was wrongly parsing the attribute values as plain
integers.
NinePatch.mPaint may be null and most methods in this class handle
that case properly. However, the constructor which derives a new
NinePatch from an existing instance assumes that mPaint is non-null.
This results in an unexpected NullPointerException, for example when
attempting to call NinePatchDrawable.mutate() on an instance that was
created from a resource.
Small unrelated fix in same file: Remove unused private mRect member.
DrawableContainerState.mDrawables is an array which may be only partially
filled, as can be seen in the constructor and the addChild() method.
DrawableContainer.mutate() wrongly assumed that the array does not contain
null references.
The mColors member can be null, as can be seen in
GradientDrawable.setSolidColor() or the plain constructor. In that case, an NPE
will be thrown on attempts to derive a new GradientDrawable from the instance
using the private constructor GradientDrawable(GradientDrawable).
The problem also occurs when inflating a GradientDrawable from XML without
defining the start, center and end colors and then calling mutate() on the
instance.
The function is used to rebuild any caches associated with the bitmap.
In the case of purgeable bitmaps, this call ensures that the pixels
are decoded for drawing, and therefore prefetching techniques
implemented by callers can be leveraged.
before the native canvas instance was created.
If the canvas constructors throw an exception (because the bitmap passed in is
immutable or already recycled), the constructor terminates early without
allocating the native canvas instance. For the most part, that's okay, since
the Canvas instance will never be returned to the application. However, the GC
will still call finalize() on the half-initialized Canvas.
The native methods for Canvas all assume that the canvas pointer passed down is
not null.
* Introduced ApplicationScale (may not be good name. CompatibilityScale? CanvasScale? Pls let me know if you have better idea)
* Changes to RootView / SurfaceView
- Makes the app believe it's running in the supported density/resolution.
- Makes the window manager believe it's running at the right density/resolution.
* Added methods to Rect/Event for scaling up/down.
Known issues:
* certain kind of images (such as nine patch for buttons) seesm to be loaded not by app, thus does not take the scale into account,
which, in turn, is causing layout issue.
* ZoomButton in MapView is rendered in wrong place
* Transparent region on Surface is not correct
* Specifying different densities in one process is not working.
BUG=1770627
Automated import of CL 147976
BitmapFactory::Options now let you specify if the resulting bitmap can be
"purgeable". If so, then its decoded pixels may be purged when not actively
being drawn, freeing up that RAM. When such a bitmap is drawn, it will
automatically be re-decoded on demand. This is done by having the bitmap
keep a reference/copy of the encoded data.
Where it is a reference or a copy is controlled by the "shareable" flag in
Options. If this is true, the implementation *may* just reference the encode
data (e.g. a file descriptor) rathern than making a complete copy of it.
Currently, purgeable is not supported for generic inputstreams, but is
enabled for byte-array, file-descriptor, and assets, though for impl
reasons only file-descripts are currently enabled for "shareable", but that
may change in the future.
There are three major classes of changes here:
- Avoid writing lines where their values are often empty, false, or some other typical thing.
- Use partial writes to the PrintWriter to avoid creating temporary strings.
- Use StringBuilder where we need to generate real String objects (and where possible cache the result).
