El lanzamiento de Android 10 incluye una refactorización significativa del administrador de políticas de audio para brindar más flexibilidad para admitir casos de uso automotriz complejos:
- Estrategias de enrutamiento específicas del OEM.
- Grupos de volumen personalizables para grupos de tipos de flujo heredados que utilizan las mismas curvas de volumen.
- Estrategias de enrutamiento declaradas por el motor de políticas de audio en lugar de estar codificadas.
- Curvas de volumen y grupos gestionados por el motor de políticas de audio.
- Refactorización interna preparándose para una futura división entre código común y código configurable y ofreciendo una gestión de dispositivos de audio más completa. Por ejemplo, el uso de todas las propiedades del dispositivo, no solo su tipo en las reglas de política.
Android 7.0 introdujo un formato de archivo de configuración de políticas de audio (XML) para describir su topología de audio.
Las versiones anteriores de Android requerían usar device/<company>/<device>/audio/audio_policy.conf para declarar los dispositivos de audio presentes en su producto (puede ver un ejemplo de este archivo para el hardware de audio Galaxy Nexus en device/samsung/tuna/audio/audio_policy.conf ). Sin embargo, CONF es un formato propietario simple que es demasiado limitado para describir topologías complejas para verticales como televisores y automóviles.
Android 7.0 dejó de audio_policy.conf y agregó soporte para definir una topología de audio usando un formato de archivo XML que es más legible, tiene una amplia variedad de herramientas de edición y análisis, y es lo suficientemente flexible para describir topologías de audio complejas. Android 7.0 usa el indicador de compilación USE_XML_AUDIO_POLICY_CONF para elegir el formato XML de los archivos de configuración.
Ventajas del formato XML
Al igual que en el archivo CONF, el archivo XML permite definir la cantidad y los tipos de perfiles de flujo de entrada y salida, los dispositivos que se pueden usar para reproducir y capturar, y los atributos de audio. Además, el formato XML ofrece las siguientes mejoras:
- En Android 10, se permite más de una aplicación de grabación activa simultáneamente.
- El inicio de la grabación nunca se rechaza debido a una situación de concurrencia.
- La devolución de llamada
registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb)notifica a los clientes 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 en primer plano ni una interfaz de usuario en primer plano.
- Los roles especiales son reconocidos por la política:
- Servicio de accesibilidad: Puede grabar incluso si un caso de uso sensible a la privacidad está activo.
- Asistente: se considera sensible a la privacidad si la interfaz de usuario 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 un conjunto diferente de frecuencias de muestreo/máscaras de canal para cada formato de audio.
- Hay definiciones explícitas para todas las conexiones posibles entre dispositivos y flujos. Anteriormente, una regla implícita permitía conectar todos los dispositivos conectados al mismo módulo HAL, lo que evitaba que la política de audio controlara las conexiones solicitadas con las API de parches de audio. En el formato XML, la descripción de la topología define las limitaciones de conexión.
- La compatibilidad con incluye evita la repetición de definiciones de envío de redireccionamiento, USB o A2DP estándar.
- Las curvas de volumen son personalizables. Anteriormente, las tablas de volumen estaban codificadas. En el formato XML, las tablas de volumen se describen y se pueden personalizar.
La plantilla en frameworks/av/services/audiopolicy/config/audio_policy_configuration.xml muestra muchas de estas características en uso.
Formato de archivo y ubicación
El nuevo archivo de configuración de la política de audio es audio_policy_configuration.xml y se encuentra en /system/etc . Los siguientes ejemplos muestran una configuración de política de audio simple en el formato de archivo XML para Android 12 y para las versiones anteriores a Android 12.
La estructura de nivel superior contiene módulos que corresponden a cada módulo de hardware HAL de audio, donde cada módulo tiene una lista de puertos de mezcla, puertos de dispositivos y rutas:
- Los puertos mixtos describen los posibles perfiles de configuración para transmisiones que se pueden abrir en la HAL de audio para reproducción y captura.
- Los puertos de dispositivo describen los dispositivos que se pueden conectar con su tipo (y, opcionalmente, la dirección y las propiedades de audio, si corresponde).
- Las rutas están separadas del descriptor de puerto mixto, lo que permite la descripción de rutas de dispositivo a dispositivo o de flujo a dispositivo.
Las tablas de volumen son listas simples de puntos que definen la curva utilizada para traducir de un índice de interfaz de usuario a un volumen en dB. Un archivo de inclusión separado proporciona curvas predeterminadas, pero se puede sobrescribir cada curva para un caso de uso y una categoría de dispositivo determinados.
inclusiones de archivos
El método de inclusiones XML (XInclude) se puede utilizar para incluir información de configuración de políticas de audio ubicada en otros archivos XML. Todos los archivos incluidos deben seguir la estructura descrita anteriormente con las siguientes restricciones:
- Los archivos solo pueden contener elementos de nivel superior.
- Los archivos no pueden contener elementos XInclude.
El uso incluye para evitar copiar la información de configuración del módulo HAL de audio estándar del Proyecto de código abierto de Android (AOSP) en todos los archivos de configuración de políticas de audio (que es propenso a errores). Se proporciona un archivo XML de configuración de política de audio estándar 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 facilitar su mantenimiento y configuración. La organización de frameworks/av/services/audiopolicy incluye los siguientes módulos.
| Módulo | Descripción |
|---|---|
/managerdefault | Incluye las interfaces genéricas y la implementación de comportamientos comunes a todas las aplicaciones. Similar a AudioPolicyManager.cpp con la funcionalidad del motor y los conceptos comunes abstraídos. |
/common | Define clases base (por ejemplo, estructuras de datos para perfiles de transmisión de audio de entrada y salida, descriptores de dispositivos de audio, parches de audio y puertos de audio). Esto se definió previamente dentro AudioPolicyManager.cpp . |
/engine | Implementa las reglas que definen qué dispositivo y volúmenes deben usarse para un caso de uso determinado. Implementa una interfaz estándar con la parte genérica, como para obtener el dispositivo apropiado para un caso de uso de reproducción o captura determinado, o para establecer dispositivos conectados o estado externo (es decir, un estado de llamada de uso forzado) que puede alterar el enrutamiento decisión. Disponible en dos versiones: configurable y por defecto . Para obtener información sobre cómo seleccionar la versión, consulte Configuración utilizando Framework de parámetros . |
/engineconfigurable | Implementación del motor de políticas que se basa en el marco de parámetros (ver más abajo). La configuración se basa en el marco de parámetros y donde la política se define mediante archivos XML. |
/enginedefault | Implementación del motor de políticas basada en implementaciones anteriores de Android Audio Policy Manager. Este es el valor predeterminado e incluye reglas codificadas que corresponden a las implementaciones de Nexus y AOSP. |
/service | Incluye interfaces de enlace, subprocesamiento e implementación de bloqueo con la interfaz para el resto del marco. |
Configuración utilizando Framework de parámetros
El código de la política de audio está organizado para que sea fácil de entender y mantener, al mismo tiempo que admite una política de audio definida completamente por archivos de configuración. El diseño de la política de organización y audio se basa en el marco de parámetros de Intel, un marco basado en complementos y reglas para el manejo de parámetros.
El uso de la política de audio configurable permite a los proveedores OEM:
- Describir la estructura de un sistema y sus parámetros en XML.
- Escriba (en C++) o reutilice un backend (complemento) para acceder a los parámetros descritos.
- Defina (en XML o en un lenguaje específico del dominio) condiciones/reglas sobre las cuales un parámetro dado debe tomar un valor dado.
AOSP incluye un ejemplo de un archivo de configuración de política de audio que usa el marco de parámetros en Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml . Para obtener más información, consulte la documentación de Intel sobre el marco de parámetros .
En Android 10 o versiones anteriores, la política de audio configurable se selecciona mediante la opción de compilación USE_CONFIGURABLE_AUDIO_POLICY . En Android 11 o superior, la versión del motor de políticas de audio se selecciona en el archivo audio_policy_configuration.xml . Para seleccionar el motor de política de audio configurable, establezca el valor del atributo engine_library del elemento globalConfiguration en configurable como en el siguiente ejemplo:
<audioPolicyConfiguration> <globalConfiguration engine_library="configurable" /> ... </audioPolicyConfiguration>
API de enrutamiento de políticas de audio
Android 6.0 introdujo una API pública de enumeración y selección que se encuentra sobre la infraestructura de parches de audio/puertos de audio y permite a los desarrolladores de aplicaciones indicar una preferencia por una salida o entrada de dispositivo específico para registros o pistas de audio conectados.
En Android 7.0, la API de enumeración y selección se verifica mediante pruebas CTS y se amplía para incluir el enrutamiento para flujos de audio nativos C/C++ (OpenSL ES). El enrutamiento de flujos nativos se sigue realizando en Java, con la adición de una interfaz AudioRouting que reemplaza, combina y descarta los métodos de enrutamiento explícitos que eran específicos de las clases AudioTrack y AudioRecord .
Para obtener detalles sobre la API de enumeración y selección, consulte las interfaces de configuración de Android y OpenSLES_AndroidConfiguration.h . Para obtener detalles sobre el enrutamiento de audio, consulte Enrutamiento de audio.
Soporte multicanal
Si su hardware y controlador admiten audio multicanal a través de HDMI, puede enviar el flujo de audio directamente al hardware de audio (esto omite el mezclador AudioFlinger para que no se mezcle en dos canales). El HAL de audio debe exponer si un perfil de flujo de salida admite capacidades de audio multicanal. Si HAL expone sus capacidades, el administrador de políticas predeterminado permite la reproducción multicanal a través de HDMI. Para obtener detalles sobre la implementación, consulte device/samsung/tuna/audio/audio_hw.c .
Para especificar que su producto contiene una salida de audio multicanal, edite el archivo de configuración de la política de audio para describir la salida multicanal de su producto. El siguiente ejemplo de 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 las máscaras de canal admitidas por el sumidero HDMI después de la conexión.
También puede especificar una máscara de canal estática como AUDIO_CHANNEL_OUT_5POINT1 . El mezclador de AudioFlinger convierte el contenido en estéreo automáticamente cuando se envía a un dispositivo de audio que no admite audio multicanal.
Códecs multimedia
Asegúrese de que los códecs de audio compatibles con su hardware y los controladores estén declarados correctamente para su producto. Para obtener más información, consulte Exposición de códecs en el marco .