Remotezugriff einrichten

Hinweis: Wenn Sie diese Funktion implementieren möchten, müssen Sie sie aktivieren. Weitere Informationen finden Sie unter Implementierung des Anbieters.

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 und bietet keine Implementierung von Nicht-Android-Komponenten (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 des Anbieters. 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 der Fahrzeugeigentümerschaft

• 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:

Hardwarekomponente	Beschreibung
App-Prozessor	Prozessor, auf dem Android ausgeführt wird. Android wird auf diesem Prozessor möglicherweise im virtuellen Arbeitsspeicher (VM) und nicht auf der tatsächlichen Hardware ausgeführt.
Fahrzeugprozessor	Prozessor, der für die Stromversorgung des App-Prozessors verantwortlich ist.
Telematik-Steuergerät (TCU)	Der Prozessor im Fahrzeug kann jederzeit Remote-Nachrichten aus der Cloud empfangen. Es wird davon ausgegangen, dass die TCU immer eingeschaltet oder im Energiesparmodus ist. Verwenden Sie Remote-Nachrichten, um das TCU zu aktivieren.
Wakeup-Server	Ein Remote-Server, der in der Cloud ausgeführt wird und für die Kommunikation mit der TCU im Fahrzeug verantwortlich ist, um Wake-up-Befehle zu senden.
Remote-Task-Server	Der Remote-Aufgabenserver wird in der Cloud ausgeführt und interagiert mit Personen und verwaltet Remote-Aufgaben.

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

On-Android-Softwarekomponente	Beschreibung
Autodienst	AAOS-Frameworkdienst, der APIs für den Remotezugriff bereitstellt.
Client für Remote-Aufgaben	Eine von einem Anbieter geschriebene Klasse Service, die Remoteaufgaben ausführt. Auf einem Android-System können mehrere Remote-Aufgaben-Clients ausgeführt werden.
HAL für Remotezugriff	Müssen für den Remotezugriff implementiert werden. Abstraktionsschicht für die Kommunikation zwischen AAOS und einer nicht Android-Komponente wie dem TCU.

Komponenten von Nicht-Android-Software werden im Folgenden beschrieben:

Nicht-Android-Softwarekomponente	Beschreibung
Wake-up-Client	Software, die auf dem TCU ausgeführt wird und eine dauerhafte Verbindung mit dem Weckserver aufrechterhält. Außerdem wird eine Verbindung mit dem Remote Access HAL aufrechterhalten, um Remote-Aufgaben an den Autodienst zu senden.
Implementierung des Weckservers	Server, der mit dem auf der TCU ausgeführten Wakeup-Client kommuniziert. Kann Weckaufforderungen an den Weckclient senden.
Implementierung des Remote-Aufgabenservers	Server, der Remoteaufgaben verwaltet. Nutzer interagieren mit diesem Server, um Remote-Aufgaben auszuführen und zu überwachen.

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 nutzt den Garage-Modus, um Updates über Google Play herunterzuladen und zu installieren.

6. Nach dem Anwenden des Updates markiert Android die Aufgabe als abgeschlossen und beendet entweder die Verbindung oder erreicht ein festgelegtes 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 Autodienst 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-Aufgabenclient auf dem Remote-Aufgabenserver 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 2-Faktor-Authentifizierung des Nutzers umfassen.

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

   Hinweis: Ein Nutzer kann mehrere Fahrzeuge haben. Eine Beispieldatenbank auf dem Remote-Aufgabenserver könnte [userID, vehicleID] als Schlüssel und [client ID] als Wert verwenden.

Sofern das Gerät nicht auf die Werkseinstellungen zurückgesetzt wird, ist die Clientregistrierung einmal pro Nutzer und Fahrzeug erforderlich. Die Client-ID wird lokal bei CarService gespeichert und bleibt für denselben Client 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-Task-Server 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-Aufgabenserver die gespeicherte Zuordnung für den jeweiligen Nutzer entfernen.

Aufgaben senden

In der Cloud:

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

2. Der Remote-Aufgabenserver ordnet die Nutzer-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 Wakeup-Server findet die spezifische TCU für die Fahrzeug-ID (vorausgesetzt, die TCU-Registrierung ist bereits abgeschlossen) und sendet die Aufgabendaten und die Client-ID an die TCU.

Am Fahrzeug (fett hervorgehobene Textstellen geben Aufschluss über die von AAOS durchgeführten 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 auf den entsprechenden Remote-Aufgabenclient.

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-Aufgaben-Client 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 die Funktionen für den Remotezugriff bereit. Weitere Informationen finden Sie unter CarRemoteAccessManager. Ein Client für Remote-Aufgaben 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;
}

Car Service verwaltet seinen Lebenszyklus. Car Service bindet sich beim Start und beim Eintreffen einer Remote-Aufgabe an diesen Dienst. 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 zum Aktivieren der Funktion eine RRO wie den folgenden hinzu:

// 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 auf Android-Geräten

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). Dies ist für die Unterstützung der Funktion für den Remotezugriff 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:

Klasse	Beschreibung
String getVehicleId()	Ruft eine eindeutige Fahrzeug-ID ab, die vom Weckserver erkannt werden kann.
String getWakeupServiceName()	Ruft den Namen des Remote-Weckservers ab.
String getProcessorId()	Eine eindeutige Prozessor-ID wird abgerufen, die durch das Aufwecken des Clients erkannt werden kann.
void setRemoteTaskCallback(IRemoteTaskCallback callback) Hiermit wird ein Rückruf festgelegt, der aufgerufen wird, wenn eine Remote-Aufgabe angefordert wird.
void clearRemoteTaskCallback()	Löscht einen zuvor festgelegten Rückruf für Remote-Aufgaben.
void notifyApStateChange(in ApState state) Prüft, ob der App-Prozessor bereit ist, Remote-Aufgaben zu empfangen.

