Motor de políticas de audio configurable

En Android 14, el sistema operativo Android Automotive (AAOS) aprovecha el motor de política de audio configurable (CAP) para la administración de audio del automóvil dentro de la zona de audio principal. Específicamente, el motor de CAP permite que AAOS controle solo el enrutamiento de audio, solo el volumen de audio o ambos de forma simultánea. Se pueden usar las siguientes marcas para controlar el comportamiento:

• Usa la marca useCoreAudioVolume para habilitar la administración de volumen de CAP. Cuando este valor es true, el servicio de audio del automóvil usa las APIs del administrador de audio para administrar los grupos de volumen.

• Usa la marca useCoreAudioRouting para habilitar la administración del enrutamiento de audio de CAP. Cuando este valor es true, el servicio de audio del automóvil usa el enrutamiento de políticas de audio configurable para administrar el enrutamiento de audio.

El motor de políticas de audio también es compatible con Android de forma predeterminada en forma del motor de políticas de audio predeterminado.

Información general

El motor de CAP se basa en el framework de parámetros de Intel, que es un framework basado en reglas y complementos para controlar parámetros. En el caso específico de la administración de audio de Android, el motor de CAP introdujo la capacidad de definir reglas de archivos XML para especificar lo siguiente:

• Estrategia de productos de audio
• Reglas para la selección del dispositivo de salida de audio
• Reglas para la selección de dispositivos de entrada de audio
• Reglas para administrar el volumen y el silencio junto con las tablas de volumen

Inicialización del CAP antes de Android 16

En la siguiente figura, se muestra una descripción general de alto nivel de la administración de la configuración del motor de políticas de audio configurable en Android 6:

Figura 1: Administración de la configuración del motor de CAP a partir de Android 6.

Como se muestra en la figura, el servicio de políticas de audio obtiene la configuración del motor de CAP analizando la información del archivo audio_policy_engine_configuration.xml en la partición vendor. El archivo de configuración del motor de CAP usa el esquema definido en audio_policy_engine_configuration.xsd para obtener la información requerida. audio_policy_engine_configuration.xml es un ejemplo para la industria automotriz. En la carpeta frameworks/av/services/audiopolicy/engineconfigurable/config/example/, se encuentran ejemplos similares para otros factores de forma.

En la siguiente figura, se muestra información más detallada sobre cómo se carga la información configurable del motor de políticas de audio en el servicio de políticas de audio. En este caso, el framework de parámetros carga la estructura y la configuración de los archivos XML.

Figura 2: Es la información del CAP que se carga en el servicio de política de audio.

Archivos de estructura de CAP en Android 15 y versiones anteriores

Para obtener la estructura y la configuración, el servicio de políticas de audio lee el archivo ParameterFrameworkConfigurationPolicy.xml. Esto hace referencia a la información de estructura a través de la ubicación del archivo de descripción de la estructura:

<StructureDescriptionFileLocation Path="Structure/Policy/PolicyClass.xml"/>

Esto apunta a la información de estructura en el archivo:

/vendor/etc/parameter-framework/Structure/Policy/PolicyClass.xml

Se proporciona una estructura esquelética en Android. La información de la estructura requiere la información de la estructura de la estrategia del producto, por lo que Android proporciona la buildStrategiesStructureFile.py herramienta de generación, que puede generar información a partir del archivo XML de la estrategia del producto disponible. Se puede hacer referencia a esto a través de la genrule predeterminada buildstrategiesstructurerule de la siguiente manera:

genrule {
    name: "buildstrategiesstructure_gen",
    defaults: ["buildstrategiesstructurerule"],
    srcs: [
        ":audio_policy_engine_configuration_files",
    ],
}

Aquí, audio_policy_engine_configuration_files son los archivos de configuración del motor de políticas de audio. En este ejemplo para el sector automotriz, se hace referencia a los archivos de configuración de políticas de audio en la carpeta automotive. En Otros ejemplos, se muestra cómo configurar una compilación para enviar los archivos a la partición del proveedor del dispositivo.

