Focus audio

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

Sebbene sia consigliabile inviare una richiesta di focus, non è applicata dal sistema. Pertanto, considera il focus 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 focus per il funzionamento del sottosistema audio.

Interazioni di focus

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

  • Esclusiva
  • Rifiuta
  • Simultanea

Interazione esclusiva

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

Nelle interazioni esclusive, è consentito a una sola app di mantenere il focus alla volta. Pertanto, a una richiesta di focus in entrata viene concesso il focus mentre il titolare del focus esistente lo perde. Poiché entrambe le app riproducono contenuti multimediali, è consentito a una sola app di mantenere il focus. Di conseguenza, la richiesta di focus dell'app appena avviata viene restituita con AUDIOFOCUS_REQUEST_GRANTED, mentre l'app di riproduzione musicale corrente riceve un evento di modifica del focus con uno stato di perdita che corrisponde al tipo di richiesta effettuata.

Interazione di rifiuto

Con le interazioni di rifiuto, la richiesta in entrata viene sempre rifiutata. Ad esempio, quando si tenta di riprodurre musica durante una chiamata. In questo caso, se l'app Telefono 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 di focus viene rifiutata, non viene inviata alcuna perdita di focus al titolare del focus corrente.

Interazione simultanea

Le interazioni simultanee sono esclusive di AAOS. In questo modo, le app che richiedono il focus audio in auto possono mantenere il focus 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 focus viene restituita con AUDIOFOCUS_REQUEST_GRANTED, mentre il focus del titolare del focus corrente non cambia. Tuttavia, se il titolare del focus corrente sceglie di ricevere eventi di ducking o di mettere in pausa quando viene eseguito il ducking, il titolare del focus corrente perde il focus, 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 instradare le istanze di CarAudioContext che possono essere riprodotte contemporaneamente a dispositivi di output diversi.

Se disponi di dispositivi di output separati per gli stream simultanei, l'HAL può eseguire il ducking di uno degli stream prima di mixarli o instradare gli stream fisici a altoparlanti diversi nel veicolo. Se gli stream logici vengono mixati in Android, i guadagni non vengono modificati e vengono forniti come parte dello stesso stream fisico.

Ad esempio, quando la navigazione e i contenuti multimediali vengono forniti contemporaneamente, il guadagno per lo stream multimediale potrebbe essere temporaneamente ridotto (o ducked) in modo che le indicazioni stradali possano essere ascoltate più chiaramente. In alternativa, lo stream di navigazione potrebbe essere instradato 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 del focus corrente e ogni colonna rappresenta quello della richiesta in entrata.

Ad esempio, quando un'app di contenuti multimediali musicali mantiene il focus mentre un'app di navigazione richiede il focus, la matrice indica che le due interazioni possono essere riprodotte contemporaneamente, presupponendo 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 focus in entrata viene confrontata con ciascuno dei titolari del focus correnti prima di determinare l'interazione da applicare. In questo caso, vince l'interazione più conservativa. Rifiuta, poi esclusiva e infine simultanea.

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 telefonate. Se impostato, android.car.KEY_AUDIO_FOCUS_NAVIGATION_REJECTED_DURING_CALL modifica l' interazione tra le richieste di focus in entrata NAVIGATION e i titolari del focus correnti CALL da simultanea a rifiuta. Se un utente preferisce che le indicazioni stradali non interrompano una chiamata, può attivare l'impostazione. Questa impostazione viene mantenuta per l'utente e può essere impostata dinamicamente in modo che le richieste di focus successive rispettino la nuova impostazione.

Focus audio ritardabile

In Android 11, AAOS ha aggiunto il supporto per la richiesta di focus audio ritardabile. In questo modo, le richieste di focus non transitorie possono essere ritardate quando la loro interazione con i titolari del focus correnti comporterebbe normalmente il rifiuto. Una volta che una modifica del focus comporta 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 le 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 AUDIOFOCUS_REQUEST_DELAYED.

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

Richiedere il 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 listener del focus gestisce le modifiche del 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
    

Dissolvenza applicata dal sistema

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

Negli ambienti automobilistici critici per la sicurezza, il rispetto del focus audio è fondamentale per ridurre al minimo la distrazione del conducente. Con questa funzionalità, il framework audio ora esegue automaticamente la dissolvenza delle app che perdono il focus audio, per un'esperienza audio più controllata e prevedibile.

