Google は、黒人コミュニティに対する人種平等の促進に取り組んでいます。取り組みを見る

電源管理

車両固有の電源管理をサポートするため、Android には CarPowerManagementService サービスと CarPowerManager インターフェースが用意されています。

状態遷移は車両マスター コントロール ユニット(VMCU)によってトリガーされます。VMCU と通信するために、インテグレータは複数のコンポーネントを実装する必要があります。インテグレータは、車両ハードウェア抽象化レイヤ(VHAL)やカーネル実装との統合を行います。また、復帰ソースを無効にし、シャットダウンが無期限に延期されないようにします。

用語

以下の用語は、このドキュメント全体で使用されています。

用語 説明
アプリケーション プロセッサ(AP) システム オン チップ(SoC)の一部。
ボード サポート プロセッサ(BSP) 製品が動作するために必要なすべてのハードウェア固有のコード。通常、SoC ベンダーとハードウェア メーカーにより提供されます。これには、デバイス ドライバ、PMIC シーケンス コード、SoC 起動などの項目が含まれます。
CarPowerManager(CPM) アプリケーションが電源状態の変更を登録するための API を公開します。
CarPowerManagementService(CPMS) 車両の電源ステートマシンを実装し、VHAL と連携して、suspend()shutdown() の最終呼び出しを実行します。
CarPowerPolicyDaemon(CPPD) 電源ポリシー リスナーを登録するためのネイティブ プロセス用の AIDL インターフェースを公開します。
汎用入出力(GPIO) 汎用のデジタル信号ピンです。
Hardware Abstraction Layer(HAL) 他のすべての上位モジュールがハードウェア機能にアクセスするためにやり取りする必要があるソフトウェア レイヤ。
休止状態 Suspend to Disk(S2D / S4)とも呼ばれます。SoC は S4 電源モード(休止状態)になり、RAM コンテンツはフラッシュやディスクなどの不揮発性メディアに書き込まれ、システム全体の電源がオフになります。
メディア プロセッサ(MP) システム オン チップ(SoC)をご覧ください。
電力管理集積回路(PMIC) ホストシステムの電力要件の管理に使用するチップ。
システム オン チップ(SoC) AAOS を実行するメイン プロセッサ。通常は Intel、MediaTek、Nvidia、Qualcomm、Renesas、Texas Instruments などのメーカーにより提供されます。
一時停止 Suspend-to-RAM(S2R または STR)とも呼ばれます。SoC は S3 電源モードになり、CPU の電源がオフになりますが、RAM は電源がオンの状態を保持します。
車両 HAL(VHAL) 車両ネットワークとのやり取りに使用される Android API。Tier 1 のパートナーまたは OEM が、このモジュールを作成します。車両ネットワークでは、すべての物理層(CAN、LIN、MOST、イーサネットなど)を使用できます。VHAL はこの車両ネットワークを抽象化して、AAOS が車両と連携することを可能にします。
車両インターフェース プロセッサ(VIP) 車両 MCU をご覧ください。
車両マスター コントロール ユニット(VMCU) 車両ネットワークと SoC 間のインターフェースを備えたマイクロコントローラ。SoC は USB、UART、SPI、GPIO の各信号によって VMCU と通信します。

システム設計

このセクションでは、AAOS がどのようにアプリケーション プロセッサの電源状態を表し、どのモジュールが電源管理システムを実装するかについて説明します。また、これらのモジュールがどのように連携し、通常どのように状態遷移が発生するのかについても説明します。

車両の電源ステートマシン

AAOS はステートマシンを使用して AP の電源状態を表します。ステートマシンは、次の図に示す状態を表します。

車両の電源ステートマシン

図 1. 車両の電源ステートマシン

最も一般的な遷移を青色でハイライト表示しています。それぞれの状態と一般的な遷移は次のとおりです。

  • Suspend-to-RAM。車両と SoC がオフの状態です。コードは実行されていません。電力は SoC RAM に対して維持されます。
  • Wait for VHAL。運転手が車両を操作(ドアを開けるなど)すると、VMCU は SoC に電力を適用します。AAOS は Suspend-to-RAM から再開し、Wait for VHAL に移行して VHAL との連携を待機します。
  • On。VHAL は、AAOS に On 状態に移行するように指示します。この状態では、AAOS は完全に動作しており、運転手との通信に応答しています。
  • Shutdown Prepare。運転手が運転を終えると、VHAL は AAOS に対し、シャットダウンの準備に入るよう指示します。この状態では、ディスプレイと音声はオフになっており、AAOS は運転手との通信を行っていません。Android システムは引き続き実行中であり、アプリや Android システムの更新を自由に行うことができます。更新が完了すると、Android システムは Wait for VHAL Finish 状態に入ります。
  • Wait for VHAL Finish。この時点で、AAOS はシャットダウンの準備が完了したことを VHAL に通知します。VMCU は SoC をディープ スリープに移行させ、アプリケーション プロセッサの電力をオフにします。実行中のコードはありませんが、AAOS は Suspend-to-RAM 状態に移行します。