Archivos de configuración de CAP en Android 15 y versiones anteriores

Al igual que la estructura, la información de configuración, que representa las reglas y los valores de los parámetros, se hace referencia en el archivo ParameterFrameworkConfigurationPolicy.xml de la siguiente manera:

<SettingsConfiguration>
  <ConfigurableDomainsFileLocation Path="Settings/Policy/PolicyConfigurableDomains.xml"/>
</SettingsConfiguration>

Android también proporciona herramientas de compilación para generar esta información con la configuración del motor de políticas de audio y los archivos del framework de parámetros. Consulta Configuraciones para obtener más información.

Inicialización del CAP de la HAL de audio del AIDL

A partir de Android 16, la definición de la API de AIDL Audio HAL se expande con las configuraciones del motor de políticas de audio, AudioHalCapConfiguration.aidl. En la siguiente figura, se muestra una descripción general de alto nivel de la administración de la configuración del motor de CAP en Android 16:

Figura 3: Administración de la configuración del motor de CAP a partir de Android 16.

El servicio de política de audio obtiene la información del motor de CAP directamente con las APIs de AIDL Audio HAL en lugar de analizar la información de los archivos XML en la partición del proveedor del dispositivo.

En esta configuración, el motor de CAP sigue cargando la estructura del framework de parámetros del lado del servidor de audio.

Figura 4: Estructura del motor de CAP.

En todos los casos, la configuración debe especificar por completo la información relacionada con las estrategias de productos, los grupos de volumen y los criterios.

En la siguiente figura, se muestra una descripción general de alto nivel de las APIs de AIDL de HAL de audio que utiliza el servicio de política de audio para obtener la configuración del motor de CAP:

Figura 5: APIs del HAL de audio del AIDL

En esta configuración, el servicio de política de audio obtiene la siguiente información del HAL de audio de AIDL:

• Configuración
• Estrategias
• Volúmenes
• Criterios
• Configuración

Cargador predeterminado de HAL de audio de AIDL

Para facilitar la transición de HIDL a AIDL, la HAL de audio predeterminada de AIDL proporciona un cargador de motor de CAP en XML. Los proveedores pueden usar este cargador directamente extendiendo su HAL de audio con el HAL de audio predeterminado o haciendo referencia a la biblioteca libaudioserviceexampleimpl.

El cargador predeterminado de la HAL de audio de AIDL usa audio_policy_engine_configuration.xml para obtener la siguiente información:

• Configuración
• Estrategias
• Volúmenes
• Criterios

La información de la estructura se obtiene del archivo PolicyConfigurableDomains.xml. La diferencia clave con el mecanismo anterior es que la información de la estructura también la obtiene el HAL de audio de AIDL en lugar del framework de parámetros en el servicio de política de audio.

Los proveedores pueden usar la herramienta domaingeneratorpolicyrule para generar los dominios configurables con la información de la configuración del motor de políticas de audio. El ejemplo de dispositivo virtual Cuttlefish para automóviles se puede usar como referencia.

Estructura en la configuración de AIDL

En Android 16 y versiones posteriores, el servicio de política de audio obtiene la información de estructura leyendo y analizando el archivo ParameterFrameworkConfigurationCap.xml [file](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/av/services/audiopolicy/engineconfigurable/wrapper/ParameterManagerWrapper.cpp;l=71

). En particular, obtiene la información del archivo de descripción de la estructura:

<StructureDescriptionFileLocation Path="Structure/Policy/CapClass.xml"/>

El framework coloca los archivos requeridos en la carpeta /etc/parameter-framework/ con la información necesaria.

La estructura representa los parámetros que se deben controlar, por lo que se deben hacer referencia en la configuración o los dominios. Para ello, la configuración del motor de AIDL debe usar un nombre predeterminado para los parámetros. En el caso de las estrategias de productos, las estructuras se configuran en CapProductStrategies.xml.

