La versión 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 automotrices complejos:
- Estrategias de enrutamiento específicas de OEM.
- Grupos de volúmenes 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 que se prepara para una futura división entre código común y código configurable y ofrece una gestión de dispositivos de audio más rica. 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 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 usar audio_policy.conf y agregó soporte para definir una topología de audio usando un formato de archivo XML que es más legible para los humanos, tiene una amplia gama de herramientas de edición y análisis y es lo suficientemente flexible como 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 el número y los tipos de perfiles de flujo de entrada y salida, dispositivos utilizables para reproducción y captura, y 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 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 en primer plano ni una interfaz de usuario en primer plano.
- La póliza reconoce funciones especiales:
- Servicio de accesibilidad: puede grabar incluso si hay activo un caso de uso sensible a la privacidad.
- 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 HDMI, lo que permite un conjunto diferente de frecuencias 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 permitía conectar todos los dispositivos conectados al mismo módulo HAL, lo que impedía 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 la conexión.
- La compatibilidad con inclusiones evita repetir definiciones estándar de envío A2DP, USB o redireccionamiento.
- Las curvas de volumen son personalizables. Anteriormente, las tablas de volúmenes estaban codificadas. En formato XML, las tablas de volúmenes se describen 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 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 inferiores a Android 12.
La estructura de nivel superior contiene módulos que corresponden a cada módulo de hardware de audio HAL, donde cada módulo tiene una lista de puertos de mezcla, puertos de dispositivo y rutas:
- Los puertos de mezcla describen los posibles perfiles de configuración para transmisiones que se pueden abrir en el HAL de audio para reproducción y captura.
- Los puertos de dispositivos describen los dispositivos que se pueden conectar con su tipo (y, opcionalmente, las propiedades de dirección y 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 transmisión a dispositivo.
Las tablas de volumen son listas simples de puntos que definen la curva utilizada para traducir de un índice UI a un volumen en dB. Un archivo de inclusión independiente proporciona curvas predeterminadas, pero cada curva para un caso de uso y categoría de dispositivo determinados se puede sobrescribir.
Inclusiones de archivos
El método XML Inclusions (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) a todos los archivos de configuración de políticas de audio (lo cual es propenso a errores). Se proporciona un archivo XML de configuración de política de audio estándar para los 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 funcionalidad del motor y conceptos comunes abstraídos. |
/common | Define clases base (por ejemplo, estructuras de datos para perfiles de flujo de audio de entrada y salida, descriptores de dispositivos de audio, parches de audio y puertos de audio). Esto se definió previamente dentro de AudioPolicyManager.cpp . |
/engine | Implementa las reglas que definen qué dispositivo y volúmenes se deben utilizar 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 configurar dispositivos conectados o estados externos (es decir, un estado de llamada de uso forzado) que puede alterar el enrutamiento. decisión. Disponible en dos versiones: configurable y predeterminada . Para obtener información sobre cómo seleccionar la versión, consulte Configuración mediante Parameter Framework . |
/engineconfigurable | Implementación del motor de políticas que se basa en Parameter Framework (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 carpeta, subprocesamiento y implementación de bloqueo con la interfaz con el resto del marco. |
Configuración utilizando el marco de parámetros
El código de la política de audio está organizado para que sea fácil de entender y mantener y, al mismo tiempo, admite una política de audio definida completamente por archivos de configuración. El diseño de la política de audio y organización se basa en el Parameter Framework de Intel, un marco basado en complementos y reglas para manejar 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 de dominio) condiciones/reglas según las cuales un parámetro determinado debe tomar un valor determinado.
AOSP incluye un ejemplo de un archivo de configuración de política de audio que utiliza Parameter Framework 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 Parameter Framework .
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 ubica en la parte superior de la infraestructura del puerto de audio/parche de audio y permite a los desarrolladores de aplicaciones indicar una preferencia por una salida o entrada de dispositivo específica para pistas o registros 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 enrutamiento para transmisiones de audio nativas C/C++ (OpenSL ES). El enrutamiento de transmisiones nativas continúa realizándose en Java, con la adición de una interfaz AudioRouting que reemplaza, combina y desaprueba 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 AudioRouting .
Soporte multicanal
Si su hardware y controlador admiten audio multicanal a través de HDMI, puede enviar la transmisión 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 transmisión 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 de 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 receptor 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 mezcla el contenido a 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 que admite su hardware y controladores estén declarados correctamente para su producto. Para obtener más información, consulte Exponer códecs al marco .