Energiespareinstellungen

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

Zustandsü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 Kernel-Implementierung verantwortlich. Integratoren sind auch dafür verantwortlich, Weckquellen zu deaktivieren und dafür zu sorgen, dass das Herunterfahren nicht auf unbestimmte Zeit verschoben wird.

Terminologie

In diesem Dokument werden die folgenden Begriffe verwendet:

Systemdesign

In diesem Abschnitt wird beschrieben, wie AAOS den Energiestatus des App-Prozessors darstellt und welche Module das Energiemanagementsystem implementieren. Außerdem wird beschrieben, wie diese Module zusammenarbeiten und wie Zustandsübergänge in der Regel erfolgen.

Zustandsautomat für die Stromversorgung des Autos

AAOS verwendet eine Zustandsmaschine, um den Energiestatus des AP darzustellen. Die Zustandsmaschine bietet die unten dargestellten Status:

Abbildung 1. Zustandsautomat für die Stromversorgung des Autos.

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

• Suspend-to-RAM Das Fahrzeug und das SoC sind ausgeschaltet. Es wird kein Code ausgeführt. Der SoC-RAM wird weiterhin mit Strom versorgt.
• Auf VHAL warten. Wenn der Fahrer mit dem Fahrzeug interagiert, z. B. durch Öffnen einer Tür, versorgt die VMCU das SoC mit Strom. AAOS wird aus dem Suspend-to-RAM-Modus reaktiviert und wechselt in den Status „Wait for VHAL“ (Warten auf VHAL), in dem es auf die Koordination mit der VHAL wartet.
• Aktiviert Das VHAL weist AAOS an, in den Status „Ein“ zu wechseln. In diesem Zustand ist AAOS vollständig aktiv und interagiert mit dem Fahrer.
• Vorbereitung vor dem Herunterfahren: Wenn der Fahrer die Fahrt beendet hat, weist das VHAL AAOS an, in die Phase „Pre Shutdown Prepare“ (Vorbereitung auf das Herunterfahren) zu wechseln. Dazu wird SHUTDOWN_PREPARE gesendet. In diesem Status erhalten Listener für Änderungen des Energiestatus STATE_PRE_SHUTDOWN_PREPARE. Dies dient als Frühwarnung, dass die Abschaltung beginnt.
• Herunterfahren vorbereiten Wenn alle Listener abgeschlossen sind oder das Zeitlimit für die Vorbereitungsphase vor dem Herunterfahren erreicht ist, wechselt das Android-System in die Kernphase „Herunterfahren vorbereiten“ und benachrichtigt Listener mit STATE_SHUTDOWN_PREPARE. Display und Audio sind deaktiviert und AAOS interagiert nicht mit dem Fahrer. Das Android-System wird weiterhin ausgeführt und kann Bereinigungs- und Updatevorgänge wie den Garagenmodus ausführen.
• Auf VHAL-Abschluss warten: An diesem Punkt informiert AAOS das VHAL darüber, dass es bereit ist, herunterzufahren. Die VMCU sollte den SoC in den Deep-Sleep-Modus versetzen und die Stromversorgung des App-Prozessors unterbrechen. AAOS befindet sich dann im Suspend-to-RAM-Zustand, obwohl kein Code ausgeführt wird.

Module für die Energieverwaltung

Das Energiemanagementsystem besteht aus den folgenden Modulen:

Die Funktion für den Tiefschlaf/Ruhezustand (Android in RAM/auf Festplatte anhalten) 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.

Der 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 Energiestatus erfolgt. Dieser Dienst verwendet auch das VHAL, um Nachrichten an die Hardware zu senden.

Das CPPD ist die „Source of Truth“ für Stromrichtlinien. Sie verwaltet die Stromrichtlinien während des gesamten Gerätelebenszyklus und benachrichtigt den CPMS, den VHAL und andere native Listener über Änderungen an den Stromrichtlinien. Das CPMS leitet Anfragen zur Änderung der Richtlinie zur gemeinsamen Stromversorgung an das CPPD weiter.

Das CPMS kommuniziert mit dem VMCU, indem es VHAL-Attribute im Zusammenhang mit dem Energiestatus liest und schreibt, z. B. AP_POWER_STATE_REQ und AP_POWER_STATE_REPORT. Apps können die im CPM definierte Schnittstelle verwenden, um Änderungen des Energiestatus zu überwachen. Über diese Schnittstelle können Apps auch Power-Richtlinien-Listener registrieren. Diese Java API ist mit @SystemApi und @hide annotiert und daher nur für privilegierte Apps verfügbar. Die Beziehung zwischen diesen Modulen, Apps und Diensten wird unten veranschaulicht:

Abbildung 2: Referenzdiagramm für Stromversorgungskomponenten.

Nachrichtensequenz

Im vorherigen Abschnitt wurden die Module beschrieben, aus denen das Energiemanagementsystem besteht. In diesem Abschnitt wird anhand der Beispiele enter deep sleep (Tiefschlafmodus aktivieren) und exit deep sleep (Tiefschlafmodus beenden) erläutert, wie die Module und Apps kommunizieren:

Tiefschlaf

Nur die VMCU kann den Tiefschlafmodus initiieren. Sobald der Tiefschlafmodus aktiviert wurde, sendet die VMCU über den VHAL eine Benachrichtigung an das CPMS. Der CPMS ändert den Status in SHUTDOWN_PREPARE und überträgt diesen Statusübergang an alle Beobachter (die Apps und Dienste, die den CPMS überwachen), indem er die Methode onStateChanged() mit einer neuen Status-ID aufruft, die vom CPM bereitgestellt wird.

Der CPM vermittelt zwischen den Apps/Diensten und den CPMS. Die Methode onStateChanged() für die Apps/Dienste wird synchron in der Methode onStateChanged() des CPM aufgerufen. Die meisten Apps und Dienste müssen ihre Vorbereitung abschließen, bevor sie von diesem Aufruf zurückkehren. Privilegierte Dienste dürfen ihre Vorbereitungen asynchron fortsetzen, nachdem sie für PRE_SHUTDOWN_PREPARE, SUSPEND_ENTER und POST_SUSPEND_ENTER zurückgekehrt sind. In diesem Fall soll der privilegierte Dienst „complete()“ für das bereitgestellte CompletablePowerStateChangeFuture-Objekt aufrufen, wenn die Vorbereitung abgeschlossen ist. Die asynchrone Vorbereitung ist für SHUTDOWN_PREPARE nicht zulässig. Bevor DEEP_SLEEP_ENTRY an das VHAL gesendet wird, sendet das CPMS regelmäßig Anfragen zum Aufschieben des Herunterfahrens an das VHAL.

Wenn alle CPM-Objekte die Vorbereitungen zum Herunterfahren abgeschlossen haben, sendet das CPMS AP_POWER_STATE_REPORT an das VHAL, das dann das VMCU benachrichtigt, dass der AP bereit ist, in den Ruhezustand zu wechseln. Das CPMS ruft auch seine Suspend-Methode auf, wodurch der Kernel angehalten wird.

Die oben beschriebene Sequenz wird unten veranschaulicht:

Abbildung 3: Tiefschlafmodus aktivieren

Von CPM bereitgestellte Programmierschnittstellen

In diesem Abschnitt wird die Java API beschrieben, die vom CPM für System-Apps und ‑Dienste bereitgestellt wird. Diese API ermöglicht der Systemsoftware Folgendes:

• Änderungen des Energiestatus des AP überwachen
• Stromrichtlinien anwenden

So rufen Sie die vom CPM bereitgestellten APIs auf:

1. Rufen Sie 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 zum Erstellen von CPM-Objekten. 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 über Änderungen des Energiestatus erhalten, indem sie CarPowerManager.CarPowerStateListener implementieren. Diese Schnittstelle definiert eine Methode onStateChanged(), die eine Callback-Funktion ist, die aufgerufen wird, wenn sich der Energiestatus 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 Übergang des Energiestatus zu überwachen, erstellen Sie einen neuen Ausführungsthread und registrieren Sie den Listener und diesen Thread für das CPM-Objekt:

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

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

Abmeldung von CarPowerStateListener

Rufen Sie die Methode clearListener auf, um die Registrierung aller Listener-Objekte aufzuheben, die bei CPM registriert sind:

powerManager.clearListener();

Systemintegration in Ihre Android-Implementierung

Integratoren sind für Folgendes verantwortlich:

• Implementierung der Kernelschnittstelle zum Anhalten von Android.
• Implementieren der VHAL-Funktionen für:
  • Die Initiierung des Ruhezustands oder Herunterfahrens vom Auto an Android weitergeben.
  • Senden Sie die Meldung „Bereit zum Herunterfahren“ von Android an das Auto.
  • Das Herunterfahren oder Anhalten von Android über die Linux-Kernelschnittstelle initiieren.
