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

AIDL para Compositor de Hardware HAL

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

A partir do Android 13, o HAL do Hardware Composer (HWC) é definido em AIDL e as versões HIDL que variam de android.hardware.graphics.composer@2.1 a android.hardware.graphics.composer@2.4 estão obsoletas.

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

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

Diferenças entre AIDL e HIDL HALs

O novo HAL do compositor AIDL, chamado android.hardware.graphics.composer3 , é definido em IComposer.aidl . Ele expõe uma API semelhante ao HIDL HAL android.hardware.graphics.composer@2.4 com as seguintes alterações:

  • Remoção do Fast Message Queue (FMQ) em favor de comandos parcelable.

    O AIDL HAL define a interface de comando com base em tipos parcelable fortemente tipados em oposição aos comandos serializados sobre FMQ em HIDL. Isso fornece uma interface estável para comandos e uma definição mais legível de como a carga útil do comando é interpretada.

    O método executeCommands é definido em IComposerClient.aidl como

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

    onde cada comando é um tipo parcelable fortemente tipado definido em DisplayCommand.aidl . As respostas de comando são parcelables fortemente tipadas definidas em CommandResultPayload.aidl .

  • Remoção de IComposerClient.getClientTargetSupport , pois não há clientes ativos para este método.

  • Representação de cores como floats em vez de bytes para melhor alinhamento com a pilha de gráficos superior no Android, conforme definido em ASurfaceTransaction_setColor .

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

    No AIDL HAL, as pilhas de camadas SDR/HDR mistas suportam o escurecimento contínuo das camadas SDR quando uma camada HDR está simultaneamente na tela.

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

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

    O campo dimmingStage permite que o HWC configure quando o RenderEngine deve escurecer o conteúdo. Isso acomoda ColorModes definidos pelo fornecedor, que podem preferir escurecer no espaço gama, para permitir aprimoramentos de contraste definidos pelo fornecedor em seus pipelines de cores.

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

    Alguns dispositivos possuem hardware dedicado para otimizar o desenho da máscara alfa que suaviza cantos arredondados e recortes nas telas. Dispositivos com esse hardware devem implementar IComposerClient.getDisplayDecorationSupport para retornar uma estrutura DisplayDecorationSupport conforme definido no novo DisplayDecorationSupport.aidl . Essa estrutura descreve as enumerações PixelFormat e AlphaInterpretation exigidas pelo dispositivo. Após essa implementação, a interface do usuário 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 para DisplayCommand.aidl .

    O campo expectedPresentTime permite que SurfaceFlinger defina o tempo presente esperado para quando o conteúdo atual deve ser exibido na tela. Com esse recurso, o SurfaceFlinger envia um comando presente para a implementação com antecedência, permitindo que ele canalize 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 é suportada. Os setBootDisplayConfig , clearBootDisplayConfig e getPreferredBootDisplayConfig usam BOOT_DISPLAY_CONFIG da seguinte forma:

    • Usando setBootDisplayConfig , a estrutura informa os fornecedores sobre a configuração de exibição do tempo de inicialização. Os fornecedores devem 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 puder inicializar nessa configuração, o fornecedor deverá encontrar uma configuração que corresponda à resolução e à taxa de atualização dessa configuração. Se não existir tal configuração, o fornecedor deve usar sua configuração de exibição preferida.

    • Usando clearBootDisplayConfig , a estrutura informa os fornecedores para limpar a configuração de exibição de inicialização e inicializar em sua configuração de exibição preferida durante a próxima reinicialização.

    • Usando getPreferredBootDisplayConfig , a estrutura 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 temporizador de inatividade do display.

    • Usando DISPLAY_IDLE_TIMER , os fornecedores podem especificar que um cronômetro de inatividade seja implementado pelo fornecedor para esta exibição. Quando ocioso, esse recurso altera 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 cronômetro e, em alguns casos, desativá-lo para evitar mudanças de taxa de atualização indesejadas quando ocioso.

    • O uso do retorno de chamada IComposerCallback.onVsyncIdle indica à plataforma que a exibição está ociosa e a cadência vsync foi alterada. A plataforma responde a esse retorno de chamada redefinindo seu modelo vsync . Ele força uma ressincronização do vsync no próximo quadro e aprende a nova cadência do vsync .

Implementação

Os fornecedores não são obrigados a implementar o AIDL HAL para Android 13. No entanto, eles são incentivados a implementar o AIDL composer HAL em vez da versão HIDL para usar as novas funcionalidades e APIs.

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

Teste

Para testar sua implementação, execute VtsHalGraphicsComposer3_TargetTest .