Power policy

To ensure that hardware and software components (such as display, audio, and voice interaction) are selectively turned on and off as needed, AAOS provides a power policy, which consists of a set of expected power on and off states for hardware and software components. VHAL, or system-privileged vendor services, can apply a new power policy when the Android power state transitions or when conditions they're waiting for are met.

Applying a power policy is allowed in the states of Wait for VHAL and On. In Shutdown Prepare, Garage Mode is running and should not be disturbed by a power state change. Though a regular power policy can't be applied, a special power policy, which is the system power policy named “no user interaction”, is applied in Shutdown Prepare.

AAOS power state

AAOS devices follow this power state diagram:

AAOS power state diagram

Figure 1. AAOS power state diagram

Each power state is described below:

Value Description
Off No power is physically provided to the application processor (AP), memory, and peripherals.
Wait for VHAL
  • When the driver interacts with the vehicle (for example, by opening a door), the VMCU applies power to the AP, memory. and peripherals.
  • AAOS transitions from one of three states (Off, Suspend-to-RAM (STR, Wait for VHAL Finish) and then enters Wait for VHAL, where it awaits coordination with the VHAL.
  • The VHAL instructs the AAOS to enter the On state. In this state, AAOS is fully running and interacting with the driver.
  • Display is controlled by the power policy and not by Android display On/Off calls for other form factors.
Shutdown Prepare
  • When the driver has stopped driving, the VHAL instructs AAOS to enter Shutdown Prepare. In this state, the display and audio are off and the AAOS is not interacting with the driver. The Android system is still running and can update apps and the Android system. When updates (if any) are completed, the Android system enters Wait for VHAL Finish.
Wait for VHAL to Finish
  • AAOS informs the VHAL that it can be shut down. The Vehicle Microcontroller Unit (VMCU) is expected to place the System-on-Chip (SoC) into Deep Sleep and to remove power from the AP. AAOS is then in the STR state, although no code is being executed.
  • If VHAL does not finish and the driver returns, the head unit (HU) should transition directly to Wait for VHAL.
Suspend-to-RAM (STR) The vehicle and the AP are off, no code is being executed, and power is maintained to the AP RAM.

Software architecture

The power policy architecture is illustrated below and defined in the following section:

Figure 2. Power policy architecture

How is power policy defined?

Implementers define power policies in /vendor/etc/automotive/power_policy.xml, which:

  • Defines the power policy.
  • Defines power policy groups, which include the default power policy and are automatically applied when power state transitions occur.
  • Override the system power policy.

Power policy

Power policy is a set of expected power states of hardware and software components. AAOS supports the following components in power policy:

  • WIFI
  • NFC
  • CPU

Power policy group

The default power policy is automatically applied at power state transition is specified in the power policy group. Vendors can define the default power policy for Wait For VHAL, On, and Wait for VHAL Finish (Deep Sleep Entry or Shutdown Start).

System power policy

AAOS supports only one system power policy, which is “no user interaction”. The system power policy is applied when the device goes into Garage Mode.

The behavior of each component in the system power policy is listed in the table below. Implementers can override Bluetooth, NFC, and Trusted device detection in the system power policy. Overrides are applied in /vendor/etc/power_policy.xml.

Components Power state Configurable
Audio Off No
Media Off No
Display main Off No
Display cluster Off No
Display front passenger Off No
Display rear passenger Off No
Bluetooth Off YES
Wi-Fi ON No
Cellular ON No
Ethernet ON No
Projection Off No
Input Off No
Voice interaction Off No
Visual interaction Off No
Trusted device detection ON YES
Location Off No
Microphone Off No

Interaction with the VHAL

The car power policy daemon running in the system layer subscribes two properties to listen to requests from the VHAL:

  • POWER_POLICY_REQ, the VHAL writes power policy ID to this property.
  • POWER_POLICY_GROUP_REQ, the VHAL writes the power policy group ID to this property.

The current power policy in the system can be changed by modules other than VHAL. In that case, the car power policy daemon updates the CURRENT_POWER_POLICY property to notify the change to the VHAL.

Interaction with native processes

As mentioned above, the car power policy daemon runs in the system layer and, in terms of power policy management, provides almost the same functionality as CPMS running in the framework layer. Also, assume that the car power policy daemon and CPMS are fully synced.

The car power policy daemon exports AIDL interfaces for use by HALs and other native processes. They can be notified when a new power policy is changed. In other words, when each must change its power state.


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.

interface ICarPowerPolicyServer {
   * Gets the current power policy.
  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.
  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.
  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.
  void unregisterPowerPolicyChangeCallback(in ICarPowerPolicyChangeCallback callback);


package android.frameworks.automotive.powerpolicy;

import android.frameworks.automotive.powerpolicy.CarPowerPolicy;

 * ICarPowerPolicyChangeCallback is notified when a power policy changes.

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

Interaction with Java modules

CarPowerManager provides methods to enable power policy management:

  • Get the current power policy.
  • Get the current power policy group
  • Apply a new power policy
  • Set a new power policy group

Only system-privileged modules can use the methods. Modules that want to be informed when a power policy is applied, can register a power policy change listener to CarPowerManager.