Przed rozpoczęciem strumienia logicznego aplikacja prosi o skupienie się na dźwięku, używając tych samych atrybutów dźwięku co w przypadku strumienia logicznego. Aplikacja musi uwzględniać straty ostrości, aby działać zgodnie z oczekiwaniami w przypadku zastosowań motoryzacyjnych.
Przesyłanie prośby o uwagę jest zalecane, ale nie jest wymuszane przez system. Dlatego traktuj fokus jako sposób pośredniego kontrolowania i unikania konfliktów podczas odtwarzania, a nie jako główny mechanizm kontroli dźwięku. Samochód nie powinien polegać na systemie sterowania w celu działania podsystemu audio.
Interakcje z elementami
Aby obsługiwać AAOS, żądania dotyczące skupienia na dźwięku są obsługiwane na podstawie zdefiniowanych wcześniej interakcji CarAudioContext
żądania z interakcjami bieżących posiadaczy skupienia. Istnieją 3 rodzaje interakcji:
- Tylko wybrani użytkownicy
- Odrzuć
- Równoczesne
Interakcja wykluczająca
Jest to model interakcji najczęściej używany w przypadku Androida.
W przypadku wyłącznych interakcji tylko 1 aplikacja może być aktywna w danym momencie.
W takim przypadku żądanie o uzyskanie fokusu powoduje, że obecny posiadacz fokusu traci go. Obie aplikacje odtwarzają multimedia, więc tylko jedna z nich może być aktywna. W efekcie żądanie skupienia uwagi nowej aplikacji zwraca wartośćAUDIOFOCUS_REQUEST_GRANTED
, a obecnie odtwarzana aplikacja muzyczna otrzymuje zdarzenie zmiany skupienia uwagi ze stanem utraty odpowiadającym rodzajowi żądania.
Odrzuć interakcję
W przypadku interakcji z wartością reject przychodząca prośba jest zawsze odrzucana. Na przykład podczas próby odtworzenia muzyki w trakcie rozmowy. W tym przypadku, jeśli Dialer ma fokus dźwięku w przypadku połączenia, a druga aplikacja poprosi o fokus w celu odtworzenia muzyki, aplikacja muzyczna otrzyma odpowiedź AUDIOFOCUS_REQUEST_FAILED
. Ponieważ prośba o ostrzenie została odrzucona, do bieżącego właściciela nie zostanie wysłana żadna informacja o utracie ostrości.
Równoległa interakcja
Specyficzne dla AAOS są jednoczesne interakcje. Dzięki temu aplikacje, które wymagają skupienia na dźwięku w samochodzie, mogą zachować fokus jednocześnie z innymi aplikacjami. Aby mogła wystąpić jednoczesna interakcja, muszą być spełnione te warunki. The:
Prośba o uzyskanie fokusa musi zawierać parametr AudioManager.AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK.
Aktualny uchwyt fokusu nie zawiera funkcji setPauseWhenDucked(true)
Obecny właściciel czasu skupienia nie chce otrzymywać zdarzeń ściszających dźwięk
Jeśli te kryteria są spełnione, żądanie fokusa zwraca wartość AUDIOFOCUS_REQUEST_GRANTED
, a obecny posiadacz fokusa nie ma zmiany w fokusie. Jeśli jednak bieżący element z fokusem zdecyduje się na otrzymywanie zdarzeń duck lub wstrzymanie działania po wciśnięciu przycisku duck, straci on fokus, tak jak w przypadku interakcji wyłącznej.
Obsługa równoczesnych strumieni
Chociaż interakcja równoczesna ma wiele zastosowań, należy zachować ostrożność podczas miksowania i wyciszania na poziomie sprzętu na urządzeniach wyjściowych. Zdecydowanie zalecamy, aby instancje CarAudioContext
, które mogą być odtwarzane jednocześnie, były kierowane na różne urządzenia wyjściowe.
Dzięki temu, że urządzenia wyjściowe są oddzielne dla poszczególnych strumieni, HAL może wyciszyć jeden z nich przed zmiksowaniem lub przekierować fizyczne strumienie do różnych głośników w samochodzie. Jeśli strumienie logiczne są miksowane w Androidzie, wzmocnienia nie są zmieniane i przesyłane jako część tego samego fizycznego strumienia.
Jeśli na przykład nawigacja i multimedia są dostarczane jednocześnie, wzmocnienie strumienia multimediów może zostać tymczasowo zmniejszone (lub wyciszone), aby instrukcje nawigacyjne były lepiej słyszalne. Można też przesłać strumień danych nawigacji do głośników po stronie kierowcy, a pozostałe media odtwarzać w pozostałej części kabiny.
Interakcja
Ta tabela pokazuje macierz interakcji zdefiniowaną przez funkcję CarAudioService
.
Każdy wiersz reprezentuje CarAudioContext
bieżącego elementu w centrum uwagi, a każda kolumna reprezentuje CarAudioContext
przychodzącego żądania.
Jeśli na przykład aplikacja muzyczna ma fokus, a aplikacja do nawigacji prosi o fokus, to macierz wskazuje, że te 2 interakcje mogą działać jednocześnie, o ile tylko są spełnione inne kryteria jednoczesnych interakcji.
Ze względu na jednoczesne interakcje może być więcej niż 1 element na pierwszym planie. W takim przypadku przychodzące żądanie fokusa jest porównywane z każdym z bieżących posiadaczy fokusa, zanim zostanie wybrana interakcja. W tym przypadku zwycięża najbardziej zachowawcza interakcja. Odrzucanie, a potem wyłączanie i wreszcie równoczesne.
Rysunek 1. Macierz interakcji z aktywną treścią audio.
Nawigacja podczas rozmów telefonicznych
W Androidzie 11 wprowadzono nowe ustawienie, które pozwala użytkownikom zmieniać sposób interakcji między nawigacją a połączeniami telefonicznymi. Gdy jest ustawiona,
android.car.KEY_AUDIO_FOCUS_NAVIGATION_REJECTED_DURING_CALL
zmienia interakcję między przychodzącymi NAVIGATION
prośbami o skupienie a obecnymi CALL
posiadaczami uprawnień ze równoległych na odrzucane. Jeśli użytkownik woli, aby wskazówki nawigacyjne nie przerywały połączenia, może włączyć to ustawienie. Jest ono przechowywane dla użytkownika i może być ustawiane dynamicznie, tak aby kolejne żądania fokusa uwzględniały nowe ustawienie.
Możliwość opóźnienia aktywacji trybu pełnej koncentracji
W Androidzie 11 dodano obsługę żądania opóźnionego skupienia na dźwięku. Dzięki temu prośby o utrzymanie miejsca na liście można opóźnić, gdy ich interakcja z obecnymi posiadaczami miejsca na liście spowoduje ich odrzucenie. Gdy zmiana stanu skupienia spowoduje, że opóźniona prośba może zostać wykonana, prośba zostanie zaakceptowana.
Zasady dotyczące opóźnionych żądań dostępu do mikrofonu
Tylko żądania nieprzelotne. Prośba o opóźnienie może dotyczyć tylko źródeł nieprzelotnych, aby uniknąć odtwarzania dźwięku przelotnego przez długi czas po jego zakończeniu.
Jednocześnie można opóźnić tylko jedno żądanie. Jeśli opóźnione żądanie zostanie wysłane, gdy opóźnione żądanie jest już opóźnione, pierwotne opóźnione żądanie otrzyma zdarzenie zmiany
AUDIOFOCUS_LOSS
, a nowe żądanie otrzyma asynchroniczną odpowiedźAUDIOFOCUS_REQUEST_DELAYED
.Prośby o opóźnienie muszą mieć wartość
OnAudioFocusChangeListener
. Gdy prośba zostanie opóźniona, listener służy do powiadamiania osoby wysyłającej prośbę, gdy prośba zostanie ostatecznie rozpatrzona (AUDIOFOCUS_GAIN
) lub odrzucona (AUDIOFOCUS_LOSS
).
Prośba o opóźnienie fokusa
Aby utworzyć prośbę, która może zostać opóźniona:
Użyj konta
AudioFocusRequest.Builder#setAcceptsDelayedFocusGain
.mMediaWithDelayedFocusListener = new MediaWithDelayedFocusListener(); mDelayedFocusRequest = new AudioFocusRequest .Builder(AudioManager.AUDIOFOCUS_GAIN) .setAudioAttributes(mMusicAudioAttrib) .setOnAudioFocusChangeListener(mMediaWithDelayedFocusListener) .setForceDucking(false) .setWillPauseWhenDucked(false) .setAcceptsDelayedFocusGain(true) .build();
Gdy przesyłasz prośbę, postępuj zgodnie z instrukcjami podanymi w odpowiedzi
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; }
Gdy żądanie jest opóźnione, odbiorca focusa obsługuje zmiany w fokusie:
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
Wymuszony przez system efekt znikania
Android 15 wprowadza systemowe wyciszanie dźwięku w AAOS. W Androidzie tryb dźwięku nie jest wymuszony przez system. Chociaż zachęcamy deweloperów aplikacji do przestrzegania wytycznych dotyczących dźwięku, jeśli aplikacja nadal odtwarza dźwięk nawet po utracie fokusu dźwięku, system nie może temu zapobiec.
W środowiskach samochodowych, w których liczy się bezpieczeństwo, zachowanie skupienia na dźwięku jest kluczowe dla zminimalizowania rozpraszania uwagi kierowcy. Dzięki tej funkcji system audio automatycznie wycisza aplikacje, które tracą nacisk dźwiękowy, co zapewnia większą kontrolę i przewidywalność dźwięku.
To ulepszenie pomaga zapewnić, aby aplikacje przestrzegały decyzji o utracie skupienia na dźwięku określonej przez macierz interakcji, co zapobiega konfliktom podczas odtwarzania dźwięku.
Projektowanie ogólne
Na rysunku poniżej widać ogólny projekt i obsługę funkcji utraty ostrości w samochodach:
Rysunek 2. Ogólny projekt funkcji wygaszania sterowanej przez system.
- Celowane wyciszanie: systemowe wyciszanie w Androidzie 15 zostało zaprojektowane specjalnie do sytuacji, w których aplikacja traci na chwilę fokus audio, ale nadal odtwarza dźwięk.
- Mechanizm wyciszania: gdy aplikacja traci fokus audio na rzecz nowej aplikacji:
- System audio automatycznie wyciszy dźwięk z aplikacji, która przestaje być aktywna.
- Po zakończeniu ścieżki dźwiękowej system wycisza strumień audio.
- Aplikacja otrzymuje wtedy powiadomienie o utracie dostępu do dźwięku.
- Aplikacje, które nie działają prawidłowo, są wyciszone, dopóki nie odzyskają kontroli nad dźwiękiem.
- Domyślna logika polega na włączaniu aplikacji, które są przyciemnione po 2 sekundach. Producenci OEM mogą jednak skonfigurować dowolną wartość czasu oczekiwania.
- Platforma audio używa konfiguracji OEM zarówno do operacji zanikania, jak i powrotu dźwięku.
Plik konfiguracji OEM: Android 15 zawiera nowy plik konfiguracji:
car_audio_fade_configuration.xml
- Ten plik umożliwia OEM-om zdefiniowanie kryteriów, według których system będzie stosował mechanizm ochrony dźwięku w przypadku aplikacji, która traci fokus.
- System audio wymusza wyciszenie tylko wtedy, gdy aplikacja, która przegrywa, spełnia określone przez producenta reguły w pliku XML.
- Umożliwia to OEM-om dostosowanie działania funkcji na podstawie cech aplikacji lub typów wykorzystania dźwięku.
Kontrola funkcji za pomocą RRO: dodano nowy parametr funkcji nakładki zasobów w czasie wykonywania (RRO)
audioUseFadeManagerConfiguration
, który umożliwia włączanie i wyłączanie tej funkcji:- Ta funkcja jest domyślnie wyłączona.
- Aby włączyć systemowe usuwanie dźwięku, OEM muszą ustawić tę flagę na
true
. - Chociaż framework audio samochodowego oczekuje prawidłowych definicji konfiguracji zanikania, gdy flaga jest włączona, brak takich definicji nie powoduje automatycznie krytycznego wyjątku.
- Wszystkie aplikacje z konfiguracją zanikania muszą mieć pasujące definicje zanikania. Błąd krytyczny: wywołanie konfiguracji zanikania (pod jej nazwą) w ramach konfiguracji audio samochodu bez podania prawidłowej definicji.
- Gdy flaga jest wyłączona, wszystkie definicje konfiguracji wygładzania i wszelkie odniesienia do konfiguracji są ignorowane.
Konfiguracja menedżera ściemniania
System Android 15 wprowadza ujednolicony interfejs FadeManagerConfiguration
, aby zapewnić producentom OEM precyzyjne sterowanie zachowaniem ścieżki dźwiękowej. Ten schemat przedstawia rysunek 3:
Rysunek 3. Konfiguracja menedżera ściemniania.
Ta konfiguracja obejmuje:
- Właściwości przejścia z efektem zanikania: ustawienia zanikania i pojawiania się.
- Może być zdefiniowany za pomocą określonych zastosowań lub atrybutów dźwięku.
- Umożliwia ustawienie niestandardowego czasu trwania.
- Te ustawienia służą do tworzenia
VolumeShaper.Configuration
.
- Zasady dotyczące zaniżania: reguły określające, kiedy następuje zanik.
- Przełącznik globalny do włączania i wyłączania zanikania.
- Konfigurowalna lista zastosowań dźwięku, które można wygłuszyć (można je wygłuszyć po utracie fokusu).
- Listy wykluczeń (niezmienialne) zapobiegają wyciszeniu kluczowych lub określonych źródeł dźwięku. Listy te mogą być tworzone na podstawie:
- Rodzaje treści
- Atrybuty dźwięku
- UID aplikacji (można ustawić tylko w czasie działania)
Konfiguracje OEM
W tej sekcji omawiamy dostępne opcje dostosowywania OEM.
Plik XML konfiguracji ścieżki dźwiękowej w samochodzie
Android 15 wprowadza nowy plik konfiguracji car_audio_fade_configuration.xml
, który umożliwia producentom OEM większą personalizację zachowania dźwięku podczas utraty fokusu.
- Ten plik XML umożliwia zdefiniowanie wielu różnych konfiguracji wygładzenia, z których każda wymaga unikalnej nazwy do porównań w pliku
car_audio_configuration.xml
. - Te konfiguracje można elastycznie stosować w różnych strefach dźwięku i konfiguracjach stref.
- Należy pamiętać, że każda konfiguracja zanikania akceptuje tylko wartości czasu trwania w milisekundach, które system wykorzystuje do wewnętrznego generowania odpowiedniego
VolumeShaper.Configuration
.
Praktyczne wskazówki dotyczące implementacji znajdziesz w przykładowych konfiguracjach dla emulatora, które znajdziesz na stronie device/generic/car/emulator/audio/car_audio_fade_configuration.xml
.
Plik XML konfiguracji dźwięku w samochodzie
Android 15 wprowadza zaktualizowany plik car_audio_configuration.xml
w wersji 4, który zawiera nowe tagi applyFadeConfigs
i fadeConfig
.
Tag applyFadeConfigs
może zawierać wiele definicji fadeConfig
, co umożliwia elastyczne konfigurowanie efektu wygładzenia. Każda definicja:
- Musi zawierać 1 domyślny element
fadeConfig
oznaczony jakoisDefault = true
. - Może zawierać kilka przejściowych definicji
fadeConfig
. Te przejściowe konfiguracje są stosowane podczas interakcji z utratą audio focus, i tylko wtedy, gdy aplikacja, która zyskała audio focus, spełnia kryteria zdefiniowane w konfiguracji przejściowej.
Praktyczne wskazówki dotyczące implementacji znajdziesz w przykładowych konfiguracjach dla emulatora, które są dostępne na stronie device/generic/car/emulator/audio/car_audio_configuration.xml
.
Rozszerzenie usługi OEM dotyczące dźwięku
Producenci oryginalnego wyposażenia, którzy implementują niestandardową usługę dźwięku w samochodzie, mogą dowolnie konfigurować ustawienia ścieżki dźwiękowej, uwzględniając je w OemCarAudioFocusResult
.
Można to zrobić za pomocą metody setAudioAttributesToCarAudioFadeConfigurationMap()
w narzędziu do tworzenia:
/** @see OemCarAudioFocusResult#getAudioAttributesToCarAudioFadeConfigurationMap() **/
@NonNull
public Builder setAudioAttributesToCarAudioFadeConfigurationMap(@NonNull
Map<AudioAttributes, CarAudioFadeConfiguration> attrsToCarAudioFadeConfig) {
}
Producenci OEM mogą używać wstępnie skonfigurowanych ustawień wygładzania podczas uruchamiania lub stosować konfiguracje dynamicznie za pomocą niestandardowej usługi skupienia na dźwięku, która zapewnia elastyczne sterowanie.
Schemat sekwencji
Ten diagram sekwencji przedstawia zachowanie po przyznaniu uprawnień do skupienia dźwięku aplikacji App2
i subsequentnej utraty uprawnień do skupienia dźwięku przez aplikację App1
:
- Gdy usługa audio w samochodzie wysyła do
App1
wiadomość o utracie skupienia na dźwięku, odtwarzanie z odtwarzaczaApp1
zostaje wygłuszone zgodnie z aktywnymiFadeManagerConfiguration
. Po zakończeniu operacji zanikania funkcjaApp1
otrzymuje standardowe wywołanie zwrotne po utracie fokusu dźwięku. - Opcjonalnie dźwięk
App1
może być przywrócony po określonym czasie. Producenci OEM mogą elastycznie określać czas trwania tego okresuBuilder#setFadeInDurationForUsage(int, long)
zgodnie ze specyfikacją swoich produktów.
Rysunek 4. Schemat sekwencji funkcji ściszania dźwięku w samochodzie.
Zarządzanie strefami fokusowania
W przypadku pojazdów z wieloma strefami dźwiękowymi można zarządzać dźwiękiem w każdej strefie niezależnie. W związku z tym żądanie wysłane do jednej strefy nie uwzględnia tego, co ma fokus w innych strefach, ani nie powoduje utraty fokusu przez inne strefy. Dzięki temu można zarządzać fokusem w głównej kabinie niezależnie od systemu rozrywki na tylnym siedzeniu, nie przerywając odtwarzania dźwięku w danej strefie przez zmiany w fokusie.
W przypadku wszystkich aplikacji funkcja CarAudioService
automatycznie zarządza trybem skupienia. Strefa audio żądania fokusowego jest określana przez powiązany z nim UserId
lub UID
(szczegóły znajdziesz w artykule Przekierowanie dźwięku w wielu strefach).
Prośba o dźwięk z wielu stref jednocześnie
Jeśli aplikacja chce odtwarzać dźwięk w kilku strefach jednocześnie, musi poprosić o skupienie dla każdej strefy, dodając AUDIOFOCUS_EXTRA_REQUEST_ZONE_ID
do pakietu:
//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
Ten parametr pakietu umożliwia zastąpienie automatycznych mapowania stref dźwięku, aby zamiast tego używać określonego identyfikatora strefy. Aplikacja może więc wysyłać oddzielne żądania dotyczące różnych stref dźwięku.
Aktywność audio HAL
Od Androida 11 interfejs HAL może prosić o skupienie uwagi w imieniu strumieni zewnętrznych. Korzystanie z tych interfejsów API jest opcjonalne, ale zdecydowanie zalecamy je, aby umożliwić zewnętrznym dźwiękom prawidłowe działanie w ekosystemie Androida i zapewnienie płynnych wrażeń użytkownikom.
HAL podejmuje ostateczną decyzję, które dźwięki mają mieć priorytet. W tym zakresie dźwięki alarmowe i dźwięki związane z bezpieczeństwem powinny być odtwarzane niezależnie od tego, czy HAL ma przydzielone skupienie dźwiękowe, i powinny być odtwarzane odpowiednio nawet wtedy, gdy HAL utraci skupienie dźwiękowe. To samo dotyczy dźwięków wymaganych przez przepisy państwowe.
HAL powinien proaktywnie wyciszać strumienie Androida w odpowiednich momentach podczas odtwarzania dźwięków alarmowych lub dźwięków związanych z bezpieczeństwem, aby zapewnić ich wyraźny dźwięk.
[email protected]
Wersja 2.0 interfejsu AudioControl HAL wprowadza te nowe interfejsy API:
Interfejs API | Cel |
---|---|
IAudioControl#registerFocusListener |
Rejestruje wystąpienie IFocusListener w AudioControl HAL. Ten odbiornik umożliwia HAL żądanie i rezygnację z koncentracji na dźwięku. HAl udostępnia instancję ICloseHandle , która jest używana przez Androida do wyrejestrowania słuchacza. |
IAudioControl#onAudioFocusChange |
Informuje HAL o zmianach stanu żądań dotyczących punktu skupienia, które zostały przesłane przez HAL za pomocą IFocusListener , w tym o odpowiedziach na początkowe żądania dotyczące punktu skupienia. |
IFocusListener#requestAudioFocus |
Prośby o skupienie w imieniu HAL w przypadku określonego sposobu użycia, identyfikatora strefy i typu wzmocnienia ostrości. |
IFocusListener#abandonAudioFocus |
powoduje porzucenie istniejących żądań skupienia HAL dla określonego użycia i identyfikatora strefy. |
HAL może mieć wiele żądań naraz, ale jest ograniczony do jednego żądania na parę identyfikatorów ID użytkowania i strefy. Android zakłada, że HAL natychmiast rozpoczyna odtwarzanie dźwięków po wysłaniu żądania i kontynuuje to do momentu utraty fokusu.
Oprócz registerFocusListener
te żądania są oneway
, aby zapewnić, że Android nie opóźnia HAL podczas przetwarzania żądania focus. HAL nie powinien czekać na uzyskanie fokusa przed odtworzeniem dźwięków istotnych dla bezpieczeństwa. HAL może opcjonalnie słuchać i reagować na zmiany w fokusie audio za pomocą IAudioControl#onAudioFocusChange
.
Usługa OEM dotycząca samochodowego systemu audio
W Androidzie 14 system AAOS wprowadził usługi wtyczek OEM, aby umożliwić konfigurowanie niektórych komponentów samochodu. W przypadku usługi wtyczki Car Audio Plugin Service usługa wtyczki umożliwia OEM-om zarządzanie żądaniami fokusowania przechwyconymi przez usługę dźwięku w samochodzie. Daje to producentom OEM większą elastyczność w zarządzaniu punktem skupienia zgodnie z wymaganiami przepisów i regulacji. W związku z tym interakcja z fokusem audio może się różnić w zależności od producenta i regionu. Podstawowa zasada dotycząca skupienia na dźwięku nadal obowiązuje, co oznacza, że aplikacje powinny nadal prosić o skupienie, aby lepiej zarządzać dźwiękiem i poprawiać wrażenia użytkownika. Ogólnie w przypadku żądań dotyczącego dźwięku w tle obowiązują określone zasady:
Bez stałego priorytetu dźwięku o wysokiej ważności (w tym połączenia telefoniczne, alerty alarmowe i powiadomienia o zabezpieczeniu) aplikacje powinny mieć możliwość uzyskania priorytetu dźwięku w sposób tymczasowy lub stały.
Gdy aktywny jest priorytet multimediów:
Aplikacje, które wymagają skupienia się na obsłudze połączeń, powinny mieć możliwość odbierania połączeń albo równocześnie, albo wyłącznie.
Aplikacje, które wymagają zaznaczenia, powinny mieć możliwość otrzymania zaznaczenia w tym samym czasie lub wyłącznie.
Aplikacje, które wymagają skupienia się na korzystaniu z asystenta, powinny mieć możliwość uzyskania takiego skupienia albo równocześnie, albo wyłącznie.
Gdy aktywne są aplikacje o wysokim priorytecie (np. aplikacja do obsługi połączeń, alertów o stanie alarmowym lub powiadomień o bezpieczeństwie), należy zezwolić na przychodzące opóźnione prośby o udzielenie dostępu do dźwięku lub opóźnić je w razie potrzeby.
Chociaż te sugestie nie są wyczerpujące, mogą pomóc aplikacjom proszącym o skupienie się w przypadku braku aktywnych dźwięków o wysokim priorytecie. Nawet gdy dźwięki o wysokim priorytecie są aktywne, opóźnione żądania dotyczące fokusa powinny być nadal respektowane i powinny mieć możliwość uzyskania fokusa, gdy dźwięk o wysokim priorytecie przestanie działać.