Konfigurowanie dostępu zdalnego

Android 14 wprowadza nową funkcję zdalnego dostępu, która umożliwia partnerom zdalne budzenie Androida w pojazdach w celu wykonywania określonych zadań. Na przykład, aby w nocy uruchomić tryb garażu w celu zastosowania aktualizacji oprogramowania. Pełny proces wymaga wielu komponentów innych niż Android. Android nie definiuje ani nie udostępnia implementacji komponentów innych niż Android (to Twoja odpowiedzialność).

Więcej informacji znajdziesz w tych sekcjach:

• Przepływ pracy. Proces pracy między wieloma komponentami w przykładowej architekturze służącej do rejestracji klienta i wykonania zadania.

• Napisać klienta zadań zdalnych. Dowiedz się, jak użyć dostępu zdalnego i jak pisać zdalnego klienta zadań.

• Implementacja przez dostawcę. Komponenty dostawcy w przykładowej architekturze obsługującej dostęp zdalny

• Przywróć ustawienia fabryczne i przenieś własność. Dowiedz się, jak przeprowadzić przywrócenie ustawień fabrycznych i przeniesienie prawa własności pojazdu.

• Przetestuj klienta dostępu zdalnego. Dowiedz się, jak przetestować funkcję zdalnego dostępu.

Architektura

Ten materiał zakłada, że używasz tej przykładowej architektury, która jest hipotetyczna i może nie odzwierciedlać rzeczywistej architektury. Producenci OEM powinni dostosować rzeczywistą implementację do architektury pojazdu i serwera.

Rysunek 1. Przykładowa architektura

Przykładowa architektura składa się z tych komponentów sprzętowych:

Komponent sprzętowy	Opis
Procesor aplikacji	Procesor, na którym działa Android. Android może działać na pamięci wirtualnej (VM) (nie na rzeczywistym sprzęcie) na tym procesorze.
Procesor pojazdu	Procesor odpowiedzialny za kontrolowanie zasilania procesora aplikacji.
Moduł sterujący telematyki (TCU)	Procesor w pojazdzie zawsze może odbierać wiadomości z chmury. Uważa się, że TCU jest zawsze włączone lub w trybie niskiego poboru mocy. Użyj wiadomości zdalnie sterujących, aby wybudzić TCU.
Serwer budzenia	Serwer zdalny działający w chmurze, który odpowiada za komunikację z urządzeniem TCU w samochodzie w celu wydawania poleceń aktywacji.
Serwer zadań zdalnych	Zdalny serwer zadań działa w chmurze i komunikuje się z osobami oraz zarządza zdalnymi zadaniami.

Przykładowa architektura składa się z tych komponentów oprogramowania, 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 działania zdalnego	Zapisana przez dostawcę klasa Service, która wykonuje zadania zdalne. Jeden system Android może uruchamiać wiele klientów zadań zdalnych.
HAL dostępu zdalnego	Musi być wdrożony w celu uzyskania dostępu zdalnego. Warstwa abstrakcyjna służąca do komunikacji między AAOS a komponentem innym niż Android, takim jak TCU.

Poniżej opisujemy komponenty oprogramowania innego niż na Androida:

Komponent oprogramowania innego niż Android	Opis
Wybudzanie klienta	Oprogramowanie działające na TCU, które utrzymuje długotrwałe połączenie z serwerem budzenia. Utrzymuje też połączenie z HAL dostępu zdalnego, aby dostarczać zadania zdalne do usługi samochodowej.
Implementacja serwera budzenia	Serwer, który komunikuje się z klientem aktywacji działającym na TCU. Może: wysyłać do klienta żądania budzenia.
Implementacja zdalnego serwera zadań	Serwer, który zarządza zadaniami zdalnymi. Użytkownicy korzystają z tego serwera, aby wydawać i monitorować zadania zdalne.

Workflow

W tej sekcji znajdziesz listę kroków w przykładowym przepływie pracy.

Przykładowy przepływ pracy

Szczegółowy proces może wyglądać tak:

1. Użytkownik parkuje pojazd w garażu.

2. Partner chce zaktualizować pojazd w nocy, gdy prawdopodobieństwo interakcji z nim jest znikome.

3. Serwer chmury partnera wysyła do pojazdu zdalne zadanie aktualizacji. Dotyczy to w szczególności jednostki sterującej telematycznej (TCU).

