Remote-Zugriff einrichten

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Mit Android 14 wird die neue Funktion für den Remotezugriff eingeführt, mit der Partner Android in einem Fahrzeug aus der Ferne aktivieren können, um bestimmte Aufgaben auszuführen. So können Sie beispielsweise den Garage-Modus über Nacht ausführen, um Softwareupdates anzuwenden. Für den End-to-End-Workflow sind mehrere nicht-Android-Komponenten erforderlich. Android definiert oder stellt keine Implementierung für nicht-Android-Komponenten bereit. Diese Verantwortung liegt bei Ihnen.

Weitere Informationen finden Sie in den folgenden Abschnitten:

• Workflow Workflow zwischen mehreren Komponenten in der Beispielarchitektur für die Kundenregistrierung und Aufgabenausführung

• Einen Remote-Aufgabenclient schreiben Informationen zum Verwenden des Remotezugriffs und zum Erstellen eines Remote-Aufgabenclients.

• Implementierung durch den Anbieter Anbieterkomponenten in der Beispielarchitektur zur Unterstützung des Remotezugriffs

• Zurücksetzen auf die Werkseinstellungen und Übertragung der Eigentumsrechte Informationen zum Zurücksetzen auf die Werkseinstellungen und zum Übertragen des Fahrzeugeigentums

• Testen Sie den Remotezugriffsclient. Informationen zum Testen der Funktion für den Remotezugriff

Architektur

Im folgenden Text wird davon ausgegangen, dass die folgende Beispielarchitektur verwendet wird. Diese ist hypothetisch und entspricht möglicherweise nicht der tatsächlichen Architektur. OEMs sollten eine tatsächliche Implementierung an ihre Fahrzeug- und Serverarchitekturen anpassen.

Abbildung 1: Beispielarchitektur

Die Beispielarchitektur besteht aus den folgenden Hardwarekomponenten:

Die Beispielarchitektur besteht aus den folgenden Softwarekomponenten, die alle auf Android ausgeführt werden:

Im Folgenden werden Nicht-Android-Softwarekomponenten beschrieben:

Workflow

In diesem Abschnitt sind die Schritte eines Beispiel-Workflows aufgeführt.

Beispiel-Workflow

Ein detaillierter Workflow könnte so aussehen:

1. Der Nutzer parkt sein Fahrzeug in der Garage.

2. Der Partner versucht, das Fahrzeug über Nacht zu aktualisieren, wenn Interaktionen mit dem Fahrzeug unwahrscheinlich sind.

3. Der Cloud-Server des Partners sendet eine Remote-Aufgabe zum Aktualisieren des Systems an das Fahrzeug. Insbesondere die Telematik-Kontrolleinheit (TCU).

4. Die TCU des Fahrzeugs weckt die Android-Elektronische-Steuereinheit (ECU) auf und ein OEM-Dienst löst den Garagenmodus aus.

5. Android verwendet den Garage-Modus, um Updates über Google Play herunterzuladen und zu installieren.

6. Nach der Aktualisierung markiert Android die Aufgabe als abgeschlossen und beendet entweder die Verbindung oder erreicht ein bestimmtes Zeitlimit.

Detaillierter Workflow

Für den Remotezugriff sind zwei wichtige Schritte erforderlich. Der erste Schritt besteht darin, den Client zu registrieren, d. h. einen bestimmten Nutzer mit einem bestimmten Remote-Task-Client zu verknüpfen, der auf einem bestimmten Fahrzeug ausgeführt wird. Die andere ist die Übermittlung einer Aufgabe, d. h. die Übermittlung der Remote-Aufgabe für einen bestimmten Nutzer an den Remote-Aufgaben-Client, der auf dem jeweiligen Fahrzeug ausgeführt wird.

Client registrieren

Wenn ein Nutzer die Funktion für den Remotezugriff verwenden möchte, muss er die Client-App für Remoteaufgaben mindestens einmal öffnen und die Clientregistrierung abschließen. Fett gedruckter Text gibt Aufgaben an, die von AAOS implementiert wurden:

1. Beim Starten erhält der Dienst „Car Service“ Fahrzeuginformationen vom HAL für den Remotezugriff.

2. Beim Starten startet der Autodienst alle Remote-Aufgaben-Clients basierend auf Intent-Filter und Berechtigung.

3. Beim Starten des Remote-Aufgabenclients registriert er sich beim Car-Dienst.

4. Der Autoservice benachrichtigt den Remote-Task-Client über Registrierungsinformationen, einschließlich Fahrzeug-ID und Kunden-ID. Die Kunden-ID ist eindeutig und wird diesem Kunden vom Autoservice zugewiesen. Er ist garantiert eindeutig unter allen Remote-Task-Clients im selben Fahrzeug.