Estrategias de productos predeterminadas

Comenzando con los valores predeterminados proporcionados en el motor predeterminado, las estrategias de productos comienzan con el prefijo STRATEGY_:

• STRATEGY_PHONE
• STRATEGY_SONIFICATION
• STRATEGY_ENFORCED_AUDIBLE
• STRATEGY_ACCESSIBILITY
• STRATEGY_SONIFICATION_RESPECTFUL
• STRATEGY_MEDIA
• STRATEGY_DTMF
• STRATEGY_CALL_ASSISTANT
• STRATEGY_TRANSMITTED_THROUGH_SPEAKER

Este formato se proporcionó para facilitar la transición de HIDL a AIDL en los dispositivos que usaban estrategias predeterminadas. Este cambio de formato tiene algunas implicaciones para los archivos existentes (por ejemplo, PfW, XML) que se usan para configurar el motor. En particular, todas las referencias a la estrategia del producto deben cambiarse para usar los nombres nuevos, por ejemplo:

Estrategias de productos definidas por el OEM

El motor configurable permite que los OEM cambien la definición de las estrategias de productos. Para seguir admitiendo esto, el archivo de estrategia de producto CapProductStrategies.xml también proporciona 40 estrategias de producto extensibles para proveedores, desde vx_1000 hasta vx_1039. Todas las extensiones del proveedor deben comenzar con el prefijo vx_ y continuar con un número que represente el ID de estrategia del producto en la definición de estrategia del producto de la HAL de audio de AIDL. El resto de las definiciones (por ejemplo, grupos de atributos de audio, nombre) se obtienen del objeto AudioHALProductStrategy en la configuración del motor de HAL de audio.

Al igual que con las estrategias de productos predeterminadas, las referencias de OEM definidas por el proveedor también se deben adaptar entre la configuración que no es de AIDL y la configuración de AIDL, por ejemplo:

Estrategias de productos

Las estrategias de productos proporcionan una forma de personalizar cómo se categorizan y agrupan los flujos de audio. Esto permite una mayor flexibilidad en la configuración de dispositivos de audio, incluida la forma en que se enrutan y se administran sus volúmenes. Cada estrategia de producto puede tener uno o más grupos de atributos de audio, que identifican los flujos que se deben asociar con esa estrategia de producto. Estos grupos de atributos de audio permiten un enfoque más detallado para categorizar el audio y pueden ser una combinación de los siguientes tipos:

• Los tipos de uso describen por qué se reproduce un sonido (es decir, medios, notificaciones, llamadas).
• Los tipos de contenido describen lo que se está reproduciendo (es decir, música, voz, video, sonificación).
• Los tipos de marcas definen diferentes comportamientos o solicitudes con respecto a la transmisión.
• Los tipos de etiquetas admiten cualquier lista arbitraria de valores de cadena del proveedor.
  • Cada cadena debe comenzar con VX_ seguido de una cadena alfanumérica (por ejemplo, VX_OEM, VX_NAVIGATION).

<ProductStrategy name="music" id="1008">
    <AttributesGroup streamType="AUDIO_STREAM_MUSIC" volumeGroup="media">
        <Attributes> <Usage value="AUDIO_USAGE_MEDIA"/> </Attributes>
        <Attributes> <Usage value="AUDIO_USAGE_GAME"/> </Attributes>
        <!-- Default product strategy has empty attributes -->
        <Attributes></Attributes>
    </AttributesGroup>
</ProductStrategy>

En este fragmento, se muestra un ejemplo de una estrategia de productos que se usa en emuladores de automóviles. Contiene dos atributos de audio con medios de uso de audio y juegos, respectivamente. Esta estrategia de producto coincide con el contexto de audio MUSIC que se usa en el servicio de audio para automóviles, pero no es necesario que coincidan. Una de las principales utilidades para los OEM que usan la CAP junto con Android es permitir definiciones de agrupamiento de audio más flexibles.

