Implementar o OpenGL ES e o EGL

O OpenGL é uma API gráfica multiplataforma que especifica uma interface de software padrão para hardware de processamento de gráficos 3D. O OpenGL ES é um subconjunto da especificação OpenGL para dispositivos incorporados.

Para serem compatíveis com o Android, os dispositivos precisam oferecer drivers para EGL, OpenGL ES 1.x e OpenGL ES 2.0. O suporte ao OpenGL ES 3.x é opcional. As principais considerações incluem:

• Garantir que o driver do GL seja robusto e esteja em conformidade com os padrões do OpenGL ES.
• Permite um número ilimitado de contextos GL. Como o Android permite apps em segundo plano e tenta manter os contextos GL ativos, não limite o número de contextos no driver.
• Tenha cuidado com a quantidade de memória alocada para cada contexto, porque é comum ter de 20 a 30 contextos GL ativos de uma só vez.
• Suporte ao formato de imagem YV12 e outros formatos de imagem YUV que vêm de outros componentes do sistema, como codecs de mídia ou a câmera.
• Suporte às extensões obrigatórias EGL_KHR_wait_sync, GL_OES_texture_external, EGL_ANDROID_image_native_buffer e EGL_ANDROID_recordable. Além disso, o Hardware Composer v1.1 e versões mais recentes exigem o EGL_ANDROID_framebuffer_target .

É altamente recomendável oferecer suporte a EGL_ANDROID_blob_cache, EGL_KHR_fence_sync e EGL_ANDROID_native_fence_sync.

O Android 10 implementa a interface EGL 1.5 (link em inglês). Para informações sobre novos recursos no EGL 1.5, consulte a especificação de versões Khronos 1.5 (link em inglês).

Observação:a API OpenGL exposta ao app desenvolvedores é diferente do OpenGL implementado no dispositivo. Os apps não podem acessar diretamente a camada do driver GL e precisam passar pela interface fornecida pelas APIs.

Carregamento do driver

O Android espera que as GPUs disponíveis para o sistema sejam conhecidas quando ele é criada. Os caminhos preferidos para drivers do OpenGL ES de 32 e 64 bits são /vendor/lib/egl e /vendor/lib64/egl, respectivamente. O loader usa duas propriedades do sistema, ro.hardware.egl e ro.board.platform ou a exata para descobrir e carregar os drivers do sistema. O driver do OpenGL ES precisa ser enviados em um binário ou divididos em três. Se o OpenGL ES é enviado em um binário, use um dos seguintes nomes:

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

Se o driver do OpenGL ES for enviado em três binários, use um dos seguintes conjuntos de nomes:

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

Camadas do OpenGL ES

O Android 10 introduz um sistema de camadas para o GLES 2.0 ou superior. As camadas do GLES são objetos compartilhados disponíveis nos apps ou fornecidos por ferramentas de visualização. As camadas GLES permitem que apps depuráveis detectem e carreguem camadas usando os mesmos mecanismos de configuração do Vulkan.

Cuidado: quando a criação de camadas é ativada, as funções exclusivas do GLES 1.x continuam sendo direcionadas para os drivers do GLES 1.x, mas as funções compartilhadas com o GLES 2.0 e mais recentes são direcionadas para os drivers da versão 2.0 e mais recentes.

O LayerLoader do GLES, um componente dentro do carregador do EGL, identifica camadas do GLES. Para cada camada encontrada, o GLES LayerLoader chama AndroidGLESLayer_Initialize, percorre as listas de funções do libEGL e chama AndroidGLESLayer_GetProcAddress para todas as funções conhecidas. Se a camada interceptar uma função, ela rastreará o endereço da função. Se a camada não interceptar uma função, AndroidGLESLayer_GetProcAddress vai retornar o mesmo endereço de função que recebeu. Em seguida, o LayerLoader atualiza a lista de ganchos de função para para o ponto de entrada da camada.

Ativar camadas

Observação: as políticas e o modelo de segurança do Android são muito diferentes dos que são usados por outras plataformas. O Android só permite que aqueles que têm acesso à raiz carreguem camadas do GLES do armazenamento local de um dispositivo. Sem acesso à raiz, as camadas do GLES só podem ser carregadas para apps depuráveis.

Você pode ativar as camadas GLES por app ou de forma global. As configurações por app persistem em reinicializações, enquanto as propriedades globais são apagadas na reinicialização.

Para ativar camadas por 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

Para desativar camadas por 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

Para ativar camadas globalmente:

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

Camadas de teste

As camadas GLES usam o Android CTS e precisam passar em testes de CTS para dispositivos compatíveis. Para identificar se as camadas estão funcionando em um dispositivo, execute $ atest CtsGpuToolsHostTestCases.