En esta página, se describe cómo habilitar el framework de audio y el HAL de audio (AHAL) para administrar las conexiones síncronas orientadas a la conexión (SCO), un proceso identificado como SCO administrado por audio (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 mueve el estado de conexión de SCO de un estado que pertenece al 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 de audio (HAL) para SCO con otros perfiles de BT, como el perfil de distribución de audio avanzada (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 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. Las funciones de cada componente de esta arquitectura son las siguientes:
El AHAL inicia y suspende la sesión de SCO solo si se cumplen las siguientes condiciones:
- Se aplica un parche a una transmisión activa en un dispositivo SCO.
- Se establece el modo de audio y existe un parche para un dispositivo SCO.
El framework de audio evita 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 la conexión ni desconecta el 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 heredada se conserva hasta por seis años en los casos en que la propiedad del sistema esté inhabilitada o la versión de 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 sesión 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 de acceso disponibles.
La pila de BT usa una delegación de hardware siempre que sea posible. La preferencia por los códecs durante la negociación sigue este orden: se prefiere el hardware LC3 al software LC3, seguido del hardware mSBC, luego el software mSBC y, por último, se prefiere el hardware CVSD al 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 la transmisión.
Procedimiento de delegación de hardware
En la figura 1, se muestra cómo se coordinan el 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 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 de códecs
Cuando la puerta de enlace de audio (AG) recibe un nuevo comando de códec disponible de BT (AT+BAC), la AG reinicia el procedimiento de negociación de códecs. En la figura 3, se ilustra el procedimiento de renegociación de códecs:
Figura 3: Procedimiento de renegociación de códecs
Impacto en HeadsetStateMachine
La máquina de estado 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 pila nativos.
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 mediante los comandos del 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 eliminació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::StartRequestmuestraBluetoothAudioCtrlAck::PENDING, el AHAL debe volver a intentar la solicitud porque no se estableció la máquina de estado 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 las telecomunicaciones esperen 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: Contesta o inicia 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, el framework dirige el AHAL para que ejecute startStream. En la siguiente figura, se ilustra este flujo:
Figura 6: Contesta o inicia una llamada a través de VoIP
Reconocimiento de voz
Para el reconocimiento de voz iniciado por manos libres (HF) y AG, 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: Inicio de 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 una llamada está activa, la pila de BT solicita BluetoothInCallService#requestBluetoothAudio de 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 de enrutamiento de audio durante las llamadas.
- Conjunto de pruebas de proveedores (VTS): Valida las interacciones de 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.