Remote-Zugriff einrichten

In Android 14 wird die neue Funktion für den Remotezugriff eingeführt, mit der Partner Android in einem Fahrzeug per Fernzugriff aktivieren können, um bestimmte Aufgaben auszuführen. So kann beispielsweise der Garagenmodus über Nacht ausgeführt werden, um Softwareupdates anzuwenden. Für den End-to-End-Workflow sind mehrere Nicht-Android-Komponenten erforderlich. Android definiert oder implementiert keine Nicht-Android-Komponenten. Das liegt in Ihrer Verantwortung.

Weitere Informationen finden Sie in den folgenden Abschnitten:

Architektur

Für die folgenden Inhalte wird die folgende Beispielarchitektur verwendet, die hypothetisch ist und möglicherweise nicht der tatsächlichen Architektur entspricht. Erstausrüster sollten eine tatsächliche Implementierung an ihre Fahrzeug- und Serverarchitekturen anpassen.

Bild

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 Speicher (VM) und nicht auf der tatsächlichen Hardware ausgeführt.
Fahrzeugprozessor Prozessor, der für die Steuerung der Stromversorgung des App-Prozessors verantwortlich ist.
Telematik-Steuergerät (TCU) Der Prozessor im Fahrzeug kann immer Remote-Nachrichten aus der Cloud empfangen. Es wird davon ausgegangen, dass die TCU immer eingeschaltet oder im Energiesparmodus ist. Verwenden Sie Remote-Nachrichten, um die TCU zu aktivieren.
Wake-up-Server Ein Remote-Server, der in der Cloud ausgeführt wird und für die Kommunikation mit der TCU im Fahrzeug verantwortlich ist, um Aktivierungsbefehle auszugeben.
Remote-Task-Server Der Server für Remote-Aufgaben wird in der Cloud ausgeführt und interagiert mit Personen und verwaltet Remote-Aufgaben.

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

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

Nicht-Android-Software-Komponenten werden unten beschrieben:

Nicht-Android-Softwarekomponente Beschreibung
Client für das Aufwecken Software, die auf der TCU ausgeführt wird und eine langlebige Verbindung zum Wake-up-Server aufrechterhält. Außerdem wird eine Verbindung zum Remote Access HAL aufrechterhalten, um Remote-Aufgaben an den Car Service zu senden.
Implementierung des Wake-up-Servers Server, der mit dem Wake-up-Client kommuniziert, der auf der TCU ausgeführt wird. Kann Weckanfragen an den Weckclient senden.
Implementierung des Remote-Task-Servers Server, der Remote-Aufgaben verwaltet. Nutzer interagieren mit diesem Server, um Remote-Aufgaben auszuführen und zu überwachen.

Workflow

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

Beispielworkflow

Ein detaillierter Workflow könnte so aussehen:

  1. Der Nutzer parkt das Fahrzeug in der Garage.

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

  3. Der Cloud-Server des Partners sendet eine Remote-Aufgabe für das Aktualisierungssystem an das Fahrzeug. Insbesondere das Telematiksteuergerät.

  4. Die TCU des Fahrzeugs aktiviert das elektronische Steuergerät (ECU) von Android und ein OEM-Dienst löst den Garagenmodus aus.

  5. Unter Android wird der Garagenmodus ausgeführt, um Updates über Google Play herunterzuladen und zu installieren.

  6. Nachdem das Update angewendet wurde, markiert Android die Aufgabe als abgeschlossen und beendet entweder die Verbindung oder erreicht ein angegebenes Zeitlimit.

Detaillierter Workflow

Für den Remotezugriff sind zwei wichtige Schritte erforderlich. Zuerst muss der Client registriert werden. Dabei wird ein bestimmter Nutzer mit einem bestimmten Remote-Task-Client verknüpft, der auf einem bestimmten Fahrzeug ausgeführt wird. Die andere besteht darin, eine Aufgabe zu übermitteln, d. h. die Remote-Aufgabe für einen bestimmten Nutzer an den spezifischen Remote-Aufgabenclient zu übermitteln, der auf dem jeweiligen Fahrzeug ausgeführt wird.

Client registrieren

