Energiespareinstellungen

Zur Unterstützung der fahrzeugspezifischen Energieverwaltung bietet Android einen CarPowerManagementService-Dienst und eine CarPowerManager-Schnittstelle.

Statusübergänge werden von der Vehicle Master Control Unit (VMCU) ausgelöst. Um mit der VMCU zu kommunizieren, müssen Integratoren mehrere Komponenten implementieren. Integratoren sind für die Integration in die Vehicle Hardware Abstraction Layer (VHAL) und die Kernelimplementierung verantwortlich. Integratoren sind außerdem dafür verantwortlich, Weckquellen zu deaktivieren und dafür zu sorgen, dass Ausschaltungen nicht auf unbestimmte Zeit verschoben werden.

Terminologie

In diesem Dokument werden die folgenden Begriffe verwendet:

System design

In diesem Abschnitt wird beschrieben, wie AAOS den Energiestatus des App-Prozessors darstellt und welche Module das Energieverwaltungssystem implementieren. Außerdem wird beschrieben, wie diese Module zusammenarbeiten und wie sich Zustände in der Regel ändern.

Statusmaschine für die Energieversorgung des Autos

AAOS verwendet einen Zustandsautomaten, um den Betriebsstatus des ZP anzugeben. Die Zustandsmaschine bietet die unten dargestellten Status:

Abbildung 1: Zustandsmaschine für die Energieversorgung des Autos

Die gängigsten Übergänge sind blau hervorgehoben. Das sind die Status und die gängigen Übergänge:

• Suspend-to-RAM Das Fahrzeug und das SoC sind ausgeschaltet. Es wird kein Code ausgeführt. Das SoC-RAM wird weiter mit Strom versorgt.
• Warten Sie auf VHAL. Wenn der Fahrer mit dem Fahrzeug interagiert, z. B. eine Tür öffnet, schaltet die VMCU den SoC ein. AAOS wird aus dem Suspend-to-RAM-Zustand fortgesetzt und geht in den Modus „Warten auf VHAL“, in dem es auf die Koordination mit der VHAL wartet.
• An Der VHAL weist AAOS an, den Status „An“ zu aktivieren. In diesem Zustand ist AAOS vollständig aktiv und interagiert mit dem Fahrer.
• Herunterfahren vorbereiten Wenn der Fahrer fertig ist, fordert die VHAL AAOS auf, den Vorgang „Herunterfahren vorbereiten“ auszuführen. In diesem Zustand sind Display und Audio deaktiviert und AAOS interagiert nicht mit dem Fahrer. Das Android-System läuft weiter und Sie können Apps und das Android-System aktualisieren. Wenn alle Updates abgeschlossen sind, wechselt das Android-System in den Status „Auf VHAL-Fertigstellung warten“.
• Warten, bis VHAL abgeschlossen ist An diesem Punkt informiert AAOS den VHAL darüber, dass er heruntergefahren werden kann. Die VMCU soll das SoC in den Tiefschlaf versetzen und den App-Prozessor ausschalten. AAOS befindet sich dann im Suspend-to-RAM-Status, obwohl kein Code ausgeführt wird.

Energiesparmodule

Das Energieverwaltungssystem besteht aus den folgenden Modulen:

Die Funktion „Tiefschlaf/Ruhezustand“ (Android im RAM/Laufwerk pausieren) ist im Kernel implementiert. Diese Funktion wird dem Nutzerbereich als spezielle Datei unter /sys/power/state zur Verfügung gestellt. AAOS wird angehalten, indem mem oder disk in diese Datei geschrieben wird.

Das CPMS koordiniert den Energiestatus mit anderen Diensten und HALs. Das CPMS implementiert den oben beschriebenen Zustandsautomaten und sendet Benachrichtigungen an alle Beobachter, wenn ein Übergang des Betriebsstatus auftritt. Dieser Dienst verwendet auch die VHAL, um Nachrichten an die Hardware zu senden.

Die CPPD verwaltet die Energierichtlinie, bis die CPMS die Kontrolle übernimmt. Außerdem werden Benachrichtigungen zu Änderungen der Energiesparrichtlinien an die nativen Listener gesendet.

