Aktywność audio

Przed rozpoczęciem strumienia logicznego aplikacja wysyła żądanie fokusu dźwięku, używając tych samych atrybutów dźwięku co strumień logiczny. Aby aplikacja działała zgodnie z oczekiwaniami w przypadku zastosowań w motoryzacji, musi reagować na utratę fokusu.

Wysyłanie żądania ostrości jest zalecane, ale nie jest wymuszane przez system. Dlatego traktuj fokus jako sposób na pośrednie kontrolowanie i unikanie konfliktów podczas odtwarzania, a nie jako podstawowy mechanizm sterowania dźwiękiem. Działanie podsystemu audio nie powinno zależeć od systemu ostrości.

Interakcje z zaznaczeniem

Aby obsługiwać AAOS, żądania fokusu audio są obsługiwane na podstawie wstępnie zdefiniowanych interakcji między CarAudioContext żądania a bieżącymi posiadaczami fokusu. Istnieją 3 rodzaje interakcji:

  • Tylko wybrani użytkownicy
  • Odrzuć
  • Równoczesne

Wyłączna interakcja

Jest to model interakcji najczęściej używany w Androidzie.

W przypadku interakcji wyłącznych tylko jedna aplikacja może być aktywna w danym momencie. Dlatego przychodzące żądanie ostrości uzyskuje ostrość, a dotychczasowy posiadacz ostrości ją traci. Ponieważ obie aplikacje odtwarzają multimedia, tylko jedna z nich może mieć fokus. W rezultacie żądanie fokusu nowo uruchomionej aplikacji jest zwracane z wartością AUDIOFOCUS_REQUEST_GRANTED, a obecnie odtwarzana aplikacja muzyczna otrzymuje zdarzenie zmiany fokusu ze stanem utraty, który odpowiada typowi wysłanego żądania.

Odrzucanie interakcji

W przypadku interakcji odrzucania przychodząca prośba jest zawsze odrzucana. Na przykład podczas próby odtworzenia muzyki w trakcie rozmowy. W tym przypadku, jeśli aplikacja Telefon ma fokus audio podczas połączenia, a druga aplikacja poprosi o fokus, aby odtwarzać muzykę, w odpowiedzi na żądanie otrzyma AUDIOFOCUS_REQUEST_FAILED. Ponieważ prośba o skupienie została odrzucona, do bieżącego elementu, który ma fokus, nie jest wysyłana informacja o utracie fokusu.

Równoczesna interakcja

W przypadku AAOS unikalne są interakcje równoczesne. Dzięki temu aplikacje, które proszą o skupienie dźwięku w samochodzie, mogą utrzymywać je jednocześnie z innymi aplikacjami. Aby doszło do interakcji równoczesnej, muszą być spełnione te warunki: W:

Jeśli te kryteria są spełnione, żądanie ostrości zwraca wartość AUDIOFOCUS_REQUEST_GRANTED, a bieżący posiadacz ostrości nie zmienia ostrości. Jeśli jednak bieżący odbiorca fokusu zdecyduje się na otrzymywanie zdarzeń „duck” lub wstrzymanie odtwarzania, gdy nastąpi wyciszenie, utraci fokus, tak jak w przypadku interakcji wyłącznej.

Obsługa równoczesnych strumieni

Równoczesna interakcja ma wiele zastosowań, ale należy zachować ostrożność podczas miksowania i przyciszania na poziomie sprzętowym na różnych 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 oddzielnym urządzeniom wyjściowym dla równoczesnych strumieni HAL może wyciszyć jeden ze strumieni przed ich zmiksowaniem lub przekierować strumienie fizyczne do różnych głośników w pojeździe. Jeśli strumienie logiczne są mieszane w Androidzie, wzmocnienie pozostaje niezmienione i jest dostarczane w ramach tego samego strumienia fizycznego.

