Focus audio

Prima di avviare un flusso logico, un'app richiede il focus audio utilizzando gli stessi attributi audio utilizzati per il flusso logico. L'app deve rispettare le perdite di messa a fuoco per funzionare come previsto nei casi d'uso automobilistici.

Sebbene sia consigliato l'invio di una richiesta di focus, non viene imposto dal sistema. Pertanto, considera la messa a fuoco come un mezzo per controllare indirettamente ed evitare conflitti durante la riproduzione anziché come un meccanismo di controllo audio primario. Il veicolo non dovrebbe dipendere dal sistema focus per il funzionamento del sottosistema audio.

Focalizzare le interazioni

Per supportare AAOS, le richieste di focus audio vengono gestite in base a interazioni predefinite tra il CarAudioContext della richiesta e quello degli attuali titolari del focus. Esistono tre tipi di interazioni:

  • Esclusivo
  • Rifiutare
  • Concorrente

Interazione esclusiva

Questo è il modello di interazione più comunemente utilizzato con Android.

Nelle interazioni esclusive , solo un'app alla volta può mantenere lo stato attivo. Pertanto, a una richiesta di focus in arrivo viene concesso il focus mentre il detentore del focus esistente perde il focus. Poiché entrambe le app riproducono contenuti multimediali, solo un'app può mantenere lo stato attivo. Di conseguenza, la richiesta di focus dell'app appena avviata viene restituita con AUDIOFOCUS_REQUEST_GRANTED mentre l'app che sta attualmente riproducendo musica riceve un evento di modifica del focus con uno stato di perdita che corrisponde al tipo di richiesta effettuata.

Rifiuta l'interazione

Con le interazioni di rifiuto , la richiesta in arrivo viene sempre rifiutata. Ad esempio, quando si tenta di riprodurre musica mentre è in corso una chiamata. In questo caso, se il Dialer 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 del focus viene rifiutata, non viene inviata alcuna perdita di focus all'attuale detentore del focus.

Interazione simultanea

Uniche per AAOS sono le interazioni simultanee . Ciò offre alle app che richiedono la messa a fuoco audio nell'auto la possibilità di mantenere la messa a fuoco contemporaneamente ad altre app. Perché abbia luogo un'interazione simultanea, devono essere soddisfatte le seguenti condizioni. IL:

Se questi criteri vengono soddisfatti, la richiesta di focus ritorna con AUDIOFOCUS_REQUEST_GRANTED mentre il detentore del focus attuale non ha alcun cambiamento nel focus. Tuttavia, se l'attuale detentore del focus sceglie di ricevere eventi di abbassamento o di mettere in pausa quando viene abbassato, l'attuale detentore del focus perde il focus, come accade con un'interazione esclusiva.

Gestione di flussi simultanei

Sebbene l'interazione simultanea abbia numerosi usi, fai attenzione al mixaggio e al ducking a livello hardware tra i dispositivi di output. Consigliamo vivamente che i CarAudioContext che possono essere riprodotti contemporaneamente vengano instradati a dispositivi di output diversi.

Avendo dispositivi di output separati per flussi simultanei, ciò consente all'HAL di attenuare uno dei flussi prima di mescolarli o di instradare i flussi fisici a diversi altoparlanti nel veicolo. Se i flussi logici vengono mischiati all'interno di Android, i guadagni rimangono inalterati e forniti come parte dello stesso flusso fisico.

Ad esempio, quando la navigazione e i contenuti multimediali vengono forniti simultaneamente, il guadagno per il flusso multimediale potrebbe essere temporaneamente ridotto (o abbassato) in modo che le istruzioni di navigazione possano essere ascoltate più chiaramente. In alternativa, il flusso della navigazione potrebbe essere indirizzato agli altoparlanti del lato conducente mentre i contenuti multimediali continuano ad essere riprodotti nel resto dell’abitacolo.

Matrice di interazione

La tabella seguente mostra la matrice di interazione definita da CarAudioService . Ogni riga rappresenta il CarAudioContext del detentore del focus corrente e ogni colonna rappresenta quello della richiesta in entrata.

