Configurar políticas de áudio

A versão Android 10 inclui uma refatoração significativa do gerenciador de políticas de áudio para oferecer mais flexibilidade e compatibilidade com casos de uso automotivos complexos:

  • Estratégias de roteamento específicas do OEM.
  • Grupos de volume personalizáveis para grupos de tipos de stream legados que usam as mesmas curvas de volume.
  • Estratégias de roteamento declaradas pelo mecanismo de política de áudio em vez de serem codificadas.
  • Curvas de volume e grupos gerenciados pelo mecanismo de política de áudio.
  • Refatoração interna para uma futura divisão entre código comum e configurável e oferecendo um gerenciamento mais completo de dispositivos de áudio. Por exemplo, o uso de todas as propriedades do dispositivo, não apenas o tipo, nas regras de política.

O Android 7.0 introduziu um formato de arquivo de configuração de política de áudio (XML) para descrever sua topologia de áudio.

As versões anteriores do Android exigiam o uso de device/<company>/<device>/audio/audio_policy.conf para declarar os dispositivos de áudio presentes no produto. Você pode conferir um exemplo desse arquivo para o hardware de áudio do Galaxy Nexus em device/samsung/tuna/audio/audio_policy.conf. No entanto, o CONF é um formato simples e proprietário que é muito limitado para descrever topologias complexas para verticais como televisores e automóveis.

O Android 7.0 descontinuou o audio_policy.conf e adicionou suporte para definir uma topologia de áudio usando um formato de arquivo XML mais legível para humanos, com uma ampla variedade de ferramentas de edição e análise e flexível o suficiente para descrever topologias de áudio complexas. O Android 7.0 usa a flag de build USE_XML_AUDIO_POLICY_CONF para escolher o formato XML dos arquivos de configuração.

Vantagens do formato XML

Assim como no arquivo CONF, o arquivo XML permite definir o número e os tipos de perfis de stream de saída e entrada, dispositivos utilizáveis para reprodução e captura e atributos de áudio. Além disso, o formato XML oferece as seguintes melhorias:

  • No Android 10, é possível ter mais de um app de gravação ativo ao mesmo tempo.
    • O início da gravação nunca é rejeitado devido a uma situação de simultaneidade.
    • O callback registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb) notifica os clientes sobre mudanças no caminho de captura.
  • Um cliente recebe amostras de áudio silenciosas nas seguintes situações:
    • Um caso de uso sensível à privacidade (por exemplo, VOICE_COMMUNICATION) está ativo.
    • O cliente não tem um serviço em primeiro plano ou uma interface em primeiro plano.
    • Os papéis especiais são reconhecidos pela política:
      • Serviço de acessibilidade: pode gravar mesmo que um caso de uso sensível à privacidade esteja ativo.
      • Assistente: considerado sensível à privacidade se a interface estiver na parte de cima.
  • Os perfis de áudio têm uma estrutura semelhante aos descritores de áudio simples HDMI, permitindo um conjunto diferente de taxas de amostragem/máscaras de canal para cada formato de áudio.
  • Há definições explícitas para todas as conexões possíveis entre dispositivos e streams. Antes, uma regra implícita permitia conectar todos os dispositivos anexados ao mesmo módulo HAL, impedindo que a política de áudio controlasse as conexões solicitadas com APIs de patch de áudio. No formato XML, a descrição da topologia define limitações de conexão.
  • O suporte para includes evita a repetição de definições padrão de A2DP, USB ou envio de redirecionamento.
  • As curvas de volume são personalizáveis. Antes, as tabelas de volume eram codificadas. No formato XML, as tabelas de volume são descritas e podem ser personalizadas.

O modelo em frameworks/av/services/audiopolicy/config/audio_policy_configuration.xml mostra muitos desses recursos em uso.

Formato e local do arquivo

O novo arquivo de configuração da política de áudio é audio_policy_configuration.xml e está localizado em /system/etc. Os exemplos a seguir mostram uma configuração simples de política de áudio no formato de arquivo XML para o Android 12 e versões anteriores.

A estrutura de nível superior contém módulos que correspondem a cada módulo de hardware HAL de áudio, em que cada módulo tem uma lista de portas de mixagem, portas de dispositivo e rotas:

  • As portas de mixagem descrevem os possíveis perfis de configuração para streams que podem ser abertos no HAL de áudio para reprodução e captura.
  • As portas de dispositivo descrevem os dispositivos que podem ser conectados com o tipo deles e, opcionalmente, endereço e propriedades de áudio, se relevante.
  • Rotas é separado do descritor de porta de mixagem, permitindo a descrição de rotas de dispositivo para dispositivo ou de stream para dispositivo.

As tabelas de volume são listas simples de pontos que definem a curva usada para traduzir de um índice da interface para um volume em dB. Um arquivo de inclusão separado fornece curvas padrão, mas cada curva para um determinado caso de uso e categoria de dispositivo pode ser substituída.

Inclusões de arquivo

O método de inclusões XML (XInclude) pode ser usado para incluir informações de configuração da política de áudio localizadas em outros arquivos XML. Todos os arquivos incluídos precisam seguir a estrutura descrita acima com as seguintes restrições:

  • Os arquivos só podem conter elementos de nível superior.
  • Os arquivos não podem conter elementos XInclude.

Use includes para evitar copiar informações de configurações do módulo HAL de áudio padrão do Android Open Source Project (AOSP) para todos os arquivos de configuração da política de áudio (o que é propenso a erros). Um arquivo XML de configuração de política de áudio padrão é fornecido para as seguintes HALs de áudio:

  • A2DP:a2dp_audio_policy_configuration.xml
  • Redirecionar submixagem:rsubmix_audio_policy_configuration.xml
  • USB:usb_audio_policy_configuration.xml

