diff options
Diffstat (limited to 'en/devices')
30 files changed, 345 insertions, 308 deletions
diff --git a/en/devices/accessories/headset/usb-headset-spec.html b/en/devices/accessories/headset/usb-headset-spec.html index c83f7eac..3279eee1 100644 --- a/en/devices/accessories/headset/usb-headset-spec.html +++ b/en/devices/accessories/headset/usb-headset-spec.html @@ -28,9 +28,8 @@ This documentation specifies USB headset buttons behavior to function uniformly across the Android ecosystem. Device manufacturers should also consult the <a href="/devices/audio/usb.html">USB Digital Audio</a> page for more information about USB implementation on Android -and the <a href="http://source.android.com/compatibility/android-cdd.html">Android -Compatibility Definition Document (CDD)</a> for requirements related to Android -devices. +and the <a href="/compatibility/android-cdd.html">Android Compatibility +Definition Document (CDD)</a> for requirements related to Android devices. </p> <p>There are also specifications for <a href="plug-headset-spec.html">3.5 mm headsets</a> for accessory manufacturers and diff --git a/en/devices/architecture/dto/implement.html b/en/devices/architecture/dto/implement.html index 5d10a92c..52906fc8 100644 --- a/en/devices/architecture/dto/implement.html +++ b/en/devices/architecture/dto/implement.html @@ -108,8 +108,8 @@ top of the main DT blob. Typically, 8 MB is more than enough and allows room to grow in the future if required.</p> <p>For devices that support -<a href="https://source.android.com/devices/tech/ota/ab_updates.html">seamless -(A/B) updates</a>, A/B the main DT and overlay DT partitions:</p> +<a href="/devices/tech/ota/ab_updates.html">seamless (A/B) updates</a>, A/B the +main DT and overlay DT partitions:</p> <div style="width:75%"> <div class="attempt-left"> diff --git a/en/devices/architecture/hidl/binder-ipc.html b/en/devices/architecture/hidl/binder-ipc.html index 811bc3b7..22c38a11 100644 --- a/en/devices/architecture/hidl/binder-ipc.html +++ b/en/devices/architecture/hidl/binder-ipc.html @@ -255,9 +255,8 @@ need renaming.</p> <p>To fulfill requirement 4, you must make changes in the way service names, service labels, and rules are handled.</p> -<p>For details on SELinux, see -<a href="https://source.android.com/security/selinux/">Security-Enhanced Linux -in Android</a>. For details on SELinux in Android 8.0, see +<p>For details on SELinux, see <a href="/security/selinux/">Security-Enhanced +Linux in Android</a>. For details on SELinux in Android 8.0, see <a href="/security/selinux/images/SELinux_Treble.pdf">SELinux for Android 8.0</a>.</p> diff --git a/en/devices/architecture/hidl/fmq.html b/en/devices/architecture/hidl/fmq.html index 13a79610..db4055b5 100644 --- a/en/devices/architecture/hidl/fmq.html +++ b/en/devices/architecture/hidl/fmq.html @@ -353,17 +353,17 @@ const MemRegion& getSecondRegion(); // get a reference to the second MemRegi <pre class="prettyprint"> MessageQueueSync::MemTransaction tx; if (mQueue->beginRead(dataLen, &tx)) { -auto first = tx.getFirstRegion(); -auto second = tx.getSecondRegion(); + auto first = tx.getFirstRegion(); + auto second = tx.getSecondRegion(); -foo(first.getAddress(), first.getLength()); // method that performs the data write -foo(second.getAddress(), second.getLength()); // method that performs the data write + foo(first.getAddress(), first.getLength()); // method that performs the data write + foo(second.getAddress(), second.getLength()); // method that performs the data write -if(commitWrite(dataLen) == false) { -//report error -} + if(commitWrite(dataLen) == false) { + // report error + } } else { -//report error + // report error } </pre> diff --git a/en/devices/architecture/hidl/interfaces.html b/en/devices/architecture/hidl/interfaces.html index a044abde..6fc1cb1b 100644 --- a/en/devices/architecture/hidl/interfaces.html +++ b/en/devices/architecture/hidl/interfaces.html @@ -75,7 +75,7 @@ interface in the package.</p> <h2 id=interface-def>Interface definition</h2> <p>Aside from <code>types.hal</code>, every other <code>.hal</code> file defines -an interface. For example, an interface is typically defined as follows:</p> +an interface. An interface is typically defined as follows:</p> <pre class="prettyprint"> interface IBar extends IFoo { // IFoo is another interface @@ -101,7 +101,7 @@ include:</p> <li><code>interfaceDescriptor</code></li> <li><code>notifySyspropsChanged</code></li> <li><code>linkToDeath</code></li> -<li><code>unlinkToDeath</code></li +<li><code>unlinkToDeath</code></li> <li><code>setHALInstrumentation</code></li> <li><code>getDebugInfo</code></li> <li><code>debug</code></li> @@ -136,13 +136,13 @@ For fully-qualified values, the following import cases are supported:</p> <li><strong>Whole-package imports</strong>. If the value is a package name and a version (syntax described below), then the entire package is imported into the importing entity.</li> -<li><strong>Partial imports</strong>. +<li><strong>Partial imports</strong>. If the value is: <ul> -<li>If the value is an interface, the package's <code>types.hal</code> and that -interface are imported into the importing entity.</li> -<li>If the value is an UDT defined in <code>types.hal</code>, then only that UDT -is imported into the importing entity (other types in <code>types.hal</code> are -not imported).</li> +<li>An interface, the package's <code>types.hal</code> and that interface are +imported into the importing entity.</li> +<li>A UDT defined in <code>types.hal</code>, then only that UDT is imported into +the importing entity (other types in <code>types.hal</code> are not imported). +</li> </ul> <li><strong>Types-only imports</strong>. If the value uses the syntax of a partial import described above, but with the keyword <code>types</code> instead @@ -208,7 +208,7 @@ be registered under the base HAL name and version, and under the extension's Versions are expressed in two integers, <em>major</em>.<em>minor</em>.</p> <ul> <li><strong>Major</strong> versions are not backwards compatible. Incrementing -the major version number resets the minor version to 0.</li> +the major version number resets the minor version number to 0.</li> <li><strong>Minor</strong> versions are backwards compatible. Incrementing the minor number indicates the newer version is fully backward compatible with the previous version. New data structures and methods can be added, but no existing @@ -219,10 +219,98 @@ data structures or method signatures may be changed.</li> can be present on a device simultaneously. While multiple minor versions can also be present on a device, as minor versions are backwards compatible no reason exists to support more than the latest minor version for each major -version.</p> - -<p>For more details on versioning and vendor extensions, see +version. For more details on versioning and vendor extensions, see <a href="/devices/architecture/hidl/versioning">HIDL Versioning</a>.</p> +<h2 id="interface-layout-summary">Interface layout summary</h2> +<p>This section summarizes how to manage a HIDL interface package (such as +<code>hardware/interfaces</code>) and consolidates information presented +throughout the HIDL section. Before reading, ensure you are familiar with +<a href="/devices/architecture/hidl/versioning">HIDL Versioning</a>, the hashing +concepts in <a href="/devices/architecture/hidl/hashing#hidl-gen">Hashing with +hidl-gen</a>, the details of <a href="/devices/architecture/hidl/">working with +HIDL in general</a>, and the following definitions:</p> + +<table> +<thead> +<tr> +<th width="30%">Term</th> +<th>Definition</th> +</tr> +</thead> +<tbody> +<tr> +<td>Application Binary Interface (ABI)</td> +<td>Application programming interface + any binary linkages required.</td> +</tr> +<tr> +<td>Fully-qualified name (fqName)</td> +<td>Name to distinguish a hidl type. Example: +<code>android.hardware.foo@1.0::IFoo</code>.</td> +</tr> +<tr> +<td>Package</td> +<td>Package containing a HIDL interface and types. Example: +<code>android.hardware.foo@1.0</code>.</td> +</tr> +<tr> +<td> Package root</td> +<td>Root package that contains the HIDL interfaces. Example: the HIDL interface +<code>android.hardware</code> is in the package root +<code>android.hardware.foo@1.0</code>.</td> +</tr> +<tr> +<td>Package root path</td> +<td>Location in the Android source tree where a package root maps to.</td> +</tr> +</tbody> +</table> + +<p>For more definitions, see HIDL +<a href="/devices/architecture/hidl/#terms">Terminology</a>. +</p> + +<h3 id="file-found">Every file can be found from the package root mapping and +its fully-qualified name</h3> +<p>Package roots are specified to <code>hidl-gen</code> as the argument +<code>-r android.hardware:hardware/interfaces</code>. For example, if the +package is <code>vendor.awesome.foo@1.0::IFoo</code> and <code>hidl-gen</code> +is sent <code>-r vendor.awesome:some/device/independent/path/interfaces</code>, +then the interface file should be located in +<code>$ANDROID_BUILD_TOP/some/device/independent/path/interfaces/foo/1.0/IFoo.hal</code>. +</p> +<p>In practice, it is recommended for a vendor or OEM named <code>awesome</code> +to put their standard interfaces in <code>vendor.awesome</code>. After a package +path has been selected, it must not be changed as this is baked into the ABI of +the interface.</p> + +<h3 id="package-path-mapping">Package path mapping should be unique</h3> +<p>For example, if you have <code>-rsome.package:$PATH_A</code> and +<code>-rsome.package:$PATH_B</code>, <code>$PATH_A</code> must be equal to +<code>$PATH_B</code> for a consistent interface directory (this also makes +<a href="/devices/architecture/hidl/versioning">versioning interfaces</a> much +easier).</p> + +<h3 id="package-root-version">Package root must have a versioning file</h3> +<p>If you create a package path such as +<code>-r vendor.awesome:vendor/awesome/interfaces</code>, you should also +create the file +<code>$ANDROID_BUILD_TOP/vendor/awesome/interfaces/current.txt</code>, which +should contain hashes of interfaces made using the <code>-Lhash</code> option in +<code>hidl-gen</code> (this is discussed extensively in +<a href="/devices/architecture/hidl/hashing#hidl-gen">Hashing with +hidl-gen</a>).</p> + +<aside class="caution"><strong>Caution:</strong> Manage all changes carefully! +The <a href="/devices/tech/vts/">Vendor Test Suite (VTS)</a> will fail if an +interface is not frozen, and ABI-incompatible changes to an interface will cause +framework-only OTAs to fail.</aside> + +<h3 id="interfaces-device-dependent">Interfaces go in device-independent +locations</h3> +<p>In practice, it is recommended to share interfaces between branches. This +allows for maximum code re-usage and maximum testing of code across different +devices and use cases.</p> + </body> </html> diff --git a/en/devices/architecture/index.html b/en/devices/architecture/index.html index 38f494a7..592198ff 100644 --- a/en/devices/architecture/index.html +++ b/en/devices/architecture/index.html @@ -75,7 +75,7 @@ primarily for system functionality and do not affect driver development.</p> <p>You can use any version of the kernel as long as it supports the required features (such as the binder driver). However, we recommend using the latest version of the Android kernel. For details, see -<a href="/source/building-kernels.html">Building Kernels</a>.</p> +<a href="/setup/building-kernels.html">Building Kernels</a>.</p> </body> </html> diff --git a/en/devices/architecture/kernel/modular-kernels.html b/en/devices/architecture/kernel/modular-kernels.html index 5c4b54c3..70debebe 100644 --- a/en/devices/architecture/kernel/modular-kernels.html +++ b/en/devices/architecture/kernel/modular-kernels.html @@ -181,8 +181,8 @@ mounted in Recovery mode.</li> partitions are <strong>not</strong> mounted early. In Android 8.0, to make module loading from these partitions possible, provisions have been made to mount partitions early for both -<a href="https://source.android.com/devices/tech/ota/ab_updates">non-A/B and A/B -devices</a>. This also ensures the partitions are mounted in both Android and +<a href="/devices/tech/ota/ab_updates">non-A/B and A/B devices</a>. This also +ensures the partitions are mounted in both Android and Charger modes.</p> <h3 id="android-build-system-support">Android build system support</h3> @@ -604,9 +604,9 @@ 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 SoC–specific DTB.</li> <li>Overlay DT partition should be -<a href="https://source.android.com/devices/tech/ota/ab_updates.html">A/B-ed</a> -for A/B devices. For these devices, the recovery kernel is the same as Android -kernel, but the partition must be A/B-ed as it can be updated via OTA.</li> +<a href="/devices/tech/ota/ab_updates.html">A/B-ed</a> for A/B devices. For these +devices, the recovery kernel is the same as Android kernel, but the partition +must be A/B-ed as it can be updated via OTA.</li> <li>Partition size is board–specific. <ul> <li>The DT overlay partition size depends on the device and the amount of diff --git a/en/devices/architecture/kernel/network_tests.html b/en/devices/architecture/kernel/network_tests.html index bc437ad2..39329d2b 100644 --- a/en/devices/architecture/kernel/network_tests.html +++ b/en/devices/architecture/kernel/network_tests.html @@ -45,9 +45,9 @@ Suite (CTS) tests.</p> <h2 id=using>Using the tests</h2> <p>The tests use <a href="http://user-mode-linux.sourceforge.net/">User-Mode Linux</a> to boot the -kernel as a process on a Linux host machine. See <a -href="https://source.android.com/source/initializing.html">Establishing a Build -Environment</a> for suitable operating system versions. The unit test framework +kernel as a process on a Linux host machine. See +<a href="/setup/initializing.html">Establishing a Build Environment</a> for +suitable operating system versions. The unit test framework boots the kernel with an appropriate disk image and runs the tests from the host file system. The tests are written in Python 2.x and use TAP interfaces to exercise kernel behaviour and the socket API.</p> diff --git a/en/devices/audio/latency_measurements.html b/en/devices/audio/latency_measurements.html index d8483c0c..9ec6e256 100644 --- a/en/devices/audio/latency_measurements.html +++ b/en/devices/audio/latency_measurements.html @@ -97,7 +97,7 @@ and <h2 id="measurements">Example measurements</h2> <p>The measurements listed below are specific to a -<a href="/source/build-numbers.html">build number</a>. Devices are listed in +<a href="/setup/build-numbers.html">build number</a>. Devices are listed in approximate order of initial release and by platform version; you can also <a href="#chart">view latencies in a chart</a>. The test application uses the Android native audio API based on OpenSL ES.</p> diff --git a/en/devices/bluetooth/verifying_debugging.html b/en/devices/bluetooth/verifying_debugging.html index 40fcfc34..691894b6 100644 --- a/en/devices/bluetooth/verifying_debugging.html +++ b/en/devices/bluetooth/verifying_debugging.html @@ -79,11 +79,12 @@ tools/test/connectivity/acts/tests/google/bt/pts</a></code>.</p> <h3 id="cts-tests">CTS Tests</h3> - <p>The <a href="https://source.android.com/compatibility/cts/"> - Compatibility Test Suite</a> (CTS) includes tests for the - Bluetooth stack. These are located in <code><a + <p> + The <a href="/compatibility/cts/">Compatibility Test Suite</a> (CTS) + includes tests for the Bluetooth stack. These are located in <code><a href="https://android.googlesource.com/platform/cts/+/master/apps/CtsVerifier/src/com/android/cts/verifier/bluetooth/"> - cts/apps/CtsVerifier/src/com/android/cts/verifier/bluetooth</a></code>.</p> + cts/apps/CtsVerifier/src/com/android/cts/verifier/bluetooth</a></code>. + </p> <h2 id="debugging-options">Debugging options</h2> <p>AOSP provides different methods of debugging a device's diff --git a/en/devices/sensors/sensor-stack.html b/en/devices/sensors/sensor-stack.html index 2522f02f..00c19a86 100644 --- a/en/devices/sensors/sensor-stack.html +++ b/en/devices/sensors/sensor-stack.html @@ -157,7 +157,7 @@ href="batching.html">Batching</a> for more information.</p> <p class="note"><strong>Note:</strong> To develop new ContextHub features that use new sensors or LEDs, you can also use a -<a href="/source/devices.html#neonkey">Neonkey SensorHub</a> connected to a +<a href="/setup/devices.html#neonkey">Neonkey SensorHub</a> connected to a Hikey or Hikey960 development board.</p> <p>How the sensor hub is materialized depends on the architecture. It is sometimes diff --git a/en/devices/tech/admin/testing-provision.html b/en/devices/tech/admin/testing-provision.html index af303a01..0891ffa4 100644 --- a/en/devices/tech/admin/testing-provision.html +++ b/en/devices/tech/admin/testing-provision.html @@ -32,18 +32,17 @@ for Device Administration</a>.</p> <p class=note><strong>Note:</strong> Building and running the AfW Test Harness is similar to building and running the Android -<a href="http://source.android.com/compatibility/cts/index.html">Compatibility -Test Suite (CTS)</a>.</p> +<a href="/compatibility/cts/index.html">Compatibility Test Suite (CTS)</a>.</p> <h2 id=setup_env>Setting up a development environment</h2> <p>The development environment for the AfW Test Harness is similar to Android OS. Follow the steps in -<a href="/source/requirements.html">Requirements</a> to set up a +<a href="/setup/requirements.html">Requirements</a> to set up a development machine.</p> <h2 id=download_source>Downloading source code</h2> <p>Download the AfW Test Harness source code using the steps in -<a href="/source/downloading.html">Downloading the Source</a>. The AfW +<a href="/setup/downloading.html">Downloading the Source</a>. The AfW Test Harness source code is in the <code>./test/AfwTestHarness</code> project. The branch name determines the version of AfW Test Harness to download (each Android platform has a separate version of AfW Test Harness). For Android 7.0, diff --git a/en/devices/tech/admin/testing-setup.html b/en/devices/tech/admin/testing-setup.html index 131ade86..06e4dcc1 100644 --- a/en/devices/tech/admin/testing-setup.html +++ b/en/devices/tech/admin/testing-setup.html @@ -84,7 +84,7 @@ the bug report is collected, the user is prompted to give consent to send the bug report data. Results are received by <code>DeviceAdminReceiver.onBugreport[Failed|Shared|SharingDeclined]</code>. For details on bug report contents, see -<a href="/source/read-bug-reports.html">Reading Bug Reports</a>.</p> +<a href="/setup/read-bug-reports.html">Reading Bug Reports</a>.</p> <p>In addition, device owner DPCs can also collect logs related to actions a user has taken on a managed device. Enterprise process logging is required for diff --git a/en/devices/tech/connect/images/ril-refactor-scenario-1-solution-1.png b/en/devices/tech/connect/images/ril-refactor-scenario-1-solution-1.png Binary files differindex c3b406f8..c252daad 100644 --- a/en/devices/tech/connect/images/ril-refactor-scenario-1-solution-1.png +++ b/en/devices/tech/connect/images/ril-refactor-scenario-1-solution-1.png diff --git a/en/devices/tech/connect/images/ril-refactor-scenario-1-solution-2.png b/en/devices/tech/connect/images/ril-refactor-scenario-1-solution-2.png Binary files differindex c144afcf..6871336e 100644 --- a/en/devices/tech/connect/images/ril-refactor-scenario-1-solution-2.png +++ b/en/devices/tech/connect/images/ril-refactor-scenario-1-solution-2.png diff --git a/en/devices/tech/connect/images/ril-refactor-scenario-1.png b/en/devices/tech/connect/images/ril-refactor-scenario-1.png Binary files differindex f35fec9d..2d4e4b06 100644 --- a/en/devices/tech/connect/images/ril-refactor-scenario-1.png +++ b/en/devices/tech/connect/images/ril-refactor-scenario-1.png diff --git a/en/devices/tech/connect/images/ril-refactor-scenario-2-solution.png b/en/devices/tech/connect/images/ril-refactor-scenario-2-solution.png Binary files differindex d25ace5c..565ac214 100644 --- a/en/devices/tech/connect/images/ril-refactor-scenario-2-solution.png +++ b/en/devices/tech/connect/images/ril-refactor-scenario-2-solution.png diff --git a/en/devices/tech/connect/images/ril-refactor-scenario-2.png b/en/devices/tech/connect/images/ril-refactor-scenario-2.png Binary files differindex d52c1746..85d44a51 100644 --- a/en/devices/tech/connect/images/ril-refactor-scenario-2.png +++ b/en/devices/tech/connect/images/ril-refactor-scenario-2.png diff --git a/en/devices/tech/connect/ril.html b/en/devices/tech/connect/ril.html index 6367fb1f..56e7f9b9 100644 --- a/en/devices/tech/connect/ril.html +++ b/en/devices/tech/connect/ril.html @@ -23,267 +23,209 @@ -<p>Android 7.0 included a refactoring of the Radio Interface Layer (RIL), using a set of -subfeatures to improve RIL functionality. Partner code changes are required to implement these -features, which are optional but encouraged. Refactoring changes are backward compatible, so prior -implementations of the refactored features continue to work.</p> +<p>Android 7.0 refactored the Radio Interface Layer (RIL) using a set of +features to improve RIL functionality. Partner code changes are required to +implement these features, which are optional but encouraged. Refactoring changes +are backward compatible, so prior implementations of the refactored features +continue to work.</p> -<p>The following subfeatures are included in the RIL refactoring feature. You -can implement any or all of the subfeatures:</p> +<p>RIL refactoring includes the following improvements:</p> <ul> -<li>Enhanced RIL error codes: Code can return more specific error codes -than the existing <code>GENERIC_FAILURE</code> code. This enhances error -troubleshooting by providing more specific information about the cause -of errors.</li> - -<li>Enhanced RIL versioning: The RIL versioning mechanism is enhanced to -provide more accurate and easier to configure version information.</li> - -<li>Redesigned RIL communication using wakelocks: RIL communication using -wakelocks is enhanced to improve device battery performance.</li> +<li><strong>RIL error codes.</strong> Enables specific error codes +in addition to the existing <code>GENERIC_FAILURE</code> code. This aids in +error troubleshooting by providing more specific information about the cause of +errors.</li> +<li><strong>RIL versioning.</strong> Provides more accurate and easier +to configure version information.</li> +<li><strong>RIL communication using wakelocks.</strong> Improves +device battery performance.</li> </ul> -<h2 id="examples">Examples and source</h2> - -<p>Documentation for RIL versioning is also in code comments in <a -href="https://android.googlesource.com/platform/hardware/ril/+/master/include/telephony/ril.h"><code>https://android.googlesource.com/platform/hardware/ril/+/master/include/telephony/ril.h</code></a>.</p> - -<h2 id="implementation">Implementation</h2> +<p>You can implement any or all of the above improvements. For more details, +refer to code comments on RIL versioning in +<a href="https://android.googlesource.com/platform/hardware/ril/+/master/include/telephony/ril.h"><code>https://android.googlesource.com/platform/hardware/ril/+/master/include/telephony/ril.h</code></a>.</p> -<p>The following sections describe how to implement the subfeatures of the -RIL refactoring feature.</p> - -<h3 id="errorcodes">Implementing enhanced RIL error codes</h3> - -<h4 id="errorcodes-problem">Problem</h4> +<h2 id="errorcodes">Implementing enhanced RIL error codes</h2> <p>Almost all RIL request calls can return the <code>GENERIC_FAILURE</code> error code in response to an error. This is an issue with all solicited -responses returned by the OEMs. It is difficult to debug an issue from -the bug report if the same <code>GENERIC_FAILURE</code> error code is +responses returned by the OEMs, which can make it difficult to debug an issue +from the bug report if the same <code>GENERIC_FAILURE</code> error code is returned by RIL calls for different reasons. It can take considerable time for vendors to even identify what part of the code could have returned a <code>GENERIC_FAILURE</code> code.</p> -<h4 id="errorcodes-solution">Solution</h4> - -<p>OEMs should return a distinct error code value associated -with each of the different errors that are currently categorized as -<code>GENERIC_FAILURE</code>.</p> - -<p>If OEMs do not want to publicly reveal their custom error codes, they may -return errors as a distinct set of integers (for example, from 1 to x) that -are mapped as <code>OEM_ERROR_1</code> to <code>OEM_ERROR_X</code>. The -vendor should make sure each such masked error code returned maps to a unique -error reason in their code. The purpose of doing this is -to speed up debugging RIL issues whenever generic errors are returned -by the OEM. It can take too much time to identify what exactly caused -<code>GENERIC_FAILURE</code>, and sometimes it's impossible to figure out.<p> - -<p>In <code>ril.h</code>, more error codes are -added for enums <code>RIL_LastCallFailCause</code> and -<code>RIL_DataCallFailCause</code> so that vendor code avoids returning -generic errors like <code>CALL_FAIL_ERROR_UNSPECIFIED</code> and +<p>In Android 7.x and higher, OEMs can return a distinct error code value +associated with each different error that is currently categorized as +<code>GENERIC_FAILURE</code>. OEMs that do not want to publicly reveal their +custom error codes can return errors as a distinct set of integers (such as 1 to +x) mapped as <code>OEM_ERROR_1</code> to <code>OEM_ERROR_X</code>. Vendors +should ensure each such masked error code returned maps to a unique error reason +in the code. Using specific error codes can speed up RIL debugging whenever +generic errors are returned by the OEM, as it can often take too much time to +identify the exact cause of a <code>GENERIC_FAILURE</code> error code (and +sometimes it's impossible to figure out).<p> + +<p>In addition, <code>ril.h</code> adds more error codes for the enums +<code>RIL_LastCallFailCause</code> and <code>RIL_DataCallFailCause</code> so +vendor code can avoid returning generic errors such as +<code>CALL_FAIL_ERROR_UNSPECIFIED</code> and <code>PDP_FAIL_ERROR_UNSPECIFIED</code>.</p> -<h3 id="version">Implementing enhanced RIL versioning</h3> +<h3 id="validate-error">Validating enhanced RIL error codes</h3> -<h4 id="version-problem">Problem</h4> +<p>After adding new error codes to replace the <code>GENERIC_FAILURE</code> +code, verify the new error codes are returned by the RIL call instead +of <code>GENERIC_FAILURE</code>.</p> -<p>RIL versioning is not accurate enough. The mechanism for vendors to -report their RIL version is not clear, causing vendors to report an incorrect -version. A workaround method of estimating the version is used, but it can -be inaccurate.</p> +<h2 id="version">Implementing enhanced RIL versioning</h2> -<h4 id="version-solution">Solution</h4> +<p>RIL versioning in older Android releases was problematic: the version itself +was imprecise, the mechanism for reporting a RIL version was unclear (causing +some vendors to report an incorrect version), and the workaround for estimating +the version was prone to inaccuracy.</p> -<p>There is a documented section in <code>ril.h</code> describing what a -particular RIL version value corresponds to. Each -RIL version is documented, including what changes correspond -to that version. Vendors must update their version in code when making -changes corresponding to that version, and return that version while doing +<p>In Android 7.x and higher, <code>ril.h</code> documents all RIL version +values, describes the corresponding RIL version, and lists all changes for that +version. When making changes that correspond to a RIL version, vendors must +update their version in code and return that version in <code>RIL_REGISTER</code>.</p> -<h3 id="wakelocks">Implementing redesigned RIL communication using -wakelocks</h3> - -<h4 id="wakelocks-prob-sum">Problem summary</h4> - -<p>Timed wakelocks are used in RIL communication in an imprecise way, -which negatively affects battery performance. RIL requests can be either -solicited or unsolicited. Solicited requests should be classified as one of -the following:</p> +<h3 id="validate-version">Validating enhanced RIL versioning</h3> -<ul> -<li>synchronous: Those that do not take considerable time to respond back. For -example, <code>RIL_REQUEST_GET_SIM_STATUS</code>.</li> +<p>Verify that the RIL version corresponding to your RIL code is returned +during <code>RIL_REGISTER</code> (rather than the <code>RIL_VERSION</code> +defined in <code>ril.h</code>).</p> -<li>asynchronous: Those that take considerable time to respond back. For -example, <code>RIL_REQUEST_QUERY_AVAILABLE_NETWORKS</code>.</li> -</ul> +<h2 id="wakelocks">Implementing RIL communication using wakelocks</h2> -<p>Follow these steps to implement redesigned wakelocks:</p> +<p>Timed wakelocks are used in RIL communication in an imprecise way, +which negatively affects battery performance. In Android 7.x and higher, you can +improve performance by classifying RIL requests and updating code to handle +wakelocks differently for different request types.</p> -<ol> -<li> -Classify solicited RIL commands as either synchronous or asynchronous -depending on how much time they take to respond. -<p>Here are some things to consider while making -that decision:</p> +<h3 id="classifying">Classifying RIL requests</h3> +<p>RIL requests can be either solicited or unsolicited. Vendors should further +classify solicited requests as one of the following:</p> <ul> -<li>As explained in the solution of asynchronous solicited RIL requests, -because the requests take considerable time, RIL Java releases the wakelock -after receiving ack from vendor code. This might cause the application -processor to go from idle to suspend state. When the response is available -from vendor code, RIL Java (the application processor) will re-acquire the -wakelock and process the response, and later go to idle state again. This -process of moving from idle to suspend state and back to idle can consume -a lot of power.</li> - -<li>If the response time isn't long enough then holding the wakelock and -staying in idle state for the entire time it takes to respond can be more -power efficient than going in suspend state by releasing the wakelock and -then waking up when the response arrives. So vendors should use -platform-specific power measurement to find out the threshold value of time 't' when -power consumed by staying in idle state for the entire time 't' consumes -more power than moving from idle to suspend and back to idle in same time -'t'. When that time 't' is discovered, RIL commands that take more than time -'t' can be classified as asynchronous, and the rest of the RIL commands can -be classified as synchronous.</li> -</ul> +<li><strong>synchronous</strong>. Requests that do not take considerable time to +respond back. For example, <code>RIL_REQUEST_GET_SIM_STATUS</code>.</li> + <li><strong>asynchronous</strong>. Requests that take considerable time to +respond back. For example, <code>RIL_REQUEST_QUERY_AVAILABLE_NETWORKS</code>. </li> +</ul> -<li>Understand the RIL communications scenarios described in the <a -href="#ril-comm-scenarios">RIL communication scenarios</a> section.</li> - -<li>Follow the solutions in the scenarios by modifying your code to handle -RIL solicited and unsolicited requests.</li> -</ol> - -<h4 id="ril-comm-scenarios">RIL communication scenarios</h4> - -<p>For implementation details of the functions used in the -following diagrams, see the source code of <code>ril.cpp</code>: -<code>acquireWakeLock()</code>, <code>decrementWakeLock()</code>, -<code>clearWakeLock(</code>)</p> - -<h5>Scenario 1: RIL request from Java APIs and solicited asynchronous response -to that request</h5> +<p>Asynchronous solicited RIL requests can take considerable time. After +receiving an ack from vendor code, RIL Java releases the wakelock, which might +cause the application processor to go from idle to suspend state. When the +response is available from vendor code, RIL Java (the application processor) +re-acquires the wakelock, processes the response, then returns to idle. Such +moving from idle to suspend to idle can consume a lot of power.</p> + +<p>If the response time isn't long enough, holding the wakelock and staying in +idle for the entire time it takes to respond can be more power efficient than +going into suspend state by releasing the wakelock and waking when the response +arrives. Vendors should use platform-specific power measurements to determine +the threshold value of time <var>T</var> when the power consumed by +staying in idle for the entire time <var>T</var> is greater than the power +consumed by moving from idle to suspend and to idle in same time <var>T</var>. +When time <var>T</var> is known, RIL commands that take more than time +<var>T</var> can be classified as asynchronous and the remaining commands +classified as synchronous.</p> + +<h3 id="ril-comm-scenarios">RIL communication scenarios</h3> +<p>The following diagrams illustrate common RIL communication scenarios and +provide solutions for modifying code to handle RIL solicited and unsolicited +requests.</p> + +<p class="note"><strong>Note:</strong> For implementation details on functions +used in the following diagrams, refer to the <code>acquireWakeLock()</code>, +<code>decrementWakeLock()</code>, and <code>clearWakeLock(</code>) methods in +<code>ril.cpp</code>.</p> + +<h4>Scenario: RIL request and solicited asynchronous response</h4> + +<p>In this scenario, if the RIL solicited response is expected to take +considerable time (i.e. a response to +<code>RIL_REQUEST_GET_AVAILABLE_NETWORKS</code>), the wakelock is held for a +long time on the application processor side. Modem problems can also result in a +long wait.</p> <p><img src="images/ril-refactor-scenario-1.png"></p> +<figcaption><strong>Figure 1.</strong> RIL solicited asynchronous +response.</figcaption> -<h6>Problem</h6> - -<p>If the RIL solicited response is expected to take considerable time (for -example, <code>RIL_REQUEST_GET_AVAILABLE_NETWORKS</code>), then wakelock -is held for a long time on the Application processor side, which is a -problem. Also, modem problems result in a long wait.</p> - -<h6>Solution part 1</h6> - -<p>In this scenario, wakelock equivalent is held by Modem code (RIL request -and asynchronous response back).</p> +<p><strong>Solution 1:</strong> The modem holds the wakelock for the RIL request +and asynchronous response.</p> <p><img src="images/ril-refactor-scenario-1-solution-1.png"></p> - -<p>As shown in the above sequence diagram:</p> +<figcaption><strong>Figure 2.</strong> Wakelock held by modem.</figcaption> <ol> -<li>RIL request is sent, and the modem needs to acquire wakelock to process -the request.</li> - -<li>The modem code sends acknowledgement that causes the Java side to decrement -the wakelock counter and release it if the wakelock counter value is 0.</li> - -<li>After the modem processes the request, it sends an interrupt to the -vendor code that acquires wakelock and sends a response to ril.cpp. ril.cpp -then acquires wakelock and sends a response to the Java side.</li> - -<li>When the response reaches the Java side, wakelock is acquired and response -is sent back to caller.</li> - -<li>After that response is processed by all modules, acknowledgement is -sent back to <code>ril.cpp</code> over a socket. <code>ril.cpp</code> then -releases the wakelock that was acquired in step 3.</li> +<li>RIL request is sent and the modem acquires wakelock to process that +request.</li> +<li>Modem sends acknowledgement that causes the Java side to decrement +the wakelock counter and release it when the counter value is 0. +<p class="note"><strong>Note:</strong> The wakelock timeout duration for the +request-ack sequence would be smallerthan the currently used timeout duration +because the ack should be received fairly quickly.</p> +</li> +<li>After processing the request, the modem sends an interrupt to the vendor +code that acquires wakelock and sends a response to ril.cpp, which in turn +acquires wakelock and sends a response to the Java side.</li> +<li>When the response reaches the Java side, wakelock is acquired and a response +is returned to the caller.</li> +<li>After the response is processed by all modules, acknowledgement is +sent (via socket) back to <code>ril.cpp</code>, which then releases the wakelock +acquired in step 3.</li> </ol> -<p>Note that the wakelock timeout duration for the request-ack sequence -would be smaller than the currently used timeout duration because the ack -should be received back fairly quickly.</p> - -<h6>Solution part 2</h6> - -<p>In this scenario, wakelock is not held by modem and response is quick -(synchronous RIL request and response).</p> +<p><strong>Solution 2:</strong> The modem does not hold the wakelock and the +response is quick (synchronous RIL request and response). The synchronous vs. +asynchronous behavior is hardcoded for a specific RIL command and decided on a +call-by-callbasis.</p> <p><img src="images/ril-refactor-scenario-1-solution-2.png"></p> - -<p>As shown in the above sequence diagram:</p> +<figcaption><strong>Figure 3.</strong> Wakelock not held by modem.</figcaption> <ol> <li>RIL request is sent by calling <code>acquireWakeLock()</code> on the Java side.</li> - <li>Vendor code doesn't need to acquire wakelock and can process the request and respond quickly.</li> - <li>When the response is received by the Java side, <code>decrementWakeLock()</code> is called, which decreases wakelock counter and releases wakelock if the counter value is 0.</li> </ol> -<p>Note that this synchronous vs. asynchronous behavior is hardcoded for a -particular RIL command and decided on a call-by-call basis.</p> - -<h5>Scenario 2: RIL unsolicited response</h5> +<h4>Scenario: RIL unsolicited response</h4> +<p>In this scenario, RIL unsolicited responses have a wakelock type flag in the +that indicates whether a wakelock needs to be acquired for the vendor response. +If the flag is set, a timed wakelock is set and the response is sent over a +socket to the Java side. When the timer expires, the wakelock is released. The +timed wakelock could be too long or too short for different RIL unsolicited +responses.</p> <p><img src="images/ril-refactor-scenario-2.png"></p> +<figcaption><strong>Figure 4.</strong> RIL unsolicited response.</figcaption> -<p>As shown in the above diagram, RIL unsolicited responses have a wakelock -type flag in the response that indicates whether a wakelock needs to be -acquired or not for the particular response received from the vendor. If -the flag is set, then a timed wakelock is set and response is sent over a -socket to the Java side. When the timer expires, the wakelock is released.</p> - -<h6>Problem</h6> - -<p>The timed wakelock illustrated in Scenario 2 could be too long or too -short for different RIL unsolicited responses.</p> - -<h6>Solution</h6> +<p><strong>Solution:</strong> An acknowledgement is sent from the Java code to +the native side (<code>ril.cpp</code>) instead of holding a timed wakelock on +the native side while sending an unsolicited response.</p> <p><img src="images/ril-refactor-scenario-2-solution.png"></p> +<figcaption><strong>Figure 5.</strong> Using ack instead of timed wakelock. +</figcaption> -<p>As shown, the problem can be solved by sending an acknowledgement from -the Java code to the native side (<code>ril.cpp</code>), instead of holding -a timed wakelock on the native side while sending an unsolicited response.</p> - -<h2 id="validation">Validation</h2> - -<p>The following sections describe how to validate the implementation of -the RIL refactoring feature's subfeatures.</p> - -<h3 id="validate-error">Validating enhanced RIL error codes</h3> - -<p>After adding new error codes to replace the <code>GENERIC_FAILURE</code> -code, verify that the new error codes are returned by the RIL call instead -of <code>GENERIC_FAILURE</code>.</p> - -<h3 id="validate-version">Validating enhanced RIL versioning</h3> - -<p>Verify that the RIL version corresponding to your RIL code is returned -during <code>RIL_REGISTER</code> rather than the <code>RIL_VERSION</code> -defined in <code>ril.h</code>.</p> <h3 id="validate-wakelocks">Validating redesigned wakelocks</h3> -<p>Verify that RIL calls are identified as synchronous or asynchronous.</p> - -<p>Because battery power consumption can be hardware/platform dependent, -vendors should do some internal testing to find out if using the new wakelock -semantics for asynchronous calls leads to battery power savings.</p> +<p>Verify that RIL calls are identified as synchronous or asynchronous. Because +battery power consumption can be hardware/platform dependent, vendors should do +some internal testing to find out if using the new wakelock semantics for +asynchronous calls leads to battery power savings.</p> </body> </html> diff --git a/en/devices/tech/dalvik/configure.html b/en/devices/tech/dalvik/configure.html index b7e80e18..6a5fa86e 100644 --- a/en/devices/tech/dalvik/configure.html +++ b/en/devices/tech/dalvik/configure.html @@ -27,11 +27,9 @@ include configuration of pre-compilation of the system image, dex2oat compilation options, and how to trade off system partition space, data partition space, and performance.</p> -<p>See <a href="http://source.android.com/devices/tech/dalvik/index.html">ART -and Dalvik</a>, the <a -href="http://source.android.com/devices/tech/dalvik/dex-format.html">Dalvik -Executable format</a>, and the remaining pages on source.android.com to work -with ART. See <a +<p>See <a href="/devices/tech/dalvik/index.html">ART and Dalvik</a>, the <a +href="/devices/tech/dalvik/dex-format.html">Dalvik Executable format</a>, and the +remaining pages on source.android.com to work with ART. See <a href="http://developer.android.com/guide/practices/verifying-apps-art.html">Verifying App Behavior on the Android Runtime (ART)</a> to ensure your apps work properly.</p> diff --git a/en/devices/tech/dalvik/index.html b/en/devices/tech/dalvik/index.html index 2c84a8e5..5604d6a6 100644 --- a/en/devices/tech/dalvik/index.html +++ b/en/devices/tech/dalvik/index.html @@ -46,11 +46,11 @@ performance. ART also has tighter install-time verification than Dalvik.</p> <p>At install time, ART compiles apps using the on-device <strong>dex2oat</strong> tool. This utility accepts <a -href="http://source.android.com/devices/tech/dalvik/dex-format.html">DEX</a> files as input and -generates a compiled app executable for the target device. The utility should be -able to compile all valid DEX files without difficulty. However, some -post-processing tools produce invalid files that may be tolerated by Dalvik but -cannot be compiled by ART. For more information, see <a +href="/devices/tech/dalvik/dex-format.html">DEX</a> files as input and generates +a compiled app executable for the target device. The utility should be able to +compile all valid DEX files without difficulty. However, some post-processing +tools produce invalid files that may be tolerated by Dalvik but cannot be +compiled by ART. For more information, see <a href="http://developer.android.com/guide/practices/verifying-apps-art.html#GC_Migration">Addressing Garbage Collection Issues</a>.</p> @@ -144,7 +144,7 @@ by including both Java and native stack information. </p> <h2 id="Reporting_Problems">Reporting Problems</h2> <p>If you run into any issues that aren’t due to app JNI issues, please report -them through the <a href="/source/report-bugs#platform">Android Open Source +them through the <a href="/setup/report-bugs#platform">Android Open Source Project Issue Tracker</a>. Include an <code>adb bugreport</code> and link to the app in Google Play store if available. Otherwise, if possible, attach an APK that reproduces the issue.</p> diff --git a/en/devices/tech/debug/index.html b/en/devices/tech/debug/index.html index 1c493637..90922b0b 100644 --- a/en/devices/tech/debug/index.html +++ b/en/devices/tech/debug/index.html @@ -159,7 +159,7 @@ directly without taking up anywhere near as much space as an unstripped version. <p>You can also <code>stack</code> an entire tombstone. Example:</p> <pre class="devsite-terminal devsite-click-to-copy"> -stack < FS/data/tombstones/tombstone_05</code> +stack < FS/data/tombstones/tombstone_05 </pre> <p>This is useful if you've just unzipped a bugreport in the current directory. For more information about diagnosing native crashes and tombstones, see diff --git a/en/devices/tech/debug/kasan-kcov.html b/en/devices/tech/debug/kasan-kcov.html index 20ba7fce..438cd027 100644 --- a/en/devices/tech/debug/kasan-kcov.html +++ b/en/devices/tech/debug/kasan-kcov.html @@ -49,16 +49,16 @@ Pixel's kernel source to boot with KASAN and KCOV turned on. environment</h2> <p> Follow the steps in the <a -href="/source/requirements">Downloading and +href="/setup/requirements">Downloading and Building</a> section to set up your build environment. </p> <h2 id="building-aosp">Building AOSP</h2> <p> -Download the <a href="/source/downloading">Android source code</a>. For the +Download the <a href="/setup/downloading">Android source code</a>. For the purpose of building KASAN images, choose a stable build that is not in active development. Often, the latest available release/stable branch is a good choice. More information about build and branch can be found at <a -href="/source/build-numbers#source-code-tags-and-builds">Source +href="/setup/build-numbers#source-code-tags-and-builds">Source Code Tags and Builds</a>. </p> @@ -72,13 +72,13 @@ downloaded tarballs, run the scripts they contain, and accept the licenses. </p> <aside class="note"> <strong>Tip</strong>: Double check that you have the <a -href="/source/initializing#installing-the-jdk">right +href="/setup/initializing#installing-the-jdk">right version of JDK</a> installed on your system before proceeding further. </aside> <p> Then clean up, set up your build environment, and choose your build target, following the steps in -<a href="/source/building#cleaning-up">Preparing to Build</a>. +<a href="/setup/building#cleaning-up">Preparing to Build</a>. </p> <p> @@ -255,7 +255,7 @@ kernel. </p> <h3 id="reconfiguring-the-kernel">Reconfiguring the kernel</h3> <p> -Set up your <a href="/source/building-kernels#building">build environment</a>. +Set up your <a href="/setup/building-kernels#building">build environment</a>. Build your modified <code>defconfig</code> and check if the newly added flags are present in the produced <code>.config</code> file. </p> @@ -363,7 +363,7 @@ index 31533fb9..81caf05d 100644 If you do not wish to modify the <code>BoardConfig.mk</code> file, you could instead create a new lunch target that contains the name <code>marlin_kasan</code>. For more information about this process, see -<a href="/source/add-device">Adding a New Device</a>. +<a href="/setup/add-device">Adding a New Device</a>. </p> <h3 id="adjusting-the-kernel-target-in-the-local-makefile">Adjusting the kernel diff --git a/en/devices/tech/display/circular-icons.html b/en/devices/tech/display/circular-icons.html index eed152a9..9e9c71e5 100644 --- a/en/devices/tech/display/circular-icons.html +++ b/en/devices/tech/display/circular-icons.html @@ -28,7 +28,7 @@ icons</a> are supported in Android 7.1.1 and later. Circular launcher icons are not enabled by default. To use circular icons in your device implementation, you must edit the <a - href="/source/add-device.html#use-resource-overlays">resource + href="/setup/add-device.html#use-resource-overlays">resource overlay</a> on your device to enable them.</p> <p>The resource file you are using an overlay on is at: diff --git a/en/devices/tech/ota/device_code.html b/en/devices/tech/ota/device_code.html index 98f37f0f..3b3d9d6c 100644 --- a/en/devices/tech/ota/device_code.html +++ b/en/devices/tech/ota/device_code.html @@ -121,7 +121,7 @@ format</a>.</p> Things console to have the images included in the selected product.</p> <p class="note"><strong>Note:</strong> These images must meet Android <a -href="/source/brands">brand guidelines</a>.</p> +href="/setup/brands">brand guidelines</a>.</p> <h2 id="recovery-ui">Recovery UI</h2> <p>To support devices with different available hardware (physical buttons, diff --git a/en/devices/tech/power/mgmt.html b/en/devices/tech/power/mgmt.html index 7dd0862b..c54821f0 100644 --- a/en/devices/tech/power/mgmt.html +++ b/en/devices/tech/power/mgmt.html @@ -35,8 +35,9 @@ access and deferring syncs and jobs for those applications.</li> <li><a href="#doze">Doze</a>. The platform can enter a state of deep sleep (periodically resuming normal operations) if users have not actively used their device (screen off and stationary) for extended periods of time. -Android 7.0 and later also enables Doze to trigger a lighter set of optimizations when -users turn off the device screen yet continue to move around.</li> +Android 7.0 and higher also enables Doze to trigger a lighter set of +optimizations when users turn off the device screen yet continue to move around. +</li> <li><a href="#exempt-apps">Exemptions</a>. System apps and cloud messaging services preloaded on a device are typically exempted from App Standby and Doze by default (although app developers can intent their @@ -95,7 +96,8 @@ a period of time. </p> <h3 id=testing_app_standby>Testing App Standby</h3> -<p>You can manually test App Standby using the following <code>adb</code> commands:</p> +<p>You can manually test App Standby using the following <code>adb</code> +commands:</p> <pre class="devsite-click-to-copy"> <code class="devsite-terminal">adb shell dumpsys battery unplug</code> @@ -110,37 +112,39 @@ a period of time. network activity when a device is unused for long periods.</p> <p>Idle devices in Doze periodically enter a maintenance window, during which -apps can complete pending activities (syncs, jobs, etc.). Doze then resumes sleep -for a longer period of time, followed by another maintenance window. The +apps can complete pending activities (syncs, jobs, etc.). Doze then resumes +sleep for a longer period of time, followed by another maintenance window. The platform continues the Doze sleep/maintenance sequence, increasing the length of idle each time, until a maximum of a few hours of sleep time is reached. At all times, a device in Doze remains aware of motion and immediately leaves Doze if motion is detected.</p> -<p>Android 7.0 and later extends Doze to trigger a lighter set of optimizations every time -a user turns off the device screen, even when the user continues to move around, -enabling longer lasting battery life.</p> +<p>Android 7.0 and higher extends Doze to trigger a lighter set of optimizations +every time a user turns off the device screen, even when the user continues to +move around, enabling longer lasting battery life.</p> <p>System services (such as telephony) may be preloaded and exempted from Doze by default. Users can also exempt specific applications from Doze in the -Settings menu. By default, Doze is <strong>disabled</strong> in AOSP; for details on -enabling Doze, see <a href="#integrate-doze">Integrating Doze</a>.</p> +Settings menu. By default, Doze is <strong>disabled</strong> in AOSP; for +details on enabling Doze, see <a href="#integrate-doze">Integrating Doze</a>. +</p> <h3 id="doze-reqs">Doze requirements</h3> <p>Doze support requires the device has a cloud messaging service, such as -<a href="https://developers.google.com/cloud-messaging/">Google Cloud Messaging -(GCM)</a>. This enables the device to know when to wake from Doze.</p> +<a href="https://firebase.google.com/docs/cloud-messaging/">Firebase Cloud +Messaging (FCM)</a>. This enables the device to know when to wake from Doze.</p> + <p>Full Doze support also requires a <a href="/devices/sensors/sensor-types.html#significant_motion">Significant Motion Detector (SMD)</a> on the device; however, the lightweight Doze mode in -Android 7.0 and later does not require an SMD. If Doze is enabled on a device that:</p> +Android 7.0 and higher does not require an SMD. If Doze is enabled on a device +that:</p> <ul> <li>Has an SMD, full Doze optimizations occur (includes lightweight optimizations).</li> <li>Does not have an SMD, only the lightweight Doze optimizations occur.</li> </ul> - <h3 id="doze-life">Doze lifecycle</h3> <p>Doze begins when the platform detects the device is idle and @@ -193,11 +197,12 @@ they can complete their processing.</li> </tbody> </table> -<p>Android 7.0 and later extends Doze by enabling a lightweight sleep mode during screen -off, before the device is idle.</p> +<p>Android 7.0 and higher extends Doze by enabling a lightweight sleep mode +during screen off, before the device is idle.</p> + <p><img src="/devices/tech/images/doze_lightweight.png"></p> -<p class="img-caption">Figure 1. Doze modes for non-stationary and stationary -devices.</p> +<figcaption><strong>Figure 1.</strong> Doze modes for non-stationary and +stationary devices.</figcaption> <table> <tbody> @@ -218,14 +223,16 @@ devices.</p> </tr> <tr> <td>Restrictions</td> -<td>No network access, wake lock, or GPS/Wi-FI scan. Alarms and jobs/syncs deferred.</td> -<td>No network access. Jobs/syncs deferred except during maintenance windows.</td> +<td>No network access, wake lock, or GPS/Wi-FI scan. Alarms and jobs/syncs +deferred.</td> +<td>No network access. Jobs/syncs deferred except during maintenance windows. +</td> </tr> <tr> <td>Behavior</td> <td>Only high-priority push notification messages received.</td> -<td>All real-time messages (instant messages, calls, etc.) received. High-priority push - notification message enables temporary network access.</td> +<td>All real-time messages (instant messages, calls, etc.) received. +High-priority push notification message enables temporary network access.</td> </tr> <tr> <td>Exit</td> @@ -279,14 +286,14 @@ optimizing applications</a>. <h4 id="doze-tips">Tips</h4> <ul> -<li>If possible, use GCM for -<a href="https://developers.google.com/cloud-messaging/downstream">downstream +<li>If possible, use FCM for +<a href="https://firebase.google.com/docs/cloud-messaging/http-server-ref#send-downstream">downstream messaging</a>.</li> <li>If your users must see a notification right away, use a -<a href="https://developers.google.com/cloud-messaging/concept-options#setting-the-priority-of-a-message">GCM +<a href="https://firebase.google.com/docs/cloud-messaging/concept-options#setting-the-priority-of-a-message">FCM high priority message</a>.</li> <li>Provide sufficient information within the initial -<a href="https://developers.google.com/cloud-messaging/concept-options#payload">message +<a href="https://firebase.google.com/docs/cloud-messaging/concept-options#notifications_and_data_messages">message payload</a> (to avoid unnecessary subsequent network access).</li> <li>Set critical alarms with <a href="http://developer.android.com/reference/android/app/AlarmManager.html#setAndAllowWhileIdle(int,%20long,%20android.app.PendingIntent)">setAndAllowWhileIdle()</a> @@ -309,9 +316,9 @@ mode.</p> <p>You can exempt applications from being subject to Doze or App Standby. Exemptions may be needed in the following use cases:</p> <ul> -<li>OEM using non-GCM Cloud Messaging platform</li> -<li>Carrier using non-GCM Cloud Messaging platform</li> -<li>Third-party application using non-GCM Cloud Messaging platform</li> +<li>OEM using non-FCM Cloud Messaging platform</li> +<li>Carrier using non-FCM Cloud Messaging platform</li> +<li>Third-party application using non-FCM Cloud Messaging platform</li> </ul> <p class="warning"><strong>Warning</strong>: Do not exempt apps to avoid testing @@ -325,14 +332,15 @@ these reasons, we strongly recommend that you do not exempt third-party applications and instead exempt only cloud messaging services or apps with similar functions.</p> -<p>Apps exempted by default are listed in a single view in <em>Settings > Battery</em>. -This list is used for exempting the app from both Doze and App +<p>Apps exempted by default are listed in a single view in <em>Settings > +Battery</em>. This list is used for exempting the app from both Doze and App Standby modes. To provide transparency to the user, the Settings menu <strong>MUST</strong> show all exempted applications.</p> -<p>Users can manually exempt apps via <em>Settings > Battery > Battery optimization > All apps</em> -and then selecting the app to turn off (or back on) optimization. However, users cannot unexempt -any application or service that is exempted by default in the system image.</p> +<p>Users can manually exempt apps via <em>Settings > Battery > Battery +optimization > All apps</em> and then selecting the app to turn off (or back on) +optimization. However, users cannot unexempt any application or service that is +exempted by default in the system image.</p> </body> </html> diff --git a/en/devices/tech/test_infra/tradefed/full_example.html b/en/devices/tech/test_infra/tradefed/full_example.html index 0d3574e1..a6527aa0 100644 --- a/en/devices/tech/test_infra/tradefed/full_example.html +++ b/en/devices/tech/test_infra/tradefed/full_example.html @@ -507,7 +507,7 @@ tf> run example/helloworld --log-level-display info <a href="https://android.googlesource.com/platform/tools/tradefederation/+/master">Trade Federation source code</a> has a lot of useful information that isn't exposed in the documentation. If all else fails, try asking on the -<a href="/source/community.html">android-platform</a> Google Group, +<a href="/setup/community.html">android-platform</a> Google Group, with "Trade Federation" in the message subject.</p> </body> diff --git a/en/devices/tech/test_infra/tradefed/fundamentals/index.html b/en/devices/tech/test_infra/tradefed/fundamentals/index.html index f4d83f1b..c7958648 100644 --- a/en/devices/tech/test_infra/tradefed/fundamentals/index.html +++ b/en/devices/tech/test_infra/tradefed/fundamentals/index.html @@ -76,7 +76,7 @@ things that aren't directly discussed in the documentation.</p> <p>If you've gotten through everything here and still have unanswered questions, first try taking a look at the <a href="https://android.googlesource.com/platform/tools/tradefederation/+/master" >Trade Federation source code</a>. Beyond that, feel free to try asking on the -<a href="/source/community.html">android-platform</a> Google Group. For best results, make +<a href="/setup/community.html">android-platform</a> Google Group. For best results, make sure to mention "Trade Federation" (or "tradefed", or "TF") in the message subject.</p> diff --git a/en/devices/tech/test_infra/tradefed/fundamentals/machine_setup.html b/en/devices/tech/test_infra/tradefed/fundamentals/machine_setup.html index 47b99bde..a15c4333 100644 --- a/en/devices/tech/test_infra/tradefed/fundamentals/machine_setup.html +++ b/en/devices/tech/test_infra/tradefed/fundamentals/machine_setup.html @@ -23,7 +23,7 @@ <p> Trade Federation is distributed with the AOSP and uses the Android build system - to create its binary. Make sure you've <a href="/source/initializing.html" + to create its binary. Make sure you've <a href="/setup/initializing.html" >established a build environment</a> to compile and run packages from the Android source tree. </p> diff --git a/en/devices/tv/reference-tv-app.html b/en/devices/tv/reference-tv-app.html index 7a35de56..a8a5105f 100644 --- a/en/devices/tv/reference-tv-app.html +++ b/en/devices/tv/reference-tv-app.html @@ -123,7 +123,10 @@ adb push $OUT/system/priv-app/LiveTv/LiveTv.apk /system/priv-app/LiveTv/ <p>Once Live TV is on your device, you should test that it is properly -integrated. In addition to running the <a href="/compatibility/cts/index.html">Compatibility test suite</a> and the <a href="http://source.android.com/compatibility/cts/verifier.html">CTS Verifier tests</a> for the TV app, you can use these tests below:</p> +integrated. In addition to running the <a +href="/compatibility/cts/index.html">Compatibility test suite</a> and the <a +href="/compatibility/cts/verifier.html">CTS Verifier tests</a> for the TV app, +you can use these tests below:</p> <h3 id=unit_tests>Unit tests</h3> |
