Nowe usługi wtyczek OEM samochodów w systemie Android 14 umożliwiają konfigurację niektórych podzespołów samochodu. W szczególności w przypadku dźwięku wprowadzono trzy nowe usługi wtyczek, które umożliwiają producentom OEM elastyczną konfigurację zarządzania dźwiękiem na urządzeniach AAOS:
- Sterowanie ostrością dźwięku
- Sterowanie głośnością i wyciszeniem
- Kontrola wyciszania dźwięku
Architektura usługi wtyczek samochodowych
Poniższy rysunek przedstawia przegląd usług samochodowych i ich związek z usługą samochodową OEM. Podobnie jak procesy aplikacji i proces serwisu samochodowego, proces serwisu samochodowego OEM zajmuje własną przestrzeń procesową.
Serwis samochodowy uruchamia usługę samochodową OEM poprzez znalezienie komponentu zdefiniowanego w config_oemCarService . Jeśli konfiguracja jest pusta, usługa OEM nie istnieje i żadna usługa nie zostanie uruchomiona. Komponent musi rozszerzać OemCarService . Usługa car audio musi zastąpić interfejsy API w celu nabycia usługi OEM car audio:
public final class OemCarServiceImp extends OemCarService {
@Override
public OemCarAudioFocusService getOemAudioFocusService();
@Override
public OemCarAudioDuckingService getOemAudioDuckingService();
@Override
public OemCarAudioVolumeService getOemAudioVolumeService();
}
Na przykład zobacz referencyjną aplikację testową zdefiniowaną w packages/services/Car/tests/OemCarServiceTestApp .
Mimo że usługa jest uruchamiana przez serwis samochodowy, nie dziedziczy ona automatycznie uprawnień dostępnych dla usługi car audio. W związku z tym wszelkie pozwolenia wymagane przez usługi OEM należy uzyskać przy użyciu odpowiedniego mechanizmu. Na przykład zobacz packages/services/Car/data/etc/com.android.car.oemcarservice.testapp.xml .
Usługa car audio z architekturą usług OEM
W AAOS usługa car audio zarządza następującymi działaniami:
- Kierowanie audio
- Fokus dźwięku
- Wyciszanie dźwięku
- Głośność i wyciszenie
Przed Androidem 14 to zachowanie było w dużej mierze statyczne i można je było modyfikować jedynie za pomocą ustawień, aczkolwiek w bardzo ograniczonych przypadkach. W Androidzie 14 wprowadzono mechanizm komunikacji usługi car audio z komponentem zdefiniowanym przez OEM, który zarządza:
- Fokus dźwięku
- Wyciszanie dźwięku
- Głośność i wyciszenie
Poniższy rysunek przedstawia uproszczoną architekturę usługi car audio i usługi OEM w samochodzie. Usługa car audio definiuje różne zaczepy, które mogą wywoływać usługę audio OEM samochodu w celu zarządzania zachowaniem dźwięku. To drugie występuje tylko wtedy, gdy zdefiniowano odpowiedni komponent usługi car audio OEM. W przeciwnym razie usługa car audio zastosuje zachowanie domyślne.
Aby mieć pewność, że usługa car audio i samochodowa usługa audio OEM są zawsze zsynchronizowane, przy każdym połączeniu usługa car audio przekazuje wymagane części bieżącego stanu stosu audio do samochodowej usługi audio OEM. Na przykład, gdy usługa audio w samochodzie przechwytuje żądanie oceny fokusu audio, przekazuje bieżący stan stosu do usługi audio OEM samochodu. Bieżący stan obejmuje bieżącego posiadacza fokusu i bieżących utraty fokusu. Przegrane skupienie to żądania skupienia, które nadal stanowią część stosu, ale chwilowo utraciły skupienie.
Usługa car audio musi zarządzać całą aktywnością audio w samochodzie. Jeśli usługa audio w samochodzie nie zarządza niektórymi elementami działania systemu audio, informacje udostępniane usłudze audio OEM samochodu są niekompletne. Na przykład, jeśli producent OEM nadpisze obsługę fokusu audio w usłudze samochodowej, rejestrując własne zasady fokusu audio, wówczas usługa car audio nie będzie w stanie zapewnić pełnych informacji samochodowej usłudze audio OEM. Może to mieć wpływ na zdolność samochodowego serwisu audio OEM do podejmowania decyzji, ponieważ może brakować w nim informacji niewidocznych dla samochodowego serwisu audio.
Aby podjąć działania, usługa car audio dzwoni do usług samochodowych OEM. Wywołania te są wykonywane między procesami, co wymaga komunikacji między procesami (IPC). IPC dodaje opóźnienie do każdego połączenia. Ważne jest, aby zminimalizować opóźnienia w usłudze OEM.
Ponieważ połączenia samochodowego sprzętu audio z usługą OEM są blokowane, usługa OEM nie powinna dzwonić do usługi car audio w ramach bezpośrednich ocen API. Zamiast tego usługa car audio dostarcza niezbędnych informacji, dzięki czemu połączenia między obydwoma procesami muszą odbywać się tylko w jednym kierunku.
Definicje usług car audio OEM
Usługa fokusowania car audio OEM
Usługa car audio zarządza żądaniami fokusu audio z aplikacji, rejestrując słuchacza fokusu zasad audio. Usługa car audio posiada mechanizm zarządzania zachowaniem fokusa w oparciu o statyczną matrycę interakcji . Macierz definiuje trzy różne rodzaje interakcji:
Równoczesna interakcja. Posiadacze ostrości mogą jednocześnie utrzymywać ostrość.
Ekskluzywne interakcje. Przychodzące żądanie fokusu przejmuje fokus od bieżącego posiadacza fokusu.
Odrzuć interakcję. Przychodzące żądanie fokusu zostało odrzucone ze względu na bieżącego posiadacza fokusu.
Chociaż jest to wystarczające w niektórych przypadkach zastosowań motoryzacyjnych, nie spełnia wszystkich potrzeb interakcji, które mogą się różnić ze względu na wymagania OEM. W tym celu przedstawiamy usługę OemCarAudioFocusService :
public interface OEmCarAudioFocusService {
OemCarAuddioFocusResults evaluateAudioFocusRequest(
OemCarAudioFocusEvaluationRequest request);
void notifyAudioFocusChange(
List<AudioFocusEntry> holder,
List<AudioFocusEntry> losers, int zoneId);
}
Funkcja API evaluateAudioFocusRequest jest wywoływana z usługi car audio za każdym razem, gdy pojawia się żądanie skupienia dźwięku, które wymaga oceny. Jest to dwukierunkowy interfejs API, który blokuje powrót wyników. Żądanie zawiera informację o aktualnym stanie stosu audio:
Informacje te można wykorzystać do oceny newFocusRequest w porównaniu z bieżącymi posiadaczami fokusu w focusHolders i obecnymi przegranymi fokusami w focusLosers . API powinno zwrócić 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 przyjęte, opóźnione czy też nie. Wszelkie zmiany w bieżącym stosie fokusów powinny być ustawione we wpisach newLosers i newlyBlocked , w zależności od charakteru zmiany stosu.
Gdzie newLosers zawiera wpisy, które wcześniej były aktywne, ale teraz powinny je stracić na stałe lub przejściowo. Trwałe utraty fokusu będą dalej usuwane ze stosu fokusu audio, a przejściowe utraty fokusu będą przenoszone do bieżącego stosu utraty fokusu, dopóki nie odzyskają fokusu lub nie zostaną opuszczone przez pierwotnego requestera fokusu. Niezależnie od tego, słuchacz fokusu żądań otrzyma odpowiednią utratę fokusu.
Lista newlyBlocked zawiera wpisy, które wcześniej znajdowały się na liście przegranych fokusu, ale teraz są blokowane przez nowy wpis. Blokada może być trwała lub przejściowa. W przypadku zablokowania stałego fokusu wpis zostanie usunięty ze stosu, a utrata fokusu zostanie wysłana do słuchaczy fokusu. W przypadku przejściowej utraty fokusu wpis pozostanie na stosie utraty fokusu, ale do listy blokerów zostanie dodany nowy bloker fokusu. Żadna utrata fokusu nie zostanie wysłana, tak jak poprzednio została wysłana, gdy została po raz pierwszy zablokowana. Żądanie zostanie ostatecznie odblokowane po usunięciu wszystkich bieżących blokad lub zostanie usunięte ze stosu, jeśli porzucono fokus.
Drugie API, notifyAudioFocusChange , jest jednym ze sposobów wywoływanych przy każdym żądaniu lub porzuceniu fokusu audio. Interfejs API jest najczęściej używany do informowania usługi OEM o zmianach fokusu, które mogą mieć wpływ na zachowanie usługi car audio OEM.
Wytyczne dotyczące oceny ostrości
W AAOS fokus audio służy do zarządzania odtwarzaniem dźwięku i określania, która aplikacja powinna być stosowana, aby zapewnić użytkownikowi optymalne wrażenia. W związku z tym usługa wtyczek OEM powinna uwzględniać następujące kwestie podczas zarządzania żądaniem fokusu audio:
Bez stałego fokusu audio o wysokim priorytecie (takiego jak połączenie telefoniczne, alarm lub bezpieczeństwo) aplikacje powinny być w stanie uzyskać fokus audio albo przejściowo lub na stałe.
Gdy fokus multimedialny jest aktywny, aplikacje żądające:
Skupienie na użyciu połączeń powinno być możliwe do uzyskania fokusu jednocześnie lub wyłącznie.
Skupienie na użyciu nawigacji powinno być możliwe do uzyskania fokusu jednocześnie lub wyłącznie.
Skupienie na użyciu Asystenta powinno być możliwe do uzyskania fokusu jednocześnie lub wyłącznie.
Gdy aktywne są aplikacje dźwiękowe o wysokim priorytecie (takie jak połączenie telefoniczne, alarm awaryjny lub alert bezpieczeństwa), wszelkie przychodzące opóźnione żądania fokusu dźwiękowego powinny zostać przyjęte lub opóźnione w razie potrzeby.
Chociaż powyższe sugestie nie są wyczerpujące, mogą pomóc zagwarantować, że aplikacje żądające fokusu będą w stanie uzyskać fokus, gdy nie ma aktywnych dźwięków o wysokim priorytecie. Nawet gdy dźwięki o wysokim priorytecie są aktywne, żądania opóźnionego skupienia powinny być nadal przestrzegane i powinno być możliwe uzyskanie skupienia po ustaniu dźwięku o wysokim priorytecie.
Usługa objętości samochodów OEM
Usługa car audio zarządza kluczowymi zdarzeniami dotyczącymi głośności, odsłuchując regulacje głośności z systemu audio lub słuchając kluczowych zdarzeń związanych z głośnością bezpośrednio z samochodowej usługi wejściowej. W każdym przypadku domyślnym zachowaniem usługi car audio jest określenie, którą grupę głośności należy zmienić, na podstawie aktywnych odtwarzaczy audio i listy priorytetów kontekstu audio.
Udostępniamy dwie listy priorytetów woluminów. Pierwsza lista uwzględnia wszystkie konteksty audio w tej kolejności. Lista prezentowana jest w kolejności malejącej, najwyższy priorytet znajduje się na górze, a najniższy priorytet na dole. Na przykład, jeśli jednocześnie aktywne są dźwięki nawigacji i dźwięki muzyki, głośność nawigacji zostanie zmieniona po naciśnięciu klawisza głośności.
- Nawigacja
- Dzwonić
- Muzyka
- Ogłoszenie
- Komenda głosowa
- Zadzwoń
- Dźwięk systemowy
- Bezpieczeństwo
- Alarm
- Powiadomienie
- Stan pojazdu
- Nagły wypadek
Aby zarządzanie zdarzeniami dotyczącymi klawiszy głośności było mniej skomplikowane, usługa car audio ma drugą listę priorytetów kontekstu audio:
- Dzwonić
- Głoska bezdźwięczna
- Ogłoszenie
- Komenda głosowa
Lista ta jest również prezentowana w kolejności malejącej. Celem tej drugiej listy jest umożliwienie zmiany bardziej popularnych dźwięków poprzez kluczowe zdarzenia. Nietypowymi, być może krótszymi dźwiękami, można zarządzać wyłącznie za pomocą interfejsu ustawień audio.
Rzeczywistą wersję woluminu można ustawić za pomocą konfiguracji audioVolumeAdjustmentContextsVersion . Konfigurację można ustawić na 1 lub 2 ( 2 jest wartością domyślną).
Aby zapewnić większą elastyczność zarządzania głośnością, w systemie Android 14 wprowadzono OemCarAudioVolumeService :
public interface OemCarAudioVolumeService {
OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}
Usługa głośności samochodowego sprzętu audio OEM ma jedną metodę, która uwzględnia volumeAdjustment i żądanie OemCarAudioVolumeRequest :
class OemCarAudioVolumeRequest {
int audioZoneId;
int callState;
List<AudioAttributes> activePlaybackAttributes;
List<AudioAttributes> duckedAttributes;
List<CarVolumeGroupInfo> volumeGroupState;
}
activePlaybackAttributes żądania ma aktywne atrybuty audio. Wszystkie duckedAttributes są obecnie wyciszonymi atrybutami audio. volumeGroupState zawiera bieżący stan grupy woluminów. Żądanie reprezentuje bieżący stan stosu audio i może zostać użyte do określenia, która grupa woluminów powinna zostać zmieniona. Wyniki powinny zostać zwrócone w OemCarVolumeChangeInfo :
class OemCarVolumeChangeInfo {
boolean change;
CarVolumeGroupInfo volumeGroupChanged;
}
Wartość logiczna change wskazuje, czy jakikolwiek wolumin uległ zmianie, true oznacza, że nastąpiła zmiana i należy zaktualizować grupę woluminów. volumeGroupChanged to rzeczywista grupa woluminów, która powinna zostać zmieniona. Grupę tę należy zmienić zgodnie z oryginalnym parametrem volumeAdjustment przekazanym do API. Na przykład, jeśli wyniki wskazują, że grupa woluminów nawigacji powinna zostać wyciszona, wartość logiczna będzie miała true , a zwrócona grupa woluminów powinna być grupą woluminów nawigacji.
Usługa ukrywania samochodów OEM
Usługa car audio zarządza wyciszaniem dźwięku, monitorując zmiany ostrości dźwięku i wysyłając sygnał do warstwy HAL AudioControl , informując, które urządzenia audio mają zostać wyciszone. Kiedy fokus się zmienia, wszystkie aktywne posiadacze fokusu są oceniane w celu określenia, który powinien zostać wyciszony, w oparciu o ten zestaw statycznych reguł wyciszania:
- Dźwięki alarmowe tłumią wszystko oprócz dźwięków połączeń
- Bezpieczeństwo pomija wszystko z wyjątkiem dźwięków alarmowych
- Nawigacja pomija wszystko oprócz dźwięków bezpieczeństwa i alarmowych
- Zadzwoń pomija wszystko oprócz dźwięków bezpieczeństwa, alarmowych i nawigacji
- Dźwięki dzwonka przywołują kaczki głosowe
- Muzykę i ogłoszenia należy omijać szerokim łukiem
Zasady te nie są wyczerpujące i producenci OEM pozostają odpowiedzialni za określenie, w jaki sposób należy wyciszać dźwięki w oparciu o te wytyczne. Producenci OEM mogą aktywniej kontrolować te zalecenia w oparciu o dostępne wymagania. Usługa OemCarDuckingService została wprowadzona w systemie Android 14:
class OemCarAudioDuckingService {
List<AudioAttributes> evaluateAttributesToDuck(
OemCarAudioVolumeRequest request);
}
Ten interfejs API jest wywoływany z usługi car audio w przypadku zmiany ostrości dźwięku. Wykorzystuje ponownie żądanie OemCarAudioVolumeRequest wprowadzone w usłudze głośności samochodów OEM i zawiera istotne informacje umożliwiające podjęcie decyzji, które atrybuty należy ukryć. Lista atrybutów audio, które należy usunąć z interfejsu API, jest porównywana z bieżącym stanem audio:
Atrybut audio aktualnie wyciszony:
- Na liście nadal jest ukrywany
- Nie ma na liście, kaczenie wyłączone
Atrybut audio nie jest obecnie wyciszony:
- Na liście, uchyliłem się
- Nie ma na liście, kaczenie wyłączone
Następnie usługa car audio określa, do których wyjściowych urządzeń audio należą atrybuty audio, i dodaje je odpowiednio do listy wyciszonych wyjściowych urządzeń audio lub listy niewyciszonych urządzeń audio. Jest on ostatecznie wysyłany do warstwy HAL AudioControl w celu wykonania wymaganego wyciszenia na poziomie sprzętowym.
Poniższy rysunek przedstawia uproszczony diagram sekwencji sterowania wyciszaniem dźwięku dla żądania skupienia, gdy używana jest usługa wyciszania dźwięku OEM:
Sekwencja rozpoczyna się, gdy aplikacja zażąda zarządzania fokusem audio za pośrednictwem publicznych interfejsów API menedżera audio. Żądanie zostaje przekazane do serwisu car audio w celu ustalenia wyników. Po podjęciu decyzji o skupieniu dźwięku usługa car audio ocenia wyciszenie dźwięku, wywołując OemCarAudioDuckingService w celu oceny, które atrybuty dźwięku powinny zostać wyciszone. Po zwróceniu wyników z interfejsu API evaluateAttributesToDuck obliczane są urządzenia audio, które mają zostać wyciszone, a na koniec informacja jest wysyłana do modułu AudioControl w celu zastosowania wyciszenia w sprzęcie audio.
Implementacja referencyjnej usługi car audio OEM
AAOS zapewnia referencyjną implementację usługi samochodowej OEM w packages/services/Car/tests/OemCarServiceTestApp , która implementuje OemCarService wraz z OemCarAudioFocusService , OemCarAudioDuckingService i OemCarAudioVolumeService . W tym drugim przypadku każda usługa korzysta z pliku XML w celu załadowania zachowania statycznego. Na przykład OemCarAudioFocusServiceImp ładuje plik oem_focus_config.xml , który zawiera macierz interakcji. Macierz służy do oceny żądania fokusu, gdy wywoływana jest metoda evaluateAudioFocusRequest .
Debugowanie aplikacji testowej referencyjnej
Aplikacja testowa serwisu samochodowego OEM jest częścią kodu źródłowego AOSP. Producenci OEM mogą wprowadzać zmiany zgodnie ze swoimi potrzebami. Do debugowania 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 serwis samochodowy OEM używa polecenia dump serwisu samochodowego dla usługi OEM:
adb shell dumpsys car_service --oem-service
Wyniki mogą być podobne do wyników poniżej:
***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 o dump określa stan funkcji i usługi. Na przykład informacja o zrzucie mIsOemServiceReady określa, czy usługa jest gotowa do użycia, gdzie true oznacza, że jest gotowa, a wartość false oznacza, że nie jest gotowa.