• Achte darauf, dass alle Wakesources deaktiviert sind, wenn sich das Gerät im Ruhezustand befindet.
• Apps müssen schnell genug heruntergefahren werden, damit der Herunterfahrvorgang nicht unbegrenzt verzögert wird.
• Der BSP muss Gerätekomponenten gemäß der Stromrichtlinie ein- oder ausschalten, damit das Anhalten oder der Ruhezustand nicht blockiert wird.

Kernelschnittstelle: /sys/power/state

AAOS versetzt ein Gerät in den Ruhemodus, wenn eine App oder ein Dienst mem für den Ruhemodus mit RAM oder disk für den Ruhemodus mit Festplatte in eine Datei unter /sys/power/state schreibt. Der Integrator muss eine Funktion bereitstellen, die diese Datei überwacht und Linux in den Suspend-Energiezustand versetzt. Diese Funktion kann ein GPIO an die VMCU senden, um sie darüber zu informieren, dass das Gerät vollständig heruntergefahren wurde. Der Integrator ist auch dafür verantwortlich, Race Conditions zwischen dem Senden der endgültigen Nachricht vom VHAL an das VMCU und dem Wechsel des Systems in den Standby- oder Herunterfahrmodus zu beseitigen.

Verantwortlichkeit von VHAL

Das VHAL bietet eine Schnittstelle zwischen dem Fahrzeugnetzwerk und Android. VHAL:

• Leitet die Initiierung des Anhaltens oder Herunterfahrens vom Auto an Android weiter.
• Sendet die Meldung „Bereit zum Herunterfahren“ von Android an das Auto.
• Leitet das Herunterfahren oder den Ruhezustand von Android über die Linux-Kernelschnittstelle ein.

Wenn das CPMS das VHAL darüber informiert, dass es bereit ist, herunterzufahren, sendet das VHAL die Meldung „shutdown ready“ (Herunterfahren bereit) an das VMCU. In der Regel wird die Nachricht über On-Chip-Peripheriegeräte wie UART, SPI und USB übertragen. Nachdem die Nachricht gesendet wurde, ruft CPMS den Kernelbefehl auf, um das Gerät in den Ruhezustand zu versetzen oder herunterzufahren. Davor kann das VHAL oder BSP ein GPIO umschalten, um der VMCU mitzuteilen, dass die Stromversorgung des Geräts sicher entfernt werden kann.

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

AP_POWER_STATE_REPORT

Mit dieser Property kann der aktuelle Energiesparmodus von Android gemeldet werden. Diese Eigenschaft enthält zwei Ganzzahlen:

• int32Values[0]: VehicleApPowerStateReport-Enum des aktuellen Status.
• int32Values[1]: Zeit in Millisekunden, um das Verschieben, den Ruhezustand oder das Herunterfahren zu verzögern. Die Bedeutung dieses Werts hängt vom ersten Wert ab.

Der erste Wert kann einen der folgenden Werte annehmen. VehicleApPowerStateReport.aidl enthält genauere Beschreibungen, die in hardware/interfaces/automotive/vehicle/aidl/android/hardware/automotive/vehicle gespeichert sind.

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

AP_POWER_STATE_REQ

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

• int32Values[0]: VehicleApPowerStateReq-Enum-Wert, der den neuen Status darstellt, in den übergegangen 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 stellt den neuen Status dar, in den Android übergehen soll. Die Semantik ist in VehicleApPowerStateReq.aidl definiert und wird unten beschrieben:

VehicleApPowerStateShutdownParam ist in VehicleApPowerStateShutdownParam.aidl definiert. Dieses Enum hat die folgenden Elemente:

Quellen für das Aufwachen

Der Integrator muss die entsprechenden Weckquellen deaktivieren, wenn sich das Gerät im Ruhemodus befindet. Häufige Weckquellen sind Herzschläge, Modem, WLAN und Bluetooth. Die einzige gültige Weckquelle muss ein Interrupt von der VMCU sein, um den SoC zu aktivieren. Dies setzt voraus, dass die VMCU das Modem auf Remote-Wakeup-Ereignisse (z. B. Remote-Motorstart) überwachen kann. Wenn diese Funktion an den AP übertragen wird, muss eine weitere Weckquelle für das Modem hinzugefügt werden.

Apps

OEMs müssen darauf achten, Apps so zu schreiben, dass sie schnell beendet werden können und den Prozess nicht unbegrenzt verzögern.

Anhang

Verzeichnisse in der Quellcodebaumstruktur

Klassendiagramm

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

Abbildung 4: Diagramm der Leistungsklasse.

Objektbeziehung

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

Abbildung 5: Objektreferenzdiagramm.