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 wymagane przez system. Dlatego traktuj fokus jako sposób pośredniego kontrolowania i unikania konfliktów podczas odtwarzania, a nie jako podstawowy mechanizm kontroli dźwięku. Samochód nie powinien polegać na systemie sterowania w celu działania podsystemu audio.
Interakcje z elementem
Aby obsługiwać AAOS, żądania dotyczące skupienia na dźwięku są przetwarzane na podstawie zdefiniowanych wcześniej interakcji CarAudioContext
żądania z interakcjami bieżących posiadaczy uprawnień do 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 fokusa powoduje, że obecny posiadacz fokusa traci go. Obie aplikacje odtwarzają multimedia, więc tylko jedna z nich może być aktywna. W rezultacie żądanie dotyczące fokusa nowo uruchomionej aplikacji jest zwracane z wartością AUDIOFOCUS_REQUEST_GRANTED
, a aplikacja, która obecnie odtwarza muzykę, otrzymuje zdarzenie zmiany fokusa ze stanem „loss” (utrata) odpowiadającym rodzajowi wysłanego żą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 podczas trwającej 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
W ramach AAOS dostępne 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.
Obecny element uchwytu nie ma ustawionej funkcji setPauseWhenDucked(true)
Obecny właściciel uprawnień do skupienia nie chce otrzymywać zdarzeń ściszania dźwięku
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 na 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 różnych urządzeniach wyjściowych. Zdecydowanie zalecamy, aby ścieżki CarAudioContext
, które mogą być odtwarzane jednocześnie, były kierowane do różnych urządzeń wyjściowych.
Dzięki temu, że urządzenia wyjściowe są oddzielne, HAL może wyciszyć jeden z kanałów 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łych częściach kabiny.
Interakcja
Tabela poniżej przedstawia macierz interakcji zdefiniowaną przez CarAudioService
.
Każdy wiersz reprezentuje CarAudioContext
bieżącego obiektu na pierwszym planie, a każda kolumna reprezentuje przychodzące żądanie.
Jeśli na przykład aplikacja muzyczna ma fokus, a aplikacja do nawigacji prosi o fokus, to według tej matrycy obie interakcje mogą działać jednocześnie, o ile tylko są spełnione inne kryteria interakcji równoczesnych.
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 wykluczanie i ostatecznie równoczesne.
Rysunek 1. Macierz interakcji z aktywną funkcją 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 to ustawienie jest włączone,
android.car.KEY_AUDIO_FOCUS_NAVIGATION_REJECTED_DURING_CALL
zmienia sposób interakcji przychodzących NAVIGATION
żądań o skupienie z obecnymi CALL
posiadaczami zasobów z równoległych na odrzucających. Jeśli użytkownik nie chce, aby wskazówki nawigacyjne przerywały połączenie, może włączyć to ustawienie. Jest ono przechowywane dla użytkownika i może być ustawiane dynamicznie, 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 zrealizowana.
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 po upływie długiego czasu od jego wystąpienia.
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 odpowiedź asynchronicznąAUDIOFOCUS_REQUEST_DELAYED
.Prośby o opóźnienie muszą zawierać parametr
OnAudioFocusChangeListener
. Gdy prośba zostanie opóźniona, listener służy do powiadamiania osoby przesyłającej prośbę, gdy prośba zostanie ostatecznie zaakceptowana (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 focus 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
Zarządzanie punktem skupienia w wielu strefach
W pojazdach z wieloma strefami dźwiękowymi można niezależnie zarządzać dźwiękiem w każdej strefie. 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 CarAudioService
automatycznie zarządza trybem skupienia. Strefa dźwiękowa żądania fokusowania jest określana przez powiązane z nim UserId
lub UID
(szczegółowe informacje 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żyć określonego identyfikatora strefy. Aplikacja może więc wysyłać oddzielne żądania dotyczące różnych stref dźwięku.
Aktywność audio HAL
Począwszy od Androida 11, 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 optymalne działanie w ekosystemie Androida i zapewnić użytkownikom płynne wrażenia.
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 aktywnie wyciszać strumienie Androida, gdy odtwarzane są dźwięki alarmowe lub dźwięki związane z bezpieczeństwem, aby zapewnić ich wyraźny dźwięk.
AudioControl@2.0
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 na potrzeby 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ń fokusu w tym samym czasie, 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 nasłuchiwać i reagować na zmiany w koncentracji dźwięku za pomocą interfejsu IAudioControl#onAudioFocusChange
.
Usługa OEM dotycząca audio w samochodzie
W Androidzie 14 system AAOS wprowadził usługi wtyczek OEM, aby umożliwić konfigurowanie niektórych komponentów samochodu. W przypadku usługi wtyczki audio samochodowej usługa wtyczki umożliwia OEM-om zarządzanie żądaniami fokusowania przechwyconymi przez usługę audio samochodową. Daje to producentom OEM większą elastyczność w zarządzaniu punktem ogniskowym 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 tryb fokusowania 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ść otrzymywania zaznaczenia równocześnie 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 wypadkach 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.
Powyższe sugestie nie wyczerpują listy, ale mogą pomóc aplikacjom proszącym o skupienie się, jeśli nie ma 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ć.