Grupos de volúmenes

Además, cada grupo de atributos de audio debe tener un grupo de volumen asociado. Este grupo de volumen está asociado a cualquier transmisión que coincida con los atributos de audio que pertenecen al grupo de atributos de audio. La estrategia de productos musicales de ejemplo que se incluye en la sección Estrategias de productos tiene el grupo de volumen media, y la definición del grupo de volumen de medios es la siguiente:

<volumeGroup>
    <name>media</name>
    <indexMin>0</indexMin>
    <indexMax>40</indexMax>
    <volume deviceCategory="DEVICE_CATEGORY_SPEAKER">
        <point>0,-2400</point>
        <point>33,-1600</point>
        <point>66,-800</point>
        <point>100,0</point>
    </volume>
</volumeGroup>

En esta definición, el grupo de volúmenes contiene lo siguiente:

• Nombre del grupo
• Índice mínimo del grupo
• Índice máximo del grupo
• Curvas de grupos de volúmenes

Las curvas del grupo de volumen contienen una asignación punto a punto entre el índice del grupo de volumen y la ganancia de volumen en milibelios. Los puntos proporcionados se usan para interpolar linealmente la mejor ganancia coincidente cuando se administra el volumen. Cada curva de grupo de volumen se asocia con una categoría de tipo de dispositivo (por ejemplo, auriculares, bocina o medios externos).

El grupo de volumen administra el volumen de las transmisiones que forman parte del grupo de atributos de audio. Por ejemplo, cuando se inicia una transmisión con atributos de audio que contienen música o juegos, se usa el último índice de volumen establecido para el grupo de volumen de medios. En este caso, se selecciona la curva de categoría de dispositivo correspondiente según el dispositivo seleccionado y se establece la ganancia correspondiente cuando se inicia la transmisión.

Configuraciones

En el motor de CAP, las configuraciones se usan para definir las condiciones o reglas que determinan cómo debe comportarse el audio. Estos parámetros de configuración se evalúan en el tiempo de ejecución para seleccionar las reglas adecuadas que se aplicarán según el estado actual del sistema de audio.

Como se muestra en la figura 5, la API contiene varios dominios, y el objetivo de cada uno es dividir la lógica en problemas de enrutamiento más pequeños para resolver (por ejemplo, dispositivo 1, dispositivo 2).

Cada dominio tiene configuraciones, y cada configuración tiene un conjunto de reglas. Las reglas se establecen según los criterios que proporciona AudioPolicyManager:

• Modo de audio
• Dispositivos de entrada y salida disponibles
• Direcciones de dispositivos de entrada y salida disponibles
• Uso para
  • Contenido multimedia
  • Comunicación
  • Grabando
  • Estación de carga
  • Sistema
  • Audio del sistema HDMI
  • Sonido envolvente codificado
  • Vibración al sonar

Cada dominio contiene configuraciones que dictan las reglas que deberían afectar el comportamiento. Ten en cuenta que el orden de configuración es importante y debes asegurarte de que las configuraciones estén en el orden requerido. Una vez que se validan las reglas de una configuración, se selecciona la configuración.

En el siguiente código, se muestra un ejemplo de fragmento de un archivo de framework de parámetros, que se puede usar para generar el archivo XML requerido para configurar dominios configurables:

supDomain: DeviceForProductStrategies
  supDomain: Music
    domain: SelectedDevice
      conf: BluetoothA2dp
        ForceUseForMedia IsNot NO_BT_A2DP
        ForceUseForCommunication IsNot BT_SCO
        AvailableOutputDevices Includes BLUETOOTH_A2DP
        component:/Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 1
          bus = 0
      conf: Bus
        AvailableOutputDevices Includes Bus
        AvailableOutputDevicesAddresses Includes BUS00_MEDIA
        component: /Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 0
          bus = 1
      conf: Default
        component: /Policy/policy/product_strategies/vx_1000/selected_output_devices/mask
          bluetooth_a2dp = 0
          bus = 0

