Bitmaps on ICS are loaded with wrong pixel format

Question

I encountered the following problem. When any bitmap is loaded from resources by an application running on Ice Cream Sandwich, it will likely be rendered incorrectly as if it has been decoded to the format, which differs from the current window format, with no dither applied. However, both, the decoding format and window format have been explicitly set:

BitmapFactory.Options opts = new BitmapFactory.Options();
opts.inPreferredConfig = Bitmap.Config.RGBA_8888;

and

getWindow().setFormat(PixelFormat.RGBA_8888);
getWindow().addFlags(WindowManager.LayoutParams.FLAG_DITHER);

Here are screenshots of the test app taken from this article running on Emulator with ICS 4.0.3 (it gives the same results on HTC HD2):

RGBA_8888 (32-bits) window format, various bitmap decoding formats:

RGB_565 (16-bits) window format, various bitmap decoding formats:

Several things could be noticed:

• Dithering flag is not taken into account from time to time;
• The default window format for ICS seems to be RGB_565;
• The only good looking gradient appears with RGB_565 window format and RGBA_8888 bitmap decoding format.

This problem has also been reported in these questions, but still no solution can be found there:

Gradient compatibility issue - ICS defaults to fewer colors than all the previous versions of Android

Awful background image quality in Android

The quistion is, how to deal with all these formats on ICS, to be more precise, how to make ICS load bitmaps with RGBA_8888 format and how to set the window format to RGBA_8888 so these bitmaps are displayed correctly?

Answer 1

That demo app is a bit odd... it has two activities which both filter the launcher intent, one intended for 16bpp and one for 32bpp. Am not sure what determines which one gets picked when you launch the app.

Running the app as-is on an ICS device (a Nexus S running stock 4.0.3) results in the 16bpp version always being chosen. If remove the 16bpp activity declaration from the manifest, it unsurprisingly launches the 32bpp version instead. Which looks fine to me. The 'dither' option has no effect in 32bpp but that's as expected... dithering only comes into play when the display surface depth is lower than the image depth.

As for display surface depths, my understanding is that window surface depth used to default to 16bpp, up until Android 3.0 (Honeycomb) at which point the default quietly switched to 32bpp. The default has always been overrideable via Window.setFormat().

Answer 2

I can definitely assure you that the default window format is RGB888. This was actually made the default in Android 2.3, and has not been changed since them. At this point I would consider RGB565 windows deprecated, since basically all current devices have 32bpp displays.

You say you are also running this on the HTC HD2, but since there is no official build for it I would be suspicious of any result you get there.

I think the emulator may still use 16bpp displays, so in this area I would not rely on its results to exactly match what you will typically see on devices.