Aktywność audio

Zanim aplikacja rozpocznie strumień logiczny, musi poprosić o aktywność audio, używając tych samych atrybutów audio, które są używane w przypadku strumienia logicznego. Aplikacja musi uwzględniać utratę aktywności, aby działać zgodnie z oczekiwaniami w przypadkach użycia w motoryzacji.

Wysyłanie prośby o aktywność jest zalecane, ale nie jest wymuszane przez system. Dlatego traktuj aktywność jako sposób na pośrednie kontrolowanie i unikanie konfliktów podczas odtwarzania, a nie jako podstawowy mechanizm sterowania dźwiękiem. Pojazd nie powinien polegać na systemie aktywności w zakresie działania podsystemu audio.

Interakcje dotyczące zaznaczania

Aby obsługiwać AAOS, prośby o aktywność audio są obsługiwane na podstawie predefiniowanych interakcji między CarAudioContext prośby a CarAudioContext bieżących posiadaczy aktywności. Istnieją 3 rodzaje interakcji:

  • Wyłączna
  • Odrzuć
  • Równoczesna

Interakcja wyłączna

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

W przypadku interakcji wyłącznych tylko 1 aplikacja może mieć aktywność w danym momencie. Dlatego przychodząca prośba o aktywność otrzymuje aktywność, a dotychczasowy posiadacz aktywności ją traci. Ponieważ obie aplikacje odtwarzają multimedia, tylko 1 z nich może mieć aktywność. W rezultacie prośba o aktywność nowo uruchomionej aplikacji jest zwracana z wartością AUDIOFOCUS_REQUEST_GRANTED, a bieżąca aplikacja do odtwarzania muzyki otrzymuje zdarzenie zmiany aktywności ze stanem utraty, który odpowiada typowi wysłanej prośby.

Interakcja „Odrzuć”

W przypadku interakcji „Odrzuć” przychodząca prośba jest zawsze odrzucana. Na przykład podczas próby odtworzenia muzyki w trakcie połączenia. W takim przypadku, jeśli aplikacja do wybierania numerów ma aktywność audio na potrzeby połączenia, a druga aplikacja prosi o aktywność w celu odtworzenia muzyki, aplikacja muzyczna otrzymuje w odpowiedzi na prośbę wartość AUDIOFOCUS_REQUEST_FAILED. Ponieważ prośba o aktywność została odrzucona, do bieżącego posiadacza aktywności nie jest wysyłana żadna utrata aktywności.

Interakcja równoczesna

Interakcje równoczesne są unikalne dla AAOS. Dzięki temu aplikacje, które proszą o aktywność audio w samochodzie, mogą mieć aktywność równocześnie z innymi aplikacjami. Aby doszło do interakcji równoczesnej, muszą być spełnione te warunki: Aplikacja:

Jeśli te kryteria są spełnione, prośba o aktywność zwraca wartość AUDIOFOCUS_REQUEST_GRANTED, a bieżący posiadacz aktywności nie zmienia aktywności. Jeśli jednak bieżący posiadacz aktywności chce otrzymywać zdarzenia wyciszenia lub wstrzymywać odtwarzanie, gdy dźwięk jest wyciszony, traci aktywność, tak jak w przypadku interakcji wyłącznej.

Obsługa równoczesnych strumieni

Interakcja równoczesna ma wiele zastosowań, ale 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ą odtwarzać dźwięk równocześnie, były kierowane do różnych urządzeń wyjściowych.

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ą miksowane w Androidzie, wzmocnienia pozostają niezmienione i są dostarczane jako część 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. Ewentualnie strumień nawigacji można przekierować do głośników po stronie kierowcy, a multimedia będą nadal odtwarzane w pozostałej części kabiny.

Dostępność działań

Ta tabela przedstawia dostępność działań zdefiniowaną przez CarAudioService. Każdy wiersz reprezentuje CarAudioContext bieżącego posiadacza aktywności, a każda kolumna – CarAudioContext przychodzącej prośby.

Na przykład, gdy aplikacja do multimediów ma aktywność, a aplikacja nawigacyjna prosi o aktywność, macierz wskazuje, że te 2 interakcje mogą odtwarzać dźwięk równocześnie, pod warunkiem że spełnione są inne kryteria interakcji równoczesnych.