Damit ein Nutzer die Funktion für den Remotezugriff verwenden kann, muss er die Client-App für Remoteaufgaben mindestens einmal öffnen und die Clientregistrierung abschließen (fett formatierter Text gibt von AAOS implementierte Aufgaben an):

  1. Beim Starten ruft der Car Service Fahrzeuginformationen vom HAL für den Remote-Zugriff ab.

  2. Beim Starten des Fahrzeugs werden alle Remote-Task-Clients basierend auf Intent-Filter und Berechtigung vom Car Service gestartet.

  3. Beim Start des Remote-Aufgabenclients registriert sich dieser beim Car Service.

  4. Car Service benachrichtigt den Remote-Task-Client über Registrierungsinformationen, einschließlich Fahrzeug-ID und Client-ID. Die Client-ID ist eindeutig und wird diesem Client vom Autoservice zugewiesen. Sie ist garantiert eindeutig für alle Remote-Task-Clients im selben Fahrzeug.

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

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

    Optional kann in diesem Schritt eine zusätzliche 2‑Faktor-Authentifizierung durch den Nutzer erforderlich sein.

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

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

Bild

Abbildung 2: Client registrieren.

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 Remote-Aufgaben-Client-App öffnen und eine Anfrage zum Aufheben der Verknüpfung senden, um die Verknüpfung dieses Fahrzeugs mit den zuvor verknüpften Nutzerkonten aufzuheben.

  • Auf dem Remote-Aufgabenserver können sich Nutzer in ihrem Konto anmelden und ein zuvor verknüpftes Fahrzeug aus diesem Konto entfernen.

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 erledigen

In der Cloud:

  1. Ein Nutzer verwendet den Remote-Aufgabenserver, um eine Remote-Aufgabe an ein bestimmtes Fahrzeug zu senden.

  2. Der Remote-Aufgabenserver ordnet die Nutzer-ID der Fahrzeug-ID und der Client-ID zu. Sie sendet die Aufgabendaten, die Fahrzeug-ID und die Client-ID an den Wake-up-Server.

  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.

Auf dem Fahrzeug (fett formatierter Text gibt Aufgaben an, die von AAOS ausgeführt werden):

  1. Die 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 Autoservice empfängt Aufgaben von der TCU.

  4. Der Autoservice verteilt Aufgaben an den entsprechenden Remote-Aufgabenclient.

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

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

  6. Optional: Der Remote-Aufgabenclient meldet das Aufgabenergebnis an den Aufgabenserver.

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

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

Bild

Abbildung 3: Aufgaben erledigen

Remote-Aufgabenclient schreiben

CarRemoteAccessManager bietet die API für Funktionen für den Remotezugriff. Weitere Informationen finden Sie unter CarRemoteAccessManager. Ein Remote-Aufgabenclient 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 bei 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);
    }
}

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 stellt beim Start und beim Eintreffen einer Remote-Aufgabe eine Verbindung zu diesem Dienst her. Car Service wird von diesem Dienst getrennt, wenn die Aufgabe abgeschlossen ist. Weitere Informationen finden Sie unter Lebenszyklus eines Dienstes verwalten.

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

Das folgende Beispiel zeigt, 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 ein RRO wie das folgende hinzu, um das Feature 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 in einem Userdebug-/Eng-Build:

adb shell cmd car_service enable-feature car_remote_access_service

Anforderungen für Android

HAL für den Remote-Zugriff

Die Hardware-Abstraktionsschicht (HAL) für den Remotezugriff ist eine vom Anbieter implementierte Abstraktionsschicht für die Kommunikation zwischen AAOS und einer anderen Steuergeräte (z. B. einem TCU). Sie ist für die Unterstützung der Funktion für den Remotezugriff erforderlich. Sie muss nicht implementiert werden, wenn die Funktion für den Remote-Zugriff nicht implementiert ist.

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

Klasse Beschreibung
String getVehicleId() Ruft eine eindeutige Fahrzeug-ID ab, die vom Wake-up-Server erkannt werden kann.
String getWakeupServiceName() Ruft den Namen für den Remote-Wake-up-Server ab.
String getProcessorId() Ruft eine eindeutige Prozessor-ID ab, die durch Aktivieren des Clients erkannt werden kann.
void setRemoteTaskCallback(IRemoteTaskCallback callback)

