En esta página, se describe cómo habilitar el framework de audio y la HAL de audio (AHAL) para administrar las conexiones síncronas orientadas a la conexión (SCO), un proceso identificado como Audio Managed SCO (AMSCO).
En Android 17 y versiones posteriores, el framework de audio de Android usa la función de administración de SCO para administrar el enrutamiento de SCO, que originalmente controlaba el framework de Bluetooth (BT). Esta migración traslada el estado de conexión SCO de un estado propiedad del framework de BT a una consecuencia descendente de la actividad de transmisión de audio.
Al centralizar la propiedad del enrutamiento de audio dentro del framework de audio, esta función alinea la implementación de la capa de abstracción de hardware (HAL) de audio para SCO con otros perfiles de BT, como el perfil de distribución de audio avanzado (A2DP) y el audio LE. Esta refactorización simplifica la interacción entre las pilas de telecomunicaciones y BT, lo que permite una arquitectura de enrutamiento de audio más sólida y centralizada.
Descripción general de la arquitectura
La arquitectura de AMSCO centraliza la administración de la conexión de SCO dentro del framework de audio de Android, que basa las decisiones de enrutamiento en la actividad de transmisión de audio. Esta arquitectura contrasta con el modelo anterior, en el que la pila de BT administraba las conexiones. Los roles de cada componente en esta arquitectura son los siguientes:
El AHAL inicia y suspende la sesión SCO solo si se cumplen las siguientes condiciones:
- Se aplica un parche a una transmisión activa en un dispositivo SCO.
- Se configuró el modo audio y existe un parche para un dispositivo SCO.
El framework de audio impide que un dispositivo A2DP tenga un parche simultáneo cuando se cumplen estos criterios específicos. El framework de audio ya no envía cambios de estado de SCO ni suspensiones de A2DP al AHAL.
El framework de audio controla la administración de SCO, por lo que la pila de BT ya no llama a conectar o desconectar audio. En casos de desconexión o error preventivo de SCO, la pila de BT informa al framework de audio con AudioManager#onHfpAudioDisconnected.
Plan
Usa la información de esta sección para evaluar los siguientes requisitos de compatibilidad y arquitectura antes de implementar la refactorización de la administración de SCO.
Retrocompatibilidad
Para permitir que el framework siga admitiendo dispositivos que podrían recibir actualizaciones del SO sin actualizar sus AHAL o AHAL de BT, usa una propiedad del sistema para indicar que se debe habilitar la nueva administración de SCO. La ruta de acceso heredada se conserva hasta por seis años en los casos en que la propiedad del sistema está inhabilitada o la versión del HAL está desactualizada.
Configura la sesión de HFP
El AHAL debe usar el nuevo tipo de sesión de perfil de manos libres (HFP) para iniciar o suspender la reproducción, de manera similar a otros tipos de sesiones de BT. En última instancia, el estado de la transmisión se administra con diferentes IBluetoothAudioProviders, que se enumeran y compilan con una clase Factory según las rutas disponibles.
La pila de BT usa una ruta de descarga de hardware siempre que es posible. La preferencia por los códecs durante la negociación sigue este orden: se prefiere el hardware LC3 sobre el software LC3, seguido del hardware mSBC, luego el software mSBC y, por último, se prefiere el hardware CVSD sobre el software CVSD.
En los siguientes diagramas de secuencia, se detallan las interacciones entre el AHAL y la pila de BT necesarias para establecer el estado de transmisión.
Procedimiento de delegación de hardware
En la figura 1, se ilustra cómo se coordinan la AHAL y la pila de BT para establecer una ruta de datos de hardware directa para el audio SCO:
Figura 1: Procedimiento de delegación de hardware.
Procedimiento de ruta de acceso a datos de software
En la figura 2, se ilustra el proceso para controlar los datos de audio que requieren procesamiento de software del sistema:
Figura 2: Procedimiento de ruta de datos de software
Procedimiento de renegociación del códec
Cuando la puerta de enlace de audio (AG) recibe un nuevo comando de códec disponible para BT (AT+BAC), la AG reinicia el procedimiento de negociación del códec. En la figura 3, se ilustra el procedimiento de renegociación del códec:
Figura 3. Procedimiento de renegociación de códec.
Impacto en HeadsetStateMachine
La máquina de estados de los auriculares de la capa de Java (representada por la clase HeadsetStateMachine) permanece en gran medida sin cambios, con la excepción del estado AUDIO_CONNECTED, que se controla mediante eventos de la pila nativa.
Dentro de la capa de Java, el sistema ya no inicia connectAudioNative ni disconnectAudioNative. En cambio, el sistema responde a los cambios de estado de la conexión de audio de la pila nativa. Estos cambios se activan con los comandos de AHAL en IBluetoothAudioProvider o IBluetoothAudioPort.
Implementación
Para integrar la refactorización de la administración de SCO, actualiza la comunicación entre la pila de BT y el framework de audio.
Sigue estos pasos para implementar la función:
Notifica al framework de audio sobre los cambios en el BT activo para ayudar con la administración adecuada del inicio y la finalización de SCO durante las conexiones de dispositivos HFP y para controlar los cambios de dispositivos activos. Usa
AudioManager.handleBluetoothActiveDeviceChanged(HfpInfo)para proporcionar esta información al framework de audio.
Figura 4: Conecta el dispositivo HFP.
El framework de audio usa la devolución de llamada
AudioManagerAudioDeviceCallback#onAudioDevicesAddeden lugar de las transmisiones heredadas para indicar el estado del dispositivo de audio.Implementa el control de transmisión de AHAL con
setCommunicationDevice(AudioDeviceInfodevice)como el punto de control principal para iniciar la conexión SCO.Si
HfpTransport::StartRequestdevuelveBluetoothAudioCtrlAck::PENDING, el AHAL debe volver a intentar la solicitud porque no se estableció la máquina de estados de HFP.
Casos de uso
En las siguientes secciones, se describen los recorridos críticos del usuario (CUJ) típicos.
Flujo de llamadas de telecomunicaciones
La refactorización de la administración de SCO cambia phoneStateChanged a una función de bloqueo. Esta modificación hace que telecom espere a que se complete la ejecución de phoneStateChanged dentro del método BluetoothInCallService.onCallAdded antes de invocar la API del framework de audio para iniciar la creación de SCO.
Figura 5: Responder o iniciar una llamada a través de telecomunicaciones
Flujo de llamadas VoIP
El framework de audio inicia el proceso llamando al método BluetoothHeadset.startScoUsingVirtualVoiceCall. Después de que la pila de BT proporciona un resultado al framework de audio, este dirige el AHAL para que ejecute startStream. En la siguiente figura, se ilustra este flujo:
Figura 6: Responder o iniciar una llamada a través de VoIP
Reconocimiento de voz
Para el reconocimiento de voz iniciado por el AG y el HF, la pila de BT debe solicitar al framework de audio que abra SCO con AudioManager.setCommunicationDevice. Esto se ilustra en la siguiente figura:
Figura 7: Iniciación de la SCO de reconocimiento de voz.
Conexión de audio
La pila de BT inicia una conexión SCO solicitando el framework de audio con AudioManager.setCommunicationDevice(AudioDeviceInfo) durante el reconocimiento de voz. Si hay una llamada activa, la pila de BT solicita BluetoothInCallService#requestBluetoothAudio a la pila de telecomunicaciones.
Este proceso se muestra en la siguiente figura:
Figura 8: Conexión de audio
Validación y prueba
Para validar que la función esté integrada correctamente y cumpla con los estándares de calidad, los fabricantes de dispositivos deben ejecutar las siguientes pruebas:
- CTS Verifier: Usa CTS Verifier para realizar pruebas interactivas del enrutamiento de audio durante las llamadas.
- Conjunto de pruebas de proveedores (VTS): Valida las interacciones entre AHAL y AHAL de BT con VTS.
Requisitos
Esta función está sujeta a los siguientes requisitos:
- AHAL: La implementación requiere un AHAL compatible que admita la ruta de administración de SCO refactorizada.