HAL de audio de HIDL

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

audio_hal

Figura 1: Interfaz de la HAL de audio

Archivos de configuración

Los archivos de configuración XML de la política de audio y los efectos de audio se consideran parte de la interfaz de la HAL de HIDL de audio. Estos archivos deben cumplir con sus esquemas, y las pruebas de VTS verifican el cumplimiento.

Como parte de la implementación de la HAL de HIDL de audio, debes crear un archivo de configuración de la política de audio que describa la topología de audio. Las capacidades de la HAL de audio se deben declarar en el archivo audio_policy_configuration.xml para que el framework las use.

API de la HAL de HIDL de audio

En esta sección, se describen las APIs de HAL Core, Effects y Common para HIDL.

HAL Core

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

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

En la siguiente tabla, se muestra la ubicación de los componentes HIDL útiles de HAL Core:

Componente de HAL Core Ubicación
Versión más reciente de la API /hardware/interfaces/audio/6.0
Tipos específicos de la API de HAL Core más reciente /hardware/interfaces/audio/6.0/types.hal
Esquema XSD del archivo de configuración de la política de audio /hardware/interfaces/audio/6.0/config/audio_policy_configuration.xsd

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

HAL Effects

En la siguiente tabla, se muestra la ubicación de los componentes útiles de HAL Effects con HIDL:

Componente de HAL Effects Ubicación
Versión más reciente de la 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, consulta una implementación de muestra de la API de HAL Effects en /hardware/interfaces/audio/effect/all-versions/default/ y la sección Efectos de audio.

HAL Common

La API de HAL Common con HIDL contiene lo siguiente:

  • Definiciones (/hardware/interfaces/audio/common/6.0/types.hal) compartidas por las APIs de Core y Effects
  • Utilidades (/hardware/interfaces/audio/common/all-versions) que se usan para ayudar a codificar en las APIs de HIDL para implementaciones, clientes y pruebas

Actualizaciones a la HAL de audio V7

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

  • Unifica los modelos de datos que usan el framework y la HAL.
  • Minimiza la duplicación entre los tipos de datos HIDL (enums) y el esquema XML que se usa para la configuración de la política de audio.

En particular, se realizan cambios en las siguientes áreas de la HAL de audio V7:

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

Enumeraciones

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

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

En la Figura 2, se comparan algunos de los cambios en el tipo de enum AudioFormat en la V7:

audioformat-change

Figura 2: Comparación de algunos de los cambios en la enum AudioFormat

Consulta la siguiente lista para ver los tipos de enum que se convirtieron en string:

  • AudioChannelMask
  • AudioContentType
  • AudioDevice: Extensible por el proveedor
  • AudioFormat: Extensible por el proveedor
  • AudioGainMode
  • AudioSource
  • AudioStreamType
  • AudioUsage

Pasa valores de enum de cadena

Los valores de cadena se usan para transferir información como valores de enumeración a través del límite de la interfaz de la HAL. Tanto el framework como el wrapper de la HAL usan valores de enum de números 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: Paso de valores de enum de cadena

Como ejemplo, para pasar un valor de tipo de formato de audio del framework al proveedor, haz lo siguiente:

  1. El valor de enum de AudioFormat se convierte en un valor de cadena en libaudiohal y se pasa a la HAL.
  2. En el lado de la HAL, el wrapper predeterminado convierte la cadena en un valor de enum, que se pasa a la HAL heredada.

Cambios en el esquema XML

Tener listas completas de valores de enum 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 que se usa con la HAL V7 para cumplir con XSD.

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

<profile channelMasks="AUDIO_CHANNEL_OUT_STEREO AUDIO_CHANNEL_OUT_MONO" … />

Para realizar los cambios de símbolos, usa una secuencia de comandos de conversión automática llamada update_audio_policy_config.sh. Consulta el siguiente comando para convertir un archivo de configuración de la política de audio de la 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 la V7 para minimizar las definiciones duplicadas. Las tuplas repetidas de elementos de datos se agrupan en estructuras reutilizables. Estas estructuras de datos usan las funciones más recientes de HIDL, como las uniones seguras.

Por ejemplo, en la V6 y versiones anteriores, se usa una tripleta de <format, sampling rate, channel mask> con frecuencia en las interfaces y los tipos de HIDL. Para quitar esta redundancia, en la 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]>

    usado por AudioConfig, AudioOffloadInfo, AudioPortConfig

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

    reemplaza las colecciones sueltas en AudioPort/PortConfig

  • AudioPortExtendedInfo := device | mix | session

    reemplaza las uniones en AudioPort/PortConfig

Etiquetas de proveedores

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

Para los metadatos de la pista de reproducción y grabación, los proveedores pueden pasar sus propias etiquetas, que se usan para agregar atributos a las transmisiones de E/S de audio, desde las apps a la HAL.

Las etiquetas de proveedores para los metadatos de la pista de reproducción se agregan como se muestra 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 las extensiones de proveedores

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

Usa el siguiente formato en la V7:

VX_{vendor}_{letters/numbers}

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

  • VX_GOOGLE_VR
  • VX_QCI_AMBIENT_MIC

Información de la versión

En la siguiente tabla, se muestra el número de versión de la HAL para cada versión de Android:

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