Audio Bluetooth Low Energy

L'audio Bluetooth Low Energy (LEA) garantisce agli utenti la ricezione di audio ad alta fedeltà senza sacrificare la durata della batteria e consente loro di passare senza problemi da un caso d'uso all'altro. Android 13 (livello API 33) include il supporto integrato per LEA.

La maggior parte delle cuffie LEA sarà in modalità doppia finché la quota di mercato dei dispositivi di origine LEA non aumenterà. Gli utenti dovrebbero essere in grado di accoppiare e configurare entrambi i trasporti sulle cuffie in modalità doppia.

Casi d'uso

Potresti voler integrare LEA per i seguenti casi d'uso:

• Condivisione audio: gli utenti possono condividere contemporaneamente più stream audio su uno o più dispositivi di ricezione audio. L'audio viene sincronizzato tra il dispositivo di origine e i dispositivi connessi.

• Audio di trasmissione: gli utenti possono trasmettere audio ad amici e parenti, nonché connettersi a trasmissioni pubbliche per informazioni, intrattenimento o accessibilità.

• Supporto del codec audio LC3: questo è il codec audio predefinito e sostituisce il codec SBC utilizzato per A2DP (media) e mSBC in HFP (voce). LC3 è più efficiente, riconfigurabile e di qualità superiore.

• Miglioramenti del campionamento audio: le cuffie possono mantenere una qualità audio di output elevata quando utilizzano i microfoni. Il Bluetooth classico riduce la qualità audio quando si utilizzano i microfoni Bluetooth. Con BLE Audio, il campionamento di input e output può raggiungere i 32 kHz.

• Microfono stereo: gli hearable possono registrare audio con microfoni stereo per miglioramenti dell'audio spaziale.

• Supporto del profilo HAP (Hearing Aid Profile): HAP offre agli utenti maggiore accessibilità e utilizzo rispetto ai precedenti protocolli ASHA. Gli utenti possono utilizzare gli apparecchi acustici per le chiamate e le applicazioni VoIP.

• Supporto del protocollo EATT (Enhanced Attribute Protocol): EATT consente agli sviluppatori di inviare più comandi contemporaneamente agli hearable accoppiati.

Scenari chiave

Esistono quattro categorie principali di casi d'uso:

1. Conversazionale: le applicazioni Dialer e VoIP che richiedono il routing delle comunicazioni a bassa latenza offrono audio di alta qualità e un minore utilizzo della batteria.

2. Gaming: la riproduzione simultanea del microfono e ad alta fedeltà consente ai giochi di trasmettere audio di alta qualità agli hearable. Un'app di gioco può accedere all'input audio BLE quando un gioco attiva il microfono Bluetooth come pronto all'uso. Poi, quando un giocatore avvia una conversazione live con un altro giocatore, l'app di gioco può utilizzare i dati del microfono senza ritardi.

3. Media: le applicazioni multimediali possono impostare il dispositivo preferito di Audio Manager. L'utente può eseguire l'override di questa impostazione modificando il dispositivo preferito dalle impostazioni del sistema.

4. Accessibilità: gli apparecchi acustici che supportano BLE Audio possono ora utilizzare il microfono, consentendo agli utenti di utilizzare continuamente gli apparecchi acustici per una chiamata.

API e metodi di BLE Audio

Per supportare gli hearable BLE Audio sono necessarie le seguenti API e i seguenti metodi:

AudioManager

• setCommunicationDevice() seleziona il dispositivo audio da utilizzare per i casi d'uso di comunicazione, ad esempio chiamate vocali o video. Questo metodo può essere utilizzato dalle applicazioni di chat vocale o videochiamata per selezionare un dispositivo audio diverso da quello selezionato per impostazione predefinita dalla piattaforma. Questa API sostituisce le seguenti API obsolete: startBluetoothSco(), stopBluetoothSco(), e setSpeakerphoneOn().
• clearCommunicationDevice() viene chiamata al termine di una chiamata o di una sessione dell'app per garantire all'utente un'esperienza ottimale quando passa da un'applicazione all'altra.

BluetoothProfile

• BluetoothLeAudio controlla il servizio Bluetooth tramite l'oggetto proxy.

Telecom InCallService

• InCallService#requestCallEndpointChange() sostituisce le API obsolete InCallService.setAudioRoute() e InCallService.requestBluetoothAudio() per consentire alle app di richiedere il routing audio a un CallEndpointspecifico. I client non devono definire il proprio CallEndpoint quando richiedono una modifica. Il nuovo endpoint deve invece essere uno degli endpoint validi forniti da InCallService.onAvailableCallEndpointsChanged(java.util.List).
• CallEndpoint.TYPE_BLUETOOTH indirizza lo stream audio tramite Bluetooth.
• Le API InCallService sopra menzionate sono progettate per essere utilizzate dall'app Telefono predefinita su uno smartphone Android o da altre superfici di chiamata come wearable, automobili o altri dispositivi Bluetooth che potrebbero voler influenzare il routing audio.