Ze względu na interakcje równoczesne może być więcej niż 1 posiadacz aktywności. W takim przypadku przychodząca prośba o aktywność jest porównywana z każdym z bieżących posiadaczy aktywności, zanim zostanie określona interakcja, która ma zostać zastosowana. W takim przypadku wygrywa najbardziej konserwatywna interakcja. Najpierw „Odrzuć”, potem „Wyłączna”, a na końcu „Równoczesna”.

Macierz interakcji aktywności audio

Rysunek 1. Dostępność działań w przypadku aktywności audio.

W Androidzie 11 wprowadzono nowe ustawienie użytkownika, które umożliwia zmianę zachowania interakcji między nawigacją a rozmowami telefonicznymi. Gdy to ustawienie jest włączone, android.car.KEY_AUDIO_FOCUS_NAVIGATION_REJECTED_DURING_CALL zmienia interakcję między przychodzącymi NAVIGATION prośbami o aktywność a bieżącymi CALL posiadaczami aktywności z równoczesnej na odrzucanie. Jeśli użytkownik woli, aby instrukcje nawigacyjne nie przerywały połączenia, może włączyć to ustawienie. Jest ono zapisywane dla użytkownika i można je ustawić dynamicznie, aby kolejne prośby o aktywność uwzględniały nowe ustawienie.

Aktywność audio z opóźnieniem

W Androidzie 11 w AAOS dodano obsługę proszenia o aktywność audio z opóźnieniem. Umożliwia to opóźnienie nietrwałych próśb o aktywność, gdy ich interakcja z bieżącymi posiadaczami aktywności normalnie spowodowałaby ich odrzucenie. Gdy zmiana aktywności spowoduje, że opóźniona prośba będzie mogła uzyskać aktywność, prośba zostanie przyznana.

Reguły dotyczące opóźnionych próśb o aktywność audio

  • Tylko prośby nietrwałe. Opóźnioną prośbę można wysłać tylko w przypadku źródeł nietrwałych, aby uniknąć odtwarzania dźwięku trwałego długo po tym, jak przestanie być istotny.

  • W danym momencie można opóźnić tylko 1 prośbę. Jeśli podczas opóźnionej prośby zostanie wysłana prośba z opóźnieniem, pierwotna opóźniona prośba otrzyma zdarzenie zmiany AUDIOFOCUS_LOSS, a nowa prośba otrzyma synchroniczną odpowiedź AUDIOFOCUS_REQUEST_DELAYED.

  • Prośby z opóźnieniem muszą mieć OnAudioFocusChangeListener. Po opóźnieniu prośby detektor powiadamia osobę wysyłającą prośbę, gdy prośba zostanie ostatecznie przyznana (AUDIOFOCUS_GAIN) lub odrzucona (AUDIOFOCUS_LOSS).

Prośba o aktywność z opóźnieniem

Aby utworzyć prośbę, którą można opóźnić:

  1. Użyj 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 prośby 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 prośba jest opóźniona, detektor aktywności obsługuje zmiany aktywności:

    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 wyciszanie

Android 15 wprowadza w AAOS wymuszone przez system wyciszanie dźwięku. W Androidzie aktywność audio nie jest wymuszana przez system. Dlatego, chociaż zachęcamy deweloperów aplikacji do przestrzegania wytycznych dotyczących aktywności audio, jeśli aplikacja nadal odtwarza dźwięk głośno nawet po utracie aktywności audio, system nie może temu zapobiec.

W środowiskach motoryzacyjnych o krytycznym znaczeniu dla bezpieczeństwa przestrzeganie aktywności audio jest niezbędne do zminimalizowania rozpraszania uwagi kierowcy. Dzięki tej funkcji platforma audio automatycznie wycisza aplikacje, które tracą aktywność audio, co zapewnia bardziej kontrolowane i przewidywalne wrażenia dźwiękowe.

To ulepszenie pomaga zapewnić, że aplikacje będą przestrzegać decyzji o utracie aktywności audio zgodnie z definicją w macierzy interakcji, co zapobiega konfliktom odtwarzania dźwięku.

Projekt na wysokim poziomie

Na ilustracji poniżej przedstawiono projekt na wysokim poziomie i obsługę funkcji utraty aktywności w samochodach:

Projekt wysokiego poziomu funkcji zanikania wymuszonego przez system