Questo miglioramento contribuisce a garantire che le app rispettino la decisione di perdita del focus audio definita 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 del focus 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 applicata dal sistema.

  • Dissolvenza mirata: l'applicazione della dissolvenza da parte del sistema in Android 15 è progettata specificamente per le situazioni in cui un'app perde il focus audio ma continua a riprodurre audio.
  • Meccanismo di dissolvenza: quando un'app perde il focus audio a favore di una nuova app richiedente:
    • Il framework audio esegue automaticamente la dissolvenza dell'audio dell'app che perde il focus.
    • Dopo la dissolvenza, lo stream audio viene silenziato dal sistema.
    • L'app riceve quindi una notifica di perdita del focus audio.
    • Le app che non si comportano correttamente vengono silenziate finché non riacquistano il focus audio.
    • La logica predefinita prevede la dissolvenza delle app dopo 2 secondi. Tuttavia, gli OEM possono configurare questo valore di timeout.
    • Il framework audio utilizza le configurazioni OEM sia per le operazioni di dissolvenza che per quelle di dissolvenza 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 del focus audio del sistema a un'app che perde il focus.
    • Il framework audio applica la dissolvenza e il silenziamento solo se l'app che perde il focus 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 audio.
  • Controllo delle funzionalità con RRO: è stato introdotto un nuovo flag funzionalità di runtime resource overlay (RRO), audioUseFadeManagerConfiguration, per attivare o disattivare questa funzionalità:

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

Configurazione di Fade Manager

Figura 3. Configurazione di Fade Manager.

Questa configurazione include:

  • Proprietà della transizione con dissolvenza: impostazioni per la dissolvenza in uscita e la dissolvenza in entrata.
    • Può essere definito con attributi o utilizzi audio specifici.
    • Consente impostazioni di durata personalizzate.
    • Queste impostazioni vengono utilizzate per creare VolumeShaper.Configuration.
  • Policy di dissolvenza: regole che regolano quando si verifica la dissolvenza.
    • Un'opzione globale per attivare o disattivare la dissolvenza.
    • Un elenco configurabile di utilizzi audio dissolvenza (idonei alla dissolvenza in caso di perdita del focus).
    • Gli elenchi di esclusione (non dissolvenza) impediscono la dissolvenza delle sorgenti audio critiche o designate. Questi elenchi possono essere basati su:
      • Tipi di contenuti
      • Attributi audio
      • UID app (può essere impostato solo durante il runtime)

Configurazioni OEM

In questa sezione esamineremo le personalizzazioni OEM disponibili.

File XML di configurazione della dissolvenza audio dell'auto

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 del focus.

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

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

File XML di configurazione audio dell'auto

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

  • Deve includere un fadeConfig predefinito designato con isDefault = true.
  • Può includere diverse definizioni fadeConfig transitorie. Queste configurazioni transitorie vengono applicate in modo specifico durante le interazioni di perdita del focus audio e solo quando l'app che acquisisce il focus audio corrisponde ai criteri definiti nella configurazione transitoria.

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

Estensione del servizio di focus audio OEM

Gli OEM che implementano un servizio di focus audio per auto personalizzato hanno la flessibilità di configurare le impostazioni di dissolvenza audio includendole in OemCarAudioFocusResult. Questa operazione può essere eseguita 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 le impostazioni di dissolvenza preconfigurate all'avvio o applicare dinamicamente le configurazioni tramite il proprio servizio di focus audio personalizzato, offrendo un controllo adattabile.

Diagramma di sequenza

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

  • Quando il servizio audio dell'auto invia la perdita del focus audio a App1, la riproduzione dal player App1 subisce una dissolvenza come definita dalle FadeManagerConfiguration attive. Al termine dell'operazione di dissolvenza, App1 riceve il callback standard di perdita del focus audio.
  • Facoltativamente, l'audio di App1 può essere ripristinato dopo una durata 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 audio dell'auto.

Gestione del focus multi-zona

Per i veicoli con più zone audio, il focus audio viene gestito in modo indipendente per ogni zona. Pertanto, una richiesta a una zona non tiene conto di ciò che mantiene il focus in altre zone, né fa sì che i titolari del focus in altre zone perdano il focus. In questo modo, il focus 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 delle modifiche apportate al focus in un'altra.

