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 den Verlust des Fokus berücksichtigen, damit sie in den Automotive-Anwendungsfällen wie erwartet funktioniert.

Das Senden einer Fokusanfrage wird zwar empfohlen, ist aber nicht zwingend erforderlich. 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 Fokus-System 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 Fokushalter den Fokus verliert. Da beide Apps Medien abspielen, darf nur eine App den Fokus haben. Daher wird die Fokusanfrage der neu gestarteten App mit AUDIOFOCUS_REQUEST_GRANTED zurückgegeben, während die aktuell wiedergebende Musik-App ein Fokusänderungsereignis mit einem Verluststatus erhält, der dem Typ der gestellten Anfrage entspricht.

Interaktion ablehnen

Bei reject-Interaktionen wird die eingehende Anfrage immer abgelehnt. Das kann beispielsweise passieren, wenn Sie versuchen, Musik abzuspielen, während ein Anruf läuft. Wenn der Dialer in diesem Fall 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 Fokus-Anfrage abgelehnt wird, wird kein Fokusverlust an den aktuellen Fokus-Inhaber gesendet.

Gleichzeitige Interaktion

Gleichzeitige Interaktionen sind nur in AAOS möglich. 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 Fokus des aktuellen Fokusinhabers nicht ändert. Wenn der aktuelle Fokusinhaber jedoch Duck-Ereignisse empfangen oder bei einem Duck-Ereignis pausieren möchte, verliert er den Fokus, wie bei einer exklusiven Interaktion.

Gleichzeitige Streams verarbeiten

Die gleichzeitige Interaktion hat viele Anwendungsbereiche. Achten Sie jedoch auf das Mischen und Ducking auf Hardwareebene über Ausgabegeräte hinweg. Wir empfehlen dringend, dass Instanzen von CarAudioContext, die gleichzeitig wiedergegeben werden dürfen, an verschiedene Ausgabegeräte weitergeleitet werden.

Durch separate Ausgabegeräte für gleichzeitige Streams kann das HAL einen der Streams vor dem Mischen unterdrücken 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 wiedergegeben werden, kann die Lautstärke des Media-Streams vorübergehend reduziert werden, damit Navigationsanweisungen besser zu hören sind. Alternativ kann der Navigationsstream an die Lautsprecher auf der Fahrerseite weitergeleitet werden, während Medien weiterhin im Rest des Fahrzeugs abgespielt werden.

Interaktionsmatrix

In dieser Tabelle sehen Sie die von CarAudioService definierte Interaktionsmatrix. 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 hat und 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 Fokusinhaber geben. In diesem Fall wird eine eingehende Fokusanfrage mit jedem der aktuellen Fokushalter verglichen, bevor bestimmt wird, welche Interaktion angewendet werden soll. In diesem Fall gewinnt die konservativste Interaktion. Zuerst wird die Anfrage abgelehnt, dann exklusiv und schließlich gleichzeitig ausgeführt.

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 festgelegt, ändert android.car.KEY_AUDIO_FOCUS_NAVIGATION_REJECTED_DURING_CALL die Interaktion zwischen eingehenden NAVIGATION-Fokusanfragen und aktuellen CALL-Fokusinhabern von concurrent zu rejects. 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 das Anfordern von verzögerbarem Audiofokus hinzugefügt. Dadurch können nicht vorübergehende Fokusanfragen verzögert werden, wenn ihre Interaktion mit aktuellen Fokusinhabern normalerweise zu einer Ablehnung führen würde. Wenn sich der Fokus so ändert, dass 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 dem relevanten Zeitpunkt 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 eine synchrone Antwort vom Typ AUDIOFOCUS_REQUEST_DELAYED.

  • Aufschiebbare Anfragen müssen OnAudioFocusChangeListener haben. Nachdem eine Anfrage verzögert wurde, wird der Listener verwendet, um den Anforderer 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. 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. Verarbeiten Sie 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, werden Änderungen des Fokus vom Fokus-Listener verarbeitet:

    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 erzwungene Einblendung

