Audiofokus

Bevor eine App einen logischen Stream startet, fordert sie den Audiofokus mit denselben Audioattributen an, die auch für den logischen Stream verwendet werden. Die App muss den Fokusverlust berücksichtigen, damit sie in den Anwendungsfällen für die Automobilbranche wie erwartet funktioniert.

Das Senden einer Fokusanfrage wird zwar empfohlen, ist aber nicht vom System erzwungen. Daher solltest du den Fokus als Mittel zur indirekten Steuerung und Vermeidung von Konflikten während der Wiedergabe ansehen, nicht als primären Audiosteuerungsmechanismus. Das Fahrzeug sollte für den Betrieb des Audiosystems nicht vom Fokussystem abhängig sein.

Fokusinteraktionen

Zur Unterstützung von AAOS werden Anfragen für den Audiofokus basierend auf vordefinierten Interaktionen zwischen dem CarAudioContext der Anfrage und dem des aktuellen Fokusinhabers verarbeitet. Es gibt drei Arten von Interaktionen:

  • Exklusiv
  • Ablehnen
  • Gleichzeitig

Exklusive Interaktion

Dies ist das Interaktionsmodell, das bei Android am häufigsten verwendet wird.

Bei exklusiven Interaktionen darf nur eine App gleichzeitig den Fokus haben. Daher wird einer eingehenden Fokusanfrage der Fokus gewährt, während der aktuelle Fokusinhaber den Fokus verliert. Da beide Apps Medien abspielen, darf nur eine App den Fokus halten. Daher wird die Fokusanfrage der neu gestarteten App mit AUDIOFOCUS_REQUEST_GRANTED zurückgegeben, während die aktuell wiedergegebene Musik-App ein Ereignis zur Fokusänderung mit einem Verluststatus erhält, der der Art der Anfrage entspricht.

Interaktion ablehnen

Bei Interaktionen vom Typ Abgelehnt wird die eingehende Anfrage immer abgelehnt. Das kann beispielsweise passieren, wenn Sie versuchen, Musik abzuspielen, während ein Anruf läuft. Wenn in diesem Fall der Dialer den Audiofokus für einen Anruf hält und eine zweite App den Fokus anfordert, um Musik abzuspielen, erhält die Musik-App AUDIOFOCUS_REQUEST_FAILED als Antwort auf die Anfrage. Da die Fokusanfrage abgelehnt wird, wird dem aktuellen Fokusinhaber kein Fokusverlust gesendet.

Gleichzeitige Interaktion

Einzigartig für AAOS sind gleichzeitige Interaktionen. So können Apps, die den Audiofokus im Auto anfordern, den Fokus gleichzeitig mit anderen Apps beibehalten. Damit eine gleichzeitige Interaktion stattfinden kann, müssen die folgenden Bedingungen erfüllt sein. Die:

Wenn diese Kriterien erfüllt sind, wird die Fokusanfrage mit AUDIOFOCUS_REQUEST_GRANTED zurückgegeben, während sich der aktuelle Fokusinhaber nicht ändert. Wenn der aktuelle Fokusinhaber jedoch festlegt, dass er Duck-Ereignisse erhalten oder bei Ducking pausieren möchte, verliert er den Fokus, wie bei einer exklusiven Interaktion.

Gleichzeitige Streams verarbeiten

Die gleichzeitige Interaktion hat zwar zahlreiche Anwendungsfälle, aber beim Mischen und Ducking auf Hardwareebene über mehrere Ausgabegeräte hinweg ist Vorsicht geboten. Wir empfehlen dringend, Instanzen von CarAudioContext, die gleichzeitig wiedergegeben werden dürfen, an verschiedene Ausgabegeräte weiterzuleiten.

Da separate Ausgabegeräte für gleichzeitige Streams vorhanden sind, kann die HAL einen der Streams vor dem Mischen stummschalten oder die physischen Streams an verschiedene Lautsprecher im Fahrzeug weiterleiten. Wenn die logischen Streams innerhalb von Android gemischt werden, bleiben die Verstärkungen unverändert und werden als Teil desselben physischen Streams gesendet.

