Audiofokus

Bevor ein logischer Stream gestartet wird, fordert eine App den Audiofokus mit denselben Audioattributen an, die für den logischen Stream verwendet werden. Die App muss Fokusverluste berücksichtigen, damit sie in den Anwendungsfällen für Fahrzeuge wie erwartet funktioniert.

Das Senden einer Fokusanfrage wird zwar empfohlen, aber nicht vom System erzwungen. Betrachten Sie den Fokus daher als Mittel, um Konflikte während der Wiedergabe indirekt zu steuern und zu vermeiden, und nicht als primären Mechanismus zur Audiosteuerung. Das Fahrzeug sollte für den Betrieb des Audiosubsystems nicht vom Fokussystem abhängig sein.

Fokusinteraktionen

Zur Unterstützung von AAOS werden Audiofokusanfragen basierend auf vordefinierten Interaktionen zwischen dem CarAudioContext der Anfrage und dem der aktuellen Fokusinhaber verarbeitet. Es gibt drei Arten von Interaktionen:

  • Exklusiv
  • Ablehnen
  • Gleichzeitig

Exklusive Interaktion

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

Bei exklusiven Interaktionen darf jeweils nur eine App 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 haben. Infolgedessen wird die Fokusanfrage der neu gestarteten App mit AUDIOFOCUS_REQUEST_GRANTED zurückgegeben, während die aktuelle Musik-App ein Fokusänderungsereignis mit einem Verluststatus erhält, der dem Typ der Anfrage entspricht.

Interaktion ablehnen

Bei Ablehnen-Interaktionen wird die eingehende Anfrage immer abgelehnt. Beispiel: Sie versuchen, Musik abzuspielen, während ein Anruf läuft. Wenn in diesem Fall die Dialer-App den Audiofokus für einen Anruf hat und eine zweite App den Fokus anfordert, um Musik abzuspielen, erhält die Musik-App als Antwort auf die Anfrage AUDIOFOCUS_REQUEST_FAILED. Da die Fokusanfrage abgelehnt wird, wird kein Fokusverlust an den aktuellen Fokusinhaber gesendet.

Gleichzeitige Interaktion

Einzigartig für AAOS sind gleichzeitige Interaktionen. Dadurch können Apps, die den Audiofokus im Auto anfordern, den Fokus gleichzeitig mit anderen Apps haben. 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 Fokus des aktuellen Fokusinhabers nicht ändert. Wenn der aktuelle Fokusinhaber jedoch Ducking-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 Sie müssen beim Mischen und Ducking auf Hardwareebene über Ausgabegeräte hinweg vorsichtig sein. Wir empfehlen dringend, Instanzen von CarAudioContext, die gleichzeitig wiedergegeben werden dürfen, an verschiedene Ausgabegeräte weiterzuleiten.

Durch separate Ausgabegeräte für gleichzeitige Streams kann die HAL einen der Streams ducken, bevor sie gemischt werden, oder die physischen Streams an verschiedene Lautsprecher im Fahrzeug weiterleiten. Wenn die logischen Streams in Android gemischt werden, bleiben die Verstärkungen unverändert und werden als Teil desselben physischen Streams bereitgestellt.

Wenn beispielsweise Navigation und Medien gleichzeitig bereitgestellt werden, kann die Verstärkung für den Media-Stream vorübergehend reduziert (oder geduckt) werden, damit Navigationsanweisungen besser zu hören sind. Alternativ kann der Navigationsstream an die Lautsprecher auf der Fahrerseite weitergeleitet werden, während die Medien im Rest des Fahrzeugs weiter abgespielt werden.

Interaktionsmatrix

In dieser Tabelle ist die Interaktionsmatrix dargestellt, wie sie von CarAudioService definiert wird. Jede Zeile steht für den CarAudioContext des aktuellen Fokusinhabers und jede Spalte für den der eingehenden Anfrage.

Wenn beispielsweise eine Medien-App den Fokus hat und eine Navigations-App den Fokus anfordert, zeigt die Matrix an, dass die beiden Interaktionen gleichzeitig wiedergegeben werden können, sofern die anderen Kriterien für gleichzeitige Interaktionen erfüllt sind.

Aufgrund der gleichzeitigen Interaktionen kann es mehr als einen Fokusinhaber geben. In diesem Fall wird eine eingehende Fokusanfrage mit jedem der aktuellen Fokusinhaber verglichen, bevor festgelegt wird, welche Interaktion angewendet werden soll. In diesem Fall gewinnt die konservativste Interaktion. Ablehnen, dann exklusiv und schließlich gleichzeitig.