Per tutte le app, CarAudioService gestisce automaticamente il focus. La zona audio di una richiesta di focus è determinata dal relativo UserId o UID (per maggiori dettagli, vedi Routing audio multi-zona).

Richiedere 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 i mapping automatici delle zone audio per utilizzare invece l'ID zona specificato. Pertanto, un'app potrebbe inviare richieste separate per zone audio diverse.

Focus audio HAL

A partire da Android 11, l'HAL è abilitato a richiedere il focus per conto di stream esterni. Sebbene sia 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 prende la decisione finale su quali suoni devono avere la priorità. A questo proposito, i suoni di emergenza e critici per la sicurezza devono essere riprodotti indipendentemente dal fatto che all'HAL venga concesso o meno il focus audio e devono 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 statali.

L'HAL deve disattivare in modo proattivo l'audio degli stream Android in modo appropriato durante la riproduzione di suoni di emergenza o critici per la sicurezza per assicurarsi che vengano ascoltati chiaramente.

AudioControl@2.0

La versione 2.0 di AudioControl HAL introduce queste nuove API:

API Finalità
IAudioControl#registerFocusListener Registra un'istanza di IFocusListener con il AudioControl HAL. Questo listener consente all'HAL di richiedere e abbandonare il focus audio focus. 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 focus effettuate dall'HAL tramite IFocusListener, incluse le risposte alle richieste di focus iniziali.
IFocusListener#requestAudioFocus Richiede il focus 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 zona specificati.

L'HAL può avere più richieste di focus contemporaneamente, ma è limitato a una richiesta per ogni coppia di utilizzo e ID zona. Android presuppone che l'HAL inizi immediatamente a riprodurre i suoni per un utilizzo una volta effettuata una richiesta e continui a farlo finché non abbandona il focus.

A parte registerFocusListener, queste richieste sono oneway per garantire che Android non ritardi l'HAL durante l'elaborazione di una richiesta di focus. L'HAL non deve attendere di ottenere il focus prima di riprodurre i suoni critici per la sicurezza. È facoltativo per l'HAL ascoltare e rispondere alle modifiche del focus audio tramite IAudioControl#onAudioFocusChange.

Servizio di focus audio per auto 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 il servizio di plug-in audio per auto, il servizio di plug-in consente agli OEM di gestire le richieste di focus intercettate dal servizio audio dell'auto. In questo modo, gli OEM hanno maggiore flessibilità nella gestione del focus in base alle regole e alle normative. Pertanto, l'interazione del focus audio può variare da produttore a produttore e da regione a regione. La premessa di base per il focus audio rimane valida: le app devono comunque richiedere il focus per una migliore gestione dell'audio al fine di migliorare l'esperienza utente. In generale, alcune regole si applicano ancora alla richiesta di focus audio da parte delle app:

  • Senza alcuna priorità, le app di focus audio ad alta priorità (inclusi una telefonata, un avviso di emergenza o una notifica di sicurezza) devono essere in grado di ottenere il focus audio in modo transitorio o permanente.

  • Mentre è attivo un focus multimediale:

    • Le app che richiedono il focus di utilizzo delle chiamate devono essere in grado di ricevere la chiamata contemporaneamente o in modo esclusivo.

    • Le app che richiedono il focus di utilizzo della navigazione devono essere in grado di ricevere il focus di navigazione contemporaneamente o in modo esclusivo.

    • Le app che richiedono il focus di utilizzo dell'assistente devono essere in grado di ricevere il focus di utilizzo contemporaneamente o in modo esclusivo.

  • Mentre le app di focus audio ad alta priorità (inclusi una telefonata, un avviso di emergenza o una notifica di sicurezza) sono attive, qualsiasi richiesta di focus audio ritardata in entrata deve essere concessa o ritardata in base alle esigenze.

Sebbene questi suggerimenti non siano esaustivi, possono aiutare le app che richiedono il focus a ottenerlo se non esistono suoni attivi ad alta priorità. Anche quando i suoni ad alta priorità sono attivi, le richieste di focus ritardate devono comunque essere rispettate e devono essere in grado di ottenere il focus quando il suono ad alta priorità si interrompe.