Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Límite de tipo de dispositivo

En el audio de Android, audio_devices_t se utiliza 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 de repuesto 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 el número 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 como están. AUDIO_DEVICE_BIT_IN todavía se utiliza para distinguir dispositivos de entrada o salida. Al agregar nuevos tipos de dispositivos de audio, se enumeran los valores en los espacios entre los valores existentes.

Fabricantes de equipos originales no debe utilizar audio_devices_t como una máscara de bits, ya que puede producir resultados inesperados cuando se añaden nuevos tipos de dispositivos de audio enumerados.

Ejemplos y fuente

Antes de Android 11, existían dos usos típicos de los tipos de dispositivos de audio como máscaras de bits.

  • Utilizando el audio_devices_t valor para representar múltiples dispositivos de audio.
  • Verificando la audio_devices_t valor contiene tipos de dispositivos de audio de una categoría.

Para representar múltiples tipos de dispositivos de audio, una clase llamada DeviceTypeSet en el /libaudiofoundation/include/media/AudioContainers.h se utiliza, que es un std::set de contenedores de audio_devices_t . La clase se declara en el proveedor disponible libaudiofoundation biblioteca. Para representar múltiples tipos de dispositivos de audio en código C, una matriz o una lista de audio_devices_t pueden ser utilizados.

Para comprobar si un solo tipo de dispositivo es de una categoría, funciones auxiliares uso audio_is_.*_device en /system/media/audio/include/system/audio.h . Para el caso de múltiples tipos de dispositivos de audio, utilice funciones de ayuda en libaudiofoundation . Por ejemplo, el uso areAllOfSameDeviceType (DeviceTypeSet, std::function ) areAllOfSameDeviceType (DeviceTypeSet, std::function ) En AudioContainers.h para comprobar si todos los tipos de dispositivos de audio dadas 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 HAL de audio.

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

    audio_devices_t no debe ser usado para representar múltiples tipos de dispositivos de audio. En su lugar, use una lista o un vector.

  2. Deje de usar operaciones de bits para las comparaciones de tipos de dispositivos.

    Antes de Android 11, los tipos de dispositivos de audio se pueden usar como un campo de bits. En ese caso, es común utilizar operaciones de bits para las comparaciones de tipos de dispositivos. Cuando se agregan nuevos tipos de dispositivos de audio enumerados, las operaciones de bits pueden producir 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 comprobar si un tipo de dispositivo de audio es de una categoría, funciones de ayuda en el uso /system/media/audio/include/system/audio.h . Por ejemplo, audio_is_output_device(audio_devices_t device) .

  3. 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 , en system/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 definido en audio-base-utils.h , que son matrices de los tipos de dispositivos de audio, como AUDIO_DEVICE_OUT_ALL_ARRAY .

  4. Implementar la create_audio_patch() y release_audio_patch() métodos para el encaminamiento en lugar de set_parameters .

    El set_parameters método utiliza los tipos de dispositivos de audio como un campo de bits, por lo que no puede haber resultados inesperados si se añaden nuevos tipos de dispositivos de audio enumerados.

    Actualmente, se requieren dos tipos de parches de audio:

    • Mezclar a los patches del dispositivo, para la reproducción
    • 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 de parche, se requiere la HAL de audio para generar un identificador de parche único que pueda identificar el parche de audio. De lo contrario, la HAL de audio debería usar el identificador de parche de audio dado para actualizar el parche de audio.

    Si utiliza un HAL de audio heredado y el contenedor AOSP HIDL, el HAL de audio heredado debe establecer la versión principal de HAL en 3.0.

    Para habilitar la función de parche de audio, la HAL de audio debe establecer la versión principal de HAL en 3.0 o superior. Consulte el Device::supportsAudioPatches() en aplicación HIDL por defecto para obtener más información, que también se pueden encontrar en HAL audio para la jibia.

Personalización

No es posible desactivar la función o 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 conjunto de bits único, por lo que las implementaciones actuales de HAL aún funcionan.

Si se agregan nuevos tipos de dispositivos de audio y los OEM quieren usarlos, deben actualizar su implementación de HAL de audio y pasar a la versión 6.0 o superior de HIDL. Es obligatorio actualizar la versión principal HAL a 3,0 y poner en práctica las create_audio_patch y release_audio_patch métodos, porque el uso de set_parameters para encaminar la corriente puede producir resultados inesperados cuando se añaden nuevos tipos de dispositivos de audio.

Validación

El trabajo requerido para los OEM es actualizar sus implementaciones de 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 .