In Android 15 wird in AAOS ein vom System erzwungenes Audio-Fade-in eingeführt. Unter Android wird der Audio-Fokus nicht vom System erzwungen. App-Entwickler werden zwar aufgefordert, die Richtlinien für den Audiofokus einzuhalten, aber wenn eine App weiterhin laut wiedergegeben wird, auch nachdem sie den Audiofokus verloren hat, kann das System dies nicht verhindern.

In sicherheitskritischen Automobilumgebungen ist die Einhaltung des Audiofokus von entscheidender Bedeutung, um die Ablenkung des Fahrers zu minimieren. Mit dieser Funktion werden Apps, die den Audiofokus verlieren, jetzt automatisch ausgeblendet, um ein kontrollierteres und vorhersehbareres Audioerlebnis zu ermöglichen.

Diese Verbesserung sorgt dafür, dass Apps die Entscheidung zum Verlust des Audiofokus gemäß der Interaktionsmatrix einhalten und Konflikte bei der Audiowiedergabe vermieden werden.

Konzeption

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

Übersichtliches Design für die systemseitig erzwungene Einblendungsfunktion

Abbildung 2: Übersichtliches Design für die vom System erzwungene Fade-Funktion.

  • Gezieltes Ausblenden:Die Systemdurchsetzung des Ausblendens in Android 15 ist speziell für Situationen konzipiert, in denen eine App den Audiofokus verliert, aber weiterhin Audio wiedergegeben wird.
  • Ausblendmechanismus:Wenn eine App den Audiofokus an eine neue anfordernde App verliert:
    • Das Audio-Framework blendet die Audioausgabe der App, die nicht mehr im Vordergrund ist, 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 korrekt verhalten, werden stummgeschaltet, bis sie den Audiofokus wiedererlangen.
    • Standardmäßig werden ausgeblendete Apps nach 2 Sekunden wieder eingeblendet. OEMs können jedoch ein beliebiges Zeitlimit 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 des Systems auf eine App angewendet wird, die den Fokus verliert.
    • Das Audio-Framework erzwingt das Ausblenden und Stummschalten nur, wenn die App, die den Fokus verliert, den vom OEM 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:Es wurde ein neues RRO-Feature-Flag (Runtime Resource Overlay) eingeführt, audioUseFadeManagerConfiguration, mit dem diese Funktion aktiviert oder deaktiviert werden kann:

    • Die Funktion ist standardmäßig deaktiviert.
    • Damit der Audiofokusverlust durch das System erzwungen wird, müssen OEMs dieses Flag auf true festlegen.
    • Obwohl das Car Audio Framework bei aktiviertem Flag gültige Fade-Konfigurationsdefinitionen erwartet, führt das Fehlen solcher Definitionen nicht automatisch zu einer schwerwiegenden Ausnahme.
    • Alle Apps von Fade-Konfigurationen müssen passende Fade-Definitionen haben. Es ist ein schwerwiegender Fehler, eine Fade-Konfiguration (nach Name) als Teil der Car-Audio-Konfiguration aufzurufen, ohne eine gültige Definition anzugeben.
    • Wenn das Flag deaktiviert ist, werden alle Konfigurationsdefinitionen für Einblendungen und alle Konfigurationsverweise ignoriert.

Fade Manager-Konfiguration

Das Audio-Framework von Android 15 führt eine einheitliche FadeManagerConfiguration ein, um OEMs eine detaillierte Steuerung des Audio-Fading-Verhaltens zu ermöglichen. Dieses Framework wird in Abbildung 3 dargestellt:

Fade Manager-Konfiguration

Abbildung 3: Fade-Manager konfigurieren

Diese Konfiguration umfasst:

  • Eigenschaften für Ein- und Ausblendung:Einstellungen für Ein- und Ausblendung.
    • Kann mit bestimmten Audio-Nutzungsarten oder ‑Attributen definiert werden.
    • Ermöglicht benutzerdefinierte Einstellungen für die Dauer.
    • Diese Einstellungen werden verwendet, um VolumeShaper.Configuration zu erstellen.
  • Fading-Richtlinien:Regeln, die festlegen, wann das Fading erfolgt.
    • Ein globaler Schalter zum Aktivieren oder Deaktivieren von Überblendungen.
    • Eine konfigurierbare Liste von Audioverwendungen, die ausgeblendet werden können (wenn der Fokus verloren geht).
    • Ausschlusslisten (nicht ausblendbar) verhindern, dass kritische oder bestimmte 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 werden die verfügbaren OEM-Anpassungen beschrieben.