電源管理モジュール

電源管理システムは、次のモジュールで構成されています。

モジュール名 説明
CarPowerManager Java / C++ API。
CarPowerManagementService 電源状態の遷移を調整。
CarPowerPolicyDaemon ネイティブの電源ポリシー クライアントと通信。
車両 HAL VMCU へのインターフェース。
カーネル Suspend to RAM / ディスクの実装。

ディープ スリープ / 休止状態の機能(Android を一時停止して RAM / ディスクに保存)はカーネルに実装されます。 この機能は、/sys/power/state にある特別なファイルとしてユーザー空間に公開されます。AAOS は、このファイルに mem または disk を書き込むことで一時停止されます。

CPMS は、他のサービスや HAL と電源状態を調整します。上記のステートマシンを実装し、電源状態の遷移が発生するとすべてのオブザーバーに通知を送信します。このサービスはまた、VHAL を使用してハードウェアにメッセージを送信します。

CPPD は、CPMS が制御するまで電源ポリシーを管理します。また、電源ポリシー変更通知をネイティブ リスナーに送信します。

一部のプロパティは VHAL で定義されています。VMCU と通信するために、CPMS はこれらのプロパティの読み取りと書き込みを行います。アプリケーションは、CPM で定義されたインターフェースを使用して電源状態の変化を監視できます。このインターフェースにより、アプリケーションは電源ポリシー リスナーを登録することもできます。この API は Java から呼び出すことができ、@hide または @System API のアノテーションが付けられます。これは特権アプリケーションのみが使用できることを意味します。これらのモジュール、アプリケーション、サービスの関係を以下に示します。

電源コンポーネントの参照図

図 2.電源コンポーネントの参照図

メッセージ シーケンス

前のセクションでは、電源管理システムを構成するモジュールについて説明しました。このセクションでは、ディープ スリープの開始とディープ スリープの終了の例を使用して、モジュールとアプリケーションの通信方法について説明します。

ディープ スリープの開始

VMCU のみがディープ スリープを開始できます。ディープ スリープが開始されると、VMCU は VHAL 経由で CPMS に通知を送信します。CPMS は状態を SHUTDOWN PREPARE に変更し、CPM によって指定された新しいステータス ID を持つ onStateChanged() メソッドを呼び出すことによって、この状態遷移をすべてのオブザーバー(CPMS を監視するアプリケーションとサービス)にブロードキャストします。

CPM はアプリケーションまたはサービスと CPMS を仲介します。アプリケーションまたはサービス向けの onStateChanged() メソッドは、CPM の onStateChanged() メソッドで同期的に呼び出されます。ほとんどのアプリケーションとサービスは、この呼び出しから戻る前に準備を完了する必要があります。特権サービスは、PRE_SHUTDOWN_PREPARESUSPEND_ENTERPOST_SUSPEND_ENTER で返された後も非同期的に準備を継続できます。この場合、特権サービスは、準備を完了すると完成した CompletablePowerStateChangeFuture オブジェクトで complete() を呼び出すことが想定されます。なお、SHUTDOWN_PREPARE では非同期の準備は許可されていません。DEEP_SLEEP_ENTRY is sent to the VHAL, the CPMS periodically sends shutdown postpone requests to the VHAL.

When all CPM objects have completed shutdown preparations, the CPMS sends AP_POWER_STATE_REPORT to the VHAL, which then notifies the VMCU that the AP is ready to suspend. The CPMS also calls its suspend method, which suspends the kernel.

The sequence described above is illustrated below:

Enter deep sleep

Figure 3. Enter deep sleep

Programming interfaces provided by CPM

This section describes the Java API provided by the CPM for system applications and services. This API enables the system software to:

  • Monitor power state changes in the AP.
  • Apply power policies.

Use these steps to call the APIs provided by the CPM:

  1. To acquire the CPM instance, call the Car API.
  2. Call the appropriate method on the object created in Step 1.

Creating a CarPowerManager object

To create a CPM object, call the Car object's getCarManager() method. This method is a facade used to create CPM objects. Specify android.car.Car.POWER_SERVICE as an argument to create a CPM object.

Car car = Car.createCar(this);
CarPowerManager powerManager =
  (CarPowerManager) car.getCarManager(android.car.Car.POWER_SERVICE);

