Nowe usługi wtyczek OEM w Androidzie 14 umożliwiają konfigurowanie niektórych komponentów samochodu. W przypadku dźwięku wprowadzamy 3 nowe usługi wtyczek, które umożliwiają producentom OEM elastyczne konfigurowanie zarządzania dźwiękiem na urządzeniach z AAOS:
- Sterowanie aktywnością audio
- Sterowanie głośnością i wyciszaniem dźwięku
- Wyciszanie tła
Architektura usługi wtyczki Car
Rysunek poniżej przedstawia przegląd usług samochodowych i ich relacji z usługą samochodową OEM. Podobnie jak w przypadku procesów związanych z aplikacjami i serwisowaniem samochodów, proces serwisowania samochodów OEM zajmuje własny obszar procesu.
Usługa samochodowa uruchamia usługę samochodową OEM, znajdując komponent zdefiniowany w pliku config_oemCarService. Jeśli konfiguracja jest pusta, usługa OEM nie istnieje i żadna usługa nie jest uruchamiana. Komponent musi być rozszerzeniem interfejsu OemCarService.
Usługa audio w samochodzie musi zastąpić interfejsy API służące do uzyskiwania danych z usługi OEM audio w samochodzie:
public final class OemCarServiceImp extends OemCarService {
@Override
public OemCarAudioFocusService getOemAudioFocusService();
@Override
public OemCarAudioDuckingService getOemAudioDuckingService();
@Override
public OemCarAudioVolumeService getOemAudioVolumeService();
}
Na przykład możesz skorzystać z testowej aplikacji referencyjnej zdefiniowanej w pliku packages/services/Car/tests/OemCarServiceTestApp.
Mimo że usługa jest uruchamiana przez usługę samochodową, nie dziedziczy automatycznie uprawnień dostępnych dla usługi audio samochodowej. W związku z tym wszelkie uprawnienia wymagane przez usługi OEM powinny być uzyskiwane za pomocą odpowiedniego mechanizmu. Przykład: packages/services/Car/data/etc/com.android.car.oemcarservice.testapp.xml.
Usługa audio w samochodzie z architekturą OEM
W AAOS usługa audio w samochodzie zarządza tymi działaniami:
- Kierowanie dźwięku
- Aktywność audio
- Wyciszanie tła
- Głośność i wyciszanie
Przed Androidem 14 to zachowanie było w dużej mierze statyczne i można je było zmienić tylko w ustawieniach, ale w bardzo ograniczonym zakresie. Android 14 wprowadził mechanizm umożliwiający komunikacji usługi audio w samochodzie z określonym przez producenta komponentem, który zarządza:
- Aktywność audio
- Wyciszanie tła
- Głośność i wyciszanie
Rysunek poniżej przedstawia uproszczoną architekturę usługi audio w samochodzie i usługi OEM samochodu. Usługa audio samochodowa definiuje różne elementy, które mogą wywoływać usługę audio OEM samochodu w celu zarządzania zachowaniem dźwięku. Ta ostatnia sytuacja występuje tylko wtedy, gdy zdefiniowano odpowiedni komponent usługi audio samochodu OEM. W przeciwnym razie usługa audio w samochodzie będzie działać zgodnie z domyślnymi ustawieniami.
Aby zapewnić, że usługa audio w samochodzie i usługa audio OEM są zawsze zsynchronizowane, usługa audio w samochodzie przekazuje w przypadku każdego wywołania wymagane części bieżącego stanu pakietu audio do usługi audio OEM. Na przykład gdy usługa audio samochodowa przechwyci prośbę o ocena skupienia na dźwięku, przekazuje bieżący stan stosu do usługi audio OEM samochodu. Bieżący stan obejmuje bieżącego posiadacza fokusa i obecnych przegranych. Zmiana priorytetu to prośba o uwzględnienie, która nadal znajduje się w stogu, ale tymczasowo straciła priorytet.
Usługa audio w samochodzie musi zarządzać całą aktywnością związaną z dźwiękiem w samochodzie. Jeśli usługa audio samochodu nie zarządza niektórymi aspektami zachowania dźwięku, informacje udostępniane usłudze audio OEM samochodu są niekompletne. Jeśli na przykład producent OEM zastąpi obsługę ustawień dźwięku w usłudze samochodowej, rejestrując własne ustawienia dźwięku, usługa dźwiękowa samochodu nie będzie mogła przekazać pełnych informacji do usługi dźwiękowej producenta OEM. Może to wpływać na zdolność do podejmowania decyzji przez usługę audio OEM-a, ponieważ może ona nie mieć informacji, które nie są widoczne dla tej usługi.
Aby podjąć działania, usługa audio w samochodzie wywołuje usługi OEM. Te wywołania są wykonywane w ramach procesów, co wymaga komunikacji między procesami (IPC). IPC dodaje opóźnienie do każdego wywołania. Ważne jest, aby zminimalizować opóźnienia w usłudze OEM.
Ponieważ wywołania usługi audio samochodu do usługi OEM są blokujące, usługa OEM nie powinna wywoływać usługi audio samochodu w przypadku bezpośrednich ocen interfejsu API. Zamiast tego usługa audio w samochodzie udostępnia niezbędne informacje, aby wywołania między tymi dwoma procesami mogły odbywać się tylko w jednym kierunku.
Definicje usług OEM dotyczących dźwięku w samochodzie
Usługa OEM dotycząca audio w samochodzie
Usługa dźwiękowa w samochodzie zarządza żądaniami dotyczącymi trybu dźwiękowego w aplikacji przez rejestrowanie słuchacza zasad dotyczących trybu dźwiękowego. Usługa audio w samochodzie ma mechanizm do zarządzania zachowaniem fokusa na podstawie statycznej matrycy interakcji. Matryca definiuje 3 rodzaje interakcji:
Równoległa interakcja. Użytkownicy mogą jednocześnie zachować fokus.
Interakcje z wyłączniej Google. Otrzymana prośba o przejęcie fokusa powoduje przejęcie fokusa od obecnego właściciela.
Odrzuć interakcję. Odrzucono żądanie dotyczące skoncentrowania się na treści na podstawie obecnego właściciela treści.
Chociaż jest to wystarczające w przypadku niektórych zastosowań motoryzacyjnych, nie spełnia wszystkich potrzeb interakcji, które mogą się różnić ze względu na wymagania OEM. W tym celu wprowadzamy OemCarAudioFocusService:
public interface OEmCarAudioFocusService {
OemCarAuddioFocusResults evaluateAudioFocusRequest(
OemCarAudioFocusEvaluationRequest request);
void notifyAudioFocusChange(
List<AudioFocusEntry> holder,
List<AudioFocusEntry> losers, int zoneId);
}
Interfejs API evaluateAudioFocusRequest jest wywoływany z usługi audio samochodu, gdy tylko pojawi się prośba o skupienie się na dźwięku, która wymaga oceny. Jest to dwukierunkowy interfejs API, który blokuje wyniki. Żądanie zawiera informacje o bieżącym stanie stosu audio:
Na podstawie tych informacji możesz porównać newFocusRequest z obecnymi posiadaczami focusHolders i obecnymi przegranymi focusLosers. Interfejs API powinien zwrócić te wyniki:
class OemCarAudioFocusResult {
int audioZoneId;
int audioFocusEvaluationResults;
AudioFocusEntry focusResult;
List<AudioFocusEntry> newLosers;
List<AudioFocusEntry> newlyBlocked;
}
Zawiera informacje o rzeczywistych wynikach oceny w audioFocusEvaluationResults, które wskazują, czy bieżące żądanie zostało spełnione, opóźnione czy też nie udało się. Wszelkie zmiany bieżącego zbioru fokusów należy wprowadzać w rekordach newLosers i newlyBlocked w zależności od charakteru zmiany.
Gdzie newLosers zawiera wpisy, które były wcześniej w centrum uwagi, ale powinny teraz stracić na znaczeniu (na stałe lub tymczasowo). Elementy, które nie są już w fokusie, zostaną usunięte z grupy elementów w fokusie, a elementy, które nie są w fokusie tymczasowo, zostaną przeniesione do grupy elementów, które nie są w fokusie tymczasowo, do czasu, gdy ponownie zostaną one włączone do grupy elementów w fokusie lub zostaną usunięte z grupy elementów w fokusie przez pierwotnego żądającego. W każdym przypadku komponent obsługujący focus dla tych żądań otrzyma odpowiednią wiadomość o utracie focusa.
Lista newlyBlocked zawiera wpisy, które wcześniej znajdowały się na liście przegranych, ale teraz są blokowane przez nowy wpis. Blokada może być trwała lub tymczasowa. W przypadku trwałego zablokowania ostrości element zostanie usunięty ze stosu, a słuchacze zostaną poinformowani o utracie ostrości. W przypadku przejściowego utraty skupienia wpis pozostanie w stosie utraty skupienia, ale do listy blokujących zostanie dodany nowy blokujący element. Nie zostanie wysłane żadne powiadomienie o utracie skupienia, ponieważ zostało ono wysłane wcześniej, gdy nastąpiło pierwsze zablokowanie. Prośba zostanie odblokowana, gdy usunięto wszystkie blokujące ją elementy lub zostanie usunięta ze stosu, jeśli praca nad nią została przerwana.
Drugi interfejs API, notifyAudioFocusChange, jest wywoływany w jednym kierunku w przypadku każdego żądania dotyczącego skupienia na audio lub rezygnacji z niego. Interfejs API jest używany głównie do informowania usługi OEM o zmianach w obszarze fokusowania, które mogą wpływać na działanie usługi OEM dotyczącej systemu audio w samochodzie.
Wskazówki dotyczące oceny ostrości
W AAOS fokus dźwięku służy do zarządzania odtwarzaniem dźwięku i określania, która aplikacja powinna zapewnić użytkownikowi optymalne wrażenia. Dlatego usługa wtyczki OEM podczas zarządzania prośbą o skupienie się na dźwięku powinna wziąć pod uwagę te kwestie:
W przypadku braku priorytetowego dźwięku o wysokiej priorytecie (takiego jak połączenie telefoniczne, alarm lub dźwięk bezpieczeństwa) aplikacje powinny mieć możliwość tymczasowego lub stałego przejęcia dźwięku.
Gdy aktywny jest tryb skupienia na mediach, aplikacje proszące o dostęp:
Użytkownik powinien mieć możliwość skupienia się na jednym lub kilku połączeniach.
Elementy nawigacji powinny być możliwe do zaznaczenia jednocześnie lub wyłącznie.
Asystent powinien mieć możliwość skupienia się na jednej rzeczy (jednocześnie lub wyłącznie).
Gdy aktywne są aplikacje o wysokim priorytecie (takie jak aplikacja do obsługi połączeń telefonicznych, alarmów alarmów czy alertów bezpieczeństwa), każda przychodząca prośba o opóźnienie dźwięku powinna zostać odpowiednio zaakceptowana lub odrzucona.
Powyższe sugestie nie są wyczerpujące, ale mogą pomóc zapewnić, że aplikacje proszące o skupienie uwagi będą mogły je uzyskać, gdy nie ma aktywnych dźwięków o wysokim priorytecie. Nawet gdy dźwięki o wysokim priorytecie są aktywne, opóźnione prośby o skupienie powinny być nadal respektowane i powinny mieć możliwość uzyskania skupienia, gdy dźwięk o wysokim priorytecie ucichnie.
Usługa dotycząca objętości OEM
Usługa audio samochodowa zarządza zdarzeniami klawisza głośności, nasłuchując zmian głośności z systemu audio lub nasłuchując zdarzenia klawisza głośności bezpośrednio z usługi wejścia samochodowego. W każdym przypadku domyślne działanie usługi audio w samochodzie polega na określeniu, którą grupę głośności należy zmienić na podstawie aktywnych odtwarzaczy audio i listy priorytetów kontekstu audio.
Udostępniamy 2 listy priorytetów objętości. Pierwsza lista uwzględnia wszystkie konteksty audio w takiej kolejności: Lista jest wyświetlana w kolejności malejącej – na górze znajdują się reguły o najwyższym priorytecie, a na dole – o najniższym. Jeśli na przykład dźwięk nawigacji i dźwięk muzyki są aktywne w tym samym czasie, głośność nawigacji zmienia się podczas zdarzenia związanego z klawiszami głośności.
- Nawigacja
- Zadzwoń
- Muzyka
- Ogłoszenie
- Polecenie głosowe
- Dzwonek połączenia
- Dźwięki systemowe
- Bezpieczeństwo
- Alarm
- Powiadomienie
- Stan pojazdu
- Alarmowe
Aby zarządzanie zdarzeniami związanymi z kluczem głośności było mniej skomplikowane, usługa audio w samochodzie ma drugą listę priorytetów kontekstu audio:
- Zadzwoń
- Multimedia
- Ogłoszenie
- Polecenie głosowe
Ta lista jest też wyświetlana w kolejności malejącej. Druga lista ma na celu umożliwienie zmiany częstszych dźwięków za pomocą kluczowych zdarzeń. Nietypowe dźwięki, na przykład krótsze, można zarządzać tylko w interfejsie ustawień dźwięku.
Rzeczywistą wersję woluminu można ustawić za pomocą konfiguracji audioVolumeAdjustmentContextsVersion. Konfigurację można ustawić jako 1 lub 2 (domyślnie jest to 2).
Aby zapewnić większą elastyczność zarządzania głośnością, w Androidzie 14 wprowadzono funkcję OemCarAudioVolumeService:
public interface OemCarAudioVolumeService {
OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}
Usługa OEM dotycząca głośności dźwięku w samochodzie ma jedną metodę, która przyjmuje volumeAdjustment i OemCarAudioVolumeRequest:
class OemCarAudioVolumeRequest {
int audioZoneId;
int callState;
List<AudioAttributes> activePlaybackAttributes;
List<AudioAttributes> duckedAttributes;
List<CarVolumeGroupInfo> volumeGroupState;
}
W activePlaybackAttributes żądania znajdują się aktywne atrybuty audio. duckedAttributes to wszystkie obecnie wyciszone atrybuty dźwięku.
volumeGroupState zawiera bieżący stan grupy woluminów. Żądanie to odzwierciedla bieżący stan stosu audio i może służyć do określenia, która grupa głośności powinna zostać zmieniona. Wyniki powinny być zwracane w formie:
OemCarVolumeChangeInfo:
class OemCarVolumeChangeInfo {
boolean change;
CarVolumeGroupInfo volumeGroupChanged;
}
Wartość logiczna change wskazuje, czy jakakolwiek głośność uległa zmianie, a wartość true wskazuje, że nastąpiła zmiana i grupa wolumenów powinna zostać zaktualizowana. volumeGroupChanged to rzeczywista grupa objętości, którą należy zmienić. Ta grupa powinna zostać zmieniona zgodnie z pierwotnym parametrem volumeAdjustment przekazanym do interfejsu API. Jeśli na przykład wyniki wskazują, że grupa głośności nawigacji powinna być wyciszona, wartość logiczna będzie true, a zwrócona grupa głośności powinna być taka jak dla nawigacji.
Usługa wyciszania OEM
Usługa dźwięku w samochodzie zarządza wyciszaniem dźwięku, monitorując zmiany w fokusie dźwięku i wysyłając sygnał do AudioControl HAL o tym, które urządzenia dźwiękowe mają zostać wyciszone.
Gdy zmienia się punkt skupienia, wszystkie aktywne elementy punkty skupienia są oceniane pod kątem tego, które z nich powinny zostać usunięte na podstawie tego zestawu statycznych reguł:
- Dźwięki alarmowe wyciszają wszystko oprócz dźwięków połączeń.
- Bezpieczne wyłączenie wszystkie oprócz dźwięków alarmowych
- Nawigacja wycisza wszystkie dźwięki oprócz dźwięków bezpieczeństwa i dźwięków alarmowych.
- Wyłącz wszystkie dźwięki oprócz dźwięków bezpieczeństwa, alarmowych i nawigacyjnych.
- Dźwięki dzwonienia w Voice Ducks
- Muzyka i ogłoszenia powinny być wyciszone przez wszystko
Te reguły nie są wyczerpujące, a producenci OEM nadal ponoszą odpowiedzialność za określanie sposobu wyciszania dźwięków zgodnie z tymi wytycznymi. Producenci OEM mogą bardziej aktywnie kontrolować te rekomendacje na podstawie dostępnych wymagań. OemCarDuckingService została wprowadzona w Androidzie 14:
class OemCarAudioDuckingService {
List<AudioAttributes> evaluateAttributesToDuck(
OemCarAudioVolumeRequest request);
}
Ten interfejs API jest wywoływany z usługi audio w samochodzie po zmianie skupienia dźwięku. Używa ona ponownie OemCarAudioVolumeRequest wprowadzonego w usłudze OEM dotyczącej liczby samochodów i zawiera odpowiednie informacje, które pomogą Ci podjąć decyzję, które atrybuty chcesz ukryć. Lista atrybutów audio do wyciszenia z interfejsu API jest porównywana z bieżącym stanem dźwięku:
Atrybut dźwięku obecnie wyciszony:
- Na liście, nadal jest zablokowany
- Nie ma na liście, tłumienie wyłączone
Atrybut audio nie jest obecnie stłumiony:
- Na liście, ścięte
- Nie ma na liście, tłumienie wyłączone
Usługa dźwięku w samochodzie określa, do których urządzeń wyjściowych dźwięku należą te atrybuty, i dodaje je odpowiednio do listy wyciszonych urządzeń wyjściowych lub listy urządzeń z niewyciszonym dźwiękiem. W efekcie jest ono wysyłane do interfejsu AudioControl HAL, aby wykonać wymagane wyciszenie na poziomie sprzętu.
Rysunek poniżej przedstawia uproszczony diagram sekwencji kontroli wyciszania dźwięku w przypadku żądania fokusa, gdy używana jest usługa wyciszania OEM:
Sekwencja rozpoczyna się, gdy aplikacja poprosi o zarządzanie natężeniem dźwięku za pomocą publicznych interfejsów API menedżera dźwięku. Prośba jest przekierowywana do usługi audio w samochodzie, aby uzyskać wyniki. Gdy zostanie wybrany dźwięk, który ma być wyciszony, usługa audio samochodu wywołuje funkcję OemCarAudioDuckingService, aby określić, które atrybuty dźwięku powinny zostać wyciszone. Po otrzymaniu wyników z interfejsu API evaluateAttributesToDuck obliczane są urządzenia audio, które mają być wyciszone, a następnie informacje są wysyłane do AudioControl, aby zastosować wyciszenie na sprzęcie audio.
Implementacja usługi OEM dotyczącej dźwięku w samochodzie
AAOS udostępnia referencyjną implementację usługi samochodu OEM w packages/services/Car/tests/OemCarServiceTestApp, która implementuje OemCarService, a także OemCarAudioFocusService, OemCarAudioDuckingService i OemCarAudioVolumeService. W przypadku tego drugiego każda usługa używa pliku XML do wczytania statycznych danych. Na przykład:
OemCarAudioFocusServiceImp wczytuje oem_focus_config.xml, który zawiera macierz interakcji. Matryca jest używana do oceny żądania fokusa, gdy wywoływana jest funkcja evaluateAudioFocusRequest.
Debugowanie aplikacji testowej referencyjnej
OEM-owa aplikacja testowa usługi samochodowej jest częścią kodu źródłowego AOSP. Producenci OEM mogą wprowadzać zmiany zgodnie ze swoimi potrzebami. Aby debugować, użyj konfiguracji config_oemCarService, aby włączyć aplikację testową.
<!-- This is the component name for the OEM customization service. OEM can choose to implement
this service to customize car service behavior for different policies. If OEMs choose to
implement it, they have to implement a service extending OemCarService exposed by car-lib,
and implement the required component services.
If the component name is invalid, CarService would not connect to any OEM service.
Component name can not be a third party package. It should be pre-installed -->
<string name="config_oemCarService" translatable="false">
com.android.car.oemcarservice.testapp/.OemCarServiceImpl
</string>
Aby sprawdzić, czy usługa samochodowa OEM używa polecenia usługi samochodowej dump dla usługi OEM:
adb shell dumpsys car_service --oem-service
Wyniki mogą być podobne do tych:
***CarOemProxyService dump***
mIsFeatureEnabled: true
mIsOemServiceBound: true
mIsOemServiceReady: true
mIsOemServiceConnected: true
mInitComplete: true
OEM_CAR_SERVICE_CONNECTED_TIMEOUT_MS: 5000
OEM_CAR_SERVICE_READY_TIMEOUT_MS: 5000
mComponentName: com.android.car.oemcarservice.testapp/.OemCarServiceImpl
Każda wartość logiczna w każdej partii informacji dump określa stan funkcji i usługi. Na przykład informacje o zrzucie mIsOemServiceReady wskazują, czy usługa jest gotowa do użycia. Wartość true oznacza, że tak jest, a wartość false – że nie.