El dominio DeviceForProductStrategies define cómo se deben aplicar las diferentes reglas cuando se controla la selección de dispositivos de las estrategias de productos. Las partes azules describen las reglas que se deben tener en cuenta, y la parte verde es la configuración aplicada. Este ejemplo en particular contiene las siguientes configuraciones:

• Selecciona el dispositivo Bluetooth A2DP para la estrategia de productos musicales (ID 1000, vx_1000).
  • Si se usa para contenido multimedia, no excluye A2DP
  • Si se usa para la comunicación, no es SCO de BT.
  • Si hay dispositivos disponibles, incluye BT A2DP
• Selecciona el dispositivo del bus.
  • Si los dispositivos de bus están disponibles
  • Si la dirección es BUS00_MEDIA
• Selecciona el dispositivo de salida predeterminado de lo contrario

Para generar el archivo XML del motor de políticas configurable correspondiente, ejecuta los archivos de parameter-framework (PFW) a través del sistema de compilación. Para ello, define una regla de compilación con los siguientes pasos:

1. En el archivo Android.bp, crea un grupo de archivos para el archivo:

   filegroup {
       name: ":device_for_product_strategies.pfw",
       srcs: ["engine/parameter-framework/Settings/device_for_product_strategyies.pfw"],
   }
   

2. Agrega el archivo a otros archivos de PfW (si hay alguno).

   filegroup {
       name: "edd_files",
       srcs: [
           ":device_for_input_source.pfw",
           ":volumes.pfw",
           ":device_for_product_strategyies.pfw",
       ],
   }
   

3. Crea la regla de generación de dominios correspondiente:

   genrule {
       name: "domaingeneratorpolicyrule_gen",
       defaults: ["domaingeneratorpolicyrule"],
       srcs: [
           ":audio_policy_engine_criterion_types",
           ":audio_policy_pfw_structure_files",
           ":audio_policy_pfw_toplevel",
           ":edd_files",
       ],
   }
   

   Aquí, domaingeneratorpolicyrule es una regla de generación que proporciona el framework para generar el archivo PolicyConfigurableDomains.xml. Los otros archivos fuente (scrs) incluidos en las reglas de generación de dominios son los siguientes:

   Fuente	Descripción
   audio_policy_pfw_toplevel	Es el archivo de configuración del framework de parámetros de nivel superior.
   audio_policy_pfw_structure_files	Archivos de estructura de generación de dominios, que se usan para generar los archivos de configuración.
   audio_policy_engine_criterion_types	Archivo XML de tipos de criterios que describe los criterios utilizados durante la generación.
   edd_files	Lista de archivos de un solo dominio (cada uno contiene una sola etiqueta <ConfigurableDomain>).

Después de ejecutar la regla de generación en la compilación, se genera el PolicyConfigurableDomains.xml con todos los dominios. A continuación, se muestra un fragmento del archivo generado con el ejemplo de reglas de PfW:

---ConfigurableDomain Name="DeviceForProductStrategies.Music.SelectedDevice"---
<Configurations>
  <Configuration Name="BluetoothA2dp">
    <CompoundRule Type="All">
      <SelectionCriterionRule SelectionCriterion="ForceUseForMedia" MatchesWhen="IsNot" Value="NO_BT_A2DP"/>
      <SelectionCriterionRule SelectionCriterion="ForceUseForCommunication" MatchesWhen="IsNot" Value="BT_SCO"/>
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevices" MatchesWhen="Includes" Value="BLUETOOTH_A2DP"/>
    </CompoundRule>
  </Configuration>
  <Configuration Name="Bus">
    <CompoundRule Type="All">
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevices" MatchesWhen="Includes" Value="BUS"/>
      <SelectionCriterionRule SelectionCriterion="AvailableOutputDevicesAddresses" MatchesWhen="Includes" Value="BUS00_MEDIA"/>
    </CompoundRule>
  </Configuration>
  <Configuration Name="Default">
    <CompoundRule Type="All"/>
  </Configuration>
