Konfigurowanie dostępu zdalnego

Android 14 wprowadza nową funkcję zdalnego dostępu, która umożliwia partnerom zdalne wybudzanie Androida w pojeździe w celu wykonywania określonych zadań. Możesz na przykład włączyć tryb garażowy na noc, aby zastosować aktualizacje oprogramowania. Kompleksowy proces wymaga wielu komponentów innych niż Android. Android nie definiuje ani nie udostępnia implementacji komponentów innych niż Android (odpowiedzialność za to spoczywa na Tobie).

Więcej informacji znajdziesz w tych sekcjach:

• Przepływ pracy. Przepływ pracy między wieloma komponentami w przykładowej architekturze rejestracji klientów i dostarczania zadań.

• Napisz klienta zadań zdalnych. Używaj zdalnego dostępu i dowiedz się, jak napisać klienta zadań zdalnych.

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

• Przywracanie do ustawień fabrycznych i przenoszenie własności Dowiedz się, jak przeprowadzić reset do ustawień fabrycznych i przenieść własność pojazdu.

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

Architektura

Poniższe treści zakładają, że używana jest ta przykładowa architektura, 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:

Przykładowa architektura składa się z tych komponentów oprogramowania, które działają na Androidzie:

Komponenty oprogramowania innego niż Android zostały opisane poniżej:

Przepływ pracy

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

Przykładowy przepływ pracy

Szczegółowy przepływ pracy może wyglądać tak:

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

2. Partner próbuje zaktualizować pojazd w nocy, gdy interakcje z nim są mało prawdopodobne.

3. Serwer chmury partnera wysyła do pojazdu zdalne zadanie aktualizacji systemu. Chodzi o telematyczną jednostkę sterującą (TCU).

4. TCU pojazdu wybudza elektroniczną jednostkę sterującą (ECU) Androida, a usługa OEM wywołuje tryb garażowy.

5. Android uruchamia tryb garażowy, aby pobierać i instalować aktualizacje za pomocą 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

Dostęp zdalny wymaga wykonania 2 ważnych czynności. Pierwszym krokiem jest zarejestrowanie klienta, czyli powiązanie konkretnego użytkownika z konkretnym klientem zdalnych zadań działającym w konkretnym pojeździe. Drugi to dostarczenie zadania, czyli dostarczenie zadania zdalnego dla konkretnego użytkownika do konkretnego klienta zadania zdalnego 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 zakończyć proces rejestracji klienta (pogrubiony tekst oznacza zadania zaimplementowane przez AAOS):

1. Po uruchomieniu usługa samochodowa pobiera informacje o pojeździe z HAL zdalnego dostępu.

2. Po uruchomieniu usługa Car Service uruchamia wszystkich klientów zadań zdalnych na podstawie filtra intencji i uprawnień.

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

4. Usługa samochodowa powiadamia klienta zdalnego zadania o informacjach dotyczących rejestracji, w tym o identyfikatorze pojazdu i identyfikatorze klienta. Identyfikator klienta jest unikalny i przypisywany przez usługę transportu do tego klienta. Gwarantujemy, że będzie on unikalnywśród wszystkich klientów zadań zdalnych w tym samym pojeździe.

5. Użytkownik loguje się na serwerze zadań zdalnych za pomocą klienta zadań zdalnych i włącza funkcję dostępu zdalnego do tego pojazdu. Ten krok zwykle obejmuje uwierzytelnianie za pomocą zdalnego serwera zadań.

6. Klient zadania zdalnego przesyła informacje o użytkowniku wraz z identyfikatorem pojazdu i identyfikatorem klienta na serwer zadania zdalnego 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 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ą atestu pojazdu.

O ile nie nastąpi przywrócenie ustawień fabrycznych, proces rejestracji klienta jest wymagany raz na użytkownika na pojazd. Identyfikator klienta jest przechowywany lokalnie w usłudze samochodowej i pozostaje taki sam dla tego samego klienta.

Rysunek 2. Zarejestruj klienta.

Wyrejestrowywanie klienta

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

