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.