Wenn beispielsweise Navigation und Medien gleichzeitig übertragen werden, kann die Verstärkung für den Medienstream vorübergehend reduziert (oder unterdrückt) werden, damit Navigationsanweisungen besser zu hören sind. Alternativ kann der Navigationsstream an die Lautsprecher auf der Fahrerseite weitergeleitet werden, während Medien im Rest der Kabine weiter abgespielt werden.

Interaktionsmatrix

Diese Tabelle zeigt die Interaktionsmatrix gemäß CarAudioService. Jede Zeile steht für die CarAudioContext des aktuellen Fokusinhabers und jede Spalte für die der eingehenden Anfrage.

Wenn beispielsweise eine Musik-Media-App den Fokus hält, während eine Navigations-App den Fokus anfordert, gibt die Matrix an, dass die beiden Interaktionen gleichzeitig ausgeführt werden können, sofern die anderen Kriterien für gleichzeitige Interaktionen erfüllt sind.

Aufgrund der gleichzeitigen Interaktionen kann es mehr als einen Fokus haben. In diesem Fall wird eine eingehende Fokusanfrage mit allen aktuellen Fokushaltern verglichen, bevor entschieden wird, welche Interaktion angewendet werden soll. In diesem Fall gewinnt die konservativste Interaktion. „Abweisen“, dann „Exklusiv“ und schließlich „Parallel“.

Interaktionsmatrix für den Audiofokus

Abbildung 1: Interaktionsmatrix für den Audiofokus

In Android 11 wurde eine neue Nutzereinstellung eingeführt, mit der Nutzer das Interaktionsverhalten zwischen Navigation und Telefonanrufen ändern können. Wenn android.car.KEY_AUDIO_FOCUS_NAVIGATION_REJECTED_DURING_CALL festgelegt ist, ändert sich die Interaktion zwischen eingehenden NAVIGATION-Aufmerksamkeitsanfragen und aktuellen CALL-Inhabern der Aufmerksamkeit von gleichzeitig zu abgelehnt. Wenn ein Nutzer nicht möchte, dass Navigationsanweisungen einen Anruf unterbrechen, kann er die Einstellung aktivieren. Diese Einstellung wird für den Nutzer beibehalten und kann dynamisch festgelegt werden, damit nachfolgende Fokusanfragen die neue Einstellung berücksichtigen.

Verzögerbarer Audiofokus

In Android 11 wurde in AAOS die Unterstützung für die Anforderung des verzögerbaren Audiofokus hinzugefügt. So können nicht vorübergehende Fokusanfragen verzögert werden, wenn ihre Interaktion mit dem aktuellen Fokusinhaber normalerweise dazu führt, dass sie abgelehnt werden. Sobald eine Fokusänderung zu einem Status führt, in dem die verzögerte Anfrage den Fokus erhalten kann, wird die Anfrage gewährt.

Regeln für verzögerte Anfragen zum Audiofokus

  • Nur nicht vorübergehende Anfragen. Eine verzögerte Anfrage kann nur für nicht transiente Quellen gestellt werden, um zu vermeiden, dass ein transienter Ton lange nach seiner Relevanz wiedergegeben wird.

  • Es kann jeweils nur eine Anfrage verzögert werden. Wenn eine verzögerbare Anfrage gesendet wird, während bereits eine verzögerte Anfrage vorliegt, erhält die ursprüngliche verzögerte Anfrage ein AUDIOFOCUS_LOSS-Änderungsereignis und die neue Anfrage eine synchrone Antwort von AUDIOFOCUS_REQUEST_DELAYED.

  • Für verzögerbare Anfragen ist OnAudioFocusChangeListener erforderlich. Nachdem eine Anfrage verzögert wurde, wird der Listener verwendet, um den Anfragenden zu benachrichtigen, wenn die Anfrage schließlich gewährt (AUDIOFOCUS_GAIN) oder später abgelehnt (AUDIOFOCUS_LOSS) wird.

Fokus mit Verzögerung anfordern

So erstellen Sie eine Anfrage, die verzögert werden kann:

  1. AudioFocusRequest.Builder#setAcceptsDelayedFocusGain verwenden.

    mMediaWithDelayedFocusListener = new MediaWithDelayedFocusListener();
    
    mDelayedFocusRequest = new AudioFocusRequest
         .Builder(AudioManager.AUDIOFOCUS_GAIN)
         .setAudioAttributes(mMusicAudioAttrib)
         .setOnAudioFocusChangeListener(mMediaWithDelayedFocusListener)
         .setForceDucking(false)
         .setWillPauseWhenDucked(false)
         .setAcceptsDelayedFocusGain(true)
         .build();
    
  2. Verarbeite bei der Anfrage die AUDIOFOCUS_REQUEST_DELAYED-Antwort:

    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. Wenn die Anfrage verzögert wird, verarbeitet der Fokus-Listener Änderungen am Fokus:

    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
    