Einige Eigenschaften sind im VHAL definiert. Zur Kommunikation mit der VMCU liest und schreibt das CPMS diese Eigenschaften. Apps können die im CPMS definierte Schnittstelle verwenden, um Änderungen des Energiestatus zu überwachen. Über diese Schnittstelle können Apps auch Energiesparrichtlinien-Listener registrieren. Diese API kann von Java aus aufgerufen werden und ist mit @hide / @System API annotiert. Das bedeutet, dass sie nur für privilegierte Apps verfügbar ist. Die Beziehung zwischen diesen Modulen, Apps und Diensten ist unten dargestellt:

Abbildung 2: Referenzdiagramm für Stromversorgungskomponenten

Nachrichtensequenz

Im vorherigen Abschnitt wurden die Module beschrieben, aus denen das Energieverwaltungssystem besteht. In diesem Abschnitt wird anhand der Beispiele Deep Sleep aktivieren und Deep Sleep beenden erläutert, wie die Module und Apps kommunizieren:

Tiefschlaf

Nur die VMCU kann den Ruhemodus initiieren. Sobald der Deep Sleep gestartet wurde, sendet die VMCU über die VHAL eine Benachrichtigung an die CPMS. Das CPMS ändert den Status in „SHUTDOWN PREPARE“ und sendet diesen Statusübergang an alle Beobachter (die Apps und Dienste, die das CPMS überwachen), indem die onStateChanged()-Methode mit einer neuen Status-ID aufgerufen wird, die vom CPM bereitgestellt wird.

Der CPM vermittelt zwischen den Apps/Diensten und dem CPMS. Die Methode onStateChanged() für die Apps/Dienste wird synchron in der Methode onStateChanged() des CPM aufgerufen. Bei den meisten Apps und Diensten muss die Vorbereitung abgeschlossen sein, bevor Sie von diesem Anruf zurückkehren. Berechtigte Dienste dürfen ihre Vorbereitungen asynchron fortsetzen, nachdem sie für PRE_SHUTDOWN_PREPARE, SUSPEND_ENTER oder POST_SUSPEND_ENTER zurückgekehrt sind. In diesem Fall muss der privilegierte Dienst die Funktion „complete()“ auf das bereitgestellte CompletablePowerStateChangeFuture-Objekt anwenden, wenn die Vorbereitung abgeschlossen ist. Für SHUTDOWN_PREPARE ist keine asynchrone Vorbereitung zulässig. Bevor DEEP_SLEEP_ENTRY an die VHAL gesendet wird, sendet das CPMS regelmäßig Anfragen zum Verschieben des Herunterfahrens an die VHAL.

Wenn alle CPM-Objekte die Vorbereitungen für das Herunterfahren abgeschlossen haben, sendet das CPMS AP_POWER_STATE_REPORT an die VHAL. Diese benachrichtigt dann die VMCU, dass der ZP zum Aussetzen bereit ist. Der CPMS ruft auch seine Suspend-Methode auf, die den Kernel anhält.

Die oben beschriebene Abfolge ist unten dargestellt:

Abbildung 3: Der Tiefschlaf wird aktiviert.

Von CPM bereitgestellte Programmierschnittstellen

In diesem Abschnitt wird die Java API beschrieben, die vom CPM für System-Apps und ‑Dienste bereitgestellt wird. Mit dieser API kann die Systemsoftware Folgendes tun:

• Änderungen des Energiestatus im ZP überwachen
• Energiesparrichtlinien anwenden.

So rufen Sie die vom CPM bereitgestellten APIs auf:

1. Rufe die Car API auf, um die CPM-Instanz abzurufen.
2. Rufen Sie die entsprechende Methode für das in Schritt 1 erstellte Objekt auf.

CarPowerManager-Objekt erstellen

Rufen Sie die Methode getCarManager() des Car-Objekts auf, um ein CPM-Objekt zu erstellen. Diese Methode ist eine Fassade, die zum Erstellen von CPM-Objekten verwendet wird. Geben Sie android.car.Car.POWER_SERVICE als Argument an, um ein CPM-Objekt zu erstellen.

