La versión de Android 10 incluye una refactorización significativa del audio. para brindar más flexibilidad y admitir casos de uso complejos de la industria automotriz:
- Estrategias de enrutamiento específicas de OEM.
- Grupos de volúmenes personalizables para grupos de tipos de transmisiones heredadas con las mismas curvas de volumen.
- Estrategias de enrutamiento declaradas por el motor de políticas de audio en lugar de hard-coded.
- Curvas de volumen y grupos administrados por el motor de políticas de audio.
- Refactorización interno preparándose para una división futura entre el código común y el código configurable y ofrece una mejor administración de dispositivos de audio. Por ejemplo, el uso de todas las propiedades del dispositivo, no solo su tipo en las reglas de políticas.
Android 7.0 introdujo un formato de archivo de configuración de política de audio (XML) para al describir tu topología de audio.
Se requieren versiones anteriores de Android con
device/<company>/<device>/audio/audio_policy.conf
para declarar los dispositivos de audio presentes en tu producto (puedes ver un ejemplo de
este archivo para el hardware de audio de Galaxy Nexus en
device/samsung/tuna/audio/audio_policy.conf). Sin embargo, CONF es un
formato sencillo y patentado que es demasiado limitado para describir topologías complejas para
verticales como televisores y automóviles.
Android 7.0 dio de baja audio_policy.conf y agregó compatibilidad
para definir una topología de audio con un formato de archivo XML
legible por humanos, tiene una amplia gama de herramientas de edición y análisis, y es flexible
para describir topologías de audio complejas. Android 7.0 usa
Marca de compilación USE_XML_AUDIO_POLICY_CONF para elegir el XML
de los archivos de configuración.
Ventajas del formato XML
Al igual que en el archivo CONF, el archivo en formato XML permite definir la cantidad y los tipos. de los perfiles de transmisión de salida y entrada, dispositivos que se pueden usar para la reproducción y la captura, y atributos de audio. Además, el formato XML ofrece las siguientes mejoras:
- En Android 10, más de una app de grabación activa
se permite simultáneamente.
- El inicio de la grabación nunca se rechaza debido a una situación de simultaneidad.
- El
registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb)notifica a los clientes sobre los cambios en la ruta de captura.
- En las siguientes situaciones, un cliente obtiene muestras de audio silenciosas:
- Un caso de uso sensible a la privacidad (por ejemplo,
VOICE_COMMUNICATION) está activo. - El cliente no tiene un servicio o una IU en primer plano.
- La política reconoce los roles especiales:
- Servicio de accesibilidad: Puede grabar incluso si está activo un caso de uso sensible a la privacidad.
- Asistente: Se considera sensible a la privacidad si la IU está en la parte superior.
- Un caso de uso sensible a la privacidad (por ejemplo,
- Los perfiles de audio tienen una estructura similar a los descriptores de audio simples de HDMI, lo que permite que un conjunto de tasas de muestreo/máscaras de canal para cada formato de audio.
- Existen definiciones explícitas para todas las conexiones posibles entre dispositivos y transmisiones. Anteriormente, una regla implícita hacía posible conectar todos los dispositivos conectados a la misma HAL. lo que evita que la política de audio controle las conexiones solicitadas con el parche de audio APIs En el formato XML, la descripción de la topología define las limitaciones de conexión.
- La compatibilidad con incluye evita que se repita el envío de A2DP estándar, USB o redireccionamiento definiciones
- Las curvas de volumen se pueden personalizar. Anteriormente, las tablas de volúmenes estaban codificadas. En el archivo XML y las tablas de volúmenes, y se pueden personalizar.
La plantilla en
frameworks/av/services/audiopolicy/config/audio_policy_configuration.xml
muestra muchas de estas funciones en uso.
Formato y ubicación del archivo
El nuevo archivo de configuración de la política de audio
audio_policy_configuration.xml y se encuentra en
/system/etc En los siguientes ejemplos, se muestra una configuración de política de audio simple en el
Formato de archivo XML para Android 12 y las versiones que se indican a continuación
Android 12
La estructura de nivel superior contiene módulos que corresponden a cada HAL de audio de hardware, en el que cada módulo tiene una lista de puertos de combinación, puertos de dispositivos y rutas:
- Los puertos de mezcla describen los perfiles de configuración posibles para las transmisiones. que se puede abrir en la HAL de audio para reproducción y captura.
- Los puertos de dispositivos describen los dispositivos con los que se pueden conectar su tipo (y, opcionalmente, propiedades de dirección y audio, si corresponde)
- Las rutas están separadas del descriptor de puertos de combinación. habilitar la descripción de las rutas de un dispositivo a otro o transmitir a otro dispositivo.
Las tablas de volumen son listas simples de puntos que definen la curva que se usa para traducir de un índice de IU a un volumen en dB. Un archivo de inclusión independiente proporciona una configuración pero cada curva en un caso de uso y una categoría de dispositivo determinados se sobrescribirá.
Inclusiones de archivos
Se puede usar el método XML Inclusions (XInclude) para incluir la política de audio de configuración local en otros archivos en formato XML. Todos los archivos incluidos deben sigue la estructura descrita anteriormente con las siguientes restricciones:
- Los archivos solo pueden contener elementos de nivel superior.
- Los archivos no pueden contener elementos XInclude.
Usa inclusiones para evitar copiar el Proyecto de código abierto de Android (AOSP) estándar información de las configuraciones del módulo HAL de audio a toda la configuración de la política de audio archivos (que son propensos a errores). Un archivo en formato XML de configuración de política de audio estándar se proporciona para las siguientes HAL de audio:
- A2DP:
a2dp_audio_policy_configuration.xml - Redirigir submezcla:
rsubmix_audio_policy_configuration.xml - USB:
usb_audio_policy_configuration.xml
Organización del código de política de audio
AudioPolicyManager.cpp se divide en varios módulos
para que sea fácil de mantener
y configurar. La organización de
frameworks/av/services/audiopolicy incluye el
siguientes módulos.
| Módulo | Descripción |
|---|---|
/managerdefault |
Incluye las interfaces genéricas y la implementación de comportamientos comunes a todos
de Google Chat. Similar a AudioPolicyManager.cpp con motor
la funcionalidad y los conceptos
comunes abstraídos. |
/common |
Define clases de base (por ejemplo, estructuras de datos para transmisión de audio de entrada y salida
descriptores de dispositivos de audio, parches y puertos de audio). Anteriormente, se
definido dentro de AudioPolicyManager.cpp. |
/engine |
Implementa las reglas que definen para qué dispositivos y volúmenes deberían usarse. para un caso de uso determinado. Implementa una interfaz estándar con la parte genérica, como para obtener el dispositivo adecuado para un caso de uso determinado de reproducción o captura establecer dispositivos conectados o un estado externo (es decir, un estado de llamada de uso forzado) que puede alterar la decisión de enrutamiento. Disponible en dos versiones: configurable y predeterminada. Para obtener información sobre cómo seleccionar la versión, consulta Configuración con el marco de trabajo de parámetros. |
/engineconfigurable |
Implementación de un motor de políticas que se basa en el marco de trabajo de parámetros (consulta a continuación) La configuración se basa en el marco de trabajo de parámetros y en la ubicación de la política definidas por los archivos en formato XML. |
/enginedefault |
Implementación del motor de políticas basada en la versión anterior del Administrador de políticas de audio de Android de Google Cloud. Esta es la opción predeterminada. Incluye reglas hard-coded que corresponden a implementaciones de Nexus y AOSP. |
/service |
Incluye interfaces de Binder, subprocesos y ejecución de bloqueo con la interfaz al resto del framework. |
Configuración con el marco de trabajo de parámetros
El código de la política de audio está organizado para facilitar la comprensión mantener, a la vez que se admite una política de audio definida completamente por la configuración archivos. La organización y el diseño de la política de audio se basa en el parámetro de Intel. Framework, un framework basado en complementos y en reglas para controlar parámetros.
El uso de la política de audio configurable permite a los proveedores OEM hacer lo siguiente:
- Describe la estructura de un sistema y sus parámetros en XML.
- Escribe (en C++) o reutiliza un backend (complemento) para acceder a las parámetros.
- Definen (en XML o en un lenguaje específico del dominio) condiciones o reglas según las cuales un parámetro dado debe tener un valor determinado.
AOSP incluye un ejemplo de un archivo de configuración de política de audio que usa el parámetro
Framework en Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml. Para
consulta la documentación de Intel en la
Marco de parámetros.
En Android 10 o versiones anteriores, la política de audio configurable
se selecciona con la opción de compilación USE_CONFIGURABLE_AUDIO_POLICY.
En Android 11 o versiones posteriores, la versión de la política de audio
Engine está seleccionado en el archivo audio_policy_configuration.xml.
Para seleccionar el motor de política de audio configurable, establece el valor de engine_library
atributo del elemento globalConfiguration a configurable
como en el siguiente ejemplo:
<audioPolicyConfiguration> <globalConfiguration engine_library="configurable" /> ... </audioPolicyConfiguration>
APIs de enrutamiento de política de audio
Android 6.0 introdujo una API pública de enumeración y selección que se ubica en de la infraestructura de los puertos de audio y de los parches de audio, y permite los desarrolladores indicar una preferencia por una salida o entrada de dispositivo específica para pistas o grabaciones de audio conectadas.
En Android 7.0, la API de Enumeration and Selection se verifica con pruebas del CTS
y se extiende para incluir el enrutamiento de audio nativo de C/C++ (OpenSL ES).
El enrutamiento de transmisiones nativas sigue realizándose en Java, con la incorporación de
Una interfaz AudioRouting que reemplaza, combina y da de baja
los métodos de enrutamiento explícitos que eran específicos para AudioTrack y
AudioRecord clases.
Para obtener más información sobre la API de Enumeration and Selection, consulta
En Android
interfaces de configuración y OpenSLES_AndroidConfiguration.h.
Para obtener detalles sobre el enrutamiento de audio, consulta
AudioEnrutamiento.
Asistencia multicanal
Si el hardware y el controlador admiten audio multicanal por HDMI, puedes
enviar la transmisión de audio directamente al hardware de audio (esto evita la
el mezclador AudioFlinger para que no se mezcle en dos canales). La HAL de audio
Debe exponer si un perfil de transmisión de salida admite audio multicanal.
capacidades de integración. Si la HAL expone sus capacidades, el administrador de políticas
permite la reproducción en varios canales a través de HDMI. Para obtener más información sobre la implementación, consulta
device/samsung/tuna/audio/audio_hw.c
Para especificar que tu producto contiene una salida de audio multicanal, edita el
de configuración de políticas de audio para describir la salida multicanal de tu
producto. El siguiente ejemplo del
frameworks/av/services/audiopolicy/config/primary_audio_policy_configuration_tv.xml
Muestra una máscara de canal dinámica, lo que significa que el administrador de políticas de audio consulta el canal
que admite el receptor HDMI luego de la conexión.
También puedes especificar una máscara de canal estático, como
AUDIO_CHANNEL_OUT_5POINT1 El mezclador de AudioFlinger mezcla
el contenido a estéreo automáticamente cuando se envía a un dispositivo de audio que no
admitir audio multicanal.
Códecs de archivos multimedia
Asegúrate de que los códecs de audio que admiten el hardware y los controladores sean correctos declarado para tu producto. Para obtener más información, consulta Exponer códecs al Framework.