</Configurations>

Depuración de CAP

Puedes usar remote-process para volcar los parámetros de configuración de CAP:

adb root && adb remount
adb shell remote-process unix:///dev/socket/audioserver/policy_debug dumpDomains

Aquí se muestran todos los dominios y las configuraciones, incluidas las condiciones de aplicabilidad. A continuación, se muestra un fragmento del dispositivo automotriz Cuttlefish con las configuraciones predeterminadas, de dispositivo de bus y de A2DP de Bluetooth. Consulta Configuraciones:

- ConfigurableDomain: DeviceForProductStrategies.Music.SelectedDevice =
 {Sequence aware: no, Last applied configuration: Bus}
  - Configuration: BluetoothA2dp
    - CompoundRule = All
      - SelectionCriterionRule = ForceUseForMedia IsNot NO_BT_A2DP
      - SelectionCriterionRule = ForceUseForCommunication IsNot BT_SCO
      - SelectionCriterionRule = AvailableOutputDevices Includes BLUETOOTH_A2DP
  - Configuration: Bus
    - CompoundRule = All
      - SelectionCriterionRule = AvailableOutputDevices Includes BUS
      - SelectionCriterionRule = AvailableOutputDevicesAddresses Includes BUS00_MEDIA_CARD_0_DEV_0
  - Configuration: Default
    - CompoundRule = All

Para obtener más información sobre otros comandos disponibles para depurar el framework de parámetros de CAP, usa esta herramienta:

adb shell remote-process unix:///dev/socket/audioserver/policy_debug help

Para usar la herramienta, los fabricantes de OEM deben permitir el ajuste en el dispositivo. Para verificar si el dispositivo permite el ajuste, usa el siguiente comando:

adb shell cat /system/etc/parameter-framework/ParameterFrameworkConfigurationCap.xml

En Android 15 y versiones anteriores, el archivo podría ser diferente, por lo que debes usar el siguiente comando:

adb shell cat /system/etc/parameter-framework/ParameterFrameworkConfigurationPolicy.xml

El archivo debe contener TuningAllowed="true" junto con el puerto del servidor correspondiente:

<?xml version="1.0" encoding="UTF-8"?>
<ParameterFrameworkConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    SystemClassName="Policy" TuningAllowed="true" ServerPort="unix:///dev/socket/audioserver/policy_debug">
    <SubsystemPlugins>
        <Location Folder="">
            <Plugin Name="libpolicy-subsystem.so"/>
        </Location>
    </SubsystemPlugins>
    <StructureDescriptionFileLocation Path="Structure/Policy/CapClass.xml"/>
</ParameterFrameworkConfiguration>

Este archivo se genera automáticamente según el tipo de imagen de compilación (o usa un archivo diferente para lanzamiento o depuración para la compilación heredada). Una compilación de lanzamiento establece TuningAllowed en false sin un puerto de socket (los sockets están prohibidos para esto en las compilaciones de lanzamiento). Las compilaciones de ingeniería y userdebug lo configuran en true con el puerto de socket utilizado. Ten en cuenta que este es el archivo al que hace referencia audio_policy_pfw_toplevel. La herramienta remote-process también se debe incluir en el archivo de compilación o make del dispositivo:

# Tool used for debug Parameter Framework (only for eng and userdebug builds)
PRODUCT_PACKAGES_DEBUG += remote-process

También se debe incluir la política de SELinux correspondiente para permitir los sockets. Esto solo funciona para el modo de depuración, ya que el modo de lanzamiento prohíbe explícitamente los sockets:

BOARD_SEPOLICY_DIRS += frameworks/av/services/audiopolicy/engineconfigurable/sepolicy

