Motor de políticas de audio configurable

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

• Usa la marca useCoreAudioVolume para habilitar la administración de volúmenes de CAP. Cuando este valor es true, el servicio de audio para vehículos usa las APIs de AudioManager para administrar los grupos de volumen.

• Usa la marca useCoreAudioRouting para habilitar la administración de enrutamiento de audio de CAP. Cuando este valor es true, el servicio de audio para vehículos 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 complementos y reglas para controlar parámetros. En el caso de la administración de audio de Android en particular, el motor de CAP introdujo la posibilidad de definir reglas de archivos en formato 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 silenciar junto con las tablas de volumen

Inicialización de CAP antes de Android 16

En la siguiente figura, se muestra una descripción general de alto nivel de la administración de configuración del motor de políticas de audio configurable a partir de 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ítica de audio obtiene la configuración del motor de CAP a través del análisis de 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. Hay ejemplos similares para otros factores de forma en la carpeta frameworks/av/services/audiopolicy/engineconfigurable/config/example/.

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 en formato XML.

Figura 2: Información de CAP cargada dentro del servicio de políticas 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ítica de audio lee el archivo ParameterFrameworkConfigurationPolicy.xml. Esto hace referencia a la información de la 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 de esqueleto en Android. La información de la estructura requiere la información de la estructura de la estrategia de productos, por lo que Android proporciona la herramienta de generación buildStrategiesStructureFile.py, que puede generar información a partir del archivo en formato XML de la estrategia de productos disponible. Se puede hacer referencia a esto a través de genrule default buildstrategiesstructurerule de la siguiente manera:

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

En el que audio_policy_engine_configuration_files es el motor de archivos de configuración de la política de audio. En este ejemplo para la industria automotriz, se hace referencia a los archivos de configuración de la política de audio en la carpeta automotriz. 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 con 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 Parámetros de configuración para obtener más información.

Inicialización de CAP de HAL de audio 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 imagen, se muestra una descripción general de alto nivel de la administración de la configuración del motor de CAP a partir de 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 HAL de audio de AIDL, en lugar de analizar la información de los archivos en formato XML de la partición del proveedor del dispositivo.

En esta configuración, el motor de CAP carga la estructura del framework de parámetros en el 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 HAL de audio AIDL que usa el servicio de política de audio para obtener la configuración del motor de CAP:

Figura 5: APIs de HAL de audio de AIDL

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

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

Cargador predeterminado de HAL de audio AIDL

Para suavizar la transición de HIDL a AIDL, la HAL de audio AIDL predeterminada proporciona un cargador de motor de CAP 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 de HAL de audio AIDL predeterminado 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 el HAL de audio de AIDL también obtiene la información de la estructura 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. Puedes usar como referencia el ejemplo de dispositivo virtual de Cuttlefish para la industria automotriz.

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 la estructura leyendo y analizando el archivo ParameterFrameworkConfigurationCap.xml. 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 necesarios 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 debe hacer referencia a ellos en la configuración o los dominios. Para ello, la configuración del motor AIDL debe usar un nombre predeterminado para los parámetros. En el caso de las estrategias de producto, las estructuras se configuran en CapProductStrategies.xml.

Estrategias de productos predeterminadas

A partir de 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 dispositivos que usaban estrategias predeterminadas. Este cambio de formato tiene algunas implicaciones para los archivos existentes (por ejemplo, PfW y XML) que se usan para configurar el motor. En particular, todas las referencias a la estrategia de productos 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 producto. Para seguir admitiendo esto, el archivo de estrategia de producto CapProductStrategies.xml también proporciona 40 estrategias de productos extensibles para proveedores, desde vx_1000 hasta vx_1039. Todas las extensiones de proveedores deben comenzar con el prefijo vx_ y continuar con un número que represente el ID de estrategia de producto en la definición de estrategia de producto de HAL de audio 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 deben adaptarse entre la configuración no AIDL y la configuración AIDL, por ejemplo:

Estrategias de productos

Las estrategias de productos proporcionan una forma de personalizar la forma en que se categorizan y agrupan las transmisiones de audio. Esto permite una mayor flexibilidad en la configuración de los 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 las transmisiones 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, contenido multimedia, notificación o llamada).
• Los tipos de contenido describen lo que se reproduce (es decir, música, voz, video o sonificación).
• Los tipos de marca definen diferentes comportamientos o solicitudes con respecto al flujo.
• Los tipos de etiquetas admiten cualquier lista arbitraria de valores de cadenas de proveedores.
  • Cada cadena debe comenzar con VX_ seguida 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 extracto, se muestra un ejemplo de una estrategia de producto que se usa en emuladores de automóviles. Contiene dos atributos de audio con medios de uso de audio y juego, respectivamente. Esta estrategia de productos coincide con el contexto de audio MUSIC que se usa en el servicio de audio para automóviles, pero no es necesario que coincida. Una de las principales utilidades para los OEMs que usan el CAP junto con Android es permitir definiciones de agrupación 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 se asocia con 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 en la sección Estrategias de productos tiene el grupo de volumen media, y la definición del grupo de volumen multimedia 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 del grupo de volúmenes

