Android 14 wprowadza nową funkcję dostępu zdalnego. który umożliwia partnerom zdalne wybudzanie Androida w pojeździe w celu realizacji do konkretnych zadań. Aby wykonać na przykład polecenie Tryb garażowy w nocy – instalowanie oprogramowania aktualizacje. Kompleks wymaga wielu komponentów spoza Androida proces. Android nie definiuje ani nie zapewnia implementacji na urządzeniach z systemem innym niż Android (to Ty odpowiadasz za to?).
Więcej informacji znajdziesz w tych sekcjach:
Przepływ pracy. Przepływ pracy między wieloma komponentami w przykładzie architektura rejestracji klientów i dostarczania zadań.
Pisanie zdalnego klienta zadań. Używaj dostępu zdalnego i dowiedz się, jak napisać zdalnego klienta zadań.
Wdrożenie dostawcy. Komponenty dostawców w przykładową architekturę obsługującą dostęp zdalny.
Przywracanie do ustawień fabrycznych i przenoszenie własności Dowiedz się, co zrobić przywracanie ustawień fabrycznych i przeniesienie własności pojazdu.
Przetestuj klienta dostępu zdalnego. Dowiedz się, jak przetestować dostęp zdalny funkcji.
Architektura
W poniższej treści przyjęto następującą przykładową architekturę, która jest hipotetyczna i może nie odzwierciedlać rzeczywistej architektury. OEM powinien dostosować się do tych zasad. faktyczne wdrożenie w architekturze pojazdu i serwera.
Rysunek 1. Przykładowa architektura.
Przykładowa architektura składa się z tych komponentów sprzętu:
| Komponent sprzętowy | Opis |
|---|---|
| Procesor aplikacji | Procesor z Androidem. Android może działać w pamięci wirtualnej (nie na sprzęcie) tego procesora. |
| Procesor samochodowy | Procesor odpowiedzialny za sterowanie zasilaniem aplikacji procesora. |
| Jednostka telematyczna (TCU) | Procesor w pojeździe zawsze może odbierać wiadomości zdalne od do chmury. Przyjmuje się, że TCU jest zawsze włączony lub w trybie niskiego zużycia energii. Używaj wiadomości zdalnych, aby wybudzić TCU. |
| Serwer wybudzania | Serwer zdalny, który działa w chmurze i odpowiada za komunikuje się z modułem TCU w pojeździe, aby wydawać polecenia wybudzania. |
| Zdalny serwer zadań | Zdalny serwer zadań działa w chmurze i wchodzi w interakcje z ludźmi zarządza zdalnymi zadaniami. |
Przykładowa architektura składa się z tych komponentów oprogramowania, a wszystkie które działają na Androidzie:
| Komponent oprogramowania na Androida | Opis |
|---|---|
| Usługa samochodowa | Usługa platformy AAOS, która udostępnia interfejsy API dostępu zdalnego. |
| Klient zadań zdalny | Napisany przez dostawcę
Service
, która wykonuje zadania zdalne. Jeden system Android może obsługiwać wiele
zdalnych klientów zadań. |
| HAL dostępu zdalnego | Wymagana na potrzeby dostępu zdalnego. Warstwa abstrakcyjna służąca do komunikacji między AAOS a urządzeniami innymi niż Android takim jak TCU. |
Komponenty oprogramowania inne niż Android są opisane poniżej:
| Komponent oprogramowania innego niż Android | Opis |
|---|---|
| Wybudzanie klienta | Oprogramowanie działające na TCU, które utrzymuje długotrwałe połączenie z serwer wybudzania. Utrzymuje też połączenie z HAL dostępu zdalnego. realizując zadania zdalne w ramach Usługi samochodowej. |
| Implementacja wybudzania serwera | Serwer komunikujący się z klientem wybudzania działającym w TCU. Puszka wysyłania żądań wybudzenia do klienta wybudzania. |
| Implementacja zdalnego serwera zadań | Serwer zarządzający zadaniami zdalnymi. Użytkownicy korzystają z tego serwera w celu i monitorowania zadań zdalnych. |
Workflow
W tej sekcji wymieniono kroki przykładowego przepływu pracy.
Przykładowy przepływ pracy
Szczegółowy przepływ pracy może wyglądać tak:
Użytkownik parkuje pojazd w garażu.
Partner chce zaktualizować pojazd w nocy, gdy interakcje z pojazdem są mało prawdopodobne.
Serwer chmury partnera wysyła do pojazdu zdalne zadanie aktualizacji. Konkretnie chodzi o jednostkę sterowania telematycznego (TCU).
TCU pojazdu wybudza elektroniczne jednostki sterujące Androida (ECU). usługa OEM aktywuje tryb garażowy.
Android używa trybu Garaż, aby pobierać i instalować aktualizacje z Google Play.
Po zastosowaniu aktualizacji Android oznaczy zadanie jako ukończone i albo zakończy połączenie lub upłynie określony czas.
Szczegółowy przepływ pracy
Aby uzyskać dostęp zdalny, musisz wykonać 2 ważne kroki. Po pierwsze, Rejestrowanie klienta, czyli połączenie określonego użytkownika z konkretnym pilotem klienta zadania uruchomionego w konkretnym pojeździe. Drugi polega na wykonaniu zadania, jest przekazanie zadania zdalnego konkretnemu użytkownikowi w ramach konkretnego pojazdu.
Rejestrowanie klienta
Aby używać funkcji dostępu zdalnego, użytkownik musi otworzyć klienta zdalnego zadań aplikację co najmniej raz i dokończyć proces rejestracji klienta (pogrubiony tekst) wskazuje zadania zaimplementowane przez AAOS):
Po uruchomieniu usługa samochodowa pobiera informacje o pojeździe ze zdalnego dostępu HAL.
Podczas uruchamiania usługa Car Service uruchamia wszystkie zdalne klienty zadań oparte na i filtr intencji.
Po uruchomieniu zdalnego klienta zadania rejestruje się on samodzielnie Usługi samochodowej.
Usługa samochodowa powiadamia klienta zadania zdalnego o rejestracji w tym identyfikator pojazdu i identyfikator klienta. Identyfikator klienta jest unikalny i przypisany temu klientowi przez Serwis samochodowy. Niepowtarzalność wśród wszystkich zdalnych klientów do wykonywania zadań w tym samym pojeździe.
Użytkownik loguje się na zdalnym serwerze zadań za pomocą zdalnego klienta zadań oraz włącza funkcję dostępu zdalnego w tym pojeździe. Ten krok zazwyczaj wymaga uwierzytelnienia przez zdalny serwer zadań.
Klient zadania zdalnego przesyła informacje o użytkowniku wraz z identyfikatorem pojazdu i identyfikatora klienta, ze zdalnym serwerem zadań oraz prosi o połączenie użytkownika w przypadku danego klienta i tego konkretnego pojazdu.
Opcjonalnie ten krok może obejmować dodatkowe uwierzytelnianie dwuskładnikowe od użytkownika.
Zdalny serwer zadań musi potwierdzić, że identyfikator pojazdu podany w żądanie jest zgodne z identyfikatorem pojazdu nadawcy. Można to zrobić za pomocą atestacji pojazdów.
O ile nie przywrócono ustawień fabrycznych, wymagany jest proces rejestracji klienta. raz na użytkownika na pojazd. Identyfikator klienta jest przechowywany lokalnie w usłudze Car Service i pozostaje bez zmian dla tego samego klienta.
Rysunek 2. Zarejestruj klienta.
Wyrejestrowywanie klienta
Użytkownik może odłączyć pojazd od swojego konta, zarówno z poziomu pojazdu, jak i z zdalny serwer zadań:
W pojeździe użytkownicy mogą otworzyć aplikację klienta zdalnego zadań i rozpocząć prośba o odłączenie tego pojazdu od wcześniej powiązanego użytkownika kont.
Na zdalnym serwerze zadań użytkownicy mogą logować się na swoje konto i odłączać wcześniej połączony pojazd z tego konta.
Jeśli użytkownik odłączy pojazd od swojego konta, zdalny serwer zadań musi usuń zapisane mapowanie danego użytkownika.
Przesyłanie zadań
W chmurze:
Użytkownik używa zdalnego serwera zadań, aby wysłać zadanie zdalne do określonego pojazdu.
Zdalny serwer zadań mapuje identyfikator użytkownika na identyfikator pojazdu i identyfikator klienta. it wysyła dane zadania, identyfikator pojazdu i klienta do serwera wybudzania.
Serwer wybudzania znajduje konkretną jednostkę TCU dla identyfikatora pojazdu (przy założeniu, że Rejestracja w TCU została już ukończona) i wysyła dane zadania oraz identyfikator klienta do czyli TCU.
Na pojeździe (pogrubiony tekst wskazuje zadania wykonywane przez AAOS):
TCU otrzymuje zadania zdalne od zdalnego serwera.
Jeśli procesor aplikacji (AP) z systemem AAOS jest wyłączony, TCU używa parametru procesora pojazdu (VP), aby wybudzić punkt dostępu.
Serwis samochodowy otrzymuje zadania od TCU.
Serwis samochodowy przydziela zadania odpowiedniemu zdalnemu klientowi zadania.
Klient zadań zdalnych otrzymuje i wykonuje zadanie.
(Opcjonalnie) Aby uzyskać więcej szczegółów zadania, kontaktuje się z serwerem zadań zdalnego klienta zadań i wykona zadanie.
(Opcjonalnie) Usługa klienta zadań zdalnych zgłasza wynik zadania na serwer zadań.
Klient zadań zdalnych powiadamia usługę samochodu, gdy zadanie zostanie ukończone.
W razie potrzeby usługa samochodowa przywraca stan zasilania pojazdu.
Rysunek 3. realizacji zadań.
Pisanie zdalnego klienta zadań
CarRemoteAccessManager udostępnia interfejs API na potrzeby funkcji dostępu zdalnego. Aby się uczyć
więcej, patrz
CarRemoteAccessManager.
Klient zadań zdalny to usługa na Androida, która wykonuje zadania zdalne i wykorzystuje
CarRemoteAccessManager Wymaga to PERMISSION_USE_REMOTE_ACCESS i
PERMISSION_CONTROL_REMOTE_ACCESS i muszą zadeklarować filtr intencji dla
RemoteTaskClientService na przykład:
<service android:name=".remoteaccess.RemoteTaskClientService"
android:directBootAware="true"
android:exported="true">
<intent-filter>
<action android:name="android.car.remoteaccess.RemoteTaskClientService" />
</intent-filter>
</service>
Klient zadań zdalnych powinien zarejestrować się w usłudze samochodowej 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);
}
}
Musi zastąpić funkcję onBind, aby zwrócić wartość null.
@Override
public IBinder onBind(Intent intent) {
return null;
}
Serwis samochodowy zarządza cyklem życia. Usługa samochodowy łączy się z tą usługą podczas po uruchomieniu i pojawieniu się zadania zdalnego. Usługa Car Service zostanie odłączone od tej usługi, gdy zadanie zostało wykonane. Więcej informacji: Zarządzanie cyklem życia usługi.
Zdalny klient zadań działa jako użytkownik systemowy, więc nie ma dostępu do żadnych danych 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 przez dostawców
Funkcja dostępu zdalnego jest opcjonalna i domyślnie wyłączona. Aby włączyć funkcję , dodaj RRO w taki sposób:
// 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
}
Możesz też użyć tego polecenia adb w kompilacji userdebug/eng:
adb shell cmd car_service enable-feature car_remote_access_service
Wymagania dotyczące Androida
HAL dostępu zdalnego
Warstwa abstrakcji sprzętowej dostępu zdalnego (HAL) jest implementowana przez dostawcę. warstwa abstrakcji do komunikacji między AAOS a inną jednostką ECU (na przykład TCU). Jest to konieczne do obsługi funkcji dostępu zdalnego. Nie wymaga należy wdrożyć, jeśli funkcja dostępu zdalnego nie jest zaimplementowana.
Interfejs jest zdefiniowany na stronie IRemoteAccess.aidl i obejmuje te metody:
| Kategoria | Opis |
|---|---|
String getVehicleId() |
Otrzymuje unikalny identyfikator pojazdu rozpoznawalny po wybudzeniu serwera. |
String getWakeupServiceName() |
Pobiera nazwę zdalnego serwera wybudzania. |
String getProcessorId() |
Pobiera unikalny identyfikator procesora, który można rozpoznać po aktywowaniu klienta. |
void setRemoteTaskCallback(IRemoteTaskCallback callback)
Ustawia wywołanie zwrotne po zażądaniu zadania zdalnego. |
|
void clearRemoteTaskCallback() |
Czyści ustawione wcześniej wywołanie zwrotne zadania. |
void notifyApStateChange(in ApState state)
Określa, czy procesor aplikacji jest gotowy do odbierania zadań zdalnych. | |
Interfejs wywołania zwrotnego jest zdefiniowany pod adresem
IRemoteTaskCallback.aid
| Kategoria | Opis |
|---|---|
oneway void onRemoteTaskRequested(String clientId, in byte[] data)
Wywołanie zwrotne, które jest wywoływane, gdy wymagane jest zadanie zdalne. |
|
Zobacz
implementacja referencyjna
z zewnętrznym TCU. Implementacja wykorzystuje długotrwały strumień odczytu do
umożliwia odbieranie zadań zdalnych i obsługuje następujące polecenie debug:
dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default
HAL pojazdu
Aby można było obsługiwać funkcję dostępu zdalnego, VHAL musi obsługiwać te właściwości:
| Kategoria | Opis |
|---|---|
SHUTDOWN_REQUEST |
Żąda wyłączenia jednostki głównej. |
VEHICLE_IN_USE |
|
Więcej informacji: Obsługiwane właściwości systemowe.
Tryb cichy
Aby pojazd mógł korzystać z funkcji dostępu zdalnego, musi być obsługiwany tryb cichy mogą uruchamiać się w trybie cichym i wykonywać zdalne zadania, gdy nie ma użytkownika. Na w trybie cichym, urządzenie AAOS uruchamia się z wyłączonym ekranem i dźwiękiem.
Tryb cichy jest sterowany za pomocą 2 plików sysfs jądra systemu Linux.
| Kategoria | 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 służący do ustawienia nowego trybu cichego. |
|
Procesor pojazdu wysyła sygnał sprzętowy do układu SOC na Androidzie, aby włączyć lub wyłączyć tryb Cichy.
i trybu uzyskiwania zgody. Sygnał (0 lub 1) jest zapisywany w
/sys/kernel/silent_boot/pm_silentmode_hw_state Następnie aktualizacje platformy AAOS
/sys/kernel/silent_boot/pm_silentmode_kernel_state odpowiednio,
reprezentuje obecny tryb cichy. Testy modułów AAOS
/sys/kernel/silent_boot/pm_silentmode_kernel_state, aby dowiedzieć się, czy system
jest w trybie cichym.
Po otrzymaniu zadania zdalnego i uruchomieniu AAOS procesor pojazdu ustawia Tryb cichy i uruchamianie AAOS, aby system uruchamiał się z wyłączonym wyświetlaczem/dźwiękiem.
Komponenty w pojeździe bez Androida
Procesor samochodowy
Procesor w pojeździe to znajdujący się w pojeździe procesor, który może sterować mocą dla procesora aplikacji z Androidem. W przykładowej architekturze TCU Wybudza procesor aplikacji, wysyłając sygnał do pojazdu. procesora.
Komponenty w pojeździe bez Androida
Moduł TCU pojazdu może zawsze odbierać komunikaty zdalne.
Klient wybudzania działa na TCU, aby zapewnić długotrwałe połączenie z zdalnym serwerem wybudzania.
System AAOS uruchomiony w punkcie dostępu może komunikować się z klientem wybudzania działającym na TCU przez HAL zdalnego dostępu.
Rysunek 4. TCU (klient wybudzania).
Komponenty w chmurze
Serwer wybudzania
Serwer wybudzania komunikuje się z klientem wybudzania na TCU w celu:
- utrzymywać długoterminowy związek z końcem TCU pojazdu.
- Znajdź konkretny TCU na podstawie identyfikatora pojazdu.
- Zgłaszać stan pojazdu. Na przykład online lub offline albo na końcu czas online na zdalny serwer zadań.
W rzeczywistości serwer wybudzania można połączyć z serwer zadań.
Zdalny serwer zadań
Tymi zdalnymi zadaniami zarządza zdalny serwer zadań.
Użytkownik wchodzi w interakcję z serwerem, aby rozpoczynać nowe zadania zdalne i monitorować zadań zdalnych.
Używa zdalnego serwera wybudzania do wybudzania procesora aplikacji pojazdów.
Wchodzi w interakcję z klientem zadań zdalnych działającym w pojeździe.
Przechowuje informacje rejestracyjne klienta. Wiąże się to z konkretnym użytkownikiem z konkretnym klientem do wykonywania zadań zdalnych w konkretnym pojeździe.
Zwykle dane zadania są wysyłane przez zdalny serwer zadań do urządzenia aktywującego przez serwer, do TCU pojazdu, a ostatecznie do zdalnego klienta zadań. identyfikator zadania. Zdalny klient zadań używa identyfikatora zadania, aby pobrać szczegółowe ze zdalnego serwera zadań.
Wymagania dotyczące prywatności i bezpieczeństwa
| Zadanie | Warunek | Wymaganie |
|---|---|---|
| TCU (klient wybudzania) | MUSI |
|
| Serwer wybudzania | MUSI |
|
| Klient zadań zdalny | MUSI |
|
| Zdalny serwer zadań | MUSI |
|
Przywracanie do ustawień fabrycznych i przenoszenie własności
Jeśli użytkownik przywróci ustawienia fabryczne, identyfikator klienta zapisany w usłudze samochodowej to wyczyszczone dane. Jednak serwery (zdalny serwer zadań i zdalny serwer wybudzania) nie są nie poinformowano. Serwery zachowują mapowanie z wygasłego identyfikatora klienta na w pojeździe. Jeśli więc użytkownik rozpocznie nowe zadanie zdalne w pojeździe, używa nieważnego identyfikatora klienta. Pojazd został wybudzony, ale zadanie zdalne nie można wykonać, ponieważ klient zadań zdalnych ma inny identyfikator klienta, który nie pasuje.
Poniżej opisujemy jedną z możliwych implementacji przywracania do ustawień fabrycznych.
Gdy użytkownik przywróci ustawienia fabryczne, dostawca poprosi go o zalogowanie się zdalny serwer zadań i odłączać pojazd od konta, jeśli użytkownik: wcześniej połączony. Nie ma gwarancji, że urządzenie będzie mieć sieć dostępu podczas resetowania do ustawień fabrycznych. W związku z tym przesłanie prośby o odłączenie to może nie być możliwe.
Po przeniesieniu własności pojazdu niektóre operacje powinny być Dzięki temu poprzedni właściciel nie będzie mógł już przydzielać zadań zdalnym pojazdu. Nowy właściciel może na przykład:
Przywróć do ustawień fabrycznych. Dzięki temu identyfikator klienta zostanie wygenerowany ponownie. Po po wykonaniu tego kroku poprzedni właściciel nadal może wybudzić pojazd, ale nie i dalsze wykonywanie zadań zdalnych.
Otwórz aplikację kliencką zadania zdalnego i postępuj zgodnie z instrukcjami Wyrejestrowywanie klienta w celu odłączenia pojazdu z konta poprzedniego właściciela. Nowy właściciel może śledzić rejestr przez klienta w celu połączenia pojazdu z jego kontem i wymiany powiązane wcześniej konto.
Nowy właściciel może skorzystać z procesu rejestrowania klienta, aby połączyć pojazd ze swoim kontem i zastąpić konto połączone wcześniej.
Przetestuj zdalnego klienta zadań
Udostępniamy referencyjną listę HAL dostępu zdalnego
default
aby przetestować zdalne klienty zadań. Możesz użyć tych elementów (debug)
w celu wstawienia do HAL fałszywego zadania zdalnego, które jest przekazywane do
klienta zadań zdalnych, jeśli podasz prawidłowy identyfikator klienta. Możesz uzyskać
Identyfikator przez zarejestrowanie informacji o rejestracji w zdalnym kliencie zadań
implementacji.
adb root && adb shell dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default --inject-task [clientID] [taskData]