Die Callback-Schnittstelle ist unter IRemoteTaskCallback.aid definiert.

Klasse	Beschreibung
oneway void onRemoteTaskRequested(String clientId, in byte[] data) Ein Rückruf, der aufgerufen wird, wenn eine Remoteaufgabe angefordert wird.

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

Vehicle HAL

Damit die Remotezugriffsfunktion unterstützt wird, muss VHAL die folgenden Eigenschaften unterstützen:

Klasse	Beschreibung
SHUTDOWN_REQUEST	Es wird angefordert, dass das Infotainmentsystem heruntergefahren wird.
VEHICLE_IN_USE	Erkennt, ob das Fahrzeug in Gebrauch ist. Nachdem der Nutzer das Fahrzeug entriegelt hat oder sich dem Fahrzeug nähert. Richtig wäre true. Eine bestimmte Dauer, nachdem der Nutzer das Fahrzeug ausgeschaltet oder verriegelt hat. Sollte false sein. Wenn true, versucht AAOS nicht, das Fahrzeug auszuschalten, wenn die Remote-Aufgabe abgeschlossen ist.

Weitere Informationen finden Sie unter Unterstützte Systemattribute.

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.

Klasse	Beschreibung
/sys/kernel/silent_boot/pm_silentmode_kernel_state Stellt den aktuellen Lautlos-Modus dar.
/sys/kernel/silent_boot/pm_silentmode_hw_state Stellt das Hardwaresignal zum Festlegen eines neuen Lautlosmodus dar.

Der Fahrzeugprozessor sendet ein Hardwaresignal an das Android-SoC, um den Lautlos-Modus zu aktivieren/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 Lautlosmodus ein und startet AAOS so, dass das System mit deaktiviertem Display und Audio gestartet wird.

Android-fremde Komponenten im Fahrzeug

Fahrzeugauftragsverarbeiter

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.

Android-fremde Komponenten im Fahrzeug

Der TCU des Fahrzeugs kann immer Remote-Nachrichten empfangen.

Der Wakeup-Client wird auf der TCU ausgeführt, um eine langlebige Verbindung zum Remote-Wakeup-Server 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

Wakeup-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
• Melden Sie den Status eines Fahrzeugs. 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-Tasks.

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

Datenschutz- und Sicherheitsanforderungen

Wichtig: AAOS verarbeitet keine Aufgabendaten, speichert keine Aufgabendaten, bietet keine Nutzerauthentifizierung und keine Geräteattestierung. Alle Anbieterkomponenten sind für Datenschutz und Sicherheit entscheidend. Für die Beispielarchitektur müssen Anbieter die folgenden Anforderungen erfüllen. Diese Liste ist nicht vollständig.

Aufgabe	Bedingung	Anforderung
TCU (Wake-up-Client)	MUSS	Authentifizieren Sie den Wakeup-Server. Vertrauen Sie dem Code.
Wake-up-Server	MUSS	Nur Remote-Taskserver dürfen eine Verbindung herstellen, die auf der Zulassungsliste stehen. Authentifizieren Sie den Weckclient. Senden Sie die Wecknachricht nur an das Zielfahrzeug.
Client für Remote-Aufgaben	MUSS	Authentifizieren Sie den Nutzer während der Registrierung. Authentifizieren Sie den Remote-Aufgabenserver. Alle Sicherheitsanforderungen für einen Android-Dienst erfüllen. Beispielsweise durch eingeschränkte Berechtigungen.
Remote-Task-Server	MUSS	Der Weckserver muss authentifiziert werden. Reichen Sie eine Fahrzeugattestierung ein. Das bedeutet, dass die in der Anfrage angegebene Fahrzeug-ID mit der Fahrzeug-ID des Absenders übereinstimmen muss. Wenn die Fahrzeugbescheinigung nicht möglich ist, muss auf andere Weise bestätigt werden, dass der Nutzer derzeit Inhaber des Fahrzeugs ist. Authentifizieren Sie die Identität des Nutzers. Alle Sicherheitsanforderungen für einen Server erfüllen, der Nutzerdaten verarbeitet

Auf Werkseinstellungen zurücksetzen und Eigentumsrechte übertragen

Wenn ein Nutzer das Gerät auf die Werkseinstellungen zurücksetzt, wird die im Autodienst gespeicherte Client-ID gelöscht. Die Server (Remote-Aufgabenserver und Remote-Wakeup-Server) 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 das Gerät auf die Werkseinstellungen zurücksetzt, wird er vom Anbieter aufgefordert, sich auf dem Remote-Aufgabenserver anzumelden und die Verknüpfung des Fahrzeugs mit seinem Konto aufzuheben, wenn der Nutzer 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 Eigentumsrechte an einem Fahrzeug übertragen werden, 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 Vorbesitzer das Fahrzeug zwar noch aktivieren, aber keine Remote-Aufgaben mehr 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 Inhaber kann dem Vorgang zum Registrieren eines Kunden folgen, um das Fahrzeug mit seinem Konto zu verknüpfen und das zuvor verknüpfte Konto zu ersetzen.

• Der neue Eigentümer kann das Fahrzeug über den Vorgang Kunden 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]