4. TCU pojazdu aktywuje elektroniczne sterowanie Androidem (ECU), a usługa OEM uruchamia tryb garażu.

5. Android uruchamia tryb Garaż, aby pobierać i instalować aktualizacje z Google Play.

6. Po zastosowaniu aktualizacji Android oznacza zadanie jako ukończone i kończy połączenie lub osiąga określony limit czasu.

Szczegółowy przepływ pracy

Aby uzyskać dostęp zdalny, musisz wykonać 2 ważne czynności. Pierwszym z nich jest zarejestrowanie klienta, czyli połączenie konkretnego użytkownika z konkretnym klientem zdalnym wykonującym zadania w konkretnym pojeździe. Druga to dostarczenie zadania, czyli przekazanie zdalnego zadania dla konkretnego użytkownika do konkretnego klienta zdalnego zadania działającego w konkretnym pojeździe.

Rejestrowanie klienta

Aby korzystać z funkcji dostępu zdalnego, użytkownik musi otworzyć aplikację klienta zadań zdalnych co najmniej raz i dokończyć proces rejestracji klienta (pogrubiony tekst wskazuje zadania implementowane przez AAOS):

1. Podczas uruchamiania usługa Car Service uzyskuje informacje o samochodzie z urządzenia zdalnego HAL.

2. Podczas uruchamiania usługa Car Service uruchamia wszystkie zdalne klienty zadań oparte na filtrze intencji i uprawnieniach.

3. Po uruchomieniu klienta zadania zdalnego rejestruje się on w usłudze samochodowej.

4. Usługa Car Service wysyła powiadomienie do klienta zdalnego o informacjach rejestracyjnych, w tym o identyfikatorze pojazdu i identyfikatorze klienta. Identyfikator klienta jest unikalny i przypisany do niego przez usługę Car Service. Gwarantuje to, że będzie on unikalny wśród wszystkich klientów zdalnych zadań w tym samym pojeździe.

5. Użytkownik loguje się na serwer zadań zdalnych za pomocą klienta zadań zdalnych i włącza funkcję dostępu zdalnego dla tego pojazdu. Zwykle ten krok obejmuje uwierzytelnianie przez zdalny serwer zadań.

6. Klient zadań zdalnych przesyła informacje o użytkowniku wraz z identyfikatorem pojazdu i identyfikatorem klienta na serwer zadań zdalnych, prosząc o połączenie użytkownika z tym konkretnym klientem i tym konkretnym pojazdem.

   Opcjonalnie ten krok może wymagać dodatkowego uwierzytelniania dwuskładnikowego przez użytkownika.

   Serwer zadań zdalnych musi uwierzytelnić, że identyfikator pojazdu podany w żądaniu jest zgodny z identyfikatorem pojazdu nadawcy. Można to zrobić za pomocą atestacji pojazdu.

O ile nie przywróci to ustawień fabrycznych, proces rejestracji klienta jest wymagany raz na użytkownika i każdy pojazd. Identyfikator klienta jest zapisywany lokalnie w usłudze samochodowej i nie zmienia się dla tego samego klienta.

Rysunek 2. Zarejestruj klienta.

Rejestrowanie klienta

Użytkownik może odłączyć pojazd od swojego konta z poziomu pojazdu lub zdalnego serwera zadań:

• Na pojazdzie użytkownicy mogą otworzyć aplikację klienta zadań zdalnych i wysłać prośbę o odłączenie tego pojazdu od wcześniej połączonych kont użytkowników.

• Na zdalnym serwerze zadań użytkownicy mogą zalogować się na swoje konto i odłączyć od tego konta wcześniej połączony pojazd.

Jeśli użytkownik odłączy pojazd od swojego konta, zdalny serwer zadań musi usunąć zapisane mapowanie tego użytkownika.

Przesyłanie zadań

W chmurze:

1. Użytkownik używa serwera zadań zdalnych do wysyłania zadań zdalnych do konkretnego pojazdu.

2. Serwer zadań zdalnych mapuje identyfikator użytkownika na identyfikator pojazdu i identyfikator klienta. Służy do wysyłania danych zadania, identyfikatora pojazdu i identyfikatora klienta do serwera wybudzania.

