HAL de audio de HIDL

En Android 13 y versiones anteriores, la interfaz de la HAL de audio es definido con HIDL en los archivos HAL del HIDL (con extensión .hal) y Esquemas XSD 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

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

Como parte de la implementación de la HAL de HIDL de audio, debes crear una Archivo de configuración de política de audio que describe la topología de audio. Las capacidades de la HAL de audio deben declararse en el archivo audio_policy_configuration.xml para que el framework los use.

API de HAL de HIDL de audio

En esta sección, se describen las APIs principales, de efectos y de HAL comunes para HIDL.

HAL principal

Algunas de las interfaces clave de la HAL principal, que usan HIDL, son las siguientes:

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

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

Componente principal de HAL Ubicación
Versión más reciente de la API /hardware/interfaces/audio/6.0
Tipos específicos de la API de Core HAL 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

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

HAL de efectos

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

Componente de HAL de efectos 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 un ejemplo de implementación del API de HAL de efectos 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:

  • Definiciones (/hardware/interfaces/audio/common/6.0/types.hal) compartidas por las APIs de Core y Effect.
  • Servicios públicos (/hardware/interfaces/audio/common/all-versions) utilizados para ayudar a programar con APIs de HIDL para implementaciones, clientes y pruebas.

Actualizaciones de la HAL de audio V7

Hay cambios significativos en la versión 7 de la HAL de audio de 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 políticas de audio.

Específicamente, 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 la configuración de la política de audio se definen únicamente en el esquema XSD y no en el HIDL.

En la HAL de audio V6, los valores de los tipos de enumeración (como AudioFormat) en types.hal son los siguientes: definido en el esquema XSD del archivo de configuración de política de audio, lo que crea un la duplicación. Para evitar esto en la V7, los tipos de enumeración se cambian a string y En cambio, 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 de la versión 7:

cambio de formato de audio

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

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

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

Cómo pasar valores de enumeración de cadenas

Los valores de cadena se usan para transferir información como valores de enumeración el límite de la interfaz de la HAL. Tanto el framework como el El wrapper de HAL usa valores de enumeración de número entero para implementar la lógica empresarial enfoque de conversión que se muestra en la figura 3:

valores-de-pasar-de-audio

Figura 3: Pasar valores de enumeración de cadena.

A modo de ejemplo, para pasar un valor de tipo de formato de audio del framework al proveedor:

  1. El valor enum de AudioFormat se convierte en un valor de cadena en libaudiohal y se pasa a la HAL.
  2. Del lado de la HAL, el wrapper predeterminado convierte la cadena en una enumeración de salida, que se pasa a la HAL heredada.

Cambios en el esquema XML

Tener listas completas de valores enum en la definición del esquema XML (XSD) permite para una mejor validación del archivo XML de configuración de la política de audio por parte de VTS. Hicimos 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 utiliza un carácter (espacio) estándar para delimitar las listas de valores en (como tasas de muestreo, máscaras de canal y marcas), en lugar del , (coma) y | (barra vertical) utilizados en V6 y versiones anteriores. Como se ve en el siguiente, se usa un espacio para delimitar la lista de valores para channelMasks:

<profile channelMasks="AUDIO_CHANNEL_OUT_STEREO AUDIO_CHANNEL_OUT_MONO" … />

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

Por ejemplo, en V6 y versiones anteriores, un triple de <format, sampling rate, channel mask> se usa a menudo en las interfaces y tipos HIDL. Para quitar 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]>

    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 de AudioPort/PortConfig

Etiquetas de proveedor

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

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

Las etiquetas de proveedor para los metadatos de la pista de reproducción se agregan como se muestra a continuación ejemplo:

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

La estructura RecordTrackMetadata se implementa de manera similar cuando agregar 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 proveedores requieren un prefijo {vendor} adicional que no se requiere en V6. Para que el prefijo {vendor} sea válido, debe ser el siguiente: tres o más caracteres alfanuméricos.

Usa el siguiente formato en V7:

VX_{vendor}_{letters/numbers}

A continuación, se incluyen algunos ejemplos de extensiones de proveedores de V7 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:

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