Usługi wtyczek OEM w Androidzie 14 umożliwiają konfigurowanie niektórych komponentów samochodu. W przypadku dźwięku wprowadziliśmy 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
- Sterowanie wyciszaniem tła
Architektura usługi wtyczki do samochodu
Na rysunku poniżej przedstawiono przegląd usług samochodowych i ich relacji z usługą samochodową OEM. Podobnie jak procesy aplikacji i usług samochodowych, proces usługi samochodowej OEM zajmuje własną przestrzeń procesową.
Usługa samochodowa uruchamia usługę samochodową OEM, wyszukując komponent zdefiniowany w config_oemCarService. Jeśli konfiguracja jest pusta, usługa OEM nie istnieje i nie jest uruchamiana. Komponent musi być rozszerzeniem elementu OemCarService.
Usługa audio w samochodzie musi zastąpić interfejsy API do uzyskiwania usługi audio OEM w samochodzie:
public final class OemCarServiceImp extends OemCarService {
@Override
public OemCarAudioFocusService getOemAudioFocusService();
@Override
public OemCarAudioDuckingService getOemAudioDuckingService();
@Override
public OemCarAudioVolumeService getOemAudioVolumeService();
}
Na przykład zobacz przykładową aplikację testową zdefiniowaną w 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 w samochodzie. W związku z tym wszelkie uprawnienia wymagane przez usługi OEM powinny być uzyskiwane za pomocą odpowiedniego mechanizmu. Na przykład zobacz packages/services/Car/data/etc/com.android.car.oemcarservice.testapp.xml.
Usługa audio w samochodzie z architekturą usług 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 wyciszenie
W Androidzie 13 i starszych wersjach to zachowanie było w dużej mierze statyczne i można je było modyfikować tylko za pomocą ustawień, ale w bardzo ograniczonym zakresie. W Androidzie 14 wprowadzono mechanizm, który umożliwia usłudze audio w samochodzie komunikowanie się z komponentem zdefiniowanym przez producenta OEM, który zarządza:
- Aktywność audio
- Wyciszanie tła
- Głośność i wyciszenie
Na rysunku poniżej przedstawiono uproszczoną architekturę usługi audio w samochodzie i usługi OEM w samochodzie. Usługa audio w samochodzie definiuje różne punkty zaczepienia, które mogą wywoływać usługę audio OEM w samochodzie, aby zarządzać zachowaniem dźwięku. Ten drugi przypadek występuje tylko wtedy, gdy zdefiniowany jest odpowiedni komponent usługi audio w samochodzie OEM. W przeciwnym razie usługa audio w samochodzie będzie działać domyślnie.
Aby mieć pewność, że usługa audio w samochodzie i usługa audio OEM w samochodzie są zawsze zsynchronizowane, w przypadku każdego połączenia usługa audio w samochodzie przekazuje wymagane części bieżącego stanu stosu audio do usługi audio OEM w samochodzie. Na przykład, gdy usługa audio w samochodzie przechwytuje żądanie oceny aktywności audio, przekazuje bieżący stan stosu do usługi audio OEM w samochodzie. Bieżący stan obejmuje bieżącego posiadacza fokusu i bieżących utraconych fokusów. Utracone żądania skupienia to żądania, które nadal znajdują się na liście, ale tymczasowo utraciły skupienie.
Usługa audio w samochodzie musi zarządzać wszystkimi działaniami związanymi z dźwiękiem w samochodzie. Jeśli usługa audio w samochodzie nie zarządza niektórymi aspektami zachowania dźwięku, informacje udostępniane usłudze audio OEM w samochodzie są niekompletne. Jeśli na przykład producent OEM zastąpi obsługę aktywności audio w usłudze samochodowej, rejestrując własną politykę aktywności audio, usługa audio w samochodzie nie będzie mogła przekazywać pełnych informacji do usługi audio producenta OEM. Może to wpłynąć na możliwość podejmowania decyzji przez usługę audio OEM, ponieważ może ona nie mieć informacji niewidocznych dla usługi audio w samochodzie.
Aby wykonać działania, usługa audio w samochodzie wywołuje usługi samochodowe OEM. Te wywołania są wykonywane w różnych procesach, co wymaga komunikacji międzyprocesowej (IPC). IPC zwiększa opóźnienie każdego wywołania. Ważne jest, aby zminimalizować opóźnienia w usłudze OEM.
Wywołania usługi audio w samochodzie do usługi OEM są blokujące, więc usługa OEM nie powinna wywoływać usługi audio w samochodzie podczas bezpośrednich ocen interfejsu API. Zamiast tego usługa audio w samochodzie udostępnia niezbędne informacje, dzięki czemu połączenia między tymi dwoma procesami muszą odbywać się tylko w jednym kierunku.
Definicje usług audio w samochodach OEM
Usługa aktywności audio w samochodzie OEM
Usługa audio w samochodzie zarządza żądaniami aktywności audio z aplikacji, rejestrując detektor fokusu zasad audio. Usługa audio w samochodzie ma mechanizm zarządzania zachowaniem fokusu na podstawie statycznej macierzy interakcji. Macierz określa 3 rodzaje interakcji:
Równoczesna interakcja Osoby, które mają fokus, mogą go zachować w tym samym czasie.
Wyłączne interakcje. Przychodzące żądanie ostrości odbiera ostrość bieżącemu posiadaczowi ostrości.
Odrzuć interakcję Odrzucenie przychodzącej prośby o skupienie na podstawie bieżącego właściciela skupienia.
W przypadku niektórych zastosowań w branży motoryzacyjnej jest to wystarczające, ale nie spełnia wszystkich potrzeb związanych z interakcjami, które mogą się różnić ze względu na wymagania producentów 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 przez usługę audio w samochodzie za każdym razem, gdy pojawia się żądanie dotyczące aktywności audio, które wymaga oceny. Jest to dwukierunkowy interfejs API, który blokuje zwracanie wyników. Żądanie zawiera informacje o bieżącym stanie stosu audio:
Te informacje mogą posłużyć do oceny newFocusRequest w porównaniu z obecnymi podmiotami, na których skupia się focusHolders, oraz z obecnymi podmiotami, które tracą na znaczeniu w 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żąca prośba została zaakceptowana, opóźniona czy odrzucona. Wszelkie zmiany w obecnym stosie ostrości należy ustawić w polach newLosers i newlyBlocked, w zależności od charakteru zmiany stosu.
Gdzie newLosers zawiera wpisy, które wcześniej były zaznaczone, ale teraz powinny utracić zaznaczenie na stałe lub tymczasowo. Aplikacje, które trwale utraciły aktywność, zostaną usunięte ze stosu aktywności audio, a aplikacje, które utraciły ją tymczasowo, zostaną przeniesione do stosu bieżących aplikacji, które utraciły aktywność, dopóki nie odzyskają aktywności lub nie zostaną porzucone przez pierwotną aplikację, która o nią poprosiła. Niezależnie od tego odbiorca aktywności w przypadku żądań otrzyma odpowiednią informację o utracie aktywności.
Lista newlyBlocked zawiera wpisy, które wcześniej znajdowały się na liście utraty fokusu, ale teraz są blokowane przez nowy wpis. Blokada może być trwała lub tymczasowa. W przypadku trwałej blokady zaznaczenia wpis zostanie usunięty ze stosu, a informacja o utracie zaznaczenia zostanie wysłana do odbiorców zaznaczenia. W przypadku przejściowej utraty fokusu wpis pozostanie na stosie elementów, które utraciły fokus, ale do jego listy blokujących zostanie dodany nowy blokujący fokus. Nie zostanie wysłana informacja o utracie fokusu, ponieważ została ona już wysłana, gdy element został po raz pierwszy zablokowany. Żądanie zostanie ostatecznie odblokowane, gdy wszystkie bieżące blokady zostaną usunięte, lub zostanie usunięte ze stosu, jeśli ostrość zostanie porzucona.
Drugi interfejs API, notifyAudioFocusChange, jest jednokierunkowy i jest wywoływany przy każdym żądaniu lub rezygnacji z fokusu dźwięku. Interfejs API jest używany głównie do informowania usługi OEM o zmianach ostrości, które mogą wpływać na działanie usługi audio w samochodzie OEM.
Wytyczne dotyczące oceny ostrości
W AAOS aktywność audio służy do zarządzania odtwarzaniem dźwięku i określania, która aplikacja powinna być aktywna, aby zapewnić użytkownikowi optymalne wrażenia. W związku z tym usługa wtyczki OEM powinna uwzględniać te kwestie podczas zarządzania żądaniem aktywności audio:
Aplikacje, które nie mają stałej aktywności audio o wysokim priorytecie (np. połączenie telefoniczne, alarm lub bezpieczeństwo), powinny mieć możliwość uzyskania aktywności audio tymczasowo lub na stałe.
Gdy aktywny jest tryb multimediów, aplikacje, które wysyłają żądania:
Skupienie na korzystaniu z połączeń – możliwość jednoczesnego lub wyłącznego skupienia.
Zaznaczenie nawigacji powinno być możliwe jednocześnie lub oddzielnie.
Tryb użycia Asystenta, który powinien być w stanie odbierać fokus jednocześnie lub wyłącznie.
Gdy aplikacje z wysokim priorytetem dźwięku (np. połączenie telefoniczne, alarm awaryjny lub alert bezpieczeństwa) są aktywne, każda przychodząca opóźniona prośba o skupienie dźwięku powinna zostać przyznana lub opóźniona w zależności od potrzeb.
Powyższe sugestie nie są wyczerpujące, ale mogą pomóc zagwarantować, że aplikacje, które proszą o skupienie, będą mogły je uzyskać, gdy nie ma aktywnych dźwięków o wysokim priorytecie. Nawet gdy aktywne są dźwięki o wysokim priorytecie, opóźnione żądania skupienia powinny być nadal uwzględniane i powinny mieć możliwość uzyskania skupienia po zatrzymaniu dźwięku o wysokim priorytecie.
Usługa głośności w samochodach OEM
Usługa audio w samochodzie zarządza zdarzeniami związanymi z przyciskiem głośności, nasłuchując zmian głośności z systemu audio lub nasłuchując zdarzeń związanych z przyciskiem głośności bezpośrednio z usługi wejścia w samochodzie. W każdym przypadku domyślne działanie usługi audio w samochodzie polega na określeniu, którą grupę głośności zmienić, na podstawie aktywnych odtwarzaczy audio i listy priorytetów kontekstu audio.
Udostępniamy 2 listy priorytetowe dotyczące głośności. Pierwsza lista uwzględnia wszystkie konteksty audio w tej kolejności. Lista jest przedstawiona w porządku malejącym – najwyższy priorytet jest na górze, a najniższy na dole. Jeśli na przykład dźwięk nawigacji i muzyki są aktywne w tym samym czasie, podczas zdarzenia związanego z klawiszem głośności zmieni się głośność nawigacji.
- Nawigacja
- Zadzwoń
- Muzyka
- Ogłoszenie
- Polecenia głosowe
- Dzwonek połączenia
- Dźwięki systemowe
- Bezpieczeństwo
- Alarm
- Powiadomienie
- Stan pojazdu
- Awaria
Aby uprościć zarządzanie zdarzeniami klawisza głośności, usługa audio w samochodzie ma drugą listę priorytetów kontekstu audio:
- Zadzwoń
- Multimedia
- Ogłoszenie
- Polecenia głosowe
Lista jest też prezentowana w kolejności malejącej. Celem tej drugiej listy jest umożliwienie zmiany bardziej popularnych dźwięków za pomocą kluczowych zdarzeń. Nietypowe dźwięki, np. krótsze, można zarządzać tylko w interfejsie ustawień dźwięku.
Rzeczywistą wersję woluminu można ustawić za pomocą konfiguracji audioVolumeAdjustmentContextsVersion. Możesz ustawić wartość 1 lub 2 (domyślnie jest to 2).
Aby zapewnić większą elastyczność zarządzania głośnością, w Androidzie 14 wprowadzono OemCarAudioVolumeService:
public interface OemCarAudioVolumeService {
OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}
Usługa głośności dźwięku w samochodzie OEM 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. Wszystkie atrybuty audio duckedAttributes są obecnie wyciszone. volumeGroupState zawiera bieżący stan grupy woluminów. Żądanie
reprezentuje bieżący stan stosu audio i może służyć do określania,
którą grupę głośności należy zmienić. Wyniki powinny być zwracane w formacie
OemCarVolumeChangeInfo:
class OemCarVolumeChangeInfo {
boolean change;
CarVolumeGroupInfo volumeGroupChanged;
}
Wartość logiczna change wskazuje, czy zmieniła się jakakolwiek liczba, a wartość true wskazuje, że nastąpiła zmiana i należy zaktualizować grupę woluminów. The
volumeGroupChanged to rzeczywista grupa głośności, którą należy zmienić. Ta grupa powinna zostać zmieniona zgodnie z oryginalnym 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 wynosić true, a zwrócona grupa głośności powinna być grupą głośności nawigacji.
Usługa wyciszania w samochodach OEM
Usługa audio w samochodzie zarządza wyciszaniem tła, monitorując zmiany aktywności audio i wysyłając sygnał do AudioControl HAL o tym, które urządzenia audio mają być wyciszone.
Gdy zmieni się fokus, wszystkie aktywne elementy, które mogą mieć fokus, zostaną sprawdzone, aby określić, które z nich powinny zostać wyciszone na podstawie tego zestawu statycznych reguł:
- Dźwięki alarmowe wyciszają wszystko z wyjątkiem dźwięków połączeń.
- Bezpieczeństwo wycisza wszystko oprócz dźwięków alarmowych
- Nawigacja wycisza wszystko z wyjątkiem dźwięków związanych z bezpieczeństwem i sytuacjami alarmowymi.
- Wyciszanie wszystkich dźwięków z wyjątkiem dźwięków związanych z bezpieczeństwem, alarmowych i nawigacyjnych
- Voice wycisza dźwięki dzwonka połączenia
- Muzyka i ogłoszenia powinny być wyciszane przez wszystkie inne dźwięki.
Te reguły nie są wyczerpujące, a producenci OEM nadal ponoszą odpowiedzialność za określanie, jak należy wyciszać dźwięki na podstawie tych wytycznych. Producenci OEM mogą aktywnie zarządzać tymi rekomendacjami na podstawie dostępnych wymagań. W Androidzie 14 wprowadzono:OemCarDuckingService
class OemCarAudioDuckingService {
List<AudioAttributes> evaluateAttributesToDuck(
OemCarAudioVolumeRequest request);
}
Ten interfejs API jest wywoływany z usługi audio w samochodzie w przypadku zmian aktywności audio. Wykorzystuje ona ponownie OemCarAudioVolumeRequest wprowadzone w usłudze dotyczącej liczby samochodów OEM i zawiera odpowiednie informacje, które pozwalają podjąć decyzję o tym, które atrybuty należy wyciszyć. Lista atrybutów audio, które mają być wyciszone przez interfejs API, jest porównywana z bieżącym stanem dźwięku:
Atrybut audio, który jest obecnie wyciszany:
- Na liście, nadal wyciszony
- Nie ma na liście, wyciszanie wyłączone
Atrybut audio nie jest obecnie wyciszony:
- Na liście, wyciszone
- Nie ma na liście, wyciszanie wyłączone
Usługa audio w samochodzie określa następnie, do których urządzeń wyjściowych audio należą atrybuty audio, i dodaje je odpowiednio do listy urządzeń wyjściowych audio z przyciszonym dźwiękiem lub listy urządzeń audio bez przyciszonego dźwięku. Ostatecznie jest ona wysyłana do AudioControl HAL, aby wykonać wymagane wyciszenie na poziomie sprzętu.
Na rysunku poniżej przedstawiono uproszczony diagram sekwencji sterowania wyciszaniem tła w przypadku żądania ostrości, gdy używana jest usługa wyciszania tła OEM:
Sekwencja rozpoczyna się, gdy aplikacja zażąda zarządzania aktywnością audio za pomocą publicznych interfejsów API menedżera dźwięku. Żądanie jest przekazywane do usługi audio w samochodzie, aby określić wyniki. Gdy zostanie podjęta decyzja dotycząca aktywności audio, wyciszanie tła jest oceniane przez usługę audio w samochodzie wywołującą funkcję OemCarAudioDuckingService, aby określić, które atrybuty dźwięku powinny zostać wyciszone. Po zwróceniu wyników przez interfejs evaluateAttributesToDuck API obliczane są urządzenia audio, które mają zostać wyciszone, a następnie informacje są wysyłane do interfejsu AudioControl w celu zastosowania wyciszenia sprzętu audio.
Implementacja referencyjna usługi audio w samochodzie OEM
AAOS udostępnia referencyjną implementację usługi samochodowej 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 wczytywania statycznego zachowania. Na przykład OemCarAudioFocusServiceImp wczytuje oem_focus_config.xml, który zawiera macierz interakcji. Macierz służy do oceny żądania ostrości, gdy wywoływana jest funkcja evaluateAudioFocusRequest.
Debugowanie aplikacji testowej
Testowa aplikacja usługi samochodowej 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 usługa samochodowa OEM używa polecenia dump usługi samochodowej w przypadku usługi OEM:
adb shell dumpsys car_service --oem-service
Wyniki mogą być podobne do tych 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 porcji informacji dump określa stan funkcji i usługi. Na przykład informacje o zrzucie mIsOemServiceReady określają, czy usługa jest gotowa do użycia. Wartość true oznacza, że jest gotowa, a false – że nie jest.