3. Serwer budzenia wyszukuje konkretny moduł TCU dla identyfikatora pojazdu (zakładając, że rejestracja modułu TCU została już przeprowadzona) i wysyła dane zadania oraz identyfikator klienta do modułu TCU.

W pojeździe (tekst pogrubiony oznacza czynności wykonywane przez AAOS):

1. TCU otrzymuje zadania zdalne od zdalnego serwera.

2. Jeśli procesor aplikacji (AP) z systemem AAOS jest wyłączony, TCU aktywuje go za pomocą procesora pojazdu (VP).

3. Usługa Car Service odbiera zadania od TCU.

4. Usługa Car Service rozsyła zadania do odpowiedniego klienta zadań zdalnych.

5. Klient działania zdalnego odbiera i wykonuje działanie.

   (Opcjonalnie) klient zdalnego zadania kontaktuje się z serwerem zadań, aby uzyskać więcej informacji o zadaniu, a następnie wykonuje to zadanie.

6. (Opcjonalnie) usługa klienta działania zdalnego przekazuje wynik działania do serwera zadań.

7. Klient zdalnego zadania powiadamia Serwis samochodowy o zakończeniu zadania.

8. W razie potrzeby usługa Car Service przywraca stan zasilania pojazdu.

Rysunek 3. realizować zadania,

Tworzenie klienta zadań zdalnych

CarRemoteAccessManager udostępnia interfejs API na potrzeby funkcji dostępu zdalnego. Więcej informacji znajdziesz na stronie CarRemoteAccessManager. Klient zadań zdalny to usługa na Androida, która wykonuje zadania zdalne i używa CarRemoteAccessManager. Wymaga to atrybutów PERMISSION_USE_REMOTE_ACCESS i PERMISSION_CONTROL_REMOTE_ACCESS oraz zadeklarowania filtra intencji dla RemoteTaskClientService, np.:

<service android:name=".remoteaccess.RemoteTaskClientService"
         android:directBootAware="true"
         android:exported="true">
    <intent-filter>
       <action android:name="android.car.remoteaccess.RemoteTaskClientService" />
    </intent-filter>
</service>

Klient zdalnego zadania powinien zarejestrować się w usłudze Car Service 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 jego cyklem życia. Usługa Car Service łączy się z tą usługą podczas uruchamiania i po otrzymaniu zadania zdalnego. Usługa Car Service odłącza się od tej usługi po zakończeniu zadania. Więcej informacji znajdziesz w artykule Zarządzanie cyklem życia usługi.

Klient zadań zdalnych działa jako użytkownik systemu, więc nie ma dostępu do żadnych danych dotyczących użytkowników.

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ę

Funkcja zdalnego dostępu jest opcjonalna i domyślnie wyłączona. Aby włączyć tę 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 ramach kompilacji userdebug/eng:

adb shell cmd car_service enable-feature car_remote_access_service

Wymagania dotyczące Androida

HAL dostępu zdalnego

Warstwę sprzętową abstrakcji dostępu zdalnego (HAL) implementuje producent. Jest ona warstwą abstrakcji służącą do komunikacji między AAOS a innym ECU (np. TCU). Jest to wymagane, aby obsługiwać funkcję zdalnego dostępu. Nie trzeba go wdrażać, jeśli nie ma funkcji dostępu zdalnego.

Interfejs jest zdefiniowany w pliku IRemoteAccess.aidl i obejmuje te metody:

Kategoria	Opis
String getVehicleId()	Pobiera unikalny identyfikator pojazdu, który może być rozpoznawany przez serwer budzenia.
String getWakeupServiceName()	Pobiera nazwę zdalnego serwera wybudzania.
String getProcessorId()	Pobiera unikalny identyfikator procesora, który można rozpoznać po wybudzeniu klienta.
void setRemoteTaskCallback(IRemoteTaskCallback callback) Ustawia wywołanie zwrotne, które zostanie wywołane po przesłaniu żądania wykonania zadania zdalnego.
void clearRemoteTaskCallback()	Czyści wcześniej ustawiony wywołanie zwrotne działania zdalnego.
void notifyApStateChange(in ApState state) Wykrywanie, czy procesor aplikacji jest gotowy do odbierania zadań zdalnych.

Interfejs wywołania zwrotnego jest zdefiniowany tutaj: 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.