• W pojeździe użytkownicy mogą otworzyć aplikację klienta zadań zdalnych i wysłać żądanie odłączenia, aby odłączyć ten pojazd od wcześniej połączonych kont użytkowników.

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

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

Przesyłanie zadań

W chmurze:

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

2. Serwer zadań zdalnych mapuje identyfikator użytkownika na identyfikator pojazdu i identyfikator klienta. Wysyła dane zadania, identyfikator pojazdu i identyfikator klienta do serwera wybudzania.

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

W pojeździe (pogrubiony tekst oznacza zadania wykonywane przez AAOS):

1. TCU odbiera zadania zdalne z serwera zdalnego.

2. Jeśli procesor aplikacji (AP) z AAOS jest wyłączony, TCU używa procesora pojazdu (VP), aby go wybudzić.

3. Usługa Car Service otrzymuje zadania z TCU.

4. Usługa samochodowa rozdziela zadania do odpowiedniego klienta zdalnego zadania.

5. Klient zadania zdalnego otrzymuje i wykonuje zadanie.

   (Opcjonalnie) Klient zadania zdalnego kontaktuje się z serwerem zadania, aby uzyskać więcej szczegółów, i wykonuje zadanie.

6. (Opcjonalnie) Usługa klienta zadania zdalnego zgłasza wynik zadania do serwera zadań.

7. Klient zadania zdalnego powiadamia usługę samochodową o zakończeniu zadania.

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

Rysunek 3. wykonywać zadania,

Pisanie klienta zadań zdalnych

CarRemoteAccessManager udostępnia interfejs API funkcji dostępu zdalnego. Więcej informacji znajdziesz w artykule CarRemoteAccessManager. Klient działania zdalnego to usługa na Androidzie, która wykonuje działania zdalne i korzysta z CarRemoteAccessManager. Wymaga to 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 zadania zdalnego 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 zwracać wartość null.

@Override
public IBinder onBind(Intent intent) {
    return null;
}

Usługa samochodowa zarządza swoim cyklem życia. Usługa Car Service łączy się z tą usługą podczas uruchamiania i gdy nadejdzie zadanie zdalne. Po zakończeniu zadania usługa Car Service przestanie być powiązana z tą usługą. Więcej informacji znajdziesz w artykule Zarządzanie cyklem życia usługi.

Klient zadania zdalnego działa jako użytkownik systemu, 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();
    }
}

Wdrożenie po stronie dostawcy

Funkcja dostępu zdalnego jest opcjonalna i domyślnie wyłączona. Aby włączyć tę funkcję, dodaj RRO, np. taki:

// 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 urządzenia z Androidem

HAL dostępu zdalnego

Warstwa abstrakcji sprzętu zdalnego dostępu (HAL) to zaimplementowana przez dostawcę warstwa abstrakcji do komunikacji między AAOS a innym ECU (np. TCU). Jest to wymagane do obsługi funkcji dostępu zdalnego. Nie musi być wdrażana, jeśli funkcja dostępu zdalnego nie jest wdrożona.

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

Interfejs wywołania zwrotnego jest zdefiniowany w IRemoteTaskCallback.aid.

Zapoznaj się z implementacją referencyjną z zewnętrzną jednostką TCU. Implementacja korzysta z długotrwałego strumienia odczytu do odbierania zadań zdalnych i obsługuje to polecenie debug:

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

Interfejs HAL pojazdu

Aby obsługiwać funkcję zdalnego dostępu, VHAL musi obsługiwać te właściwości:

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

Tryb cichy

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

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

Procesor pojazdu wysyła sygnał sprzętowy do układu 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 aktualizacje platformy AAOS/sys/kernel/silent_boot/pm_silentmode_kernel_stateodpowiednio dostosowują się do/sys/kernel/silent_boot/pm_silentmode_kernel_statebieżącego trybu cichego. Moduły AAOS sprawdzają/sys/kernel/silent_boot/pm_silentmode_kernel_state, czy system jest w trybie cichym.

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

Komponenty w pojeździe inne niż Android

Procesor pojazdu

