Mit der Geräteverwaltung können Sie ein Fahrzeug mit Android Automotive OS (AAOS) aus der Ferne verwalten. Beispielsweise kann es sein, dass ein Fahrzeugbesitzer das Infotainmentgerät aus der Ferne auf die Werkseinstellungen zurücksetzen möchte.
Im Bereich Automotive bieten wir zwei Kategorien der Geräteverwaltung an:
- Eigenes Gerät: Ein Fahrzeug ist im Besitz eines Verbrauchers. Das Fahrzeug wird vom Eigentümer des Fahrzeugs aus der Ferne verwaltet. Beispielsweise kann der Eigentümer die Infotainmenteinheit über die mobile App des Fahrzeugs per Fernzugriff auf die Werkseinstellungen zurücksetzen.
- Unternehmensgerät: Ein Fahrzeug gehört einem Unternehmen oder einer Organisation. Ein Administrator verwaltet das Auto per Fernzugriff.
Private Geräte
In einem Szenario mit einem privaten Gerät muss bei der Remote-Verwaltung des Fahrzeugs der Fahrzustand des Autos berücksichtigt werden. Wenn der Eigentümer des Fahrzeugs beispielsweise aus der Ferne ein Zurücksetzen auf die Werkseinstellungen auslöst, sollte das Fahrzeug nicht auf die Werkseinstellungen zurückgesetzt werden, wenn es gerade von einer anderen Person gefahren wird.
Daher haben wir eine Reihe von APIs für die Geräteverwaltung mit Einschränkungen für den Status des Fahrzeugs integriert. Diese APIs können von jeder System-App (vorinstallierte Apps in der Systempartition) mit den richtigen Berechtigungen aufgerufen werden.
APIs für die Verwaltung von persönlichen Geräten
| API | Zweck |
|---|---|
CarDevicePolicyManager.createUser() |
Erstellt im Hintergrund einen neuen Nutzer auf dem Gerät. Wie interagiert er mit dem Drive-Status? Unabhängig vom Laufwerkstatus wird im Hintergrund ein neuer Nutzer erstellt. |
CarDevicePolicyManager.RemoveUser() |
Entfernt einen vorhandenen Nutzer auf dem Gerät. Wie interagiert er mit dem Drive-Status? Wenn sich der Zielnutzer in folgenden Ländern befindet:
|
DevicePolicyManager.lockNow() |
Sperrt einen vorhandenen Nutzer auf dem Gerät. Wenn der Nutzer bereits Anmeldedaten für den Sperrbildschirm hat (z. B. eine PIN oder ein Muster), bleibt das Display eingeschaltet. Wie wirkt sich das auf den Antriebsstatus aus? Wenn sich der Zielnutzer in folgenden Ländern befindet:
|
DevicePolicyManager.resetPassword() |
Sperrt einen vorhandenen Nutzer auf dem Gerät, indem Anmeldedaten für den Sperrbildschirm festgelegt werden, falls der Nutzer keine Anmeldedaten hat. Das Display bleibt eingeschaltet. Wie interagiert es mit dem Laufwerksstatus? Wenn sich der Zielnutzer in folgenden Ländern befindet:
|
DevicePolicyManager.wipeData() |
Das Gerät wird auf die Werkseinstellungen zurückgesetzt. Wie interagiert es mit dem Laufwerksstatus? Unabhängig vom Status des Antriebs (PARKED, IDLING oder MOVING) wird der Vorgang fortgesetzt. Das System benachrichtigt den Treiber, dass ein Zurücksetzen auf die Werkseinstellungen erforderlich ist. Wenn das Fahrzeug geparkt ist, kann der Fahrer mit der Benachrichtigung entscheiden, das Gerät jetzt oder später (beim nächsten Start) zurückzusetzen. |
Beispiel:
Abbildung 1. Das System sendet eine Benachrichtigung, wenn das Zurücksetzen auf die Werkseinstellungen ausgelöst wird.
Abbildung 2. Wenn das Fahrzeug PARKT, kann der Fahrer mit der Benachrichtigung interagieren, um das Gerät jetzt oder später (beim nächsten Start des Fahrzeugs) zurückzusetzen.
Abbildung 3: Wenn der Fahrer „Später zurücksetzen“ auswählt, wird in einer Toast-Meldung angezeigt, dass das Gerät beim nächsten Starten des Fahrzeugs auf die Werkseinstellungen zurückgesetzt wird.
Geräte für Unternehmen
Android Automotive OS-Geräte mit Android 13 und höher können die Unterstützung der Funktion android.software.device_admin deklarieren, um APIs zur Geräteverwaltung für Unternehmen zu aktivieren. Weitere Informationen finden Sie unter DevicePolicyManager.
Eine Organisation kann dann eine Device Policy Controller-App (DPC) verwenden, um lokale Geräterichtlinien und System-Apps auf dem Gerät zu steuern.
Die Automobilbranche unterstützt keine Arbeitsprofile. Die einzige unterstützte Verwaltungslösung ist ein vollständig verwaltetes Gerät, das für unternehmenseigene Geräte gedacht ist, über die die Organisation die vollständige Verwaltungskontrolle hat.
Unternehmen, die das Fahrzeug aus der Ferne verwalten, müssen auch den Fahrstatus des Autos berücksichtigen. Bestimmte Remote-Aktionen sind daher auch in den Fahrstatus eines Fahrzeugs eingebunden. Beispielsweise gilt die Anleitung zum Zurücksetzen auf die Werkseinstellungen in DevicePolicyManager.setFactoryResetProtectionPolicy() auch für für Unternehmen aktivierte Fahrzeuge.
Jede API aus dem DevicePolicyManager-Code> kann eine Ausnahme auslösen (z. B. wenn das Fahrzeug in Bewegung ist). Unten finden Sie eine unvollständige Liste der DevicePolicyManagercode> APIs. Weitere Informationen finden Sie unter Geräteverwaltung – Übersicht.
DevicePolicyManager.removeActiveAdmin()DevicePolicyManager.setFactoryResetProtectionPolicy()DevicePolicyManager.installCaCert()DevicePolicyManager.uninstallCaCert()DevicePolicyManager.installKeyPair()DevicePolicyManager.removeKeyPair()
Geräteverwaltung für Unternehmen für mehrere Nutzer
Die Geräteverwaltung für Automotive funktioniert mit Unterstützung für mehrere Nutzer. Das bedeutet, dass mehrere Fahrer dasselbe unternehmenseigene Fahrzeug verwenden können, aber ihre Privatsphäre durch ihre eigenen Nutzer nicht anderen Fahrern zugänglich machen.
Der Administrator kann eine Device Policy Controller-App (DPC) verwenden, wie unter Device Policy Controller erstellen beschrieben, um geräteweite oder nutzerspezifische Richtlinien zu steuern.
Für Automotive-Builds wird in der Regel der Headless-Systemnutzermodus verwendet. In diesem Fall wird der Device Policy Controller (DPC) als Geräteeigentümer (Device Owner, DO) des Systemnutzers und als Profilinhaber (Profile Owner, PO) aller anderen Nutzer festgelegt. Der Remote-Administrator sollte die Nutzer des Auftrags verknüpfen, da einige APIs (z. B. requestBugreport()) nur verfügbar sind, wenn alle Nutzer verknüpft sind. Der Remote-Administrator muss dann den richtigen DPC auswählen, um Aktionen auszuführen. Wenn die Aktion mit dem Gerät verknüpft ist (z. B. das Zurücksetzen auf die Werkseinstellungen über wipeData()), sollte der DO-DPC verwendet werden. Wenn es mit einem Nutzer verknüpft ist (z. B. addUserRestriction()), sollte der PO-DPC verwendet werden.
Weitere Informationen zur Verwaltung mehrerer Nutzer in einer DPC-App finden Sie unter Zugeordnete Nutzer.