CarPowerStateListener and registration

System applications and services can receive power state change notifications by implementing CarPowerManager.CarPowerStateListener. This interface defines one method onStateChanged(), which is a callback function invoked when the power state of CPMS is changed. The following example defines a new anonymous class that implements the interface:

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

To instruct this listener object to monitor a power state transition, create a new execution thread and register the listener and this thread to the CPM object:

executor = new ThreadPerTaskExecutor();
powerManager.setListener(powerListener, executor);

When the power state is changed, the onStateChanged() method of the listener object is invoked with a value to represent the new power state. The association between actual value and power state is defined in CarPowerManager and is shown in the following table:

Name Description
STATE_ON Enter the on state. The system is fully operational.
STATE_SHUTDOWN_CANCELLED Shutdown is cancelled and power state is returned to the normal state.
STATE_SHUTDOWN_ENTER Applications are expected to clean up and be ready for shut down.
STATE_POST_SHUTDOWN_ENTER Preparations for shutting down have completed and VMCU is ready for shut down. Enter the shutdown state.
STATE_PRE_SHUTDOWN_PREPARE Shutdown process is requested but CPMS doesn't start the process yet. Display and audio are still on
STATE_SHUTDOWN_PREPARE Garage Mode may run during the period.
STATE_SUSPEND_ENTER Applications are expected to clean up and be ready for suspend-to-RAM.
STATE_POST_SUSPEND_ENTER Preparations for suspend-to-RAM have completed and VMCU is ready for suspend-to-RAM. Enter the suspend state.
STATE_SUSPEND_EXIT Wake up from suspend or resume from a cancelled suspend.
STATE_HIBERNATION_ENTER Applications are expected to clean up and be ready for hibernation.
STATE_POST_HIBERNATION_ENTER Preparations for hibernation have completed and VMCU is ready for hibernation Enter the hibernation state.
STATE_HIBERNATION_EXIT Wake up from hibernation or resume from a cancelled hibernation.
STATE_WAIT_FOR_VHAL The system is starting up, but waiting to establish communication with the VHAL before going to the ON state.

CarPowerStateListener unregistration

To unregister all listener objects registered to CPM, call the clearListener method:

powerManager.clearListener();

System integration on your Android implementation

Integrators are responsible for the following items:

  • Implementing the kernel interface to suspend Android.
  • Implementing the VHAL functions to:
    • Propagate the initiation of suspend or shutdown from the car to Android.
    • Send the shutdown ready message from Android to the car.
    • Initiate shutdown or suspend of Android through the Linux kernel interface.
  • Ensure that all wakesources are disabled when the device is in suspend.
  • Ensure that applications shut down quickly enough so as not to indefinitely postpone the shutdown process.
  • Ensure that BSP turns on/off device components according to the power policy so as not to block suspend/hibernation

Kernel interface: /sys/power/state

AAOS places a device into suspend mode when an application or service writes mem for suspend-to-RAM or disk for suspend-to-disk into a file located at /sys/power/state. The integrator must provide a function that monitors this file and puts Linux into the suspend power state. This function may send a GPIO to the VMCU to notify the VMCU that the device has shut down completely. The Integrator is also responsible for removing any race conditions between VHAL sending the final message to the VMCU and the system going into suspend or shutdown mode.

VHAL responsibility

The VHAL provides an interface between the vehicle network and Android. The VHAL:

  • Propagates the initiation of suspend or shutdown from the car to Android.
  • Sends the shutdown ready message from Android to the car.
  • Initiates the shutdown or suspend of Android via the Linux kernel interface.

When the CPMS informs the VHAL that it is ready to shut down, the VHAL sends the shutdown ready message to the VMCU. Typically, on-chip peripherals such as UART, SPI, and USB transmit the message. Once the message has been sent, the CPMS calls the kernel command to suspend or shutdown the device. Before doing so, the VHAL or BSP may toggle a GPIO to instruct the VMCU that it is safe to remove power from the device.

The VHAL must support the following properties, which control power management via the VHAL:

Name Description
AP_POWER_STATE_REPORT Android reports state transitions to the VMCU with this property, using VehicleApPowerStateReport enum values.
AP_POWER_STATE_REQ The VMCU uses this property to instruct Android to transition to different power states, using VehicleApPowerStateReq enum values.

AP_POWER_STATE_REPORT

Use this property to report Android's current power management state. This property contains two integers:

  • int32Values[0]: VehicleApPowerStateReport enum of the current state.
  • int32Values[1]: Time in milliseconds to postpone or sleep or shutdown. The meaning of this value depends on the first value.