Na przykład gdy 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. Strumień nawigacji może być też kierowany do głośników po stronie kierowcy, a multimedia mogą być odtwarzane w pozostałej części kabiny.

Macierz interakcji

Ta tabela przedstawia macierz interakcji zdefiniowaną przez CarAudioService. Każdy wiersz reprezentuje CarAudioContext bieżącego posiadacza fokusu, a każda kolumna – żądanie przychodzące.

Na przykład, gdy aplikacja do odtwarzania muzyki jest aktywna, a aplikacja do nawigacji żąda aktywacji, macierz wskazuje, że te 2 interakcje mogą występować jednocześnie, pod warunkiem że spełnione są pozostałe kryteria interakcji równoczesnych.

Ze względu na równoczesne interakcje może być więcej niż 1 element, który ma fokus. W takim przypadku przychodzące żądanie fokusu jest porównywane z każdym z obecnych posiadaczy fokusu, zanim zostanie określona interakcja, którą należy zastosować. W tym przypadku wygrywa interakcja o najbardziej zachowawczym charakterze. Odrzucanie, a potem wyłączność i w końcu współbieżność.

Macierz interakcji aktywności audio

Rysunek 1. Macierz interakcji aktywności audio.

W Androidzie 11 wprowadziliśmy nowe ustawienie użytkownika, które pozwala zmieniać sposób interakcji między nawigacją a połączeniami telefonicznymi. Gdy ta opcja jest ustawiona, android.car.KEY_AUDIO_FOCUS_NAVIGATION_REJECTED_DURING_CALL zmienia interakcję między przychodzącymi żądaniami fokusu NAVIGATION a bieżącymi posiadaczami fokusu CALLjednoczesnej na odrzucanie. Jeśli użytkownik woli, aby instrukcje nawigacyjne nie przerywały połączenia, może włączyć to ustawienie. To ustawienie jest zachowywane dla użytkownika i może być ustawiane dynamicznie, tak aby kolejne żądania ostrości uwzględniały nowe ustawienie.

Aktywność audio z możliwością opóźnienia

W Androidzie 11 AAOS dodano obsługę żądania opóźnionego fokusu dźwięku. Dzięki temu nietrwałe żądania fokusu mogą być opóźniane, gdy ich interakcja z obecnymi posiadaczami fokusu zwykle powodowałaby ich odrzucenie. Gdy zmiana fokusu spowoduje, że opóźnione żądanie będzie mogło uzyskać fokus, zostanie ono przyznane.

Reguły dotyczące opóźnionych żądań fokusu audio

  • Tylko żądania nietrwałe. Opóźnioną prośbę można wysłać tylko w przypadku nietrwałych źródeł, aby uniknąć odtwarzania dźwięku przez dłuższy czas po jego wygaśnięciu.

  • Jednorazowo można opóźnić tylko 1 prośbę. Jeśli w momencie, gdy jest już opóźnione żądanie, zostanie wysłane żądanie, które można opóźnić, pierwotne opóźnione żądanie otrzyma zdarzenie zmiany AUDIOFOCUS_LOSS, a nowe żądanie otrzyma synchroniczną odpowiedź AUDIOFOCUS_REQUEST_DELAYED.

  • Żądania, które można opóźnić, muszą mieć wartość OnAudioFocusChangeListener. Gdy żądanie zostanie opóźnione, odbiornik powiadomi osobę wysyłającą prośbę, gdy żądanie zostanie ostatecznie przyznane (AUDIOFOCUS_GAIN) lub odrzucone (AUDIOFOCUS_LOSS).

Żądanie zaznaczenia z możliwością opóźnienia

Aby utworzyć żądanie, które można opóźnić:

  1. 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();
    
  2. Podczas wysyłania żądania obsługuj odpowiedź 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. Gdy żądanie jest opóźnione, odbiornik fokusu obsługuje zmiany fokusu:

    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
    

Wymuszone przez system wyciszenie

