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.
On	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:

AUDIO
MEDIA
DISPLAY_MAIN
DISPLAY_CLUSTER
DISPLAY_FRONT_PASSENGER
DISPLAY_REAR_PASSENGER
BLUETOOTH
WIFI
CELLULAR
ETHERNET
PROJECTION
NFC
INPUT
VOICE_INTERACTION
VISUAL_INTERACTION
TRUSTED_DEVICE_DETECTION
LOCATION
MICROPHONE
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 Silent Mode or 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
NFC	Off	YES
Input	Off	No
Voice interaction	Off	No
Visual interaction	Off	No
Trusted device detection	ON	YES
Location	Off	No
Microphone	Off	No
CPU	On	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.

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.
   */
  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);
}

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);
}

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.