5. Der Nutzer meldet sich über den Remote-Task-Client beim Remote-Task-Server an und aktiviert die Funktion für den Remotezugriff für dieses Fahrzeug. Dieser Schritt umfasst in der Regel die Authentifizierung über den Remote-Aufgabenserver.

6. Der Remote-Task-Client lädt die Informationen des Nutzers zusammen mit der Fahrzeug-ID und der Kunden-ID auf den Remote-Task-Server hoch und bittet ihn, den Nutzer mit diesem bestimmten Kunden und diesem bestimmten Fahrzeug zu verknüpfen.

   Optional kann dieser Schritt eine zusätzliche Bestätigung in zwei Schritten durch den Nutzer erfordern.

   Der Remote-Aufgabenserver muss authentifizieren, dass die in der Anfrage angegebene Fahrzeug-ID mit der Fahrzeug-ID des Absenders übereinstimmt. Dies kann durch eine Fahrzeugattestierung erfolgen.

Sofern kein Zurücksetzen auf die Werkseinstellungen erfolgt, ist die Registrierung des Kunden einmal pro Nutzer und Fahrzeug erforderlich. Die Kunden-ID wird lokal im Autoservice gespeichert und bleibt für denselben Kunden gleich.

Abbildung 2: Registrieren Sie einen Client.

Client abmelden

Ein Nutzer kann die Verknüpfung des Fahrzeugs mit seinem Konto entweder über das Fahrzeug oder über den Remote-Aufgabenserver aufheben:

• Im Fahrzeug können Nutzer die Client-App für Remote-Aufgaben öffnen und eine Aufhebung der Verknüpfung beantragen, um die Verknüpfung dieses Fahrzeugs mit den zuvor verknüpften Nutzerkonten aufzuheben.

• Auf dem Remote-Task-Server können sich Nutzer in ihrem Konto anmelden und die Verknüpfung eines zuvor verknüpften Fahrzeugs mit diesem Konto aufheben.

Wenn der Nutzer die Verknüpfung des Fahrzeugs mit seinem Konto aufhebt, muss der Remote-Task-Server die gespeicherte Zuordnung für den jeweiligen Nutzer entfernen.

Aufgaben ausführen

In der Cloud:

1. Ein Nutzer sendet über den Remote-Aufgabenserver eine Remote-Aufgabe an ein bestimmtes Fahrzeug.

2. Der Remote-Aufgabenserver ordnet die User-ID der Fahrzeug-ID und der Client-ID zu. Er sendet die Aufgabendaten, die Fahrzeug-ID und die Kunden-ID an den Weckserver.

3. Der Wake-up-Server sucht die spezifische TCU für die Fahrzeug-ID (vorausgesetzt, die TCU-Registrierung ist bereits erfolgt) und sendet die Aufgabendaten und die Client-ID an die TCU.

Am Fahrzeug (fett hervorgehobene Textstellen geben Aufschluss über von AAOS durchgeführte Aufgaben):

1. TCU empfängt Remote-Aufgaben vom Remote-Server.

2. Wenn der App-Prozessor (AP), auf dem AAOS ausgeführt wird, ausgeschaltet ist, verwendet die TCU den Fahrzeugprozessor (VP), um den AP zu aktivieren.

3. Der Dienst „Car Service“ empfängt Aufgaben von der TCU.

4. Car Service verteilt Aufgaben an den entsprechenden Remote-Task-Client.

5. Der Remote-Task-Client empfängt und führt die Aufgabe aus.

   (Optional) Der Remote-Aufgabenclient kontaktiert den Aufgabenserver, um weitere Aufgabendetails zu erhalten, und führt die Aufgabe aus.

6. (Optional) Der Remote-Aufgabenclientdienst meldet das Aufgabenergebnis an den Aufgabenserver.

7. Der Remote-Aufgabenclient benachrichtigt den Autoservice, wenn die Aufgabe abgeschlossen ist.

8. Bei Bedarf stellt der Autodienst den Betriebszustand des Fahrzeugs wieder her.

Abbildung 3: Aufgaben erledigen

Remote-Aufgabenclient schreiben

CarRemoteAccessManager stellt die API für Funktionen für den Remotezugriff bereit. Weitere Informationen finden Sie unter CarRemoteAccessManager. Ein Remote-Task-Client ist ein Android-Dienst, der Remote-Aufgaben ausführt und CarRemoteAccessManager verwendet. Dazu sind PERMISSION_USE_REMOTE_ACCESS und PERMISSION_CONTROL_REMOTE_ACCESS erforderlich. Außerdem muss ein Intent-Filter für RemoteTaskClientService deklariert werden, z. B.:

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

Ein Remote-Aufgabenclient sollte sich beim Erstellen beim Autodienst registrieren:

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);
    }
}

