aboutsummaryrefslogtreecommitdiff
path: root/en/devices/automotive/power.html
diff options
context:
space:
mode:
Diffstat (limited to 'en/devices/automotive/power.html')
-rw-r--r--en/devices/automotive/power.html114
1 files changed, 57 insertions, 57 deletions
diff --git a/en/devices/automotive/power.html b/en/devices/automotive/power.html
index f126825d..084a39bb 100644
--- a/en/devices/automotive/power.html
+++ b/en/devices/automotive/power.html
@@ -21,16 +21,16 @@
limitations under the License.
-->
-<p>Android Automotive (AAE) P introduces a new state – <em>deep sleep</em> – into the AAE P power
-management state machine. To implement this state, AAE P provides a new power management service
+<p>Android 9 introduces a new state – <em>deep sleep</em> – into the power
+management state machine. To implement this state, Android 9 provides a new power management service
and interface: <code>CarPowerManagementService</code> and <code>CarPowerManager</code>.</p>
-<p>State transitions are triggered by the Vehicle MCU (VMCU). To enable AAE to communicate with the
-VMCU, integrators must implement several components. Integrators are responsible for integrating
+<p>State transitions are triggered by the Vehicle MCU (VMCU). To communicate with the VMCU,
+integrators must implement several components. Integrators are responsible for integrating
with the VHAL and the kernel implementation. Integrators are also responsible for disabling wake
sources and ensuring that shutdowns are not postponed indefinitely.</p>
-<h2>Terminology</h2>
+<h2 id=terms>Terminology</h2>
<p>These terms are used throughout this document:</p>
@@ -73,7 +73,7 @@ bringup.</td>
<td>Hibernate</td>
<td>AKA <em>Suspend to Disk</em> (S2D/S4). The SoC is placed into S4 power mode (hibernate) and RAM
content is written to non-volatile media (such as flash or disk) and the entire system is powered
-off. Android does <strong><em>not</em></strong> currently implement hibernate.</td>
+off. Android does <strong><em>not</em></strong> currently implement hibernate.</td>
</tr>
<tr>
<td>Media Processor (MP)</td>
@@ -86,7 +86,7 @@ off. Android does <strong><em>not</em></strong> currently implement hibernate.<
<tr>
<td>System on a Chip (SoC)</td>
<td>Main processor that runs Android, typically supplied by manufacturers such as Intel, Mediatek,
-Nvidia, Qualcomm, Renesas, and Texas Instruments. </td>
+Nvidia, Qualcomm, Renesas, and Texas Instruments.</td>
</tr>
<tr>
<td>Suspend</td>
@@ -112,15 +112,15 @@ communicates with the VMCU via USB, UART, SPI, and GPIO signals. </td>
</tbody>
</table>
-<h2>System design</h2>
+<h2 id=design>System design</h2>
-<p>This section describes how AAE represents the application processor's power state and which
+<p>This section describes how Android 9 represents the application processor's power state and which
modules implement the power management system. This material also describes how these modules work
together and how state transitions typically occur.</p>
-<h3>Car power state machine</h3>
+<h3 id=state>Car power state machine</h3>
-<p>AAE uses a <em>state machine</em> to represent the power state of the AP. This state machine
+<p>Android 9 uses a <em>state machine</em> to represent the power state of the AP. This state machine
provides these five states, as illustrated below:
<p><img src="/devices/automotive/images/automotive_power_states.png"></p>
@@ -136,15 +136,15 @@ When display turns on, the ON: DISP OFF state transitions into ON:FULL (and vice
SHUTDOWN PREPARE and then transitions to OFF or DEEP SLEEP:</p>
<ul>
-<li>Power off</li>
-<li>Suspended to RAM</li>
+<li>Power off.</li>
+<li>Suspended to RAM.</li>
</ul>
<p>When this power management state machine enters the DEEP SLEEP state, the AP runs Suspend to
RAM. For example, the AP suspends its state (such as register stored value) in RAM. When the AP
wakes up, all states are restored.</p>
-<h3>Power management modules</h3>
+<h3 id=module>Power management modules</h3>
<p>These five modules comprise the power management system:</p>
@@ -203,14 +203,14 @@ modules, applications, and services is illustrated below:</p>
<p><b>Figure 2</b>. Power components reference diagram</p>
-<h3>Typical message sequence</h3>
+<h3 id=msg>Typical message sequence</h3>
<p>The previous section described the modules that comprise the power management system. This
section uses the following two examples to explain how the modules and applications communicate:</p>
<ul>
-<li>Enter deep sleep</li>
-<li>Exit deep sleep</li>
+<li>Enter deep sleep.</li>
+<li>Exit deep sleep.</li>
</ul>
<h4>Enter deep sleep</h4>
@@ -262,16 +262,16 @@ provided by the CPM. This method returns these values, as notified from the VMCU
<p><b>Figure 4</b>. Exit deep sleep sequence diagram</p>
-<h2>Programming interfaces provided by CPM</h2>
+<h2 id=cpm>Programming interfaces provided by CPM</h2>
<p>This section describes the Java and C++ API provided by the CPM for system applications and
services. The process to call the CPM in C++ is identical to that used by the Java API. This API
enables the system software to:</p>
<ul>
-<li>Monitor the AP's power state changes</li>
-<li>Acquire boot reasons from the CPMS</li>
-<li>Request the VMCU to shut down the AP on the next suspend instruction</li>
+<li>Monitor power state changes in the AP.</li>
+<li>Acquire boot reasons from the CPMS.</li>
+<li>Request the VMCU to shut down the AP on the next suspend instruction.</li>
</ul>
<p><code>PowerTestFragment.java</code> in <code>com.google.android.car.kitchensink.power</code>
@@ -282,7 +282,7 @@ illustrates how to use these APIs in Java. Use these steps to call the APIs prov
<li>Call the appropriate method on the object created in Step 1.</li>
</ol>
-<h3>Creating a CarPowerManager object</h3>
+<h3 id=object>Creating a CarPowerManager object</h3>
<p>To create a CPM object, call the Car object's <code>getCarManager()</code> method. This method is
a facade used to create CM objects. Specify <code>android.car.Car.POWER_SERVICE</code> as an
@@ -297,7 +297,7 @@ CarPowerManager powerManager =
</pre>
</div>
-<h2>CarPowerStateListener and registration</h2>
+<h2 id=reg>CarPowerStateListener and registration</h2>
<p>System applications and services can receive power state change notifications by implementing
<code>CarPowerManager.CarPowerStateListener</code>. This interface defines one method
@@ -358,7 +358,7 @@ following table:</p>
</tbody>
</table>
-<h3>CarPowerStateListener unregistration</h3>
+<h3 id=dereg>CarPowerStateListener unregistration</h3>
<p>To unregister all listener objects registered to CPM, call the <code>clearListener</code> method:</p>
@@ -367,7 +367,7 @@ powerManager.clearListener();
</pre>
</div>
-<h3>Boot reason acquisition</h3>
+<h3 id=boot>Boot reason acquisition</h3>
<p>To acquire the boot reason, call the <code>getBootReason</code> method, which communicates with
the CPMS and returns one of the following five boot reasons:</p>
@@ -424,29 +424,29 @@ try{
<p>This method throws a <code>CarNotConnectedException</code> when it fails to communicate with the
CPMS.</p>
-<h3>Shutdown request on next suspend</h3>
+<h3 id=shutdown>Shutdown request on next suspend</h3>
<p>The <code>requestShutdownOnNextSuspend()</code>method instructs CPMS to shut down instead of deep
sleep at the next opportunity.</p>
-<h2>System integration on your Android implementation</h2>
+<h2 id=integration>System integration on your Android implementation</h2>
<p>Integrators are responsible for implementing the following items:</p>
<ul>
-<li>Kernel interface to suspend Android</li>
+<li>Kernel interface to suspend Android.</li>
<li>The VHAL to:<ul type="circle">
-<li>Propagate the initiation of suspend or shutdown from the car to Android</li>
-<li>Send the shutdown ready message from Android to the car</li>
-<li>Initiate shutdown or suspend of Android via the Linux kernel interface</li>
-<li>Propagate the wake reason from the car to Android upon resume from suspend</li>
+<li>Propagate the initiation of suspend or shutdown from the car to Android.</li>
+<li>Send the shutdown ready message from Android to the car.</li>
+<li>Initiate shutdown or suspend of Android via the Linux kernel interface.</li>
+<li>Propagate the wake reason from the car to Android upon resume from suspend.</li>
</ul>
-<li>Wakesources to be disabled when the device is in suspend</li>
+<li>Wakesources to be disabled when the device is in suspend.</li>
<li>Applications to shut down quickly enough so as not to indefinitely postpone the shutdown
-process</li>
+process.</li>
</ul>
-<h3>Kernel interface: /sys/power/state</h3>
+<h3 id=kernel>Kernel interface: /sys/power/state</h3>
<p>First, implement the Linux suspend power state. Android places a device into suspend mode when
an application or service writes <code>mem</code> into a file located at
@@ -455,15 +455,15 @@ the VMCU that the device has shut down completely. The Integrator is also respon
any race conditions between VHAL sending the final message to the VMCU and the system going into
suspend or shutdown mode.</p>
-<h3>VHAL responsibility</h3>
+<h3 id=vhal>VHAL responsibility</h3>
<p>The VHAL provides an interface between the vehicle network and Android. The VHAL:</p>
<ul>
-<li>Propagates the initiation of suspend or shutdown from the car to Android</li>
-<li>Sends the shutdown ready message from Android to the car</li>
-<li>Initiates the shutdown or suspend of Android via the Linux kernel interface</li>
-<li>Propagates the wake reason from the car to Android upon resume from suspend</li>
+<li>Propagates the initiation of suspend or shutdown from the car to Android.</li>
+<li>Sends the shutdown ready message from Android to the car.</li>
+<li>Initiates the shutdown or suspend of Android via the Linux kernel interface.</li>
+<li>Propagates the wake reason from the car to Android upon resume from suspend.</li>
</ul>
<p>When the CPMS informs the VHAL that it is ready to shut down, the VHAL sends the shutdown ready
@@ -503,7 +503,7 @@ instruct the VMCU that it is safe to remove power from the device.</p>
integers:</p>
<ul>
-<li><code>int32Values[0]</code>: <code>VehicleApPowerStateReport</code> enum of current state </li>
+<li><code>int32Values[0]</code>: <code>VehicleApPowerStateReport</code> enum of the current state.</li>
<li><code>int32Values[1]</code>: Time in milliseconds to postpone or sleep/shutdown. This value
depends on the first value.</li>
</ul>
@@ -517,7 +517,7 @@ specific descriptions, which are stored in the
<tr>
<th><strong>Value name</strong></th>
<th><strong>Description</strong></th>
-<th><strong>Second value</strong></th>
+<th><strong>Second&nbsp;value</strong></th>
</tr>
</thead>
<tbody>
@@ -562,7 +562,7 @@ value.</td>
<p>The state can be set asynchronously (in the case of <code>BOOT_COMPLETE</code>) or in response to
a request via the VMCU. When the state is set to <code>SHUTDOWN_START</code>,
-<code>DEEP_SLEEP_ENTRY,</code> or <code>SHUTDOWN_POSTPONE</code>, an integer value in
+<code>DEEP_SLEEP_ENTRY,</code> or <code>SHUTDOWN_POSTPONE</code>, an integer value in
milliseconds is sent to notify the VMCU for how long the AP must postpone shutdown or sleep.</p>
<h4>AP_POWER_STATE_REQ</h4>
@@ -572,14 +572,14 @@ two integers:</p>
<ul>
<li><code>int32Values[0]</code>: <code>VehicleApPowerStateReq</code> enum value, which represents
-the new state into which to transition</li>
-<li><code>int32Values[1]</code>: <code>VehicleApPowerStateShutdownParam</code> enum value. This is
-sent only for a <code>SHUTDOWN_PREPARE</code> message and conveys to Android what options it
-contains.</li>
+the new state into which to transition.</li>
+<li><code>int32Values[1]</code>: <code>VehicleApPowerStateShutdownParam</code> enum value. This
+ value os sent only for a <code>SHUTDOWN_PREPARE</code> message and transmits to Android the
+ options it contains.</li>
</ul>
<p>The first integer value represents the new state into which Android is to transit. The semantics
-are defined in <code>types.hal</code> and provided in the following table:</p>
+are defined in <code>types.hal</code> and provided in the following table:</p>
<table>
<thead>
@@ -677,24 +677,24 @@ a specific duration, as specified in <code>VehicleApPowerSetState</code>#SHUTDOW
</tbody>
</table>
-<h3>Wake sources</h3>
+<h3 id=wake>Wake sources</h3>
<p>Use Integrator to disable the appropriate wake sources when the device is in suspend mode.
-Common wake sources include heartbeats, modem, wifi, and Bluetooth. The only valid wake source must
+Common wake sources include heartbeats, modem, wifi, 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,
+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. In the current design, the Integrator
-supplies a file with a list of wake sources to be turned off. The CPMS iterates through this file
+supplies a file with a list of wake sources to be turned off. The CPMS iterates through this file
and manages the turning off and on of the wake sources at suspend time.</p>
-<h3>Applications</h3>
+<h3 id=apps>Applications</h3>
<p>OEMs must be careful to write applications so that they can be shut down quickly and not postpone
the process indefinitely. </p>
-<h2>Appendix</h2>
+<h2 id=app>Appendix</h2>
-<h3>Directories in the source code tree</h3>
+<h3 id=tree>Directories in the source code tree</h3>
<table>
<thead>
@@ -731,7 +731,7 @@ the process indefinitely. </p>
</tbody>
</table>
-<h3>Class diagram</h3>
+<h3 id=diagram>Class diagram</h3>
<p>This class diagram displays the Java classes and interfaces in the power management system:</p>
@@ -739,7 +739,7 @@ the process indefinitely. </p>
<p><b>Figure 5</b>. Power class diagram</p>
-<h3>Object relationship </h3>
+<h3 id=rel>Object relationship</h3>
<p>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