Zapoznaj się z implementacją referencyjną z zewnętrznym modułem TCU. Implementacja używa długotrwałego strumienia odczytu do odbierania zadań zdalnych i obsługuje to polecenie: debug.

dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default

HAL pojazdu

Aby 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	Wykrywanie, czy pojazd jest używany. Po odblokowaniu pojazdu przez użytkownika lub gdy użytkownik zbliża się do pojazdu. Powinno być true. Określony czas po wyłączeniu pojazdu lub zablokowaniu go przez użytkownika. Powinno być false. Gdy true, AAOS nie próbuje wyłączyć pojazdu po wykonaniu zadania zdalnego.

Więcej informacji znajdziesz w artykule Obsługiwane właściwości systemu.

Tryb cichy

Tryb cichy musi być obsługiwany w przypadku funkcji dostępu zdalnego, aby pojazd mógł się uruchamiać w trybie cichym i wykonywać zadania zdalne, gdy nie ma użytkownika. W trybie wyciszenia urządzenie z AAOS uruchamia się z wyłączonym wyświetlaczem i dźwiękiem.

Tryb cichy jest kontrolowany przez 2 pliki sysfs jądra Linuksa.

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, który ustawia nowy tryb cichy.

Procesor pojazdu wysyła sygnał sprzętowy do SoC Androida, aby włączyć lub wyłączyć tryb cichy. Sygnał (0 lub 1) jest zapisywany w /sys/kernel/silent_boot/pm_silentmode_hw_state. Następnie framework AAOS aktualizuje się/sys/kernel/silent_boot/pm_silentmode_kernel_state, aby odzwierciedlać bieżący tryb cichy. Moduły AAOS sprawdzają, /sys/kernel/silent_boot/pm_silentmode_kernel_state aby dowiedzieć się, czy system jest w trybie cichym.

Gdy otrzymane zostanie zadanie zdalne i uruchomi się AAOS, procesor pojazdu ustawi tryb cichy i uruchomi AAOS, aby system uruchomił się z wyłączonym wyświetlaczem i dźwiękiem.

Komponenty w samochodzie inne niż Android

Procesor pojazdu

Procesor pojazdu to procesor w samochodzie, który może kontrolować zasilanie procesora aplikacji z Androidem. W przykładowej architekturze TCU aktywuje procesor aplikacji przez wysłanie sygnału do procesora pojazdu.

Komponenty w samochodzie inne niż Android

TCU pojazdu może zawsze odbierać wiadomości zdalne.

Klient aktywujący działa na TCU, aby zapewnić długotrwałe połączenie z odległym serwerem aktywującym.

System AAOS działający na AP może komunikować się z klientem aktywującym działającym na TCU za pomocą interfejsu HAL dostępu zdalnego.

Rysunek 4. TCU (klient wybudzania).

Komponenty w chmurze

Serwer budzenia

Serwer budzenia komunikuje się z klientem budzenia na TCU, aby:

• Utrzymywanie długotrwałego połączenia z jednostką sterującą pojazdu.
• Znajdź konkretny moduł TCU na podstawie identyfikatora pojazdu.
• zgłaszać stan pojazdu; Na przykład informacje o tym, czy urządzenie jest online czy offline, lub o ostatnim czasie połączenia z serwerem zadań zdalnych.

W rzeczywistej implementacji serwer budzenia może zostać połączony z serwerem zadań zdalnych.

Serwer zadań zdalnych

Serwer zadań zdalnych zarządza tymi zadaniami.

• Użytkownik wchodzi w interakcję z serwerem, aby uruchamiać nowe zadania zdalne i monitorować zadania zdalne.

• Używa serwera zdalnego budzenia do budzenia procesora aplikacji w pojazdach.

• Komunikacja z klientem zadań zdalnych działającym w pojazdach.

• przechowuje informacje o rejestracji klienta; Powiązanie konkretnego użytkownika z konkretnym klientem zdanego zadania w konkretnym pojeździe.

Zwykle dane zadania wysyłane przez serwer zadań zdalnych do serwera budzenia, do TCU pojazdu, a potem do klienta zadań zdalnych to po prostu identyfikator zadania. Klient zdalnego zadania używa identyfikatora zadania do pobierania szczegółowych informacji z serwera zdalnego zadania.

Wymagania dotyczące prywatności i bezpieczeństwa

