HAL de áudio HIDL

No Android 13 e versões anteriores, a interface Audio HAL é definida usando HIDL em arquivos HIDL HAL (com a extensão .hal ) e esquemas XSD para os arquivos de configuração, mostrados a seguir.

Figura 1. Interface HAL de áudio.

Nota: Para obter mais detalhes, consulte a definição da interface de áudio HAL e os comentários nos arquivos *.hal do diretório da versão HAL correspondente. Consulte o arquivo README de Audio HAL para obter a estrutura de diretórios de Audio HAL para HIDL.

Arquivos de configuração

Os arquivos de configuração XML de política de áudio e efeitos de áudio são considerados parte da interface Audio HIDL HAL. Esses arquivos devem estar em conformidade com seus esquemas, e a conformidade é verificada por testes VTS.

Como parte da implementação do HAL HIDL de áudio, você deve criar um arquivo de configuração de política de áudio que descreva a topologia de áudio. Os recursos HAL de áudio devem ser declarados no arquivo audio_policy_configuration.xml para que a estrutura possa usá-los.

API de áudio HIDL HAL

Esta seção descreve as APIs Core, Effects e Common HAL para HIDL.

Observação: no Android 13, todos os caminhos de código que contêm 7.0 são substituídos por 7.1 . No Android 12, todos os caminhos de código contendo 6.0 foram substituídos por 7.0 .

Núcleo HAL

Algumas das principais interfaces do Core HAL, usando HIDL, são as seguintes:

• IDeviceFactory.hal é o ponto de entrada na API.
• IDevice.hal e IPrimaryDevice.hal contêm métodos como setMasterVolume ou openInputStream .
• Os fluxos são unidirecionais e são usados ​​pelo AudioFlinger para enviar ou receber áudio de e para o HAL por meio de IStream.hal , IStreamOut.hal e IStreamIn.hal .

A tabela a seguir lista a localização de componentes úteis do Core HAL HIDL:

Componente principal HAL	Localização
Versão mais recente da API	/hardware/interfaces/audio/6.0
Tipos específicos para a API Core HAL mais recente	/hardware/interfaces/audio/6.0/types.hal
Esquema XSD do arquivo de configuração de política de áudio	/hardware/interfaces/audio/6.0/config/audio_policy_configuration.xsd

A implementação padrão da API Core HAL ( /hardware/interfaces/audio/core/all-versions/default/ ) é um wrapper em torno da implementação pré-Treble HAL usando bibliotecas compartilhadas legadas . A implementação padrão também pode ser considerada uma referência ao implementar novas versões de HALs de áudio que interagem diretamente com os drivers do kernel.

Efeitos HAL

A tabela a seguir lista a localização de componentes HAL de efeitos úteis usando HIDL:

Componente HAL de efeitos	Localização
Versão mais recente da API	/hardware/interfaces/audio/effect/6.0/
Esquema XSD do arquivo de configuração de efeito	/hardware/interfaces/audio/effect/6.0/xml/audio_effects_conf.xsd

Para obter mais informações, consulte um exemplo de implementação da API HAL de efeitos em /hardware/interfaces/audio/effect/all-versions/default/ e a seção Efeitos de áudio .

HAL comum

A API HAL comum usando HIDL contém o seguinte:

• Definições ( /hardware/interfaces/audio/common/6.0/types.hal ) compartilhadas pelas APIs Core e Effect.
• Utilitários ( /hardware/interfaces/audio/common/all-versions ) usados ​​para ajudar na codificação em APIs HIDL para implementações, clientes e testes.

Atualizações para o áudio HAL V7

Há alterações significativas na versão 7 do Audio HAL no Android 12, conforme descrito nesta seção. O Áudio HAL V7 faz o seguinte:

• Unifica os modelos de dados usados ​​pela estrutura e HAL.
• Minimiza a duplicação entre tipos de dados HIDL (enums) e o esquema XML usado para configuração de política de áudio.

Especificamente, são feitas alterações nas seguintes áreas no Audio HAL V7:

• Tipos de enumeração
• Tipos de dados
• Tags do fornecedor
• Namespace de extensões de fornecedor

Essas alterações são discutidas com mais detalhes em suas respectivas seções.

Enumerações

A partir do Audio HAL V7, os tipos enumerados usados ​​no arquivo de configuração de política de áudio são definidos apenas no esquema XSD e não no HIDL.

No Audio HAL V6, os valores dos tipos enum (como AudioFormat ) em types.hal também são definidos no esquema XSD do arquivo de configuração da política de áudio, criando uma duplicação. Para evitar isso na V7, os tipos de enum são alterados para string e todos os valores de enumeração possíveis são listados no esquema XSD.

A Figura 2 compara algumas das alterações no tipo de enumeração AudioFormat na V7:

Figura 2. Comparação de algumas das alterações na enumeração AudioFormat.

Consulte a lista a seguir para os tipos de enum que foram convertidos em string :

• AudioChannelMask
• AudioContentType
• AudioDevice : fornecedor extensível
• AudioFormat : extensível pelo fornecedor
• AudioGainMode
• AudioSource
• AudioStreamType
• AudioUsage

Passar valores de enum de string

