Fernzugriff einrichten

Mit Android 14 wird die neue Fernzugriffsfunktion eingeführt, die es Partnern ermöglicht, Android in einem Fahrzeug aus der Ferne zu aktivieren, um bestimmte Aufgaben auszuführen. Zum Beispiel, um den Garage-Modus über Nacht auszuführen, um Software-Updates 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:

• Arbeitsablauf . Workflow zwischen mehreren Komponenten in der Beispielarchitektur für die Kundenregistrierung und Aufgabenbereitstellung.

• Schreiben Sie einen Remote-Task-Client . Nutzen Sie den Fernzugriff und erfahren Sie, wie Sie einen Remote-Task-Client schreiben.

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

• Zurücksetzen auf Werkseinstellungen und Eigentumsübertragung . Erfahren Sie, wie Sie mit dem Zurücksetzen auf die Werkseinstellungen und der Übertragung des Fahrzeugbesitzes umgehen.

• Testen Sie den Remote-Access-Client . Erfahren Sie, wie Sie die Fernzugriffsfunktion testen.

Die Architektur

Der folgende Inhalt geht davon aus, dass die folgende Beispielarchitektur verwendet wird, die hypothetisch ist und möglicherweise nicht die tatsächliche Architektur widerspiegelt. OEMs sollten eine tatsächliche Implementierung an ihre Fahrzeug- und Serverarchitekturen anpassen.

Abbildung 1. Beispielarchitektur.

Die Beispielarchitektur besteht aus diesen Hardwarekomponenten :

Hardwarekomponente	Beschreibung
App-Prozessor	Prozessor, auf dem Android läuft. Android läuft möglicherweise auf virtuellem Speicher (VM) (nicht auf tatsächlicher Hardware) auf diesem Prozessor.
Fahrzeugprozessor	Prozessor, der für die Steuerung der Leistung des App-Prozessors verantwortlich ist.
Telematik-Steuergerät (TCU)	Der Prozessor im Fahrzeug ist jederzeit in der Lage, Fernnachrichten aus der Cloud zu empfangen. Es wird davon ausgegangen, dass die TCU immer eingeschaltet ist oder sich im Energiesparmodus befindet. Verwenden Sie Remote-Nachrichten, um die TCU zu wecken.
Weckserver	Ein Remote-Server, der in der Cloud läuft und für die Kommunikation mit der TCU im Fahrzeug verantwortlich ist, um Weckbefehle zu erteilen.
Remote-Task-Server	Der Remote-Task-Server läuft in der Cloud, interagiert mit Menschen und verwaltet Remote-Aufgaben.

Die Beispielarchitektur besteht aus den folgenden Softwarekomponenten , die alle auf Android laufen:

On-Android-Softwarekomponente	Beschreibung
Autowerkstatt	AAOS-Framework-Dienst, der Fernzugriffs-APIs bereitstellt.
Remote-Task-Client	Eine vom Anbieter geschriebene Service , die Remote-Aufgaben ausführt. Auf einem Android-System können mehrere Remote-Task-Clients ausgeführt werden.
Fernzugriff HAL	Muss für den Fernzugriff implementiert werden. Abstraktionsschicht für die Kommunikation zwischen AAOS und einer Nicht-Android-Komponente wie der TCU.

Im Folgenden werden Nicht-Android-Softwarekomponenten beschrieben:

Nicht-Android-Softwarekomponente	Beschreibung
Weck-Client	Auf der TCU laufende Software, die eine dauerhafte Verbindung mit dem Weckserver aufrechterhält. Es unterhält außerdem eine Verbindung mit dem Remote Access HAL, um Remote-Aufgaben an den Autoservice zu übermitteln.
Implementierung des Wake-up-Servers	Server, der mit dem auf TCU ausgeführten Weck-Client kommuniziert. Kann Weckanfragen an den Weckclient senden.
Implementierung eines Remote-Task-Servers	Server, der Remote-Aufgaben verwaltet. Benutzer interagieren mit diesem Server, um Remote-Aufgaben auszugeben und zu überwachen.

Arbeitsablauf

In diesem Abschnitt werden die Schritte in einem Beispielworkflow aufgeführt.