Vom System erzwungenes Ausblenden

Mit Android 15 wird in AAOS ein systemgestützter Audio-Ausblendeffekt eingeführt. Unter Android wird der Audiofokus nicht vom System erzwungen. App-Entwickler werden zwar dazu ermutigt, die Richtlinien für den Audiofokus einzuhalten, aber wenn eine App auch dann laut wiedergegeben wird, wenn der Audiofokus verloren gegangen ist, kann das System dies nicht verhindern.

In sicherheitskritischen Umgebungen im Automobilbereich ist die Einhaltung des Audiofokus entscheidend, um die Ablenkung des Fahrers zu minimieren. Mit dieser Funktion werden Apps, die den Audiofokus verlieren, jetzt automatisch vom Audio-Framework ausgeblendet. So wird die Audiowiedergabe besser gesteuert und vorhersehbar.

Diese Verbesserung trägt dazu bei, dass Apps die Entscheidung zum Verlust des Audiofokus gemäß der Interaktionsmatrix einhalten und Konflikte bei der Audiowiedergabe verhindert werden.

Grobkonzept

Die folgende Abbildung zeigt das allgemeine Design und die Unterstützung der Funktion für den Fokusverlust in den Autos:

Hochrangiges Design für die systemerzwungene Funktion „Ausblenden“

Abbildung 2: Hochrangiges Design für die systemerzwungene Funktion „Ausblenden“.

  • Ausgerichtetes Ausblenden:Die systemische Erzwingung des Ausblendens in Android 15 ist speziell für Situationen konzipiert, in denen eine App den Audiofokus verliert, aber weiterhin Audio abspielt.
  • Ausblendmechanismus:Wenn eine App den Audiofokus an eine neue anfragende App verliert, geschieht Folgendes:
    • Das Audio-Framework blendet das Audio der App, die die Priorität verliert, automatisch aus.
    • Nach dem Ausblenden wird der Audiostream vom System stummgeschaltet.
    • Die App erhält dann eine Benachrichtigung, dass der Audiofokus verloren gegangen ist.
    • Apps, die sich nicht ordnungsgemäß verhalten, werden stummgeschaltet, bis sie wieder den Audiofokus erhalten.
    • Standardmäßig werden die Apps eingeblendet und nach zwei Sekunden ausgeblendet. OEMs können dies jedoch auf einen beliebigen Zeitlimitwert konfigurieren.
    • Das Audio-Framework verwendet die OEM-Konfigurationen sowohl für das Ausblenden als auch für das Einblenden.
  • OEM-Konfigurationsdatei:Android 15 enthält eine neue Konfigurationsdatei, car_audio_fade_configuration.xml:

    • In dieser Datei können OEMs Kriterien festlegen, wann die Audiofokus-Erzwigung des Systems auf eine verlierende App angewendet wird.
    • Das Audio-Framework erzwingt das Ausblenden und Stummschalten nur, wenn die unterlegene App den vom OEM definierten Regeln in dieser XML-Datei entspricht.
    • So können OEMs das Verhalten der Funktion basierend auf App-Merkmalen oder Audionutzungsarten anpassen.
  • Funktionssteuerung mit RRO:Es wurde ein neues RRO-Flag (Runtime Resource Overlay) namens audioUseFadeManagerConfiguration eingeführt, mit dem diese Funktion aktiviert oder deaktiviert werden kann:

    • Die Funktion ist standardmäßig deaktiviert.
    • Wenn OEMs den systemerzwungenen Verlust des Audiofokus aktivieren möchten, müssen sie dieses Flag auf true setzen.
    • Das Car Audio Framework erwartet zwar gültige Definitionskonfigurationen für das Ein- und Ausblenden, wenn das Flag aktiviert ist, aber das Fehlen solcher Definitionen führt nicht automatisch zu einer fatalen Ausnahme.
    • Alle Apps von Ausblendungskonfigurationen müssen über übereinstimmende Ausblendungsdefinitionen verfügen. Es ist ein schwerwiegender Fehler, eine Abdunkelungskonfiguration (anhand ihres Namens) als Teil der Konfiguration der Autoaudioanlage aufzurufen, ohne eine gültige Definition anzugeben.
    • Wenn das Flag deaktiviert ist, werden alle Definitions- und Konfigurationsreferenzen für das Ausblenden ignoriert.