Android 15 wprowadza w AAOS wymuszane przez system stopniowe zwiększanie głośności dźwięku. W Androidzie system nie wymusza skupienia dźwięku. Dlatego zachęcamy deweloperów aplikacji do przestrzegania wytycznych dotyczących fokusu audio, ale jeśli aplikacja nadal odtwarza dźwięk głośno nawet po utracie fokusu audio, system nie może temu zapobiec.

W środowiskach motoryzacyjnych o krytycznym znaczeniu dla bezpieczeństwa przestrzeganie zasad dotyczących fokusu dźwięku jest niezbędne, aby zminimalizować rozproszenie uwagi kierowcy. Dzięki tej funkcji platforma audio automatycznie wycisza aplikacje, które utraciły fokus audio, co zapewnia większą kontrolę i przewidywalność dźwięku.

To ulepszenie pomaga zapewnić, że aplikacje będą przestrzegać decyzji o utracie fokusu dźwięku zgodnie z macierzą interakcji, co zapobiega konfliktom odtwarzania dźwięku.

Projekt wysokiego poziomu

Na rysunku poniżej przedstawiono ogólny projekt i obsługę funkcji utraty ostrości w samochodach:

Projekt wysokiego poziomu funkcji zanikania wymuszanej przez system

Rysunek 2. Projekt wysokiego poziomu funkcji zanikania wymuszonego przez system.

  • Ukierunkowane wyciszanie: systemowe wyciszanie w Androidzie 15 zostało zaprojektowane specjalnie z myślą o sytuacjach, w których aplikacja traci fokus audio, ale nadal odtwarza dźwięk.
  • Mechanizm wyciszania: gdy aplikacja traci fokus audio na rzecz nowej aplikacji, która o to poprosiła:
    • Framework audio automatycznie wycisza dźwięk aplikacji, która przegrywa.
    • Po wyciszeniu strumień audio jest wyciszany przez system.
    • Aplikacja otrzymuje powiadomienie o utracie fokusu dźwięku.
    • Aplikacje, które nie działają prawidłowo, są wyciszane do momentu, aż odzyskają fokus dźwięku.
    • Domyślna logika polega na przywracaniu aplikacji, które zostały wygaszone, po 2 sekundach. Producenci OEM mogą jednak skonfigurować dowolną wartość czasu oczekiwania.
    • Platforma audio korzysta z konfiguracji OEM zarówno w przypadku wyciszania, jak i w przypadku zwiększania głośności.
  • Plik konfiguracyjny OEM: Android 15 zawiera nowy plik konfiguracyjny:car_audio_fade_configuration.xml

    • Ten plik umożliwia producentom OEM określanie kryteriów, zgodnie z którymi systemowe egzekwowanie fokusu audio jest stosowane do aplikacji, która go utraciła.
    • Platforma audio wymusza wyciszanie i wygaszanie tylko wtedy, gdy aplikacja, która traci fokus, spełnia reguły zdefiniowane przez producenta OEM w tym pliku XML.
    • Dzięki temu producenci OEM mogą dostosowywać działanie tej funkcji do charakterystyki aplikacji lub typów użycia dźwięku.
  • Kontrolowanie funkcji za pomocą RRO: wprowadziliśmy nową flagę nakładki zasobów w czasie działania (RRO) – audioUseFadeManagerConfiguration –, która umożliwia włączanie i wyłączanie tej funkcji:

    • Ta funkcja jest domyślnie wyłączona.
    • Aby aktywować wymuszane przez system utratę ostrości dźwięku, producenci OEM muszą ustawić tę flagę na true.
    • Chociaż platforma audio w samochodzie oczekuje prawidłowych definicji konfiguracji zanikania, gdy flaga jest włączona, brak takich definicji nie powoduje automatycznie wyjątku krytycznego.
    • Wszystkie aplikacje konfiguracji zanikania muszą mieć pasujące definicje zanikania. Wywołanie konfiguracji zanikania (według nazwy) w ramach konfiguracji dźwięku w samochodzie bez podania prawidłowej definicji jest błędem krytycznym.
    • Gdy flaga jest wyłączona, wszystkie definicje konfiguracji zanikania i wszystkie odwołania do konfiguracji są ignorowane.