Interaktionsmatrix für 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 Anrufen ändern können. Wenn diese Einstellung festgelegt ist, android.car.KEY_AUDIO_FOCUS_NAVIGATION_REJECTED_DURING_CALL ändert die Interaktion zwischen eingehenden NAVIGATION Fokusanfragen und aktuellen CALL Fokusinhabern von gleichzeitig zu ablehnen. Wenn ein Nutzer möchte, dass Navigationsanweisungen einen Anruf nicht unterbrechen, kann er die Einstellung aktivieren. Diese Einstellung wird für den Nutzer gespeichert und kann dynamisch festgelegt werden, sodass nachfolgende Fokusanfragen die neue Einstellung berücksichtigen.

Verzögerbarer Audiofokus

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

Regeln für verzögerte Audiofokusanfragen

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

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

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

Verzögerbaren Fokus anfordern

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

  1. Verwenden Sie 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. Verarbeiten Sie beim Stellen der Anfrage die Antwort 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. 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

In Android 15 wird in AAOS das vom System erzwungene Ausblenden von Audio eingeführt. In Android wird der Audiofokus nicht vom System erzwungen. App-Entwickler werden zwar aufgefordert, die Richtlinien für den Audiofokus einzuhalten, aber wenn eine App auch nach dem Verlust des Audiofokus laut weiter abgespielt wird, kann das System dies nicht verhindern.

In sicherheitskritischen Fahrzeugumgebungen ist die Einhaltung des Audiofokus von entscheidender Bedeutung, um die Ablenkung des Fahrers zu minimieren. Mit dieser Funktion blendet das Audio-Framework jetzt automatisch Apps aus, die den Audiofokus verlieren, um eine kontrolliertere und vorhersehbarere Audioausgabe zu ermöglichen.

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

Hochwertiges Design

Die folgende Abbildung zeigt das hochwertige Design und die Unterstützung für die Funktion zum Verlust des Fokus in Fahrzeugen:

Konzept auf hoher Ebene für die vom System erzwungene Einblendungsfunktion

Abbildung 2 : Hochwertiges Design für die Funktion zum vom System erzwungenen Ausblenden.

  • Gezieltes Ausblenden:Das vom System erzwungene Ausblenden 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:
    • Das Audio-Framework blendet die Audioausgabe der verlierenden App automatisch aus.
    • Nach dem Ausblenden wird der Audiostream vom System stummgeschaltet.
    • Die App erhält dann eine Benachrichtigung über den Verlust des Audiofokus.
    • Apps, die sich nicht ordnungsgemäß verhalten, werden stummgeschaltet, bis sie den Audiofokus wiedererlangen.
    • Standardmäßig werden die ausgeblendeten Apps nach zwei Sekunden wieder eingeblendet. OEMs können diesen Wert jedoch auf einen beliebigen Timeout-Wert 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 dafür definieren, wann die Erzwingung des Audiofokus durch das System auf eine verlierende App angewendet wird.
    • Das Audio-Framework erzwingt das Ausblenden und Stummschalten nur, wenn die verlierende App den von OEMs definierten Regeln in dieser XML-Datei entspricht.
    • So können OEMs das Verhalten der Funktion basierend auf App-Merkmalen oder Audio-Nutzungstypen anpassen.

  • Funktionssteuerung mit RRO:Ein neues Feature-Flag für das Runtime Resource Overlay (RRO), audioUseFadeManagerConfiguration, wurde eingeführt, um diese Funktion zu aktivieren oder zu deaktivieren:

    • Die Funktion ist standardmäßig deaktiviert.
    • Um den vom System erzwungenen Verlust des Audiofokus zu aktivieren, müssen OEMs dieses Flag auf true setzen.
    • Das Car Audio-Framework erwartet zwar gültige Konfigurationsdefinitionen für das Ausblenden, wenn das Flag aktiviert ist, aber das Fehlen solcher Definitionen führt nicht automatisch zu einer schwerwiegenden Ausnahme.
    • Alle Apps von Ausblendkonfigurationen müssen übereinstimmende Ausblenddefinitionen haben. Es ist ein schwerwiegender Fehler, eine Ausblendkonfiguration (nach Name) als Teil der Car Audio-Konfiguration aufzurufen, ohne eine gültige Definition anzugeben.
    • Wenn das Flag deaktiviert ist, werden alle Definitionen der Ausblendkonfiguration und alle Konfigurationsverweise ignoriert.

Konfiguration des Ausblendmanagers

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

Fade-Manager-Konfiguration

Abbildung 3 : Konfiguration des Ausblendmanagers.