Rysunek 2. Projekt na wysokim poziomie funkcji wymuszonego przez system wyciszania.

  • Wyciszanie docelowe: wymuszanie wyciszania przez system w Androidzie 15 jest przeznaczone specjalnie do sytuacji, w których aplikacja traci aktywność audio, ale nadal odtwarza dźwięk.
  • Mechanizm wyciszania: gdy aplikacja traci aktywność audio na rzecz nowej aplikacji wysyłającej prośbę:
    • Platforma audio automatycznie wycisza dźwięk aplikacji, która traci aktywność.
    • Po wyciszeniu strumień audio jest wyciszany przez system.
    • Aplikacja otrzymuje powiadomienie o utracie aktywności audio.
    • Aplikacje, które nie działają prawidłowo, są wyciszane do czasu odzyskania aktywności audio.
    • Domyślna logika polega na wyciszaniu aplikacji, które są wyciszane po 2 sekundach. Producenci OEM mogą jednak skonfigurować dowolną wartość limitu czasu.
    • Platforma audio używa konfiguracji OEM zarówno do wyciszania, jak i wyciszania.

  • Plik konfiguracji OEM: Android 15 zawiera nowy plik konfiguracji car_audio_fade_configuration.xml:

    • Ten plik umożliwia producentom OEM określenie kryteriów, kiedy wymuszanie aktywności audio przez system jest stosowane do aplikacji, która traci aktywność.
    • Platforma audio wymusza wyciszanie i wyciszanie tylko wtedy, gdy aplikacja, która traci aktywność, pasuje do reguł zdefiniowanych przez producenta OEM w tym pliku XML.
    • Dzięki temu producenci OEM mogą dostosowywać działanie funkcji na podstawie cech aplikacji lub typów użycia dźwięku.

  • Sterowanie funkcją za pomocą RRO: wprowadzono nową flagę funkcji 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ć wymuszoną przez system utratę aktywności audio, producenci OEM muszą ustawić tę flagę na true.
    • Chociaż platforma audio w samochodzie oczekuje prawidłowych definicji konfiguracji wyciszania, gdy flaga jest włączona, brak takich definicji nie powoduje automatycznie błędu krytycznego.
    • Wszystkie aplikacje konfiguracji wyciszania muszą mieć pasujące definicje wyciszania. Wywołanie konfiguracji wyciszania (według nazwy) w ramach konfiguracji audio w samochodzie bez podania prawidłowej definicji jest błędem krytycznym.
    • Gdy flaga jest wyłączona, wszystkie definicje konfiguracji wyciszania i wszelkie odwołania do konfiguracji są ignorowane.

Konfiguracja menedżera wyciszania

Platforma audio w Androidzie 15 wprowadza ujednoliconą konfigurację FadeManagerConfiguration, która zapewnia producentom OEM szczegółową kontrolę nad zachowaniem wyciszania dźwięku. Ta platforma jest przedstawiona na rysunku 3:

Konfiguracja menedżera zanikania

Rysunek 3. Konfiguracja menedżera wyciszania.

Ta konfiguracja obejmuje:

  • Właściwości przejścia z efektem zanikania: Ustawienia zarówno zanikania, jak i pojawiania się.
    • Można je zdefiniować za pomocą określonych zastosowań lub atrybutów audio.
    • Umożliwia ustawienia niestandardowego czasu trwania.
    • Te ustawienia służą do tworzenia VolumeShaper.Configuration.
  • Zasady wyciszania: reguły określające, kiedy następuje wyciszanie.
    • Globalny przełącznik umożliwiający włączanie i wyłączanie wyciszania.
    • Konfigurowalna lista zastosowań audio, które można wyciszyć (kwalifikujące się do wyciszenia po utracie aktywności).
    • Listy wykluczeń (nie można wyciszyć) uniemożliwiają wyciszanie krytycznych lub wyznaczonych źródeł dźwięku. Listy te mogą być oparte na:
      • Rodzaje treści
      • Atrybuty audio
      • Identyfikatory UID aplikacji (można je ustawić tylko w czasie działania)

Konfiguracje OEM

W tej sekcji omówimy dostępne dostosowania OEM.

Plik XML konfiguracji wyciszania audio w samochodzie

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

  • Ten plik XML umożliwia zdefiniowanie wielu różnych konfiguracji wyciszania, z których każda wymaga unikalnej nazwy do odwoływania się w pliku car_audio_configuration.xml.
  • Te konfiguracje można elastycznie stosować w różnych strefach audio i konfiguracjach stref.
  • Każda konfiguracja wyciszania akceptuje tylko wartości czasu trwania w milisekundach, które system wykorzystuje do wewnętrznego generowania odpowiedniej VolumeShaper.Configuration.

