Focus audio

Prima di avviare uno stream logico, un'app richiede l'attenzione audio utilizzando gli stessi attributi audio utilizzati per lo stream logico. L'app deve rispettare le perdite di attenzione per funzionare come previsto nei casi d'uso nel settore auto e motori.

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

Interazioni con lo stato attivo

Per supportare AAOS, le richieste di attenzione audio vengono gestite in base a interazioni predefinite tra il CarAudioContext della richiesta e quello dei detentori dell'attenzione attuali. Esistono tre tipi di interazioni:

  • Esclusiva
  • Rifiuta
  • Contemporaneamente

Interazione esclusiva

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

Nelle interazioni esclusive, solo un'app può avere il focus alla volta. Pertanto, a una richiesta di messa a fuoco in arrivo viene concessa la messa a fuoco, mentre il detentore della messa a fuoco esistente perde la messa a fuoco. Poiché entrambe le app riproducono contenuti multimediali, solo una può avere il controllo. Di conseguenza, la richiesta di attenzione dell'app appena avviata viene restituita conAUDIOFOCUS_REQUEST_GRANTED, mentre l'app che sta attualmente riproducendo musica riceve un evento di modifica dell'attenzione con uno stato di perdita corrispondente al tipo di richiesta effettuata.

Rifiutare l'interazione

Con le interazioni reject, la richiesta in arrivo viene sempre rifiutata. Ad esempio, quando provi a riprodurre musica durante una chiamata in corso. In questo caso, se Telefono ha lo stato attivo per una chiamata e una seconda app richiede lo stato attivo per riprodurre musica, l'app di musica riceve AUDIOFOCUS_REQUEST_FAILED in risposta alla richiesta. Poiché la richiesta di attenzione viene rifiutata, non viene inviata alcuna perdita di attenzione al detentore corrente dell'attenzione.

Interazione simultanea

Un'interazione contemporanea è un'interazione unica di AAOS. In questo modo, le app che richiedono il controllo audio nell'auto possono mantenere il controllo contemporaneamente ad altre app. Affinché si verifichi un'interazione simultanea, devono essere soddisfatte le seguenti condizioni. La

Se questi criteri sono soddisfatti, la richiesta di attenzione viene restituita con AUDIOFOCUS_REQUEST_GRANTED, mentre l'attuale detentore dell'attenzione non subisce alcuna variazione. Tuttavia, se l'elemento che ha lo stato attivo corrente sceglie di ricevere eventi duck o di mettere in pausa quando è in modalità duck, perde lo stato attivo, come accade con un'interazione esclusiva.

Gestione di stream simultanei

Sebbene l'interazione simultanea abbia numerosi utilizzi, fai attenzione al mixing e al ducking a livello hardware sui dispositivi di output. Consigliamo vivamente di indirizzare i CarAudioContextconsentiti per la riproduzione contemporanea a diversi dispositivi di output.

Avere dispositivi di output separati per gli stream simultanei consente all'HAL di disattivare uno degli stream prima di combinarli o di instradare gli stream fisici a diversi altoparlanti del veicolo. Se gli stream logici vengono combinati all'interno di Android, i guadagni rimangono invariati e vengono trasmessi nell'ambito dello stesso stream fisico.

Ad esempio, quando la navigazione e i contenuti multimediali vengono riprodotti contemporaneamente, l'amplificazione per lo stream multimediale potrebbe essere ridotta temporaneamente (o attenuata) in modo da poter sentire più chiaramente le istruzioni di navigazione. In alternativa, lo stream di navigazione potrebbe essere indirizzato agli altoparlanti lato conducente mentre i contenuti multimediali continuano a essere riprodotti nel resto dell'abitacolo.

Matrice di interazione

La tabella seguente mostra la matrice di interazione come definita da CarAudioService. Ogni riga rappresenta il CarAudioContext dell'attuale detentore dell'attenzione e ogni colonna rappresenta quello della richiesta in arrivo.

Ad esempio, quando un'app di contenuti multimediali musicali ha il focus mentre un'app di navigazione richiede il focus, la matrice indica che le due interazioni possono essere riprodotte contemporaneamente, assumendo che gli altri criteri per le interazioni simultanee siano soddisfatti.

