Focus audio

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

Sebbene l'invio di una richiesta di messa a fuoco sia consigliato, non è imposto dal sistema. Pertanto, considera la messa a fuoco 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 messa a fuoco per il funzionamento del sottosistema audio.

Interazioni di messa a fuoco

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

  • Esclusiva
  • Rifiuta
  • Simultaneo

Interazione esclusiva

Si tratta del modello di interazione più comunemente utilizzato con Android.

Nelle interazioni esclusive, è consentito che una sola app mantenga lo stato attivo alla volta. Pertanto, a una richiesta di messa a fuoco in entrata viene concessa la messa a fuoco, mentre il titolare della messa a fuoco esistente la perde. Poiché entrambe le app riproducono contenuti multimediali, solo una può mantenere lo stato attivo. Di conseguenza, la richiesta di messa a fuoco dell'app appena avviata viene restituita con AUDIOFOCUS_REQUEST_GRANTED, mentre l'app di musica in riproduzione corrente riceve un evento di cambio di messa a fuoco con uno stato di perdita corrispondente al tipo di richiesta effettuata.

Rifiuta interazione

Con le interazioni reject, la richiesta in entrata viene sempre rifiutata. Ad esempio, quando tenti di riprodurre musica mentre è in corso una chiamata. In questo caso, se il dialer mantiene lo stato attivo audio 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 messa a fuoco viene rifiutata, non viene inviata alcuna perdita di messa a fuoco al titolare della messa a fuoco corrente.

Interazione simultanea

Le interazioni simultanee sono esclusive di AAOS. In questo modo, le app che richiedono la messa a fuoco dell'audio nell'auto possono mantenere la messa a fuoco contemporaneamente ad altre app. Affinché si verifichi un'interazione simultanea, devono essere soddisfatte le seguenti condizioni. La funzione

Se questi criteri vengono soddisfatti, la richiesta di messa a fuoco viene restituita con AUDIOFOCUS_REQUEST_GRANTED, mentre il titolare della messa a fuoco corrente non subisce modifiche alla messa a fuoco. Tuttavia, se l'attuale titolare dello stato attivo sceglie di ricevere eventi di ducking o di mettere in pausa quando viene eseguito il ducking, l'attuale titolare dello stato attivo perde lo stato attivo, 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 indirizzare le istanze di CarAudioContext che possono essere riprodotte contemporaneamente a dispositivi di output diversi.

Disponendo di dispositivi di output separati per gli stream simultanei, l'HAL può abbassare il volume di uno degli stream prima di mixarli o indirizzare gli stream fisici a diversi altoparlanti del veicolo. Se i flussi logici vengono mixati in Android, i guadagni rimangono invariati e vengono forniti come parte dello stesso flusso fisico.

Ad esempio, quando la navigazione e i contenuti multimediali vengono riprodotti contemporaneamente, il guadagno del flusso multimediale potrebbe essere temporaneamente ridotto (o abbassato) in modo che le istruzioni di navigazione possano essere ascoltate più chiaramente. In alternativa, il flusso di navigazione potrebbe essere indirizzato 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 attuale del focus e ogni colonna quello della richiesta in arrivo.

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

A causa delle interazioni simultanee, è possibile avere più di un titolare del focus. In questo caso, una richiesta di messa a fuoco in entrata viene confrontata con ciascuno dei titolari della messa a fuoco attuali prima di determinare quale interazione applicare. In questo caso, vince l'interazione più conservativa. Rifiuto, poi esclusivo e infine simultaneo.

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 la navigazione e le chiamate. Se impostato, android.car.KEY_AUDIO_FOCUS_NAVIGATION_REJECTED_DURING_CALL modifica l'interazione tra le richieste di messa a fuoco NAVIGATION in arrivo e i titolari della messa a fuoco CALL correnti da concurrent a rejects. Se un utente preferisce che le istruzioni di navigazione non interrompano una chiamata, può attivare l'impostazione. Questo viene mantenuto per l'utente e può essere impostato in modo dinamico in modo che le successive richieste di messa a fuoco rispettino la nuova impostazione.

Focus audio ritardabile