Sie muss die onBind-Funktion überschreiben, um „null“ zurückzugeben.

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

Der Lebenszyklus wird von Car Service verwaltet. Der Dienst „Car Service“ wird beim Starten und bei der Ausführung einer Remote-Aufgabe mit diesem Dienst verknüpft. Der Dienst „Car Service“ wird von diesem Dienst getrennt, wenn die Aufgabe abgeschlossen ist. Weitere Informationen finden Sie unter Lebenszyklus eines Dienstes verwalten.

Der Remote-Aufgaben-Client wird als Systemnutzer ausgeführt und hat daher keinen Zugriff auf nutzerspezifische Daten.

Im folgenden Beispiel wird gezeigt, wie die registrierten Callbacks verarbeitet werden:

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();
    }
}

Implementierung durch den Anbieter

Die Funktion für den Remotezugriff ist optional und standardmäßig deaktiviert. Fügen Sie eine RRO wie die folgende hinzu, um die Funktion zu aktivieren:

// 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
}

Oder verwenden Sie den folgenden adb-Befehl für ein userdebug/eng-Build:

adb shell cmd car_service enable-feature car_remote_access_service

Anforderungen unter Android

HAL für Remotezugriff

Die Remote Access Hardware Abstraction Layer (HAL) ist eine vom Anbieter implementierte Abstraktionsschicht für die Kommunikation zwischen AAOS und einer anderen ECU (z. B. einer TCU). Er ist für die Unterstützung der Remotezugriffsfunktion erforderlich. Sie muss nicht implementiert werden, wenn die Remote-Zugriffsfunktion nicht implementiert ist.

Die Schnittstelle ist in IRemoteAccess.aidl definiert und enthält die folgenden Methoden:

Die Callback-Schnittstelle ist unter IRemoteTaskCallback.aid definiert.

Referenzimplementierung mit externer TCU ansehen Die Implementierung verwendet einen Long-Live-Lesestream, um Remote-Aufgaben zu empfangen, und unterstützt den folgenden debug-Befehl:

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

Fahrzeug-HAL

Damit die Funktion „Remotezugriff“ unterstützt wird, muss VHAL die folgenden Eigenschaften unterstützen:

Weitere Informationen finden Sie unter Unterstützte Systemeigenschaften.

Lautlos-Modus

Der Modus „Lautlos“ muss für die Funktion „Remotezugriff“ unterstützt werden, damit das Fahrzeug im Modus „Lautlos“ gestartet werden kann, um Remote-Aufgaben auszuführen, wenn kein Nutzer anwesend ist. Im Lautlosmodus wird das AAOS-Gerät mit deaktiviertem Display und Audio gestartet.

Der Silent-Modus wird über zwei sysfs-Dateien des Linux-Kernels gesteuert.

Der Fahrzeugprozessor sendet ein Hardwaresignal an das Android-SoC, um den Lautlosmodus zu aktivieren oder zu deaktivieren. Das Signal (0 oder 1) wird in /sys/kernel/silent_boot/pm_silentmode_hw_state geschrieben. Anschließend aktualisiert das AAOS-Framework /sys/kernel/silent_boot/pm_silentmode_kernel_state entsprechend, was den aktuellen Lautlosmodus darstellt. AAOS-Module prüfen /sys/kernel/silent_boot/pm_silentmode_kernel_state, um festzustellen, ob sich das System im Lautlosmodus befindet.

Wenn eine Remote-Aufgabe empfangen und AAOS gestartet wird, stellt der Fahrzeugprozessor den Silent-Modus ein und startet AAOS so, dass das System mit deaktiviertem Display und Audio gestartet wird.

Nicht Android-Komponenten im Fahrzeug

Fahrzeugprozessor

Der Fahrzeugprozessor ist ein Prozessor im Fahrzeug, der die Stromversorgung für den App-Prozessor mit Android steuern kann. In der Beispielarchitektur weckt das TCU den App-Prozessor durch Senden eines Signals an den Fahrzeugprozessor auf.

Nicht Android-Komponenten im Fahrzeug

Die TCU des Fahrzeugs kann jederzeit Remote-Nachrichten empfangen.

Der Weckclient wird auf dem TCU ausgeführt, um eine langlebige Verbindung mit dem Remote-Weckserver zu gewährleisten.

AAOS, das auf dem ZP ausgeführt wird, kann über die HAL für Remotezugriff mit dem Weckclient kommunizieren, der auf der TCU ausgeführt wird.

Abbildung 4: TCU (Wake-up-Client)

Cloud-Komponenten

Wake-up-Server

Der Weckserver kommuniziert mit dem Weckclient auf der TCU, um:

• Eine dauerhafte Verbindung mit der TCU des Fahrzeugs aufrechterhalten.
• Eine bestimmte TCU anhand einer Fahrzeug-ID finden
• Status eines Fahrzeugs melden Beispielsweise „online“ oder „offline“ oder die letzte Onlinezeit beim Remote-Aufgabenserver.

Bei einer tatsächlichen Implementierung kann ein Weckserver mit einem Remote-Task-Server zusammengeführt werden.

Remote-Task-Server

Der Remote-Task-Server verwaltet diese Remote-Aufgaben.

• Der Nutzer interagiert mit dem Server, um neue Remote-Aufgaben zu starten und zu überwachen.

• Verwendet den Remote-Weckserver, um den App-Prozessor in den Fahrzeugen zu aktivieren.

• Interagiert mit dem Remote-Aufgaben-Client, der im Fahrzeug ausgeführt wird.

• Hier werden Informationen zur Registrierung des Kunden gespeichert. Dadurch wird ein bestimmter Nutzer einem bestimmten Remote-Aufgaben-Client in einem bestimmten Fahrzeug zugeordnet.

Normalerweise sind die Aufgabendaten, die über den Remote-Aufgabenserver an den Weckserver, die TCU des Fahrzeugs und schließlich an den Remote-Aufgabenclient gesendet werden, einfach eine Aufgaben-ID. Der Remote-Task-Client verwendet die Aufgaben-ID, um die detaillierten Informationen vom Remote-Task-Server abzurufen.

Anforderungen an den Datenschutz und die Sicherheit

Auf Werkseinstellungen zurücksetzen und Eigentumsrechte übertragen

Wenn ein Nutzer ein Gerät auf die Werkseinstellungen zurücksetzt, wird die im Autodienst gespeicherte Client-ID gelöscht. Die Server (Remote-Aufgabenserver und Remote-Weckserver) werden jedoch nicht informiert. Die Server behalten eine Zuordnung der jetzt abgelaufenen Client-ID zum Fahrzeug bei. Wenn der Nutzer also eine neue Remote-Aufgabe für das Fahrzeug startet, wird die abgelaufene Client-ID verwendet. Das Fahrzeug wird geweckt, aber die Remote-Aufgabe kann nicht ausgeführt werden, da der Remote-Aufgaben-Client eine andere Client-ID hat, die nicht übereinstimmt.

Im Folgenden wird eine mögliche Implementierung für die Wiederherstellung der Werkseinstellungen beschrieben.

Wenn ein Nutzer einen Werksreset ausführt, wird er vom Anbieter aufgefordert, sich beim Remote-Task-Server anzumelden und die Verknüpfung des Fahrzeugs mit seinem Konto aufzuheben, falls er das Fahrzeug zuvor verknüpft hat. Es kann nicht garantiert werden, dass das Gerät während des Zurücksetzens auf die Werkseinstellungen Netzwerkzugriff hat. Daher ist es möglicherweise nicht möglich, die Aufhebung der Verknüpfung zum Zeitpunkt des Zurücksetzens auf die Werkseinstellungen über das Gerät zu beantragen.

Wenn die Inhaberschaft eines Fahrzeugs übertragen wird, sollten einige Vorkehrungen getroffen werden, damit der bisherige Eigentümer dem Fahrzeug keine Aufgaben mehr per Fernzugriff zuweisen kann. Der neue Inhaber wird beispielsweise möglicherweise aufgefordert,

• Setzen Sie das Gerät auf die Werkseinstellungen zurück. Dadurch wird sichergestellt, dass die Client-ID neu generiert wird. Nach diesem Schritt kann der bisherige Eigentümer das Fahrzeug zwar noch aufwecken, aber keine Aufgaben mehr aus der Ferne ausführen.

• Öffne die Remote-Aufgaben-Client-App und folge dem Verfahren zur Deaktivierung eines Clients, um die Verknüpfung des Fahrzeugs mit dem Konto des Vorbesitzers aufzuheben. Der neue Eigentümer kann das Fahrzeug mit seinem Konto verknüpfen und das zuvor verknüpfte Konto ersetzen.

• Der neue Eigentümer kann das Fahrzeug über den Vorgang Nutzer registrieren mit seinem Konto verknüpfen und das zuvor verknüpfte Konto ersetzen.

Remote-Aufgabenclient testen

Wir stellen das HAL-Verzeichnis für den Remotezugriff default zum Testen von Remote-Aufgabenclients bereit. Mit dem folgenden debug-Befehl können Sie eine gefälschte Remote-Aufgabe in die HAL einschleusen, die an Ihren Remote-Aufgaben-Client weitergeleitet wird, wenn Sie die richtige Client-ID angeben. Sie können die Client-ID abrufen, indem Sie die Registrierungsinformationen in Ihrer Remote-Task-Clientimplementierung protokollieren.

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