Legt einen Callback fest, der aufgerufen wird, wenn eine Remote-Aufgabe angefordert wird.

void clearRemoteTaskCallback() Löscht einen zuvor festgelegten Remote-Aufgaben-Callback.
void notifyApStateChange(in ApState state)

Erkennt, 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 Callback, der aufgerufen wird, wenn eine Remote-Aufgabe angefordert wird.

Referenzimplementierung mit einer externen TCU Bei der Implementierung wird ein Read-Stream mit langer Lebensdauer verwendet, um Remote-Aufgaben zu empfangen. Außerdem wird der folgende debug-Befehl unterstützt:

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

Fahrzeug-HAL

Damit die Funktion für den Remotezugriff unterstützt wird, muss VHAL die folgenden Eigenschaften unterstützen:

Klasse Beschreibung
SHUTDOWN_REQUEST Fordert das Herunterfahren des Infotainmentsystems an.
VEHICLE_IN_USE
  • Erkennt, ob das Fahrzeug in Betrieb ist.
  • Nachdem der Nutzer das Fahrzeug entriegelt hat oder sich dem Fahrzeug nähert. Sollte true sein.
  • Eine bestimmte Zeit nach dem Ausschalten oder Verriegeln des Fahrzeugs durch den Nutzer. Sollte false sein.
  • Wenn true, versucht AAOS nicht, das Fahrzeug herunterzufahren, wenn die Remote-Aufgabe abgeschlossen ist.

Weitere Informationen finden Sie unter Unterstützte Systemeigenschaften.

Lautlos-Modus

Der Silent-Modus muss für die Remotezugriffsfunktion unterstützt werden, damit das Fahrzeug im Silent-Modus hochfahren kann, um Remoteaufgaben auszuführen, wenn kein Nutzer anwesend ist. Im lautlosen Modus wird das AAOS-Gerät mit deaktiviertem Display und deaktivierter Audioausgabe gestartet.

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

Klasse Beschreibung
/sys/kernel/silent_boot/pm_silentmode_kernel_state

Stellt den aktuellen lautlosen Modus dar.

/sys/kernel/silent_boot/pm_silentmode_hw_state

Stellt das Hardwaresignal zum Festlegen eines neuen lautlosen Modus dar.

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

Wenn eine Remote-Aufgabe empfangen wird und AAOS hochfährt, stellt der Fahrzeugprozessor den lautlosen Modus ein und startet AAOS, sodass das System mit deaktiviertem Display und Audio hochfährt.

Nicht auf Android basierende 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 die TCU den App-Prozessor, indem sie ein Signal an den Fahrzeugprozessor sendet.

Nicht auf Android basierende Komponenten im Fahrzeug

Die TCU des Fahrzeugs kann immer Remote-Nachrichten empfangen.

Der Wake-up-Client wird auf der TCU ausgeführt, um eine dauerhafte Verbindung mit dem Remote-Wake-up-Server zu gewährleisten.

AAOS, das auf dem AP ausgeführt wird, kann über das HAL für den Remote-Zugriff mit dem Wake-up-Client kommunizieren, der auf der TCU ausgeführt wird.

Bild

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

Cloud-Komponenten

Wake-up-Server

Der Wake-up-Server kommuniziert mit dem Wake-up-Client auf der TCU, um:

  • Stellen Sie eine langlebige Verbindung zur TCU des Fahrzeugs her.
  • Eine bestimmte TCU anhand einer Fahrzeug-ID finden
  • Den Status eines Fahrzeugs melden. Zum Beispiel online oder offline oder die letzte Onlinezeit des Remote-Aufgabenservers.

In einer tatsächlichen Implementierung kann ein Wake-up-Server 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 Remote-Aufgaben zu überwachen.

  • Verwendet den Remote-Wake-up-Server, um den App-Prozessor in den Fahrzeugen zu aktivieren.

  • Interagiert mit dem Remote-Aufgabenclient, der auf dem Fahrzeug ausgeführt wird.

  • Speichert Informationen zur Clientregistrierung. Dadurch wird ein bestimmter Nutzer einem bestimmten Remote-Task-Client in einem bestimmten Fahrzeug zugeordnet.

