O Android 10 inclui uma refatoração significativa do gerenciador de políticas
de áudio para oferecer mais flexibilidade ao suporte a casos de uso automotivos complexos:
Estratégias de roteamento específicas do OEM.
Grupos de volume personalizáveis para grupos de tipos de transmissão 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.
Grupos e curvas de volume gerenciados pelo mecanismo da política de áudio.
Refatoração interna que prepara para uma divisão futura entre código comum e código configurável,
além de oferecer um gerenciamento de dispositivos de áudio mais avançado. Por exemplo, o uso de todas as propriedades do dispositivo, não apenas
o tipo dele, nas regras de políticas.
O Android 7.0 introduziu um formato de arquivo de configuração de política de áudio (XML) para
descrevê-la.
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 televisões e automóveis.
O Android 7.0 suspendeu o uso de audio_policy.conf e adicionou suporte
à definição de uma topologia de áudio usando um formato de arquivo XML que é mais
legível por humanos, tem 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 de entrada, dispositivos utilizáveis para reprodução e captura e
atributos de áudio. Além disso, o formato XML oferece os seguintes aprimoramentos:
No Android 10, mais de um app de gravação ativo é
permitido simultaneamente.
A inicialização da gravação nunca é rejeitada devido a uma situação de simultaneidade.
O callback registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb)
notifica os clientes sobre mudanças no caminho de captura.
Nas seguintes situações, um cliente recebe amostras de áudio silenciosas:
Um caso de uso sensível à privacidade (por exemplo, VOICE_COMMUNICATION) está ativo.
O cliente não tem um serviço ou uma interface em primeiro plano.
As funções especiais são reconhecidas pela política:
Serviço de acessibilidade: pode gravar mesmo se um caso de uso que envolve privacidade estiver ativo.
Assistente: considerado sensível à privacidade se a IU 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 transmissões.
Antes, uma regra implícita possibilitava a conexão de todos os dispositivos conectados ao mesmo módulo
HAL, impedindo a política de áudio de controlar 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 a includes evita a repetição de definições padrão de envio de A2DP, USB ou redirecionamento.
As curvas de volume são personalizáveis. Antes, as tabelas de volume eram fixadas no código. 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 do arquivo e localização
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 de política de áudio simples no
formato de arquivo XML para o Android 12 e para as versões anteriores ao
Android 12.
Mostrar exemplo de política de áudio para o Android 12
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 relevantes).
Routes é separado do descritor de porta de mixagem,
permitindo a descrição de rotas de dispositivo para dispositivo ou de streaming para dispositivo.
As tabelas de volume são listas simples de pontos que definem a curva usada para converter
de um índice da interface em 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.
O método de inclusões de XML (XInclude) pode ser usado para incluir informações de configuração
de 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 podem conter apenas elementos de nível superior.
Os arquivos não podem conter elementos XInclude.
Use includes para evitar copiar informações de configurações de módulo HAL de áudio
do Android Open Source Project (AOSP) padrão para todos os arquivos de configuração de política de áudio,
que são propensos a erros. Um arquivo XML de configuração de política de áudio padrão
é fornecido para os seguintes HALs 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
módulos a seguir.
Módulo
Descrição
/managerdefault
Inclui a implementação de interfaces genéricas e comportamentos comuns a todos os
apps. Semelhante a AudioPolicyManager.cpp com a funcionalidade
do mecanismo e conceitos comuns abstraídos.
/common
Define classes básicas (por exemplo, estruturas de dados para perfis de stream de áudio de entrada e saída,
descriptores de dispositivos de áudio, patches de áudio e portas de áudio). Isso foi definido anteriormente
dentro de AudioPolicyManager.cpp.
/engine
Implementa as regras que definem quais dispositivos e volumes devem ser usados para
um determinado caso de uso. Ele implementa uma interface padrão com a parte genérica, como
para conseguir o dispositivo apropriado 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.
Implementação do mecanismo de políticas que depende do parâmetro framework (confira abaixo).
A configuração é baseada no framework de parâmetros e onde a política é
definida por arquivos XML.
/enginedefault
Implementação do mecanismo de política com base em implementações anteriores do Gerenciador de Políticas de Áudio do Android. Esse é o padrão e inclui regras fixadas que
correspondem às implementações do Nexus e do AOSP.
/service
Inclui interfaces de vinculação, linhas de execução e implementação de bloqueio com
a interface para o restante do framework.
Configuração usando o framework de parâmetro
O código de 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. O design da organização e da política de áudio é baseado no Framework de Parâmetros
da Intel, um framework baseado em plug-ins e regras para processar parâmetros.
O uso da política de áudio configurável permite que os OEMs dos 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) as condições/regras em que
um determinado parâmetro precisa ter um determinado valor.
O AOSP inclui um exemplo de um arquivo de configuração de política de áudio que usa o Framework
de parâmetros 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 mais recente, a versão do mecanismo de política
de áudio é selecionada no arquivo audio_policy_configuration.xml.
Para selecionar o mecanismo da política de áudio configurável, defina o valor do atributo engine_library
do elemento globalConfiguration como configurable,
como no exemplo a seguir:
O Android 6.0 introduziu uma API de enumeração e seleção pública que fica
acima da infraestrutura de patch/porta de áudio e permite que os desenvolvedores
de apps indiquem uma preferência para uma saída ou entrada de dispositivo específica para
registros ou faixas de áudio conectados.
No Android 7.0, a API Enumeration and Selection é verificada pelos testes do CTS e é estendida para incluir o roteamento de streams de áudio C/C++ (OpenSL ES) nativos.
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 que eram específicos para as classes AudioTrack e
AudioRecord.
Para ver 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 a vários canais
Se o hardware e o driver oferecerem suporte a áudio multicanal via HDMI, você vai poder
enviar o stream de áudio diretamente para o hardware de áudio. Isso vai ignorar o
mixer do AudioFlinger para que ele não seja reduzido para dois canais. A HAL de áudio
precisa expor se um perfil de stream de saída oferece suporte a recursos de áudio
multicanal. Se o HAL expor os recursos, o gerenciador de políticas padrão
permitirá a reprodução multicanal por HDMI. Para detalhes de implementação, consulte
device/samsung/tuna/audio/audio_hw.c.
Para especificar que o 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 aceitas pelo sink HDMI após a conexão.
Mostrar exemplo de configuração de dispositivo HDMI
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
oferece suporte ao áudio multicanal.
Codecs de mídia
Verifique se os codecs de áudio compatíveis com hardware e drivers foram declarados
corretamente para o produto. Para mais detalhes, consulte
Exposição de codecs ao
framework.
O conteúdo e os exemplos de código nesta página estão sujeitos às licenças descritas na Licença de conteúdo. Java e OpenJDK são marcas registradas da Oracle e/ou suas afiliadas.