Konfiguration des Fade-Managers

Das Audio-Framework von Android 15 führt eine einheitliche FadeManagerConfiguration ein, mit der OEMs das Verhalten von Audio-Übergängen detaillierter steuern können. Dieses Framework ist in Abbildung 3 dargestellt:

Konfiguration des Fade-Managers

Abbildung 3: Konfiguration des Ausblendungsmanagers

Diese Konfiguration umfasst Folgendes:

  • Eigenschaften für den Übergang „Weich ausblenden“:Einstellungen für das Aus- und Einblenden.
    • Kann mit bestimmten Audionutzungen oder -attributen definiert werden.
    • Ermöglicht benutzerdefinierte Zeiteinstellungen.
    • Mit diesen Einstellungen wird VolumeShaper.Configuration erstellt.
  • Richtlinien für das Ausblenden:Regeln, die festlegen, wann das Ausblenden erfolgt.
    • Ein globaler Schalter, mit dem das Ein- und Ausblenden aktiviert oder deaktiviert werden kann.
    • Eine konfigurierbare Liste von Audionutzungen, die ausgeblendet werden können, wenn der Fokus verloren geht.
    • Mit Ausschlusslisten (nicht ausblendbar) wird verhindert, dass kritische oder ausgewählte Audioquellen ausgeblendet werden. Diese Listen können auf Folgendem basieren:
      • Inhaltstypen
      • Audioattribute
      • App-UIDs (können nur während der Laufzeit festgelegt werden)

OEM-Konfigurationen

In diesem Abschnitt werden die verfügbaren OEM-Anpassungen beschrieben.

XML-Datei für die Ausblendungskonfiguration der Auto-Audioanlage

In Android 15 wird die neue Konfigurationsdatei car_audio_fade_configuration.xml eingeführt, mit der OEMs das Verhalten des Ausblendens von Audio bei Verlust des Fokus umfassend anpassen können.

  • In dieser XML-Datei können mehrere verschiedene Überblendungskonfigurationen definiert werden, die jeweils einen eindeutigen Namen für den Verweis innerhalb von car_audio_configuration.xml erfordern.
  • Diese Konfigurationen können flexibel auf verschiedene Audiozonen und Zonenkonfigurationen angewendet werden.
  • Für jede Überblendungskonfiguration werden ausschließlich Dauerwerte in Millisekunden akzeptiert, die das System dann intern verwendet, um die entsprechenden VolumeShaper.Configuration zu generieren.

Eine praktische Anleitung zur Implementierung finden Sie in den Beispielkonfigurationen für den Emulator unter device/generic/car/emulator/audio/car_audio_fade_configuration.xml.

XML-Datei für die Konfiguration der Auto-Audioanlage

Android 15 führt eine aktualisierte car_audio_configuration.xml-Datei ein, die jetzt Version 4 hat und neue applyFadeConfigs- und fadeConfig-Tags enthält. Das applyFadeConfigs-Tag kann mehrere fadeConfig-Definitionen enthalten, was eine flexible Ausblendungskonfiguration ermöglicht. Für jede Definition gilt:

  • Muss eine Standard-fadeConfig mit isDefault = true enthalten.
  • Kann mehrere vorübergehende fadeConfig-Definitionen enthalten. Diese sitzungsspezifischen Konfigurationen werden speziell bei Interaktionen angewendet, bei denen der Audiofokus verloren geht. Außerdem gilt dies nur, wenn die App, die den Audiofokus erhält, den in der sitzungsspezifischen Konfiguration definierten Kriterien entspricht.

Eine praktische Anleitung zur Implementierung finden Sie in den Beispielkonfigurationen für den Emulator unter device/generic/car/emulator/audio/car_audio_configuration.xml.

Diensterweiterung für den Audiofokus des OEM