Telecom CallControl

• La nuova classe CallControl è stata introdotta nel livello API 34 per sostituire Connection e ConnectionService solo per le applicazioni VoIP.
• CallControl.requestCallEndpointChange() richiede anche una modifica di CallEndpoint. Questa API sostituisce le API obsolete Connection.requestBluetoothAudio() e Connection.setAudioRoute().
• Oltre alle API della piattaforma Telecom aggiornate, la libreria Telecom Jetpack è altamente consigliata per la creazione di applicazioni di chiamata vocale e/o video. Questa libreria può semplificare notevolmente il processo di integrazione e migliorare le chiamate VoIP su tutte le superfici Android.

Informazioni sul dispositivo audio

• AudioDeviceInfo.TYPE_BLE_HEADSET descrive il tipo di dispositivo audio come dispositivo LEA. Utilizzato per identificare se il dispositivo hearable è un dispositivo LEA.

Registratore audio

• setPreferredDevice() imposta il dispositivo preferito da utilizzare per il routing audio. L'utente può eseguire l'override di questa impostazione nelle impostazioni di sistema.

Adattatore Bluetooth

• isLeAudioSupported(): Restituisce una @BluetoothStatusCodes costante (FEATURE_SUPPORTED, FEATURE_NOT_SUPPORTED, o un codice di errore) che indica se l'hardware del dispositivo supporta LE Audio.
• isLeAudioBroadcastSourceSupported(): Restituisce una @BluetoothStatusCodes costante (FEATURE_SUPPORTED, FEATURE_NOT_SUPPORTED, o un codice di errore) che indica se l'hardware del dispositivo supporta la sorgente di trasmissione LE Audio.

Guide basate sul caso d'uso

Di seguito sono riportate le linee guida per l'implementazione di LEA in base a casi d'uso specifici.

Applicazioni di comunicazione vocale

Le applicazioni di comunicazione vocale possono scegliere di gestire il routing audio e lo stato del dispositivo gestendo autonomamente il proprio stato o utilizzando l'API Telecom, che esegue la logica di routing audio e stato.

• Autogestito: per le applicazioni che attualmente utilizzano startBluetoothSco(), stopBluetoothSco(), e setSpeakerphoneOn() o che vogliono gestire autonomamente lo stato di routing audio, segui la guida alle chiamate autogestite di Audio Manager.

• Gestito: utilizza la libreria Telecom Jetpack o le API della piattaforma Telecom per creare un'applicazione di chiamata audio o video.

Queste due soluzioni consentono di controllare in modo rapido e semplice il routing audio e di passare da un dispositivo Bluetooth all'altro. Per saperne di più, consulta la guida alle chiamate gestite di Telecom.

Applicazioni di registrazione audio

• Media Recorder: quando registri audio utilizzando Media Recorder, ora puoi registrare in stereo se l'hearable Bluetooth supporta LEA. Consulta la guida alla registrazione audio.

Consigli per le cuffie LE Audio (LEA)

Con il rilascio di un numero sempre maggiore di cuffie LEA, abbiamo riscontrato problemi nei test reali che compromettono l'esperienza utente. La specifica non copre tutti questi problemi. La tabella seguente fornisce un elenco di consigli che i produttori di cuffie LEA dovrebbero seguire per migliorare l'esperienza end-to-end per gli utenti Android.

