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 (sometimes with some restrictions). 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 to 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.
Suspend-to-disk (STD)
  • The vehicle and the AP are off, no code is being executed, an no power is maintained to the processing unit and AP RAM.

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.
  • Overrides the system power policy.

Power policy

The power policy consists of a set of expected power states of hardware and software components. AAOS supports these components in the power policy:

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

Vendors can also define their own custom power components for use with power policies. Define custom power components in the same XML file as power policies, as in this example:

<customComponents>
  CUSTOM_COMPONENT_1000
  CUSTOM_COMPONENT_SPECIAL_SENSOR
  CUSTOM_COMPONENT_AUX_INPUT
</customComponents>

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 policies

AAOS supports two system power policies, which are no user interaction and suspend prep. The system power policy is applied when the device goes into Silent Mode, Garage Mode, Suspend-to-RAM, or Suspend-to-disk.

The following tables list the behavior of each component in the system power policy. Implementers can override Bluetooth, NFC, and Trusted device detection in the no user interaction system power policy. Overrides are applied in /vendor/etc/power_policy.xml.

no user interaction

The behavior of the no user interaction system power policy is defined in this table:

Components Power state Configurable
Audio Off No
Media Off No
Display Off No
Bluetooth Off Yes
Wifi On No
Cellular On No
Ethernet On No
Projection Off No
NFC Off Yes
Input Off No
Assistant Off No
User interaction Off No
Trusted-device detection for user login On Yes
Location Off No
Microphone Off No
CPU On No

suspend prep

The behavior of the suspend prep system power policy is defined in this table:

Components Power state OEM-configurable
Audio Off No
Media N/A No
Display N/A No
Bluetooth Off No
Wifi Off No
Cellular N/A No
Ethernet N/A No
Projection N/A No
NFC N/A No
Input N/A No
Assistant N/A No
User interaction N/A No
Trusted-device detection for user login N/A No
Location Off No
Microphone Off No
CPU 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.

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

Interaction with Java modules

CarPowerManager provides methods to enable power policy management:

  • Get the current power policy
  • 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