Zadanie	Warunek	Wymaganie
TCU (klient aktywujący)	MUST	Uwierzytelnij serwer wybudzania. Ufaj kodom.
Serwer budzenia	MUSI	Zezwalaj na połączenia tylko z serwerami zadań zdalnych znajdującymi się na liście dozwolonych. Uwierzytelnij klienta wybudzania. Wysyłaj wiadomość o pobudce tylko do pojazdu docelowego.
Klient zadań zdalnych	MUST	uwierzytelnić użytkownika podczas rejestracji; uwierzytelnianie serwera zadań zdalnych, Spełnić wszystkie wymagania dotyczące zabezpieczeń usługi na Androida. na przykład ograniczone uprawnienia.
Serwer zadań zdalnych	MUST	Musi uwierzytelnić serwer budzenia. Prześlij zaświadczenie o pochodzeniu pojazdu. Oznacza to, że musisz zweryfikować, czy identyfikator pojazdu podany w żądaniu jest zgodny z identyfikatorem pojazdu nadawcy. Jeśli nie można potwierdzić własności pojazdu, należy użyć innych środków, aby zweryfikować, że użytkownik jest jego obecnym właścicielem. uwierzytelnić tożsamość użytkownika; Spełnij wszystkie wymagania dotyczące zabezpieczeń serwera, który obsługuje dane użytkownika.

Przywracanie do ustawień fabrycznych i przenoszenie własności

Jeśli użytkownik przywróci ustawienia fabryczne, identyfikator klienta zapisany w usłudze samochodowej zostanie wyczyszczony. Serwery (serwer zadań zdalnych i serwer budzenia zdalnego) nie są jednak o tym informowane. Serwery zachowują mapowanie do pojazdu z wygasłego identyfikatora klienta. W efekcie, jeśli użytkownik rozpocznie nowe zadanie zdalne dla pojazdu, wykorzysta identyfikator klienta, którego ważność wygasła. Pojazd jest wybudzony, ale zdalne zadanie nie może zostać wykonane, ponieważ klient zdalnego zadania ma inny identyfikator klienta, który nie pasuje.

Poniżej opisujemy jedną z możliwych implementacji przywracania ustawień fabrycznych.

Gdy użytkownik zresetuje urządzenie do ustawień fabrycznych, sprzedawca poprosi go o zalogowanie się na serwerze zadań zdalnych i odłączenie pojazdu od konta, jeśli użytkownik wcześniej połączył pojazd. Nie ma gwarancji, że urządzenie będzie mieć dostęp do sieci podczas przywracania ustawień fabrycznych. Dlatego wysłanie prośby o odłączenie podczas przywracania urządzenia do ustawień fabrycznych może nie być możliwe.

Po przeniesieniu własności pojazdu należy wykonać pewne operacje, aby poprzedni właściciel nie mógł już wykonywać zadań zdalnych. Możemy poprosić nowego właściciela na przykład o:

• Przywróć do ustawień fabrycznych. Dzięki temu identyfikator klienta zostanie wygenerowany ponownie. Po wykonaniu tego kroku poprzedni właściciel nadal może aktywować pojazd, ale nie może już wykonywać zadań zdalnych.

• Otwórz aplikację klienta zadań zdalnych i wykonaj proces rejestracji klienta, aby odłączyć pojazd od konta poprzedniego właściciela. Nowy właściciel może zarejestrować klienta, aby połączyć pojazd z jego kontem i zastąpić wcześniej połączone konto.

• Nowy właściciel może skorzystać z procesu rejestracji klienta, aby połączyć pojazd ze swoim kontem i zastąpić konto połączone wcześniej.

Testowanie klienta zadań zdalnych

Do testowania klientów zadań zdalnych udostępniamy katalog HAL dostępu zdalnegodefault. Aby wstrzyknąć do HAL fałszywe zadanie zdalne, możesz użyć tego polecenia debug. Zadanie to zostanie przekazane do klienta zadań zdalnych, jeśli podasz prawidłowy identyfikator klienta. Identyfikator klienta możesz uzyskać, rejestrując informacje rejestracyjne w implementacji zdalnego klienta zadań.

adb root && adb shell dumpsys android.hardware.automotive.remoteaccess.IRemoteAccess/default --inject-task [clientID] [taskData]