A causa delle interazioni simultanee, è possibile avere più di un detentore dell'attenzione. In questo caso, una richiesta di messa a fuoco in entrata viene confrontata con ciascuno dei detentori dell'attuale stato attivo prima di determinare quale interazione applicare. In questo caso, vince l'interazione più conservativa. Rifiuta, poi esclusivo e infine simultaneo.

Figura 1. Matrice di interazione con il focus audio.

In Android 11 è stata introdotta una nuova impostazione utente per consentire agli utenti di modificare il comportamento di interazione tra navigazione e chiamate. Se impostato, android.car.KEY_AUDIO_FOCUS_NAVIGATION_REJECTED_DURING_CALL modifica l'Interaction tra le richieste di stato attivo NAVIGATION in arrivo e i detentori dello stato attivo CALL attuali da simultanea a rifiuta. Se un utente preferisce che le istruzioni di navigazione non interrompano una chiamata, può attivare l'impostazione. Questo valore rimane costante per l'utente e può essere impostato in modo dinamico in modo che le richieste di messa a fuoco successive rispettino la nuova impostazione.

Messa in primo piano audio posticipabile

In Android 11, AAOS ha aggiunto il supporto per la richiesta dell'attenzione audio posticipabile. In questo modo, le richieste di attivazione non transitorie possono essere ritardate quando la loro interazione con i detentori dell'attuale stato attivo normalmente ne comporterebbe il rifiuto. Una volta che un cambio di stato dell'attenzione genera uno stato in cui la richiesta in ritardo può acquisire l'attenzione, la richiesta viene concessa.

Regole per le richieste di messa a fuoco audio ritardate

  • Solo richieste non transitorie. Una richiesta in ritardo può essere effettuata solo per fonti non transitorie, per evitare che un suono transitorio venga riprodotto molto tempo dopo che è stato rilevato.

  • È possibile ritardare una sola richiesta alla volta. Se viene fatta una richiesta ritardabile quando è 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, l'ascoltatore viene utilizzato per notificare al richiedente quando la richiesta viene finalmente concessa (AUDIOFOCUS_GAIN) o se viene rifiutata in un secondo momento (AUDIOFOCUS_LOSS).

Richiedi messa a fuoco posticipabile

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 è in ritardo, l'ascoltatore dell'attenzione gestisce le modifiche dell'attenzione:

    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 dell'attenzione multizona

Per i veicoli con più zone audio, l'attenzione audio viene gestita in modo indipendente per ogni zona. Di conseguenza, una richiesta in una zona non tiene conto di ciò che ha il controllo in altre zone né fa perdere il controllo ai detentori del controllo in altre zone. In questo modo, lo stato attivo 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 di modifiche apportate in un'altra.

Per tutte le app, CarAudioService gestisce automaticamente lo stato attivo. La zona audio di una richiesta di attenzione è determinata dal relativo UserId o UID associato (per maggiori dettagli, vedi Instradamento audio multizona).

Richiedere l'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 all'autore della richiesta di ignorare le mappature automatiche delle zone audio per utilizzare l'ID zona specificato. Di conseguenza, un'app potrebbe emettere richieste separate per zone audio diverse.

Messa a fuoco audio HAL

A partire da Android 11, l'HAL è abilitato a richiedere lo stato attivo per conto di stream esterni. Sebbene facoltativo, l'utilizzo di queste API è vivamente consigliato per consentire ai suoni esterni di essere componenti ottimali dell'ecosistema Android e per offrire un'esperienza utente fluida.

L'HAL prende la decisione finale su quali suoni devono avere la priorità. In questo senso, gli avvisi di emergenza e di sicurezza critici devono essere riprodotti indipendentemente dal fatto che all'HAL sia stato concesso o meno l'audio focus e devono continuare a essere riprodotti come appropriato anche se l'HAL perde l'audio focus. Lo stesso vale per qualsiasi suono richiesto dalle normative governative.

L'HAL deve disattivare in modo proattivo gli stream di Android, se opportuno, durante la riproduzione di suoni di emergenza o di sicurezza per garantire che vengano ascoltati chiaramente.

