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.
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
yIPrimaryDevice.hal
contienen métodos como los siguientes:setMasterVolume
oopenInputStream
.- Las transmisiones son unidireccionales, y AudioFlinger las utiliza para enviar o recibir
audio desde y hacia la HAL mediante
IStream.hal
,IStreamOut.hal
yIStreamIn.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:
- Tipos de enumeración
- Tipos de datos
- Etiquetas de proveedor
- Espacios de nombres de extensiones de proveedores
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:
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 proveedorAudioFormat
: Extensible por el proveedorAudioGainMode
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:
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:
- El valor enum de
AudioFormat
se convierte en un valor de cadena enlibaudiohal
y se pasa a la HAL. - 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
yAudioPortConfig
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 |