Car car = Car.createCar(this);
CarPowerManager powerManager =
  (CarPowerManager) car.getCarManager(android.car.Car.POWER_SERVICE);

CarPowerStateListener und Registrierung

System-Apps und ‑Dienste können Benachrichtigungen zu Änderungen des Energiestatus erhalten, wenn sie CarPowerManager.CarPowerStateListener implementieren. Diese Schnittstelle definiert eine Methode onStateChanged(), eine Callback-Funktion, die aufgerufen wird, wenn sich der Betriebsstatus von CPMS ändert. Im folgenden Beispiel wird eine neue anonyme Klasse definiert, die die Schnittstelle implementiert:

private final CarPowerManager.CarPowerStateListener powerListener =
  new CarPowerManager.CarPowerStateListener () {
    @Override
     public void onStateChanged(int state) {
       Log.i(TAG, "onStateChanged() state = " + state);
     }
};

Wenn Sie dieses Listener-Objekt anweisen möchten, einen Wechsel des Betriebsstatus zu überwachen, erstellen Sie einen neuen Ausführungsthread und registrieren Sie den Listener und diesen Thread beim CPM-Objekt:

executor = new ThreadPerTaskExecutor();
powerManager.setListener(powerListener, executor);

Wenn sich der Betriebsstatus ändert, wird die onStateChanged()-Methode des Listener-Objekts mit einem Wert aufgerufen, der den neuen Betriebsstatus darstellt. Die Zuordnung zwischen tatsächlichem Wert und Betriebsstatus ist in CarPowerManager definiert und in der folgenden Tabelle dargestellt:

CarPowerStateListener-Abmeldung

Wenn Sie alle für CPM registrierten Listenerobjekte abmelden möchten, rufen Sie die Methode clearListener auf:

powerManager.clearListener();

Systemintegration in Ihrer Android-Implementierung

Integratoren sind für Folgendes verantwortlich:

• Implementierung der Kernel-Schnittstelle zum Aussetzen von Android
• Implementieren Sie die VHAL-Funktionen, um:
  • Die Inaktivitäts- oder Ausschaltvorgänge des Autos an Android weitergeben.
  • Senden Sie die Nachricht „Ausschalten bereit“ von Android an das Auto.
  • Android über die Linux-Kernel-Benutzeroberfläche herunterfahren oder anhalten
• Alle Weckquellen müssen deaktiviert sein, wenn das Gerät im Ruhemodus ist.
• Achten Sie darauf, dass Apps schnell genug heruntergefahren werden, damit der Vorgang nicht auf unbestimmte Zeit verschoben wird.
• Sorgen Sie dafür, dass die BSP-Firmware die Gerätekomponenten gemäß der Energiesparrichtlinie ein- oder ausschaltet, damit der Ruhemodus oder der Hibernationsmodus nicht blockiert wird.

Kernel-Schnittstelle: /sys/power/state

AAOS versetzt ein Gerät in den Ruhemodus, wenn eine App oder ein Dienst mem für „Suspend-to-RAM“ oder disk für „Suspend-to-Disk“ in eine Datei unter /sys/power/state schreibt. Der Integrator muss eine Funktion bereitstellen, die diese Datei überwacht und Linux in den Ruhezustand versetzt. Diese Funktion kann ein GPIO an die VMCU senden, um die VMCU darüber zu informieren, dass das Gerät vollständig heruntergefahren wurde. Der Integrator ist außerdem dafür verantwortlich, alle Race-Bedingungen zwischen dem Senden der letzten Nachricht von VHAL an die VMCU und dem Wechsel des Systems in den Ruhe- oder Ausschaltmodus zu beseitigen.

Verantwortung von VHAL

Die VHAL stellt eine Schnittstelle zwischen dem Fahrzeugnetzwerk und Android bereit. Die VHAL:

• Überträgt die Inaktivitäts- oder Ausschaltvorgänge vom Auto an Android.
• Sendet die Nachricht „Herunterfahren kann beginnen“ von Android an das Auto.
• Initiiert das Herunterfahren oder Aussetzen von Android über die Linux-Kernel-Schnittstelle.