Valores de string são usados ​​para transferir informações como valores de enumeração através do limite da interface HAL. Tanto a estrutura quanto o wrapper HAL usam valores enum inteiros para implementar a lógica de negócios e empregam a abordagem de conversão ilustrada na Figura 3 :

Figura 3. Passando valores de enum de string.

Observação: pode parecer incomum ou ineficiente que nossa API use strings aqui. Optamos por usar strings para eliminar a duplicação de constantes de enumeração entre arquivos HIDL e XSD e para simplificar a adição de extensões de fornecedores. A representação de enums como strings é recomendada apenas com a finalidade de transportá-los pela interface HAL. Não é recomendado usar enumerações representadas como cadeias de caracteres na lógica de negócios devido à sobrecarga associada na implementação de operações de lógica booleana e nos mapeamentos de comparação resultantes.

Por exemplo, para passar um valor do tipo de formato de áudio da estrutura para o fornecedor:

1. O valor enum de AudioFormat é convertido em um valor de string em libaudiohal e passado para o HAL.
2. No lado HAL, o wrapper padrão converte a string em um valor enum, que é passado para o HAL legado.

Nota: Os fornecedores podem modificar system/audio.h para usar seus próprios valores de enum.

Alterações no esquema XML

Ter listas completas de valores enum na definição de esquema XML (XSD) permite uma melhor validação do arquivo XML de configuração de política de áudio pelo VTS. Fizemos alterações no arquivo de configuração da política de áudio usado com HAL V7 para estar em conformidade com XSD.

Na V7, um caractere ␣ (espaço) padrão é usado para delimitar listas de valores em atributos (como taxas de amostragem, máscaras de canal e sinalizadores), em vez de , (vírgula) e | (barra vertical) símbolos usados ​​em V6 e abaixo. Conforme visto no exemplo a seguir, um espaço é usado para delimitar a lista de valores para channelMasks :

<profile channelMasks="AUDIO_CHANNEL_OUT_STEREO AUDIO_CHANNEL_OUT_MONO" … />

Para fazer alterações nos símbolos, use um script de conversão automática chamado update_audio_policy_config.sh . Consulte o comando a seguir para converter um arquivo de configuração de política de áudio V6 em uma versão V7 para o dispositivo Pixel 5 (Redfin):

hardware/interfaces/audio/7.0/config/update_audio_policy_config.sh \
device/google/redfin/audio/audio_policy_configuration.xml 6.0

Tipos de dados

Redefinimos algumas estruturas de dados na V7 para minimizar definições duplicadas. Tuplas repetidas de itens de dados são agrupadas em estruturas reutilizáveis. Essas estruturas de dados usam os recursos HIDL mais recentes, como uniões seguras.

Por exemplo, na V6 e abaixo, um triplo de <format, sampling rate, channel mask> é usado frequentemente nas interfaces e tipos HIDL. Para remover essa redundância, na V7, o tipo de dados AudioConfigBase e outros tipos de dados são definidos da seguinte forma:

• AudioConfigBase := <format, sampling rate, channel mask>

• AudioConfigBaseOptional := <[fmt], [sampl. rate], [chan. mask]>

  usado por AudioConfig , AudioOffloadInfo , AudioPortConfig

• AudioProfile := <format, {sampling rates}, {channel masks}>

  substitui coleções soltas em AudioPort/PortConfig

• AudioPortExtendedInfo := device | mix | session

  substitui uniões em AudioPort/PortConfig

Tags do fornecedor

Além dos tipos e formatos de dispositivos, os fornecedores podem adicionar tags personalizadas para metadados de trilhas de áudio.

Para reprodução e gravação de metadados de trilha, os fornecedores podem passar suas próprias tags, que são usadas para adicionar atributos aos fluxos de E/S de áudio, dos aplicativos para o HAL.

Observação: as tags do fornecedor são semelhantes às extensões do fornecedor para formatos de áudio e tipos de dispositivos de áudio. A diferença é que, para tags de fornecedor, não há valores definidos no AOSP, portanto, elas contêm apenas valores estendidos pelo fornecedor.

Tags de fornecedor para metadados de faixa de reprodução são adicionadas conforme visto no exemplo a seguir:

struct PlaybackTrackMetadata {
…
    /** Tags from AudioTrack audio attributes */
    vec<AudioTag> tags;
};

A estrutura RecordTrackMetadata é implementada de maneira semelhante, adicionando tags específicas para os metadados da trilha de gravação.

Namespace de extensões de fornecedor

A partir do HAL V7, as extensões do fornecedor exigem um prefixo {vendor} adicional que não é necessário na V6. Para que o prefixo {vendor} seja válido, ele deve ter três ou mais caracteres alfanuméricos.

Use o seguinte formato na V7:

VX_{ vendor }_{ letters/numbers }

A seguir estão alguns exemplos de extensões válidas do fornecedor V7:

• VX_ GOOGLE _VR
• VX_ QCI _AMBIENT_MIC

Versão informação

A tabela a seguir lista o número da versão HAL para cada versão do Android:

Versão Android	Versão HIDL HAL
Andróide 13	7.1
Andróide 12	7,0
Android 11	6,0
Android 10	5,0
Android 9	4,0
Android 8	2,0