Konfiguracja menedżera zanikania

W ramach struktury audio w Androidzie 15 wprowadzono ujednolicony FadeManagerConfiguration , który zapewnia producentom OEM szczegółową kontrolę nad zachowaniem związanym z wyciszaniem dźwięku. Ten schemat jest przedstawiony na rysunku 3:

Konfiguracja menedżera zanikania

Rysunek 3. Konfiguracja menedżera zanikania.

Ta konfiguracja obejmuje:

  • Właściwości przejścia z efektem zanikania: ustawienia zanikania i pojawiania się.
    • Można je zdefiniować za pomocą konkretnych zastosowań lub atrybutów dźwięku.
    • Umożliwia dostosowanie ustawień czasu trwania.
    • Te ustawienia służą do tworzenia VolumeShaper.Configuration.
  • Zasady zanikania: reguły określające, kiedy następuje zanikanie.
    • Globalny przełącznik włączający i wyłączający zanikanie.
    • Konfigurowalna lista zastosowań dźwięku, które można wyciszyć (kwalifikują się do wyciszenia po utracie fokusu).
    • Listy wykluczeń (nieznikające) zapobiegają wyciszaniu ważnych lub wyznaczonych źródeł dźwięku. Listy te mogą być tworzone na podstawie:
      • Rodzaje treści
      • Atrybuty audio
      • Identyfikatory UID aplikacji (można je ustawić tylko w czasie działania)

Konfiguracje OEM

W tej sekcji przyjrzymy się dostępnym opcjom dostosowywania przez producentów OEM.

Plik XML konfiguracji zanikania dźwięku w samochodzie

Android 15 wprowadza nowy plik konfiguracyjny, car_audio_fade_configuration.xml, który umożliwia producentom OEM rozbudowane dostosowywanie zachowania wyciszania dźwięku podczas utraty fokusu.

  • Ten plik XML umożliwia zdefiniowanie wielu różnych konfiguracji zanikania, z których każda wymaga unikalnej nazwy do odwoływania się w car_audio_configuration.xml.
  • Te konfiguracje można elastycznie stosować w różnych strefach audio i konfiguracjach stref.
  • 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 emulatora dostępnych pod adresem 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 applyFadeConfigsfadeConfig. Tag applyFadeConfigs może zawierać wiele definicji fadeConfig, co umożliwia elastyczną konfigurację zanikania. Każda definicja:

  • Musi zawierać jeden domyślny element fadeConfig oznaczony symbolem isDefault = true.
  • Może zawierać kilka definicji przejściowych fadeConfig. Te tymczasowe konfiguracje są stosowane w szczególności podczas interakcji związanych z utratą fokusu dźwięku i tylko wtedy, gdy aplikacja uzyskująca fokus dźwięku spełnia kryteria określone w konfiguracji tymczasowej.

Praktyczne wskazówki dotyczące implementacji znajdziesz w przykładowych konfiguracjach emulatora dostępnych pod adresem device/generic/car/emulator/audio/car_audio_configuration.xml.

Rozszerzenie usługi OEM audio focus

Producenci OEM, którzy wdrażają niestandardową usługę skupienia dźwięku w samochodzie, mogą konfigurować ustawienia wyciszania dźwięku, umieszczając je w OemCarAudioFocusResult. Można to osiągnąć za pomocą metody tworzenia setAudioAttributesToCarAudioFadeConfigurationMap():

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

Producenci OEM mogą używać wstępnie skonfigurowanych ustawień wyciszania podczas uruchamiania lub dynamicznie stosować konfiguracje za pomocą niestandardowej usługi ostrości dźwięku, co zapewnia elastyczną kontrolę.

Schemat sekwencji