Beispiel-Workflow

Ein detaillierter Arbeitsablauf kann wie folgt aussehen:

1. Benutzer parkt Fahrzeug in Garage.

2. Der Partner möchte das Fahrzeug über Nacht aktualisieren, wenn Fahrzeuginteraktionen unwahrscheinlich sind.

3. Der Partner-Cloud-Server sendet eine Remote-Aktualisierungsaufgabe für das System an das Fahrzeug. Konkret die Telematik-Steuereinheit (TCU).

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

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

6. Nach der Anwendung des Updates markiert Android die Aufgabe als abgeschlossen und beendet entweder die Verbindung oder erreicht eine festgelegte Zeitüberschreitung.

Detaillierter Arbeitsablauf

Für den Fernzugriff sind zwei wichtige Schritte erforderlich. Die erste besteht darin, den Client zu registrieren, d. h. einen bestimmten Benutzer mit einem bestimmten Remote-Task-Client zu verknüpfen, der auf einem bestimmten Fahrzeug ausgeführt wird. Die andere Möglichkeit besteht darin, eine Aufgabe zu liefern, die darin besteht, die Remote-Aufgabe für einen bestimmten Benutzer an den spezifischen Remote-Task-Client zu übermitteln, der auf dem bestimmten Fahrzeug ausgeführt wird.

Registrieren Sie einen Kunden

Um die Fernzugriffsfunktion nutzen zu können, muss ein Benutzer die Remote-Aufgaben-Client-App mindestens einmal öffnen und den Client-Registrierungsprozess abschließen ( fetter Text kennzeichnet von AAOS implementierte Aufgaben):

1. Beim Hochfahren erhält der Autoservice Fahrzeuginformationen vom Fernzugriffs-HAL.

2. Beim Hochfahren startet Car Service alle Remote-Task-Clients basierend auf Intent-Filter und Erlaubnis.

3. Beim Start des Remote-Task-Clients registriert sich der Remote-Task-Client beim Car Service.

4. Car Service benachrichtigt den Remote-Task-Client über Registrierungsinformationen, einschließlich Fahrzeug-ID und Kunden-ID. Die Kunden-ID ist eindeutig und wird von Car Service diesem Kunden zugewiesen. Es ist garantiert einzigartig unter allen Remote-Task-Clients im selben Fahrzeug.

5. Der Benutzer meldet sich über den Remote Task Client beim Remote Task Server an und aktiviert die Fernzugriffsfunktion für dieses Fahrzeug. Dieser Schritt umfasst normalerweise die Authentifizierung über den Remote-Task-Server.

6. Der Remote-Task-Client lädt die Benutzerinformationen zusammen mit der Fahrzeug-ID und der Client-ID auf den Remote-Task-Server hoch und fordert ihn auf, den Benutzer mit diesem spezifischen Client und diesem spezifischen Fahrzeug zu verknüpfen.

   Optional kann dieser Schritt eine zusätzliche Zwei-Faktor-Authentifizierung durch den Benutzer beinhalten.

   Der Remote-Task-Server muss authentifizieren, dass die in der Anfrage angegebene Fahrzeug-ID mit der Fahrzeug-ID des Absenders übereinstimmt, was durch Fahrzeugbescheinigung erfolgen kann.

Sofern kein Zurücksetzen auf die Werkseinstellungen erfolgt, ist der Kundenregistrierungsprozess einmal pro Benutzer und Fahrzeug erforderlich. Die Kunden-ID wird lokal im Car Service gespeichert und bleibt für denselben Kunden gleich.

Abbildung 2. Registrieren Sie einen Kunden.

Melden Sie einen Kunden ab

Ein Benutzer kann die Verknüpfung des Fahrzeugs mit seinem Konto entweder vom Fahrzeug oder vom Remote-Task-Server aus aufheben:

• Auf dem Fahrzeug können Benutzer die Remote-Task-Client-App öffnen und eine Aufhebungsanforderung stellen, um die Verknüpfung dieses Fahrzeugs mit seinen zuvor verknüpften Benutzerkonten aufzuheben.

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

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