OEMs, die einen benutzerdefinierten Dienst für den Audiofokus im Auto implementieren, können die Einstellungen für den Audio-Einblendeffekt konfigurieren, indem sie sie in OemCarAudioFocusResult einbinden. Dazu können Sie die Builder-Methode setAudioAttributesToCarAudioFadeConfigurationMap() verwenden:

/** @see OemCarAudioFocusResult#getAudioAttributesToCarAudioFadeConfigurationMap() **/
@NonNull
public Builder setAudioAttributesToCarAudioFadeConfigurationMap(@NonNull
        Map<AudioAttributes, CarAudioFadeConfiguration> attrsToCarAudioFadeConfig) {
}

OEMs können entweder vorkonfigurierte Einstellungen für den Ausblendeffekt beim Starten verwenden oder Konfigurationen dynamisch über ihren benutzerdefinierten Dienst für den Audiofokus anwenden, um eine anpassbare Steuerung zu ermöglichen.

Sequenzdiagramm

Dieses Sequenzdiagramm veranschaulicht das Verhalten nach der Gewährung des Audiofokus an App2 und dem anschließenden Verlust des Audiofokus durch App1:

  • Wenn der Audiodienst des Autos den Verlust des Audiofokus an App1 sendet, wird die Wiedergabe über den App1-Player gemäß den aktiven FadeManagerConfigurations ausgeblendet. Sobald der Vorgang abgeschlossen ist, erhält App1 den standardmäßigen Rückruf bei Verlust des Audiofokus.
  • Optional kann der Ton für App1 nach einer konfigurierbaren Dauer wieder eingeblendet werden. OEMs können diese Dauer über Builder#setFadeInDurationForUsage(int, long) gemäß ihren spezifischen Produktanforderungen festlegen.

Sequenzdiagramm für die Funktion „Ausblenden des Autoradios“

Abbildung 4: Sequenzdiagramm für die Funktion „Auto-Audio leiser“

Verwaltung des Fokus in mehreren Zonen

In Fahrzeugen mit mehreren Audiozonen wird der Audiofokus für jede Zone unabhängig voneinander verwaltet. Daher wird bei einer Anfrage an eine Zone nicht berücksichtigt, was in anderen Zonen den Fokus hat, und es wird auch nicht dazu geführt, dass Elemente in anderen Zonen den Fokus verlieren. So kann der Fokus der Hauptkabine getrennt von einem Entertainmentsystem für die Rücksitze verwaltet werden, sodass die Audiowiedergabe in einer Zone nicht durch Änderungen am Fokus in einer anderen unterbrochen wird.

Für alle Apps wird der Fokus automatisch über die CarAudioService verwaltet. Die Audiozone einer Fokusanfrage wird durch die zugehörige UserId oder UID bestimmt. Weitere Informationen finden Sie unter Audio-Routing für mehrere Zonen.

Audio aus mehreren Zonen gleichzeitig anfordern

Wenn eine App Audio in mehreren Zonen gleichzeitig abspielen möchte, muss sie für jede Zone den Fokus anfordern, indem sie AUDIOFOCUS_EXTRA_REQUEST_ZONE_ID in das Bundle aufnimmt:

//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

Mit diesem Bundle-Parameter kann der Anfragende die automatischen Audiozonenzuordnungen überschreiben, um stattdessen die angegebene Zonen-ID zu verwenden. Daher kann eine App separate Anfragen für verschiedene Audiozonen senden.

HAL-Audiofokus

Ab Android 11 kann die HAL den Fokus im Namen externer Streams anfordern. Die Verwendung dieser APIs ist zwar optional, wird aber dringend empfohlen, damit externe Audioinhalte optimal in das Android-System eingebunden werden und eine reibungslose Nutzererfahrung möglich ist.

Die HAL trifft die endgültige Entscheidung darüber, welche Töne Vorrang haben sollen. In diesem Zusammenhang sollten Notfall- und sicherheitskritische Töne unabhängig davon abgespielt werden, ob der HAL der Audiofokus gewährt wird, und sollten auch dann entsprechend fortgesetzt werden, wenn der HAL den Audiofokus verliert. Das gilt auch für alle Töne, die aufgrund behördlicher Vorschriften erforderlich sind.

Der HAL sollte Android-Streams bei der Wiedergabe von Notfall- oder sicherheitsrelevanten Tönen proaktiv stummschalten, damit sie deutlich zu hören sind.