Procesor pojazdu to procesor w samochodzie, który może sterować zasilaniem procesora aplikacji z Androidem. W przykładowej architekturze moduł TCU wybudza procesor aplikacji, wysyłając sygnał do procesora pojazdu.

Komponenty w pojeździe inne niż Android

TCU w pojeździe zawsze może odbierać wiadomości zdalne.

Klient wybudzania działa na TCU, aby zapewnić długotrwałe połączenie ze zdalnym serwerem wybudzania.

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

Rysunek 4. TCU (klient wybudzania).

Komponenty w chmurze

Serwer wybudzania

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

• utrzymywać długotrwałe połączenie z TCU pojazdu;
• Znajdź konkretny moduł TCU na podstawie identyfikatora pojazdu.
• zgłaszać stan pojazdu, Na przykład online lub offline albo ostatni czas online na serwerze zadań zdalnych.

W rzeczywistym wdrożeniu serwer wybudzania może być połączony z serwerem zadań zdalnych.

Zdalny serwer zadań

Tymi zadaniami zdalnymi zarządza serwer zadań zdalnych.

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

• Wykorzystuje serwer zdalnego wybudzania do wybudzania procesora aplikacji w pojazdach.

• Współpracuje z klientem zadań zdalnych działającym w pojeździe.

• Przechowuje informacje o rejestracji klienta. Powiązuje to konkretnego użytkownika z konkretnym klientem zadania zdalnego w konkretnym pojeździe.

Zazwyczaj dane zadania, które są wysyłane przez zdalny serwer zadań do serwera wybudzania, do modułu TCU pojazdu, a ostatecznie do zdalnego klienta zadań, to po prostu identyfikator zadania. Klient zadania zdalnego używa identyfikatora zadania do pobierania szczegółowych informacji z serwera zadań zdalnych.

Wymagania dotyczące prywatności i bezpieczeństwa

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

Jeśli użytkownik przywróci ustawienia fabryczne, identyfikator klienta przechowywany w usłudze samochodowej zostanie usunięty. Serwery (serwer zadań zdalnych i serwer zdalnego wybudzania) nie są jednak informowane. Serwery zachowują mapowanie wygasłego identyfikatora klienta na pojazd. W rezultacie, jeśli użytkownik rozpocznie nowe zadanie zdalne dla pojazdu, użyje wygasłego identyfikatora klienta. Pojazd jest wybudzany, ale zadanie zdalne nie może zostać wykonane, ponieważ klient zadania zdalnego ma inny identyfikator klienta, który nie pasuje.

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

Gdy użytkownik przywraca ustawienia fabryczne, dostawca prosi go o zalogowanie się na serwerze zadań zdalnych i odłączenie pojazdu od konta, jeśli użytkownik wcześniej połączył pojazd z kontem. Podczas przywracania ustawień fabrycznych urządzenie nie musi mieć dostępu do sieci. Dlatego wysłanie prośby o odłączenie podczas przywracania urządzenia do ustawień fabrycznych może być niemożliwe.

Za każdym razem, gdy własność pojazdu jest przenoszona, należy wykonać pewne czynności, aby poprzedni właściciel nie mógł już wydawać zdalnych poleceń dotyczących pojazdu. Nowy właściciel może być na przykład poproszony o:

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

• Otwórz aplikację kliencką do zadań zdalnych i wykonaj proces wyrejestrowania klienta, aby odłączyć pojazd od konta poprzedniego właściciela. Nowy właściciel może postępować zgodnie z procesem rejestracji klienta, aby połączyć pojazd ze swoim kontem i zastąpić wcześniej połączone konto.

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

Testowanie klienta zadania zdalnego

Aby testować klienty zadań zdalnych, udostępniamy referencyjny katalog HAL dostępu zdalnego default. Aby wstrzyknąć do HAL fałszywe zadanie zdalne, możesz użyć tego debugpolecenia. Jeśli podasz prawidłowy identyfikator klienta, zostanie ono przekazane do klienta zadania zdalnego. Identyfikator klienta możesz uzyskać, rejestrując informacje o rejestracji w implementacji klienta zadań zdalnych.

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