Ad esempio, quando un'app multimediale musicale mantiene il focus mentre un'app di navigazione richiede il focus, la matrice indica che le due interazioni possono essere riprodotte contemporaneamente, presupponendo che siano soddisfatti gli altri criteri per le interazioni simultanee .

A causa delle interazioni simultanee, è possibile avere più di un focus holder. In questo caso, una richiesta di focus in arrivo viene confrontata con ciascuno degli attuali detentori del focus prima di determinare quale interazione applicare. In questo caso vince l’interazione più conservativa. Rifiuto, poi esclusivo e infine concorrente.

Matrice di interazione del focus audio

Figura 1. Matrice di interazione del focus audio.

In Android 11 è stata introdotta una nuova impostazione utente per consentire agli utenti di modificare il comportamento di interazione tra navigazione e telefonate. Se impostato, android.car.KEY_AUDIO_FOCUS_NAVIGATION_REJECTED_DURING_CALL modifica l'interazione tra le richieste di focus NAVIGATION in arrivo e gli attuali detentori di focus CALL da simultanei a rifiutati . Se un utente preferisce che le istruzioni di navigazione non interrompano una chiamata, può abilitare l'impostazione. Questo è persistente per l'utente e può essere impostato dinamicamente in modo che le successive richieste di focus rispettino la nuova impostazione.

Messa a fuoco audio ritardabile

In Android 11, AAOS ha aggiunto il supporto per richiedere la messa a fuoco audio ritardabile . Ciò consente di ritardare le richieste di focus non transitorie quando la loro interazione con gli attuali detentori del focus normalmente comporterebbe il loro rifiuto. Una volta che la modifica del focus determina 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 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_LOSS e la nuova richiesta riceve una risposta sincrona di AUDIOFOCUS_REQUEST_DELAYED .

  • Le richieste ritardabili devono avere un OnAudioFocusChangeListener Una volta ritardata una richiesta, il listener viene utilizzato per notificare al richiedente quando la richiesta viene finalmente concessa ( AUDIOFOCUS_GAIN ) o se viene rifiutata successivamente ( AUDIOFOCUS_LOSS ).

Richiedi focus ritardabile

Per creare una richiesta che può essere ritardata:

  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 focus listener gestisce le modifiche al 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

Gestione della messa a fuoco multizona

Per i veicoli con più zone audio, la messa a fuoco audio viene gestita in modo indipendente per ciascuna zona. Pertanto, una richiesta a una zona non tiene conto di ciò che mantiene il focus in altre zone, né fa perdere il focus ai detentori del focus in altre zone. In questo modo, il focus dell'abitacolo principale può essere gestito separatamente dal sistema di intrattenimento dei sedili posteriori, senza interrompere la riproduzione audio in una zona a causa delle modifiche apportate al focus in un'altra.

Per tutte le app, CarAudioService gestisce automaticamente la messa a fuoco. La zona audio di una richiesta focus è determinata dal relativo UserId o UID associato (per i dettagli, vedere Routing audio ).

Richiedi audio da più zone contemporaneamente

Se un'app desidera riprodurre l'audio in più zone contemporaneamente, deve richiedere il focus per ciascuna 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 sovrascrivere le mappature automatiche delle zone audio per utilizzare invece l'ID di zona specificato. Pertanto, un'app potrebbe emettere richieste separate per diverse zone audio.

Messa a fuoco audio HAL

A partire da Android 11, l'HAL è abilitato a richiedere lo stato attivo per conto di flussi esterni. Anche se facoltativo, l'uso di queste API è fortemente incoraggiato per consentire ai suoni esterni di partecipare in modo ottimale all'ecosistema Android e per fornire un'esperienza utente fluida.

L'HAL prende la decisione finale su quali suoni dovrebbero avere la priorità. In questo senso, i suoni di emergenza e critici per la sicurezza dovrebbero essere riprodotti indipendentemente dal fatto che all'HAL sia concesso o meno il focus audio e dovrebbero 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 governative.

