aboutsummaryrefslogtreecommitdiff
path: root/en
diff options
context:
space:
mode:
Diffstat (limited to 'en')
-rw-r--r--en/compatibility/cts/camera-hal.html10
-rw-r--r--en/compatibility/cts/images/sensor_fusion_adjust.pngbin2144196 -> 197156 bytes
-rw-r--r--en/compatibility/cts/images/sensor_fusion_connect_lights.pngbin2899237 -> 664646 bytes
-rw-r--r--en/compatibility/cts/images/sensor_fusion_conversion_cable.pngbin0 -> 725957 bytes
-rw-r--r--en/compatibility/cts/images/sensor_fusion_fixture.pngbin0 -> 581254 bytes
-rw-r--r--en/compatibility/cts/images/sensor_fusion_servo_connector.pngbin2050227 -> 191299 bytes
-rw-r--r--en/compatibility/cts/images/sensor_fusion_servo_control.pngbin0 -> 972280 bytes
-rw-r--r--en/compatibility/cts/images/sensor_fusion_servo_control_box.pngbin0 -> 859775 bytes
-rw-r--r--en/compatibility/cts/images/sensor_fusion_test_components.pngbin2737880 -> 914920 bytes
-rw-r--r--en/compatibility/cts/images/sensor_fusion_zip_ties.pngbin325663 -> 261974 bytes
-rw-r--r--en/compatibility/cts/sensor-fusion-box-assembly.md4
-rw-r--r--en/compatibility/cts/sensor-fusion-quick-start.html236
-rw-r--r--en/compatibility/cts/sensor_fusion_1_5.zip (renamed from en/compatibility/cts/sensor_fusion_1.5.zip)bin6650653 -> 6712097 bytes
-rw-r--r--en/devices/architecture/kernel/modular-kernels.html2
-rw-r--r--en/devices/automotive/images/automotive_power_class_diagram.pngbin206642 -> 141145 bytes
-rw-r--r--en/devices/automotive/images/automotive_power_deep_sleep.pngbin129342 -> 73006 bytes
-rw-r--r--en/devices/automotive/images/automotive_power_deep_sleep_exit.pngbin106899 -> 60340 bytes
-rw-r--r--en/devices/automotive/images/automotive_power_object_state.pngbin64709 -> 39254 bytes
-rw-r--r--en/devices/automotive/images/automotive_power_reference_diagram.pngbin42141 -> 10636 bytes
-rw-r--r--en/devices/automotive/images/automotive_power_states.pngbin58397 -> 25526 bytes
-rw-r--r--en/devices/automotive/power.html114
-rw-r--r--en/devices/camera/camera3.html10
-rw-r--r--en/devices/tech/debug/asan.html16
-rw-r--r--en/devices/tech/debug/gdb.html42
-rw-r--r--en/devices/tech/power/values.html104
-rw-r--r--en/security/bulletin/2019.html4
-rw-r--r--en/security/bulletin/index.html4
-rw-r--r--en/security/bulletin/pixel/2019.html4
-rw-r--r--en/security/bulletin/pixel/index.html4
-rw-r--r--en/security/encryption/file-based.html4
-rw-r--r--en/setup/build/initializing.html2
-rw-r--r--en/setup/build/known-issues.html2
32 files changed, 334 insertions, 228 deletions
diff --git a/en/compatibility/cts/camera-hal.html b/en/compatibility/cts/camera-hal.html
index 72da83db..5e74be2f 100644
--- a/en/compatibility/cts/camera-hal.html
+++ b/en/compatibility/cts/camera-hal.html
@@ -21,7 +21,7 @@
limitations under the License.
-->
-
+{% include "_versions.html" %}
<p>This document lists all tests available for evaluating the Android camera
hardware abstraction layer (HAL). It is intended for original equipment
@@ -157,8 +157,12 @@ the <code>android.hardware.camera2</code> API</h3>
<h2 id=its_tests>Image Test Suite (ITS) tests</h2>
<aside class="Note"><strong>Note:</strong>
-<a href="/devices/camera/camera3">Camera HAL3</a> is required for all devices
-running Android 9 or higher (except for Android Go devices).</aside>
+<a href="/devices/camera/camera3">Camera HAL3</a> is strongly recommended for
+ devices running Android {{ androidPVersionNumber }} or higher as Camera HAL1
+ has been deprecated. This
+ also allows for a smooth phase out of the deprecated
+ <a href="https://developer.android.com/reference/android/hardware/Camera" class="external">
+ Camera API</a>.</aside>
<p>The Camera Image Test Suite (ITS) tests focus on image correctness.
To perform the tests, run the Python scripts on a workstation with the
diff --git a/en/compatibility/cts/images/sensor_fusion_adjust.png b/en/compatibility/cts/images/sensor_fusion_adjust.png
index 17282ce4..16905229 100644
--- a/en/compatibility/cts/images/sensor_fusion_adjust.png
+++ b/en/compatibility/cts/images/sensor_fusion_adjust.png
Binary files differ
diff --git a/en/compatibility/cts/images/sensor_fusion_connect_lights.png b/en/compatibility/cts/images/sensor_fusion_connect_lights.png
index e77bab0e..6efe549b 100644
--- a/en/compatibility/cts/images/sensor_fusion_connect_lights.png
+++ b/en/compatibility/cts/images/sensor_fusion_connect_lights.png
Binary files differ
diff --git a/en/compatibility/cts/images/sensor_fusion_conversion_cable.png b/en/compatibility/cts/images/sensor_fusion_conversion_cable.png
new file mode 100644
index 00000000..4bb730c2
--- /dev/null
+++ b/en/compatibility/cts/images/sensor_fusion_conversion_cable.png
Binary files differ
diff --git a/en/compatibility/cts/images/sensor_fusion_fixture.png b/en/compatibility/cts/images/sensor_fusion_fixture.png
new file mode 100644
index 00000000..d2b54d50
--- /dev/null
+++ b/en/compatibility/cts/images/sensor_fusion_fixture.png
Binary files differ
diff --git a/en/compatibility/cts/images/sensor_fusion_servo_connector.png b/en/compatibility/cts/images/sensor_fusion_servo_connector.png
index dc20d1bf..422b95a2 100644
--- a/en/compatibility/cts/images/sensor_fusion_servo_connector.png
+++ b/en/compatibility/cts/images/sensor_fusion_servo_connector.png
Binary files differ
diff --git a/en/compatibility/cts/images/sensor_fusion_servo_control.png b/en/compatibility/cts/images/sensor_fusion_servo_control.png
new file mode 100644
index 00000000..db1a69cf
--- /dev/null
+++ b/en/compatibility/cts/images/sensor_fusion_servo_control.png
Binary files differ
diff --git a/en/compatibility/cts/images/sensor_fusion_servo_control_box.png b/en/compatibility/cts/images/sensor_fusion_servo_control_box.png
new file mode 100644
index 00000000..1b7a67f2
--- /dev/null
+++ b/en/compatibility/cts/images/sensor_fusion_servo_control_box.png
Binary files differ
diff --git a/en/compatibility/cts/images/sensor_fusion_test_components.png b/en/compatibility/cts/images/sensor_fusion_test_components.png
index ae7a4f54..d3577f44 100644
--- a/en/compatibility/cts/images/sensor_fusion_test_components.png
+++ b/en/compatibility/cts/images/sensor_fusion_test_components.png
Binary files differ
diff --git a/en/compatibility/cts/images/sensor_fusion_zip_ties.png b/en/compatibility/cts/images/sensor_fusion_zip_ties.png
index 790766eb..6c416719 100644
--- a/en/compatibility/cts/images/sensor_fusion_zip_ties.png
+++ b/en/compatibility/cts/images/sensor_fusion_zip_ties.png
Binary files differ
diff --git a/en/compatibility/cts/sensor-fusion-box-assembly.md b/en/compatibility/cts/sensor-fusion-box-assembly.md
index ba236e51..5f6c6f6f 100644
--- a/en/compatibility/cts/sensor-fusion-box-assembly.md
+++ b/en/compatibility/cts/sensor-fusion-box-assembly.md
@@ -51,7 +51,7 @@ Figure 1):
Before starting, ensure you have downloaded the technical drawings for the
Sensor Fusion Box (included in the
-[Sensor Fusion Box zip file](/compatibility/cts/sensor_fusion_1.5.zip)) and
+[Sensor Fusion Box zip file](/compatibility/cts/sensor_fusion_1_5.zip)) and
have the following tools available:
* Phillips head screwdriver
@@ -211,7 +211,7 @@ To complete assembly of the Sensor Fusion Box:
screw detail
1. Print out a colored copy of the checkerboard (included in the [Sensor Fusion
- Box zip file](/compatibility/cts/sensor_fusion_1.5.zip)) on A3 (or 11 x 17
+ Box zip file](/compatibility/cts/sensor_fusion_1_5.zip)) on A3 (or 11 x 17
inch) paper, and tape it on the opposite wall of the phone fixture.
Make sure the red dot in the center of the checkerboard is directly facing
diff --git a/en/compatibility/cts/sensor-fusion-quick-start.html b/en/compatibility/cts/sensor-fusion-quick-start.html
index 6ade5513..2b3783bb 100644
--- a/en/compatibility/cts/sensor-fusion-quick-start.html
+++ b/en/compatibility/cts/sensor-fusion-quick-start.html
@@ -25,43 +25,55 @@
</p>
<h2 id="required-tools">Required tools</h2>
<p>
- Before getting started, ensure you have the following cables and cords
- available:</p>
+ Before getting started, ensure you have the following components:</p>
<figure id="sensor-fusion-test-component">
<img src="/compatibility/cts/images/sensor_fusion_test_components.png" width="700" alt="Sensor fusion test components">
- <figcaption><b>Figure 1.</b> Components required for the sensor fusion test</figcaption>
+ <figcaption><b>Figure 1.</b> Components required for the sensor fusion
+ test</figcaption>
</figure>
- <ul>
+ <ol>
<li>USB A to B cable</li>
<li>USB A to C cable (for test phone)</li>
- <li>12V power cord (for servo control box)</li>
+ <li>12V 2A power cord (for servo control box)</li>
<li>12V power cord (for lighting, with switch)</li>
- <li>Interconnected cable (for lighting)</li>
- <li>Conversion cable (for lighting)</li>
- </ul>
+ <li>5V male-male connection cable (for lighting)</li>
+ <li>5V male-female conversion cable (for lighting)</li>
+ </ol>
<h2 id="step-1-connect-lights">Step 1: Connect lights</h2>
<p>
To connect the lights:
</p>
<ol>
- <li>Use the interconnected cable to connect the two lights.</li>
- <li>Connect one light to the conversion cable.
+ <li>Use the male-male cable to connect the two lights on the bottom ends
+ of the lights as shown in figure 2. Secure the cable to the bottom of the
+ box to keep the cable from interfering with the operation.</li>
+ <li>Connect the end of the light closer to the light cable exit hole to
+ the conversion cable
<figure id="sensor-fusion-connect-lights">
<img src="/compatibility/cts/images/sensor_fusion_connect_lights.png" width="300" alt="Connect lights">
- <figcaption><b>Figure 2.</b> Connecting the lights to each other and one light to the conversion cable</figcaption>
+ <figcaption><b>Figure 2.</b> Connecting the lights to each other and
+ one light to the conversion cable</figcaption>
</figure>
+ <ol>
+ <li>Light cable exit hole</li>
+ <li>USB cable exit hole</li>
+ <li>5V male-male conversion cable</li>
+ </ol>
</li>
<li>Thread the unconnected end of the conversion cable through the round
- hole that exits the box, then connect the end of that cable to the power
+ hole that exits the box, then connect it to the power
cable for lighting.
- <table class="columns">
- <tr>
- <td><img src="/compatibility/cts/images/sensor_fusion_conversion_cable1.png" width="" alt="Conversion cable and power cable"></td>
- <td><img src="/compatibility/cts/images/sensor_fusion_conversion_cable2.png" width="" alt="Power cable for lighting"></td>
- </tr>
- </table>
- <b>Figure 3.</b> Lighting conversion cable exiting the box and connecting
- to power cable</li>
+ <figure id="Conversion cable and power cable">
+ <img src="/compatibility/cts/images/sensor_fusion_conversion_cable.png" width="500" alt="Conversion and power cable">
+ <figcaption><b>Figure 3.</b> Lighting conversion cable exiting the box
+ and connecting to power cable</figcaption>
+ </figure>
+ <ol>
+ <li>Exit hole</li>
+ <li>Conversion cable</li>
+ <li>Power cable</li>
+ </ol>
+ </li>
</ol>
<h2 id="step-2-attach-servo">Step 2: Attach servo</h2>
<p>
@@ -71,104 +83,116 @@
<li>Plug the servo connector into the servo control. Be sure to insert
the connector oriented to the corresponding colors as labeled (Y =
Yellow, R = Red, B = Black), as reversing the order could damage the
- motor.
+ motor. If the cord is too short, use a
+ <a href="https://www.adafruit.com/product/972" class="external">
+ servo extension cable</a>.
<figure id="sensor-fusion-servo-connector">
<img src="/compatibility/cts/images/sensor_fusion_servo_connector.png" width="300" alt="Servo connecting to the servo control box">
- <figcaption><b>Figure 4.</b> Servo connecting to the servo control box</figcaption>
+ <figcaption><b>Figure 4.</b> Servo connecting to the servo control
+ box</figcaption>
+ </figure>
+ </li>
+ <li>Connect the servo control with its power cord (the lighting and
+ servo control have independent, dedicated power supplies as shown in
+ figure 5).
+ <figure id="sensor-fusion-servo-control">
+ <img src="/compatibility/cts/images/sensor_fusion_servo_control.png" width="500" alt="Connecting servo control to power">
+ <figcaption><b>Figure 5.</b> Connecting the servo control to its
+ dedicated power cord</figcaption>
</figure>
- <li>Connect the servo control with its power cord (the lighting and
- servo control have independent, dedicated power supplies).
- <table class="columns">
- <tr>
- <td><img src="/compatibility/cts/images/sensor_fusion_servo_control1.png" width="" alt="Servo control"></td>
- <td><img src="/compatibility/cts/images/sensor_fusion_servo_control2.png" width="" alt="Power to servo control"></td>
- </tr>
- </table>
- <b>Figure 5.</b> Connecting the servo control to its dedicated power
- cord
- <li>Use the USB A to B cable to connect the servo control box to the
- host (machine that is running the test).
- <table class="columns">
- <tr>
- <td><img src="/compatibility/cts/images/sensor_fusion_servo_control_box1.png" width="" alt="Connect servo control box"></td>
- <td><img src="/compatibility/cts/images/sensor_fusion_servo_control_box2.png" width="" alt="Connect servo control box to host"></td>
- </tr>
- </table>
- <b>Figure 6.</b> Connecting the servo control box to the host machine</li>
- </ol>
- <h2 id="step-3-attach-phone">Step 3: Attach phone</h2>
<ol>
- <li>Set the phone on the fixture and clamp it down.<br>
- <table class="columns">
- <tr>
- <td><img src="/compatibility/cts/images/sensor_fusion_fixture1.png" width="" alt="Phone on fixture"></td>
- <td><img src="/compatibility/cts/images/sensor_fusion_fixture2.png" width="" alt="Clamping phone on fixture"></td>
- </tr>
- </table>
- <b>Figure 7.</b> Placing and clamping the phone on the fixture
- <p> The upside-down thumb screw provides back support while the
- other screw tightens the grip by turning right. For more help,
- refer to the video on loading the phone (included in the
- <a href="/compatibility/cts/sensor_fusion_1.5.zip">Sensor
- Fusion Box zip file</a>). </p>
- </li>
- <li>Use a zip tie to hold the phone USB cord to the fixture plate and
- lead it outside the box through the exit hole. Plug the other end
- of the cord to the host running the test.
- <figure id="sensor-fusion-zip-ties">
- <img src="/compatibility/cts/images/sensor_fusion_zip_ties.png" width="300" alt="Phone USB cord with zip ties">
- <figcaption><b>Figure 8.</b> Phone USB cord held to fixture with
- zip ties</figcaption>
- </figure>
- </li>
+ <li>Power for servo control</li>
+ <li>Power for lighting</li>
</ol>
- <h2 id="step-4-run-test-script">Step 4: Run test script</h2>
- <p>
- The main python executable for the test script is:
- </p>
- <pre class="prettyprint">python tools/run_all_tests.py device=ID camera=0 scenes=sensor_fusion rot_rig=default</pre>
- <p>You can also enter the actual rotator address at the command line
- using:</p>
- <pre class="prettyprint">rot_rig=VID:PID:CH</pre>
+ </li>
+ <li>Use the USB A to B cable to connect the servo control box to the
+ host (machine that is running the test).
+ <figure id="sensor-fusion-servo-control-box">
+ <img src="/compatibility/cts/images/sensor_fusion_servo_control_box.png" width="500" alt="Connect servo control box to host machine">
+ <figcaption><b>Figure 6.</b> Connecting the servo control box to the
+ host machine</figcaption>
+ </figure>
+ </ol>
+ <h2 id="step-3-attach-phone">Step 3: Attach phone</h2>
+ <ol>
+ <li>Set the phone on the fixture and clamp it down.<br>
+ <figure id="sensor-fusion-servo-connector">
+ <img src="/compatibility/cts/images/sensor_fusion_fixture.png" width="500" alt="Attaching phone on fixture">
+ <figcaption><b>Figure 7.</b> Placing and clamping the phone on the
+ fixture</figcaption>
+ </figure>
+ <ol>
+ <li>Back support</li>
+ <li>Tightness</li>
+ </ol>
+ <p>Phones should be placed in a manner where the USB cords are located at
+ the periphery of the phone mount and the cameras are near the center of
+ the mount.
+ </p>
+ <p>The upside-down thumb screw provides back support while the other screw
+ tightens the grip by turning right. For more details, see
+ <a href="#attach-phone-to-mount">video on how to
+ attach the phone</a>.</p>
+ </li>
+ <li>Use a zip tie to hold the phone USB cord to the fixture plate and
+ lead it outside the box through the exit hole. Plug the other end
+ of the cord to the host running the test.
+ <figure id="sensor-fusion-zip-ties">
+ <img src="/compatibility/cts/images/sensor_fusion_zip_ties.png" width="300" alt="Phone USB cord with zip ties">
+ <figcaption><b>Figure 8.</b> Phone USB cord held to fixture with
+ zip ties</figcaption>
+ </figure>
+ </li>
+ </ol>
+ <h2 id="step-4-run-test-script">Step 4: Run test script</h2>
+ <p>
+ The main python executable for the test script is:
+ </p>
+ <pre class="prettyprint"><code class="devsite-terminal">python tools/run_all_tests.py device=ID camera=0 scenes=sensor_fusion rot_rig=default</code>
+ </pre>
+ <p>You can modify the command to specify the actual rotator address by using:</p>
+ <pre class="prettyprint">rot_rig=<var>VID:PID:CH</var>
+ </pre>
<ul>
<li>To determine the Vendor ID (VID) and Product ID (PID), use the Linux
- command <code>lsusb</code>.</li> <li>By default, the VID and PID are set
+ command <code>lsusb</code>.</li>
+ <li>By default, the VID and PID are set
to <code>04d8</code> and <code>fc73</code> with channel "1".</li>
</ul>
- <h3 id="multiple-runs-different-formats">Multiple runs, different formats</h3>
+ <h3 id="multiple-runs-different-formats">Multiple runs, different formats</h3>
<p>To perform multiple runs with different formats, you can use a
different script (however, the results will not be uploaded to
- <code>CtsVerifier.apk</code>). Sample test script: </p>
- <pre class="prettyprint">python tools/run_sensor_fusion_box.py device=FA7831A00278 camera=0 rotator=default img_size=640,360 fps=30 test_length=7</pre>
+ <code>CtsVerifier.apk</code>). Sample test script:</p>
+ <pre class="prettyprint"><code class="devsite-terminal">python tools/run_sensor_fusion_box.py device=FA7831A00278 camera=0 rotator=default img_size=640,360 fps=30 test_length=7</code></pre>
<h3 id="permission-issues">Permission issues</h3>
<p>To resolve permission issues related to controlling the motor through the
USB port:</p>
<ol>
- <li>Add the operator username to <code>dialout</code> group using:
- <pre class="prettyprint">sudo adduser $username dialout</pre></li>
+ <li>Add the operator username to the <code>dialout</code> group using:
+ <pre class="prettyprint"><code class="devsite-terminal">sudo adduser <var>USERNAME</var> dialout</code>
+ </pre></li>
<li>Log out the operator.</li>
<li>Log in the operator.</li>
</ol>
- <h2>Adjusting the motor</h2>
+ <h2 id="adjusting-the-motor">Adjusting the motor</h2>
<p>
- You can adjust the speed of the motor and the distance the phone' travels
- using the resistance ports (labelled <strong>A</strong>,
+ You can adjust the speed of the motor and the distance the phone travels
+ using the resistance ports (labeled <strong>A</strong>,
<strong>B</strong>, and <strong>T</strong>) on the side of the controller
box.
</p>
<ol>
+ <li>Upon first receiving the box, power up the box and determine the initial
+ position. If the initial position on power-up is not close to 12
+ o'clock, unscrew the phone fixture (single Philips head screw in mount
+ hole) and rotate the phone fixture to 12 o'clock.</li>
<li>Ensure the phone fixture travels a full 90 degrees (from 12
o'clock to 9 o'clock when looking at the phone) for each rotation.
<ul>
- <li>To adjust the distance travelled, use the <strong>A</strong> and
+ <li>To adjust the distance traveled, use the <strong>A</strong> and
<strong>B</strong> screws (where <strong>A</strong> is the starting
location
and <strong>B</strong> is the final location).</li>
- <li>Upon first receiving the box, it is easiest to power up the box and
- determine the initial position. If the initial position on power-up
- is not close to 12 o'clock, unscrew the phone fixture (single Philips
- head screw in mount hole) and rotate the phone fixture to 12
- o'clock.</li>
</ul>
</li>
<li>Adjust the rotation speed to travel a full rotation in 1.5s. Turning
@@ -176,7 +200,7 @@
<table class="columns">
<tr>
<td>
- <img src="/compatibility/cts/images/sensor_fusion_adjust.png" width="" alt="Adjust position and speed of servo">
+ <img src="/compatibility/cts/images/sensor_fusion_adjust.png" width="300" alt="Adjust position and speed of servo">
</td>
<td>
<ul>
@@ -191,10 +215,32 @@
fixture
</li>
</ol>
- <p>
- For more help, refer to the video of the sensor fusion box running (included
- in the <a href=/compatibility/cts/sensor_fusion_1.5.zip>Sensor Fusion Box
- zip file</a>).
- </p>
+ <p>For more information, see <a href="#video-tutorials">video tutorials</a>.</p>
+ <h2 id="video-tutorials">Video tutorials</h2>
+ <div class="video-wrapper-full-width">
+ <h3 id="attach-phone-to-mount">Attaching phone to mount</h3>
+ <iframe class="devsite-embedded-youtube-video" data-video-id="zV61A0Mv394"
+ data-autohide="1" data-showinfo="0" frameborder="0" allowfullscreen>
+ </iframe>
+ </div>
+ <div class="video-wrapper-full-width">
+ <h3 id="install-phones-dual-mount">Installing phones on a dual mount</h3>
+ <iframe class="devsite-embedded-youtube-video" data-video-id="S2SrICXJWOA"
+ data-autohide="1" data-showinfo="0" frameborder="0" allowfullscreen>
+ </iframe>
+ </div>
+ <div class="video-wrapper-full-width">
+ <h3 id="calibrate-controller">Calibrating the controller</h3>
+ <iframe class="devsite-embedded-youtube-video" data-video-id="Jvm0RlwaTlY"
+ data-autohide="1" data-showinfo="0" frameborder="0" allowfullscreen>
+ </iframe>
+ </div>
+ <div class="video-wrapper-full-width">
+ <h3 id="adjust-phone-fixture">Adjusting the phone fixture</h3>
+ <iframe class="devsite-embedded-youtube-video" data-video-id="hbKCxqmg-eg"
+ data-autohide="1" data-showinfo="0" frameborder="0" allowfullscreen>
+ </iframe>
+ </div>
+
</body>
</html>
diff --git a/en/compatibility/cts/sensor_fusion_1.5.zip b/en/compatibility/cts/sensor_fusion_1_5.zip
index a35275b6..1090c033 100644
--- a/en/compatibility/cts/sensor_fusion_1.5.zip
+++ b/en/compatibility/cts/sensor_fusion_1_5.zip
Binary files differ
diff --git a/en/devices/architecture/kernel/modular-kernels.html b/en/devices/architecture/kernel/modular-kernels.html
index c314a956..a0908b71 100644
--- a/en/devices/architecture/kernel/modular-kernels.html
+++ b/en/devices/architecture/kernel/modular-kernels.html
@@ -599,7 +599,7 @@ where to load the DT blob from.</p>
<p>Requirements for Device Tree Overlay support (if used):</p>
<ul>
-<li>Device should have new device tree blob for overlay (DTBO) partion per
+<li>Device should have new device tree blob for overlay (DTBO) partition per
kernel image for board–specific DT overlay (for details on the partition format,
see <a href="/devices/architecture/dto/partitions.html">DTB/DTBO Partitions</a>.
The assumption is that bootloader already knows where and how to load the
diff --git a/en/devices/automotive/images/automotive_power_class_diagram.png b/en/devices/automotive/images/automotive_power_class_diagram.png
index 736dadb8..ac46c2c3 100644
--- a/en/devices/automotive/images/automotive_power_class_diagram.png
+++ b/en/devices/automotive/images/automotive_power_class_diagram.png
Binary files differ
diff --git a/en/devices/automotive/images/automotive_power_deep_sleep.png b/en/devices/automotive/images/automotive_power_deep_sleep.png
index 2ccfda75..a4ee79f9 100644
--- a/en/devices/automotive/images/automotive_power_deep_sleep.png
+++ b/en/devices/automotive/images/automotive_power_deep_sleep.png
Binary files differ
diff --git a/en/devices/automotive/images/automotive_power_deep_sleep_exit.png b/en/devices/automotive/images/automotive_power_deep_sleep_exit.png
index b920eb20..8ab08220 100644
--- a/en/devices/automotive/images/automotive_power_deep_sleep_exit.png
+++ b/en/devices/automotive/images/automotive_power_deep_sleep_exit.png
Binary files differ
diff --git a/en/devices/automotive/images/automotive_power_object_state.png b/en/devices/automotive/images/automotive_power_object_state.png
index 0e0aba62..32f3145c 100644
--- a/en/devices/automotive/images/automotive_power_object_state.png
+++ b/en/devices/automotive/images/automotive_power_object_state.png
Binary files differ
diff --git a/en/devices/automotive/images/automotive_power_reference_diagram.png b/en/devices/automotive/images/automotive_power_reference_diagram.png
index 625450f1..8b521c09 100644
--- a/en/devices/automotive/images/automotive_power_reference_diagram.png
+++ b/en/devices/automotive/images/automotive_power_reference_diagram.png
Binary files differ
diff --git a/en/devices/automotive/images/automotive_power_states.png b/en/devices/automotive/images/automotive_power_states.png
index d0c5cab6..8772354f 100644
--- a/en/devices/automotive/images/automotive_power_states.png
+++ b/en/devices/automotive/images/automotive_power_states.png
Binary files differ
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
diff --git a/en/devices/camera/camera3.html b/en/devices/camera/camera3.html
index bb2e6833..71e90a34 100644
--- a/en/devices/camera/camera3.html
+++ b/en/devices/camera/camera3.html
@@ -30,7 +30,7 @@ to your underlying camera driver and hardware. Android 8.0 introduced
<a href="/devices/architecture/treble">Treble</a>, switching the CameraHal API
to a stable interface defined by the HAL Interface Description Language (HIDL).
If you have previously developed a camera
-HAL module and driver for older versions of Android, be aware of significant
+HAL module and driver for Android 7.0 and lower, be aware of significant
changes in the camera pipeline.</p>
<h2 id="v3-enhance">Camera HAL3 features</h2>
@@ -84,12 +84,12 @@ may be repeated indefinitely (with <code>setRepeatingRequest()</code>). Captures
have priority over repeating requests.</p>
<img src="images/camera_simple_model.png" alt="Camera data model" id="figure2" />
-<p class="img-caption"><strong>Figure 2.</strong> Camera core operation model</p>
+<p class="img-caption"><strong>Figure 1.</strong> Camera core operation model</p>
<h2 id="overview">Camera HAL1 overview</h2>
-<aside class="note"><strong>Note:</strong> Camera HAL1 has been deprecated. New
-devices should use Camera HAL3.</aside>
+<aside class="note"><strong>Note:</strong> As Camera HAL1 has been deprecated,
+ Camera HAL3 is recommended for devices launching on Android 9 or higher.</aside>
<p>Version 1 of the camera subsystem was designed as a black box with high-level
controls and the following three operating modes:</p>
@@ -105,7 +105,7 @@ hard to implement new features such as burst mode, which falls between two of
the operating modes.</p>
<img src="images/camera_block.png" alt="Camera block diagram" id="figure1" />
-<p class="img-caption"><strong>Figure 1.</strong> Camera components</p>
+<p class="img-caption"><strong>Figure 2.</strong> Camera components</p>
<p>Android 7.0 continues to support camera HAL1 as many devices still rely on
it. In addition, the Android camera service supports implementing both HALs (1
diff --git a/en/devices/tech/debug/asan.html b/en/devices/tech/debug/asan.html
index 9ea32939..29df8b6d 100644
--- a/en/devices/tech/debug/asan.html
+++ b/en/devices/tech/debug/asan.html
@@ -44,7 +44,8 @@ HWASan is non-deterministic. There are only 256 possible tag values, so there is
probability of missing any bug. HWAsan does not have ASan's limited-size redzones for
detecting overflows and limited-capacity quarantine for detecting use-after-free,
so it does not matter to HWAsan how large the overflow is or how long ago the memory
-was deallocated. This makes HWASan better than ASan.</p>
+was deallocated. This makes HWASan better than ASan. You can read more about
+<a href="http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html" class="external">the design of HWAsan</a>.</p>
<p>Valgrind's Memcheck tool is similar, but ASan also detects stack/global overflows
in addition to heap overflows, and is much faster with less memory overhead. Conversely,
@@ -60,10 +61,15 @@ instead.</p>
<h2 id="using-hwasan">Using HWAsan</h2>
-<p>As of December 2018 only Pixel 2 and Pixel 2 XL are supported. Supporting another device
-requires backporting several kernel patches. The Android team is working on getting those into
-the common kernel.
-You may also need to remove some optional extras to make room on your system partition for the
+<p>As of February 2019 only Pixel 2 and Pixel 2 XL support HWAsan. The Android team is working on
+getting the necessary patches into the common kernel, but for now supporting another device requires
+backporting these kernel patches:</p>
+<ul>
+<li><a href="https://lore.kernel.org/patchwork/project/lkml/list/?series=375855" class="external">arm64: untag user pointers passed to the kernel</a></li>
+<li><a href="https://lore.kernel.org/patchwork/project/lkml/list/?series=375865" class="external">arm64 relaxed ABI</a></li>
+</ul>
+
+<p>You may also need to remove some optional extras to make room on your system partition for the
larger libraries. See the <code>walleye_hwasan</code> target for an example.</p>
<p>Use the following commands to build the entire platform using HWASan:</p>
diff --git a/en/devices/tech/debug/gdb.html b/en/devices/tech/debug/gdb.html
index 49d62aa3..34096fb6 100644
--- a/en/devices/tech/debug/gdb.html
+++ b/en/devices/tech/debug/gdb.html
@@ -162,5 +162,47 @@ the following property:</p>
set arm fallback-mode arm # or thumb
</pre>
+<h2 id="vscode">Debugging with VS Code</h2>
+<p>GDB supports debugging platform code on
+ <a href="https://code.visualstudio.com/" class="external">Visual Studio Code</a>.
+ You can use the
+ VS Code debugger frontend instead of the GDB CLI interface to control and
+ debug native code running on devices.</p>
+<p>Before using VS Code for debugging, make sure you install the
+ <a href="https://marketplace.visualstudio.com/items?itemName=ms-vscode.cpptools" class="external">
+ C/C++ extension</a>.</p>
+<p>To debug code using VS Code:</p>
+<ol>
+ <li>Ensure all build artifacts (such as symbols) required to run
+ <code>gdbclient.py</code> are present.</li>
+ <li>
+ <p>Run the following command:</p>
+ <pre class="prettyprint"><code class="devsite-terminal">gdbclient.py <var>-p pid | -n proc-name | -r ...</var> --setup-forwarding vscode <var>ANY_OTHER_FLAGS</var></code></pre>
+ <p>This prints a JSON object and <code>gdbclient.py</code> continues running.
+ This is expected; do not kill the <code>gdbclient.py</code> program.</p>
+ </li>
+ <li>In the debugging tab in VS Code, select
+ <strong>add configuration</strong>, then select
+ <strong>C/C++ gdb attach</strong>.
+ This opens a <code>launch.json</code> file and adds a new JSON object to a
+ list.
+ </li>
+ <li>Delete the newly added debugger configuration.</li>
+ <li>Copy the JSON object printed by <code>gdbclient.py</code> and paste it
+ into the object you just deleted. Save the changes.
+ </li>
+ <li>To reload the window to refresh the debugger list, press
+ <strong>Ctrl+Shift+P</strong> and type "reload window".
+ </li>
+ <li>Select the new debugger configuration and press
+ <strong>run</strong>. The debugger should connect after 10 to 30 seconds.
+ </li>
+ <li>When you are done debugging, go to the terminal running
+ <code>gdbclient.py</code> and press <strong>enter</strong> to end the
+ <code>gdbclient.py</code> program.
+ </li>
+</ol>
+<p>After setting up the debugger configuration for the first time,
+ you can skip steps 3 through 6.</p>
</body>
</html>
diff --git a/en/devices/tech/power/values.html b/en/devices/tech/power/values.html
index e4c68426..a2ea8388 100644
--- a/en/devices/tech/power/values.html
+++ b/en/devices/tech/power/values.html
@@ -5,6 +5,7 @@
<meta name="book_path" value="/_book.yaml" />
</head>
<body>
+ {% include "_versions.html" %}
<!--
Copyright 2017 The Android Open Source Project
@@ -104,17 +105,18 @@ sample file in AOSP, see
<th>Example Value</th>
<th>Notes</th>
</tr>
+
<tr>
- <td>none</td>
- <td>Nothing</td>
- <td>0</td>
- <td></td>
+ <td>ambient.on</td>
+ <td>Additional power used when screen is in doze/ambient/always-on mode instead of off.</td>
+ <td>around 100 mA</td>
+ <td> - </td>
</tr>
<tr>
<td>screen.on</td>
<td>Additional power used when screen is turned on at minimum brightness.</td>
- <td>200mA</td>
+ <td>200 mA</td>
<td>Includes touch controller and display backlight. At 0 brightness, not the
Android minimum which tends to be 10 or 20%.</td>
</tr>
@@ -123,7 +125,7 @@ sample file in AOSP, see
<td>screen.full</td>
<td>Additional power used when screen is at maximum brightness, compared to
screen at minimum brightness.</td>
- <td>100mA-300mA</td>
+ <td>100 mA-300 mA</td>
<td>A fraction of this value (based on screen brightness) is added to the
screen.on value to compute the power usage of the screen.</td>
</tr>
@@ -132,44 +134,43 @@ sample file in AOSP, see
<td>wifi.on</td>
<td>Additional power used when Wi-Fi is turned on but not receiving,
transmitting, or scanning.</td>
- <td>2mA</td>
- <td></td>
+ <td>2 mA</td>
+ <td> - </td>
</tr>
<tr>
<td>wifi.active</td>
<td>Additional power used when transmitting or receiving over Wi-Fi.</td>
- <td>31mA</td>
- <td></td>
+ <td>31 mA</td>
+ <td> - </td>
</tr>
<tr>
<td>wifi.scan</td>
<td>Additional power used when Wi-Fi is scanning for access points.</td>
- <td>100mA</td>
- <td></td>
+ <td>100 mA</td>
+ <td> - </td>
</tr>
<tr>
- <td>dsp.audio</td>
+ <td>audio</td>
<td>Additional power used when audio decoding/encoding via DSP.</td>
- <td>14.1mA</td>
- <td>Reserved for future use.</td>
+ <td>around 10 mA</td>
+ <td>Used for DSP audio.</td>
</tr>
-
<tr>
- <td>dsp.video</td>
+ <td>video</td>
<td>Additional power used when video decoding via DSP.</td>
- <td>54mA</td>
- <td>Reserved for future use.</td>
+ <td>around 50 mA</td>
+ <td>Used for DSP video.</td>
</tr>
<tr>
<td>camera.avg</td>
<td>Average power use by the camera subsystem for a typical camera
application.</td>
- <td>600mA</td>
+ <td>600 mA</td>
<td>Intended as a rough estimate for an application running a preview
and capturing approximately 10 full-resolution pictures per minute.</td>
</tr>
@@ -177,37 +178,44 @@ sample file in AOSP, see
<tr>
<td>camera.flashlight</td>
<td>Average power used by the camera flash module when on.</td>
- <td>200mA</td>
- <td></td>
+ <td>200 mA</td>
+ <td> - </td>
</tr>
+<tr>
+ <td>gps.signalqualitybased</td>
+ <td>Additional power used by GPS based on signal strength. This is a multi-value entry,
+ one per signal strength, from weakest to strongest.</td>
+ <td> 30 mA, 10 mA </td>
+ <td> - </td>
+</tr>
<tr>
<td>gps.on</td>
<td>Additional power used when GPS is acquiring a signal.</td>
- <td>50mA</td>
- <td></td>
+ <td>50 mA</td>
+ <td> - </td>
</tr>
<tr>
<td>radio.active</td>
<td>Additional power used when cellular radio is transmitting/receiving.</td>
- <td>100mA-300mA</td>
- <td></td>
+ <td>100 mA-300 mA</td>
+ <td> - </td>
</tr>
<tr>
<td>radio.scanning</td>
<td>Additional power used when cellular radio is paging the tower.</td>
- <td>1.2mA</td>
- <td></td>
+ <td>1.2 mA</td>
+ <td> - </td>
</tr>
<tr>
<td>radio.on</td>
- <td>Additional power used when the cellular radio is on. Multi-value entry,
+ <td>Additional power used when the cellular radio is on. This is a multi-value entry,
one per signal strength (no signal, weak, moderate, strong).</td>
- <td>1.2mA</td>
+ <td>1.2 mA</td>
<td>Some radios boost power when they search for a cell tower and do not
detect a signal. Values can be the same or decrease with increasing signal
strength. If you provide only one value, the same value is used for all
@@ -223,7 +231,7 @@ sample file in AOSP, see
the controller. If there are multiple receive or transmit states, the average
of those states is taken. In addition, the system now collects data for
<a href="#le-bt-scans">Low Energy (LE) and Bluetooth scans</a>.<br><br>Android
- N and later no longer use the Bluetooth power values for bluetooth.active
+ 7.0 and later no longer use the Bluetooth power values for bluetooth.active
(used when playing audio via Bluetooth A2DP) and bluetooth.on (used when
Bluetooth is on but idle).</td>
</tr>
@@ -247,12 +255,19 @@ sample file in AOSP, see
</tr>
<tr>
+ <td>modem.controller.sleep</td>
+ <td> Average current draw (mA) of the modem controller when asleep.</td>
+ <td> 0 mA </td>
+ <td rowspan=5>These values are not estimated, but taken from the data sheet of the controller.
+ If there are multiple receive states, the average of those states is taken. If there are
+ multiple transmit states, specifying a value for each transmit state is supported
+ starting in Android {{ androidPVersionNumber}}.</td>
+</tr>
+
+<tr>
<td>modem.controller.idle</td>
<td>Average current draw (mA) of the modem controller when idle.</td>
<td> - </td>
- <td rowspan=4>These values are not estimated, but taken from the data sheet of
- the controller. If there are multiple receive or transmit states, the average
- of those states is taken.</td>
</tr>
<tr>
@@ -263,8 +278,9 @@ sample file in AOSP, see
<tr>
<td>modem.controller.tx</td>
- <td>Average current draw (mA) of the modem controller when transmitting.</td>
- <td> - </td>
+ <td>Average current draw (mA) of the modem controller when transmitting at different RF power
+ levels. This is a multi-value entry with one value per transmit power level.</td>
+ <td> 100 mA, 200 mA, 300 mA, 400 mA, 500 mA </td>
</tr>
<tr>
@@ -302,8 +318,8 @@ sample file in AOSP, see
<tr>
<td>cpu.speeds</td>
- <td>Multi-value entry that lists each possible CPU speed in KHz.</td>
- <td>125000KHz, 250000KHz, 500000KHz, 1000000KHz, 1500000KHz</td>
+ <td>This is a multi-value entry that lists each possible CPU speed in KHz.</td>
+ <td>125000 KHz, 250000 KHz, 500000 KHz, 1000000 KHz, 1500000 KHz</td>
<td>The number and order of entries must correspond to the mA entries in
cpu.active.</td>
</tr>
@@ -312,15 +328,15 @@ sample file in AOSP, see
<td>cpu.idle</td>
<td>Total power drawn by the system when CPUs (and the SoC) are in system
suspend state.</td>
- <td>3mA</td>
- <td></td>
+ <td>3 mA</td>
+ <td> - </td>
</tr>
<tr>
<td>cpu.awake</td>
<td>Additional power used when CPUs are in scheduling idle state
(kernel idle loop); system is not in system suspend state.</td>
- <td>50mA</td>
+ <td>50 mA</td>
<td>Your platform might have more than one idle state in use with differing
levels of power consumption; choose a representative idle state for longer
periods of scheduler idle (several milliseconds). Examine the power graph on
@@ -331,7 +347,7 @@ sample file in AOSP, see
<tr>
<td>cpu.active</td>
<td>Additional power used by CPUs when running at different speeds.</td>
- <td>100mA, 120mA, 140mA, 160mA, 200mA</td>
+ <td>100 mA, 120 mA, 140 mA, 160 mA, 200 mA</td>
<td>Value represents the power used by the CPU rails when running at different
speeds. Set the max speed in the kernel to each of the allowed speeds and peg
the CPU at that speed. The number and order of entries correspond to the
@@ -352,8 +368,8 @@ sample file in AOSP, see
<tr>
<td>battery.capacity</td>
<td>Total battery capacity in mAh.</td>
- <td>3000mAh</td>
- <td></td>
+ <td>3000 mAh</td>
+ <td> - </td>
</tr>
</table>
diff --git a/en/security/bulletin/2019.html b/en/security/bulletin/2019.html
index f5e41f15..9212b8ca 100644
--- a/en/security/bulletin/2019.html
+++ b/en/security/bulletin/2019.html
@@ -196,15 +196,13 @@ Android Security Bulletins</a> homepage.</p>
-->
<tr>
<td><a href="/security/bulletin/2019-01-01.html">January 2019</a></td>
- <td>Coming soon
- <!--
+ <td>
<a href="/security/bulletin/2019-01-01.html">English</a>&nbsp;/
<a href="/security/bulletin/2019-01-01.html?hl=ja">日本語</a>&nbsp;/
<a href="/security/bulletin/2019-01-01.html?hl=ko">한국어</a>&nbsp;/
<a href="/security/bulletin/2019-01-01.html?hl=ru">ру́сский</a>&nbsp;/
<a href="/security/bulletin/2019-01-01.html?hl=zh-cn">简体中文</a>&nbsp;/
<a href="/security/bulletin/2019-01-01.html?hl=zh-tw">繁體中文&nbsp;(台灣)</a>
- -->
</td>
<td>January 7, 2019</td>
<td>2019-01-01<br>
diff --git a/en/security/bulletin/index.html b/en/security/bulletin/index.html
index ee61a610..aba83c43 100644
--- a/en/security/bulletin/index.html
+++ b/en/security/bulletin/index.html
@@ -72,15 +72,13 @@ Android Open Source Project (AOSP), the upstream Linux kernel, and system-on-chi
</tr>
<tr>
<td><a href="/security/bulletin/2019-01-01.html">January 2019</a></td>
- <td>Coming soon
- <!--
+ <td>
<a href="/security/bulletin/2019-01-01.html">English</a>&nbsp;/
<a href="/security/bulletin/2019-01-01.html?hl=ja">日本語</a>&nbsp;/
<a href="/security/bulletin/2019-01-01.html?hl=ko">한국어</a>&nbsp;/
<a href="/security/bulletin/2019-01-01.html?hl=ru">ру́сский</a>&nbsp;/
<a href="/security/bulletin/2019-01-01.html?hl=zh-cn">简体中文</a>&nbsp;/
<a href="/security/bulletin/2019-01-01.html?hl=zh-tw">繁體中文&nbsp;(台灣)</a>
- -->
</td>
<td>January 7, 2019</td>
<td>2019-01-01<br>
diff --git a/en/security/bulletin/pixel/2019.html b/en/security/bulletin/pixel/2019.html
index 65eb244d..e580dd95 100644
--- a/en/security/bulletin/pixel/2019.html
+++ b/en/security/bulletin/pixel/2019.html
@@ -185,15 +185,13 @@ Bulletins</a> homepage.</p>
-->
<tr>
<td><a href="/security/bulletin/pixel/2019-01-01.html">January 2019</a></td>
- <td>Coming soon
- <!--
+ <td>
<a href="/security/bulletin/pixel/2019-01-01.html">English</a>&nbsp;/
<a href="/security/bulletin/pixel/2019-01-01.html?hl=ja">日本語</a>&nbsp;/
<a href="/security/bulletin/pixel/2019-01-01.html?hl=ko">한국어</a>&nbsp;/
<a href="/security/bulletin/pixel/2019-01-01.html?hl=ru">ру́сский</a>&nbsp;/
<a href="/security/bulletin/pixel/2019-01-01.html?hl=zh-cn">简体中文</a>&nbsp;/
<a href="/security/bulletin/pixel/2019-01-01.html?hl=zh-tw">繁體中文&nbsp;(台灣)</a>
- -->
</td>
<td>January 7, 2019</td>
<td>2019-01-05</td>
diff --git a/en/security/bulletin/pixel/index.html b/en/security/bulletin/pixel/index.html
index 45a70c7b..d1382362 100644
--- a/en/security/bulletin/pixel/index.html
+++ b/en/security/bulletin/pixel/index.html
@@ -62,15 +62,13 @@ class="external">supported Google Pixel and Nexus devices</a> (Google devices).
</tr>
<tr>
<td><a href="/security/bulletin/pixel/2019-01-01.html">January 2019</a></td>
- <td>Coming soon
- <!--
+ <td>
<a href="/security/bulletin/pixel/2019-01-01.html">English</a>&nbsp;/
<a href="/security/bulletin/pixel/2019-01-01.html?hl=ja">日本語</a>&nbsp;/
<a href="/security/bulletin/pixel/2019-01-01.html?hl=ko">한국어</a>&nbsp;/
<a href="/security/bulletin/pixel/2019-01-01.html?hl=ru">ру́сский</a>&nbsp;/
<a href="/security/bulletin/pixel/2019-01-01.html?hl=zh-cn">简体中文</a>&nbsp;/
<a href="/security/bulletin/pixel/2019-01-01.html?hl=zh-tw">繁體中文&nbsp;(台灣)</a>
- -->
</td>
<td>January 7, 2018</td>
<td>2018-12-05</td>
diff --git a/en/security/encryption/file-based.html b/en/security/encryption/file-based.html
index d62bac19..9c7787c9 100644
--- a/en/security/encryption/file-based.html
+++ b/en/security/encryption/file-based.html
@@ -145,8 +145,8 @@ following dependencies:
<ul>
<li><strong>Kernel Support</strong> for Ext4 encryption or F2FS encryption
-(Kernel config option: <code>EXT4_FS_ENCRYPTION</code> or
-<code>F2FS_FS_ENCRYPTION</code>)
+(Kernel config option: <code>CONFIG_EXT4_ENCRYPTION</code> or
+<code>CONFIG_F2FS_FS_ENCRYPTION</code>)
<li><strong><a
href="/security/keystore/index.html">Keymaster
Support</a></strong> with a HAL version 1.0 or 2.0. There is no support for
diff --git a/en/setup/build/initializing.html b/en/setup/build/initializing.html
index 24c697ff..ef36dd07 100644
--- a/en/setup/build/initializing.html
+++ b/en/setup/build/initializing.html
@@ -332,7 +332,7 @@ hdiutil create -type SPARSE -fs 'Case-sensitive Journaled HFS+' -size 40g ~/andr
For older versions of Mac OS (10.8 or earlier), you must install Xcode from
the <a href="http://developer.apple.com/" class="external">Apple developer
site</a>. If you are not already registered as an Apple developer, you must
- must create an Apple ID to download.
+ create an Apple ID to download.
</li>
<li>Install MacPorts from
<a href="http://www.macports.org/install.php">macports.org</a>. Ensure
diff --git a/en/setup/build/known-issues.html b/en/setup/build/known-issues.html
index ef229a28..6a908c0e 100644
--- a/en/setup/build/known-issues.html
+++ b/en/setup/build/known-issues.html
@@ -32,7 +32,7 @@ fail with http errors, typically 403 or 500.</p>
<p><strong>Cause:</strong> There are quite a few possible causes, most often
related to http proxies, which have difficulties handling the
large amounts of data getting transferred.</p>
-<p><strong>Fix:</strong> While there's no general solution, using python 2.7
+<p><strong>Fix:</strong> While there's no general solution, using Python 2.7
and explicitly using <code>repo sync -j1</code> have been reported to
improve the situation for some users.</p>