AIDL para a HAL do Hardware Composer

No Android 13 e versões mais recentes, a HAL do Hardware Composer (HWC) é definida na AIDL. 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 as HALs de AIDL e HIDL para o HWC e como implementar e testar a HAL de AIDL.

Como a AIDL oferece vantagens, os fornecedores podem implementar a HAL do compositor de AIDL no Android 13 e versões mais recentes em vez da versão HIDL. Para mais informações, consulte a seção Implementação.

Diferenças entre as HALs de AIDL e HIDL

A nova HAL do compositor de AIDL, chamada android.hardware.graphics.composer3, é definida em IComposer.aidl. A API é semelhante à HAL de HIDL android.hardware.graphics.composer@2.4, mas inclui 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 de AIDL define a interface de comando com base em tipos parceláveis fortemente tipados em vez dos comandos serializados na FMQ em HIDL. Isso fornece uma interface estável para comandos e uma definição mais legível de como o sistema interpreta o payload de comando.

    O executeCommands 5 método é definido em IComposerClient.aidl:

    CommandResultPayload[] executeCommands(in DisplayCommand[] commands);

    Cada comando é um tipo parcelável fortemente tipado definido em DisplayCommand.aidl. As respostas de comando são parceláveis fortemente tipadas definidas em CommandResultPayload.aidl.

  • Remoção de IComposerClient.getClientTargetSupport porque nenhum cliente ativo usa esse método.

  • Representação de cores como floats em vez de bytes para se alinhar à pilha de gráficos superior no Android, conforme definido por ASurfaceTransaction_setColor.

  • Adição de novos campos para controlar o conteúdo HDR.

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

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

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

    O campo dimmingStage permite que o HWC configure quando RenderEngine escurece o conteúdo. Isso acomoda ColorModes definidos pelo fornecedor que podem preferir escurecer no espaço gama para ativar melhorias de contraste definidas pelo fornecedor nos pipelines de cores.

  • Adição de um tipo de composição, DISPLAY_DECORATION, em Composition.aidl para decorações de tela.

    Alguns dispositivos têm hardware dedicado para otimizar o desenho da máscara alfa que suaviza cantos arredondados e recortes em telas. Os dispositivos com esse hardware precisam implementar IComposerClient.getDisplayDecorationSupport e retornar uma estrutura DisplayDecorationSupport conforme definido em DisplayDecorationSupport.aidl. Essa estrutura descreve as PixelFormat e AlphaInterpretation enumerações exigidas pelo dispositivo. Após essa implementação, a interface do sistema marca a camada de máscara alfa como DISPLAY_DECORATION, um tipo de composição que aproveita o hardware dedicado.

  • Adição de um expectedPresentTime campo a DisplayCommand.aidl.

    O campo expectedPresentTime permite que o SurfaceFlinger defina o tempo de apresentação esperado para quando o conteúdo atual precisa ser exibido na tela. Com esse recurso, o SurfaceFlinger envia um comando de apresentação para a implementação com antecedência, o que permite que ele pipeline mais do trabalho de composição.

  • Adição de novas APIs para controlar a configuração de exibição de inicialização.

    Usando BOOT_DISPLAY_CONFIG, os fornecedores podem especificar que a configuração de exibição de inicialização é compatível. Os métodos setBootDisplayConfig, clearBootDisplayConfig e getPreferredBootDisplayConfig usam BOOT_DISPLAY_CONFIG da seguinte maneira:

    • Usando setBootDisplayConfig, o framework informa aos fornecedores a configuração de exibição do tempo de inicialização. Os fornecedores precisam armazenar em cache a configuração de exibição de inicialização e inicializar nessa configuração na próxima reinicialização. Se o dispositivo não puder ser inicializado nessa configuração, o fornecedor precisará encontrar uma configuração que corresponda à resolução e à taxa de atualização dessa configuração. Se não houver essa configuração, o fornecedor precisará usar a configuração de exibição preferida.

    • Usando clearBootDisplayConfig, o framework informa aos fornecedores para limpar a configuração de exibição de inicialização e inicializar na configuração de exibição preferida durante a próxima reinicialização.

    • Usando getPreferredBootDisplayConfig, o framework consulta o modo de inicialização preferido do fornecedor.

    Quando a configuração de exibição de inicialização não é compatível, esses métodos retornam um valor de 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 é implementado pelo fornecedor para essa tela. Quando inativa, essa capacidade muda a taxa de atualização para uma configuração mais baixa para preservar a energia. A plataforma usa setIdleTimerEnabled para controlar o tempo limite do timer e, em alguns casos, para desativá-lo a fim de evitar mudanças indesejadas na taxa de atualização quando inativa.

    • O uso do callback IComposerCallback.onVsyncIdle indica à plataforma que a tela está inativa e que a cadência vsync mudou. A plataforma responde a esse callback redefinindo o modelo vsync. Ele força uma resincronização vsync no próximo frame e aprende a nova cadência vsync.

Implementação

Os fornecedores não precisam implementar a HAL de AIDL para o Android 13. No entanto, recomendamos que os fornecedores implementem a HAL do compositor de AIDL em vez da versão HIDL para usar a funcionalidade e as APIs da HAL do compositor de AIDL.

Os emuladores do Android incluem uma implementação de referência para a HAL de AIDL do HWC.

Teste

Para testar sua implementação, execute VtsHalGraphicsComposer3_TargetTest.