In der Regel sind die Aufgabendaten, die über den Remote-Aufgabenserver an den Wake-up-Server, an die TCU des Fahrzeugs und schließlich an den Remote-Aufgabenclient gesendet werden, einfach eine Aufgaben-ID. Der Remote-Aufgabenclient verwendet die Aufgaben-ID, um die detaillierten Informationen vom Remote-Aufgabenserver abzurufen.

Anforderungen an Datenschutz und Sicherheit

Aufgabe Bedingung Anforderung
TCU (Wake-up-Client) MUSS
  • Authentifizieren Sie den Wake-up-Server.
  • Vertrauen Sie dem Code.
Wake-up-Server MUSS
  • Es dürfen nur Remotetaskserver mit einer Zulassungsliste eine Verbindung herstellen.
  • Authentifiziere den Weckclient.
  • Senden Sie die Wecknachricht nur an das Zielfahrzeug.
Client für Remote-Aufgaben MUSS
  • Authentifizieren Sie den Nutzer bei der Registrierung.
  • Authentifizieren Sie den Remote-Aufgabenserver.
  • Alle Sicherheitsanforderungen für einen Android-Dienst sind erfüllt. Beispiel: eingeschränkte Berechtigungen.
Remote-Task-Server MUSS
  • Der Wake-up-Server muss authentifiziert werden.
  • Geben Sie eine Fahrzeugbestätigung an. Das heißt, Sie müssen authentifizieren, dass die im Antrag angegebene Fahrzeug-ID mit der Fahrzeug-ID des Absenders übereinstimmt. Wenn die Fahrzeugbestätigung nicht möglich ist, müssen Sie auf andere Weise bestätigen, dass der Nutzer das Fahrzeug besitzt.
  • Authentifizieren Sie die Identität des Nutzers.
  • Alle Sicherheitsanforderungen für einen Server erfüllen, auf dem Nutzerinformationen verarbeitet werden.

Auf Werkseinstellungen zurücksetzen und Eigentümer übertragen

Wenn ein Nutzer das Gerät auf die Werkseinstellungen zurücksetzt, wird die im Car Service gespeicherte Client-ID gelöscht. Die Server (Remote-Aufgabenserver und Remote-Wake-up-Server) werden jedoch nicht informiert. Die Server behalten eine Zuordnung der 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 aktiviert, 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 das Zurücksetzen auf die Werkseinstellungen beschrieben.

Wenn ein Nutzer das Gerät auf die Werkseinstellungen zurücksetzt, fordert der Anbieter ihn auf, sich auf dem Remote-Task-Server anzumelden und die Verknüpfung des Fahrzeugs mit seinem Konto aufzuheben, falls er das Fahrzeug zuvor verknüpft hat. Es ist nicht garantiert, dass das Gerät während des Zurücksetzens auf die Werkseinstellungen Netzwerkzugriff hat. Daher ist es möglicherweise nicht möglich, die Anfrage zum Aufheben der Verknüpfung beim Zurücksetzen auf die Werkseinstellungen über das Gerät zu senden.

Wenn die Inhaberschaft eines Fahrzeugs übertragen wird, sollten einige Vorgänge ausgeführt werden, um sicherzustellen, dass der Vorbesitzer keine Remote-Aufgaben mehr an das Fahrzeug senden kann. Der neue Inhaber kann beispielsweise aufgefordert werden:

  • Setzen Sie das Gerät auf die Werkseinstellungen zurück. Dadurch wird die Client-ID neu generiert. Nach diesem Schritt kann der bisherige Inhaber das Fahrzeug weiterhin aufwecken, aber keine Remote-Aufgaben mehr ausführen.

  • Öffnen Sie die Remote-Aufgaben-Client-App und folgen Sie der Anleitung unter Client-Registrierung aufheben, um die Verknüpfung des Fahrzeugs mit dem Konto des vorherigen Besitzers aufzuheben. Der neue Eigentümer kann den Registrierungsprozess für einen Client durchlaufen, 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 Referenzverzeichnis für das HAL für den Remotezugriff default zur Verfügung, um Remote-Task-Clients zu testen. Mit dem folgenden debug-Befehl können Sie eine gefälschte Remote-Aufgabe in das HAL einfügen, 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 Implementierung des Remote-Task-Clients protokollieren.

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