While tinkering with shrinking Fennec’s apk size, I came across a potential optimisation for nine-patches that’s oddly missing from Android’s resource preprocessing steps.
There’s a pretty decent explanation of what nine-patches are over here.
When a nine-patch contains multiple scalable regions along an axis, the system guarantees to maintain their relative size (though no promises are made about aspect ratio of the entire image).
In the simpler (and more common) case where only a single scalable region exists along an axis, if all the columns (or rows) are identical, they may safely be collapsed to a single column (or row). The renderer will happily later upscale this single-pixel region as much as necessary with identical results.
Apparently this isn’t something that’s done automagically during the packaging step, so I’ve written a neat (and slightly badly-structured) utility for performing this optimisation, available here:
https://bitbucket.org/ckitching/shrinkninepatch
It takes a list of .9.png files as input and overwrites them with optimised versions (if the optimisation is found to be safe. It does not currently perform any optimisation where multiple scalable regions exist, even though it should be safe to do so under some circumstances (if the regions each consist of homogenous rows/columns and you reduce their size in a way that preserve their relative size)).
Note that this program doesn’t preserve PNG indexes, so if you feed it an indexed png you’ll get an unindexed ARGB image as the result (causing the file to grow in size). Simply repeat your png quantisation step to obtain your optimised image.
Perplexed Turnip 