Prima di avviare uno stream logico, un'app richiede il focus audio utilizzando gli stessi attributi audio utilizzati per lo stream logico. L'app deve rispettare le perdite di focus per funzionare come previsto nei casi d'uso automobilistici.
Sebbene sia consigliabile inviare una richiesta di focus, non è applicata dal sistema. Pertanto, considera il focus come un mezzo per controllare indirettamente ed evitare conflitti durante la riproduzione anziché come meccanismo di controllo audio principale. Il veicolo non deve dipendere dal sistema di focus per il funzionamento del sottosistema audio.
Interazioni di focus
Per supportare AAOS, le richieste di focus audio vengono gestite in base alle interazioni predefinite tra il CarAudioContext della richiesta e quello dei titolari del focus correnti. Esistono tre tipi di interazioni:
- Esclusiva
- Rifiuta
- Simultanea
Interazione esclusiva
Questo è il modello di interazione più comunemente utilizzato con Android.
Nelle interazioni esclusive, è consentito a una sola app di mantenere il focus alla volta.
Pertanto, a una richiesta di focus in entrata viene concesso il focus mentre il titolare del focus esistente lo perde. Poiché entrambe le app riproducono contenuti multimediali, è consentito a una sola app di mantenere il focus. Di conseguenza, la richiesta di focus dell'app appena avviata viene restituita con AUDIOFOCUS_REQUEST_GRANTED, mentre l'app di riproduzione musicale corrente riceve un evento di modifica del focus con uno stato di perdita che corrisponde al tipo di richiesta effettuata.
Interazione di rifiuto
Con le interazioni di rifiuto, la richiesta in entrata viene sempre rifiutata. Ad esempio, quando si tenta di riprodurre musica durante una chiamata. In questo caso, se l'app Telefono mantiene il focus audio per una chiamata e una seconda app richiede il focus per riprodurre musica, l'app musicale riceve AUDIOFOCUS_REQUEST_FAILED in risposta alla richiesta. Poiché la richiesta di focus viene rifiutata, non viene inviata alcuna perdita di focus al titolare del focus corrente.
Interazione simultanea
Le interazioni simultanee sono esclusive di AAOS. In questo modo, le app che richiedono il focus audio in auto possono mantenere il focus contemporaneamente ad altre app. Affinché si verifichi un'interazione simultanea, devono essere soddisfatte le seguenti condizioni. La funzione
La richiesta di focus in entrata deve richiedere AudioManager.AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK
Il titolare del focus corrente non imposta setPauseWhenDucked(true)
Il titolare del focus corrente sceglie di non ricevere eventi di ducking
Se questi criteri vengono soddisfatti, la richiesta di focus viene restituita con AUDIOFOCUS_REQUEST_GRANTED, mentre il focus del titolare del focus corrente non cambia. Tuttavia, se il titolare del focus corrente sceglie di ricevere eventi di ducking o di mettere in pausa quando viene eseguito il ducking, il titolare del focus corrente perde il focus, come avviene con un'interazione esclusiva.
Gestire gli stream simultanei
Sebbene l'interazione simultanea abbia numerosi utilizzi, fai attenzione al mixaggio e al ducking a livello hardware sui dispositivi di output. Ti consigliamo vivamente di instradare le istanze di CarAudioContext che possono essere riprodotte contemporaneamente a dispositivi di output diversi.
Se disponi di dispositivi di output separati per gli stream simultanei, l'HAL può eseguire il ducking di uno degli stream prima di mixarli o instradare gli stream fisici a altoparlanti diversi nel veicolo. Se gli stream logici vengono mixati in Android, i guadagni non vengono modificati e vengono forniti come parte dello stesso stream fisico.
Ad esempio, quando la navigazione e i contenuti multimediali vengono forniti contemporaneamente, il guadagno per lo stream multimediale potrebbe essere temporaneamente ridotto (o ducked) in modo che le indicazioni stradali possano essere ascoltate più chiaramente. In alternativa, lo stream di navigazione potrebbe essere instradato agli altoparlanti lato conducente, mentre i contenuti multimediali continuano a essere riprodotti nel resto dell'abitacolo.
Matrice di interazione
Questa tabella mostra la matrice di interazione definita da CarAudioService.
Ogni riga rappresenta il CarAudioContext del titolare del focus corrente e ogni colonna rappresenta quello della richiesta in entrata.
A causa delle interazioni simultanee, è possibile avere più di un titolare del focus. In questo caso, una richiesta di focus in entrata viene confrontata con ciascuno dei titolari del focus correnti prima di determinare l'interazione da applicare. In questo caso, vince l'interazione più conservativa. Rifiuta, poi esclusiva e infine simultanea.
Figura 1. Matrice di interazione del focus audio.
Navigazione durante le telefonate
In Android 11 è stata introdotta una nuova impostazione utente per consentire agli utenti di modificare il comportamento di interazione tra la navigazione e le telefonate. Se impostato,
android.car.KEY_AUDIO_FOCUS_NAVIGATION_REJECTED_DURING_CALL modifica l'
interazione tra le richieste di focus in entrata NAVIGATION e i titolari del focus correnti CALL
da simultanea a rifiuta. Se un utente preferisce che le indicazioni stradali non interrompano una chiamata, può attivare l'impostazione. Questa impostazione viene mantenuta per l'utente e può essere impostata dinamicamente in modo che le richieste di focus successive rispettino la nuova impostazione.
Focus audio ritardabile
In Android 11, AAOS ha aggiunto il supporto per la richiesta di focus audio ritardabile. In questo modo, le richieste di focus non transitorie possono essere ritardate quando la loro interazione con i titolari del focus correnti comporterebbe normalmente il rifiuto. Una volta che una modifica del focus comporta uno stato in cui la richiesta ritardata può ottenere il focus, la richiesta viene concessa.
Regole per le richieste di focus audio ritardate
Solo richieste non transitorie. Una richiesta ritardata può essere effettuata solo per le sorgenti non transitorie per evitare che un suono transitorio venga riprodotto molto tempo dopo che è rilevante.
È possibile ritardare una sola richiesta alla volta. Se viene effettuata una richiesta ritardabile mentre è già presente una richiesta ritardata, la richiesta ritardata originale riceve un evento di modifica
AUDIOFOCUS_LOSSe la nuova richiesta riceve una risposta sincronaAUDIOFOCUS_REQUEST_DELAYED.Le richieste ritardabili devono avere
OnAudioFocusChangeListener. Dopo che una richiesta è stata ritardata, il listener viene utilizzato per notificare al richiedente quando la richiesta viene concessa (AUDIOFOCUS_GAIN) o se viene rifiutata in un secondo momento (AUDIOFOCUS_LOSS).
Richiedere il focus ritardabile
Per creare una richiesta che può essere ritardata:
Utilizza
AudioFocusRequest.Builder#setAcceptsDelayedFocusGain.mMediaWithDelayedFocusListener = new MediaWithDelayedFocusListener(); mDelayedFocusRequest = new AudioFocusRequest .Builder(AudioManager.AUDIOFOCUS_GAIN) .setAudioAttributes(mMusicAudioAttrib) .setOnAudioFocusChangeListener(mMediaWithDelayedFocusListener) .setForceDucking(false) .setWillPauseWhenDucked(false) .setAcceptsDelayedFocusGain(true) .build();Quando effettui la richiesta, gestisci la risposta
AUDIOFOCUS_REQUEST_DELAYED:int delayedFocusRequestResults = mAudioManager.requestAudioFocus(mDelayedFocusRequest); if (delayedFocusRequestResults == AudioManager.AUDIOFOCUS_REQUEST_GRANTED) { // start audio playback return; } if (delayedFocusRequestResults == AudioManager.AUDIOFOCUS_REQUEST_DELAYED) { // audio playback delayed to audio focus listener return; }Quando la richiesta viene ritardata, il listener del focus gestisce le modifiche del focus:
private final class MediaWithDelayedFocusListener implements OnAudioFocusChangeListener { @Override public void onAudioFocusChange(int focusChange) { synchronized (mLock) { switch (focusChange) { case AudioManager.AUDIOFOCUS_GAIN: … // Start focus playback case AudioManager.AUDIOFOCUS_LOSS_TRANSIENT: … // Pause media transiently case AudioManager.AUDIOFOCUS_LOSS: … // Stop media
Dissolvenza applicata dal sistema
Android 15 introduce la dissolvenza audio applicata dal sistema in AAOS. In Android, il focus audio non viene applicato dal sistema. Pertanto, sebbene gli sviluppatori di app siano incoraggiati a rispettare le linee guida per il focus audio, se un'app continua a essere riprodotta ad alto volume anche dopo aver perso il focus audio, il sistema non può impedirlo.
Negli ambienti automobilistici critici per la sicurezza, il rispetto del focus audio è fondamentale per ridurre al minimo la distrazione del conducente. Con questa funzionalità, il framework audio ora esegue automaticamente la dissolvenza delle app che perdono il focus audio, per un'esperienza audio più controllata e prevedibile.
Questo miglioramento contribuisce a garantire che le app rispettino la decisione di perdita del focus audio definita dalla matrice di interazione, evitando conflitti di riproduzione audio.
Progettazione di alto livello
La figura seguente mostra la progettazione di alto livello e il supporto per la funzionalità di perdita del focus nelle auto:
Figura 2. Progettazione di alto livello per la funzionalità di dissolvenza applicata dal sistema.
- Dissolvenza mirata: l'applicazione della dissolvenza da parte del sistema in Android 15 è progettata specificamente per le situazioni in cui un'app perde il focus audio ma continua a riprodurre audio.
- Meccanismo di dissolvenza: quando un'app perde il focus audio a favore di una nuova app richiedente:
- Il framework audio esegue automaticamente la dissolvenza dell'audio dell'app che perde il focus.
- Dopo la dissolvenza, lo stream audio viene silenziato dal sistema.
- L'app riceve quindi una notifica di perdita del focus audio.
- Le app che non si comportano correttamente vengono silenziate finché non riacquistano il focus audio.
- La logica predefinita prevede la dissolvenza delle app dopo 2 secondi. Tuttavia, gli OEM possono configurare questo valore di timeout.
- Il framework audio utilizza le configurazioni OEM sia per le operazioni di dissolvenza che per quelle di dissolvenza in entrata.
File di configurazione OEM: Android 15 include un nuovo file di configurazione,
car_audio_fade_configuration.xml:- Questo file consente agli OEM di definire i criteri per l'applicazione del focus audio del sistema a un'app che perde il focus.
- Il framework audio applica la dissolvenza e il silenziamento solo se l'app che perde il focus corrisponde alle regole definite dall'OEM in questo file XML.
- In questo modo, gli OEM possono personalizzare il comportamento della funzionalità in base alle caratteristiche dell'app o ai tipi di utilizzo audio.
Controllo delle funzionalità con RRO: è stato introdotto un nuovo flag funzionalità di runtime resource overlay (RRO),
audioUseFadeManagerConfiguration, per attivare o disattivare questa funzionalità:- La funzionalità è disattivata per impostazione predefinita.
- Per attivare la perdita del focus audio applicata dal sistema, gli OEM devono impostare questo flag su
true. - Sebbene il framework audio dell'auto si aspetti definizioni di configurazione di dissolvenza valide quando il flag è attivato, l'assenza di tali definizioni non comporta automaticamente un'eccezione irreversibile.
- Tutte le app delle configurazioni di dissolvenza devono avere definizioni di dissolvenza corrispondenti. È un errore irreversibile chiamare una configurazione di dissolvenza (per nome) come parte della configurazione audio dell'auto senza fornire una definizione valida.
- Quando il flag è disattivato, tutte le definizioni di configurazione di dissolvenza e tutti i riferimenti di configurazione vengono ignorati.
Configurazione di Fade Manager
Il framework audio di Android 15 introduce un FadeManagerConfiguration unificato per fornire agli OEM un controllo granulare sul comportamento di dissolvenza audio. Questo framework è illustrato nella Figura 3:
Figura 3. Configurazione di Fade Manager.
Questa configurazione include:
- Proprietà della transizione con dissolvenza: impostazioni per la dissolvenza in uscita e la dissolvenza in entrata.
- Può essere definito con attributi o utilizzi audio specifici.
- Consente impostazioni di durata personalizzate.
- Queste impostazioni vengono utilizzate per creare
VolumeShaper.Configuration.
- Policy di dissolvenza: regole che regolano quando si verifica la dissolvenza.
- Un'opzione globale per attivare o disattivare la dissolvenza.
- Un elenco configurabile di utilizzi audio dissolvenza (idonei alla dissolvenza in caso di perdita del focus).
- Gli elenchi di esclusione (non dissolvenza) impediscono la dissolvenza delle sorgenti audio critiche o designate. Questi elenchi possono essere basati su:
- Tipi di contenuti
- Attributi audio
- UID app (può essere impostato solo durante il runtime)
Configurazioni OEM
In questa sezione esamineremo le personalizzazioni OEM disponibili.
File XML di configurazione della dissolvenza audio dell'auto
Android 15 introduce un nuovo file di configurazione, car_audio_fade_configuration.xml, che consente un'ampia personalizzazione OEM del comportamento di dissolvenza audio durante la perdita del focus.
- Questo file XML consente la definizione di più configurazioni di dissolvenza distinte, ognuna delle quali richiede un nome univoco per i riferimenti incrociati all'interno di
car_audio_configuration.xml. - Queste configurazioni possono essere applicate in modo flessibile a diverse zone audio e configurazioni di zona.
- In particolare, ogni configurazione di dissolvenza accetta solo valori di durata in
millisecondi, che il sistema utilizza per generare internamente il
corrispondente
VolumeShaper.Configuration.
Per indicazioni pratiche sull'implementazione, consulta le configurazioni di esempio fornite per l'emulatore all'indirizzo device/generic/car/emulator/audio/car_audio_fade_configuration.xml.
File XML di configurazione audio dell'auto
Android 15 introduce un file car_audio_configuration.xml aggiornato, ora alla versione 4, che incorpora i nuovi tag applyFadeConfigs e fadeConfig.
Il tag applyFadeConfigs può contenere più definizioni fadeConfig, consentendo una configurazione di dissolvenza flessibile. Ogni definizione:
- Deve includere un
fadeConfigpredefinito designato conisDefault = true. - Può includere diverse definizioni
fadeConfigtransitorie. Queste configurazioni transitorie vengono applicate in modo specifico durante le interazioni di perdita del focus audio e solo quando l'app che acquisisce il focus audio corrisponde ai criteri definiti nella configurazione transitoria.
Per indicazioni pratiche sull'implementazione, consulta le configurazioni di esempio fornite per l'emulatore all'indirizzo device/generic/car/emulator/audio/car_audio_configuration.xml.
Estensione del servizio di focus audio OEM
Gli OEM che implementano un servizio di focus audio per auto personalizzato hanno la flessibilità di configurare le impostazioni di dissolvenza audio includendole in OemCarAudioFocusResult.
Questa operazione può essere eseguita utilizzando il metodo di creazione setAudioAttributesToCarAudioFadeConfigurationMap():
/** @see OemCarAudioFocusResult#getAudioAttributesToCarAudioFadeConfigurationMap() **/
@NonNull
public Builder setAudioAttributesToCarAudioFadeConfigurationMap(@NonNull
Map<AudioAttributes, CarAudioFadeConfiguration> attrsToCarAudioFadeConfig) {
}
In particolare, gli OEM possono scegliere di utilizzare le impostazioni di dissolvenza preconfigurate all'avvio o applicare dinamicamente le configurazioni tramite il proprio servizio di focus audio personalizzato, offrendo un controllo adattabile.
Diagramma di sequenza
Questo diagramma di sequenza illustra il comportamento dopo la concessione del focus audio a App2 e la successiva perdita del focus audio da parte di App1:
- Quando il servizio audio dell'auto invia la perdita del focus audio a
App1, la riproduzione dal playerApp1subisce una dissolvenza come definita dalleFadeManagerConfigurationattive. Al termine dell'operazione di dissolvenza,App1riceve il callback standard di perdita del focus audio. - Facoltativamente, l'audio di
App1può essere ripristinato dopo una durata configurabile. Gli OEM hanno la flessibilità di impostare questa durata tramiteBuilder#setFadeInDurationForUsage(int, long)in base ai requisiti specifici del prodotto.
Figura 4. Diagramma di sequenza per la funzionalità di dissolvenza audio dell'auto.
Gestione del focus multi-zona
Per i veicoli con più zone audio, il focus audio viene gestito in modo indipendente per ogni zona. Pertanto, una richiesta a una zona non tiene conto di ciò che mantiene il focus in altre zone, né fa sì che i titolari del focus in altre zone perdano il focus. In questo modo, il focus dell'abitacolo principale può essere gestito separatamente da un sistema di intrattenimento per i sedili posteriori, evitando così di interrompere la riproduzione audio in una zona a causa delle modifiche apportate al focus in un'altra.
Per tutte le app, CarAudioService gestisce automaticamente il focus. La zona audio di una richiesta di focus è determinata dal relativo UserId o UID
(per maggiori dettagli, vedi Routing audio multi-zona).
Richiedere audio da più zone contemporaneamente
Se un'app vuole riprodurre audio in più zone contemporaneamente, deve richiedere il focus per ogni zona includendo AUDIOFOCUS_EXTRA_REQUEST_ZONE_ID nel bundle:
//Create attribute with bundle and AUDIOFOCUS_EXTRA_REQUEST_ZONE_ID
Bundle bundle = new Bundle();
bundle.putInt(CarAudioManager.AUDIOFOCUS_EXTRA_REQUEST_ZONE_ID,
zoneId);
AudioAttributes attributesWithZone = new AudioAttributes.Builder()
.setUsage(AudioAttributes.USAGE_MEDIA)
.addBundle(bundle)
.build();
//Create focus request using built attributesWithZone
Questo parametro del bundle consente al richiedente di ignorare i mapping automatici delle zone audio per utilizzare invece l'ID zona specificato. Pertanto, un'app potrebbe inviare richieste separate per zone audio diverse.
Focus audio HAL
A partire da Android 11, l'HAL è abilitato a richiedere il focus per conto di stream esterni. Sebbene sia facoltativo, l'utilizzo di queste API è vivamente consigliato per consentire ai suoni esterni di partecipare in modo ottimale all'ecosistema Android e per offrire un'esperienza utente fluida.
L'HAL prende la decisione finale su quali suoni devono avere la priorità. A questo proposito, i suoni di emergenza e critici per la sicurezza devono essere riprodotti indipendentemente dal fatto che all'HAL venga concesso o meno il focus audio e devono continuare a essere riprodotti in modo appropriato anche se l'HAL perde il focus audio. Lo stesso vale per tutti i suoni richiesti dalle normative statali.
L'HAL deve disattivare in modo proattivo l'audio degli stream Android in modo appropriato durante la riproduzione di suoni di emergenza o critici per la sicurezza per assicurarsi che vengano ascoltati chiaramente.
AudioControl@2.0
La versione 2.0 di AudioControl HAL introduce queste nuove API:
| API | Finalità |
|---|---|
IAudioControl#registerFocusListener |
Registra un'istanza di IFocusListener con il
AudioControl HAL. Questo listener consente all'HAL di richiedere e abbandonare il focus audio
focus. L'HAL fornisce un'istanza ICloseHandle da utilizzare da
Android per annullare la registrazione del listener. |
IAudioControl#onAudioFocusChange |
Notifica all'HAL le modifiche dello stato delle richieste di focus effettuate dall'HAL
tramite IFocusListener, incluse le risposte alle richieste di focus iniziali. |
IFocusListener#requestAudioFocus |
Richiede il focus per conto dell'HAL per un utilizzo, un ID zona, e un tipo di guadagno del focus specificati. |
IFocusListener#abandonAudioFocus |
Abbandona le richieste di focus HAL esistenti per l'utilizzo e l'ID zona specificati. |
L'HAL può avere più richieste di focus contemporaneamente, ma è limitato a una richiesta per ogni coppia di utilizzo e ID zona. Android presuppone che l'HAL inizi immediatamente a riprodurre i suoni per un utilizzo una volta effettuata una richiesta e continui a farlo finché non abbandona il focus.
A parte registerFocusListener, queste richieste sono oneway per garantire che Android non ritardi l'HAL durante l'elaborazione di una richiesta di focus. L'HAL non deve attendere di ottenere il focus prima di riprodurre i suoni critici per la sicurezza. È facoltativo per l'HAL ascoltare e rispondere alle modifiche del focus audio tramite IAudioControl#onAudioFocusChange.
Servizio di focus audio per auto OEM
In Android 14, AAOS ha introdotto i servizi di plug-in OEM per auto per consentire la configurabilità di alcuni componenti dell'auto. Per il servizio di plug-in audio per auto, il servizio di plug-in consente agli OEM di gestire le richieste di focus intercettate dal servizio audio dell'auto. In questo modo, gli OEM hanno maggiore flessibilità nella gestione del focus in base alle regole e alle normative. Pertanto, l'interazione del focus audio può variare da produttore a produttore e da regione a regione. La premessa di base per il focus audio rimane valida: le app devono comunque richiedere il focus per una migliore gestione dell'audio al fine di migliorare l'esperienza utente. In generale, alcune regole si applicano ancora alla richiesta di focus audio da parte delle app:
Senza alcuna priorità, le app di focus audio ad alta priorità (inclusi una telefonata, un avviso di emergenza o una notifica di sicurezza) devono essere in grado di ottenere il focus audio in modo transitorio o permanente.
Mentre è attivo un focus multimediale:
Le app che richiedono il focus di utilizzo delle chiamate devono essere in grado di ricevere la chiamata contemporaneamente o in modo esclusivo.
Le app che richiedono il focus di utilizzo della navigazione devono essere in grado di ricevere il focus di navigazione contemporaneamente o in modo esclusivo.
Le app che richiedono il focus di utilizzo dell'assistente devono essere in grado di ricevere il focus di utilizzo contemporaneamente o in modo esclusivo.
Mentre le app di focus audio ad alta priorità (inclusi una telefonata, un avviso di emergenza o una notifica di sicurezza) sono attive, qualsiasi richiesta di focus audio ritardata in entrata deve essere concessa o ritardata in base alle esigenze.
Sebbene questi suggerimenti non siano esaustivi, possono aiutare le app che richiedono il focus a ottenerlo se non esistono suoni attivi ad alta priorità. Anche quando i suoni ad alta priorità sono attivi, le richieste di focus ritardate devono comunque essere rispettate e devono essere in grado di ottenere il focus quando il suono ad alta priorità si interrompe.