Descrizione	Contesto
Supporta la derivazione della chiave di trasporto incrociata (CTKD) per le cuffie in modalità doppia: Supporta la derivazione della chiave sia per l'accoppiamento Classic-to-LE sia per l'accoppiamento LE-to-Classic.	La maggior parte delle nuove cuffie LEA sarà in modalità doppia finché la quota di mercato dei dispositivi di origine LEA non aumenterà. È importante che gli utenti siano in grado di accoppiare senza problemi le cuffie in modalità doppia e di configurare entrambi i trasporti. Questo è anche importante per Google accoppiamento rapido.
Supporta gli annunci mirati (TA) se vuoi che le cuffie LEA si riconnettano in modo affidabile ai dispositivi di origine. Gli auricolari LE Audio devono utilizzare i TA per richiedere una connessione in entrata dai dispositivi centrali. Verrà aggiunto al prossimo BT SIG.	A differenza del modello di paging di BR/EDR, in cui una connessione può essere avviata dallo smartphone o dalle cuffie, una connessione in LEA deve essere avviata dal dispositivo centrale. Al momento, molte cuffie non utilizzano i TA, il che significa che il dispositivo centrale potrebbe non essere in grado di riconnettersi al dispositivo periferico senza aggiungerlo a una lista consentita. Tuttavia, una soluzione alternativa con la lista consentita potrebbe impedire alle cuffie di connettersi a un dispositivo centrale diverso. Pertanto, è importante che le cuffie LEA supportino correttamente i TA in modo che il dispositivo centrale possa riconnettersi in modo affidabile senza soluzioni alternative che potrebbero interrompere le connessioni multipunto.
Visibilità ottimizzata per gli auricolari in modalità doppia L'auricolare principale - componente BR/EDR deve pubblicizzare utilizzando il suo indirizzo pubblico, abilitare la scansione di richiesta e pagina con il suo nome disponibile tramite EIR e impostare il bit 14 dell'audio LE su 1 nelle classi di servizi principali della classe di dispositivo (CoD). Auricolare principale - componente LE: l'auricolare principale deve eseguire una pubblicità connettibile e rilevabile (limitata o generale) utilizzando lo stesso indirizzo pubblico del componente BR/EDR e lo stesso nome locale completo del componente BR/EDR, con la categoria di aspetto impostata come una categoria di aspetto appropriata che corrisponda al tipo di dispositivo remoto, con l'aspettativa che il dispositivo centrale utilizzi queste informazioni per regolare le proprie norme di routing audio e dell'interfaccia utente. Auricolare secondario - solo LE: l'auricolare secondario deve eseguire una pubblicità connettibile e non rilevabile con la categoria di aspetto impostata come una categoria di aspetto appropriata che corrisponda al tipo di dispositivo remoto, con l'aspettativa che il dispositivo centrale utilizzi queste informazioni per regolare le proprie norme di routing audio e dell'interfaccia utente. Gli auricolari devono eleggere dinamicamente un leader dal gruppo CSIP come dispositivo principale. Se l'auricolare è in modalità doppia, il dispositivo principale deve essere in modalità doppia per garantire che le funzionalità LE e Classic funzionino correttamente dopo l'accoppiamento.	In questo modo, gli auricolari LEA in modalità doppia non vengono visualizzati come voci duplicate nelle impostazioni Bluetooth, il che potrebbe confondere gli utenti e compromettere l'esperienza di accoppiamento LEA. L'elezione dinamica del leader è particolarmente importante per i dispositivi in modalità doppia accoppiati in modo incrementale. Ad esempio, se è disponibile un solo auricolare è disponibile durante l'accoppiamento iniziale, deve presentarsi come un dispositivo in modalità doppia. Quando un utente accoppia il secondo auricolare in un secondo momento, deve accoppiare solo il componente LE e CSIP si assicurerà che siano raggruppati su Android. L'indirizzo di identità è consigliato durante l'accoppiamento perché il componente BR/EDR espone già l'indirizzo pubblico del dispositivo ai dispositivi nelle vicinanze.
Supporta il protocollo EATT (Enhanced Attribute Protocol).	Riduce la latenza di accoppiamento e connessione.
Supporta la memorizzazione nella cache GATT robusta.	Riduce la latenza di connessione, soprattutto per gli auricolari TWS.
Supporta la sottovalutazione della connessione.	Consente una pianificazione dei pacchetti più flessibile e un potenziale risparmio della batteria
Assicurati che durante la pre-elaborazione e la post-elaborazione sia per la riproduzione sia per l'acquisizione, la pipeline di elaborazione del segnale possa operare a 16, 24, 32 e 48 kHz, oltre a supportare frequenze più elevate.	Sfrutta le frequenze di campionamento più elevate supportate per i percorsi di acquisizione delle chiamate o VoIP LEA e la riproduzione multimediale.
Supporta LE Power Control	Migliore gestione dell'alimentazione

Supporto del tipo di contesto

Descrizione	Contesto
Utilizza tutti i tipi di contesto specificati in Assigned Numbers 6.12.3 a meno che le cuffie non supportino esplicitamente un determinato tipo di contesto.	Ad esempio, se il tipo di contesto "Gioco" non è supportato, Android invierà i suoni del gioco. In particolare, tieni presente che il tipo di contesto "Non specificato" non significa "qualsiasi tipo di contesto" e non copre i tipi di contesto non supportati.
Quando il dispositivo centrale interagisce con l'ASCS del dispositivo periferico, quest'ultimo deve connettersi all'MCS e al TBS del dispositivo centrale. Il dispositivo centrale potrebbe non utilizzare sempre l'audio LE come percorso di streaming perché potrebbe tornare a utilizzare A2DP o HFP. Il dispositivo periferico può utilizzare l'interazione ASCS come indicazione se il dispositivo centrale utilizzerà l'audio LE per lo streaming. Alcuni esempi di interazioni ASCS sono la lettura, la scrittura e la registrazione per la notifica.

Nota: in linea con la specifica, le cuffie possono rimuovere i tipi di contesto da i tipi di contesto disponibili in qualsiasi momento e per tutti i dispositivi connessi, anche per un dispositivo che sta attualmente eseguendo lo streaming di un determinato tipo di contesto. Ti consigliamo di non rimuovere il tipo di contesto attualmente in streaming dai tipi di contesto disponibili sul dispositivo che sta eseguendo lo streaming di quel tipo di contesto.