Questa pagina descrive come abilitare il framework audio e l'HAL audio (AHAL) per gestire le connessioni SCO (Synchronous Connection-Oriented), una procedura identificata come SCO gestito dall'audio (AMSCO).
In Android 17 e versioni successive, il framework audio di Android utilizza la funzionalità di gestione SCO per gestire il routing SCO, originariamente gestito dal framework Bluetooth (BT). Questa migrazione sposta lo stato della connessione SCO da uno stato di proprietà del framework BT a una conseguenza a valle dell'attività di streaming audio.
Centralizzando la proprietà del routing audio all'interno del framework audio, questa funzionalità allinea l'implementazione dell'HAL audio (Hardware Abstraction Layer) per SCO con altri profili BT come A2DP (Advanced Audio Distribution Profile) e LE Audio. Questo refactoring semplifica l'interazione tra gli stack di telecomunicazioni e BT, consentendo un'architettura di routing audio più robusta e centralizzata.
Panoramica dell'architettura
L'architettura AMSCO centralizza la gestione delle connessioni SCO all'interno del framework audio di Android, che basa le decisioni di routing sull'attività di streaming audio. Questa architettura è in contrasto con il modello precedente in cui lo stack BT gestiva le connessioni. I ruoli di ogni componente in questa architettura sono i seguenti:
L'AHAL avvia e sospende la sessione SCO solo se sono soddisfatte le seguenti condizioni:
- Uno stream attivo è collegato a un dispositivo SCO.
- La modalità audio è impostata ed esiste una patch per un dispositivo SCO.
Il framework audio impedisce a un dispositivo A2DP di avere una patch simultanea quando vengono soddisfatti questi criteri specifici. Il framework audio non invia più modifiche dello stato SCO o sospensioni A2DP all'AHAL.
Il framework audio gestisce SCO, quindi lo stack BT non chiama più l'audio di connessione o disconnessione. In caso di disconnessione o errore SCO preventiva, lo stack BT informa il framework audio con AudioManager#onHfpAudioDisconnected.
Piano
Utilizza le informazioni in questa sezione per valutare i seguenti requisiti di compatibilità e architettura prima di implementare il refactoring della gestione SCO.
Compatibilità con le versioni precedenti
Per consentire al framework di continuare a supportare i dispositivi che potrebbero ricevere aggiornamenti del sistema operativo senza aggiornare i relativi AHAL o AHAL BT, utilizza una proprietà di sistema per indicare che la nuova gestione SCO deve essere abilitata. Il percorso legacy viene mantenuto per un massimo di sei anni nei casi in cui la proprietà di sistema è disattivata o la versione HAL non è aggiornata.
Configurare la sessione HFP
L'AHAL deve utilizzare il nuovo tipo di sessione HFP (Hands-Free Profile) per avviare o sospendere la riproduzione, in modo simile ad altri tipi di sessione BT. Lo stato dello stream viene gestito in definitiva utilizzando diversi IBluetoothAudioProviders, che vengono enumerati e creati da una classe Factory a seconda dei percorsi disponibili.
Lo stack BT utilizza un percorso di offload hardware ogni volta che è possibile. La preferenza per i codec durante la negoziazione segue questo ordine: l'hardware LC3 è preferito al software LC3, seguito dall'hardware mSBC, quindi dal software mSBC e infine l'hardware CVSD è preferito al software CVSD.
I seguenti diagrammi di sequenza descrivono in dettaglio le interazioni tra l'AHAL e lo stack BT necessarie per stabilire lo stato dello stream.
Procedura di offload hardware
La Figura 1 illustra come l'AHAL e lo stack BT si coordinano per stabilire un percorso dati hardware diretto per l'audio SCO:
Figura 1. Procedura di offload hardware.
Procedura del percorso dati software
La Figura 2 illustra la procedura per la gestione dei dati audio che richiedono l'elaborazione del software di sistema:
Figura 2. Procedura del percorso dati software.
Procedura di rinegoziazione del codec
Quando il gateway audio (AG) riceve un nuovo comando del codec BT disponibile (AT+BAC), riavvia la procedura di negoziazione del codec. La Figura 3 illustra la procedura di rinegoziazione del codec:
Figura 3. Procedura di rinegoziazione del codec.
Impatto su HeadsetStateMachine
La macchina di stato dell'auricolare del livello Java (rappresentata dalla classe HeadsetStateMachine) rimane in gran parte invariata, ad eccezione dello stato AUDIO_CONNECTED, che è guidato dagli eventi dello stack nativo.
All'interno del livello Java, il sistema non avvia più
connectAudioNative o disconnectAudioNative. Il sistema risponde invece alle modifiche dello stato della connessione audio dallo stack nativo. Queste modifiche vengono attivate dai comandi dell'AHAL su IBluetoothAudioProvider o IBluetoothAudioPort.
Implementazione
Per integrare il refactoring della gestione SCO, aggiorna la comunicazione tra lo stack BT e il framework audio.
Segui questi passaggi per implementare la funzionalità:
Informa il framework audio delle modifiche al BT attivo per facilitare la gestione corretta dell'avvio e dell'interruzione di SCO durante le connessioni dei dispositivi HFP e per gestire le modifiche dei dispositivi attivi. Utilizza
AudioManager.handleBluetoothActiveDeviceChanged(HfpInfo)per fornire queste informazioni al framework audio.
Figura 4. Connetti il dispositivo HFP.
Il framework audio utilizza il callback
AudioManagerAudioDeviceCallback#onAudioDevicesAddedanziché le trasmissioni legacy per indicare lo stato del dispositivo audio.Implementa il controllo dello stream AHAL utilizzando
setCommunicationDevice(AudioDeviceInfodevice)come punto di controllo principale per avviare la connessione SCO.Se
HfpTransport::StartRequestrestituisceBluetoothAudioCtrlAck::PENDING, l'AHAL deve riprovare la richiesta perché la macchina di stato HFP non è stabilita.
Casi d'uso
Le seguenti sezioni descrivono i percorsi utente critici (CUJ) tipici.
Flusso di chiamata di telecomunicazioni
Il refactoring della gestione SCO trasforma phoneStateChanged in una funzione di blocco. Questa modifica fa sì che le telecomunicazioni attendano il completamento dell'esecuzione di phoneStateChanged all'interno del metodo BluetoothInCallService.onCallAdded prima di richiamare l'API del framework audio per avviare la creazione di SCO.
Figura 5. Rispondi o avvia una chiamata tramite telecomunicazioni.
Flusso di chiamata VoIP
Il framework audio avvia la procedura chiamando il metodo BluetoothHeadset.startScoUsingVirtualVoiceCall. Dopo che lo stack BT fornisce un risultato al framework audio, il framework indica all'AHAL di eseguire startStream. La figura seguente illustra questo flusso:
Figura 6. Rispondi o avvia una chiamata tramite VoIP.
Riconoscimento vocale
Per il riconoscimento vocale avviato sia da HF (Hands-Free) sia da AG, lo stack BT deve richiedere al framework audio di aprire SCO utilizzando AudioManager.setCommunicationDevice. Questo è illustrato nella figura seguente:
Figura 7. Avvio di SCO per il riconoscimento vocale.
Connessione audio
Lo stack BT avvia una connessione SCO richiedendo il framework audio con
AudioManager.setCommunicationDevice(AudioDeviceInfo) durante il riconoscimento vocale. Se una chiamata è attiva, lo stack BT richiede invece BluetoothInCallService#requestBluetoothAudio dallo stack di telecomunicazioni.
Questa procedura è mostrata nella figura seguente:
Figura 8. Connessione audio.
Convalida e test
Per verificare che la funzionalità sia integrata correttamente e soddisfi gli standard di qualità, i produttori di dispositivi devono eseguire i seguenti test:
- CTS Verifier: utilizza CTS Verifier per i test interattivi del routing audio durante le chiamate.
- Vendor Test Suite (VTS): convalida le interazioni AHAL e BT AHAL utilizzando VTS.
Requisiti
Questa funzionalità è soggetta ai seguenti requisiti:
- AHAL: l'implementazione richiede un AHAL compatibile che supporti il percorso di gestione SCO sottoposto a refactoring.