Las curvas de grupo de volumen contienen una asignación puntual entre el índice de grupo de volumen y la ganancia de volumen en milibelios. Los puntos proporcionados se usan para interpolar de forma lineal la mejor ganancia de coincidencia cuando se administra el volumen. Cada curva del grupo de volumen está asociada con una categoría de tipo de dispositivo (por ejemplo, auriculares, bocinas o contenido multimedia externo).

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 un juego, se usa el último índice de volumen establecido para el grupo de volumen multimedia. 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, se usan configuraciones para definir las condiciones o reglas que determinan cómo debe comportarse el audio. Estas configuraciones 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, cuyo objetivo es dividir la lógica en problemas de enrutamiento más pequeños para resolverlos (por ejemplo, dispositivo 1, dispositivo 2).

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

• Modo de audio
• Dispositivos de entrada y salida disponibles
• Direcciones de dispositivos de entrada y salida disponibles
• Usos
  • 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 que debes asegurarte de que las configuraciones estén en el orden requerido. Después de validar las reglas de una configuración, se selecciona la configuración.

En el siguiente código, se muestra un ejemplo de extracto 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 BT SCO
  • Si hay dispositivos disponibles, incluye BT A2DP
• Seleccionar dispositivo de bus
  • Si los dispositivos de bus están disponibles
  • Si la dirección es BUS00_MEDIA
• Selecciona el dispositivo de salida predeterminado de otra manera

Para generar el archivo XML del motor de políticas configurable correspondiente, ejecuta los archivos del framework de parámetros (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 los hay).

   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",
       ],
   }
   

   En el que 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 de 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	Es un archivo en formato XML de tipos de criterios que describe los criterios utilizados durante la generación.
   edd_files	Es una lista de archivos de dominio único (cada uno contiene una sola etiqueta <ConfigurableDomain>).

Después de ejecutar la regla de generación en la compilación, se genera PolicyConfigurableDomains.xml con todos los dominios. A continuación, se muestra un extracto 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 las configuraciones de CAP:

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

Se muestran todos los dominios y parámetros de configuración, incluidas las condiciones de aplicabilidad. A continuación, se muestra un extracto del dispositivo automotriz Cuttlefish que usa el A2DP de Bluetooth, el dispositivo de bus y las configuraciones predeterminadas. Consulta Parámetros de configuración:

- 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 la sintonización en el dispositivo. Para verificar si el dispositivo permite la sintonización, usa el siguiente comando:

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

En Android 15 y versiones anteriores, el archivo puede ser diferente, así que usa 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 se 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 establecen en true con el puerto de zócalo utilizado. Ten en cuenta que este es el archivo al que hace referencia audio_policy_pfw_toplevel. La herramienta de proceso remoto también se debe incluir en el archivo make o de compilación 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 no permite de forma explícita los sockets:

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

Migración de CAP en Android 16

Debido a los cambios importantes que introdujo el motor de CAP de HAL de audio de AIDL y las versiones anteriores, existen varias situaciones de transición de dispositivos que debes tener en cuenta. En esta sección, se describen las situaciones de transición más importantes y se proporcionan recomendaciones para el trabajo que permite la configuración del motor de CAP.

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

Un dispositivo nuevo debe iniciarse con el código de Android 16 o versiones posteriores en la partición vendor. Esto significa que debe exponer la configuración del motor de políticas de audio configurable a través de la interfaz de HAL de audio 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 versiones posteriores. El framework de servicios de audio descubre la configuración de CAP a través de la interfaz de HAL de audio AIDL, por lo que inicializa PfW con la definición de dominio de CAP de PfW de la imagen del sistema y carga la configuración de CAP del dispositivo que se recibe a través de AIDL.

Para ver un ejemplo, consulta el dispositivo virtual Cuttlefish para la industria automotriz, que se introdujo en este cambio y al que se puede hacer referencia para obtener los archivos, las reglas de compilación y los archivos de make necesarios para configurar los archivos de configuración requeridos. Esto funciona con los cargadores proporcionados en el HAL de audio AIDL predeterminado.

Situación 2: Dispositivo nuevo con Android 16 o versiones posteriores, desde un dispositivo anterior que usa CAP

Un dispositivo nuevo debe iniciarse con el código de Android 16 o versiones posteriores 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 Android 15 y versiones anteriores, por lo que el proveedor debe convertir la configuración existente a AIDL. Consulta el análisis en Estrategias de productos para conocer los cambios entre Android 16 y versiones anteriores. En general, el framework de audio descubre y carga la configuración de CAP de la misma manera que en la situación 1.

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

En esta situación, la partición vendor contiene la versión de Android 15 y versiones anteriores de la configuración de CAP del dispositivo, y la definición del dominio de CAP de PfW. La partición vendor no se toca, por lo que todavía usa la HAL de HIDL. El framework sigue el caso de Android 15 y versiones anteriores, y carga toda la configuración relacionada con el CAP desde la partición vendor.

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

CAP no era compatible con AIDL en Android 15, por lo que algunos proveedores lanzaron dispositivos nuevos con HAL de audio de AIDL y 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 la carga de 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 deben cargarse desde la partición vendor.

Resumen de la migración de CAP

En la siguiente tabla, se resumen los requisitos y las configuraciones de sistemas y proveedores compatibles para la configuración de CAP: