Focus audio

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:

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.

Matrice di interazione con messa a fuoco audio

Figura 1. Matrice di interazione con messa a fuoco audio.

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 di AUDIOFOCUS_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:

  1. 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();

  2. 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;
}

  3. 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à.