Wenn das CPMS dem VHAL mitteilt, dass es zum Herunterfahren bereit ist, sendet der VHAL die Meldung „Herunterfahren bereit“ an die VMCU. In der Regel wird die Nachricht von On-Chip-Peripheriegeräten wie UART, SPI und USB übertragen. Nachdem die Nachricht gesendet wurde, ruft das CPMS den Kernelbefehl auf, um das Gerät zu pausieren oder herunterzufahren. Zuvor kann die VHAL oder BSP ein GPIO umschalten, um der VMCU mitzuteilen, dass das Gerät sicher vom Stromnetz getrennt werden kann.

Die VHAL muss die folgenden Eigenschaften unterstützen, die die Energieverwaltung über die VHAL steuern:

AP_POWER_STATE_REPORT

Verwenden Sie dieses Attribut, um den aktuellen Status der Energieverwaltung von Android zu melden. Diese Eigenschaft enthält zwei Ganzzahlen:

• int32Values[0]: VehicleApPowerStateReport-Enum für den aktuellen Status.
• int32Values[1]: Zeit in Millisekunden, um die Ausführung zu verschieben, den Ruhezustand zu aktivieren oder das Gerät herunterzufahren. Die Bedeutung dieses Werts hängt vom ersten Wert ab.

Der erste Wert kann einen der folgenden Werte haben. VehicleApPowerStateReport.aidl enthält detailliertere Beschreibungen, die im hardware/interfaces/automotive/vehicle/aidl/android/hardware/automotive/vehicle gespeichert werden.

Der Status kann autonom oder als Reaktion auf eine Anfrage über die VMCU festgelegt werden.

AP_POWER_STATE_REQ

Diese Eigenschaft wird von der VMCU gesendet, um Android in einen anderen Energiesparmodus zu versetzen. Sie enthält zwei Ganzzahlen:

• int32Values[0]: VehicleApPowerStateReq-Eintragstyp, der den neuen Status angibt, in den gewechselt werden soll.
• int32Values[1]: VehicleApPowerStateShutdownParam-Enum-Wert. Dieser Wert wird nur für eine SHUTDOWN_PREPARE-Nachricht gesendet und überträgt die darin enthaltenen Optionen an Android.

Der erste Ganzzahlwert steht für den neuen Status, in den Android wechseln soll. Die Semantik ist in VehicleApPowerStateReq.aidl definiert und unten aufgeführt:

VehicleApPowerStateShutdownParam ist in VehicleApPowerStateShutdownParam.aidl definiert. Diese Enum-Klasse hat folgende Elemente:

Weckquellen

Der Integrator muss die entsprechenden Weckquellen deaktivieren, wenn sich das Gerät im Ruhemodus befindet. Zu den gängigen Quellen für das Aktivieren gehören Herzschläge, Modem, WLAN und Bluetooth. Die einzige gültige Wake-Quelle muss ein Interrupt von der VMCU sein, um das SoC zu aktivieren. Dabei wird davon ausgegangen, dass die VMCU das Modem auf Remote-Weck-Ereignisse (z. B. Start des Motors per Fernbedienung) überwachen kann. Wenn diese Funktion an den ZP gesendet wird, muss eine weitere Weckquelle für das Modem hinzugefügt werden.

Apps

OEMs müssen Apps so entwickeln, dass sie schnell heruntergefahren werden können und der Vorgang nicht auf unbestimmte Zeit verschoben wird.

Anhang

Verzeichnisse im Quellcodebaum

Klassendiagramm

Dieses Klassendiagramm zeigt die Java-Klassen und ‑Schnittstellen im Energieverwaltungssystem:

Abbildung 4: Diagramm der Leistungsklasse.

Objektbeziehung

Abbildung 5 zeigt, welche Objekte Verweise auf andere Objekte haben. Ein Kantenelement bedeutet, dass das Quellobjekt eine Referenz auf das Zielobjekt enthält. VehicleHAL enthält beispielsweise einen Verweis auf ein PropertyHalService-Objekt.

Abbildung 5: Objektreferenzdiagramm.