Praktyczne wskazówki dotyczące implementacji znajdziesz w przykładowych konfiguracjach udostępnionych na potrzeby emulatora w lokalizacji device/generic/car/emulator/audio/car_audio_fade_configuration.xml.

Plik XML konfiguracji audio 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 elastyczną konfigurację wyciszania. Każda definicja:

  • Musi zawierać 1 domyślną konfigurację fadeConfig oznaczoną jako isDefault = true.
  • Może zawierać kilka definicji fadeConfig. Te konfiguracje tymczasowe są stosowane tylko podczas interakcji związanych z utratą aktywności audio i tylko wtedy, gdy aplikacja uzyskująca aktywność audio spełnia kryteria zdefiniowane w konfiguracji tymczasowej.

Praktyczne wskazówki dotyczące implementacji znajdziesz w przykładowych konfiguracjach udostępnionych na potrzeby emulatora w lokalizacji device/generic/car/emulator/audio/car_audio_configuration.xml.

Rozszerzenie usługi aktywności audio w samochodzie OEM

Producenci OEM, którzy implementują niestandardową usługę aktywności audio w samochodzie, mogą konfigurować ustawienia wyciszania dźwięku, uwzględniając je w OemCarAudioFocusResult. Można to zrobić za pomocą metody konstruktora setAudioAttributesToCarAudioFadeConfigurationMap():

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

Producenci OEM mogą używać wstępnie skonfigurowanych ustawień wyciszania w czasie uruchamiania lub dynamicznie stosować konfiguracje za pomocą niestandardowej usługi aktywności audio, co zapewnia elastyczną kontrolę.

Schemat sekwencji

Ten schemat sekwencji ilustruje zachowanie po przyznaniu aktywności audio aplikacji App2 i późniejszej utracie aktywności audio przez aplikację App1:

  • Gdy usługa audio w samochodzie wysyła utratę aktywności audio do aplikacji App1, odtwarzanie z odtwarzacza App1 jest wyciszane zgodnie z aktywnymi konfiguracjami FadeManagerConfiguration. Po zakończeniu wyciszania aplikacja App1 otrzymuje standardowe wywołanie zwrotne utraty aktywności audio.
  • Opcjonalnie dźwięk aplikacji App1 można wyciszyć po skonfigurowanym czasie trwania. Producenci OEM mogą ustawić ten czas trwania za pomocą Builder#setFadeInDurationForUsage(int, long) zgodnie z wymaganiami dotyczącymi konkretnego produktu.

Schemat sekwencji funkcji wyciszania dźwięku w samochodzie

Rysunek 4. Schemat sekwencji funkcji wyciszania audio w samochodzie.

Zarządzanie aktywnością w wielu strefach

W przypadku pojazdów z wieloma strefami audio aktywność audio jest zarządzana niezależnie w każdej strefie. W związku z tym prośba do jednej strefy nie uwzględnia tego, co ma aktywność w innych strefach, ani nie powoduje utraty aktywności przez posiadaczy aktywności w innych strefach. Dzięki temu aktywność w głównej kabinie można zarządzać oddzielnie od systemu rozrywki na tylnych siedzeniach, co pozwala uniknąć przerywania odtwarzania dźwięku w jednej strefie przez zmiany aktywności w innej.

W przypadku wszystkich aplikacji usługa CarAudioService automatycznie zarządza aktywnością. Strefa audio prośby o aktywność jest określana przez powiązany z nią UserId lub UID (szczegółowe informacje znajdziesz w artykule Kierowanie dźwięku do wielu stref).

Równoczesne proszenie o dźwięk z wielu stref

Jeśli aplikacja chce odtwarzać dźwięk w wielu strefach równocześnie, musi poprosić o aktywność w każdej strefie, dodając do pakietu 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 prośbę zastąpienie automatycznych mapowań stref audio i użycie określonego identyfikatora strefy. Dlatego aplikacja może wysyłać osobne prośby do różnych stref audio.

Aktywność audio HAL