Diese Konfiguration umfasst:

  • Eigenschaften für den fließenden Übergang:Einstellungen für das Ausblenden und Einblenden.
    • Kann mit bestimmten Audioverwendungen oder Attributen definiert werden.
    • Ermöglicht benutzerdefinierte Einstellungen für die Dauer.
    • Diese Einstellungen werden verwendet, um VolumeShaper.Configuration zu erstellen.
  • Ausblendrichtlinien:Regeln, die festlegen, wann das Ausblenden erfolgt.
    • Eine globale Option zum Aktivieren oder Deaktivieren des Ausblendens.
    • Eine konfigurierbare Liste von Audioverwendungen, die ausgeblendet werden können (geeignet für das Ausblenden beim Verlust des Fokus).
    • Ausschlusslisten (nicht ausblendbar) verhindern, dass kritische oder festgelegte Audioquellen ausgeblendet werden. Diese Listen können auf Folgendem basieren:
      • Inhaltstypen
      • Audioattribute
      • App-UIDs (können nur zur Laufzeit festgelegt werden)

OEM-Konfigurationen

In diesem Abschnitt sehen wir uns die verfügbaren OEM-Anpassungen an.

XML-Datei für die Konfiguration des Ausblendens von Car Audio

Android 15 führt eine neue Konfigurationsdatei ein: car_audio_fade_configuration.xml. Damit können OEMs das Verhalten beim Ausblenden von Audio beim Verlust des Fokus umfassend anpassen.

  • Diese XML-Datei ermöglicht die Definition mehrerer unterschiedlicher Ausblendkonfigurationen, die jeweils einen eindeutigen Namen für Querverweise in car_audio_configuration.xml erfordern.
  • Diese Konfigurationen können flexibel auf verschiedene Audiozonen und Zonenkonfigurationen angewendet werden.
  • Jede Ausblendkonfiguration akzeptiert nur Werte für die Dauer in Millisekunden, die das System dann verwendet, um intern die entsprechende VolumeShaper.Configuration zu generieren.

Praktische Implementierungsanleitungen 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 von Car Audio

Android 15 führt eine aktualisierte car_audio_configuration.xml-Datei ein, jetzt in Version 4, die die neuen Tags applyFadeConfigs und fadeConfig enthält. Das Tag applyFadeConfigs kann mehrere fadeConfig-Definitionen enthalten, was eine flexible Ausblendkonfiguration ermöglicht. Jede Definition:

  • Muss eine Standard-fadeConfig enthalten, die mit isDefault = true festgelegt ist.
  • Kann mehrere vorübergehende fadeConfig-Definitionen enthalten. Diese vorübergehenden Konfigurationen werden speziell bei Interaktionen zum Verlust des Audiofokus angewendet und nur, wenn die App, die den Audiofokus erhält, den Kriterien entspricht, die in der vorübergehenden Konfiguration definiert sind.

Praktische Implementierungsanleitungen finden Sie in den Beispielkonfigurationen für den Emulator unter device/generic/car/emulator/audio/car_audio_configuration.xml.

OEM-Erweiterung für den Audiofokusdienst

OEMs, die einen benutzerdefinierten Car Audio-Fokusdienst implementieren, können die Einstellungen für das Ausblenden von Audio konfigurieren, indem sie sie in OemCarAudioFocusResult einfügen. 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 Ausblend-Einstellungen für den Start verwenden oder Konfigurationen dynamisch über ihren benutzerdefinierten Audiofokusdienst anwenden, was eine anpassbare Steuerung ermöglicht.

Sequenzdiagramm

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

  • Nachdem der Car Audio-Dienst den Verlust des Audiofokus an App1 gesendet hat, wird die Wiedergabe vom Player von App1 gemäß den aktiven FadeManagerConfigurations ausgeblendet. Sobald der Ausblendvorgang abgeschlossen ist, erhält App1 den Standard-Callback für den Verlust des Audiofokus.
  • Optional kann das Audio für App1 nach einer konfigurierbaren Dauer wieder eingeblendet werden. OEMs können diese Dauer über Builder#setFadeInDurationForUsage(int, long) entsprechend ihren spezifischen Produktanforderungen festlegen.

Sequenzdiagramm für die Funktion zum Ein- und Ausblenden von Audio im Auto

Abbildung 4 : Sequenzdiagramm für die Funktion zum Ausblenden von Car Audio.

Fokusverwaltung für mehrere Zonen

Bei Fahrzeugen mit mehreren Audiozonen wird der Audiofokus für jede Zone unabhängig verwaltet. Eine Anfrage an eine Zone berücksichtigt daher nicht, was den Fokus in anderen Zonen hat, und führt auch nicht dazu, dass Fokusinhaber in anderen Zonen den Fokus verlieren. So kann der Fokus der Hauptkabine unabhängig von einem Entertainment-System auf dem Rücksitz verwaltet werden, wodurch die Audioausgabe in einer Zone nicht durch Fokusänderungen in einer anderen Zone unterbrochen wird.

Für alle Apps verwaltet CarAudioService den Fokus automatisch. 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 gleichzeitig aus mehreren Zonen anfordern

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

//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 Audiozonenzuweisungen überschreiben und stattdessen die angegebene Zonen-ID verwenden. Eine App kann daher separate Anfragen für verschiedene Audiozonen stellen.

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 Sounds optimal in das Android-Ökosystem integriert werden können und eine nahtlose Nutzererfahrung möglich ist.

