Richtlinie zu Stromversorgung

Damit Hardware- und Softwarekomponenten (z. B. Display, Audio und Sprachinteraktion) nach Bedarf selektiv ein- und ausgeschaltet werden, bietet AAOS eine Energiesparrichtlinie, die eine Reihe von erwarteten Ein- und Aus-Zuständen für Hardware- und Softwarekomponenten enthält. VHAL oder systemberechtigte Anbieterdienste können eine neue Energiesparrichtlinie anwenden, wenn der Android-Energiestatus wechselt oder wenn die Bedingungen erfüllt sind, auf die sie warten.

Die Anwendung einer Energiesparrichtlinie ist in den Status „Auf VHAL warten“ und „An“ zulässig (manchmal mit einigen Einschränkungen). Im Modus „Herunterfahren vorbereiten“ ist der Garagenmodus aktiv und sollte nicht durch eine Änderung des Betriebsstatus unterbrochen werden. Obwohl eine normale Energiesparrichtlinie nicht angewendet werden kann, wird in „Shutdown Prepare“ eine spezielle Energiesparrichtlinie angewendet, die Systemenergiesparrichtlinie „Keine Nutzerinteraktion“.

AAOS-Energiestatus

Für AAOS-Geräte gilt dieses Diagramm für den Energiestatus:

Diagramm zum Energiestatus von AAOS

Abbildung 1: Diagramm zum Energiestatus von AAOS

Die einzelnen Betriebszustände werden unten beschrieben:

Wert Beschreibung
Aus
  • Der Anwendungsprozessor (AP), der Arbeitsspeicher und die Peripheriegeräte werden nicht physisch mit Strom versorgt.
Auf VHAL warten
  • Wenn der Fahrer mit dem Fahrzeug interagiert (z. B. eine Tür öffnet), versorgt die VMCU den AP, den Arbeitsspeicher und die Peripheriegeräte mit Strom.
  • AAOS wechselt von einem der drei Status (Aus, Suspend-to-RAM (STR, Warten auf Abschluss von VHAL)) in den Status „Warten auf VHAL“, in dem die Koordination mit dem VHAL abgewartet wird.
An
  • Der VHAL weist das AAOS an, den Betriebsstatus „An“ zu aktivieren. In diesem Zustand ist AAOS vollständig aktiv und interagiert mit dem Fahrer.
  • Das Display wird durch die Energiesparrichtlinie und nicht durch Android-Aufrufe zum Ein- und Ausschalten des Displays für andere Formfaktoren gesteuert.
Herunterfahren vorbereiten
  • Wenn der Fahrer nicht mehr fährt, weist die VHAL AAOS an, den Vorgang „Herunterfahren vorbereiten“ auszuführen. In diesem Zustand sind das Display und die Audiofunktionen deaktiviert und das AAOS interagiert nicht mit dem Fahrer. Das Android-System ist weiterhin aktiv und kann Apps und das Android-System aktualisieren. Wenn alle Updates abgeschlossen sind, wechselt das Android-System in den Status „Auf VHAL-Fertigstellung warten“.
Warten Sie, bis VHAL abgeschlossen ist.
  • AAOS informiert die VHAL, dass sie heruntergefahren werden kann. Die Vehicle Microcontroller Unit (VMCU) soll das System-on-Chip (SoC) in den Tiefschlaf versetzen und die Stromversorgung des ZP unterbrechen. AAOS befindet sich dann im STR-Status, obwohl kein Code ausgeführt wird.
  • Wenn VHAL nicht abgeschlossen wird und der Fahrer zurückkehrt, sollte die Headunit (HU) direkt zu „Auf VHAL warten“ wechseln.
Suspend-to-RAM (STR)
  • Das Fahrzeug und der AP sind ausgeschaltet, es wird kein Code ausgeführt und der AP-RAM wird mit Strom versorgt.
Suspend-to-Disk (STD)
  • Das Fahrzeug und der AP sind ausgeschaltet, es wird kein Code ausgeführt und die Verarbeitungseinheit und der AP-RAM werden nicht mit Strom versorgt.

Wie wird die Energiesparrichtlinie definiert?

Implementierer definieren Energierichtlinien in /vendor/etc/automotive/power_policy.xml. Sie haben folgende Funktionen:

  • Definiert die Energiesparrichtlinie.
  • Hiermit werden Gruppen von Energiesparrichtlinien definiert, die die Standardenergiesparrichtlinie enthalten und automatisch angewendet werden, wenn der Energiestatus wechselt.
  • Überschreibt die Richtlinie zur Systemstromversorgung.

