Le bitmap su ICS sono caricate con un formato pixel errato

Question

Ho riscontrato il seguente problema. Quando una bitmap viene caricata dalle risorse da un'applicazione in esecuzione su Ice Cream Sandwich, verrà probabilmente visualizzata in modo errato come se fosse stata decodificata nel formato, che differisce dal formato corrente della finestra, senza applicare alcun dithering. Tuttavia, sia, il formato di decodificazione e il formato della finestra sono stati esplicitamente impostare:

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

e

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

Ecco le schermate del test app preso da this article esecuzione sul emulatore con ICS 4.0.3 (che dà gli stessi risultati su HTC HD2):

RGBA_8888 (32-bit) formato finestra, vari formati di decodifica bitmap:

RGB_565 (16-bit) formato finestra, vari formati di decodifica bitmap:

Parecchie cose potrebbero essere notati:

• dithering flag non viene presa in considerazione di volta in volta ;
• Il formato di finestra predefinito per ICS sembra essere RGB_565;
• L'unica buona gradiente di sguardo appare con RGB_565 formato finestra e RGBA_8888formato bitmap decodifica.

Questo problema è anche stata riportata in queste domande, ma ancora nessuna soluzione può essere trovato lì:

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

Awful background image quality in Android

Il quistion è, come affrontare tutti questi formati su ICS, per essere più precisi, come rendere ICS caricare i bitmap con il formato RGBA_8888 e come impostare il formato della finestra su RGBA_8888 in modo che questi bitmap vengano visualizzati correttamente?

Answer 1

Posso sicuramente assicurarvi che il formato di finestra predefinito è RGB888. Questo è stato effettivamente impostato come predefinito in Android 2.3 e non è stato modificato da loro. A questo punto considererei deprecate le finestre RGB565, poiché in pratica tutti i dispositivi attuali hanno display a 32 bit.

Si dice che si sta eseguendo anche questo sull'HTC HD2, ma dal momento che non esiste una versione ufficiale per questo, sarei sospettoso di ogni risultato che si ottiene.

Penso che l'emulatore possa ancora utilizzare i display a 16 bpp, quindi in quest'area non fare affidamento sui suoi risultati per corrispondere esattamente a ciò che si vedrà normalmente sui dispositivi.

Answer 2

Questa app demo è un po 'strana ... ha due attività che filtrano l'intento del launcher, uno per 16bpp e uno per 32bpp. Non sono sicuro di cosa determina quale viene selezionato quando avvii l'app.

L'esecuzione dell'app su un dispositivo ICS (un Nexus S con magazzino 4.0.3) comporta la scelta della versione 16bpp. Se si rimuove la dichiarazione di attività 16bpp dal manifest, invece si avvia in modo non sorprendente la versione a 32 bit. Per me va bene. L'opzione 'dither' non ha effetto in 32bpp ma è come previsto ... la dithering entra in gioco solo quando la profondità della superficie di visualizzazione è inferiore alla profondità dell'immagine.

Per quanto riguarda la profondità della superficie del display, la mia comprensione è che la profondità della superficie della finestra utilizzata per default è 16bpp, fino a Android 3.0 (Honeycomb), a quel punto l'impostazione predefinita passò tranquillamente a 32bpp. L'impostazione predefinita è sempre stata sovrascrivibile tramite Window.setFormat().