XML-Datei für die Konfiguration des Auto-Audio-Fading

Mit Android 15 wird eine neue Konfigurationsdatei eingeführt: car_audio_fade_configuration.xml. Damit können OEMs das Verhalten beim Ausblenden von Audioinhalten bei Fokusverlust umfassend anpassen.

  • In dieser XML-Datei können mehrere unterschiedliche Fade-Konfigurationen definiert werden, für die jeweils ein eindeutiger Name für Querverweise in car_audio_configuration.xml erforderlich ist.
  • Diese Konfigurationen können flexibel auf verschiedene Audiozonen und Zonenkonfigurationen angewendet werden.
  • Wichtig: Jede Fade-Konfiguration akzeptiert nur Dauerwerte in Millisekunden. Das System verwendet diese Werte dann, um intern die entsprechende VolumeShaper.Configuration zu generieren.

Praktische Implementierungshinweise 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

In Android 15 wird eine aktualisierte car_audio_configuration.xml-Datei (Version 4) eingeführt, die neue applyFadeConfigs- und fadeConfig-Tags enthält. Das applyFadeConfigs-Tag kann mehrere fadeConfig-Definitionen enthalten, was eine flexible Konfiguration von Ein- und Ausblendungen ermöglicht. Für jede Definition gilt:

  • Muss eine Standard-fadeConfig enthalten, die mit isDefault = true gekennzeichnet ist.
  • Kann mehrere temporäre fadeConfig-Definitionen enthalten. Diese vorübergehenden Konfigurationen werden speziell bei Interaktionen angewendet, bei denen der Audiofokus verloren geht, und nur dann, wenn die App, die den Audiofokus erhält, den in der vorübergehenden Konfiguration definierten Kriterien entspricht.

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

OEM-Diensterweiterung für Audiofokus

OEMs, die einen benutzerdefinierten Dienst für den Audiofokus im Auto 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 Einstellungen für das Einblenden beim Booten verwenden oder Konfigurationen dynamisch über ihren benutzerdefinierten Audiofokusdienst anwenden.

Sequenzdiagramm

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

  • Wenn der Car Audio-Dienst den Verlust des Audiofokus an App1 sendet, wird die Wiedergabe vom App1-Player gemäß den aktiven FadeManagerConfigurations ausgeblendet. Sobald der Fade-out-Vorgang abgeschlossen ist, erhält App1 den Standard-Callback für den Verlust des Audiofokus.
  • Optional kann die Audioausgabe für App1 nach einer konfigurierbaren Dauer wieder eingeblendet werden. Originalgerätehersteller 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 Ein- und Ausblenden von Audio im Auto.

Fokusverwaltung für mehrere Zonen

Bei Fahrzeugen mit mehreren Audiozonen wird der Audiofokus für jede Zone separat verwaltet. Bei einer Anfrage an eine Zone wird also nicht berücksichtigt, was in anderen Zonen im Fokus steht. Außerdem verlieren Fokusinhaber in anderen Zonen nicht den Fokus. So kann der Fokus der Hauptkabine unabhängig von einem Infotainmentsystem für die Rücksitze verwaltet werden. Dadurch wird die Audiowiedergabe in einer Zone nicht durch Änderungen des Fokus in einer anderen Zone unterbrochen.

Bei allen Apps wird der Fokus automatisch von 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 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 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 Paketparameter kann der Anfragesteller die automatischen Audiozonenzuordnungen überschreiben und stattdessen die angegebene Zonen-ID verwenden. Eine App könnte daher separate Anfragen für verschiedene Audiozonen senden.

HAL-Audiofokus

Ab Android 11 kann der HAL im Namen externer Streams den Fokus anfordern. Die Verwendung dieser APIs ist zwar optional, wird aber dringend empfohlen, damit externe Sounds optimal in das Android-Ökosystem eingebunden werden und eine reibungslose Nutzererfahrung geboten wird.

