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

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.