Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
O lançamento do Android 10 inclui uma refatoração significativa do
Gerenciador de políticas para oferecer mais flexibilidade e oferecer suporte a casos de uso automotivos complexos:
Estratégias de roteamento específicas do OEM.
Grupos de volumes personalizáveis para grupos de tipos de stream legados que usam as mesmas curvas de volume.
Estratégias de roteamento declaradas pelo mecanismo da 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
e 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ítica.
O Android 7.0 introduziu um formato de arquivo de configuração de política de áudio (XML) para
descrevendo sua topologia de áudio.
As versões anteriores do Android eram necessárias usando o
device/<company>/<device>/audio/audio_policy.conf
para declarar os dispositivos de áudio presentes no seu produto. Confira um exemplo
esse arquivo para o hardware de áudio do Galaxy Nexus
device/samsung/tuna/audio/audio_policy.conf). No entanto, CONF é uma
simples e reservado que é muito limitado para descrever topologias complexas para
verticais como televisões 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 que é mais
legível por humanos, possui 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
Sinalização de build USE_XML_AUDIO_POLICY_CONF para escolher o XML
dos arquivos de configuração.
Vantagens do formato XML
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
audio. Além disso, o formato XML oferece as seguintes melhorias:
No Android 10, há 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 registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb)
o callback notifica os clientes sobre as 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 interface de primeiro plano.
Os papéis especiais são reconhecidos pela política:
Serviço de acessibilidade: pode gravar mesmo se um caso de uso que envolve privacidade estiver ativo.
Google Assistente: considera a privacidade quando a interface está na parte de cima.
Os perfis de áudio têm uma estrutura semelhante aos descritores de áudio simples HDMI, permitindo um
conjunto 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 possibilitava conectar todos os dispositivos conectados à mesma HAL.
impedindo que a política de áudio controle as conexões solicitadas com o patch de áudio
APIs de terceiros. No formato XML, a descrição da topologia define limitações de conexão.
O suporte para inclui evita a repetição de envios de A2DP, USB ou redirecionamento padrão.
e definições.
As curvas de volume são personalizáveis. Antes, as tabelas de volume eram fixadas no código. No 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 simples de política de áudio na
Formato de arquivo XML para o Android 12 e para as versões abaixo
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 HAL de áudio.
módulo de hardware, em que cada módulo tem uma lista de portas de mix, portas de dispositivos e
rotas:
As portas de mix descrevem os possíveis perfis de configuração para streams
que pode ser aberta na HAL de áudio para reprodução e captura.
As portas do dispositivo descrevem os dispositivos que podem ser conectados
o tipo (e, opcionalmente, propriedades de endereço e áudio, se relevante).
Routes são separados do descritor da porta de combinação,
ativando a descrição de trajetos de um dispositivo para outro ou de um stream para outro.
As tabelas de volume são listas simples de pontos que definem a curva usada para converter
de um índice de IU para um volume em dB. Um arquivo de inclusão separado fornece padrões
mas cada curva para um determinado caso de uso e categoria de dispositivo pode ser
substituída.
O método de inclusões XML (XInclude) pode ser usado para incluir a política de áudio
informações de configuração localizadas em outros arquivos XML. Todos os arquivos incluídos devem
siga 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 inclusões para evitar a cópia do Android Open Source Project (AOSP) padrão
informações de configurações do módulo HAL de áudio para todas as configurações da política de áudio
(que é propenso a erros). Um arquivo XML de configuração de política de áudio padrão
é fornecido para as 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
frameworks/av/services/audiopolicy inclui o
módulos a seguir.
Module
Descrição
/managerdefault
Inclui a implementação de interfaces genéricas e comportamentos comuns a todos
apps. Semelhante a AudioPolicyManager.cpp com mecanismo
e conceitos comuns abstraídos.
/common
Define classes de base (por exemplo, estruturas de dados para stream de áudio de entrada e saída)
perfis, descritores de dispositivos de áudio, patches de áudio e portas de áudio). Anteriormente, isso era
definidos em AudioPolicyManager.cpp.
/engine
implementa as regras que definem quais dispositivos e volumes devem ser usados
em um determinado caso de uso. Ele implementa uma interface padrão com a parte genérica, como
sobre como conseguir o dispositivo apropriado para um determinado caso de uso de reprodução ou captura, ou
definem os dispositivos conectados ou um estado externo (ou seja, um estado de chamada de uso forçado) que
pode alterar a decisão do trajeto.
Implementação do mecanismo de política que se baseia na estrutura de parâmetros (veja abaixo).
A configuração é baseada na estrutura de parâmetros e no local em que a política é
definidos por arquivos XML.
/enginedefault
Implementação do mecanismo de política com base no Gerenciador de políticas de áudio do Android
e implementações. Esse é o padrão e inclui regras codificadas 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
da interface para o restante do framework.
Configuração usando a estrutura de parâmetros
O código da política de áudio é organizado para facilitar o entendimento e
manter e, ao mesmo tempo, oferecer suporte a uma política de áudio definida inteiramente pela configuração
. O design da política de áudio e organização é baseado nos parâmetros da Intel
Framework, um framework com base em plug-ins e regras para lidar com 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 o conteúdo
parâmetros.
Defina (em XML ou em um idioma específico do 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 parâmetro
Framework em Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml. Para
mais detalhes, consulte a documentação da Intel
Estrutura de parâmetros.
No Android 10 ou versões anteriores, a política de áudio configurável
é selecionado usando a opção de build USE_CONFIGURABLE_AUDIO_POLICY.
No Android 11 ou mais recente, a versão da política de áudio
está selecionado no arquivo audio_policy_configuration.xml.
Para selecionar o mecanismo da política de áudio configurável, defina o valor de engine_library
atributo do elemento globalConfiguration para configurable
como no exemplo a seguir:
O Android 6.0 introduziu uma API Enumeration and Selection pública localizada no
da infraestrutura de patch/porta de áudio e permite que o app
os desenvolvedores a indicar sua preferência por uma saída ou entrada específica do dispositivo
gravações ou faixas de áudio conectadas.
No Android 7.0, a API Enumeration and Selection é verificada por testes CTS
e é estendido 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 dos métodos AudioTrack e
AudioRecord.
Se o hardware e o driver forem compatíveis com áudio multicanal via HDMI, será possível
envia o stream de áudio diretamente para o hardware de áudio (isso ignora a
Mixer do AudioFlinger para que ele não seja reduzido a dois canais. A HAL de áudio
precisa mostrar se um perfil de stream de saída oferece suporte a áudio multicanal.
recursos. Se a HAL expor seus recursos, o gerenciador de políticas padrão
permite a reprodução multicanal por HDMI. Para 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 as
do arquivo de configuração da política de áudio para descrever a saída multicanal do seu
produto. O exemplo a seguir
frameworks/av/services/audiopolicy/config/primary_audio_policy_configuration_tv.xml
exibe uma máscara de canal dinâmica, o que significa que o gerenciador de políticas de áudio consulta o canal
máscaras compatíveis com o coletor HDMI após a conexão.
Mostrar exemplo de configuração do dispositivo HDMI
Também é possível especificar uma máscara de canal estática, como
AUDIO_CHANNEL_OUT_5POINT1: O mixer do AudioFlinger faz downmix
conteúdo para estéreo automaticamente quando enviado a um dispositivo de áudio que não
são compatíveis com áudio multicanal.
Codecs de mídia
Verifique se os codecs de áudio compatíveis com hardware e drivers estão corretos
declaradas para seu produto. Para mais detalhes, consulte
Como expor 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.
Última atualização 2024-08-23 UTC.
[{
"type": "thumb-down",
"id": "missingTheInformationINeed",
"label":"Não contém as informações de que eu preciso"
},{
"type": "thumb-down",
"id": "tooComplicatedTooManySteps",
"label":"Muito complicado / etapas demais"
},{
"type": "thumb-down",
"id": "outOfDate",
"label":"Desatualizado"
},{
"type": "thumb-down",
"id": "translationIssue",
"label":"Problema na tradução"
},{
"type": "thumb-down",
"id": "samplesCodeIssue",
"label":"Problema com as amostras / o código"
},{
"type": "thumb-down",
"id": "otherDown",
"label":"Outro"
}]
[{
"type": "thumb-up",
"id": "easyToUnderstand",
"label":"Fácil de entender"
},{
"type": "thumb-up",
"id": "solvedMyProblem",
"label":"Meu problema foi resolvido"
},{
"type": "thumb-up",
"id": "otherUp",
"label":"Outro"
}]
{"lastModified": "\u00daltima atualiza\u00e7\u00e3o 2024-08-23 UTC."}
