Audiofokus

Bevor eine App einen logischen Stream startet, fordert sie mit denselben Audioattributen wie für den logischen Stream den Audiofokus an. 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 in beiden Apps Medien abgespielt werden, darf nur eine App den Fokus halten. Daher wird die Fokusanfrage der neu gestarteten App mit AUDIOFOCUS_REQUEST_GRANTED zurückgegeben, während die App, in der gerade Musik wiedergegeben wird, 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, CarAudioContext, die gleichzeitig wiedergegeben werden dürfen, an verschiedene Ausgabegeräte weiterzuleiten.

Da separate Ausgabegeräte für gleichzeitige Streams vorhanden sind, kann der 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 des Fahrzeugs weiter abgespielt werden.

Interaktionsmatrix

Die folgende 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 jedem der aktuellen Fokushalter verglichen, bevor entschieden wird, welche Interaktion angewendet werden soll. In diesem Fall gewinnt die konservativste Interaktion. „Abweisen“, dann „Exklusiv“ und schließlich „Parallel“.

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.

  • Verzögerbare Anfragen müssen einen OnAudioFocusChangeListener haben. Wenn eine Anfrage verzögert wird, wird der Anfragende über den Listener benachrichtigt, 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

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 vom 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 den Audiofokus erhält oder nicht. Sie sollten auch dann entsprechend abgespielt werden, wenn der HAL den Audiofokus verliert. Das gilt auch für alle Töne, die aufgrund von behördlichen Vorschriften erforderlich sind.

Die HAL sollte Android-Streams bei Bedarf proaktiv stummschalten, wenn Notfall- oder sicherheitskritische Töne abgespielt 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. Ü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 Paarung von 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 sicherheitskritische 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. ein Telefonanruf, eine Notfallbenachrichtigung oder eine Sicherheitsbenachrichtigung) aktiv sind, sollte jede eingehende verzögerte Audiofokusanfrage gewährt oder bei Bedarf verzögert werden.

Die oben genannten Vorschläge sind nicht vollständig, können aber Apps, die den Fokus anfordern, dabei helfen, den Fokus zu erhalten, wenn keine aktiven Töne mit hoher Priorität vorhanden 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.