Audio Bluetooth Low Energy

Nota: isLeAudioSupported() e isLeAudioBroadcastSourceSupported() restituiranno True se il dispositivo supporta BLE Audio.

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

La maggior parte delle cuffie LEA utilizzerà la modalità doppia fino a quando la quota di mercato dei dispositivi di origine LEA non crescerà. Gli utenti devono essere in grado di accoppiare e configurare entrambi i trasporti sulle cuffie dual mode.

Casi d'uso

Ti consigliamo di integrare LEA per i seguenti casi d'uso:

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

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

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

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

• Microfono stereo: gli auricolari 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 protocolli ASHA precedenti. 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 principali

Esistono quattro categorie principali di casi d'uso:

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

2. Gioco: il microfono simultaneo e la riproduzione ad alta fedeltà consentono ai giochi di trasmettere in streaming audio di alta qualità agli ascoltatori. Un'app di gioco può accedere all'input audio BLE quando un gioco attiva il microfono Bluetooth come pronto per l'uso. Quindi, quando un giocatore avvia una conversazione dal vivo con un giocatore peer, l'app di gioco può utilizzare i dati del microfono senza ritardi.

3. Contenuti multimediali: le applicazioni multimediali sono autorizzate a impostare il dispositivo preferito dal gestore audio. L'utente può sostituire questa impostazione modificando il dispositivo preferito dalle impostazioni del sistema.

4. Accessibilità: gli apparecchi acustici che supportano l'audio BLE ora possono usare il microfono, consentendo agli utenti di utilizzarli continuamente per una chiamata.

API e metodi BLE Audio

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

AudioManager

• setCommunicationDevice() consente di selezionare il dispositivo audio da utilizzare per i casi d'uso di comunicazione, ad esempio le chiamate vocali o le videochiamate. Questo metodo può essere utilizzato dalle applicazioni di chat vocale o video per selezionare un dispositivo audio diverso da quello selezionato per impostazione predefinita dalla piattaforma. Questa API sostituisce le seguenti API ritirate: startBluetoothSco(), stopBluetoothSco(), e setSpeakerphoneOn().
• clearCommunicationDevice() viene chiamato 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 oggetto proxy.

Telecom InCallService

• L'API InCallService#requestCallEndpointChange() sostituisce le API InCallService.setAudioRoute() e InCallService.requestBluetoothAudio() riservate per consentire alle app di richiedere il routing dell'audio a un CallEndpoint specifico. 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.
• Queste API InCallService precedenti sono progettate per essere utilizzate dall'app Telefono predefinita su uno smartphone Android o su altre piattaforme di chiamata come indossabili, automobili o altri dispositivi Bluetooth che potrebbero voler influenzare il routing dell'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 Connection.requestBluetoothAudio() e Connection.setAudioRoute() ritirate.
• Oltre alle API della piattaforma di telecomunicazioni aggiornate, la libreria Telecom Jetpack è molto consigliata per la creazione di applicazioni di chiamate vocali e/o video. Questa biblioteca può semplificare notevolmente il processo di integrazione e migliorare le chiamate VoIP su tutte le piattaforme Android.

Informazioni sul dispositivo audio

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

Registratore audio

• setPreferredDevice() imposta il dispositivo preferito per l'utilizzo del routing audio. L'utente può eseguire l'override di questo valore nelle impostazioni di sistema.

Adattatore Bluetooth

• isLeAudioSupported() restituisce se l'hardware della piattaforma supporta il LEA.
• isLeAudioBroadcastSourceSupported() restituisce true se l'hardware della piattaforma supporta LEA.

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 dei dispositivi tramite la gestione autonoma dello stato o tramite l'API Telecom, che gestisce il routing audio e la logica dello stato al posto tuo.

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

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

Queste due soluzioni ti consentono di controllare rapidamente e facilmente il routing audio e di passare tra i dispositivi Bluetooth. Per ulteriori informazioni, consulta la guida alle chiamate gestite da Telecom.

Applicazioni di registrazione audio

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

Consigli per le cuffie LE Audio (LEA)

Man mano che vengono rilasciati altri visori LEA, abbiamo rilevato dei problemi nei test reale che peggiorano l'esperienza utente. La specifica non copre tutti questi problemi. La tabella seguente fornisce un elenco di consigli che i produttori di cuffie LEA devono seguire per migliorare l'esperienza end-to-end per gli utenti Android.

