En audio de Android, audio_devices_t
se usa para representar el tipo de dispositivo de audio. Se usa ampliamente en el código fuente de audio como un campo de bits para filtrar o seleccionar uno o más dispositivos específicos. Antes de Android 11, había un límite de 30 tipos de dispositivos de entrada/salida de audio y no había ranuras libres para agregar nuevos tipos de dispositivos de audio. Hemos eliminado el límite en la cantidad de tipos de dispositivos de audio para permitir que se agreguen nuevos tipos de dispositivos de audio.
Para eliminar el límite en la cantidad de tipos de dispositivos de audio, los tipos de dispositivos de audio ahora son valores enumerados en lugar de máscaras de bits.
Todos los tipos de dispositivos de audio existentes se mantienen tal como están. AUDIO_DEVICE_BIT_IN
todavía se usa para distinguir dispositivos de entrada o salida. Al agregar nuevos tipos de dispositivos de audio, se enumeran valores en los espacios entre los valores existentes.
Los OEM no deberían usar audio_devices_t
como máscara de bits, porque eso puede causar resultados inesperados cuando se agregan nuevos tipos de dispositivos de audio enumerados.
Ejemplos y fuente
Antes de Android 11, había dos usos típicos de los tipos de dispositivos de audio como máscaras de bits.
- Usar el valor
audio_devices_t
para representar múltiples dispositivos de audio. - Comprobar si el valor
audio_devices_t
contiene tipos de dispositivos de audio de una categoría específica.
Para representar varios tipos de dispositivos de audio, se utiliza una clase denominada DeviceTypeSet
en /libaudiofoundation/include/media/AudioContainers.h
, que es un contenedor std::set
de audio_devices_t
. La clase se declara en la biblioteca libaudiofoundation
disponible por el proveedor. Para representar múltiples tipos de dispositivos de audio en código C, se puede usar una matriz o una lista de audio_devices_t
.
Para verificar si un solo tipo de dispositivo pertenece a una categoría específica, use las funciones auxiliares audio_is_.*_device
en /system/media/audio/include/system/audio.h
. Para el caso de varios tipos de dispositivos de audio, utilice las funciones auxiliares en libaudiofoundation
. Por ejemplo, utilice areAllOfSameDeviceType (DeviceTypeSet, std::function )
areAllOfSameDeviceType (DeviceTypeSet, std::function )
en AudioContainers.h
para comprobar si todos los tipos de dispositivos de audio indicados son del mismo tipo.
Implementación
Los OEM deben eliminar la representación del campo de bits del tipo de dispositivo de audio de la implementación de audio HAL.
- Elimine todo el almacenamiento de dispositivos en un campo de bits.
audio_devices_t
no debe usarse para representar múltiples tipos de dispositivos de audio. En su lugar, utilice una lista o un vector. - Deje de utilizar operaciones de bits para comparar tipos de dispositivos.
Antes de Android 11, los tipos de dispositivos de audio se podían usar como campo de bits. En ese caso, es común utilizar operaciones de bits para comparar tipos de dispositivos. Cuando se agregan nuevos tipos de dispositivos de audio enumerados, las operaciones de bits pueden provocar resultados inesperados. En su lugar, utilice funciones auxiliares como alternativa. Si hay un solo tipo de dispositivo de audio, utilice la comparación directa para comparar los dos valores. Para verificar si un tipo de dispositivo de audio pertenece a una categoría específica, use las funciones auxiliares en
/system/media/audio/include/system/audio.h
. Por ejemplo,audio_is_output_device(audio_devices_t device)
. - Deje de usar valores predefinidos para grupos de tipos de dispositivos de audio.
Hay algunos valores predefinidos para grupos de tipos de dispositivos de audio,
AUDIO_DEVICE_OUT_ALL
, ensystem/media/audio/include/system/audio-base-utils.h
. Todos estos valores están reservados, pero pueden quedar obsoletos ya que no serán correctos cuando se agreguen nuevos tipos de dispositivos de audio enumerados. Hay nuevos grupos de tipos de dispositivos de audio definidos enaudio-base-utils.h
, que son matrices de tipos de dispositivos de audio, comoAUDIO_DEVICE_OUT_ALL_ARRAY
. - Implemente los métodos
create_audio_patch()
yrelease_audio_patch()
para enrutamiento en lugar deset_parameters
.El método
set_parameters
utiliza tipos de dispositivos de audio como un campo de bits, por lo que puede haber resultados inesperados si se agregan nuevos tipos de dispositivos de audio enumerados.Actualmente, se requieren dos tipos de parches de audio:
- Mezclar parches en el dispositivo para reproducirlos
- Dispositivo para mezclar patches, para grabar.
En actualizaciones posteriores, es posible que se requieran parches adicionales de dispositivo a dispositivo.
Al crear un parche de audio, si no se especifica el identificador del parche, se requiere que el HAL de audio genere un identificador de parche único que pueda identificar el parche de audio. De lo contrario, el HAL de audio debería utilizar el controlador de parche de audio proporcionado para actualizar el parche de audio.
Si utiliza un HAL de audio heredado y el contenedor AOSP HIDL, el HAL de audio heredado debe configurar la versión principal de HAL en 3.0.
Para habilitar la función de parche de audio, el HAL de audio debe configurar la versión principal de HAL en 3.0 o superior. Consulte
Device::supportsAudioPatches()
en la implementación HIDL predeterminada para obtener más información, que también se puede encontrar en audio HAL para Cuttlefish.
Personalización
No es posible desactivar la función ni revertir la refactorización del dispositivo de audio en el marco que permite agregar tipos de dispositivos de audio.
Todos los tipos de dispositivos de audio agregados permiten representar un tipo de dispositivo con un solo bit configurado, por lo que las implementaciones HAL actuales aún funcionan.
Si se agregan nuevos tipos de dispositivos de audio y los OEM quieren usarlos, deben actualizar su implementación de audio HAL y pasar a HIDL versión 6.0 o superior. Es obligatorio actualizar la versión principal de HAL a 3.0 e implementar los métodos create_audio_patch
y release_audio_patch
, porque el uso set_parameters
para enrutar la transmisión puede causar resultados inesperados cuando se agregan nuevos tipos de dispositivos de audio.
Validación
El trabajo requerido para los OEM es actualizar sus implementaciones HAL. VTS para audio HAL se puede utilizar para validar si la implementación funciona según lo previsto. Todas las pruebas se pueden encontrar en los archivos VTS .