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
- Sterowanie wyciszaniem tła
Architektura usługi wtyczki do samochodu
Na poniższym rysunku 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
Przed Androidem 14 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ę ze zdefiniowanym przez producenta OEM komponentem zarządzającym:
- 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 producenta samochodów. Usługa audio w samochodzie definiuje różne punkty zaczepienia, które mogą wywoływać usługę audio OEM w samochodzie w celu zarządzania 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 fokusu 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 fokusu to żądania fokusu, które nadal znajdują się w stosie, ale tymczasowo utraciły fokus.
Usługa audio w samochodzie musi zarządzać wszystkimi działaniami audio 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ę fokusu audio w usłudze samochodowej, rejestrując własną politykę fokusu 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 skupienia dźwięku z aplikacji, rejestrując odbiornik skupienia 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 z uprawnieniami do skupiania uwagi mogą skupiać uwagę w tym samym czasie.
Wyłączne interakcje. Przychodząca prośba o skupienie uwagi odbiera fokus od bieżącego właściciela fokusu.
Odrzuć interakcję Odrzucenie przychodzącej prośby o skupienie na podstawie bieżącego właściciela skupienia.
W niektórych przypadkach użycia 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. Wprowadzamy w tym celu 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 w samochodzie za każdym razem, gdy pojawia się żądanie dotyczące fokusu 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, które zyskują na zmianach w focusHolders, oraz podmiotami, które na nich tracą 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 bieżącym 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 ostrości wpis zostanie usunięty ze stosu, a informacja o utracie ostrości zostanie wysłana do odbiorców ostrości. W przypadku przejściowej utraty fokusu wpis pozostanie na stosie elementów, które utraciły fokus, ale do jego listy elementów blokujących zostanie dodany nowy element blokujący fokus. Nie zostanie wysłana informacja o utracie fokusu, ponieważ została 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 fokusowania 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 fokus dźwięku 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 podczas zarządzania żądaniem fokusu audio usługa wtyczki OEM powinna uwzględniać te kwestie:
Aplikacje, które nie mają stałego priorytetu w zakresie dźwięku (np. połączenia telefoniczne, alarmy lub bezpieczeństwo), powinny mieć możliwość uzyskania fokusu dźwięku 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.
Elementy nawigacyjne powinny być zaznaczane 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 klawisza głośności, nasłuchując zmian głośności z systemu audio lub nasłuchując zdarzeń klawisza 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 wolumenu. Pierwsza lista uwzględnia wszystkie konteksty audio w tej kolejności. Lista jest przedstawiona w porządku malejącym, od najwyższego do najniższego priorytetu. Jeśli na przykład dźwięk nawigacji i muzyki są aktywne w tym samym czasie, głośność nawigacji zmienia się podczas zdarzenia związanego z klawiszem głośności.
- Nawigacja
- Zadzwoń
- Muzyka
- Ogłoszenie
- Polecenia głosowe
- Dzwonek połączenia
- Dźwięki systemowe
- Bezpieczeństwo
- Alarm
- Powiadomienie
- Stan pojazdu
- Połączenie alarmowe
Aby uprościć zarządzanie zdarzeniami klawiszy głośności, usługa audio w samochodzie ma drugą listę priorytetów kontekstu audio:
- Zadzwoń
- Multimedia
- Ogłoszenie
- Polecenia głosowe
Lista ta 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ń. Nietypowymi dźwiękami, np. krótszymi, można zarządzać tylko w interfejsie ustawień dźwięku.
Rzeczywistą wersję woluminu można ustawić za pomocą konfiguracji audioVolumeAdjustmentContextsVersion. Można 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 audio 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. Atrybuty duckedAttributes to obecnie wszystkie atrybuty audio, które są 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óra grupa głośności powinna zostać zmieniona. Wyniki powinny być zwracane w formacie
OemCarVolumeChangeInfo:
class OemCarVolumeChangeInfo {
boolean change;
CarVolumeGroupInfo volumeGroupChanged;
}
Wartość logiczna change wskazuje, czy zmieniła się jakakolwiek wielkość, a wartość true wskazuje, że
nastąpiła zmiana i należy zaktualizować grupę wielkości. 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 dźwięku, monitorując zmiany fokusu audio i wysyłając sygnał do AudioControl HAL o tym, które urządzenia audio mają być wyciszone.
Gdy fokus się zmieni, 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 oprócz dźwięków związanych z bezpieczeństwem i sytuacjami alarmowymi.
- Wycisz wszystkie dźwięki 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 w zakresie dźwięku. Wykorzystuje ona OemCarAudioVolumeRequest wprowadzone w usłudze dotyczącej liczby pojazdów OEM i zawiera odpowiednie informacje, które pozwalają podjąć decyzję o tym, które atrybuty mają zostać wyciszone. Lista atrybutów audio, które mają być wyciszone, jest porównywana z bieżącym stanem dźwięku:
Atrybut audio jest obecnie wyciszony:
- Na liście nadal jest 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. Jest on ostatecznie wysyłany do AudioControl HAL, aby wykonać wymagane wyciszenie na poziomie sprzętowym.
Na rysunku poniżej przedstawiono uproszczony diagram sekwencji sterowania wyciszaniem dźwięku w przypadku żądania ostrości, gdy używana jest usługa wyciszania OEM:
Sekwencja rozpoczyna się, gdy aplikacja zażąda zarządzania fokusem dźwięku 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 priorytetu dźwięku, usługa audio w samochodzie wywołuje funkcję OemCarAudioDuckingService, aby określić, które atrybuty dźwięku powinny zostać wyciszone. Po otrzymaniu wyników z interfejsu 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 implementację referencyjną usługi samochodowej OEM w packages/services/Car/tests/OemCarServiceTestApp, która implementuje OemCarService, a także OemCarAudioFocusService, OemCarAudioDuckingService i OemCarAudioVolumeService. W tym drugim przypadku każda usługa używa pliku XML do wczytywania statycznego działania. 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 referencyjnej 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 config_oemCarServicekonfiguracji, 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 dla 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.