In Android 11, AAOS ha aggiunto il supporto per la richiesta di messa a fuoco audio ritardabile. In questo modo, le richieste di messa a fuoco non temporanee possono essere ritardate quando la loro interazione con i titolari della messa a fuoco corrente comporterebbe normalmente il loro rifiuto. Quando un cambio di focus porta a uno stato in cui la richiesta ritardata può acquisire il focus, la richiesta viene concessa.

Regole per le richieste di messa a fuoco audio ritardata

  • Solo richieste non temporanee. Una richiesta ritardata può essere effettuata solo per fonti non temporanee per evitare che un suono temporaneo venga riprodotto a lungo dopo che non è più pertinente.

  • È possibile posticipare 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 AUDIOFOCUS_REQUEST_DELAYED.

  • Le richieste rinviabili devono avere OnAudioFocusChangeListener. Dopo che una richiesta viene ritardata, il listener viene utilizzato per notificare al richiedente quando la richiesta viene alla fine concessa (AUDIOFOCUS_GAIN) o se viene rifiutata in un secondo momento (AUDIOFOCUS_LOSS).

Richiedi lo stato attivo 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 listener di messa a fuoco gestisce le modifiche della messa a fuoco:

    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 forzata dal sistema

Android 15 introduce l'audio in dissolvenza forzato dal sistema in AAOS. In Android, l'audio focus non viene applicato dal sistema. Pertanto, anche se gli sviluppatori di app sono incoraggiati a rispettare le linee guida per la messa a fuoco audio, se un'app continua a riprodurre audio ad alto volume anche dopo aver perso la messa a fuoco audio, il sistema non può impedirlo.

In ambienti automobilistici critici per la sicurezza, il rispetto della messa a fuoco dell'audio è fondamentale per ridurre al minimo le distrazioni del conducente. Con questa funzionalità, il framework audio ora attenua automaticamente le app che perdono la messa a fuoco audio, per un'esperienza audio più controllata e prevedibile.

Questo miglioramento contribuisce a garantire che le app rispettino la decisione relativa alla perdita dello stato attivo audio come definito 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 di messa a fuoco nelle auto:

Progettazione di alto livello per la funzionalità di dissolvenza forzata dal sistema

Figura 2. Progettazione di alto livello per la funzionalità di dissolvenza forzata dal sistema.

  • Dissolvenza mirata:l'applicazione di sistema della dissolvenza in Android 15 è progettata specificamente per le situazioni in cui un'app perde la messa a fuoco audio, ma continua a riprodurre l'audio.
  • Meccanismo di dissolvenza:quando un'app perde lo stato attivo audio a favore di una nuova app richiedente:
    • Il framework audio attenua automaticamente l'audio dell'app che perde.
    • Dopo la dissolvenza in uscita, il flusso audio viene silenziato dal sistema.
    • L'app riceve quindi una notifica di perdita della messa a fuoco audio.
    • Le app che non si comportano correttamente vengono silenziate finché non riacquistano lo stato attivo dell'audio.
    • La logica predefinita prevede la visualizzazione graduale delle app che sono state attenuate dopo 2 secondi. Tuttavia, gli OEM possono configurarlo su qualsiasi valore di timeout.
    • Il framework audio utilizza le configurazioni OEM sia per le operazioni di dissolvenza in uscita che 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 dell'imposizione della messa a fuoco audio del sistema a un'app che perde la messa a fuoco.
    • Il framework audio applica l'attenuazione e la disattivazione dell'audio solo se l'app perdente 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 dell'audio.

  • Controllo delle funzionalità con RRO: è stato introdotto un nuovo flag di funzionalità di overlay delle risorse di runtime (RRO), audioUseFadeManagerConfiguration, per attivare o disattivare questa funzionalità:

    • La funzionalità è disattivata per impostazione predefinita.
    • Per attivare la perdita di messa a fuoco dell'audio imposta dal sistema, gli OEM devono impostare questo flag su true.
    • Sebbene il framework audio per auto preveda definizioni di configurazione di dissolvenza valide quando il flag è abilitato, 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 richiamare una configurazione di dissolvenza (per nome) come parte della configurazione dell'audio dell'auto senza fornire una definizione valida.
    • Quando il flag è disattivato, tutte le definizioni di configurazione di dissolvenza e tutti i riferimenti alla 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 dell'audio. Questo framework è illustrato nella Figura 3:

Configurazione di Fade Manager