L'HAL dovrebbe disattivare in modo proattivo i flussi Android in modo appropriato durante la riproduzione di suoni di emergenza o critici per la sicurezza per garantire che vengano ascoltati chiaramente.

AudioControl@2.0

La versione 2.0 di AudioControl HAL introduce queste nuove API:

API Scopo
IAudioControl#registerFocusListener Registra un'istanza di IFocusListener con l'HAL AudioControl. Questo ascoltatore consente all'HAL di richiedere e abbandonare il focus audio. HAl fornisce un'istanza ICloseHandle che può essere utilizzata da Android per annullare la registrazione del listener.
IAudioControl#onAudioFocusChange Notifica all'HAL le modifiche allo stato per focalizzare le richieste effettuate dall'HAL tramite IFocusListener , incluse le risposte alle richieste di focus iniziali.
IFocusListener#requestAudioFocus Le richieste si concentrano 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 di zona specificati.

L'HAL può avere più richieste di focus contemporaneamente, ma è limitato a una richiesta per utilizzo e abbinamento con ID zona. Android presuppone che l'HAL inizi immediatamente a riprodurre suoni per un utilizzo una volta effettuata una richiesta e continua a farlo finché non abbandona lo stato attivo.

Oltre a registerFocusListener , queste richieste sono oneway per garantire che Android non ritardi l'HAL durante l'elaborazione di una richiesta di focus. L'HAL non dovrebbe aspettare di concentrarsi prima di riprodurre suoni critici per la sicurezza. È facoltativo che l'HAL ascolti e risponda alle modifiche nel focus audio tramite IAudioControl#onAudioFocusChange .

Servizio di messa a fuoco audio per auto OEM

In Android 14, AAOS ha introdotto i servizi plug-in OEM dell'auto per consentire la configurabilità di alcuni componenti dell'auto. Per il servizio plug-in audio per auto , il servizio plug-in consente agli OEM di gestire le richieste di focus intercettate dal servizio audio per auto. Ciò offre agli OEM una maggiore flessibilità in termini di gestione dell'attenzione come richiesto da norme e regolamenti. Pertanto, l'interazione del focus audio può differire tra i produttori e da una regione all'altra. Resta valida la premessa di base per la messa a fuoco dell'audio, ovvero che le app dovrebbero comunque richiedere la messa a fuoco per una migliore gestione dell'audio per migliorare l'esperienza dell'utente. In generale, alcune regole si applicano ancora alla richiesta di focus audio da parte delle app:

  • Senza alcuna messa a fuoco audio permanente e ad alta priorità (inclusa una telefonata, un avviso di emergenza o una notifica di sicurezza), le app dovrebbero essere in grado di ottenere la messa a fuoco audio in modo transitorio o permanente.

  • Mentre è attivo un focus mediatico:

    • Le app che richiedono il focus sull'utilizzo delle chiamate dovrebbero essere in grado di ricevere la chiamata contemporaneamente o esclusivamente.

    • Le app che richiedono il focus sull'utilizzo della navigazione dovrebbero essere in grado di ricevere il focus sulla navigazione contemporaneamente o esclusivamente.

    • Le app che richiedono il focus sull'utilizzo dell'assistente dovrebbero essere in grado di ricevere il focus sull'utilizzo contemporaneamente o esclusivamente.

  • Mentre sono attive le app di focus audio ad alta priorità (inclusa una telefonata, un avviso di emergenza o una notifica di sicurezza), qualsiasi richiesta di focus audio ritardato in arrivo deve essere concessa o ritardata secondo necessità.

Sebbene i suggerimenti sopra riportati non siano esaustivi, possono aiutare le app che richiedono la messa a fuoco a ottenere la messa a fuoco se non esistono suoni attivi ad alta priorità. Anche quando i suoni ad alta priorità sono attivi, le richieste di messa a fuoco ritardata dovrebbero comunque essere rispettate e dovrebbero essere in grado di ottenere la messa a fuoco quando il suono ad alta priorità si interrompe.