Konfigurowanie dostępu zdalnego

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Android 14 wprowadza nową funkcję zdalnego dostępu, która umożliwia partnerom zdalne budzenie Androida w samochodzie w celu wykonywania określonych zadań. Na przykład możesz uruchomić tryb garażu na noc, aby zastosować aktualizacje 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. Używaj dostępu zdalnego i dowiedz się, jak napisać klienta zadań zdalnych.

• 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 zresetować ustawienia fabryczne i przenieść własność 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:

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

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

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 partnera w chmurze wysyła do pojazdu zdalne zadanie aktualizacji systemu. Dotyczy to w szczególności jednostki sterującej telematycznej (TCU).

4. TCU pojazdu aktywuje elektroniczny moduł sterujący Androida (ECU), a usługa OEM uruchamia tryb Garaż.

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 jest zarejestrowanie klienta, czyli połączenie konkretnego użytkownika z konkretnym klientem zdalnym działającym 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.

Rejestracja 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 wszystkich klientów zadań zdalnych na podstawie filtra intencji i uprawnień.

3. Po uruchomieniu klienta zadania zdalnego klient rejestruje się w usługi Car Service.

4. Usługa Car Service wysyła do klienta zdalnego zadania informacje o rejestracji, w tym identyfikator pojazdu i identyfikator klienta. Identyfikator klienta jest unikalny i przypisany przez Serwis Samochodowy do tego klienta. 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. Ten krok zwykle wymaga uwierzytelniania na serwerze zadań zdalnych.

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 klientem i tym konkretnym pojazdem.

   Opcjonalnie ten krok może obejmować dodatkowe uwierzytelnianie dwuskładnikowe 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.

Jeśli nie nastąpi przywrócenie ustawień fabrycznych, wymagany jest proces rejestracji klienta. Identyfikator klienta jest przechowywany lokalnie w usłudze Car Service i pozostaje taki sam dla tego samego klienta.

Rysunek 2. Rejestrowanie klienta.

Rejestrowanie i wyrejestrowywanie klienta

Użytkownik może odłączyć pojazd od konta, korzystając z pojazdu lub serwera zadań zdalnych:

• 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 niego wcześniej połączony pojazd.

Jeśli użytkownik odłączy pojazd od swojego konta, serwer zadań zdalnych musi usunąć przechowywane mapowanie dla konkretnego 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. Wysyła dane zadania, identyfikator pojazdu i identyfikator klienta do serwera budzenia.

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 pojazdach (tekst pogrubiony oznacza czynności wykonywane przez AAOS):

1. TCU otrzymuje zadania zdalne z serwera zdalnego.

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

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 do funkcji dostępu zdalnego. Więcej informacji znajdziesz w CarRemoteAccessManager. Klient działań zdalnych to usługa na Androida, która wykonuje działania zdalne i korzysta z funkcji CarRemoteAccessManager. Wymaga to PERMISSION_USE_REMOTE_ACCESS i PERMISSION_CONTROL_REMOTE_ACCESS oraz deklaracji 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 zwracać null.

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

Usługa Car Service zarządza swoim 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.

Ten 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 musisz go implementować, jeśli funkcja dostępu zdalnego nie jest implementowana.

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

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

Zobacz 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

Interfejs HAL pojazdu

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

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 w nim użytkownika. W trybie wyciszenia urządzenie AAOS uruchamia się z wyłączonym wyświetlaczem i dźwiękiem.

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

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 odpowiednio do bieżącego trybu cichego. 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 pobudki).

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.
• Znajdowanie konkretnego 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 rozpocząć 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 zdalnego 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 zabezpieczeń

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

Jeśli użytkownik przywróci ustawienia fabryczne, identyfikator klienta zapisany w usłudze Car Service zostanie usunięty. Serwery (serwer zadań zdalnych i serwer budzenia zdalnego) nie są jednak o tym informowane. Serwery zachowują mapowanie identyfikatora klienta, którego ważność wygasła, na pojazd. 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.

Gdy własność pojazdu zostanie przeniesiona, należy wykonać kilka operacji, aby poprzedni właściciel nie mógł już wydawać zdalnych poleceń pojazdowi. 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ń z dalsza.

• 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 użyć procesu Rejestracja klienta, aby połączyć pojazd ze swoim kontem i zastąpić wcześniej połączone konto.

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. Zostanie ono przekazane do klienta zadań zdalnych, jeśli podasz prawidłowy identyfikator klienta. 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]