Die HAL legt endgültig fest, welche Sounds Priorität haben sollen. In diesem Zusammenhang sollten Notfall- und sicherheitskritische Sounds unabhängig davon wiedergegeben werden, ob die HAL den Audiofokus erhält oder nicht. Sie sollten auch dann weiter abgespielt werden, wenn die HAL den Audiofokus verliert. Das gilt auch für alle Sounds, die durch behördliche Bestimmungen erforderlich sind.

Die HAL sollte Android-Streams proaktiv stummschalten, wenn Notfall- oder sicherheitskritische Sounds wiedergegeben werden, 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. Mit diesem Listener kann die HAL den Audiofokus anfordern und aufgeben. Die HAL stellt eine ICloseHandle-Instanz bereit, die von Android verwendet werden kann, um die Registrierung des Listeners aufzuheben.
IAudioControl#onAudioFocusChange Benachrichtigt die HAL über Statusänderungen bei Fokusanfragen, die von der HAL über den IFocusListener, einschließlich Antworten auf anfängliche Fokusanfragen gestellt wurden.
IFocusListener#requestAudioFocus Fordert den Fokus im Namen der HAL für eine bestimmte Verwendung, Zonen-ID, und einen bestimmten Typ der Fokusverstärkung an.
IFocusListener#abandonAudioFocus Gibt vorhandene HAL-Fokusanfragen für die angegebene Verwendung und Zonen ID auf.

Die HAL kann mehrere Fokusanfragen gleichzeitig haben, ist aber auf eine Anfrage pro Verwendung und Zonen-ID-Paarung beschränkt. Android geht davon aus, dass die HAL sofort mit der Wiedergabe von Sounds für eine Verwendung beginnt, sobald eine Anfrage gestellt wurde, und dies so lange tut, bis sie den Fokus aufgibt.

Abgesehen von registerFocusListener sind diese Anfragen oneway, damit Android die HAL nicht verzögert, während eine Fokusanfrage verarbeitet wird. Die HAL sollte nicht warten, bis sie den Fokus erhält, bevor sie sicherheitskritische Sounds wiedergibt. Es ist optional, dass die HAL über IAudioControl#onAudioFocusChange auf Änderungen des Audiofokus reagiert.

OEM-Audiofokusdienst für Fahrzeuge

In Android 14 wurden in AAOS die Plugin-Dienste für Car OEMs eingeführt, um die Konfigurierbarkeit für einige Fahrzeugkomponenten zu ermöglichen. Für den Car Audio Plugin Service können OEMs mit dem Plugin Dienst Fokusanfragen verwalten, die vom Car Audio Dienst abgefangen werden. So haben OEMs mehr Flexibilität bei der Verwaltung des Fokus gemäß Regeln und Vorschriften. Daher kann sich die Interaktion mit dem Audiofokus zwischen Herstellern und von Region zu Region unterscheiden. Die grundlegende Annahme für den Audiofokus bleibt bestehen: Apps sollten weiterhin den Fokus anfordern, um die Audioausgabe besser zu verwalten und die Nutzerfreundlichkeit zu verbessern. Im Allgemeinen gelten weiterhin bestimmte Regeln für Audiofokusanfragen von Apps:

  • Ohne bestehenden Audiofokus mit hoher Priorität (einschließlich Anruf, Warnmeldung oder Sicherheitsbenachrichtigung) sollten Apps den Audiofokus entweder vorübergehend oder dauerhaft erhalten können.

  • Wenn ein Media-Fokus aktiv ist:

    • Apps, die den Fokus für die Anrufverwendung anfordern, sollten den Anruf entweder gleichzeitig oder exklusiv erhalten können.

    • Apps, die den Fokus für die Navigationsverwendung anfordern, sollten den Navigationsfokus entweder gleichzeitig oder exklusiv erhalten können.

    • Apps, die den Fokus für die Assistentenverwendung anfordern, sollten den Fokus entweder gleichzeitig oder exklusiv erhalten können.

  • Wenn Apps mit bestehendem Audiofokus mit hoher Priorität (einschließlich Anruf, Notfallbenachrichtigung oder Sicherheitsbenachrichtigung) aktiv sind, sollte jede eingehende verzögerte Audiofokusanfrage nach Bedarf gewährt oder verzögert werden.

Diese Vorschläge sind zwar nicht erschöpfend, können aber Apps, die den Fokus anfordern, helfen, den Fokus zu erhalten, wenn keine aktiven Sounds mit hoher Priorität vorhanden sind. Auch wenn Sounds mit hoher Priorität aktiv sind, sollten verzögerte Fokusanfragen berücksichtigt werden und den Fokus erhalten können, wenn der Sound mit hoher Priorität beendet wird.