Richtlinie zu Stromversorgung

Die Energierichtlinie besteht aus einer Reihe von erwarteten Energiestatus von Hardware- und Softwarekomponenten. AAOS unterstützt die folgenden Komponenten in der Energiesparrichtlinie:

AUDIO
MEDIEN
DISPLAY
BLUETOOTH 		WIFI
CELLULAR
ETHERNET
PROJECTION 		NFC
INPUT
VOICE_INTERACTION
VISUAL_INTERACTION 		TRUSTED_DEVICE_DETECTION
LOCATION
MICROPHONE
CPU

Anbieter können auch eigene benutzerdefinierte Energiekomponenten für die Verwendung mit Energierichtlinien definieren. Definieren Sie benutzerdefinierte Energiekomponenten in derselben XML-Datei wie die Energierichtlinien, wie in diesem Beispiel: 

<customComponents>
  CUSTOM_COMPONENT_1000
  CUSTOM_COMPONENT_SPECIAL_SENSOR
  CUSTOM_COMPONENT_AUX_INPUT
</customComponents>

Gruppe für Energiesparrichtlinien

Die Standardenergiesparrichtlinie wird automatisch angewendet, wenn der Energiestatus in der Gruppe der Energiesparrichtlinien geändert wird. Anbieter können die Standard-Energiesparrichtlinie für „Wait For VHAL“, „On“ und „Wait for VHAL Finish“ (Deep Sleep Entry oder Shutdown Start) definieren.

Richtlinien für die Systemenergieverwaltung

AAOS unterstützt zwei Systemenergierichtlinien: Keine Nutzerinteraktion und Vorbereitung auf die Sperrung. Die Systemenergierichtlinie wird angewendet, wenn das Gerät in den Lautlosmodus, den Garagenmodus, den Suspend-to-RAM-Modus oder den Suspend-to-Disk-Modus wechselt.

In den folgenden Tabellen wird das Verhalten der einzelnen Komponenten in der Systemenergierichtlinie aufgeführt. Implementierer können die Erkennung von Bluetooth, NFC und vertrauenswürdigen Geräten in der Systemenergierichtlinie Ohne Nutzerinteraktion überschreiben. Überschreibungen werden in /vendor/etc/power_policy.xml angewendet.

ohne Nutzerinteraktion

Das Verhalten der Systemenergierichtlinie Ohne Nutzerinteraktion ist in dieser Tabelle definiert:

Komponenten Energiestatus Konfigurierbar
Audio Aus Nein
Medien Aus Nein
Anzeige Aus Nein
Bluetooth Aus Ja
WLAN An Nein
Mobilfunk An Nein
Ethernet An Nein
Projektion Aus Nein
NFC Aus Ja
Eingabe Aus Nein
Assistent Aus Nein
Nutzerinteraktion Aus Nein
Erkennung vertrauenswürdiger Geräte für die Nutzeranmeldung An Ja
Standort Aus Nein
Mikrofon Aus Nein
CPU An Nein

suspend prep

Das Verhalten der Systemenergierichtlinie suspend prep ist in dieser Tabelle definiert:

Komponenten Energiestatus Vom OEM konfigurierbar
Audio Aus Nein
Medien – Nein
Anzeige – Nein
Bluetooth Aus Nein
WLAN Aus Nein
Mobilfunk – Nein
Ethernet – Nein
Projektion – Nein
NFC – Nein
Eingabe – Nein
Assistent – Nein
Nutzerinteraktion – Nein
Erkennung vertrauenswürdiger Geräte für die Nutzeranmeldung – Nein
Standort Aus Nein
Mikrofon Aus Nein
CPU Aus Nein

Interaktion mit der VHAL

Der Daemon für die Auto-Energiepolitik, der in der Systemschicht ausgeführt wird, abonniert zwei Eigenschaften, um Anfragen von der VHAL zu empfangen:

  • POWER_POLICY_REQ Die VHAL schreibt die ID der Energiesparrichtlinie in diese Property.
  • POWER_POLICY_GROUP_REQ Die VHAL schreibt die ID der Gruppe der Energiesparrichtlinie in diese Property.

Die aktuelle Energiesparrichtlinie im System kann auch von anderen Modulen als VHAL geändert werden. In diesem Fall aktualisiert der Daemon für die Richtlinie zur Fahrzeugstromversorgung die Eigenschaft CURRENT_POWER_POLICY, um die Änderung an die VHAL zu senden.

Interaktion mit nativen Prozessen

