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 la HAL de HIDL (con la extensión .hal) y esquemas XSD para los archivos de configuración, como se muestra a continuación.

Figura 1: Es la 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 del HAL de HIDL de audio, debes crear un archivo de configuración de políticas 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 HAL de HIDL de audio

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

HAL principal

Estas son algunas de las interfaces clave del HAL principal, que usan HIDL:

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

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

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

HAL de efectos

En la siguiente tabla, se indica la ubicación de los componentes HAL de Effects útiles que usan HIDL:

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

HAL común

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

• Son las definiciones (/hardware/interfaces/audio/common/6.0/types.hal) que comparten las APIs de Core y Effect.
• Utilidades (/hardware/interfaces/audio/common/all-versions) que se usan para ayudar a la codificación en las APIs de HIDL para implementaciones, clientes y pruebas.

Actualizaciones a la HAL de audio V7

En esta sección, se describen los cambios significativos que se realizaron en la versión 7 de la HAL de audio en Android 12. 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 de HIDL (enumeraciones) y el esquema XML que se usa para la configuración de la política de audio.

Específicamente, se realizaron cambios en las siguientes áreas de la HAL de audio V7:

• Tipos de enumeración
• Tipos de datos
• Etiquetas de proveedores
• Espacio de nombres de las extensiones de proveedores

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

Enumeraciones

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

En la HAL de audio 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 la política de audio, lo que genera una duplicación. Para evitar esto en la versión 7, los tipos de enumeración se cambiaron 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 enumeración AudioFormat en la versión 7:

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

Consulta la siguiente lista para ver los tipos de enumeración que se convirtieron a string:

• AudioChannelMask
• AudioContentType
• AudioDevice: Extensible para proveedores
• AudioFormat: Extensible para proveedores
• AudioGainMode
• AudioSource
• AudioStreamType
• AudioUsage

Pasa valores de enumeración de cadenas

Los valores de cadena se usan para transferir información como valores de enumeración a través del límite de la interfaz HAL. Tanto el framework como el wrapper de HAL usan valores de enumeración de números enteros para implementar la lógica de negocios y emplean el enfoque de conversión que se muestra en la figura 3:

Figura 3: Se pasan valores de enumeración de cadenas.

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

1. El valor de enumeración de AudioFormat se convierte en un valor de cadena en libaudiohal y se pasa a la HAL.
2. En el lado del HAL, el wrapper 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 que VTS realice una mejor validación del archivo de configuración de la política de audio en formato XML. Realizamos cambios en el archivo de configuración de la política de audio que se usa con HAL V7 para cumplir con XSD.

En la versión 7, 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 canales y las marcas), en lugar de los símbolos , (coma) y | (barra vertical) que se usaban en la versión 6 y 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 política de audio de la versión 6 a una versión 7 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 versión 7 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 versión 6 y anteriores, se usa a menudo una tripleta de <format, sampling rate, channel mask> en las interfaces y los tipos de HIDL. Para quitar esta redundancia, en la versión 7, 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 y 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 pistas de audio.

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

Se agregan etiquetas de proveedores para los metadatos de pistas de reproducción, 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 versión 7 de HAL, las extensiones del proveedor requieren un prefijo {vendor} adicional que no se necesita en la versión 6. Para que el prefijo {vendor} sea válido, debe tener tres o más caracteres alfanuméricos.

Usa el siguiente formato en la versión 7:

VX_{vendor}_{letters/numbers}

A continuación, se muestran algunos ejemplos de extensiones de proveedores de la versión 7 válidas:

• VX_GOOGLE_VR
• VX_QCI_AMBIENT_MIC

Información de la versión

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