Organização do código da política de áudio

O AudioPolicyManager.cpp é dividido em vários módulos para facilitar a manutenção e a configuração. A organização de frameworks/av/services/audiopolicy inclui os seguintes módulos.

Módulo Descrição
/managerdefault Inclui as interfaces genéricas e a implementação de comportamento comuns a todos os apps. Semelhante a AudioPolicyManager.cpp, com funcionalidade de mecanismo e conceitos comuns abstraídos.
/common Define classes de base (por exemplo, estruturas de dados para perfis de stream de áudio de entrada/saída, descritores de dispositivos de áudio, patches de áudio e portas de áudio). Antes, isso era definido em AudioPolicyManager.cpp.
/engine

Implementa as regras que definem quais dispositivos e volumes devem ser usados para um determinado caso de uso. Ela implementa uma interface padrão com a parte genérica, como para receber o dispositivo adequado para um determinado caso de uso de reprodução ou captura ou para definir dispositivos conectados ou estado externo (ou seja, um estado de chamada de uso forçado) que pode alterar a decisão de roteamento.

Disponível em duas versões: configurável e padrão. Para saber como selecionar a versão, consulte Configuração usando o Parameter Framework.

/engineconfigurable Implementação do mecanismo de política que depende do Parameter Framework (veja abaixo). A configuração é baseada no Parameter Framework e em que a política é definida por arquivos XML.
/enginedefault Implementação do mecanismo de política com base em implementações anteriores do Android Audio Policy Manager. Essa é a opção padrão e inclui regras codificadas que correspondem às implementações do Nexus e do AOSP.
/service Inclui interfaces de binder, threading e implementação de bloqueio com a interface para o restante do framework.

Configuração usando o Parameter Framework

O código da política de áudio é organizado para facilitar o entendimento e a manutenção, além de oferecer suporte a uma política de áudio definida inteiramente por arquivos de configuração. A organização e o design da política de áudio são baseados no Parameter Framework da Intel, um framework baseado em plug-ins e regras para processar parâmetros.

Usar a política de áudio configurável permite que os OEMs fornecedores:

  • Descrever a estrutura e os parâmetros de um sistema em XML.
  • Escreva (em C++) ou reutilize um back-end (plug-in) para acessar os parâmetros descritos.
  • Defina (em XML ou em uma linguagem específica do domínio) condições/regras para que um determinado parâmetro receba um determinado valor.

O AOSP inclui um exemplo de arquivo de configuração de política de áudio que usa o Parameter Framework em Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml. Para mais detalhes, consulte a documentação da Intel sobre o Parameter Framework.

No Android 10 ou versões anteriores, a política de áudio configurável é selecionada usando a opção de build USE_CONFIGURABLE_AUDIO_POLICY. No Android 11 ou versões mais recentes, a versão do mecanismo de política de áudio é selecionada no arquivo audio_policy_configuration.xml. Para selecionar o mecanismo de política de áudio configurável, defina o valor do atributo engine_library do elemento globalConfiguration como configurable , como no exemplo a seguir:

<audioPolicyConfiguration>
    <globalConfiguration engine_library="configurable" />
...
</audioPolicyConfiguration>

APIs de roteamento de política de áudio

O Android 6.0 introduziu uma API pública de enumeração e seleção que fica acima da infraestrutura de patch/porta de áudio e permite que os desenvolvedores de apps indiquem uma preferência por uma saída ou entrada de dispositivo específica para gravações ou faixas de áudio conectadas.

No Android 7.0, a API Enumeration and Selection é verificada por testes do CTS e estendida para incluir roteamento de fluxos de áudio nativos em C/C++ (OpenSL ES). O roteamento de streams nativos continua sendo feito em Java, com a adição de uma interface AudioRouting que substitui, combina e descontinua os métodos de roteamento explícitos específicos das classes AudioTrack e AudioRecord.

Para detalhes sobre a API Enumeration and Selection, consulte Interfaces de configuração do Android e OpenSLES_AndroidConfiguration.h. Para detalhes sobre o roteamento de áudio, consulte AudioRouting.

Suporte multicanal

Se o hardware e o driver forem compatíveis com áudio multicanal via HDMI, você poderá enviar o fluxo de áudio diretamente para o hardware de áudio. Isso ignora o mixer AudioFlinger para que ele não seja reduzido a dois canais. O HAL de áudio precisa expor se um perfil de stream de saída é compatível com recursos de áudio multicanal. Se a HAL expuser os recursos, o gerenciador de políticas padrão permitirá a reprodução multicanal por HDMI. Para detalhes da implementação, consulte device/samsung/tuna/audio/audio_hw.c.

Para especificar que seu produto tem uma saída de áudio multicanal, edite o arquivo de configuração da política de áudio para descrever a saída multicanal do produto. O exemplo a seguir de frameworks/av/services/audiopolicy/config/primary_audio_policy_configuration_tv.xml mostra uma máscara de canal dinâmica, o que significa que o gerenciador de políticas de áudio consulta as máscaras de canal compatíveis com o receptor HDMI após a conexão.

Também é possível especificar uma máscara de canal estática, como AUDIO_CHANNEL_OUT_5POINT1. O mixer do AudioFlinger faz o downmix do conteúdo para estéreo automaticamente quando enviado a um dispositivo de áudio que não é compatível com áudio multicanal.

Codecs de mídia

Verifique se os codecs de áudio compatíveis com seu hardware e drivers estão declarados corretamente para o produto. Para mais detalhes, consulte Como expor codecs ao framework.