Od Androida 11 HAL może prosić o aktywność w imieniu strumieni zewnętrznych. Chociaż korzystanie z tych interfejsów API jest opcjonalne, zdecydowanie zachęcamy do ich używania, aby umożliwić optymalne uczestnictwo 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. W tym celu dźwięki alarmowe i krytyczne dla bezpieczeństwa powinny być odtwarzane niezależnie od tego, czy HAL ma aktywność audio, i powinny być odtwarzane w odpowiedni sposób nawet wtedy, gdy HAL utraci aktywność audio. To samo dotyczy dźwięków wymaganych przez przepisy rządowe.

HAL powinien proaktywnie 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 AudioControl HAL wprowadza te nowe interfejsy API:

Interfejs API Cel
IAudioControl#registerFocusListener Rejestruje instancję IFocusListener w interfejsie AudioControl HAL. Ten detektor umożliwia HAL proszenie o aktywność audio i jej porzucanie aktywności. HAL udostępnia instancję ICloseHandle, która jest używana przez Androida do wyrejestrowania detektora.
IAudioControl#onAudioFocusChange Powiadamia HAL o zmianach stanu próśb o aktywność wysyłanych przez HAL za pomocą IFocusListener, w tym o odpowiedziach na początkowe prośby o aktywność.
IFocusListener#requestAudioFocus Prosi o aktywność w imieniu HAL dla określonego zastosowania, identyfikatora strefy, i typu uzyskania aktywności.
IFocusListener#abandonAudioFocus Porzuca istniejące prośby o aktywność HAL dla określonego zastosowania i identyfikatora strefy.

HAL może mieć jednocześnie wiele próśb o aktywność, ale jest ograniczony do 1 prośby na parę zastosowania i identyfikatora strefy. Android zakłada, że HAL natychmiast rozpoczyna odtwarzanie dźwięków dla danego zastosowania po wysłaniu prośby i kontynuuje to do momentu porzucenia aktywności.

Oprócz registerFocusListener te prośby są oneway, aby zapewnić, że Android nie opóźnia HAL podczas przetwarzania prośby o aktywność. HAL nie powinien czekać na uzyskanie aktywności przed odtworzeniem dźwięków krytycznych dla bezpieczeństwa. HAL może opcjonalnie nasłuchiwać zmian aktywności audio i odpowiadać na nie za pomocą IAudioControl#onAudioFocusChange.

Usługa aktywności audio w samochodzie OEM

W Androidzie 14 w AAOS wprowadzono usługi wtyczek OEM w samochodzie, które umożliwiają konfigurowanie niektórych komponentów samochodu. W przypadku usługi wtyczek audio w samochodzieusługa wtyczek umożliwia producentom OEM zarządzanie prośbami o aktywność przechwytywanymi przez usługę audio w samochodzie. Dzięki temu producenci OEM mają większą elastyczność w zarządzaniu aktywnością zgodnie z regułami i przepisami. W związku z tym interakcja aktywności audio może się różnić w zależności od producenta i regionu. Podstawowa zasada aktywności audio nadal obowiązuje – aplikacje powinny prosić o aktywność, aby lepiej zarządzać dźwiękiem i poprawiać komfort użytkowników. Ogólnie rzecz biorąc, w przypadku próśb o aktywność audio wysyłanych przez aplikacje nadal obowiązują pewne reguły:

  • Aplikacje bez aktywności audio o wysokim priorytecie (w tym połączenia telefoniczne, alerty o zagrożeniu lub powiadomienia o bezpieczeństwie) powinny mieć możliwość uzyskania aktywności audio tymczasowo lub na stałe.

  • Gdy aktywna jest aktywność multimedialna:

    • Aplikacje proszące o aktywność w zakresie połączeń powinny mieć możliwość odbierania połączeń równocześnie lub wyłącznie.

    • Aplikacje proszące o aktywność w zakresie nawigacji powinny mieć możliwość uzyskania aktywności w zakresie nawigacji równocześnie lub wyłącznie.

    • Aplikacje proszące o aktywność w zakresie asystenta powinny mieć możliwość uzyskania aktywności w zakresie asystenta równocześnie lub wyłącznie.

  • Gdy aktywne są aplikacje z aktywnością audio o wysokim priorytecie (w tym połączenia telefoniczne, alerty o zagrożeniu lub powiadomienia o bezpieczeństwie), każda przychodząca opóźniona prośba o aktywność audio powinna zostać przyznana lub opóźniona w razie potrzeby.

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