W Androidzie 14 wprowadzono nową funkcję zdalnego dostępu, która umożliwia partnerom zdalne wybudzanie Androida w pojeździe w celu wykonania określonych zadań. Na przykład, aby uruchomić tryb garażowy na noc w celu zastosowania aktualizacji oprogramowania. Do kompleksowego przepływu pracy wymaganych jest wiele komponentów innych niż Android. Android nie definiuje ani nie zapewnia implementacji komponentów innych niż Android (ta odpowiedzialność należy do Ciebie).
Aby dowiedzieć się więcej, zobacz następujące sekcje:
Przepływ pracy . Przepływ pracy pomiędzy wieloma komponentami przykładowej architektury w celu rejestracji klienta i dostarczania zadań.
Napisz klienta zadań zdalnych . Skorzystaj ze zdalnego dostępu i naucz się pisać klienta zadań zdalnych.
Implementacja dostawcy . Komponenty dostawcy w przykładowej architekturze obsługujące dostęp zdalny.
Reset do ustawień fabrycznych i przeniesienie własności . Dowiedz się, jak sobie poradzić z przywróceniem ustawień fabrycznych i przeniesieniem własności pojazdu.
Przetestuj klienta dostępu zdalnego . Dowiedz się, jak przetestować funkcję zdalnego dostępu.
Architektura
Poniższa treść zakłada, że używana jest następująca przykładowa architektura, która jest hipotetyczna i może nie odzwierciedlać rzeczywistej architektury. Producenci OEM powinni dostosować rzeczywistą implementację do architektury swoich pojazdów i serwerów.
Rysunek 1. Przykładowa architektura.
Przykładowa architektura składa się z następujących komponentów sprzętowych :
Element sprzętowy | Opis |
---|---|
Procesor aplikacji | Procesor obsługujący system Android. Android może działać na pamięci wirtualnej (VM) (nie na rzeczywistym sprzęcie) tego procesora. |
Procesor pojazdu | Procesor odpowiedzialny za kontrolowanie zasilania procesora aplikacji. |
Jednostka sterująca telematyki (TCU) | Procesor w pojeździe zawsze zdolny do odbierania zdalnych wiadomości z chmury. Zakłada się, że TCU jest zawsze włączone lub w trybie niskiego poboru mocy. Użyj zdalnych wiadomości, aby obudzić TCU. |
Serwer budzenia | Zdalny serwer działający w chmurze i odpowiedzialny za komunikację z TCU w pojeździe w celu wydawania poleceń budzenia. |
Zdalny serwer zadań | Zdalny serwer zadań działa w chmurze i współpracuje z ludźmi oraz zarządza zdalnymi zadaniami. |
Przykładowa architektura składa się z następujących komponentów oprogramowania , z których wszystkie działają na systemie Android:
Komponent oprogramowania na Androida | Opis |
---|---|
Serwis samochodowy | Usługa ramowa AAOS udostępniająca interfejsy API dostępu zdalnego. |
Klient zadań zdalnych | Napisana przez dostawcę klasa Service , która wykonuje zadania zdalne. Jeden system Android może obsługiwać wielu klientów zadań zdalnych. |
Zdalny dostęp HAL | Należy wdrożyć funkcję zdalnego dostępu. Warstwa abstrakcji do komunikacji między AAOS a komponentem innym niż Android, takim jak TCU. |
Poniżej opisano komponenty oprogramowania innego niż Android :
Komponent oprogramowania inny niż Android | Opis |
---|---|
Klient, który się budzi | Oprogramowanie działające na TCU, które utrzymuje długotrwałe połączenie z serwerem wznawiania. Utrzymuje także połączenie z HAL dostępu zdalnego, aby dostarczać zdalne zadania do serwisu samochodowego. |
Implementacja serwera budzenia | Serwer komunikujący się z klientem wznowienia działającym na TCU. Może wysyłać żądania wznowienia do klienta wznawiania. |
Implementacja zdalnego serwera zadań | Serwer zarządzający zadaniami zdalnymi. Użytkownicy wchodzą w interakcję z tym serwerem, aby wydawać i monitorować zadania zdalne. |
Przepływ pracy
W tej sekcji wymieniono kroki przykładowego przepływu pracy.
Przykładowy przepływ pracy
Szczegółowy przepływ pracy może wyglądać następująco:
Użytkownik parkuje pojazd w garażu.
Partner stara się aktualizować pojazd z dnia na dzień, gdy interakcje z pojazdem są mało prawdopodobne.
Serwer w chmurze partnera wysyła zdalne zadanie aktualizacji systemu do pojazdu. W szczególności telematyczna jednostka sterująca (TCU).
TCU pojazdu budzi elektroniczną jednostkę sterującą Androida (ECU), a usługa OEM uruchamia tryb garażowy.
Android działa w trybie garażu, aby pobierać i instalować aktualizacje za pośrednictwem Google Play.
Po zastosowaniu aktualizacji Android oznacza zadanie jako ukończone i albo kończy połączenie, albo osiąga określony limit czasu.
Szczegółowy przebieg pracy
Aby uzyskać dostęp zdalny, wymagane są dwa ważne kroki. Pierwsza polega na zarejestrowaniu klienta, czyli powiązaniu konkretnego użytkownika z konkretnym klientem zdalnego zadania działającym na konkretnym pojeździe. Drugim jest dostarczenie zadania, które polega na dostarczeniu zadania zdalnego dla konkretnego użytkownika do konkretnego klienta zadania zdalnego działającego w konkretnym pojeździe.
Zarejestruj klienta
Aby skorzystać z funkcji zdalnego dostępu, użytkownik musi przynajmniej raz otworzyć aplikację kliencką do zadań zdalnych i zakończyć proces rejestracji klienta ( pogrubiony tekst oznacza zadania realizowane przez AAOS):
Po uruchomieniu Car Service pobiera informacje o pojeździe ze zdalnego dostępu HAL.
Podczas uruchamiania Car Service uruchamia wszystkich klientów zadań zdalnych w oparciu o filtr intencji i uprawnienia.
Po uruchomieniu klienta zadań zdalnych, klient zadań zdalnych rejestruje się w serwisie samochodowym.
Car Service powiadamia klienta zadania zdalnego o informacjach rejestracyjnych, w tym identyfikatorze pojazdu i identyfikatorze klienta. Identyfikator klienta jest unikalny i przydzielany temu klientowi przez Car Service. Gwarantujemy, że będzie wyjątkowy wśród wszystkich klientów zadań zdalnych w tym samym pojeździe.
Użytkownik loguje się do zdalnego serwera zadań za pośrednictwem klienta zadań zdalnych i włącza funkcję zdalnego dostępu dla tego pojazdu. Ten krok zazwyczaj obejmuje uwierzytelnianie za pośrednictwem zdalnego serwera zadań.
Klient zdalnego zadania przesyła informacje o użytkowniku wraz z identyfikatorem pojazdu i identyfikatorem klienta do zdalnego serwera zadań i prosi go o powiązanie użytkownika z tym konkretnym klientem i tym konkretnym pojazdem.
Opcjonalnie ten krok może obejmować dodatkowe uwierzytelnianie dwuskładnikowe ze strony użytkownika.
Zdalny serwer zadań musi uwierzytelnić, czy identyfikator pojazdu podany w żądaniu jest zgodny z identyfikatorem pojazdu nadawcy, czego można dokonać poprzez zaświadczenie pojazdu.
O ile nie nastąpi przywrócenie ustawień fabrycznych, proces rejestracji klienta jest wymagany raz na użytkownika i pojazd. Identyfikator klienta jest przechowywany lokalnie w Serwisie samochodowym i pozostaje taki sam dla tego samego klienta.
Rysunek 2. Zarejestruj klienta.
Wyrejestruj klienta
Użytkownik może odłączyć pojazd od swojego konta albo z pojazdu, albo ze zdalnego serwera zadań:
W pojeździe użytkownicy mogą otworzyć aplikację kliencką do zadań zdalnych i wysłać żądanie odłączenia, aby odłączyć ten pojazd od wcześniej połączonych kont użytkowników.
Na zdalnym serwerze zadań użytkownicy mogą zalogować się na swoje konto i odłączyć wcześniej powiązany pojazd z tym kontem.
Jeśli użytkownik odłączy pojazd od swojego konta, zdalny serwer zadań musi usunąć zapisane mapowanie dla konkretnego użytkownika.
Dostarczaj zadania
W chmurze:
Użytkownik korzysta ze zdalnego serwera zadań, aby wysłać zdalne zadanie do określonego pojazdu.
Zdalny serwer zadań mapuje identyfikator użytkownika na identyfikator pojazdu i identyfikator klienta. Wysyła dane zadania, identyfikator pojazdu i identyfikator klienta do serwera budzenia.
Serwer budzenia znajduje konkretny TCU dla identyfikatora pojazdu (zakładając, że rejestracja TCU została już wykonana) i wysyła dane zadania oraz identyfikator klienta do TCU.
Na pojeździe ( pogrubiony tekst oznacza zadania wykonywane przez AAOS):
TCU odbiera zdalne zadania ze zdalnego serwera.
Jeśli procesor aplikacji (AP) z systemem AAOS jest wyłączony, TCU używa procesora pojazdu (VP) do wybudzenia punktu dostępowego.
Car Service otrzymuje zadania od TCU.
Car Service przydziela zadania odpowiedniemu klientowi zadań zdalnych.
Klient zadań zdalnych odbiera i wykonuje zadanie.
( Opcjonalnie ) Klient zadań zdalnych kontaktuje się z serwerem zadań, aby uzyskać więcej szczegółów zadania i wykonuje je.
( Opcjonalnie ) Usługa klienta zadań zdalnych raportuje wyniki zadania do serwera zadań.
Zdalny klient zadania powiadamia serwis samochodowy o zakończeniu zadania.
W razie potrzeby Serwis Samochodowy przywraca stan zasilania pojazdu.
Rysunek 3. Dostarczaj zadania.
Napisz klienta zadań zdalnych
CarRemoteAccessManager
zapewnia interfejs API dla funkcji zdalnego dostępu. Aby dowiedzieć się więcej, zobacz CarRemoteAccessManager . Klient zadań zdalnych to usługa systemu Android, która wykonuje zadania zdalne i korzysta z narzędzia CarRemoteAccessManager
. Wymaga to uprawnień PERMISSION_USE_REMOTE_ACCESS
i PERMISSION_CONTROL_REMOTE_ACCESS
oraz musi zadeklarować filtr intencji dla RemoteTaskClientService
taki jak:
<service android:name=".remoteaccess.RemoteTaskClientService"
android:directBootAware="true"
android:exported="true">
<intent-filter>
<action android:name="android.car.remoteaccess.RemoteTaskClientService" />
</intent-filter>
</service>
Zdalny klient zadania powinien zarejestrować się w serwisie samochodowym podczas tworzenia:
public final class RemoteTaskClientService extends Service {
@Override
public void onCreate() {
// mCar = Car.createCar()...
mRemoteAccessManager = (CarRemoteAccessManager)
mcar.getCarManager(Car.CAR_REMOTE_ACCESS_SERVICE);
if (mRemoteAccessManager == null) {
// Remote access feature is not supported.
return;
}
mRemoteAccessManager.setRemoteTaskClient(executor, mRemoteTaskClient);
}
}
Aby zwrócić wartość null, musi ona zastąpić funkcję onBind.
@Override
public IBinder onBind(Intent intent) {
return null;
}
Car Service zarządza jego cyklem życia. Car Service łączy się z tą usługą podczas uruchamiania i po nadejściu zadania zdalnego. Car Service rozłącza się z tą usługą po zakończeniu zadania. Aby dowiedzieć się więcej, zobacz Zarządzanie cyklem życia usługi .
Klient zadań zdalnych działa jako użytkownik systemu, więc nie ma dostępu do żadnych danych specyficznych dla użytkownika.
Poniższy przykład pokazuje, jak obsługiwać zarejestrowane wywołania zwrotne:
private final class RemoteTaskClient
implements CarRemoteAccessManager.RemoteTaskClientCallback {
@Override
public void onRegistrationUpdated(
RemoteTaskClientRegistrationInfo info) {
// Register to remote task server using info.
}
@Override
public void onRemoteTaskRequested(String taskId,
byte[] data, int remainingTimeSec) {
// Parses the data and execute the task.
// Report task result to remote task server.
mRemoteAccessManager.reportRemoteTaskDone(taskId);
}
@Override
public void onShutdownStarting(CompleteableRemoteTaskFuture future) {
// Stop the executing task.
// Clear the pending task queue.
future.complete();
}
}
Implementacja dostawcy
Funkcja zdalnego dostępu jest opcjonalna i domyślnie wyłączona. Aby włączyć tę funkcję, dodaj RRO, takie jak następujące:
// res/xml/overlays.xml
<?xml version="1.0" encoding="utf-8"?>
<overlay>
<item target="array/config_allowed_optional_car_features" value="@array/config_allowed_optional_car_features" />
</overlay>
// res/values/config.xml
<resources xmlns:xliff="urn:oasis:names:tc:xliff:document:1.2">
<string-array translatable="false" name="config_allowed_optional_car_features">
<item>car_remote_access_service</item>
</string-array>
</resources>
// Android.bp
runtime_resource_overlay {
name: "RemoteAccessOverlay",
resource_dirs: ["res"],
manifest: "AndroidManifest.xml",
sdk_version: "current",
product_specific: true
}
Lub użyj następującego polecenia adb w kompilacji userdebug/eng:
adb shell cmd car_service enable-feature car_remote_access_service
Wymagania dotyczące Androida
Zdalny dostęp HAL
Warstwa abstrakcji sprzętu dostępu zdalnego (HAL) to implementowana przez dostawcę warstwa abstrakcji służąca do komunikacji pomiędzy systemem AAOS a innym ECU (na przykład TCU). Jest to obowiązkowe w przypadku obsługi funkcji zdalnego dostępu. Nie trzeba go implementować, jeśli nie zaimplementowano funkcji zdalnego dostępu.
Interfejs jest zdefiniowany w pliku IRemoteAccess.aidl i zawiera następujące metody:
Klasa | Opis |
---|---|
String getVehicleId() | Pobiera unikalny identyfikator pojazdu, który może zostać rozpoznany przez serwer wznawiania. |
String getWakeupServiceName() | Pobiera nazwę zdalnego serwera wznawiania. |
String getProcessorId() | Pobiera unikalny identyfikator procesora, który można rozpoznać po wznowieniu działania klienta. |
void setRemoteTaskCallback(IRemoteTaskCallback callback) Ustawia wywołanie zwrotne, które będzie wywoływane w przypadku żądania zadania zdalnego. | |
void clearRemoteTaskCallback() | Czyści wcześniej ustawione wywołanie zwrotne zadania zdalnego. |
void notifyApStateChange(in ApState state) Wykrywa, czy procesor aplikacji jest gotowy na odbieranie zadań zdalnych. |
Interfejs wywołania zwrotnego jest zdefiniowany w IRemoteTaskCallback.aid
.
Klasa | Opis |
---|---|
oneway void onRemoteTaskRequested(String clientId, in byte[] data) Wywołanie zwrotne wywoływane w przypadku żądania zadania zdalnego. |
Zobacz implementację referencyjną z zewnętrznym TCU. Implementacja wykorzystuje długotrwały strumień odczytu do odbierania zadań zdalnych i obsługuje następujące polecenie debug
:
dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default
Pojazd HAL
Aby obsługiwać funkcję zdalnego dostępu, VHAL musi obsługiwać następujące właściwości:
Klasa | Opis |
---|---|
SHUTDOWN_REQUEST | Żąda wyłączenia jednostki głównej. |
VEHICLE_IN_USE |
|
Aby dowiedzieć się więcej, zobacz Obsługiwane właściwości systemu .
Tryb cichy
Funkcja zdalnego dostępu musi obsługiwać tryb cichy, aby pojazd mógł zostać uruchomiony w trybie cichym i wykonywać zadania zdalne, gdy nie ma użytkownika. W trybie cichym urządzenie AAOS uruchamia się z wyłączonym wyświetlaczem i dźwiękiem.
Tryb cichy jest kontrolowany przez dwa pliki sysfs
jądra Linux.
Klasa | Opis |
---|---|
/sys/kernel/silent_boot/pm_silentmode_kernel_state Reprezentuje bieżący tryb cichy. | |
/sys/kernel/silent_boot/pm_silentmode_hw_state Reprezentuje sygnał sprzętowy umożliwiający ustawienie nowego trybu cichego. |
Procesor pojazdu wysyła sygnał sprzętowy do systemu Android SoC w celu włączenia/wyłączenia trybu cichego. Sygnał (0 lub 1) jest zapisywany w /sys/kernel/silent_boot/pm_silentmode_hw_state
. Następnie struktura AAOS aktualizuje odpowiednio /sys/kernel/silent_boot/pm_silentmode_kernel_state
, który reprezentuje bieżący tryb cichy. Moduły AAOS sprawdzają /sys/kernel/silent_boot/pm_silentmode_kernel_state
aby wiedzieć, czy system znajduje się w trybie cichym, czy nie.
Po odebraniu zdalnego zadania i uruchomieniu systemu AAOS procesor pojazdu ustawia tryb cichy i uruchamia AAOS, dzięki czemu system uruchamia się z wyłączonym wyświetlaczem/dźwiękiem.
Komponenty w pojeździe inne niż Android
Procesor pojazdu
Procesor pojazdu to procesor w pojeździe, który może kontrolować zasilanie procesora aplikacji z systemem Android. W przykładowej architekturze TCU budzi procesor aplikacji, wysyłając sygnał do procesora pojazdu.
Komponenty w pojeździe inne niż Android
TCU pojazdu może zawsze odbierać komunikaty zdalne.
Klient wznawiania działa na TCU, aby zapewnić długotrwałe połączenie ze zdalnym serwerem wznawiania.
AAOS działający w punkcie dostępowym może komunikować się z klientem wybudzania działającym w TCU poprzez warstwę HAL dostępu zdalnego.
Rysunek 4. TCU (klient wybudzania).
Komponenty w chmurze
Serwer budzenia
Serwer wznawiania komunikuje się z klientem wznawiania w TCU w celu:
- Utrzymaj długotrwałe połączenie z TCU pojazdu.
- Znajdź konkretny TCU na podstawie identyfikatora pojazdu.
- Zgłoś stan pojazdu. Na przykład online lub offline albo ostatni raz online na zdalnym serwerze zadań.
W rzeczywistej implementacji serwer wznawiania można połączyć ze zdalnym serwerem zadań.
Zdalny serwer zadań
Zdalny serwer zadań zarządza tymi zdalnymi zadaniami.
Użytkownik wchodzi w interakcję z serwerem, aby rozpocząć nowe zadania zdalne i monitorować zadania zdalne.
Korzysta ze zdalnego serwera budzenia, aby obudzić procesor aplikacji w pojazdach.
Współpracuje ze zdalnym klientem zadań działającym w pojeździe.
Przechowuje informacje rejestracyjne klienta. Spowoduje to powiązanie konkretnego użytkownika z konkretnym klientem zadania zdalnego w konkretnym pojeździe.
Zwykle dane zadania wysyłane za pośrednictwem zdalnego serwera zadań do serwera wznawiania, do TCU pojazdu i ostatecznie do zdalnego klienta zadań to po prostu identyfikator zadania. Klient zadań zdalnych używa identyfikatora zadania do pobrania szczegółowych informacji ze zdalnego serwera zadań.
Wymagania dotyczące prywatności i bezpieczeństwa
Zadanie | Stan | Wymóg |
---|---|---|
TCU (klient wybudzania) | MUSIEĆ |
|
Serwer budzenia | MUSIEĆ |
|
Klient zadań zdalnych | MUSIEĆ |
|
Zdalny serwer zadań | MUSIEĆ |
|
Reset do ustawień fabrycznych i przeniesienie własności
Jeśli użytkownik przywróci ustawienia fabryczne, identyfikator klienta zapisany w Serwisie samochodowym zostanie usunięty. Jednakże serwery (zdalny serwer zadań i zdalny serwer wznawiania) nie są informowane. Serwery zachowują mapowanie wygasłego identyfikatora klienta na pojazd. W rezultacie, jeśli użytkownik rozpocznie nowe zdalne zadanie dla pojazdu, użyje on wygasłego identyfikatora klienta. Pojazd został wybudzony, ale zadania zdalnego nie można wykonać, ponieważ klient zadania zdalnego ma inny identyfikator klienta, który nie pasuje.
Poniżej opisano jedną z możliwych implementacji przywracania ustawień fabrycznych.
Gdy użytkownik przywróci ustawienia fabryczne, sprzedawca poprosi go o zalogowanie się na zdalnym serwerze zadań i odłączenie pojazdu od konta, jeśli użytkownik wcześniej połączył pojazd. Nie gwarantujemy, że urządzenie będzie miało dostęp do sieci w czasie przywracania ustawień fabrycznych. Dlatego wydanie żądania odłączenia z urządzenia w momencie przywracania ustawień fabrycznych może nie być wykonalne.
Po każdym przeniesieniu własności pojazdu należy wykonać pewne czynności, aby poprzedni właściciel nie mógł już zlecać zdalnych zadań pojazdowi. Nowy właściciel może zostać poproszony na przykład o:
Wykonaj reset do ustawień fabrycznych. Dzięki temu identyfikator klienta zostanie ponownie wygenerowany. Po tym kroku poprzedni właściciel nadal może wybudzić pojazd, ale nie może już wykonywać zadań zdalnych.
Otwórz aplikację kliencką do zadań zdalnych i wykonaj proces Wyrejestruj klienta , aby odłączyć pojazd od konta poprzedniego właściciela. Nowy właściciel może skorzystać z procedury rejestracji klienta, aby powiązać pojazd ze swoim kontem i zastąpić wcześniej połączone konto.
Nowy właściciel może skorzystać z procesu Zarejestruj klienta , aby powiązać pojazd ze swoim kontem i zastąpić wcześniej połączone konto.
Przetestuj klienta zadań zdalnych
Udostępniamy referencyjny default
katalog HAL zdalnego dostępu do testowania klientów zadań zdalnych. Możesz użyć poniższego polecenia debug
, aby wstrzyknąć fałszywe zadanie zdalne do warstwy HAL, która zostanie przekazana do klienta zadań zdalnych, jeśli podasz poprawny identyfikator klienta. Identyfikator klienta można uzyskać, rejestrując informacje rejestracyjne w implementacji klienta zadań zdalnych.
adb root && adb shell dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default --inject-task [clientID] [taskData]