Migración de CAP en Android 16

Debido a los cambios importantes que trajo el motor de CAP de la HAL de audio de AIDL y las versiones anteriores, hay varias situaciones de transición de dispositivos que debes tener en cuenta. En esta sección, se describen los casos de transición más destacados y se brindan recomendaciones para el trabajo que se debe realizar para habilitar la configuración del motor de CAP.

Situación 1: Dispositivo nuevo con Android 16 o versiones posteriores, sin fuente anterior para la configuración de CAP del dispositivo

Los dispositivos nuevos deben lanzarse con código de Android 16 o una versión posterior en la partición vendor. Es decir, debe exponer la configuración del motor de políticas de audio configurable a través de la interfaz de HAL de audio de AIDL. La configuración del motor de CAP del dispositivo se debe copiar de los ejemplos. No debe haber ninguna definición de dominio de CAP de PfW en la partición vendor.

La imagen del sistema que se usa para el dispositivo es Android 16 o una versión posterior. El framework del servicio de audio descubre la configuración de CAP a través de la interfaz de HAL de audio de AIDL, por lo que inicializa PfW con la definición del dominio de CAP de PfW de la imagen del sistema y carga la configuración de CAP del dispositivo recibida a través de AIDL.

Por ejemplo, consulta el dispositivo virtual Cuttlefish para automóviles, que se introdujo en este cambio y al que se puede hacer referencia para los archivos, las reglas de compilación y los archivos make necesarios para configurar los archivos de configuración requeridos. Esto funciona con los cargadores proporcionados en la HAL de audio AIDL predeterminada.

Situación 2: Dispositivo nuevo con Android 16 o una versión posterior, desde un dispositivo anterior que usa CAP

Los dispositivos nuevos deben lanzarse con código de Android 16 o una versión posterior en la partición vendor. Sin embargo, como el OEM tiene una configuración del motor de CAP del dispositivo que se puede usar, querrá usarla como punto de partida (o reutilizarla por completo). La versión de AIDL de la configuración de CAP tiene algunos cambios en comparación con la versión de Android 15 y versiones anteriores, por lo que el proveedor debe convertir la configuración existente a AIDL. Consulta el debate en Estrategias de productos para conocer los cambios entre Android 16 y versiones anteriores, y los cambios necesarios. En general, el framework de audio descubre y carga la configuración de CAP de la misma manera que en el Escenario 1.

Situación 3: Dispositivo existente con CAP que actualiza a Android 16 solo la partición del sistema

En este caso, la partición vendor contiene la configuración de CAP del dispositivo de Android 15 y versiones anteriores, y la definición del dominio de CAP de PfW. La partición vendor no se modifica, por lo que sigue usando la HAL de HIDL. El framework sigue el escenario de Android 15 y versiones anteriores, y carga toda la configuración relacionada con CAP desde la partición vendor.

Situación 4: Dispositivo existente lanzado en Android 15, con CAP

La CAP no era compatible con AIDL en Android 15, por lo que algunos proveedores lanzaron dispositivos nuevos con la HAL de audio de AIDL y la CAP, que cargó el framework de audio. Este modo híbrido no era oficial, pero se incluye en Android 16. Ten en cuenta que este modo no se debe usar para lanzar dispositivos nuevos en Android 16, sino para permitir que los dispositivos existentes con el proveedor de Android 15 se actualicen a Android 16 (la actualización de la partición system).

El framework de audio descubre la configuración de audio de la HAL de audio de AIDL sin la configuración de CAP. Para la configuración de CAP, el servicio de política de audio (framework de audio) recurre a cargar la configuración de CAP desde la partición vendor. En este caso, tanto la definición del dominio de CAP de PfW como la configuración de CAP del dispositivo se deben cargar desde la partición vendor.

Resumen de la migración de CAP

En la siguiente tabla, se resumen los requisitos y la configuración del sistema y del proveedor compatibles con la configuración de la CAP: