Energiespareinstellungen

Zur Unterstützung des fahrzeugspezifischen Energiemanagements stellt Android einen CarPowerManagementService Dienst und eine CarPowerManager Schnittstelle bereit.

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 mit der Vehicle Hardware Abstraction Layer (VHAL) und der Kernel-Implementierung verantwortlich. Integratoren sind auch dafür verantwortlich, Wake-Quellen zu deaktivieren und sicherzustellen, dass Abschaltungen nicht auf unbestimmte Zeit verschoben werden.

Terminologie

Die folgenden Begriffe werden in diesem Dokument verwendet:

System-Design

In diesem Abschnitt wird beschrieben, wie AAOS den Energiestatus des App-Prozessors darstellt und welche Module das Energieverwaltungssystem implementieren. In diesem Material wird auch beschrieben, wie diese Module zusammenarbeiten und wie Zustandsübergänge typischerweise auftreten.

Auto-Power-Zustandsmaschine

AAOS verwendet eine Zustandsmaschine , um den Energiezustand des AP darzustellen. Die Zustandsmaschine stellt die unten dargestellten Zustände bereit:

Abbildung 1. Auto-Power-State-Machine.

Die häufigsten Übergänge sind blau hervorgehoben. Dies sind die Zustände und gemeinsamen Übergänge:

• Suspend-to-RAM. Das Fahrzeug und der SoC sind ausgeschaltet. Es wird kein Code ausgeführt. Die Stromversorgung des SoC-RAM bleibt erhalten.
• Warten Sie auf VHAL. Wenn der Fahrer mit dem Fahrzeug interagiert, indem er beispielsweise eine Tür öffnet, versorgt die VMCU den SoC mit Strom. AAOS setzt den Suspend-to-RAM-Modus fort und geht in „Warten auf VHAL“ über, wo es auf die Koordination mit dem VHAL wartet.
• An. Der VHAL weist AAOS an, in den Ein-Zustand zu wechseln. In diesem Zustand läuft AAOS vollständig und interagiert mit dem Treiber.
• Herunterfahren vorbereiten. Wenn der Fahrer mit der Fahrt fertig ist, weist der VHAL AAOS an, in den Shutdown Prepare-Modus zu wechseln. In diesem Zustand sind Display und Audio ausgeschaltet und AAOS interagiert nicht mit dem Fahrer. Das Android-System läuft noch und es stehen Ihnen kostenlose Updates für Apps und das Android-System zur Verfügung. Wenn Aktualisierungen (falls vorhanden) abgeschlossen sind, wechselt das Android-System zu „Warten auf VHAL-Fertigstellung“.
• Warten Sie, bis VHAL fertig ist. An diesem Punkt informiert AAOS den VHAL darüber, dass er zum Herunterfahren bereit ist. Es wird erwartet, dass die VMCU den SoC in den Tiefschlaf versetzt und den App-Prozessor von der Stromversorgung trennt. AAOS befindet sich dann im Suspend-to-RAM-Zustand, obwohl kein Code ausgeführt wird.

Energieverwaltungsmodule

Das Energiemanagementsystem besteht aus folgenden Modulen:

Die Tiefschlaf-/Ruhezustandsfunktion (Android an RAM/Festplatte hängen lassen) ist im Kernel implementiert. Diese Funktion wird dem Benutzerbereich 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 Energiezustand mit anderen Diensten und HALs. Das CPMS implementiert die oben beschriebene Zustandsmaschine und sendet Benachrichtigungen an jeden Beobachter, wenn ein Stromzustandsübergang auftritt. Dieser Dienst verwendet VHAL auch zum Senden von Nachrichten an die Hardware.

Das CPPD verwaltet die Energiepolitik, bis das CPMS die Kontrolle übernimmt. Außerdem werden Benachrichtigungen über Änderungen der Energierichtlinien an die nativen Listener gesendet.

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

Abbildung 2. Referenzdiagramm der Leistungskomponenten.

Nachrichtenfolge

Im vorherigen Abschnitt wurden die Module beschrieben, aus denen das Energieverwaltungssystem besteht. In diesem Abschnitt wird anhand der Beispiele zum Eintreten in den Tiefschlaf und zum Verlassen des Tiefschlafs erläutert, wie die Module und Apps kommunizieren:

Begeben Sie sich in den Tiefschlaf

Nur die VMCU kann den Tiefschlaf einleiten. Sobald der Tiefschlaf eingeleitet wird, sendet die VMCU über die VHAL eine Benachrichtigung an das CPMS. Das CPMS ändert den Status in SHUTDOWN PREPARE und sendet diesen Statusübergang an alle Beobachter (die Apps und Dienste, die CPMS überwachen), indem es die Methode onStateChanged() mit einer neuen Status-ID aufruft, die vom CPM bereitgestellt wird.

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

Wenn alle CPM-Objekte die Vorbereitungen zum Herunterfahren abgeschlossen haben, sendet das CPMS AP_POWER_STATE_REPORT an die VHAL, die dann die VMCU benachrichtigt, dass der AP zum Anhalten bereit ist. Das CPMS ruft auch seine Suspend-Methode auf, die den Kernel anhält.

Der oben beschriebene Ablauf wird im Folgenden veranschaulicht:

Abbildung 3. Betreten Sie den Tiefschlaf.

Von CPM bereitgestellte Programmierschnittstellen

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

• Überwachen Sie Änderungen des Energiezustands im AP.
• Wenden Sie Energierichtlinien an.

Verwenden Sie diese Schritte, um die vom CPM bereitgestellten APIs aufzurufen:

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

Erstellen Sie ein CarPowerManager-Objekt

Um ein CPM-Objekt zu erstellen, rufen Sie die getCarManager() -Methode des Car-Objekts auf. Bei dieser Methode handelt es sich um 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 durch die Implementierung CarPowerManager.CarPowerStateListener Benachrichtigungen über Änderungen des Energiezustands empfangen. Diese Schnittstelle definiert eine Methode onStateChanged() , eine Rückruffunktion, die aufgerufen wird, wenn der Energiezustand von CPMS geändert wird. Das folgende Beispiel definiert eine neue anonyme Klasse, die die Schnittstelle implementiert:

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

Um dieses Listener-Objekt anzuweisen, einen Energiezustandsübergang 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 der Energiezustand geändert wird, wird die Methode onStateChanged() des Listener-Objekts mit einem Wert aufgerufen, der den neuen Energiezustand darstellt. Der Zusammenhang zwischen Istwert und Leistungszustand wird im CarPowerManager definiert und ist in der folgenden Tabelle dargestellt:

Aufhebung der CarPowerStateListener-Registrierung

Um die Registrierung aller bei CPM registrierten Listener-Objekte aufzuheben, rufen Sie die Methode clearListener auf:

powerManager.clearListener();

Systemintegration in Ihre Android-Implementierung

Integratoren sind für folgende Punkte verantwortlich:

• Implementierung der Kernel-Schnittstelle zum Anhalten von Android.
• Implementieren der VHAL-Funktionen, um:
  • Übertragen Sie die Einleitung des Suspend- oder Shutdown-Vorgangs vom Auto auf Android.
  • Senden Sie die Shutdown-Ready-Nachricht von Android an das Auto.
  • Initiieren Sie das Herunterfahren oder Anhalten von Android über die Linux-Kernel-Schnittstelle.
• Stellen Sie sicher, dass alle Wakesources deaktiviert sind, wenn sich das Gerät im Ruhezustand befindet.
• Stellen Sie sicher, dass Apps schnell genug heruntergefahren werden, um den Herunterfahrvorgang nicht auf unbestimmte Zeit zu verschieben.
• Stellen Sie sicher, dass der BSP Gerätekomponenten gemäß der Energierichtlinie einschaltet (oder ausschaltet), um den Suspend- oder Ruhezustand nicht zu blockieren

Kernel-Schnittstelle: /sys/power/state

AAOS versetzt ein Gerät in den Suspend-Modus, 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 Suspend-Power-Zustand versetzt. Diese Funktion sendet möglicherweise einen GPIO an die VMCU, um die VMCU darüber zu informieren, dass das Gerät vollständig heruntergefahren wurde. Der Integrator ist auch dafür verantwortlich, etwaige Race-Bedingungen zwischen dem Senden der endgültigen Nachricht durch VHAL an die VMCU und dem Wechsel des Systems in den Suspend- oder Shutdown-Modus zu beseitigen.

VHAL-Verantwortung

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

• Gibt die Einleitung des Suspend- oder Shutdown-Vorgangs vom Auto an Android weiter.
• Sendet die Shutdown-Ready-Nachricht von Android an das Auto.
• Initiiert das Herunterfahren oder Anhalten von Android über die Linux-Kernel-Schnittstelle.

Wenn das CPMS dem VHAL mitteilt, dass es zum Herunterfahren bereit ist, sendet das VHAL die Meldung „Bereit zum Herunterfahren“ an die VMCU. Normalerweise übertragen On-Chip-Peripheriegeräte wie UART, SPI und USB die Nachricht. Sobald die Nachricht gesendet wurde, ruft das CPMS den Kernel-Befehl auf, um das Gerät anzuhalten oder herunterzufahren. Zuvor kann der VHAL oder BSP einen GPIO umschalten, um der VMCU mitzuteilen, dass die Stromversorgung des Geräts sicher unterbrochen werden kann.

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

AP_POWER_STATE_REPORT

Verwenden Sie diese Eigenschaft, um den aktuellen Energieverwaltungsstatus von Android zu melden. Diese Eigenschaft enthält zwei Ganzzahlen:

• int32Values[0] : VehicleApPowerStateReport-Enumeration des aktuellen Status.
• int32Values[1] : Zeit in Millisekunden zum Verschieben, Ruhen oder Herunterfahren. Die Bedeutung dieses Werts hängt vom ersten Wert ab.

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

Der Zustand kann autonom oder als Reaktion auf eine Anfrage über die VMCU gesetzt werden.

AP_POWER_STATE_REQ

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

• int32Values[0] : VehicleApPowerStateReq Enumerationswert, der den neuen Zustand darstellt, in den übergegangen werden soll.
• int32Values[1] : VehicleApPowerStateShutdownParam -Enumerationswert. Dieser Wert wird nur für eine SHUTDOWN_PREPARE Nachricht gesendet und übermittelt die darin enthaltenen Optionen an Android.

Der erste ganzzahlige Wert stellt den neuen Zustand dar, in den Android übergehen soll. Die Semantik ist in VehicleApPowerStateReq.aidl definiert und wird unten bereitgestellt:

VehicleApPowerStateShutdownParam ist in VehicleApPowerStateShutdownParam.aidl definiert. Diese Aufzählung hat diese Elemente:

Wake-Quellen

Der Integrator muss die entsprechenden Wake-Quellen deaktivieren, wenn sich das Gerät im Suspend-Modus befindet. Zu den gängigen Wake-Quellen gehören Heartbeats, Modem, WLAN und Bluetooth. Die einzige gültige Weckquelle muss ein Interrupt von der VMCU sein, um den SoC aufzuwecken. Dies setzt voraus, dass die VMCU das Modem auf Remote-Wakeup-Ereignisse (z. B. Remote-Engine-Start) überwachen kann. Wenn diese Funktionalität an den AP übertragen wird, muss eine weitere Wake-Quelle zur Bedienung des Modems hinzugefügt werden.

Apps

OEMs müssen darauf achten, Apps so zu schreiben, dass sie schnell heruntergefahren werden können und den Prozess nicht auf unbestimmte Zeit verschieben.

Anhang

Verzeichnisse im Quellcodebaum

Klassen Diagramm

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

Abbildung 4. Leistungsklassendiagramm.

Objektbeziehung

Abbildung 5 zeigt, welche Objekte Verweise auf andere Objekte haben. Eine Kante bedeutet, dass das Quellobjekt einen Verweis auf das Zielobjekt enthält. Beispielsweise verfügt VehicleHAL über einen Verweis auf ein PropertyHalService-Objekt.

Abbildung 5. Objektreferenzdiagramm.