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 do compositor 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 do compositor AIDL, chamada android.hardware.graphics.composer3, é
definida em IComposer.aidl.
Ela expõe uma API semelhante à HAL HIDL
android.hardware.graphics.composer@2.4 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 estrita, 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 emIComposerClient.aidlcomoCommandResultPayload[] 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 emCommandResultPayload.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 melhor alinhamento com a pilha de gráficos superior no Android, conforme definido em
ASurfaceTransaction_setColor.Adição de novos campos para controlar conteúdo HDR.
No HAL do AIDL, as pilhas de camadas SDR/HDR mistas oferecem suporte ao escurecimento perfeito de camadas SDR quando uma camada HDR está simultaneamente na tela.
O campo
brightnessemLayerCommandpermite que o SurfaceFlinger especifique um brilho por camada, para que o HWC diminua o conteúdo da camada no espaço de luz linear, em vez do espaço gamma.O campo
brightnessemClientTargetPropertyWithBrightnesspermite que o HWC especifique o espaço de brilho para a composição do cliente e instruaRenderEnginea escurecer as camadas SDR na composição do cliente.O campo
dimmingStagepermite que o HWC configure quando oRenderEngineprecisa escurecer o conteúdo. Isso aceitaColorModesdefinido pelo fornecedor, que pode preferir escurecer no espaço Gamma, para permitir melhorias de contraste definidas pelo fornecedor nos pipelines de cores.Adição de um novo tipo de composição
DISPLAY_DECORATIONemComposition.aidlpara 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. Dispositivos com esse hardware precisam implementar
IComposerClient.getDisplayDecorationSupportpara retornar uma estruturaDisplayDecorationSupport, conforme definido no novoDisplayDecorationSupport.aidl. Essa estrutura descreve os tipos enumeradosPixelFormateAlphaInterpretationrequeridos pelo dispositivo. Após essa implementação, a IU do sistema marca a camada de máscara Alfa comoDISPLAY_DECORATION, um novo tipo de composição que aproveita o hardware dedicado.Adição de um novo campo
expectedPresentTimeaDisplayCommand.aidl.O campo
expectedPresentTimepermite 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 um comando de presente para a implementação com antecedência, permitindo que ele envie mais trabalho de composição.Adição de novas APIs para controlar a configuração da tela de inicialização.
Usando
BOOT_DISPLAY_CONFIG, os fornecedores podem especificar que a configuração de tela de inicialização tem suporte. Os métodossetBootDisplayConfig,clearBootDisplayConfigegetPreferredBootDisplayConfigusamBOOT_DISPLAY_CONFIGda 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 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 vai usar a configuração de exibição preferida.Usando
clearBootDisplayConfig, o framework informa aos fornecedores para limpar a configuração de tela de inicialização e iniciar na configuração de tela 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 tela de inicialização não tem suporte, 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 foi implementado para essa exibição. Quando ocioso, esse recurso muda a taxa de atualização para uma configuração mais baixa para economizar energia. A plataforma usasetIdleTimerEnabledpara controlar o tempo limite do timer e, em alguns casos, para desativá-lo e evitar mudanças indesejadas na taxa de atualização quando o dispositivo está ocioso.O uso do callback
IComposerCallback.onVsyncIdleindica à plataforma que a tela está inativa e que a cadência devsyncmudou. A plataforma responde a esse callback redefinindo o modelovsync. Ele força uma resynchronização devsyncno próximo frame e aprende a nova cadência devsync.
Implementação
Os fornecedores não precisam implementar a HAL AIDL para o Android 13. No entanto, recomendamos que você implemente o HAL do compositor AIDL em vez da versão HIDL para usar as novas APIs e funcionalidades.
Uma implementação de referência para o HAL de HWC da AIDL é implementada em emuladores do Android.
Teste
Para testar a implementação, execute VtsHalGraphicsComposer3_TargetTest.