Wie bereits erwähnt, wird der Car Power Policy Daemon in der Systemschicht ausgeführt und bietet in Bezug auf die Verwaltung von Energierichtlinien fast dieselben Funktionen wie CPMS, das in der Framework-Schicht ausgeführt wird. Angenommen, der Daemon für die Autostromversorgungsrichtlinie und das CPMS sind vollständig synchronisiert.

Der Daemon für die Richtlinien für die Autostromversorgung exportiert AIDL-Schnittstellen für die Verwendung durch HALs und andere native Prozesse. Sie können benachrichtigt werden, wenn eine neue Energiesparrichtlinie geändert wird. Mit anderen Worten: wann jeder seinen Energiestatus ändern muss.

ICarPowerPolicyServer.aidl

  package android.frameworks.automotive.powerpolicy;

  import android.frameworks.automotive.powerpolicy.CarPowerPolicy;
  import android.frameworks.automotive.powerpolicy.CarPowerPolicyFilter;
  import android.frameworks.automotive.powerpolicy.ICarPowerPolicyChangeCallback;
  import android.frameworks.automotive.powerpolicy.PowerComponent;

  /**
   * ICarPowerPolicyServer is an interface implemented by the power policy daemon.
   * VHAL changes the power policy and the power policy daemon notifies the change to
   * registered subscribers. When subscribing to policy changes, a filter can be specified so
   * that the registered callbacks can listen only to a specific power component's change.
   */

  @VintfStability
  interface ICarPowerPolicyServer {
    /**
     * Gets the current power policy.
     * @throws IllegalStateException if the current policy is not set.
     */
    CarPowerPolicy getCurrentPowerPolicy();

    /**
     * Gets whether the power component is turned on or off.
     *
     * @param componentId Power component ID defined in PowerComponent.aidl to check power
     * state.
     * @return True if the component's power state is on.
     * @throws IllegalArgumentException if the componentId is invalid.
     */
    boolean getPowerComponentState(in PowerComponent componentId);

    /**
     * Subscribes to power policy change.
     * Notification is sent to the registered callback when the power policy changes and the
     * power state of the components which the callback is interested in changes.
     *
     * @param callback Callback that is invoked when the power policy changes.
     * @param filter The list of components which the callback is interested in.
     * @throws IllegalArgumentException if the callback is already registered.
     * @throws IllegalStateException if the callback is dead.
     */
    void registerPowerPolicyChangeCallback(in ICarPowerPolicyChangeCallback callback,
        in CarPowerPolicyFilter filter);

    /**
     * Unsubscribes from power policy change.
     *
     * @param callback Callback that doesn't want to receive power policy change.
     * @throws IllegalArgumentException if the callback is not registered.
     */
    void unregisterPowerPolicyChangeCallback(in ICarPowerPolicyChangeCallback callback);

    /**
     * Applies the power policy.
     *
     * 
{@code policyId} should be one of power policy IDs defined in
     * {@code /vendor/etc/automotive/power_policy.xml} or predefined system power policies.
     *
     * @param policyId ID of power policy.
     * @throws IllegalArgumentException if {@code policyId} is invalid.
     */
    void applyPowerPolicy(in @utf8InCpp String policyId);

    /**
     * Sets the current power policy group.
     *
     * 
{@code policyGroupId} should be one of power policy group IDs defined in
     * {@code /vendor/etc/automotive/power_policy.xml}.
     *
     * @param policyGroupId ID of power policy group.
     * @throws IllegalArgumentException if {@code policyGroupId} is invalid.
     */
    void setPowerPolicyGroup(in @utf8InCpp String policyGroupId);
  }

ICarPowerPolicyChangeCallback.aidl

  package android.frameworks.automotive.powerpolicy;

  import android.frameworks.automotive.powerpolicy.CarPowerPolicy;

  /**
   * ICarPowerPolicyChangeCallback is notified when a power policy changes.
   */

  @VintfStability
  oneway interface ICarPowerPolicyChangeCallback {
    /**
     * Called when a power policy is fully changed.
     *
     * @param policy The current policy.
     */
    void onPolicyChanged(in CarPowerPolicy policy);
  }

Interaktion mit Java-Modulen

CarPowerManager bietet Methoden zur Verwaltung von Energierichtlinien:

  • Aktuelle Energiesparrichtlinie abrufen
  • Neue Energiesparrichtlinie anwenden
  • Neue Gruppe für Energierichtlinien festlegen

Nur Module mit Systemberechtigungen können die Methoden verwenden. Module, die benachrichtigt werden möchten, wenn eine Energiesparrichtlinie angewendet wird, können einen Energiesparrichtlinien-Änderungsempfänger für CarPowerManager registrieren.