A partir de Android 16, la interfaz de la HAL de audio de AIDL es totalmente compatible con la política de audio configurable (CAP).
En esta página, se proporcionan los antecedentes técnicos necesarios para ayudar a los socios y proveedores de SoC a migrar sus parámetros de configuración de políticas de audio.
El framework de parámetros
La implementación del CAP se basa en el Framework de parámetros de Intel. El CAP se introdujo en Android 6. El Framework de parámetros (PfW) permite describir un sistema en términos de parámetros. Cuando se usa un archivo XML de configuración, el PfW vincula los parámetros a acciones con complementos y proporciona reglas para cambiar los parámetros según los criterios actuales.
Estructura de CAP en HIDL
En HIDL, toda la configuración del CAP se especificaba en XML. Consulta Parameter Framework y Configuración con Parameter Framework para obtener más información. Se usaron archivos en formato XML para especificar lo siguiente:
- Descripción de la estructura de los parámetros (es decir, la descripción del dominio de audio para la PfW)
- Definiciones de los criterios
- Reglas para estrategias de enrutamiento (selección de dispositivos de entrada y salida)
- Especificación de las tablas de volúmenes
Con HIDL, el framework de Android pudo cargar estos archivos en formato XML directamente desde la partición del proveedor. Esto se permitió porque se definió un esquema XSD, como parte de la API de HAL, para estos archivos en formato XML. Cada versión principal del HAL de HIDL tenía un esquema XSD correspondiente. Las versiones principales no requerían compatibilidad con versiones anteriores.
Estructura de CAP en AIDL
Con la transición a AIDL, las versiones de la API de HAL deben seguir siendo retrocompatibles (en términos de HIDL, cada versión del HAL de AIDL es una actualización "menor"). Los esquemas XSD ya no se pueden usar como parte de las APIs de HAL, ya que no hay una forma establecida de definir actualizaciones retrocompatibles de los esquemas. Por lo tanto, el HAL ahora debe proporcionar la configuración que se definió anteriormente en los archivos en formato XML con las APIs de AIDL. Para facilitar esto, la estructura de la configuración de CAP se convierte a AIDL, similar a los archivos en formato XML de configuración de la política de audio en el HAL de audio de AIDL para Android 15.
Las estructuras de datos para la CAP se agregan a los tipos de datos estables comunes y, además, incluyen los siguientes elementos parcelables:
AudioHalCapConfiguration.aidlAudioHalCapCriterionV2.aidlAudioHalCapDomain.aidlAudioHalCapParameter.aidlAudioHalCapRule.aidl
El punto de entrada para la configuración de CAP se encuentra en la estructura AudioHalEngineConfig.CapSpecificConfig. Consulta los comentarios en AudioHalCapConfiguration.aidl para ver un diagrama de las estructuras de datos de CAP.
La implementación predeterminada del HAL de AIDL contiene una clase de ayuda que completa los elementos parcelables de AIDL según el contenido de los archivos en formato XML de CAP heredados para simplificar la migración para los socios.
Situaciones de migración
Los socios pueden considerar las opciones que se enumeran en esta sección, según si se trata del primer lanzamiento de un producto que no usaba CAP antes o de la migración de un producto existente.
Producto nuevo
En el caso de un producto nuevo que comienza a usar CAP para la implementación de políticas de audio, el OEM puede optar por usar XML para almacenar la configuración de CAP del proveedor.
El beneficio de usar XML es que existe un conjunto de herramientas de secuencias de comandos que facilitan la generación de la configuración a partir de una descripción de alto nivel.
Si el OEM decide usar XML para almacenar la configuración de CAP en la partición del proveedor, se recomienda usar la implementación predeterminada del analizador de XML para convertir la configuración en AIDL.
Actualización de un producto existente
Si el producto ya usa CAP y, por lo tanto, tiene la configuración XML, puedes seguir usando el CAP existente con la versión AIDL del HAL.
La convención de nombres para las estrategias de productos difiere en las versiones HIDL y AIDL de la configuración de CAP. En HIDL, las estrategias integradas ("heredadas") usaban nombres cortos en minúsculas, como media, mientras que en AIDL, las estrategias integradas usan nombres en mayúsculas con el prefijo STRATEGY_, por ejemplo, STRATEGY_MEDIA. Consulta la lista de estrategias integradas en CapProductStrategies.xml.
En el mismo archivo, se definen los IDs "asignados de antemano" para las estrategias específicas del OEM que siguen el patrón de nombres de vx_10xx con números del 1000 al 1039.
Producto heredado
Si el producto que se basa en CAP no actualiza su partición de proveedor y permanece en HIDL, puedes actualizar la partición del sistema a Android 16. El framework sigue siendo compatible con la configuración de CAP heredada.
Ejemplo de implementación
Para ayudar a los socios a implementar CAP para sus plataformas, el AOSP tiene un ejemplo de la variante "automotriz" del dispositivo virtual Cuttlefish que usa CAP con HAL de AIDL. La configuración específica del dispositivo se encuentra en device/google/cuttlefish/shared/auto/audio/policy/engine, con el nombre de destino lunch de aosp_cf_x86_64_auto. El archivo Android.bp se puede usar como referencia para generar el conjunto completo de archivos de proveedores de CAP.