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 trybu dźwiękowego są obsługiwane na podstawie zdefiniowanych wcześniej interakcji CarAudioContext
i obecnych posiadaczy trybu dźwiękowego. 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 dotychczasowy posiadacz fokusa traci go. Obie aplikacje odtwarzają multimedia, więc tylko jedna z nich może być aktywna. W efekcie żądanie dotyczące skupienia uwagi nowej aplikacji zwraca wartośćAUDIOFOCUS_REQUEST_GRANTED
, a aplikacja, która obecnie odtwarza muzykę, otrzymuje zdarzenie zmiany skupienia uwagi 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 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.
Obecny element trzymający fokus nie ma ustawionej funkcji setPauseWhenDucked(true)
Obecny właściciel uprawnień do 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 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ównoległa ma wiele zastosowań, należy zachować ostrożność podczas miksowania i wyciszania na poziomie sprzętu na urządzeniach wyjściowych. Zdecydowanie zalecamy, aby ścieżki CarAudioContext
, które mogą być odtwarzane jednocześnie, były kierowane na różne urządzenia wyjściowe.
Dzięki temu, że dane wyjściowe są przesyłane na osobne urządzenia, 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 nawigacji 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 głośnikach w całym wnętrzu pojazdu.
Interakcja
Tabela poniżej przedstawia macierz interakcji zdefiniowaną przez CarAudioService
.
Każdy wiersz reprezentuje CarAudioContext
bieżącego obiektu fokusa, a każda kolumna – 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ą być wykonywane 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 wreszcie równoczesne.
Rysunek 1. Interakcja z aktywną ścieżką dźwiękową.
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 sposób interakcji między przychodzącymi NAVIGATION
prośbami o skupienie a obecnymi CALL
posiadaczami uprawnień z 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, 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 zainteresowania, które nie są krótkotrwałe, mogą zostać opóźnione, gdy ich interakcja z obecnymi posiadaczami zainteresowania zazwyczaj kończyłaby się odrzuceniem. 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 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 asynchroniczną odpowiedź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 wysył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 zdarzenia 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 strefami fokusowania
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 jest w fokusie w innych strefach, ani nie powoduje utraty fokusu w innych strefach. 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 jednej strefie przez zmiany w fokusie w innej.
W przypadku wszystkich aplikacji funkcja 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 Przekazywanie 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ęku, i powinny być odtwarzane odpowiednio nawet wtedy, gdy HAL utraci skupienie dźwięku. To samo dotyczy dźwięków wymaganych przez przepisy państwowe.
HAL powinien aktywnie 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źne słyszenie.
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ń fokusu wysłanych przez HAL za pomocą IFocusListener , w tym o odpowiedziach na początkowe żądania fokusu. |
IFocusListener#requestAudioFocus
| Prośby o wyostrzanie w imieniu HAL dla określonego użycia, identyfikatora strefy i typu wzmocnienia ostrości. |
IFocusListener#abandonAudioFocus |
powoduje porzucenie istniejących próśb o skupienie 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 fokusu 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 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ę audio samochodową. Daje to producentom OEM większą elastyczność w zarządzaniu punktem ogniskowej 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. Nadal obowiązuje podstawowa zasada dotycząca skupienia na dźwięku: aplikacje powinny nadal prosić o skupienie się na dźwięku, aby lepiej zarządzać dźwiękiem i ulepszać 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 zabezpieczeniach) 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ść uzyskania 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 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.
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ć.