Ten diagram sekwencji ilustruje zachowanie po przyznaniu fokusu audio aplikacji App2 i późniejszej utracie fokusu audio przez aplikację App1:

  • Gdy usługa audio w samochodzie wyśle do App1 informację o utracie fokusu audio, odtwarzanie z odtwarzacza App1 zostanie wyciszone zgodnie z aktywnymi FadeManagerConfiguration. Po zakończeniu operacji wyciszania App1otrzymuje standardowe wywołanie zwrotne utraty fokusu dźwięku.
  • Opcjonalnie dźwięk App1 może być przywracany po skonfigurowanym czasie trwania. Producenci OEM mogą ustawić ten czas za pomocą Builder#setFadeInDurationForUsage(int, long) zgodnie ze swoimi wymaganiami dotyczącymi konkretnych produktów.

Schemat sekwencji funkcji wyciszania dźwięku w samochodzie

Rysunek 4. Diagram sekwencji funkcji ściszania dźwięku w samochodzie.

Zarządzanie ostrością w wielu strefach

W przypadku pojazdów z kilkoma strefami audio zarządzanie ostrością dźwięku odbywa się niezależnie w każdej strefie. W związku z tym żądanie wysłane do jednej strefy nie uwzględnia tego, co jest aktywne w innych strefach, ani nie powoduje utraty aktywności w innych strefach. Dzięki temu można zarządzać dźwiękiem w głównej kabinie niezależnie od systemu rozrywki na tylnych siedzeniach, co oznacza, że zmiany w jednej strefie nie będą przerywać odtwarzania dźwięku w innej.

W przypadku wszystkich aplikacji CarAudioService automatycznie zarządza ostrością. Strefa audio żądania ustawienia ostrości jest określana przez powiązany z nim element UserId lub UID (szczegółowe informacje znajdziesz w sekcji Routing dźwięku do wielu stref).

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 w każdej z nich, umieszczając w pakiecie element AUDIOFOCUS_EXTRA_REQUEST_ZONE_ID:

//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 osobie wysyłającej żądanie zastąpienie automatycznych mapowań strefy audio i użycie określonego identyfikatora strefy. Dlatego aplikacja może wysyłać oddzielne żądania dotyczące różnych stref audio.

Aktywność audio HAL

Od Androida 11 HAL może żądać ostrości w imieniu strumieni zewnętrznych. Korzystanie z tych interfejsów API jest opcjonalne, ale wysoce zalecane, aby umożliwić optymalne działanie dźwięków zewnętrznych w ekosystemie Androida i zapewnić użytkownikom spójne wrażenia.

HAL ostatecznie decyduje, które dźwięki powinny mieć priorytet. Dlatego dźwięki związane z bezpieczeństwem i sytuacjami awaryjnymi powinny być odtwarzane niezależnie od tego, czy HAL ma fokus audio, i powinny być odtwarzane w odpowiedni sposób nawet wtedy, gdy HAL utraci fokus audio. To samo dotyczy dźwięków wymaganych przez przepisy państwowe.

HAL powinien aktywnie wyciszać strumienie Androida w odpowiednich sytuacjach podczas odtwarzania dźwięków alarmowych lub krytycznych dla bezpieczeństwa, aby zapewnić ich wyraźne słyszenie.

AudioControl@2.0

Wersja 2.0 interfejsu HAL AudioControl wprowadza te nowe interfejsy API:

Interfejs API Cel
IAudioControl#registerFocusListener Rejestruje instancję IFocusListener w warstwie HAL AudioControl. Ten odbiornik umożliwia HAL-owi żądanie i zwalnianie fokusu audio. HAL udostępnia instancję ICloseHandle, która jest używana przez Androida do wyrejestrowania odbiornika.
IAudioControl#onAudioFocusChange Powiadamia HAL o zmianach stanu żądań ostrości wysyłanych przez HAL za pomocą interfejsu IFocusListener, w tym o odpowiedziach na początkowe żądania ostrości.
IFocusListener#requestAudioFocus Żądania są wysyłane w imieniu HAL w określonym celu, z określonym identyfikatorem strefy i określonym typem wzmocnienia ostrości.
IFocusListener#abandonAudioFocus Porzuca istniejące żądania ostrości HAL dla określonego zastosowania i strefy.

