The original intention for forcing ninepatches to be encoded as
RGBA (with alpha) was to avoid the possibility of the decoder
producing 565 output.
565 output is bad for ninepatches because dithering tiny images
that we intend to scale later leads to bad results. I would
argue that, since the new BitmapFactory does not dither, we might
now be ok to allow 565 decodes for ninepatches. However, we
will maintain the old behavior by disabling 565 decodes for
ninepatch.
There are two changes to PNG encodings:
(1) Allows ninepatch images to be encoded in any mode. Forcing
them to RGBA makes things awkward for the decoder. Currently,
BitmapFactory's png decoder checks every pixel for alpha.
That way, RGBA images that are actually opaque can be marked
as opaque, in order to optimize drawing. We want to remove
this complexity from the decoder.
(2) Make sure ninepatch chunks are stored in the png header. That
way we know immediately that the png is a ninepatch, and can
refuse to decode to 565 (if we feel this is best).
Change-Id: I724f5dbefb1be7b412f9b362dff83cbc0603f0bf
3b1b68d6c7