Liefern Sie Aufgaben

In der Wolke:

1. Ein Benutzer verwendet den Remote-Task-Server, um eine Remote-Aufgabe an ein bestimmtes Fahrzeug zu senden.

2. Der Remote-Task-Server ordnet die Benutzer-ID der Fahrzeug-ID und der Client-ID zu. Es sendet die Auftragsdaten, die Fahrzeug-ID und die Client-ID an den Weckserver.

3. Der Wake-up-Server findet 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.

Auf dem Fahrzeug ( fett gedruckter Text weist auf von AAOS durchgeführte Aufgaben hin):

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

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

3. Car Service erhält Aufgaben von TCU.

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

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

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

6. ( Optional ) Der Remote-Task-Client-Dienst meldet das Task-Ergebnis an den Task-Server.

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

8. Bei Bedarf stellt der Autoservice den Energiezustand des Fahrzeugs wieder her.

Abbildung 3. Aufgaben liefern.

Schreiben Sie einen Remote-Task-Client

CarRemoteAccessManager stellt die API für Fernzugriffsfunktionen bereit. Weitere Informationen finden Sie unter CarRemoteAccessManager . Ein Remote-Task-Client ist ein Android-Dienst, der Remote-Aufgaben ausführt und CarRemoteAccessManager verwendet. Dies erfordert PERMISSION_USE_REMOTE_ACCESS und PERMISSION_CONTROL_REMOTE_ACCESS und muss einen Absichtsfilter für RemoteTaskClientService deklarieren, wie zum Beispiel:

<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-Task-Client sollte sich während der Erstellung beim Car Service 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);
    }
}

Es 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. Car Service trennt sich von diesem Dienst, wenn die Aufgabe abgeschlossen ist. Weitere Informationen finden Sie unter Verwalten des Lebenszyklus eines Dienstes .

Der Remote-Task-Client wird als Systembenutzer ausgeführt und hat daher keinen Zugriff auf benutzerspezifische Daten.

Das folgende Beispiel zeigt, wie mit den registrierten Rückrufen umgegangen wird:

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 Fernzugriffsfunktion ist optional und standardmäßig deaktiviert. Um die Funktion zu aktivieren, fügen Sie ein RRO wie das folgende 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 einen Userdebug/eng-Build:

adb shell cmd car_service enable-feature car_remote_access_service

Anforderungen für Android

Fernzugriff HAL

Die Remote Access Hardware Abstraction Layer (HAL) ist eine vom Hersteller implementierte Abstraktionsschicht für die Kommunikation zwischen AAOS und einem anderen Steuergerät (z. B. einem TCU). Dies ist für die Unterstützung der Fernzugriffsfunktion zwingend erforderlich. Es muss nicht implementiert werden, wenn die Fernzugriffsfunktion nicht implementiert ist.

Die Schnittstelle ist unter IRemoteAccess.aidl definiert und umfasst die folgenden Methoden:

Klasse	Beschreibung
String getVehicleId()	Ruft eine eindeutige Fahrzeug-ID ab, die vom Weckserver erkannt werden kann.
String getWakeupServiceName()	Ruft den Namen für den Remote-Reaktivierungsserver ab.
String getProcessorId()	Ruft eine eindeutige Prozessor-ID ab, die beim Aufwecken des Clients erkannt werden kann.
void setRemoteTaskCallback(IRemoteTaskCallback callback) Legt einen Rückruf fest, der aufgerufen wird, wenn eine Remote-Aufgabe angefordert wird.
void clearRemoteTaskCallback()	Löscht einen zuvor festgelegten Remote-Task-Rückruf.
void notifyApStateChange(in ApState state) Erkennt, ob der App-Prozessor bereit ist, Remote-Aufgaben zu empfangen.

Die Rückrufschnittstelle ist unter IRemoteTaskCallback.aid definiert.

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

Sehen Sie sich die Referenzimplementierung mit einer externen TCU an. Die Implementierung verwendet einen langlebigen Lesestrom zum Empfangen von Remote-Aufgaben und unterstützt den folgenden debug Befehl:

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

Fahrzeug HAL