AudioControl@2.0

Version 2.0 der AudioControl HAL führt die folgenden neuen APIs ein:

API Zweck
IAudioControl#registerFocusListener Registriert eine Instanz von IFocusListener bei der AudioControl HAL. Über diesen Listener kann die HAL den Audiofokus anfordern und aufheben. Der HAl stellt eine ICloseHandle-Instanz bereit, die von Android zum Aufheben der Registrierung des Listeners verwendet wird.
IAudioControl#onAudioFocusChange Benachrichtigt die HAL über Statusänderungen bei Fokusanfragen, die von der HAL über die IFocusListener gesendet wurden, einschließlich Antworten auf erste Fokusanfragen.
IFocusListener#requestAudioFocus Anfragen werden im Namen des HAL für eine bestimmte Verwendung, Zonen-ID und einen bestimmten Fokusgewinntyp gesendet.
IFocusListener#abandonAudioFocus Gibt vorhandene HAL-Fokusanfragen für die angegebene Verwendung und Zonen-ID auf.

Der HAL kann mehrere Fokusanfragen gleichzeitig haben, ist aber auf eine Anfrage pro Paar aus Nutzungs- und Zonen-ID beschränkt. Android geht davon aus, dass die HAL sofort nach einer Anfrage mit der Wiedergabe von Tönen für eine Nutzung beginnt und dies so lange fortsetzt, bis der Fokus aufgehoben wird.

Außer registerFocusListener sind diese Anfragen oneway, damit Android die HAL nicht verzögert, während eine Fokusanfrage verarbeitet wird. Der HAL sollte nicht warten, bis er den Fokus erlangt hat, bevor er sicherheitsrelevante Töne abspielt. Es ist optional, ob die HAL über IAudioControl#onAudioFocusChange auf Änderungen des Audiofokus achtet und darauf reagiert.

OEM-Audiofokusdienst für Autos

In Android 14 wurden in AAOS die OEM-Plug-in-Dienste für Autos eingeführt, um die Konfiguration einiger Fahrzeugkomponenten zu ermöglichen. Beim Car Audio Plugin Service können OEMs über den Plug-in-Dienst Fokusanfragen verwalten, die vom Car Audio-Dienst abgefangen werden. So haben OEMs mehr Flexibilität bei der Verwaltung des Fokus gemäß den geltenden Vorschriften. Daher kann die Interaktion für den Audiofokus je nach Hersteller und Region variieren. Die Grundvoraussetzung für den Audiofokus gilt weiterhin: Apps sollten weiterhin den Fokus anfordern, um die Audioverwaltung zu verbessern und die Nutzerfreundlichkeit zu erhöhen. Im Allgemeinen gelten für Anfragen zum Audiofokus durch Apps weiterhin bestimmte Regeln:

  • Ohne dauerhaften Audiofokus mit hoher Priorität (z. B. Anruf, Notfallbenachrichtigung oder Sicherheitsbenachrichtigung) sollten Apps den Audiofokus entweder vorübergehend oder dauerhaft erhalten können.

  • Wenn ein Medienfokus aktiv ist:

    • Apps, für die die Anrufnutzung im Vordergrund steht, sollten den Anruf entweder gleichzeitig oder ausschließlich empfangen können.

    • Apps, die den Navigationsfokus anfordern, sollten den Navigationsfokus entweder gleichzeitig oder ausschließlich erhalten können.

    • Apps, für die der Fokus auf die Nutzung des Assistants angefordert wird, sollten den Fokus entweder gleichzeitig oder ausschließlich erhalten können.

  • Wenn Apps mit dauerhafter Audiofokus mit hoher Priorität (z. B. Anrufe, Notfallwarnungen oder Sicherheitsbenachrichtigungen) aktiv sind, sollte jede eingehende Anfrage für den verzögerten Audiofokus gewährt oder bei Bedarf verzögert werden.

Diese Vorschläge sind nicht vollständig, können aber Apps, die den Fokus anfordern, dabei helfen, den Fokus zu erhalten, wenn keine Töne mit hoher Priorität aktiv sind. Auch wenn Töne mit hoher Priorität aktiv sind, sollten verzögerte Fokusanfragen berücksichtigt werden und der Fokus sollte auf die App gerichtet werden, sobald der Ton mit hoher Priorität stoppt.