Implementare OpenGL ES ed EGL

OpenGL è un'API grafica multipiattaforma che specifica un'interfaccia software standard per l'hardware di elaborazione della grafica 3D. OpenGL ES è un sottoinsieme della specifica OpenGL per i dispositivi embedded.

Per essere compatibili con Android, i dispositivi devono fornire driver per EGL, OpenGL ES 1.x e OpenGL ES 2.0. Il supporto per OpenGL ES 3.x è facoltativo. Le considerazioni principali includono:

• Assicurarsi che il driver GL sia affidabile e conforme agli standard OpenGL ES.
• Consentire un numero illimitato di contesti GL. Poiché Android consente le app in background e cerca di mantenere attivi i contesti GL, non dovresti limitare il numero di contesti nel conducente.
• Tieni presente la quantità di memoria allocata per ogni contesto, perché è normale avere 20-30 contesti GL attivi contemporaneamente.
• Supporto del formato immagine YV12 e di altri formati di immagini YUV provenienti da altri componenti del sistema, come i codec multimediali o la videocamera.
• Supporto delle estensioni obbligatorie EGL_KHR_wait_sync, GL_OES_texture_external, EGL_ANDROID_image_native_buffer e EGL_ANDROID_recordable. Inoltre, Hardware Composer 1.1 e versioni successive richiedono l'estensione EGL_ANDROID_framebuffer_target.

Ti consigliamo vivamente di supportare anche EGL_ANDROID_blob_cache, EGL_KHR_fence_sync e EGL_ANDROID_native_fence_sync.

Android 10 implementa l'interfaccia eSIM 1.5. Per informazioni sulle nuove funzionalità di EGL 1.5, consulta la specifica delle release 1.5 di Khronos.

Nota: l'API OpenGL esposta agli sviluppatori di app è diversa da quella implementata sul dispositivo. Le app non possono accedere direttamente al livello del driver GL e devono passare per l'interfaccia fornita dalle API.

Caricamento del driver

Android si aspetta che le GPU disponibili per il sistema siano note al momento della compilazione dell'immagine di sistema. I percorsi preferiti per i driver OpenGL ES a 32 e 64 bit sono rispettivamente /vendor/lib/egl e /vendor/lib64/egl. Il loader utilizza due proprietà di sistema, ro.hardware.egl e ro.board.platform, o il nome esatto, per rilevare e caricare i driver di sistema. Il driver OpenGL ES deve essere fornito in un file binario o suddiviso in tre file binari. Se il driver OpenGL ES viene spedito in un file binario, usa uno dei seguenti nomi:

libGLES_${ro.hardware.egl}.so
libGLES_${ro.board.platform}.so
libGLES.so

Se il driver OpenGL ES viene fornito in tre file binari, utilizza uno dei seguenti set di nomi:

libEGL_${ro.hardware.egl}.so
libGLESv1_CM_${ro.hardware.egl}.so
libGLESv2_${ro.hardware.egl}.so

libEGL_${ro.board.platform}.so
libGLESv1_CM_${ro.board.platform}.so
libGLESv2_${ro.board.platform}.so

libEGL.so
libGLESv1_CM.so
libGLESv2.so

Livelli OpenGL ES

Android 10 introduce un sistema di stratificazione per GLES 2.0 e versioni successive. Gli strati GLES sono oggetti condivisi disponibili all'interno delle app o forniti da strumenti. I livelli GLES consentono alle app di debug di rilevare e caricare i livelli utilizzando gli stessi meccanismi di configurazione di Vulkan.

Attenzione:quando è abilitata la suddivisione in livelli, le funzioni esclusive di GLES 1.x continuano a indirizzare ai driver GLES 1.x, ma le funzioni condivise con GLES 2.0 e versioni successive vengono instradate a driver 2.0 e versioni successive.

GLES LayerLoader, un componente all'interno del caricatore EGL, identifica i livelli GLES. Per ogni livello trovato da GLES LayerLoader, GLES LayerLoader chiama AndroidGLESLayer_Initialize, gestisce gli elenchi di funzioni di libEGL e chiama AndroidGLESLayer_GetProcAddress per tutte le funzioni note. Se il livello intercetta una funzione, ne monitora l'indirizzo. Se il livello non intercetta una funzione, AndroidGLESLayer_GetProcAddress restituisce lo stesso indirizzo della funzione che gli è stato passato. LayerLoader aggiorna quindi l'elenco degli hook delle funzioni in modo che punti al punto di ingresso del livello.

Attivare i livelli

Nota: il modello e i criteri di sicurezza di Android differiscono notevolmente da quelli di altre piattaforme. Android consente solo a chi ha accesso come amministratore di caricare i livelli GLES dallo spazio di archiviazione locale di un dispositivo. Senza accesso come utente amministratore, i livelli GLES possono essere caricati solo per le app di cui è possibile eseguire il debug.

Puoi attivare i livelli GLES per app o a livello globale. Le impostazioni per app rimangono valide per tutti i riavvii, mentre le proprietà globali vengono cancellate al riavvio.

Per attivare i livelli per app:

# Enable layers
adb shell settings put global enable_gpu_debug_layers 1

# Specify target app
adb shell settings put global gpu_debug_app package_name

# Specify layer list (from top to bottom)
adb shell settings put global gpu_debug_layers_gles layer1:layer2:...:layerN

# Specify packages to search for layers
adb shell settings put global gpu_debug_layer_app package1:package2:...:packageN

Per disattivare i livelli per app:

adb shell settings delete global enable_gpu_debug_layers
adb shell settings delete global gpu_debug_app
adb shell settings delete global gpu_debug_layer_app

Per attivare i livelli a livello globale:

# Attempts to load layers for all applications, including native executables
adb shell setprop debug.gles.layers layer1:layer2:...:layerN

Testare i livelli

I livelli GLES sono supportati da Android CTS e devono superare i test CTS per i dispositivi compatibili. Per identificare se i livelli funzionano su un dispositivo, esegui $ atest CtsGpuToolsHostTestCases.