Ristrutturazione dello SCO gestito audio

Questa pagina descrive come attivare il framework audio e l'HAL audio (AHAL) per gestire le connessioni sincrone orientate alla connessione (SCO), un processo identificato 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, che in origine era 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 (Hardware Abstraction Layer) audio per SCO con altri profili Bluetooth 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ù solida e centralizzata.

Panoramica dell'architettura

L'architettura AMSCO centralizza la gestione della connessione SCO all'interno del framework audio di Android, che basa le decisioni di routing sull'attività di streaming audio. Questa architettura è diversa dal modello precedente in cui lo stack BT gestiva le connessioni. I ruoli di ogni componente di questa architettura sono i seguenti:

L'AHAL avvia e sospende la sessione SCO solo se sono soddisfatte le seguenti condizioni:

• Un flusso attivo viene patchato su 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'HAL audio.

Il framework audio gestisce la gestione SCO, quindi lo stack BT non chiama più la connessione o la disconnessione dell'audio. In caso di disconnessione o errore SCO preventivo, 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 gli AHAL o gli AHAL BT, utilizza una proprietà di sistema per indicare che la nuova gestione SCO deve essere attivata. 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 del profilo vivavoce (HFP) 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 quando possibile. La preferenza per i codec durante la negoziazione segue questo ordine: l'hardware LC3 è preferito al software LC3, seguito dall'hardware mSBC, poi dal software mSBC e infine l'hardware CVSD è preferito al software CVSD.

I seguenti diagrammi di sequenza descrivono in dettaglio le interazioni tra AHAL e lo stack BT necessarie per stabilire lo stato dello stream.

Procedura di offload hardware

La Figura 1 mostra come lo stack AHAL e BT si coordinano per stabilire un percorso dati hardware diretto per l'audio SCO:

Figura 1. Procedura di offload hardware.

Procedura del percorso dei dati del software

La Figura 2 illustra il processo di gestione dei dati audio che richiedono l'elaborazione del software di sistema:

Figura 2. Procedura del percorso dei dati del software.

Procedura di rinegoziazione dei codec

Quando il gateway audio (AG) riceve un nuovo comando BT available codec (AT+BAC), l'AG 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 a stati delle cuffie del livello Java (rappresentata dalla classe HeadsetStateMachine) rimane in gran parte invariata, ad eccezione dello stato AUDIO_CONNECTED, che è determinato dagli eventi dello stack nativo. All'interno del livello Java, il sistema non avvia più connectAudioNative o disconnectAudioNative. Il sistema risponde 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.

Per implementare la funzionalità:

1. Notifica al framework audio le modifiche al BT attivo per facilitare la corretta gestione dell'avvio e dell'interruzione di SCO durante le connessioni dei dispositivi HFP e per gestire le modifiche ai dispositivi attivi. Utilizza AudioManager.handleBluetoothActiveDeviceChanged(HfpInfo) per fornire queste informazioni al framework audio.

   

   Figura 4. Connetti il dispositivo HFP.

   Il framework audio utilizza il AudioManagerAudioDeviceCallback#onAudioDevicesAdded callback anziché le trasmissioni legacy per indicare lo stato del dispositivo audio.

2. Implementa il controllo del flusso AHAL utilizzando setCommunicationDevice(AudioDeviceInfodevice) come punto di controllo principale per avviare la connessione SCO.

   Se HfpTransport::StartRequest restituisce BluetoothAudioCtrlAck::PENDING, AHAL deve riprovare la richiesta perché la macchina a stati HFP non è stabilita.

Casi d'uso

Le sezioni seguenti descrivono i tipici Critical User Journey (CUJ).

Flusso di chiamata di telecomunicazione

Il refactoring della gestione SCO trasforma phoneStateChanged in una funzione di blocco. Questa modifica fa sì che l'operatore di telecomunicazioni attenda 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. Rispondere a una chiamata o avviarla tramite l'operatore di telefonia.

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, quest'ultimo indica all'HAL audio di eseguire startStream. La figura seguente illustra questo flusso:

Figura 6. Rispondere a una chiamata o avviarne una tramite VoIP.

Riconoscimento vocale

Per il riconoscimento vocale avviato sia in vivavoce (HF) sia dall'app, lo stack BT deve richiedere al framework audio di aprire SCO utilizzando AudioManager.setCommunicationDevice(). Ciò è illustrato nella figura seguente:

Figura 7. Avvio del riconoscimento vocale SCO.

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 BluetoothInCallService#requestBluetoothAudio dallo stack di telecomunicazioni.

Questa procedura è illustrata nella figura seguente:

Immagine 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 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.