Skonfiguruj dostęp zdalny

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:

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.

image

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:

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

  2. Partner stara się aktualizować pojazd z dnia na dzień, gdy interakcje z pojazdem są mało prawdopodobne.

  3. Serwer w chmurze partnera wysyła zdalne zadanie aktualizacji systemu do pojazdu. W szczególności telematyczna jednostka sterująca (TCU).

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

  5. Android działa w trybie garażu, aby pobierać i instalować aktualizacje za pośrednictwem Google Play.

  6. 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):

  1. Po uruchomieniu Car Service pobiera informacje o pojeździe ze zdalnego dostępu HAL.

  2. Podczas uruchamiania Car Service uruchamia wszystkich klientów zadań zdalnych w oparciu o filtr intencji i uprawnienia.

  3. Po uruchomieniu klienta zadań zdalnych, klient zadań zdalnych rejestruje się w serwisie samochodowym.

  4. 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.

  5. 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ń.

  6. 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.

image

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:

  1. Użytkownik korzysta ze zdalnego serwera zadań, aby wysłać zdalne zadanie do określonego pojazdu.

  2. 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.

  3. 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):

  1. TCU odbiera zdalne zadania ze zdalnego serwera.

  2. Jeśli procesor aplikacji (AP) z systemem AAOS jest wyłączony, TCU używa procesora pojazdu (VP) do wybudzenia punktu dostępowego.

  3. Car Service otrzymuje zadania od TCU.

  4. Car Service przydziela zadania odpowiedniemu klientowi zadań zdalnych.

  5. 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.

  6. ( Opcjonalnie ) Usługa klienta zadań zdalnych raportuje wyniki zadania do serwera zadań.

  7. Zdalny klient zadania powiadamia serwis samochodowy o zakończeniu zadania.

  8. W razie potrzeby Serwis Samochodowy przywraca stan zasilania pojazdu.

image

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
  • Wykrywa, czy pojazd jest używany.
  • Po odblokowaniu pojazdu przez użytkownika lub zbliżeniu się do pojazdu. Powinno być true .
  • Określony czas po wyłączeniu pojazdu przez użytkownika lub zablokowaniu pojazdu. Powinno być false .
  • Jeśli ma true , system AAOS nie podejmuje próby wyłączenia pojazdu po zakończeniu zadania zdalnego.

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.

image

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Ć
  • Uwierzytelnij serwer wznawiania.
  • Zaufaj kodowi.
Serwer budzenia MUSIEĆ
  • Zezwalaj na łączenie się tylko zdalnym serwerom zadań znajdującym się na liście dozwolonych.
  • Uwierzytelnij klienta wznawiania.
  • Wyślij wiadomość alarmową tylko do pojazdu docelowego.
Klient zadań zdalnych MUSIEĆ
  • Uwierzytelnij użytkownika podczas rejestracji.
  • Uwierzytelnij zdalny serwer zadań.
  • Spełnij wszystkie wymagania bezpieczeństwa usługi Android. Na przykład ograniczone uprawnienia.
Zdalny serwer zadań MUSIEĆ
  • Należy uwierzytelnić serwer wznawiania.
  • Dostarcz świadectwo pojazdu. Oznacza to, że należy sprawdzić, czy identyfikator pojazdu podany w żądaniu odpowiada identyfikatorowi pojazdu nadawcy. Jeśli zaświadczenie pojazdu nie jest możliwe, należy skorzystać z innych środków, aby sprawdzić, czy użytkownik jest obecnie właścicielem pojazdu.
  • Uwierzytelnij tożsamość użytkownika.
  • Spełnia wszystkie wymagania bezpieczeństwa stawiane serwerowi obsługującemu informacje o użytkownikach.

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]