Prima di avviare uno stream logico, un'app richiede lo stato attivo audio utilizzando lo stesso gli attributi audio usati per lo stream logico. L'app deve rispettare la concentrazione in modo da funzionare come previsto nei casi d'uso del settore auto e motori.
Sebbene sia consigliato inviare una richiesta di impostazione dello stato attivo, questa non viene applicata in modo forzato dal sistema. Pertanto, considera l'attenzione come mezzo per controllare indirettamente ed evitare conflitti durante la riproduzione invece che come meccanismo principale di controllo dell'audio. Il veicolo non deve dipendere dal sistema di messa a fuoco per il funzionamento del sottosistema audio.
Concentrati sulle interazioni
Per supportare AAOS, le richieste di messa a fuoco audio vengono gestite in base a
interazioni tra il CarAudioContext
della richiesta e quello dell'attuale
i principali elementi. Esistono tre tipi di interazioni:
- Esclusiva
- Rifiuta
- Simultanea
Interazione esclusiva
Questo è il modello di interazione più utilizzato con Android.
Nelle interazioni esclusive, può essere attivata una sola app alla volta.
Di conseguenza, a una richiesta di stato attivo in entrata viene concesso lo stato attivo mentre quello esistente
il titolare perde la concentrazione. Dato che entrambe le app riproducono contenuti multimediali, è consentita una sola app di conservazione
il focus. Di conseguenza, la richiesta di impostazione dello stato attivo dell'app appena avviata viene restituita
AUDIOFOCUS_REQUEST_GRANTED
mentre l'app sta riproducendo musica riceve un
evento di variazione dello stato attivo con uno stato di perdita corrispondente al tipo di richiesta
che è stato creato.
Rifiuta interazione
Con le interazioni rifiutate, la richiesta in entrata viene sempre rifiutata. Per
ad esempio quando si cerca di riprodurre musica mentre è in corso una chiamata. In questo
caso, se Telefono mantiene lo stato attivo dell'audio per una chiamata e se una seconda app richiede lo stato attivo
per ascoltare musica, l'app Music riceve AUDIOFOCUS_REQUEST_FAILED
in risposta
alla richiesta. Poiché la richiesta di impostazione dello stato attivo viene rifiutata, non viene inviata alcuna perdita di messa a fuoco.
all'attuale blocco attivo.
Interazione simultanea
Univoco di AAOS è un'interazione contemporanea. In questo modo, le app che richiedono audio di mettere a fuoco nell'auto la possibilità di mantenere lo stato attivo in concomitanza con altre app. Per un si verifichi un'interazione simultanea, devono essere soddisfatte le seguenti condizioni. La:
La richiesta di messa a fuoco in arrivo deve richiedere AudioManager.AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK
Il blocco dello stato attivo corrente non setPauseWhenDucked(true)
L'attuale titolare dello stato attivo sceglie di non ricevere eventi anatra
Se questi criteri sono soddisfatti, la richiesta di messa a fuoco restituisce con
AUDIOFOCUS_REQUEST_GRANTED
mentre l'attuale titolare dello stato attivo non ha modifiche
il focus. Tuttavia, se il titolare attuale dello stato attivo sceglie di ricevere eventi duck o di
pausa quando viene abbassato, il titolare corrente perde lo stato attivo, come accade con un
per un'interazione esclusiva.
Gestione di flussi simultanei
Sebbene l'interazione simultanea abbia numerosi utilizzi,
a livello di hardware su tutti i dispositivi di output. Ti consigliamo vivamente di
I dispositivi CarAudioContext
a cui è consentito giocare contemporaneamente devono essere indirizzati a
diversi dispositivi di output.
Poiché ha dispositivi di output separati per gli stream simultanei, l'HAL in modo da ridurre il rumore in uno degli stream prima di mischiarli o per instradare gli stream fisici. ai diversi altoparlanti del veicolo. Se i flussi logici sono mescolati all'interno Android, i guadagni non vengono modificati e vengono forniti come parte dello stesso flusso fisico.
Ad esempio, quando la navigazione e i contenuti multimediali vengono pubblicati contemporaneamente, il guadagno per lo stream multimediale potrebbe essere temporaneamente ridotto (o "attenuato") in modo che le istruzioni di navigazione possono essere ascoltate in modo più chiaro. In alternativa, la navigazione lo stream può essere indirizzato agli altoparlanti lato conducente mentre i contenuti multimediali giocano per il resto della baita.
Matrice di interazione
La tabella seguente mostra la matrice dell'interazione come definita da CarAudioService
.
Ogni riga rappresenta il CarAudioContext
del titolare attuale dello stato attivo e ogni
rappresenta quella della richiesta in entrata.
Ad esempio, quando un'app di contenuti multimediali di musica mantiene lo stato attivo mentre un'app di navigazione richiede lo stato attivo la matrice indica che le due interazioni possono giocare contemporaneamente, assumendo che gli altri criteri le interazioni simultanee.
A causa delle interazioni simultanee, è possibile avere più di una supporto del focus. In questo caso, una richiesta di messa a fuoco in entrata viene confrontata con gli attuali titolari dell'elemento attivo prima di determinare quale interazione applicare. In questo caso, vince l'interazione più conservativa. Rifiuta, quindi esclusivo e alla fine simultanei.
Figura 1. Matrice di interazione con messa a fuoco audio.
Navigazione durante le telefonate
In Android 11, è stata introdotta una nuova impostazione utente per consentire agli utenti di modificare
comportamento di interazione tra navigazione e telefonate. Una volta impostato,
android.car.KEY_AUDIO_FOCUS_NAVIGATION_REJECTED_DURING_CALL
cambia la
interazione tra le richieste di stato attivo di NAVIGATION
in arrivo e l'attuale CALL
i titolari degli elementi in evidenza da simultanei a rifiuti. Se un utente preferisce
le istruzioni di navigazione non interrompono una chiamata, possono attivare l'impostazione. Questo
sia persistente per l'utente e può essere impostato in modo dinamico in modo che
le richieste rispettino la nuova impostazione.
Focus audio ritardabile
In Android 11, AAOS ha aggiunto il supporto per la richiesta di focus audio ritardabile. Questo consente di ritardare le richieste di messa a fuoco non temporanee quando la loro interazione gli attuali titolari degli elementi in primo piano li comporterebbero normalmente respinti. Una volta una modifica dello stato attivo porta a uno stato in cui la richiesta ritardata può diventare attiva, la richiesta viene accolta.
Regole per le richieste di messa a fuoco audio ritardata
Solo richieste non temporanee. Una richiesta ritardata può essere effettuata solo per sorgenti non transitorie per evitare la riproduzione di suoni temporanei a lungo. dopo che è pertinente.
È possibile ritardare una sola richiesta alla volta. Se una richiesta ritardabile viene mentre esiste già una richiesta in ritardo, la richiesta originale in ritardo riceve un evento di modifica
AUDIOFOCUS_LOSS
e la nuova richiesta riceve un risposta sincrona diAUDIOFOCUS_REQUEST_DELAYED
.Le richieste ritardate devono avere un
OnAudioFocusChangeListener
Una volta che un viene ritardata, il listener viene utilizzato per informare il richiedente quando alla fine viene concessa (AUDIOFOCUS_GAIN
) o viene rifiutata in un secondo momento (AUDIOFOCUS_LOSS
).
Richiedi focus ritardabile
Per creare una richiesta che può subire ritardi:
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 dello stato attivo gestisce le modifiche in stato attivo:
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
Gestione multizona
Per i veicoli con più zone audio, il focus audio viene gestito in modo indipendente per ogni zona. Di conseguenza, una richiesta a una zona non prende in considerazione mantiene il focus in altre zone né fa sì che i contenitori di focus in altre zone perde la concentrazione. In questo modo, l'attenzione della cabina principale può essere gestita separatamente sistema di intrattenimento sul sedile posteriore, senza interrompere la riproduzione audio una zona in base alle modifiche apportate in base a un'altra.
Per tutte le app, l'CarAudioService
gestisce automaticamente lo stato attivo. Un obiettivo
la zona audio della richiesta viene determinata in base al valore UserId
o UID
associato
(per maggiori dettagli, vedi Routing audio).
Richiedi audio da più zone contemporaneamente
Se un'app vuole riprodurre audio in più zone contemporaneamente, deve richiedere
per ogni zona includendo AUDIOFOCUS_EXTRA_REQUEST_ZONE_ID
nell'
gruppo:
//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 bundle consente al richiedente di ignorare la zona audio automatica per utilizzare l'ID zona specificato. Di conseguenza, un'app potrebbe presentare richieste separate per le diverse zone audio.
Focus audio HAL
A partire da Android 11, l'HAL è abilitato per richiedere lo stato attivo per conto di per i flussi di dati esterni. Sebbene facoltativo, l'uso 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 sta determinando la priorità dei suoni. A questo punto, i suoni critici per le emergenze e la sicurezza devono essere riprodotti indipendentemente che indica se all'HAL viene concesso o meno il focus audio e deve continuare venga riprodotta in modo appropriato anche se l'HAL perde il focus audio. Lo stesso vale per suoni richiesti dalle normative governative.
L'HAL dovrebbe disattivare proattivamente l'audio degli stream Android in base alle esigenze durante la riproduzione suoni critici per la sicurezza o di emergenza per garantire un ascolto chiaro.
Controllo audio@2.0
La versione 2.0 di AudioControl HAL introduce queste nuove API:
API | Finalità |
---|---|
IAudioControl#registerFocusListener |
Registra un'istanza di IFocusListener con
Controllo audio HAL. Questo listener consente all'HAL di richiedere e abbandonare l'audio
il focus. L'HAl fornisce un'istanza ICloseHandle che può essere utilizzata
Android per annullare la registrazione del listener. |
IAudioControl#onAudioFocusChange |
Informa l'HAL delle modifiche di stato per focalizzare le richieste effettuate dall'HAL
tramite IFocusListener , incluse le risposte alle richieste iniziali
richieste di focus. |
IFocusListener#requestAudioFocus
| Le richieste sono incentrate sull'HAL per un utilizzo specifico, ID zona, e tipo di guadagno della concentrazione. |
IFocusListener#abandonAudioFocus |
Abbandona le richieste di focus HAL esistenti per l'utilizzo e la zona specificati ID. |
L'HAL può avere più richieste di stato attivo contemporaneamente, ma è limitato a una richiesta in base all'utilizzo e accoppiamento di ID di zona. Android presuppone che l'HAL venga utilizzato immediatamente inizia a riprodurre suoni per un utilizzo dopo che è stata fatta una richiesta e continua a fallo finché non viene abbandonato lo stato attivo.
Oltre a registerFocusListener
, queste richieste sono oneway
per garantire che
Android non ritarda l'HAL durante l'elaborazione di una richiesta di impostazione dello stato attivo. L'HAL deve
non aspettare per concentrarti prima di riprodurre suoni critici per la sicurezza. È facoltativo
affinché l'HAL ascolti e risponda ai cambiamenti della messa a fuoco audio tramite
IAudioControl#onAudioFocusChange
.
Servizio di messa a fuoco audio auto OEM
In Android 14, AAOS ha introdotto i servizi di plug-in OEM per auto per consentire Configurabilità per alcuni componenti dell'auto. Per Car Audio Plugin Service, il plug-in consente agli OEM di gestire le richieste di messa a fuoco intercettate dall'audio dell'auto completamente gestito di Google Cloud. Questo offre agli OEM una maggiore flessibilità nella gestione dell'attenzione in base alle esigenze. da regole e normative. Di conseguenza, l'interazione con il focus audio può variare produttori di Google e da regione a regione. Premessa di base per il focus audio è ancora valida, le app devono comunque richiedere attenzione per migliorare la gestione per migliorare l'esperienza utente. In generale, alcune regole continuano a essere valide richiesta di priorità per app:
Senza messa a fuoco audio ad alta priorità in piedi (inclusa una telefonata, per gli avvisi di emergenza o le notifiche di sicurezza) devono poter rilevare sia in modo temporaneo che permanente.
Mentre è attivo un elemento multimediale:
Le app che richiedono l'utilizzo delle chiamate devono poter ricevere la chiamata contemporaneamente o in modo esclusivo.
Le app che richiedono l'uso della navigazione devono poter ricevere la navigazione contemporaneamente o in modo esclusivo.
Le app che richiedono l'utilizzo dell'assistente devono poter ricevere questa priorità contemporaneamente o in modo esclusivo.
Mentre sei in piedi con audio di alta priorità (inclusa una telefonata, avvisi di emergenza o notifiche di sicurezza) siano attive, qualsiasi la richiesta di focus audio ritardato deve essere accolta o ritardata in base alle esigenze.
Sebbene i suggerimenti sopra riportati non siano esaustivi, possono aiutare le app a richiedere focus per ottenere la messa a fuoco se non sono presenti suoni attivi ad alta priorità. Anche quando il livello i suoni prioritari sono attivi, le richieste di messa a fuoco ritardate devono comunque essere rispettate e dovrebbero riuscire a concentrarsi quando si interrompe il suono ad alta priorità.