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.
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.hales el punto de entrada a la API. -
IDevice.haleIPrimaryDevice.halcontienen métodos comosetMasterVolumeoopenInputStream. - Las transmisiones son unidireccionales y AudioFlinger las utiliza para enviar o recibir audio hacia y desde HAL a través de
IStream.hal,IStreamOut.haleIStreamIn.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:
- Tipos de enumeración
- Tipos de datos
- Etiquetas de proveedor
- Espacio de nombres de extensiones de proveedores
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:
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 :
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:
- El valor de enumeración de
AudioFormatse convierte en un valor de cadena enlibaudiohaly se pasa a HAL. - 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,AudioPortConfigAudioProfile := <format, {sampling rates}, {channel masks}>reemplaza colecciones sueltas en
AudioPort/PortConfigAudioPortExtendedInfo := device | mix | sessionreemplaza 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 |