Figura 3. Configurazione di Fade Manager.

Questa configurazione include:

  • Proprietà della transizione dissolvenza:impostazioni per la dissolvenza in uscita e in entrata.
    • Può essere definito con utilizzi o attributi audio specifici.
    • Consente impostazioni di durata personalizzate.
    • Queste impostazioni vengono utilizzate per creare VolumeShaper.Configuration.
  • Norme di dissolvenza:regole che disciplinano quando si verifica la dissolvenza.
    • Un pulsante di attivazione/disattivazione globale per abilitare o disabilitare l'attenuazione.
    • Un elenco configurabile di utilizzi audio che possono essere attenuati (idonei all'attenuazione quando perdono la messa a fuoco).
    • Gli elenchi di esclusione (non dissolvibili) impediscono la dissolvenza delle sorgenti audio critiche o designate. Questi elenchi possono essere basati su:
      • Tipi di contenuti
      • Attributi audio
      • UID app (possono essere impostati solo durante l'esecuzione)

Configurazioni OEM

In questa sezione esaminiamo le personalizzazioni OEM disponibili.

File XML di configurazione del dissolvenza audio dell'automobile

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 di messa a fuoco.

  • Questo file XML consente la definizione di più configurazioni di dissolvenza distinte, ognuna delle quali richiede un nome univoco per il riferimento incrociato 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 poi per generare internamente la VolumeShaper.Configuration corrispondente.

Per indicazioni pratiche sull'implementazione, consulta le configurazioni di esempio fornite per l'emulatore disponibile all'indirizzo device/generic/car/emulator/audio/car_audio_fade_configuration.xml.

File XML di configurazione dell'audio dell'automobile

Android 15 introduce un file car_audio_configuration.xml aggiornato, ora alla versione 4, che incorpora nuovi tag applyFadeConfigs e fadeConfig. Il tag applyFadeConfigs può contenere più definizioni fadeConfig, consentendo una configurazione della dissolvenza flessibile. Ogni definizione:

  • Deve includere un fadeConfig predefinito indicato con isDefault = true.
  • Può includere diverse definizioni di fadeConfig temporanee. Queste configurazioni temporanee vengono applicate in modo specifico durante le interazioni di perdita della messa a fuoco audio e solo quando l'app che acquisisce la messa a fuoco audio corrisponde ai criteri definiti all'interno della configurazione temporanea.

Per indicazioni pratiche sull'implementazione, consulta le configurazioni di esempio fornite per l'emulatore disponibile all'indirizzo device/generic/car/emulator/audio/car_audio_configuration.xml.

Estensione del servizio di messa a fuoco audio OEM

I produttori OEM che implementano un servizio di messa a fuoco audio personalizzato per l'auto hanno la flessibilità di configurare le impostazioni di dissolvenza audio includendole in OemCarAudioFocusResult. Ciò può essere ottenuto 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 impostazioni di dissolvenza all'avvio preconfigurate o applicare dinamicamente le configurazioni tramite il proprio servizio di messa a fuoco audio personalizzato, offrendo un controllo adattabile.

Diagramma di sequenza

Questo diagramma di sequenza illustra il comportamento dopo la concessione della messa a fuoco audio a App2 e la successiva perdita della messa a fuoco audio da parte di App1:

  • Quando il servizio audio dell'auto invia la perdita di messa a fuoco audio a App1, la riproduzione dal player App1 subisce un dissolvenza in uscita definita da FadeManagerConfiguration attivi. Una volta completata l'operazione di dissolvenza in uscita, App1 riceve il callback standard di perdita della messa a fuoco audio.
  • Se vuoi, l'audio di App1 può essere ripristinato dopo un periodo di tempo configurabile. Gli OEM hanno la flessibilità di impostare questa durata tramite Builder#setFadeInDurationForUsage(int, long) in base ai requisiti specifici del prodotto.

Diagramma di sequenza per la funzionalità di dissolvenza dell&#39;audio dell&#39;auto

Figura 4. Diagramma di sequenza per la funzionalità di dissolvenza dell'audio dell'auto.

Gestione della messa a fuoco multizona

Per i veicoli con più zone audio, la messa a fuoco dell'audio viene gestita in modo indipendente per ogni zona. Pertanto, una richiesta a una zona non tiene conto di ciò che mantiene lo stato attivo in altre zone, né fa sì che i titolari dello stato attivo in altre zone perdano lo stato attivo. In questo modo, la messa a fuoco dell'abitacolo principale può essere gestita separatamente da un sistema di intrattenimento per i sedili posteriori, in modo da non interrompere la riproduzione audio in una zona a causa delle modifiche apportate alla messa a fuoco in un'altra.

Per tutte le app, CarAudioService gestisce automaticamente lo stato attivo. La zona audio di una richiesta di messa a fuoco è determinata dal relativo UserId o UID associato (per maggiori dettagli, vedi Routing 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 al richiedente di ignorare le mappature automatiche delle zone audio per utilizzare invece l'ID zona specificato. Pertanto, un'app potrebbe emettere richieste separate per zone audio diverse.

Focus audio HAL

A partire da Android 11, l'HAL è abilitato a richiedere la messa a fuoco per conto di stream esterni. Sebbene 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 determina in modo definitivo a quali suoni deve essere data la priorità. A questo scopo, i suoni critici per l'emergenza e la sicurezza devono essere riprodotti indipendentemente dal fatto che l'HAL abbia o meno l'audio in primo piano e devono continuare a essere riprodotti in modo appropriato anche se l'HAL perde l'audio in primo piano. Lo stesso vale per qualsiasi suono richiesto dai regolamenti governativi.

L'HAL deve disattivare proattivamente 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 le seguenti nuove API:

API Finalità
IAudioControl#registerFocusListener Registra un'istanza di IFocusListener con AudioControl HAL. Questo listener consente all'HAL di richiedere e abbandonare la messa a fuoco dell'audio. 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 messa a fuoco effettuate dall'HAL tramite IFocusListener, incluse le risposte alle richieste di messa a fuoco iniziali.
IFocusListener#requestAudioFocus Le richieste si concentrano per conto dell'HAL su un utilizzo, un ID zona e un tipo di guadagno di messa a fuoco specificati.
IFocusListener#abandonAudioFocus Abbandona le richieste di messa a fuoco 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 ogni accoppiamento di ID utilizzo e zona. Android presuppone che l'HAL inizi immediatamente a riprodurre suoni per un utilizzo una volta effettuata una richiesta e continui a farlo finché non abbandona 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 attendere di acquisire la messa a fuoco prima di riprodurre suoni critici per la sicurezza. È facoltativo per l'HAL ascoltare e rispondere alle modifiche dello stato attivo audio tramite IAudioControl#onAudioFocusChange.

Servizio di focus audio per autoradio 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 Car Audio Plugin Service, il servizio plugin consente agli OEM di gestire le richieste di messa a fuoco intercettate dal servizio audio dell'auto. In questo modo, gli OEM hanno maggiore flessibilità nella gestione della messa a fuoco come richiesto da regole e normative. Pertanto, l'interazione con la messa a fuoco audio può variare in base al produttore e alla regione. Il presupposto di base per la messa a fuoco dell'audio è ancora valido: le app devono comunque richiedere la messa a fuoco per una migliore gestione dell'audio per migliorare l'esperienza utente. In generale, alcune regole si applicano ancora alla richiesta di messa a fuoco dell'audio da parte delle app:

  • Senza alcuna priorità elevata permanente per l'audio (inclusa una chiamata, un avviso di emergenza o una notifica di sicurezza), le app devono essere in grado di ottenere la priorità per l'audio in modo temporaneo o permanente.

  • Mentre è attivo un focus sui contenuti multimediali:

    • Le app che richiedono l'utilizzo della funzionalità di chiamata devono essere in grado di ricevere la chiamata contemporaneamente o in esclusiva.

    • Le app che richiedono la messa a fuoco dell'utilizzo della navigazione devono essere in grado di ricevere la messa a fuoco della navigazione contemporaneamente o in esclusiva.

    • Le app che richiedono l'utilizzo dell'assistente devono essere in grado di ricevere l'utilizzo in modo simultaneo o esclusivo.

  • Mentre le app con priorità audio elevata (inclusa una chiamata, un avviso di emergenza o una notifica di sicurezza) sono attive, qualsiasi richiesta di priorità audio ritardata in arrivo deve essere concessa o ritardata in base alle necessità.

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