Warstwa HAL może obsługiwać wiele żądań ostrości jednocześnie, ale jest ograniczona do jednego żądania na parę identyfikatorów zastosowania i strefy. Android zakłada, że HAL natychmiast zaczyna odtwarzać dźwięki dla danego zastosowania po otrzymaniu żądania i kontynuuje to, dopóki nie zrezygnuje z fokusu.

Oprócz registerFocusListener te żądania są oneway, aby Android nie opóźniał HAL podczas przetwarzania żądania ostrości. Warstwa HAL nie powinna czekać na uzyskanie fokusu przed odtworzeniem dźwięków o krytycznym znaczeniu dla bezpieczeństwa. Słuchanie zmian fokusu dźwięku i reagowanie na nie za pomocą funkcji IAudioControl#onAudioFocusChange jest opcjonalne dla HAL.

Usługa aktywności audio w samochodzie OEM

W Androidzie 14 w AAOS wprowadzono usługi wtyczek OEM, które umożliwiają konfigurowanie niektórych komponentów samochodu. W przypadku usługi wtyczki audio w samochodzie usługa wtyczki umożliwia producentom OEM zarządzanie żądaniami ostrości przechwytywanymi przez usługę audio w samochodzie. Daje to producentom OEM większą elastyczność w zakresie zarządzania ostrością zgodnie z wymaganiami określonymi w zasadach i przepisach. Dlatego interakcja z fokusem dźwięku może się różnić w zależności od producenta i regionu. Podstawowa zasada dotycząca skupienia dźwięku nadal obowiązuje: aplikacje powinny nadal prosić o skupienie, aby lepiej zarządzać dźwiękiem i zwiększać wygodę użytkowników. Ogólnie rzecz biorąc, w przypadku żądań aplikacji dotyczących uzyskania fokusu audio nadal obowiązują pewne reguły:

  • Aplikacje powinny mieć możliwość uzyskania fokusu audio tymczasowo lub na stałe, jeśli nie ma żadnego aktywnego fokusu audio o wysokim priorytecie (w tym połączenia telefonicznego, alertu alarmowego lub powiadomienia dotyczącego bezpieczeństwa).

  • Gdy aktywny jest priorytet dotyczący multimediów:

    • Aplikacje, które proszą o skupienie na używaniu połączeń, powinny mieć możliwość odbierania połączeń jednocześnie lub wyłącznie.

    • Aplikacje, które proszą o zaznaczenie nawigacji, powinny mieć możliwość otrzymywania zaznaczenia nawigacji jednocześnie lub wyłącznie.

    • Aplikacje, które proszą o skupienie się na korzystaniu z asystenta, powinny mieć możliwość otrzymania tego skupienia jednocześnie lub wyłącznie.

  • Gdy aplikacje z wysokim priorytetem odtwarzania dźwięku (w tym połączenia telefoniczne, alerty alarmowe i powiadomienia dotyczące bezpieczeństwa) są aktywne, każde przychodzące opóźnione żądanie odtwarzania dźwięku powinno zostać przyznane lub opóźnione w zależności od potrzeb.

Te sugestie nie są wyczerpujące, ale mogą pomóc aplikacjom, które proszą o skupienie, uzyskać je, jeśli nie ma aktywnych dźwięków o wysokim priorytecie. Nawet gdy aktywne są dźwięki o wysokim priorytecie, opóźnione żądania skupienia powinny być nadal uwzględniane i powinny mieć możliwość uzyskania skupienia, gdy dźwięk o wysokim priorytecie przestanie być odtwarzany.