The first value can take one of the following values. VehicleApPowerStateReport.aidl contains more specific descriptions, which are stored in the hardware/interfaces/automotive/vehicle/aidl/android/hardware/automotive/vehicle.

Value name Description Second value
WAIT_FOR_VHAL AP is starting and needs to establish communication with the VHAL.
DEEP_SLEEP_ENTRY AP is entering the deep sleep state. The VMCU should turn the AP back on after the time specified in the second value. Must be set
DEEP_SLEEP_EXIT AP is exiting the deep sleep state.
HIBERNATION_ENTRY AP is entering the hibernation state. The VMCU should turn the AP back on after the time specified in the second value. Must be set
HIBERNATION_EXIT AP is exiting the hibernation state.
SHUTDOWN_POSTPONE Android is not ready to shut down. The VMCU should wait the time specified in the second value before shutting down the AP. Android may request additional postponement by issuing additional SHUTDOWN_POSTPONE reports. Must be set
SHUTDOWN_PREPARE Android is preparing to shut down. Must be set
SHUTDOWN_START AP is ready to shut down. The VMCU should turn the AP back on after the time specified in the second value. (The VMCU is not required to support the timed turn-on feature.) Must be set
SHUTDOWN_CANCELLED Android is ceasing to prepare to shut down and will proceed to WAIT_FOR_VHAL.
ON Android is running normally.

The state can be set autonomously or in response to a request via the VMCU.

AP_POWER_STATE_REQ

This property is sent by the VMCU to transition Android into a different power state and contains two integers:

  • int32Values[0]: VehicleApPowerStateReq enum value, which represents the new state into which to transition.
  • int32Values[1]: VehicleApPowerStateShutdownParam enum value. This value is sent only for a SHUTDOWN_PREPARE message and transmits to Android the options it contains.

The first integer value represents the new state into which Android is to transit. The semantics are defined in VehicleApPowerStateReq.aidl and provided below:

Value name Description
ON AP should begin full operation.
SHUTDOWN_PREPARE The AP should prepare to shut down. The second value indicates if the AP is allowed to postpone shutting down and whether the AP should expect to power off or enter deep sleep.
CANCEL_SHUTDOWN The AP should stop preparing to shut down and prepare to go ON.
FINISHED The AP will now be shut down or suspended.

VehicleApPowerStateShutdownParam is defined in VehicleApPowerStateShutdownParam.aidl. This enum has these elements:

Value name Description
CAN_SLEEP AP can enter deep sleep instead of shutting down completely. Postponing is allowed.
CAN_HIBERNATE AP can enter hibernation instead of shutting down completely. Postponing is allowed.
SHUTDOWN_ONLY AP should shut down. Postponing is allowed. Deep sleep is not allowed.
SLEEP_IMMEDIATELY AP may enter deep sleep, but must either sleep or shut down immediately. Postponing is not allowed.
HIBERNATE_IMMEDIATELY AP may enter suspend-to-disk, but must either hibernate or shut down immediately. Postponing is not allowed.
SHUTDOWN_IMMEDIATELY AP must shut down immediately. Postponing is not allowed. Deep sleep is not allowed.

Wake sources

The Integrator must disable the appropriate wake sources when the device is in suspend mode. Common wake sources include heartbeats, modem, Wi-Fi, and Bluetooth. The only valid wake source must be an interrupt from the VMCU to wake up the SoC. This assumes that the VMCU can listen to the modem for remote wakeup events (such as remote engine start). If this functionality is pushed to the AP, then another wake source to service the modem must be added.

Applications

OEMs must be careful to write applications so that they can be shut down quickly and not postpone the process indefinitely.

Appendix

Directories in the source code tree

Content Directory
CarPowerManager-related code. packages/services/Car/car-lib/src/android/car/hardware/power
CarPowerManagementService and so on. packages/services/Car/service/src/com/android/car/power
Services dealing with the VHAL, such as VehicleHal and HAlClient. packages/services/Car/service/src/com/android/car/hal
VHAL interface and property definitions. hardware/interfaces/automotive/vehicle/aidl/android/hardware/automotive/vehicle/
Sample app to provide some idea about the CarPowerManager packages/services/Car/tests/EmbeddedKitchenSinkApp/src/com/google/android/car/kitchensink

Class diagram

This class diagram displays the Java classes and interfaces in the power management system:

Power class diagram

Figure 5. Power class diagram

Object relationship

The following graph illustrates which objects have references to other objects. An edge means that the source object holds a reference to the target object. For example, VehicleHAL has a reference to a PropertyHalService object.

Object reference diagram

Figure 6. Object reference diagram