Límite de tipos de dispositivos

En el 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 especificados. Antes de Android 11, había un límite de 30 tipos de dispositivos de entrada y salida de audio, y no había ranuras de repuesto para agregar nuevos tipos de dispositivos de audio. Quitamos el límite de cantidad de tipos de dispositivos de audio para que puedan agregarse nuevos.

Para quitar el límite de la cantidad de tipos de dispositivos de audio, ahora estos son valores enumerados en lugar de máscaras de bits.

Todos los tipos de dispositivos de audio existentes se conservan tal como están. AUDIO_DEVICE_BIT_IN se sigue usando para distinguir los dispositivos de entrada o salida. Cuando se agregan nuevos tipos de dispositivos de audio, se enumeran los valores en los espacios entre los valores existentes.

Los OEM no deben usar audio_devices_t como una máscara de bits, ya que esto 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.

• Se usa el valor audio_devices_t para representar varios dispositivos de audio.
• Comprobar si el valor de audio_devices_t contiene tipos de dispositivos de audio de una categoría especificada

Para representar varios tipos de dispositivos de audio, se usa una clase llamada 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 para el proveedor. Para representar varios tipos de dispositivos de audio en código C, se puede usar un array o una lista de audio_devices_t.

Para verificar si un solo tipo de dispositivo pertenece a una categoría especificada, usa las funciones de ayuda audio_is_.*_device en /system/media/audio/include/system/audio.h. En el caso de varios tipos de dispositivos de audio, usa funciones de ayuda en libaudiofoundation. Por ejemplo, usa areAllOfSameDeviceType (DeviceTypeSet, std::function) en AudioContainers.h para verificar si todos los tipos de dispositivos de audio proporcionados son del mismo tipo.

Implementación

Los OEM deben quitar la representación del campo de bits del tipo de dispositivo de audio de la implementación del HAL de audio.

1. Quita todo el almacenamiento de dispositivos en un campo de bits.

   audio_devices_t no se debe usar para representar varios tipos de dispositivos de audio. En su lugar, usa una lista o un vector.

2. Se dejó de usar operaciones de bits para las comparaciones de tipos de dispositivos.

   Antes de Android 11, los tipos de dispositivos de audio se podían usar como un campo de bits. En ese caso, es común usar operaciones bit a bit para las comparaciones de tipos de dispositivos. Cuando se agregan nuevos tipos de dispositivos de audio enumerados, las operaciones de bits pueden causar resultados inesperados. En su lugar, usa funciones auxiliares como alternativa. Si hay un solo tipo de dispositivo de audio, usa 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, usa las funciones de ayuda en /system/media/audio/include/system/audio.h. Por ejemplo, audio_is_output_device(audio_devices_t device).

3. Se dejó de usar valores predefinidos para grupos de tipos de dispositivos de audio.

   Hay algunos valores predefinidos para los grupos de tipos de dispositivos de audio, AUDIO_DEVICE_OUT_ALL, en system/media/audio/include/system/audio-base-utils.h. Todos estos valores están reservados, pero es posible que se dejen de usar, ya que no serán correctos cuando se agreguen nuevos tipos de dispositivos de audio enumerados. En audio-base-utils.h, se definen nuevos grupos de tipos de dispositivos de audio, que son arrays de tipos de dispositivos de audio, como AUDIO_DEVICE_OUT_ALL_ARRAY.

4. Implementa los métodos create_audio_patch() y release_audio_patch() para el enrutamiento en lugar de set_parameters.

   El método set_parameters usa 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:

   • Parches de mezcla para el dispositivo, para la reproducción
   • Dispositivo para mezclar parches, para grabar

   En actualizaciones posteriores, es posible que se requieran parches adicionales para cada dispositivo.

   Cuando se crea 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 debe usar el identificador de parche de audio proporcionado para actualizar el parche de audio.

   Si se usa una HAL de audio heredada y el wrapper de HIDL de AOSP, la HAL de audio heredada debe establecer la versión principal de la HAL en 3.0.

   Para habilitar la función de parche de audio, el HAL de audio debe establecer la versión principal del HAL en 3.0 o una versión posterior. Consulta Device::supportsAudioPatches() en la implementación predeterminada del HIDL para obtener más información, que también se puede encontrar en la HAL de audio para Cuttlefish.

Personalización

No es posible desactivar la función ni revertir la refactorización del dispositivo de audio en el framework 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 establecido, por lo que las implementaciones actuales del HAL siguen funcionando.

Si se agregan nuevos tipos de dispositivos de audio y los OEM quieren usarlos, deben actualizar su implementación de HAL de audio y migrar a la versión 6.0 de HIDL o a una posterior. Es obligatorio actualizar la versión principal de la HAL a 3.0 y, luego, implementar los métodos create_audio_patch y release_audio_patch, ya que usar set_parameters para enrutar la transmisión puede generar resultados inesperados cuando se agregan nuevos tipos de dispositivos de audio.

Validación

El trabajo requerido para los OEM es actualizar sus implementaciones de HAL. Se puede usar VTS para el HAL de audio para validar si la implementación funciona según lo previsto. Todas las pruebas se pueden encontrar en los archivos de VTS.