O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Esta página foi traduzida pela API Cloud Translation.

AIDL para a HAL do Hardware Composer

No Android 13 e versões mais recentes, a HAL do Hardware Composer (HWC) é definida na AIDL, e as versões HIDL que variam de android.hardware.graphics.composer@2.1 a android.hardware.graphics.composer@2.4 foram descontinuadas.

Esta página descreve as diferenças entre a AIDL e a HAL HIDL para o HWC e a implementação e o teste da HAL AIDL.

Devido às vantagens oferecidas pela AIDL, os fornecedores são incentivados a implementar a HAL de criação da AIDL a partir do Android 13, em vez da versão HIDL. Consulte a seção Implementação para mais informações.

Diferenças entre as HALs AIDL e HIDL

A nova HAL de compositor da AIDL, chamada android.hardware.graphics.composer3, é definida em IComposer.aidl. Ele expõe uma API semelhante à android.hardware.graphics.composer@2.4 da HAL de HIDL com as seguintes mudanças:

Remoção da fila de mensagens rápidas (FMQ, na sigla em inglês) em favor de comandos parceláveis.

A HAL da AIDL define a interface de comando com base em tipos com tipagem forte, em vez dos comandos serializados sobre FMQ no HIDL. Isso oferece uma interface estável para comandos e uma definição mais legível de como o payload do comando é interpretado.

O método executeCommands é definido em IComposerClient.aidl como
```
CommandResultPayload[] executeCommands(in DisplayCommand[] commands);
```
em que cada comando é um tipo parcelável com tipo definido em DisplayCommand.aidl. As respostas de comando são parceláveis fortemente tipados definidos em CommandResultPayload.aidl.
Remoção de IComposerClient.getClientTargetSupport, porque não há clientes ativos para esse método.
Representação de cores como números flutuantes em vez de bytes para se alinhar melhor com a pilha de gráficos superior no Android, conforme definido em ASurfaceTransaction_setColor.
Inclusão de novos campos para controlar o conteúdo HDR.

Na HAL da AIDL, as pilhas de camadas mistas SDR/HDR oferecem suporte ao escurecimento contínuo das camadas de SDR quando uma camada HDR está simultaneamente na tela.

O campo brightness em LayerCommand permite que o SurfaceFlinger especifique um brilho por camada para que o HWC escureça o conteúdo da camada no espaço de luz linear, em vez do espaço gamma.

O campo brightness em ClientTargetPropertyWithBrightness permite que o HWC especifique o espaço de brilho para a composição do cliente e instrua RenderEngine se as camadas SDR serão escurecidas na composição do cliente.

O campo dimmingStage permite que o HWC configure quando o RenderEngine precisa escurecer o conteúdo. Isso acomoda o ColorModes definido pelo fornecedor, que pode preferir escurecer no espaço gama, para permitir melhorias de contraste definidas pelo fornecedor nos pipelines de cor.
Adição de um novo tipo de composição DISPLAY_DECORATION em Composition.aidl para decorações de tela.

Alguns dispositivos têm hardware dedicado para otimizar a exibição da máscara Alfa, que suaviza cantos arredondados e cortes nas telas. Dispositivos com esse hardware precisam implementar IComposerClient.getDisplayDecorationSupport para retornar uma estrutura DisplayDecorationSupport, conforme definido no novo DisplayDecorationSupport.aidl. Essa estrutura descreve os tipos enumerados PixelFormat e AlphaInterpretation necessários para o dispositivo. Após essa implementação, a interface do sistema marca a camada de máscara Alfa como DISPLAY_DECORATION, um novo tipo de composição que aproveita o hardware dedicado.
Adição de um novo campo expectedPresentTime a DisplayCommand.aidl.

O campo expectedPresentTime permite que o SurfaceFlinger defina o tempo atual esperado para quando o conteúdo atual precisa ser mostrado na tela. Com esse recurso, o SurfaceFlinger envia uma comando de presente para a implementação com antecedência, permitindo que ele faça o pipeline de mais trabalho de composição.
Adição de novas APIs para controlar a configuração de exibição na inicialização.

Ao usar BOOT_DISPLAY_CONFIG, os fornecedores podem especificar que a configuração de tela da inicialização tem suporte. Os métodos setBootDisplayConfig, clearBootDisplayConfig e getPreferredBootDisplayConfig usam BOOT_DISPLAY_CONFIG desta forma:
- Usando setBootDisplayConfig, o framework informa os fornecedores sobre a configuração de exibição do tempo de inicialização. Os fornecedores precisam armazenar em cache na configuração de exibição de inicialização e inicializar nessa configuração na próxima reinicialização. Se o dispositivo não conseguir inicializar nessa configuração, o fornecedor precisará encontrar uma configuração que corresponda à resolução e à taxa de atualização dela. Se essa configuração não existir, o fornecedor precisará usar a configuração de tela preferida dele.
- Usando clearBootDisplayConfig, o framework informa aos fornecedores que precisam limpar a configuração da tela de inicialização e inicializar com a configuração de tela preferida deles durante a próxima reinicialização.
- Usando getPreferredBootDisplayConfig, o framework consulta o modo de inicialização preferido do fornecedor.
Quando a configuração de tela de inicialização não tem suporte, esses métodos retornam um valor UNSUPPORTED.
Adição de novas APIs para controlar o timer de inatividade da tela.
- Usando DISPLAY_IDLE_TIMER, os fornecedores podem especificar que um timer de inatividade seja implementado pelo fornecedor para essa tela. Quando inativo, esse recurso muda a taxa de atualização para uma configuração menor para economizar energia. A plataforma usa setIdleTimerEnabled para controlar o tempo limite do timer e, em alguns casos, para desativá-lo, evitando mudanças indesejadas na taxa de atualização quando o dispositivo está inativo.
- O uso do callback IComposerCallback.onVsyncIdle indica à plataforma que a tela está inativa e que a cadência de vsync mudou. A plataforma responde a esse callback redefinindo o modelo vsync. Ele força uma ressincronização de vsync no próximo frame e aprende a nova cadência de vsync.

Implementação

Os fornecedores não precisam implementar a HAL AIDL para o Android 13. No entanto, é recomendável implementar a HAL de compositor da AIDL em vez da versão HIDL para usar a nova funcionalidade e APIs.

Uma implementação de referência para a HAL de HWC da AIDL é implementada em emuladores do Android.

Teste

Para testar a implementação, execute VtsHalGraphicsComposer3_TargetTest.