Um die Fernzugriffsfunktion zu unterstützen, muss VHAL diese Eigenschaften unterstützen:

Klasse	Beschreibung
SHUTDOWN_REQUEST	Fordert das Herunterfahren der Haupteinheit an.
VEHICLE_IN_USE	Erkennt, ob das Fahrzeug im Einsatz ist. Nachdem der Benutzer das Fahrzeug entriegelt hat oder wenn sich der Benutzer dem Fahrzeug nähert. Sollte true sein . Eine bestimmte Dauer, nachdem der Benutzer das Fahrzeug abgestellt hat oder wenn der Benutzer das Fahrzeug verriegelt. Sollte false sein. Bei true versucht AAOS nicht, das Fahrzeug herunterzufahren, wenn die Remote-Aufgabe abgeschlossen ist.

Weitere Informationen finden Sie unter Unterstützte Systemeigenschaften .

Stiller Modus

Für die Fernzugriffsfunktion muss der Silent-Modus unterstützt werden, damit das Fahrzeug im Silent-Modus hochfahren und Remote-Aufgaben ausführen kann, wenn kein Benutzer anwesend ist. Im lautlosen Modus startet das AAOS-Gerät mit ausgeschaltetem Display und ausgeschaltetem Ton.

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

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

Der Fahrzeugprozessor sendet ein HW-Signal an den Android SoC, um den Silent-Modus ein-/auszuschalten. Das Signal (0 oder 1) wird nach /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 Silent-Modus darstellt. AAOS-Module prüfen /sys/kernel/silent_boot/pm_silentmode_kernel_state , um festzustellen, ob sich das System im Silent-Modus befindet oder nicht.

Wenn eine Remote-Aufgabe empfangen wird und AAOS startet, stellt der Fahrzeugprozessor den Silent-Modus ein und startet AAOS, sodass das System mit ausgeschalteter Anzeige/Audio startet.

Nicht-Android-Komponenten im Fahrzeug

Fahrzeugprozessor

Der Fahrzeugprozessor ist ein Prozessor im Fahrzeug, der die Leistung für den App-Prozessor mit Android steuern kann. In der Beispielarchitektur weckt die TCU den App-Prozessor, indem sie ein Signal an den Fahrzeugprozessor sendet.

Nicht-Android-Komponenten im Fahrzeug

Die TCU des Fahrzeugs kann jederzeit Fernnachrichten empfangen.

Der Wake-up-Client läuft auf der TCU, um eine langlebige Verbindung mit dem Remote-Wake-up-Server sicherzustellen.

AAOS, das auf dem AP läuft, kann über die Fernzugriffs-HAL mit dem Weck-Client kommunizieren, der auf der TCU läuft.

Abbildung 4. TCU (Wake-up-Client).

On-Cloud-Komponenten

Weckserver

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

• Sorgen Sie für eine dauerhafte Verbindung mit der TCU des Fahrzeugs.
• Finden Sie eine bestimmte TCU anhand einer Fahrzeug-ID.
• Melden Sie den Status eines Fahrzeugs. Zum Beispiel online oder offline oder letzte Online-Zeit beim Remote-Task-Server.

In 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 Benutzer interagiert mit dem Server, um neue Remote-Aufgaben zu starten und Remote-Aufgaben zu überwachen.

• Verwendet den Remote-Wake-Up-Server, um den App-Prozessor in den Fahrzeugen aufzuwecken.

• Interagiert mit dem Remote-Task-Client, der auf dem Fahrzeug läuft.

• Speichert Kundenregistrierungsinformationen. Dadurch wird ein bestimmter Benutzer einem bestimmten Remote-Aufgaben-Client in einem bestimmten Fahrzeug zugeordnet.

Typischerweise handelt es sich bei den Aufgabendaten , die über den Remote-Task-Server an den Weckserver, an die TCU des Fahrzeugs und schließlich an den Remote-Task-Client gesendet werden, lediglich um eine Aufgaben-ID. Der Remote-Task-Client verwendet die Task-ID, um die detaillierten Informationen vom Remote-Task-Server abzurufen.

Datenschutz- und Sicherheitsanforderungen

