HAL de audio HIDL

En Android 13 y versiones anteriores, la interfaz Audio HAL se define usando HIDL en archivos HIDL HAL (con la extensión .hal ) y esquemas XSD para los archivos de configuración, como se muestra a continuación.

audio_hal

Figura 1. Interfaz de audio HAL.

Archivos de configuración

Los archivos de configuración XML de políticas de audio y efectos de audio se consideran parte de la interfaz Audio HIDL HAL. Estos archivos deben ajustarse a sus esquemas y la conformidad se verifica mediante pruebas VTS.

Como parte de la implementación de audio HIDL HAL, debe crear un archivo de configuración de política de audio que describa la topología de audio. Las capacidades de audio HAL deben declararse en el archivo audio_policy_configuration.xml para que el marco las utilice.

API de audio HIDL HAL

Esta sección describe las API HAL principales, de efectos y comunes para HIDL.

Núcleo HAL

Algunas de las interfaces clave de Core HAL, que utilizan HIDL, son las siguientes:

  • IDeviceFactory.hal es el punto de entrada a la API.
  • IDevice.hal e IPrimaryDevice.hal contienen métodos como setMasterVolume o openInputStream .
  • Las transmisiones son unidireccionales y AudioFlinger las utiliza para enviar o recibir audio hacia y desde HAL a través de IStream.hal , IStreamOut.hal e IStreamIn.hal .

La siguiente tabla enumera la ubicación de componentes útiles de Core HAL HIDL:

Componente principal de HAL Ubicación
Última versión de API /hardware/interfaces/audio/6.0
Tipos específicos de la última API Core HAL /hardware/interfaces/audio/6.0/types.hal
Esquema XSD del archivo de configuración de política de audio /hardware/interfaces/audio/6.0/config/audio_policy_configuration.xsd

La implementación predeterminada de la API Core HAL ( /hardware/interfaces/audio/core/all-versions/default/ ) es una envoltura de la implementación HAL anterior a Treble utilizando bibliotecas compartidas heredadas . La implementación predeterminada también se puede considerar como referencia al implementar nuevas versiones de Audio HAL que interactúan directamente con los controladores del kernel.

Efectos HAL

La siguiente tabla enumera la ubicación de componentes útiles de efectos HAL que utilizan HIDL:

Componente HAL de efectos Ubicación
Última versión de API /hardware/interfaces/audio/effect/6.0/
Esquema XSD del archivo de configuración de efectos /hardware/interfaces/audio/effect/6.0/xml/audio_effects_conf.xsd

Para obtener más información, consulte una implementación de muestra de la API HAL de efectos en /hardware/interfaces/audio/effect/all-versions/default/ y la sección Efectos de audio .

HAL común

La API HAL común que utiliza HIDL contiene lo siguiente:

  • Definiciones ( /hardware/interfaces/audio/common/6.0/types.hal ) compartidas por las API Core y Effect.
  • Utilidades ( /hardware/interfaces/audio/common/all-versions ) utilizadas para ayudar a codificar las API HIDL para implementaciones, clientes y pruebas.

Actualizaciones del Audio HAL V7

Hay cambios importantes en la versión 7 de Audio HAL en Android 12, como se describe en esta sección. El Audio HAL V7 hace lo siguiente:

  • Unifica los modelos de datos utilizados por el framework y HAL.
  • Minimiza la duplicación entre los tipos de datos HIDL (enumeraciones) y el esquema XML utilizado para la configuración de la política de audio.

Específicamente, se realizan cambios en las siguientes áreas en Audio HAL V7:

Estos cambios se analizan con más detalle en sus respectivas secciones.

Enumeraciones

A partir de Audio HAL V7, los tipos enumerados utilizados en el archivo de configuración de política de audio se definen solo en el esquema XSD y no en HIDL.

En Audio HAL V6, los valores de los tipos de enumeración (como AudioFormat ) en types.hal también se definen en el esquema XSD del archivo de configuración de política de audio, lo que crea una duplicación. Para evitar esto en V7, los tipos de enumeración se cambian a string y, en su lugar, todos los valores de enumeración posibles se enumeran en el esquema XSD.

La Figura 2 compara algunos de los cambios en el tipo de enumeración AudioFormat en V7:

audioformat-change

Figura 2. Comparación de algunos de los cambios en la enumeración AudioFormat.

Consulte la siguiente lista para conocer los tipos de enumeración que se han convertido en string :

  • AudioChannelMask
  • AudioContentType
  • AudioDevice : Proveedor extensible
  • AudioFormat : Proveedor extensible
  • AudioGainMode
  • AudioSource
  • AudioStreamType
  • AudioUsage