AudioControl@2.0

La versione 2.0 dell'HAL AudioControl introduce queste nuove API:

API Finalità
IAudioControl#registerFocusListener Registra un'istanza di IFocusListener con l'HAL AudioControl. Questo ascoltatore consente all'HAL di richiedere e abbandonare l'attenzione audio. L'HAL fornisce un'istanza ICloseHandle da utilizzare da parte di Android per annullare la registrazione dell'ascoltatore.
IAudioControl#onAudioFocusChange Invia una notifica all'HAL delle modifiche dello stato delle richieste di messa a fuoco effettuate dall'HAL tramite IFocusListener, incluse le risposte alle richieste di messa a fuoco iniziali.
IFocusListener#requestAudioFocus Richiede il fuoco per conto dell'HAL per un utilizzo, un ID zona e un tipo di guadagno del fuoco specificati.
IFocusListener#abandonAudioFocus Abbandona le richieste di attenzione HAL esistenti per l'utilizzo e l'ID zona specificati.

L'HAL può avere più richieste di messa a fuoco contemporaneamente, ma è limitato a una richiesta per accoppiamento di utilizzo e ID zona. Android presuppone che l'HAL inizi immediatamente a riprodurre i suoni per un utilizzo dopo che è stata effettuata una richiesta e continui a farlo finché non perde lo stato attivo.

A parte registerFocusListener, queste richieste sono oneway per garantire che Android non ritardi l'HAL durante l'elaborazione di una richiesta di messa a fuoco. L'HAL non deve non attendere di acquisire lo stato attivo prima di riprodurre suoni critici per la sicurezza. È facoltativo per l'HAL ascoltare e rispondere alle modifiche dell'attenzione audio tramite IAudioControl#onAudioFocusChange.

Servizio di attivazione dell'audio dell'auto OEM

In Android 14, AAOS ha introdotto i servizi plug-in OEM per auto per abilitare la configurabilità di alcuni componenti dell'auto. Per il servizio di plug-in per l'impianto audio dell'auto, il servizio di plug-in consente agli OEM di gestire le richieste di messa a fuoco intercettate dal servizio di impianto audio dell'auto. Ciò offre agli OEM una maggiore flessibilità in termini di gestione dell'attenzione in base alle regole e ai regolamenti. Di conseguenza, l'interazione con l'audio potrebbe variare in base al produttore e alla regione. La premessa di base per l'attenzione audio rimane valida: le app devono comunque richiedere l'attenzione per una gestione migliore dell'audio al fine di migliorare l'esperienza utente. In generale, per la richiesta di attenzione audio da parte delle app valgono ancora alcune regole:

  • In assenza di un audio focus di priorità elevata (inclusa una chiamata, un avviso di emergenza o una notifica di sicurezza), le app dovrebbero essere in grado di acquisire l'audio focus in modo temporaneo o permanente.

  • Quando è attivo un'opzione di messa a fuoco dei contenuti multimediali:

    • Le app che richiedono l'attenzione per l'utilizzo delle chiamate devono essere in grado di ricevere la chiamata contemporaneamente o in modo esclusivo.

    • Le app che richiedono l'attenzione per l'utilizzo della navigazione devono essere in grado di ricevere l'attenzione per la navigazione contemporaneamente o esclusivamente.

    • Le app che richiedono l'attenzione per l'utilizzo dell'assistente devono essere in grado di ricevere l'attenzione per l'utilizzo contemporaneamente o esclusivamente.

  • Quando sono attive app con attenzione audio ad alta priorità (inclusa una telefonata, un avviso di emergenza o una notifica di sicurezza), qualsiasi richiesta di attenzione audio in ritardo in arrivo deve essere concessa o ritardata in base alle esigenze.

Sebbene i suggerimenti riportati sopra non siano esaustivi, possono aiutare le app che richiedono il silenzio attivo a ottenerlo se non esistono suoni ad alta priorità attivi. Anche quando sono attivi suoni con priorità elevata, le richieste di messa a fuoco ritardata devono essere rispettate e devono essere in grado di acquisire il controllo quando il suono con priorità elevata si interrompe.