Das HAL trifft die endgültige Entscheidung darüber, welche Sounds Priorität haben sollen. In diesem Fall sollten Notfall- und sicherheitskritische Töne unabhängig davon wiedergegeben werden, ob der HAL den Audiofokus hat oder nicht. Sie sollten auch dann weitergegeben werden, wenn der HAL den Audiofokus verliert. Das gilt auch für alle Sounds, die durch staatliche Vorschriften vorgeschrieben sind.

Das HAL sollte Android-Streams proaktiv stummschalten, wenn Notfall- oder sicherheitskritische Töne abgespielt werden, damit sie deutlich zu hören sind.

AudioControl@2.0

In Version 2.0 der AudioControl-HAL werden die folgenden neuen APIs eingeführt:

API Zweck
IAudioControl#registerFocusListener Registriert eine Instanz von IFocusListener bei der AudioControl-HAL. Mit diesem Listener kann das HAL den Audiofokus anfordern und aufgeben. Das HAL stellt eine ICloseHandle-Instanz bereit, die von Android zum Aufheben der Registrierung des Listeners verwendet wird.
IAudioControl#onAudioFocusChange Benachrichtigt das HAL über Statusänderungen bei Fokusanfragen, die vom HAL über IFocusListener gestellt wurden, einschließlich Antworten auf anfängliche Fokusanfragen.
IFocusListener#requestAudioFocus Anfragen werden im Namen des HAL für eine bestimmte Verwendung, Zonen-ID und Art der Fokusverstärkung gestellt.
IFocusListener#abandonAudioFocus Bricht vorhandene HAL-Fokusanfragen für die angegebene Verwendung und Zonen-ID ab.

Das HAL kann mehrere Fokusanfragen gleichzeitig haben, ist aber auf eine Anfrage pro Kombination aus Verwendungszweck und Zonen-ID beschränkt. Unter Android wird davon ausgegangen, dass das HAL sofort mit der Wiedergabe von Sounds für eine Nutzung beginnt, sobald eine Anfrage gestellt wurde, und dies fortsetzt, bis der Fokus aufgegeben wird.

Mit Ausnahme von registerFocusListener sind diese Anfragen oneway, damit Android das HAL nicht verzögert, während eine Fokusanfrage verarbeitet wird. Das HAL sollte nicht warten, bis es den Fokus erhält, bevor sicherheitskritische Töne abgespielt werden. Es ist optional, dass der HAL über IAudioControl#onAudioFocusChange auf Änderungen des Audiofokus reagiert.

OEM-Dienst für Audiofokus im Auto

In Android 14 wurden in AAOS die Plugin-Dienste für Auto-OEMs eingeführt, um die Konfigurierbarkeit einiger Fahrzeugkomponenten zu ermöglichen. Für den Car Audio Plugin Service ermöglicht der Plug-in-Dienst OEMs, Fokusanfragen zu verwalten, die vom Car Audio-Dienst abgefangen werden. Dies gibt OEMs mehr Flexibilität bei der Verwaltung des Fokus, wie es durch Regeln und Vorschriften erforderlich ist. Daher kann die Interaktion mit dem Audiofokus je nach Hersteller und Region unterschiedlich sein. Die grundlegende Prämisse für den Audiofokus gilt weiterhin: Apps sollten den Fokus anfordern, um Audio besser zu verwalten und die Nutzerfreundlichkeit zu verbessern. Im Allgemeinen gelten für Audiofokus-Anfragen von Apps weiterhin bestimmte Regeln:

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

  • Wenn ein Media-Schwerpunkt aktiv ist:

    • Apps, die die Verwendung von Anrufen anfordern, müssen Anrufe entweder gleichzeitig oder exklusiv empfangen können.

    • Apps, die den Navigationsfokus anfordern, sollten ihn entweder gleichzeitig oder exklusiv erhalten können.

    • Apps, die die Nutzung des Assistenten anfordern, müssen den Fokus entweder gleichzeitig oder exklusiv erhalten können.

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

Diese Vorschläge sind zwar nicht vollständig, können aber Apps, die den Fokus anfordern, dabei 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. Der Fokus sollte möglich sein, wenn der Sound mit hoher Priorität beendet wird.