Pasar valores de enumeración de cadena

Los valores de cadena se utilizan para transferir información como valores de enumeración a través del límite de la interfaz HAL. Tanto el marco como el contenedor HAL utilizan valores de enumeración enteros para implementar la lógica empresarial y emplean el enfoque de conversión que se muestra en la Figura 3 :

audio-passing-values

Figura 3. Pasar valores de enumeración de cadenas.

Como ejemplo, para pasar un valor de tipo de formato de audio desde el marco al proveedor:

  1. El valor de enumeración de AudioFormat se convierte en un valor de cadena en libaudiohal y se pasa a HAL.
  2. En el lado de HAL, el contenedor predeterminado convierte la cadena en un valor de enumeración, que se pasa al HAL heredado.

Cambios en el esquema XML

Tener listas completas de valores de enumeración en la definición del esquema XML (XSD) permite una mejor validación del archivo XML de configuración de la política de audio por parte de VTS. Realizamos cambios en el archivo de configuración de la política de audio utilizado con HAL V7 para cumplir con XSD.

En V7, se utiliza un carácter ␣ (espacio) estándar para delimitar listas de valores en atributos (como frecuencias de muestreo, máscaras de canal y banderas), en lugar de , (coma) y | (barra vertical) símbolos utilizados en V6 y versiones anteriores. Como se ve en el siguiente ejemplo, se utiliza un espacio para delimitar la lista de valores de channelMasks :

<profile channelMasks="AUDIO_CHANNEL_OUT_STEREO AUDIO_CHANNEL_OUT_MONO" … />

Para realizar cambios en los símbolos, utilice un script de conversión automática llamado update_audio_policy_config.sh . Consulte el siguiente comando para convertir un archivo de configuración de política de audio V6 a una versión V7 para el dispositivo Pixel 5 (Redfin):

hardware/interfaces/audio/7.0/config/update_audio_policy_config.sh \
device/google/redfin/audio/audio_policy_configuration.xml 6.0

Tipos de datos

Redefinimos algunas estructuras de datos en V7 para minimizar definiciones duplicadas. Las tuplas repetidas de elementos de datos se agrupan en estructuras reutilizables. Estas estructuras de datos utilizan las últimas funciones HIDL, como uniones seguras.

Por ejemplo, en V6 y versiones anteriores, se utiliza a menudo una tripleta de <format, sampling rate, channel mask> en las interfaces y tipos HIDL. Para eliminar esta redundancia, en V7, el tipo de datos AudioConfigBase y otros tipos de datos se definen de la siguiente manera:

  • AudioConfigBase := <format, sampling rate, channel mask>

  • AudioConfigBaseOptional := <[fmt], [sampl. rate], [chan. mask]>

    utilizado por AudioConfig , AudioOffloadInfo , AudioPortConfig

  • AudioProfile := <format, {sampling rates}, {channel masks}>

    reemplaza colecciones sueltas en AudioPort/PortConfig

  • AudioPortExtendedInfo := device | mix | session

    reemplaza las uniones en AudioPort/PortConfig

Etiquetas de proveedor

Además de los tipos y formatos de dispositivos, los proveedores pueden agregar etiquetas personalizadas para los metadatos de las pistas de audio.

Para reproducir y grabar metadatos de pistas, los proveedores pueden pasar sus propias etiquetas, que se utilizan para agregar atributos a las transmisiones de E/S de audio, desde las aplicaciones al HAL.

Las etiquetas de proveedor para los metadatos de la pista de reproducción se agregan como se ve en el siguiente ejemplo:

struct PlaybackTrackMetadata {
…
    /** Tags from AudioTrack audio attributes */
    vec<AudioTag> tags;
};

La estructura RecordTrackMetadata se implementa de manera similar agregando etiquetas específicas para los metadatos de la pista de grabación.

Espacio de nombres de extensiones de proveedores

A partir de HAL V7, las extensiones de proveedor requieren un prefijo {vendor} adicional que no es necesario en V6. Para que el prefijo {vendor} sea válido, debe tener tres o más caracteres alfanuméricos.

Utilice el siguiente formato en V7:

VX_{ vendor }_{ letters/numbers }

Los siguientes son algunos ejemplos de extensiones válidas de proveedores V7:

  • VX_ GOOGLE _VR
  • VX_ QCI _AMBIENT_MIC

Información de versión

La siguiente tabla enumera el número de versión de HAL para cada versión de Android:

versión de Android Versión HIDL-HAL
androide 13 7.1
androide 12 7.0
androide 11 6.0
androide 10 5.0
androide 9 4.0
androide 8 2.0