Descrizione	Contesto
Supporto della derivazione della chiave di trasporto incrociato (CTKD) per gli cuffie dual mode: Supporta la derivazione delle chiavi sia per l'accoppiamento da Classic a LE sia per l'accoppiamento da LE a Classic.	La maggior parte delle nuove cuffie LEA sarà dual-mode fino a quando la quota di mercato dei dispositivi di origine LEA non crescerà. È importante che gli utenti possano accoppiare i loro headset dual mode senza problemi e configurare entrambi i trasporti. Questo è importante anche per l'accoppiamento rapido di Google.
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 gli annunci di accoppiamento 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 tramite il telefono o le cuffie, una connessione in LEA deve essere avviata dal dispositivo centrale. Attualmente, molte cuffie non utilizzano TA, il che significa che il dispositivo centrale potrebbe non riuscire a riconnettersi alla periferica senza aggiungerla a una lista consentita. Tuttavia, una soluzione alternativa con la lista consentita potrebbe impedire all'auricolare di collegarsi a un altro dispositivo centrale. Pertanto, è importante che le cuffie LEA supportino correttamente le TA in modo che il dispositivo centrale possa ricollegarsi in modo affidabile senza soluzioni alternative che potrebbero interrompere le connessioni multipunto.
Visibilità ottimizzata per gli auricolari dual mode L'auricolare principale - Componente BR/EDR deve pubblicizzarsi utilizzando il proprio indirizzo pubblico e attivare la ricerca e la scansione di pagine con il proprio nome disponibile tramite EIR, nonché impostare il bit audio LE 14 su 1 nelle classi di servizio principali della classe del dispositivo (CoD). Auricolare principale - Componente LE: l'auricolare principale deve pubblicare un annuncio collegabile e rilevabile (limitato 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 Categoria di aspetto appropriata che corrisponda al tipo di dispositivo remoto, aspettandosi che il dispositivo centrale utilizzi queste informazioni per regolare le norme dell'interfaccia utente. Auricolare secondario - Solo LE: l'auricolare secondario deve eseguire un annuncio connesso e non rilevabile con la relativa Categoria aspetto impostata come Categoria aspetto appropriata che corrisponda al tipo di dispositivo remoto, con l'aspettativa che il dispositivo centrale utilizzi queste informazioni per regolare la UI e le norme di instradamento audio Gli auricolari devono eleggere dinamicamente un leader dal gruppo CSIP come dispositivo principale. Se l'auricolare è dual mode, il dispositivo principale deve essere dual mode per garantire che entrambe le funzionalità LE e Classic funzionino correttamente dopo l'accoppiamento.	In questo modo, gli auricolari LEA dual-mode non vengono visualizzati come voci duplicate nelle impostazioni Bluetooth, il che potrebbe confondere gli utenti e compromettere l'esperienza di accoppiamento LEA. L'elezione del leader dinamico è particolarmente importante per i dispositivi dual-mode accoppiati in modo incrementale. Ad esempio, se all'accoppiamento iniziale è disponibile un solo auricolare, questo dovrebbe presentarsi come un dispositivo dual mode. Quando un utente accoppia il secondo auricolare in un secondo momento, deve solo accoppiarlo al 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 Enhanced Attribute Protocol (EATT).	Riduce la latenza di accoppiamento e connessione.
Supporta la cache GATT affidabile.	Riduce la latenza di connessione, in particolare per i mini auricolari TWS.
Supporto della classificazione secondaria della connessione.	Consente una pianificazione dei pacchetti più flessibile e un potenziale risparmio di batteria.
Assicurati che durante l'elaborazione pre e post-produzione sia per la riproduzione che per la registrazione, la pipeline di elaborazione del segnale possa funzionare a 16, 24, 32 e 48 kHz, nonché supportare frequenze più elevate.	Sfrutta le frequenze di campionamento più elevate supportate per i percorsi di acquisizione delle chiamate o VoIP delle forze dell'ordine e la riproduzione dei contenuti multimediali.
Supporto di LE Power Control	Migliore gestione dell'alimentazione

Supporto del tipo di contesto

Descrizione	Contesto
Utilizza tutti i tipi di contesto specificati in Numeri assegnati 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 di 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, la periferica deve connettersi ai sistemi MCS e TBS del dispositivo centrale. Il dispositivo centrale potrebbe non utilizzare sempre LE Audio come percorso di streaming perché potrebbe tornare all'utilizzo di A2DP o HFP. Il dispositivo periferico può utilizzare l'interazione ASCS come indicazione dell'utilizzo o meno dell'audio LE per lo streaming da parte del dispositivo centrale. Alcuni esempi di interazioni ASCS sono lettura, scrittura e registrazione per la notifica.

Nota: in conformità con le specifiche, gli auricolari possono rimuovere i tipi di contesto dai tipi di contesto disponibili in qualsiasi momento e su tutti i dispositivi connessi, anche su un dispositivo che sta attualmente trasmettendo in streaming un determinato tipo di contesto. È consigliabile che le cuffie non rimuovano il tipo di contesto attualmente in streaming dai tipi di contesto disponibili sul dispositivo che sta trasmettendo quel tipo di contesto.