Aufgabe	Zustand	Erfordernis
TCU (Wake-up-Client)	MUSS	Authentifizieren Sie den Weckserver. Vertrauen Sie dem Code.
Weckserver	MUSS	Erlauben Sie nur Remote-Task-Servern, die auf der Zulassungsliste stehen, eine Verbindung herzustellen. Authentifizieren Sie den Weckclient. Senden Sie die Wecknachricht nur an das Zielfahrzeug.
Remote-Task-Client	MUSS	Authentifizieren Sie den Benutzer bei der Registrierung. Authentifizieren Sie den Remote-Task-Server. Erfüllen Sie alle Sicherheitsanforderungen für einen Android-Dienst. Zum Beispiel eingeschränkte Berechtigungen.
Remote-Task-Server	MUSS	Der Weckserver muss authentifiziert werden. Fahrzeugbescheinigung vorlegen. Stellen Sie also sicher, dass die in der Anfrage angegebene Fahrzeug-ID mit der Fahrzeug-ID des Absenders übereinstimmt. Wenn eine Fahrzeugbescheinigung nicht möglich ist, muss auf andere Weise überprüft werden, ob der Benutzer derzeit Eigentümer des Fahrzeugs ist. Authentifizieren Sie die Identität des Benutzers. Erfüllen Sie alle Sicherheitsanforderungen für einen Server, der Benutzerinformationen verarbeitet.

Zurücksetzen auf Werkseinstellungen und Eigentumsübertragung

Wenn ein Benutzer einen Werksreset durchführt, wird die im Autoservice gespeicherte Kunden-ID gelöscht. Die Server (Remote-Task-Server und Remote-Wakeup-Server) werden jedoch nicht informiert. Die Server behalten eine Zuordnung der nun abgelaufenen Client-ID zum Fahrzeug bei. Wenn der Benutzer daher eine neue Remote-Aufgabe für das Fahrzeug startet, wird die abgelaufene Client-ID verwendet. Das Fahrzeug wird aufgeweckt, aber der Remote-Task kann nicht ausgeführt werden, da der Remote-Task-Client eine andere Client-ID hat, die nicht übereinstimmt.

Im Folgenden wird eine mögliche Implementierung für einen Werksreset beschrieben.

Wenn ein Benutzer einen Werksreset durchführt, fordert der Anbieter den Benutzer auf, sich beim Remote-Task-Server anzumelden und die Verknüpfung des Fahrzeugs mit seinem Konto aufzuheben, wenn der Benutzer 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 Aufhebungsanforderung zum Zeitpunkt des Zurücksetzens auf die Werkseinstellungen vom Gerät aus zu stellen.

Wenn der Besitz eines Fahrzeugs übertragen wird, sollten einige Vorgänge durchgeführt werden, um sicherzustellen, dass der Vorbesitzer dem Fahrzeug keine Remote-Aufgaben mehr erteilen kann. Der neue Eigentümer kann beispielsweise aufgefordert werden:

• Führen Sie einen Werksreset durch. Dadurch wird sichergestellt, dass die Client-ID neu generiert wird. Nach diesem Schritt kann der Vorbesitzer das Fahrzeug zwar noch aufwecken, aber keine Remote-Aufgaben mehr ausführen.

• Öffnen Sie die Remote-Task-Client-App und folgen Sie dem Prozess „Registrierung eines Clients aufheben“ , um die Verknüpfung des Fahrzeugs mit dem Konto des Vorbesitzers aufzuheben. Der neue Besitzer kann dem Registrierungsprozess eines Kunden folgen, um das Fahrzeug mit seinem Konto zu verknüpfen und das zuvor verknüpfte Konto zu ersetzen.

• Der neue Besitzer kann den Prozess „Kunden registrieren“ verwenden, um das Fahrzeug mit seinem Konto zu verknüpfen und das zuvor verknüpfte Konto zu ersetzen.

Testen Sie den Remote-Task-Client

Wir stellen das Referenz-Remote-Access-HAL- default zum Testen von Remote-Task-Clients 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 erhalten, indem Sie die Registrierungsinformationen in Ihrer Remote-Task-Client-Implementierung protokollieren.

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