La versión de Android 10 incluye una refactorización significativa del administrador de políticas de audio para proporcionar más flexibilidad y admitir casos de uso complejos de la industria automotriz:
- Estrategias de enrutamiento específicas del OEM
- Grupos de volumen personalizables para grupos de tipos de transmisión heredados que usan las mismas curvas de volumen
- Estrategias de enrutamiento declaradas por el motor de políticas de audio en lugar de estar codificadas de forma fija.
- Curvas de volumen y grupos administrados por el motor de políticas de audio.
- Refactorización interno que se prepara para una futura división entre el código común y el código configurable, y ofrece una administración de dispositivos de audio más enriquecida. 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 tu topología de audio.
Se requieren versiones anteriores de Android que usen 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 de propiedad que se limita demasiado a 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 en formato XML que es más legible por humanos, tiene una amplia variedad 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 la marca 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 la reproducción y la captura, y los atributos de audio. Además, el formato XML ofrece las siguientes mejoras:
- En Android 10, se permite más de una app de grabación activa de forma simultánea.
- El inicio de la grabación nunca se rechaza debido a una situación de simultaneidad.
- 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 recibe 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 IU en primer plano.
- La política reconoce los siguientes roles especiales:
- Servicio de accesibilidad: Puede grabar incluso si hay un caso de uso sensible a la privacidad activo.
- 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 un conjunto diferente de tasas de muestreo o máscaras de canales 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 APIs de parche de audio. En el formato XML, la descripción de la topología define las limitaciones de conexión.
- La compatibilidad con includes evita repetir las definiciones estándar de A2DP, USB o reenvío.
- Las curvas de volumen se pueden personalizar. Anteriormente, las tablas de volumen estaban codificadas de forma fija. En el formato XML, se describen las tablas de volumen y se pueden personalizar.
La plantilla de 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. 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 para las versiones anteriores a Android 12.
La estructura de nivel superior contiene módulos que corresponden a cada módulo de hardware de HAL de audio, donde cada módulo tiene una lista de puertos de combinación, puertos de dispositivo y rutas:
- Los puertos de combinación describen los posibles perfiles de configuración para las transmisiones que se pueden abrir en el HAL de audio para la reproducción y la captura.
- Los puertos de dispositivos describen los dispositivos que se pueden conectar con su tipo (y, de manera opcional, la dirección y las propiedades de audio, si corresponde).
- Routes está separado del descriptor de puerto de combinación, 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 de IU a un volumen en dB. Un archivo de inclusión independiente proporciona curvas predeterminadas, pero se puede reemplazar 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 usar para incluir información de configuración de la política de audio que se encuentra en otros archivos en formato 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.
Usa includes para evitar copiar la información de configuración del módulo HAL de audio del Proyecto de código abierto de Android (AOSP) estándar a todos los archivos de configuración de políticas de audio (lo que es propenso a errores). Se proporciona un archivo en formato XML de configuración de políticas de audio estándar para los siguientes HAL de audio:
- A2DP:
a2dp_audio_policy_configuration.xml - Reenvía el submix:
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 el mantenimiento y la 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 comportamiento comunes a todas las apps. Es similar a AudioPolicyManager.cpp, con la funcionalidad del motor y los conceptos comunes abstraídos. |
/common |
Define clases de 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 definía anteriormente dentro de AudioPolicyManager.cpp. |
/engine |
Implementa las reglas que definen qué dispositivo y volúmenes se deben usar 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 de reproducción o captura determinado, o para configurar dispositivos conectados o estado externo (es decir, un estado de llamada de uso forzado) que puede alterar la decisión de enrutamiento. Está disponible en dos versiones: configurable y predeterminada. Para obtener información sobre cómo seleccionar la versión, consulta Configuración con el Framework de parámetros. |
/engineconfigurable |
Implementación del motor de políticas que se basa en Parameter Framework (consulta a continuación). La configuración se basa en el marco de trabajo de parámetros y en el que los archivos en formato XML definen la política. |
/enginedefault |
Implementación del motor de políticas basada en implementaciones anteriores del Administrador de políticas de audio de Android Esta es la opción predeterminada y, además, incluye reglas hard-coded que corresponden a implementaciones de Nexus y AOSP. |
/service |
Incluye interfaces de Binder, implementación de bloqueos y subprocesos, con la interfaz para el resto del framework. |
Configuración con el framework de parámetros
El código de la política de audio está organizado para que sea fácil de entender y mantener, a la vez que admite una política de audio definida por completo por archivos de configuración. El diseño de la organización y la política de audio se basa en el Framework de parámetros de Intel, un framework basado en complementos y reglas para controlar parámetros.
El uso de la política de audio configurable permite a los OEMs de los proveedores 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 los parámetros descritos.
- Definen (en XML o en un lenguaje específico del dominio) condiciones o 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 usa el Framework de parámetros en Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml. Para obtener más información, consulta la documentación de Intel sobre el framework 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 del motor de políticas de audio se selecciona en el archivo audio_policy_configuration.xml.
Para seleccionar el motor de políticas de audio configurable, establece el valor del atributo engine_library del elemento globalConfiguration en configurable, como en el siguiente ejemplo:
<audioPolicyConfiguration> <globalConfiguration engine_library="configurable" /> ... </audioPolicyConfiguration>
APIs 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 o el parche de audio y permite que los desarrolladores de apps indiquen una preferencia por una salida o entrada de dispositivo específica para pistas o grabaciones de audio conectadas.
En Android 7.0, las pruebas de CTS verifican la API de Enumeration and Selection y la extienden para incluir el enrutamiento de flujos de audio nativos de C/C++ (OpenSL ES).
El enrutamiento de transmisiones nativas se sigue realizando en Java, con la adición de una interfaz AudioRouting que reemplaza, combina y da de baja los métodos de enrutamiento explícitos que eran específicos de las clases AudioTrack y AudioRecord.
Para obtener detalles sobre la API de Enumeration and Selection, consulta Interfaces de configuración de Android y OpenSLES_AndroidConfiguration.h.
Para obtener más información sobre el enrutamiento de audio, consulta AudioRouting.
Asistencia multicanal
Si el hardware y el controlador admiten audio multicanal a través de HDMI, puedes enviar la transmisión de audio directamente al hardware de audio (esto pasa por alto el mezclador de AudioFlinger para que no se reduzca a dos canales). El HAL de audio debe exponer si un perfil de flujo de salida admite capacidades de audio multicanal. Si el sistema 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, consulta device/samsung/tuna/audio/audio_hw.c.
Para especificar que tu producto contiene una salida de audio multicanal, edita el archivo de configuración de la política de audio para describir la salida multicanal del producto. En el siguiente ejemplo de frameworks/av/services/audiopolicy/config/primary_audio_policy_configuration_tv.xml, se 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 compatibles con el receptor HDMI después de la conexión.
También puedes especificar una máscara de canal estática, como AUDIO_CHANNEL_OUT_5POINT1. El mezclador de AudioFlinger baja el contenido a estéreo automáticamente cuando se envía a un dispositivo de audio que no admite audio multicanal.
Códecs de archivos multimedia
Asegúrate de que los códecs de audio que admiten el hardware y los controladores estén declarados correctamente para tu producto. Para obtener más detalles, consulta Cómo exponer códecs al framework.