A versão do Android 10 inclui uma refatoração significativa do gerenciador de políticas de áudio para fornecer mais flexibilidade para dar suporte a casos de uso automotivos complexos:
Estratégias de roteamento específicas de OEM.
Grupos de volumes personalizáveis para grupos de tipos de fluxo herdados usando 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 preparando-se para uma futura divisão entre código comum e código configurável e oferecendo gerenciamento de dispositivo de áudio mais rico. Por exemplo, o uso de todas as propriedades do dispositivo não apenas seu 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 device/<company>/<device>/audio/audio_policy.conf para declarar os dispositivos de áudio presentes em seu produto (você pode ver um exemplo deste arquivo para o hardware de áudio Galaxy Nexus em device/samsung/tuna/audio/audio_policy.conf ). No entanto, CONF é um formato proprietário simples que é muito limitado para descrever topologias complexas para verticais como televisores e automóveis.
O Android 7.0 audio_policy.conf e adicionou suporte para definir 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 o sinalizador de compilação 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 fluxo de saída e 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 aplicativo de gravação ativo é permitido simultaneamente.
O início da gravação nunca é rejeitado devido a uma situação de simultaneidade.
O retorno de chamada registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb) notifica os clientes sobre as alterações do caminho de captura.
Nas seguintes situações, um cliente obtém 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 em primeiro plano ou uma interface do usuário 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 sensível à privacidade estiver ativo.
Assistente: considerado sensível à privacidade se a interface do usuário estiver no topo.
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.
Existem definições explícitas para todas as conexões possíveis entre dispositivos e fluxos. Anteriormente, uma regra implícita permitia conectar todos os dispositivos conectados 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 as limitações de conexão.
O suporte para inclui evita a repetição de definições de envio padrão A2DP, USB ou redirecionamento.
As curvas de volume são personalizáveis. Anteriormente, as tabelas de volume eram codificadas permanentemente. No formato XML, as tabelas de volume são descritas e podem ser customizadas.
O modelo em frameworks/av/services/audiopolicy/config/audio_policy_configuration.xml mostra muitos desses recursos em uso.
Formato e localização do arquivo
O novo arquivo de configuração de 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 Android 12 e para as versões abaixo do Android 12.
Mostrar exemplo de política de áudio para Android 12
A estrutura de nível superior contém módulos que correspondem a cada módulo de hardware HAL de áudio, onde cada módulo possui uma lista de portas de mixagem, portas de dispositivos e rotas:
As portas Mix descrevem os possíveis perfis de configuração para fluxos que podem ser abertos no áudio HAL para reprodução e captura.
As portas do dispositivo descrevem os dispositivos que podem ser conectados com seu tipo (e, opcionalmente, endereço e propriedades de áudio, se relevante).
Routes é separado do descritor de mix port, permitindo a descrição de rotas de dispositivo para dispositivo ou fluxo para dispositivo.
As tabelas de volume são listas simples de pontos que definem a curva usada para traduzir de um índice de interface do usuário 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.
O método XML Inclusions (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 devem 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.
O uso inclui para evitar a cópia de 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 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:
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 comum a todos os aplicativos. Semelhante ao AudioPolicyManager.cpp com funcionalidade de mecanismo e conceitos comuns abstraídos.
/common
Define classes base (por exemplo, estruturas de dados para perfis de fluxo de áudio de saída de entrada, descritores de dispositivos de áudio, patches de áudio e portas de áudio). Isso foi definido anteriormente dentro AudioPolicyManager.cpp .
/engine
Implementa as regras que definem qual dispositivo e volumes devem ser usados para um determinado caso de uso. Ele implementa uma interface padrão com a parte genérica, como obter o dispositivo apropriado para um determinado caso de uso de reprodução ou captura, ou definir dispositivos conectados ou estado externo (ou seja, um estado de chamada de uso forçado) que pode alterar o roteamento decisão.
Implementação do mecanismo de política que depende do Parameter Framework (veja abaixo). A configuração é baseada no Parameter Framework e onde a política é definida por arquivos XML.
/enginedefault
Implementação do mecanismo de políticas com base em implementações anteriores do Android Audio Policy Manager. Este é o padrão e inclui regras codificadas que correspondem às implementações do Nexus e AOSP.
/service
Inclui interfaces de fichário, encadeamento e implementação de bloqueio com a interface para o restante da estrutura.
Configuração usando o Parameter Framework
O código da política de áudio é organizado para facilitar a compreensão 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 baseado em regras para manipulação de parâmetros.
O uso da política de áudio configurável permite que os OEMs dos fornecedores:
Descreva a estrutura de um sistema e seus parâmetros em XML.
Escreva (em C++) ou reutilize um backend (plugin) para acessar os parâmetros descritos.
Defina (em XML ou em uma linguagem específica de domínio) condições/regras sobre as quais um determinado parâmetro deve ter 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 obter detalhes, consulte a documentação da Intel sobre o Parameter Framework .
No Android 10 ou inferior, a política de áudio configurável é selecionada usando a opção de compilação USE_CONFIGURABLE_AUDIO_POLICY . No Android 11 ou superior, 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:
O Android 6.0 introduziu uma API pública de enumeração e seleção que fica no topo da infraestrutura de patch de áudio/porta de áudio e permite que os desenvolvedores de aplicativos indiquem uma preferência por uma saída ou entrada de dispositivo específica para registros ou faixas de áudio conectadas.
No Android 7.0, a API de Enumeração e Seleção é verificada por testes CTS e estendida para incluir roteamento para fluxos de áudio C/C++ (OpenSL ES) nativos. O roteamento de fluxos 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 das classes AudioTrack e AudioRecord .
Para obter detalhes sobre a API de Enumeração e Seleção, consulte as interfaces de configuração do Android e OpenSLES_AndroidConfiguration.h . Para obter detalhes sobre roteamento de áudio, consulte AudioRouting .
Suporte multicanal
Se seu hardware e driver suportam áudio multicanal via HDMI, você pode enviar o fluxo de áudio diretamente para o hardware de áudio (isso ignora o mixer AudioFlinger para que não seja mixado para dois canais.) O HAL de áudio deve expor se um perfil de fluxo de saída suporta recursos de áudio multicanal. Se o HAL expor seus recursos, o gerenciador de políticas padrão permitirá a reprodução multicanal por HDMI. Para obter detalhes de implementação, consulte device/samsung/tuna/audio/audio_hw.c .
Para especificar que seu produto contém uma saída de áudio multicanal, edite o arquivo de configuração de política de áudio para descrever a saída multicanal para seu 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ítica de áudio consulta as máscaras de canal suportadas pelo coletor HDMI após a conexão.
Mostrar exemplo de configuração do dispositivo HDMI
Você também pode especificar uma máscara de canal estático como AUDIO_CHANNEL_OUT_5POINT1 . O mixer do AudioFlinger reduz o conteúdo para estéreo automaticamente quando enviado para um dispositivo de áudio que não suporta áudio multicanal.
Codecs de mídia
Certifique-se de que os codecs de áudio que seu hardware e drivers suportam estão declarados corretamente para o seu produto. Para obter detalhes, consulte Expondo 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.