diff options
| author | android-build-team Robot <android-build-team-robot@google.com> | 2017-06-21 07:33:12 +0000 |
|---|---|---|
| committer | android-build-team Robot <android-build-team-robot@google.com> | 2017-06-21 07:33:12 +0000 |
| commit | c3f0998625979beb0ad8ac401e746ade54e0b5a1 (patch) | |
| tree | 9d32c0a36693b9ce3d89bd10152cd3a2564f486e | |
| parent | a7614f063c573514e9d4a207bf245ba288f9ec6a (diff) | |
| parent | d9c0a94dd500fc616309192152fa737a83c185d8 (diff) | |
| download | source.android.com-c3f0998625979beb0ad8ac401e746ade54e0b5a1.tar.gz | |
release-request-d1418208-3b0b-4ef9-a2f0-a8f8ac6c24e8-for-git_oc-mr1-release-4120176 snap-temp-L55000000076156472
Change-Id: I43c2a7cdc07044ac08e8cd36c8df7a403b8035bc
104 files changed, 1963 insertions, 1456 deletions
diff --git a/OWNERS b/OWNERS deleted file mode 100644 index bb3433d0..00000000 --- a/OWNERS +++ /dev/null @@ -1,6 +0,0 @@ -claym@google.com -daroberts@google.com -delphij@google.com -gdimino@google.com -hvm@google.com -unsuk@google.com diff --git a/en/compatibility/cts/camera-hal.html b/en/compatibility/cts/camera-hal.html index 1c63ab7b..0b42a34f 100644 --- a/en/compatibility/cts/camera-hal.html +++ b/en/compatibility/cts/camera-hal.html @@ -102,10 +102,10 @@ tests.</p> <p>To set up these tests:</p> -<pre> -$ cd hardware/libhardware/tests/camera*/ -$ mm -$ adb remount; adb sync +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">cd hardware/libhardware/tests/camera*/</code> +<code class="devsite-terminal">mm</code> +<code class="devsite-terminal">adb remount; adb sync</code> </pre> <h3 id=hal_3_x_tests>[ ] 3.1. HAL 3.x tests</h3> @@ -115,8 +115,8 @@ $ adb remount; adb sync <p>To run all tests:</p> -<pre> -$ adb shell /data/nativetest/camera3_test/camera3_test +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell /data/nativetest/camera3_test/camera3_test </pre> <p>You receive an <strong>OK</strong> for each passed test. Errors are logged @@ -129,24 +129,22 @@ at the end of output along with a summary of tests passed.</p> <p>To run all tests:</p> -<pre> -$ adb shell /data/nativetest/camera3_test/camera3_test +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell /data/nativetest/camera3_test/camera3_test </pre> <p>To run a single test, pass the <code>--gtest_filter</code> argument and the test name, like so:</p> -<pre> -$ adb shell /data/nativetest/camera2_test/camera2_test \ ---gtest_filter=Camera2Test.OpenClose +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell /data/nativetest/camera2_test/camera2_test --gtest_filter=Camera2Test.OpenClose </pre> <p>To run a subset of tests, use a wildcard with the <code>--gtest_filter</code> argument, like so:</p> -<pre> -$ adb shell /data/nativetest/camera2_test/camera2_test \ ---gtest_filter=Camera2Test.* +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell /data/nativetest/camera2_test/camera2_test --gtest_filter=Camera2Test.* </pre> <h3 id=3_tests_that_interact_with_the_camera_service>[ ] 3.3. Tests that @@ -213,11 +211,11 @@ to communicate.</p> instructions on how to set up and run the tests. For setup: <code>make cts</code></p> -<pre> -$ extract root/out/host/linux-x86/cts-verfier/android-cts-verifier.zip -$ cd android-cts-verifier -$ adb install -r CtsVerifier.apk -$ cd CameraITS +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">extract root/out/host/linux-x86/cts-verfier/android-cts-verifier.zip</code> +<code class="devsite-terminal">cd android-cts-verifier</code> +<code class="devsite-terminal">adb install -r CtsVerifier.apk</code> +<code class="devsite-terminal">cd CameraITS</code> </pre> <p>See <code>tutorial.py</code> in the <code>tests</code> subdirectory for a @@ -338,9 +336,9 @@ to install the resulting .apk. Example commands are included below.</p> <p>To set up these tests:</p> -<pre> -$ make mediaframeworktest -$ adb install out/target/product/<em><name></em>/data/app/mediaframeworktest.apk +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">make mediaframeworktest</code> +<code class="devsite-terminal">adb install out/target/product/<em><name></em>/data/app/mediaframeworktest.apk</code> </pre> <p>Where the <em><code><name></code></em> variable represents the directory @@ -348,7 +346,7 @@ containing the vendor's product.</p> <p>Find all of the tests in the following directory or its subdirectories:</p> -<pre> +<pre class="devsite-click-to-copy"> frameworks/base/media/tests/MediaFrameworkTest/src/com/android/mediaframeworktest </pre> @@ -367,13 +365,13 @@ frameworks/base/media/tests/MediaFrameworkTest/src/com/android/mediaframeworktes <p>To see all of the available tests::</p> -<pre> -$ adb shell pm list instrumentation +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell pm list instrumentation </pre> <p>This will yield results resembling:</p> -<pre> +<pre class="devsite-click-to-copy"> instrumentation:com.android.mediaframeworktest/.MediaFrameworkIntegrationTestRunner (target=com.android.mediaframeworktest) instrumentation:com.android.mediaframeworktest/.MediaRecorderStressTestRunner @@ -392,7 +390,7 @@ The component is composed of the target package name <p>For instance:</p> -<pre> +<pre class="devsite-click-to-copy"> com.android.mediaframeworktest/.MediaFrameworkIntegrationTestRunner com.android.mediaframeworktest/.MediaRecorderStressTestRunner com.android.mediaframeworktest/.MediaFrameworkPerfTestRunner @@ -401,15 +399,14 @@ com.android.mediaframeworktest/.MediaFrameworkPowerTestRunner <p>You may then pass each component to <code>adb shell am instrument</code> like so:</p> -<pre> -$ adb shell am instrument -w <component.name> +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell am instrument -w <component.name> </pre> <p>Where the <component.name> equals the extracted value above. For example:</p> -<pre> -$ adb shell am instrument -w \ -com.android.mediaframeworktest/.MediaFrameworkIntegrationTestRunner +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell am instrument -w com.android.mediaframeworktest/.MediaFrameworkIntegrationTestRunner </pre> <p>Please note, while the class path is the Java package + class name, the @@ -420,19 +417,15 @@ name, not the Java package in which the test runner class resides.</p> <p>To run a single class of tests, pass the -e class <test-class> argument, like so:</p> -<pre> -$ adb shell am instrument -e class \ -com.android.mediaframeworktest.integration.CameraBinderTest -w \ -com.android.mediaframeworktest/.MediaFrameworkIntegrationTestRunner +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell am instrument -e class com.android.mediaframeworktest.integration.CameraBinderTest -w com.android.mediaframeworktest/.MediaFrameworkIntegrationTestRunner </pre> <p>To run only a single method in a test class, append a pound (#) sign and the method name (in this case, <code>testConnectPro</code>) to the class name, like so:</p> -<pre> -$ adb shell am instrument -e class \ -'com.android.mediaframeworktest.integration.CameraBinderTest#testConnectPro' -w -\ com.android.mediaframeworktest/.MediaFrameworkIntegrationTestRunner +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell am instrument -e class 'com.android.mediaframeworktest.integration.CameraBinderTest#testConnectPro' -w com.android.mediaframeworktest/.MediaFrameworkIntegrationTestRunner </pre> <h3 id=media_settings_functional_tests>[ ] 7.2. Media settings functional tests</h3> @@ -442,10 +435,8 @@ functionality of different combinations of camera settings. (ie, Flash, exposure, WB, scene, picture size and geoTag)</p> <p>Run the test command:</p> -<pre> -$ adb shell am instrument -w -r -e delay_msec 15 -e log true -e class \ -com.android.mediaframeworktest.functional.camera.CameraPairwiseTest \ -com.android.mediaframeworktest/com.android.mediaframeworktest.CameraStressTestRunner +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell am instrument -w -r -e delay_msec 15 -e log true -e class com.android.mediaframeworktest.functional.camera.CameraPairwiseTest com.android.mediaframeworktest/com.android.mediaframeworktest.CameraStressTestRunner </pre> <h3 id=media_integration_tests>[ ] 7.3. Media integration tests</h3> @@ -454,13 +445,13 @@ com.android.mediaframeworktest/com.android.mediaframeworktest.CameraStressTestRu mediaframeworktest/integration/CameraBinderTest.java and mediaframeworktest/CameraStressTestRunner.java:</p> -<pre> -$ adb shell am instrument -e class \ 'com.android.mediaframeworktest.<strong>integration</strong>.<strong>CameraBinderTest'</strong> -w \ 'com.android.mediaframeworktest/.<strong>CameraStressTestRunner'</strong> +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell am instrument -e class \ 'com.android.mediaframeworktest.<strong>integration</strong>.<strong>CameraBinderTest'</strong> -w \ 'com.android.mediaframeworktest/.<strong>CameraStressTestRunner'</strong> </pre> <p>If successful, this results in output resembling:</p> -<pre> +<pre class="devsite-click-to-copy"> ----- com.android.mediaframeworktest.integration.CameraBinderTest:........... @@ -480,10 +471,8 @@ and it will compare the memory usage different after 200 iterations. Test will fail If the difference is greater than 150kM.</p> <p>Run the test command:</p> -<pre> -$ adb shell am instrument -w -r -e class \ -com.android.mediaframeworktest.performance.MediaPlayerPerformance#testCameraPreviewMemoryUsage -\ com.android.mediaframeworktest/.MediaFrameworkPerfTestRunner +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell am instrument -w -r -e class com.android.mediaframeworktest.performance.MediaPlayerPerformance#testCameraPreviewMemoryUsage com.android.mediaframeworktest/.MediaFrameworkPerfTestRunner </pre> <p>More detailed output can be found in: @@ -494,10 +483,8 @@ com.android.mediaframeworktest.performance.MediaPlayerPerformance#testCameraPrev <p>The commands to run unit tests are all similar. For example, for CameraMetadataTest.java, the command would be:</p> -<pre> -$ adb shell am instrument -e class \ -'com.android.mediaframeworktest.unit.CameraMetadataTest' -w \ -'com.android.mediaframeworktest/.CameraStressTestRunner' +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell am instrument -e class 'com.android.mediaframeworktest.unit.CameraMetadataTest' -w 'com.android.mediaframeworktest/.CameraStressTestRunner' </pre> <h3 id=media_stress_tests>[ ] 7.6. Media stress tests</h3> @@ -506,9 +493,8 @@ $ adb shell am instrument -e class \ <p>Run the test command:</p> -<pre> -$ adb shell am instrument -w -com.google.android.camera.tests/com.android.camera.stress.CameraStressTestRunner +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell am instrument -w com.google.android.camera.tests/com.android.camera.stress.CameraStressTestRunner </pre> <p>All tests should pass.</p> diff --git a/en/compatibility/cts/camera-its-box.html b/en/compatibility/cts/camera-its-box.html index b88b0b72..ac997536 100644 --- a/en/compatibility/cts/camera-its-box.html +++ b/en/compatibility/cts/camera-its-box.html @@ -110,7 +110,9 @@ charts on the tablet screen. <li>Position the tablet face-up on a table (do not attach the tablet to the back panel of the box)</li> <li>Run the following command: -<pre>$ python tools/run_all_tests.py device=$device_id camera=0 chart=$chart_id scenes=2,3</pre> +<pre class="devsite-terminal devsite-click-to-copy"> +python tools/run_all_tests.py device=$device_id camera=0 chart=$chart_id scenes=2,3 +</pre> Scenes 2 and 3 require the tablet to display an image, so the tablet prompts you to "Allow Drive to access photos, media, and files on your device?". Clear this prompt (and prevent future prompts) by pressing <strong>Allow</strong>.</li> @@ -135,25 +137,31 @@ hardware and software:</p> <ul> <li>One (1) Pixel NOF26W for the back camera(0) testing, S/N: FA6BM0305016. To install the CTS Verifier app, unzip android-cts-verifier.zip then run -<pre>$ adb -s FA6BM0305016 install -r android-cts-verifier/CtsVerifier.apk</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +adb -s FA6BM0305016 install -r android-cts-verifier/CtsVerifier.apk +</pre></li> <li>One (1) Pixel NOF26W for the front camera(1) testing, S/N: FA6BM0305439. To install the CTS Verifier app, unzip android-cts-verifier.zip then run -<pre>$ adb -s FA6BM0305439 install -r android-cts-verifier/CtsVerifier.apk</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +adb -s FA6BM0305439 install -r android-cts-verifier/CtsVerifier.apk +</pre> +</li> </ul> </li></ul> <h3 id=scenes-0-4>Running scenes 0-4</h3> <p>To run scenes 0-4 on the front and back camera in parallel:</p> -<pre>$ cd android-cts-verifier/CameraITS -$ . build/envsetup.sh -$ python tools/run_parallel_tests.py device0=FA6BM0305016 device1=FA6BM0305439 chart=5811000011 +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">cd android-cts-verifier/CameraITS</code> +<code class="devsite-terminal">. build/envsetup.sh</code> +<code class="devsite-terminal">python tools/run_parallel_tests.py device0=FA6BM0305016 device1=FA6BM0305439 chart=5811000011</code> </pre> <p>Examples:</p> <table> <tr> -<td ><img src=images/camera_its_cam0.png align="center"></td> -<td align="center"><img src=images/camera_its_cam0.png></td> +<td ><img src=/compatibility/cts/images/camera_its_cam0.png align="center"></td> +<td align="center"><img src=/compatibility/cts/images/camera_its_cam0.png></td> </tr> <tr> <td align="center"><p class=caption><strong>Figure 1</strong>. Camera 0 S/N: @@ -169,9 +177,15 @@ FA6BM0305439</p> <p>You can retry scenes for both front and back cameras or a single camera: <ul> <li>To retry scenes on front and back cameras in parallel: -<pre>$ python tools/run_parallel_tests.py device0=FA6BM0305016 device1=FA6BM0305439 chart=5811000011 scenes=3,4</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +python tools/run_parallel_tests.py device0=FA6BM0305016 device1=FA6BM0305439 chart=5811000011 scenes=3,4 +</pre> +</li> <li>To retry scenes on a single camera: -<pre>$ python tools/run_all_tests.py device=FA6BM0305016 chart=5811000011 camera=1 scenes=3,4</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +python tools/run_all_tests.py device=FA6BM0305016 chart=5811000011 camera=1 scenes=3,4 +</pre> +</li> </ul> <h3 id=scenes-0-4>Running scene 5</h3> @@ -180,12 +194,15 @@ CameraITS.pdf in the CTS Verifier download). You can run Scene 5 separately (outside of the box) to test two devices in parallel.</p> <ul> <li>To run Scene 5 on front and back cameras on two devices in parallel: -<pre>$ python tools/run_parallel_tests.py device0=FA6BM0305016 device1=FA6BM0305439 chart=5811000011 scenes=5</pre> -<br><img src=images/camera_its_scene5.png width="50%"><br> +<pre class="devsite-terminal devsite-click-to-copy"> +python tools/run_parallel_tests.py device0=FA6BM0305016 device1=FA6BM0305439 chart=5811000011 scenes=5 +</pre> +<br><img src=/compatibility/cts/images/camera_its_scene5.png width="50%"><br> <strong>Figure 3</strong>. Camera scene 5.</li> <li>To run Scene 5 for front and back cameras on a single device: -<pre>$ python tools/run_all_tests.py device=FA6BM0305016 camera=0 scenes=5 -$ python tools/run_all_tests.py device=FA6BM0305016 camera=1 scenes=5 +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">python tools/run_all_tests.py device=FA6BM0305016 camera=0 scenes=5</code> +<code class="devsite-terminal">python tools/run_all_tests.py device=FA6BM0305016 camera=1 scenes=5</code> </pre></li> </ul> @@ -199,21 +216,27 @@ have finished, so to view results during test execution you must use Android Device Monitor or <code>adb logcat</code> to verify progress and/or view screenshots.<br> <br>Example adb command: -<pre>$ adb -s FA6BM0305016 logcat -v time</pre> +<pre class="devsite-terminal devsite-click-to-copy"> +adb -s FA6BM0305016 logcat -v time +</pre> Example screenshots command: -<pre>$ adb -s FA6BM0305016 shell screencap -p /sdcard/screencap.png -$ adb -s FA6BM0305016 pull /sdcard/screencap.png -$ display ./screencap.png +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb -s FA6BM0305016 shell screencap -p /sdcard/screencap.png</code> +<code class="devsite-terminal">adb -s FA6BM0305016 pull /sdcard/screencap.png</code> +<code class="devsite-terminal">display ./screencap.png</code> </pre></li> <li><strong>View results</strong>. To save Camera ITS results as a report: <ol> <li>Press <strong>Pass</strong> and save the report: -<br><img src=images/camera_its_results.png width="50%"><br> +<br><img src=/compatibility/cts/images/camera_its_results.png width="50%"><br> <strong>Figure 4</strong>. Camera ITS report.</li> <li>Pull reports from the device: -<pre>$ adb -s FA6BM0305016 pull /sdcard/verifierReports</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +adb -s FA6BM0305016 pull /sdcard/verifierReports +</pre> +</li> <li>Unzip the report file and view the test_result.xml. -<br><img src=images/camera_its_reports.png><br> +<br><img src=/compatibility/cts/images/camera_its_reports.png><br> <strong>Figure 5</strong>. Camera ITS reports.<br></li> </ol> </li> diff --git a/en/compatibility/cts/development.html b/en/compatibility/cts/development.html index 6e44d27f..ae4c6e7e 100644 --- a/en/compatibility/cts/development.html +++ b/en/compatibility/cts/development.html @@ -37,14 +37,16 @@ CTS console:</p> <p class="note"><strong>Note:</strong> You may supply one of these other values for <code>TARGET_PRODUCT</code> to build for different architectures: <code>aosp_x86_64</code> or <code>aosp_mips</code></p> -<pre><code>cd <em>/path/to/android/root</em> -make cts -j32 TARGET_PRODUCT=aosp_arm64 -cts-tradefed +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">cd <em>/path/to/android/root</em></code> +<code class="devsite-terminal">make cts -j32 TARGET_PRODUCT=aosp_arm64</code> +<code class="devsite-terminal">cts-tradefed</code> </code></pre> <p>At the cts-tf console, enter e.g.:</p> -<pre><code>run cts --plan CTS -</code></pre> +<pre class="devsite-click-to-copy"> +tf> run cts --plan CTS +</pre> <h2 id="writing-cts-tests">Writing CTS tests</h2> @@ -106,7 +108,7 @@ For Android 6.0 and earlier, use CTS v1. For CTS v1, the sample code is at <p> The directory structure in CTS v1 tests looks like this: </p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> cts/ tests/ tests/ @@ -120,7 +122,7 @@ cts/ cts/ SampleDeviceTest.java </pre> -<h4 id="cts-v2"><strong>CTS v2</strong></h4> +<h4 id="cts-v2">CTS v2</h4> <p> For Android 7.0 and later, use CTS v2. For details, see <a href="https://android.googlesource.com/platform/cts/+/master/tests/sample/">the @@ -130,7 +132,7 @@ sample test in AOSP</a>. The CTS v2 directory structure looks like this: </p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> cts/ tests/ <em>module-name</em>/ @@ -169,7 +171,7 @@ to quick start your new test module with following steps: <ol> <li>Run this command to create the test directory and copy sample files to it: - <pre class="no-pretty-print">$ mkdir cts/tests/<i>module-name</i> && cp -r cts/tests/sample/* cts/tests/<i>module-name</i></pre> + <pre class="devsite-terminal devsite-click-to-copy">mkdir cts/tests/<i>module-name</i> && cp -r cts/tests/sample/* cts/tests/<i>module-name</i></pre> <li>Navigate to <code>cts/tests/<em>module-name</em></code> and substitute all instances of "[Ss]ample" following the recommended naming convention from above. <li>Update <code>SampleDeviceActivity</code> to exercise the feature you're testing. @@ -177,7 +179,7 @@ to quick start your new test module with following steps: errors.</li> </ol> -<h4><strong>Additional directories</strong></h4> +<h4>Additional directories</h4> <p> Other Android directories such as <code>assets</code>, <code>jni</code>, <code>libs</code> and <code>res</code> can also be added. To add JNI code, @@ -187,7 +189,7 @@ code and an <code>Android.mk</code> in it.</p> <p> The makefile typically contains the following settings: </p> -<pre> +<pre class="devsite-click-to-copy"> LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE := libCtsSample_jni @@ -210,7 +212,7 @@ include $(BUILD_SHARED_LIBRARY) need to be modified to build the native code and depend on it, as shown below:</p> -<pre> +<pre class="devsite-click-to-copy"> # All tests should include android.test.runner. LOCAL_JAVA_LIBRARIES := android.test.runner diff --git a/en/compatibility/cts/downloads.html b/en/compatibility/cts/downloads.html index 32186e70..c71ccb7d 100644 --- a/en/compatibility/cts/downloads.html +++ b/en/compatibility/cts/downloads.html @@ -180,7 +180,7 @@ Android 4.0.3 is found in the 'android-4.0.3_r1' branch in the open source tree. </ul> <h2 id="android-23">Android 2.3</h2> <p>Android 2.3 is the release of the development milestone code-named -Gingerbread. Source code for Android 2.3 is found in the 'gingerbread' branch in +Gingerbread. Source code for Android 2.3 is found in the 'gingerbread' branch in the open source tree.</p> <ul> <li><a href="https://dl.google.com/dl/android/cts/android-cts-2.3_r13-linux_x86-arm.zip">Android 2.3 R13 Compatibility Test Suite (CTS)</a></li> @@ -211,6 +211,7 @@ in the 'donut' branch in the open source tree.</p> <h2 id="cts-media-files">CTS Media Files</h2> <p>These media files are required for the CTS media stress tests.</p> <ul> +<li><a href="https://dl.google.com/dl/android/cts/android-cts-media-1.3.zip">CTS Media 1.3</a></li> <li><a href="https://dl.google.com/dl/android/cts/android-cts-media-1.2.zip">CTS Media 1.2</a></li> <li><a href="https://dl.google.com/dl/android/cts/android-cts-media-1.1.zip">CTS Media 1.1</a></li> <li><a href="https://dl.google.com/dl/android/cts/android-cts-media-1.0.zip">CTS Media 1.0</a></li> diff --git a/en/compatibility/cts/interpret.html b/en/compatibility/cts/interpret.html index 42ec9414..75ada597 100644 --- a/en/compatibility/cts/interpret.html +++ b/en/compatibility/cts/interpret.html @@ -24,7 +24,7 @@ <p>The CTS test results are placed in the file:</p> -<pre> +<pre class="devsite-click-to-copy"> $CTS_ROOT/android-cts/repository/results/<start_time>.zip </pre> @@ -73,14 +73,14 @@ could not be executed.</p> <section class="expandable"> <h4 class="showalways">Show CTS v1 sample test summary</h4> - <img src="images/cts-test-summary.png" alt="CTS v1 test summary" id="figure1a" /> + <img src="/compatibility/cts/images/cts-test-summary.png" alt="CTS v1 test summary" id="figure1a" /> <p class="img-caption"><strong>Figure 1a.</strong> CTS v1 sample test summary </p> </section> <section class="expandable"> <h4 class="showalways">Show CTS v2 sample test summary</h4> - <img src="images/cts-v2-test-summary.png" alt="CTS v2 test summary" id="figure1b" /> + <img src="/compatibility/cts/images/cts-v2-test-summary.png" alt="CTS v2 test summary" id="figure1b" /> <p class="img-caption"><strong>Figure 1b.</strong> CTS v2 sample test summary </p> </section> @@ -104,13 +104,13 @@ for the <em><StackTrace></em> tag).</p> <section class="expandable"> <h4 class="showalways">Show CTS v1 sample test report</h4> - <img src="images/cts-test-report.png" alt="CTS v1 test report" id="figure2a" /> + <img src="/compatibility/cts/images/cts-test-report.png" alt="CTS v1 test report" id="figure2a" /> <p class="img-caption"><strong>Figure 2a.</strong> CTS v1 sample test report</p> </section> <section class="expandable"> <h4 class="showalways">Show CTS v2 sample test report</h4> - <img src="images/cts-v2-test-report.png" alt="CTS v2 test report" id="figure2b" /> + <img src="/compatibility/cts/images/cts-v2-test-report.png" alt="CTS v2 test report" id="figure2b" /> <p class="img-caption"><strong>Figure 2b.</strong> CTS v2 sample test report</p> </section> diff --git a/en/compatibility/cts/setup.html b/en/compatibility/cts/setup.html index e22f2fdd..65bd8480 100644 --- a/en/compatibility/cts/setup.html +++ b/en/compatibility/cts/setup.html @@ -68,8 +68,8 @@ the Stand-alone SDK Tools</a>.</p> following command assumes you've opened the package archive in your home directory:</p> <hr> -<pre> -$ export PATH=$PATH:$HOME/android-sdk-linux/build-tools/<version> +<pre class="devsite-terminal devsite-click-to-copy"> +export PATH=$PATH:$HOME/android-sdk-linux/build-tools/<version> </pre> <p class="note"><strong>Note:</strong> Please ensure your starting path and @@ -132,7 +132,7 @@ property is the first API level the device was commercially launched with.</p> <p>OEMs can add <code>PRODUCT_PROPERTY_OVERRIDES</code> into their device.mk file to set this property, as shown in the following example: </p> -<pre> +<pre class="devsite-click-to-copy"> #ro.product.first_api_level indicates the first api level, device has been commercially launched on. PRODUCT_PROPERTY_OVERRIDES +=\ ro.product.first_api_level=21 diff --git a/en/compatibility/cts/verifier.html b/en/compatibility/cts/verifier.html index ace9475e..212b2bf0 100644 --- a/en/compatibility/cts/verifier.html +++ b/en/compatibility/cts/verifier.html @@ -43,8 +43,8 @@ SDK</a> on the Linux computer <li>Download the appropriate <a href="downloads.html">CTS Verifier.apk</a> for the version of Android under test. - <li>Install CTS Verifier.apk to the <em>Device Under Test</em> (DUT). <br> - <code>adb install -r -g CtsVerifier.apk</code> + <li>Install CTS Verifier.apk to the <em>Device Under Test</em> (DUT). + <pre class="devsite-terminal devsite-click-to-copy">adb install -r -g CtsVerifier.apk</pre> <li>Ensure that the device has its system data and time set correctly. </ul> <h2 id=cts_test_procedure>CTS Verifier test procedure</h2> @@ -52,7 +52,7 @@ version of Android under test. <li>After the CTS Verifier.apk has been installed, launch the CTS Verifier application: -<img src="images/cts-verifier-icon.png" alt="CTS Verifier icon in launcher" id="figure1" /> +<img src="/compatibility/cts/images/cts-verifier-icon.png" alt="CTS Verifier icon in launcher" id="figure1" /> <p class="img-caption"> <strong>Figure 1.</strong> CTS Verifier icon </p> @@ -60,7 +60,7 @@ version of Android under test. <li>Once opened, the CTS Verifier displays a list of all test sets available for manual verification: -<img src="images/cts-verifier-menu.png" alt="CTS Verifier menu of tests" id="figure2" /> +<img src="/compatibility/cts/images/cts-verifier-menu.png" alt="CTS Verifier menu of tests" id="figure2" /> <p class="img-caption"> <strong>Figure 2.</strong> CTS Verifier menu of tests </p> @@ -76,7 +76,7 @@ version of Android under test. press the <strong>Fail</strong> button (！). </ul> -<img src="images/video-verifier.png" alt="Streaming video quality verifier" id="figure3" /> +<img src="/compatibility/cts/images/video-verifier.png" alt="Streaming video quality verifier" id="figure3" /> <p class="img-caption"> <strong>Figure 3.</strong> Video quality verifier </p> @@ -91,17 +91,17 @@ version of Android under test. <li>Connect the DUT to a computer. <li>Execute the cts-usb-accessory program on the computer found in the CTS Verifier package. + <pre class="devsite-terminal devsite-click-to-copy">./cts-usb-accessory</pre> <li>A popup message will appear on the DUT. Select <strong>OK</strong> and go into the USB Accessory Test in the CTS Verifier application. <br> -<img src="images/screen-lock-test.png" alt="CTS Verifier screen lock test" id="figure4" /> +<img src="/compatibility/cts/images/screen-lock-test.png" alt="CTS Verifier screen lock test" id="figure4" /> <p class="img-caption"> <strong>Figure 4.</strong> Screen lock test </p> <li>Output similar to below will appear on the computer’s console. </ol> -<pre> -out/host/linux-x86/cts-verifier/android-cts-verifier$ <strong>./cts-usb-accessory</strong> +<pre class="devsite-click-to-copy"> CTS USB Accessory Tester Found possible Android device (413c:2106) - attempting to switch to accessory mode... @@ -138,7 +138,7 @@ href="/compatibility/calibration-pattern.pdf">calibration-pattern.pdf</a> target file and mount it on a rigid backing. Print on 11” x 17” or A3. Orient the camera device and the printed target as shown in the diagram below:</p> -<img src="images/camera-printed-target.png" alt="Camera printed target" id="figure5" /> +<img src="/compatibility/cts/images/camera-printed-target.png" alt="Camera printed target" id="figure5" /> <p class="img-caption"> <strong>Figure 5.</strong> Camera printed target </p> @@ -177,11 +177,11 @@ ensure that the optical axis is orthogonal to the target.</p> <li> After all tests are completed, tap the <strong>Save (disk)</strong> icon. <br> - <img src="images/verifier-save-icon.png" alt="CTS Verifier Save icon" id="figure6" /> + <img src="/compatibility/cts/images/verifier-save-icon.png" alt="CTS Verifier Save icon" id="figure6" /> <p class="img-caption"> <strong>Figure 6.</strong> CTS Verifier Save icon. <em>Note:</em> In Android 7.0 and later, the preview feature is removed: - <img src="images/verifier-preview-icon.png" width="24" height="24"> + <img src="/compatibility/cts/images/verifier-preview-icon.png" width="24" height="24"> </p> </li> <li> @@ -202,9 +202,10 @@ ensure that the optical axis is orthogonal to the target.</p> <code>adb pull CTSVerifierReportPath</code> to download the report from the device. <ul> <li> - To download all reports run: <code>adb pull /sdcard/verifierReports</code> - <br/> - For Android 6.0 and earlier, run: <code>adb pull /mnt/sdcard/ctsVerifierReports/</code> + To download all reports run: + <pre class="devsite-terminal devsite-click-to-copy">adb pull /sdcard/verifierReports</pre> + For Android 6.0 and earlier, run: + <pre class="devsite-terminal devsite-click-to-copy">adb pull /mnt/sdcard/ctsVerifierReports/</pre> </li> <li> The name of the reports are time-stamped based on the DUT’s system time. diff --git a/en/devices/_toc-tech.yaml b/en/devices/_toc-tech.yaml index 13534b2d..fda6c38d 100644 --- a/en/devices/_toc-tech.yaml +++ b/en/devices/_toc-tech.yaml @@ -101,6 +101,8 @@ toc: path: /devices/tech/debug/asan - title: Dumpsys path: /devices/tech/debug/dumpsys + - title: Using GDB + path: /devices/tech/debug/gdb - title: Native Memory Use path: /devices/tech/debug/native-memory - title: Network Use diff --git a/en/devices/audio/attributes.html b/en/devices/audio/attributes.html index b685e8bf..61825c00 100644 --- a/en/devices/audio/attributes.html +++ b/en/devices/audio/attributes.html @@ -135,7 +135,7 @@ audio attribute API</a>.</p> <p>In this example, AudioAttributes.Builder defines the AudioAttributes to be used by a new AudioTrack instance:</p> -<pre> +<pre class="devsite-click-to-copy"> AudioTrack myTrack = new AudioTrack( new AudioAttributes.Builder() .setUsage(AudioAttributes.USAGE_MEDIA) diff --git a/en/devices/audio/data_formats.html b/en/devices/audio/data_formats.html index e11a1abf..382c9567 100644 --- a/en/devices/audio/data_formats.html +++ b/en/devices/audio/data_formats.html @@ -118,7 +118,7 @@ for all signed fixed-point representations, so the following holds where all values are in units of one <a href="https://en.wikipedia.org/wiki/Least_significant_bit">LSB</a>: </p> -<pre> +<pre class="devsite-click-to-copy"> |largest negative value| = |largest positive value| + 1 </pre> @@ -306,7 +306,7 @@ To convert a value from Q<em>m</em>.<em>n</em> format to floating point: <p> For example, to convert a Q4.27 internal value to floating point, use: </p> -<pre> +<pre class="devsite-click-to-copy"> float = integer * (2 ^ -27) </pre> diff --git a/en/devices/audio/debugging.html b/en/devices/audio/debugging.html index 9f8efb79..67e23d03 100644 --- a/en/devices/audio/debugging.html +++ b/en/devices/audio/debugging.html @@ -50,30 +50,31 @@ For Android 7.x, replace <code>/data/misc/media</code> with <code>/data/misc/audioserver</code>. Additionally, you must use a userdebug or eng build. If you use a userdebug build, then disable verity with:</p> -<pre> -<code>$ adb root && adb disable-verity && adb reboot</code> + +<pre class="devsite-terminal devsite-click-to-copy"> +adb root && adb disable-verity && adb reboot </pre> <h3 id="compile">Compile-time setup</h3> <ol> -<li><code>$ cd frameworks/av/services/audioflinger</code></li> + <li><code class="devsite-terminal">cd frameworks/av/services/audioflinger</code></li> <li>Edit <code>Configuration.h</code>.</li> <li>Uncomment <code>#define TEE_SINK</code>.</li> <li>Re-build <code>libaudioflinger.so</code>.</li> -<li><code>$ adb root</code></li> -<li><code>$ adb remount</code></li> +<li><code class="devsite-terminal">adb root</code></li> +<li><code class="devsite-terminal">adb remount</code></li> <li>Push or sync the new <code>libaudioflinger.so</code> to the device's <code>/system/lib</code>.</li> </ol> <h3 id="runtime">Run-time setup</h3> <ol> -<li><code>$ adb shell getprop | grep ro.debuggable</code> +<li><code class="devsite-terminal">adb shell getprop | grep ro.debuggable</code> <br />Confirm that the output is: <code>[ro.debuggable]: [1]</code> </li> -<li><code>$ adb shell</code></li> -<li><code>$ ls -ld /data/misc/media</code> +<li><code class="devsite-terminal">adb shell</code></li> +<li><code class="devsite-terminal">ls -ld /data/misc/media</code> <br /> <p> Confirm that the output is: @@ -81,20 +82,19 @@ Confirm that the output is: <pre> drwx------ media media ... media </pre> -<br /> <p> If the directory does not exist, create it as follows: </p> -<pre> -$ mkdir /data/misc/media -$ chown media:media /data/misc/media +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">mkdir /data/misc/media</code> +<code class="devsite-terminal">chown media:media /data/misc/media</code> </pre> </li> -<li><code>$ echo af.tee=# > /data/local.prop</code> +<li><code class="devsite-terminal">echo af.tee=# > /data/local.prop</code> <br />Where the <code>af.tee</code> value is a number described below. </li> -<li><code>$ chmod 644 /data/local.prop</code></li> -<li><code>$ reboot</code></li> +<li><code class="devsite-terminal">chmod 644 /data/local.prop</code></li> +<li><code class="devsite-terminal">reboot</code></li> </ol> <h4>Values for <code>af.tee</code> property</h4> @@ -120,7 +120,7 @@ but you can get similar results using "4." <ol> <li>Run your audio test.</li> -<li><code>$ adb shell dumpsys media.audio_flinger</code></li> +<li><code class="devsite-terminal">adb shell dumpsys media.audio_flinger</code></li> <li>Look for a line in dumpsys output such as this:<br /> <code>tee copied to /data/misc/media/20131010101147_2.wav</code> <br />This is a PCM .wav file. @@ -165,10 +165,10 @@ Restore your build and device as follows: <li>Push or sync the restored <code>libaudioflinger.so</code> to the device's <code>/system/lib</code>. </li> -<li><code>$ adb shell</code></li> -<li><code>$ rm /data/local.prop</code></li> -<li><code>$ rm /data/misc/media/*.wav</code></li> -<li><code>$ reboot</code></li> +<li><code class="devsite-terminal">adb shell</code></li> +<li><code class="devsite-terminal">rm /data/local.prop</code></li> +<li><code class="devsite-terminal">rm /data/misc/media/*.wav</code></li> +<li><code class="devsite-terminal">reboot</code></li> </ol> <h2 id="mediaLog">media.log</h2> @@ -345,7 +345,7 @@ First, you need to add logs to your code. <p> In <code>FastMixer</code> and <code>FastCapture</code> threads, use code such as this: </p> -<pre> +<pre class="devsite-click-to-copy"> logWriter->log("string"); logWriter->logf("format", parameters); logWriter->logTimestamp(); @@ -359,7 +359,7 @@ there is no need for mutual exclusion. <p> In other AudioFlinger threads, use <code>mNBLogWriter</code>: </p> -<pre> +<pre class="devsite-click-to-copy"> mNBLogWriter->log("string"); mNBLogWriter->logf("format", parameters); mNBLogWriter->logTimestamp(); @@ -397,19 +397,19 @@ The full <code>NBLog</code> API is at <code>frameworks/av/include/media/nbaio/NB <code>ro.test_harness</code> is <code>1</code>. You can enable it by: </p> -<pre> -$ adb root -$ adb shell -$ echo ro.test_harness=1 > /data/local.prop -$ chmod 644 /data/local.prop -$ reboot +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb root</code> +<code class="devsite-terminal">adb shell</code> +<code class="devsite-terminal">echo ro.test_harness=1 > /data/local.prop</code> +<code class="devsite-terminal">chmod 644 /data/local.prop</code> +<code class="devsite-terminal">reboot</code> </pre> <p> The connection is lost during reboot, so: </p> -<pre> -$ adb shell +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell </pre> The command <code>ps media</code> will now show two processes: @@ -427,8 +427,8 @@ Note the process ID of <code>mediaserver</code> for later. You can manually request a log dump at any time. This command shows logs from all the active and recent timelines, and then clears them: </p> -<pre> -$ dumpsys media.log +<pre class="devsite-terminal devsite-click-to-copy"> +dumpsys media.log </pre> <p> @@ -443,8 +443,9 @@ Now try killing <code>mediaserver</code> process: <code>kill -9 #</code>, where the process ID you noted earlier. You should see a dump from <code>media.log</code> in the main <code>logcat</code>, showing all the logs leading up to the crash. </p> -<pre> -$ dumpsys media.log + +<pre class="devsite-terminal devsite-click-to-copy"> +dumpsys media.log </pre> </body> diff --git a/en/devices/audio/latency_app.html b/en/devices/audio/latency_app.html index b4e7495b..61a1c56f 100644 --- a/en/devices/audio/latency_app.html +++ b/en/devices/audio/latency_app.html @@ -104,7 +104,7 @@ The document "OpenSL ES for Android" is provided in the NDK installation, and is not currently available online. Open this link in a browser: </p> -<pre> +<pre class="devsite-click-to-copy"> NDKroot/docs/Additional_library_docs/opensles/index.html </pre> diff --git a/en/devices/audio/midi.html b/en/devices/audio/midi.html index 31b55182..ecebb012 100644 --- a/en/devices/audio/midi.html +++ b/en/devices/audio/midi.html @@ -153,7 +153,7 @@ Applications can screen for the presence of MIDI support using the <p> To claim MIDI support, add this line to your <code>device.mk</code>: </p> -<pre> +<pre class="devsite-click-to-copy"> PRODUCT_COPY_FILES += \ frameworks/native/data/etc/android.software.midi.xml:system/etc/permissions/android.software.midi.xml </pre> diff --git a/en/devices/audio/midi_test.html b/en/devices/audio/midi_test.html index 303f0980..d6531f98 100644 --- a/en/devices/audio/midi_test.html +++ b/en/devices/audio/midi_test.html @@ -104,9 +104,9 @@ For example, to install the <em>MidiScope</em> app:</p> <li> On the workstation, enter:</li> </ol> -<pre> -cd <em><this-folder></em> -adb install -r MidiScope.apk +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">cd <var>THIS_FOLDER</var></code> +<code class="devsite-terminal">adb install -r MidiScope.apk</code> </pre> diff --git a/en/devices/audio/tv.html b/en/devices/audio/tv.html index 29c95bb5..61bdbe4e 100644 --- a/en/devices/audio/tv.html +++ b/en/devices/audio/tv.html @@ -73,12 +73,12 @@ of all the TV output (11Khz, 16bit mono or 48Khz, 16bit mono). Used only for aud <p>Android supports the following audio devices for TV audio input/output.</p> -<h4>system/media/audio/include/system/audio.h</h4> +<h4><code>system/media/audio/include/system/audio.h</code></h4> <p class="note"><strong>Note:</strong> In Android 5.1 and earlier, the path to this file is: <code>system/core/include/system/audio.h</code></p> -<pre> +<pre class="devsite-click-to-copy"> /* output devices */ AUDIO_DEVICE_OUT_AUX_DIGITAL = 0x400, AUDIO_DEVICE_OUT_HDMI = AUDIO_DEVICE_OUT_AUX_DIGITAL, @@ -101,12 +101,12 @@ AUDIO_DEVICE_IN_LOOPBACK = AUDIO_DEVICE_BIT_IN | 0x40000, <p>The Audio HAL extension for the audio routing API is defined by following:</p> -<h4>system/media/audio/include/system/audio.h</h4> +<h4><code>system/media/audio/include/system/audio.h</code></h4> <p class="note"><strong>Note:</strong> In Android 5.1 and earlier, the path to this file is: <code>system/core/include/system/audio.h</code></p> -<pre> +<pre class="devsite-click-to-copy"> /* audio port configuration structure used to specify a particular configuration of an audio port */ struct audio_port_config { audio_port_handle_t id; /* port unique ID */ @@ -144,9 +144,9 @@ struct audio_port { }; </pre> -<h4>hardware/libhardware/include/hardware/audio.h</h4> +<h4><code>hardware/libhardware/include/hardware/audio.h</code></h4> -<pre> +<pre class="devsite-click-to-copy"> struct audio_hw_device { : /** @@ -185,9 +185,9 @@ struct audio_hw_device { <p>To test DEVICE_IN_LOOPBACK for TV monitoring, use the following testing code. After running the test, the captured audio saves to <code>/sdcard/record_loopback.raw</code>, where you can listen to -it using <code>ffmeg</code>.</p> +it using <code><a href="https://en.wikipedia.org/wiki/FFmpeg">FFmpeg</a></code>.</p> -<pre> +<pre class="devsite-click-to-copy"> <uses-permission android:name="android.permission.MODIFY_AUDIO_ROUTING" /> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" /> @@ -267,12 +267,12 @@ it using <code>ffmeg</code>.</p> </pre> <p>Locate the captured audio file in <code>/sdcard/record_loopback.raw</code> and listen to it using -<code>ffmeg</code>:</p> +<code>FFmpeg</code>:</p> -<pre> -adb pull /sdcard/record_loopback.raw -ffmpeg -f s16le -ar 48k -ac 1 -i record_loopback.raw record_loopback.wav -ffplay record_loopback.wav +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb pull /sdcard/record_loopback.raw</code> +<code class="devsite-terminal">ffmpeg -f s16le -ar 48k -ac 1 -i record_loopback.raw record_loopback.wav</code> +<code class="devsite-terminal">ffplay record_loopback.wav</code> </pre> <h2 id="useCases">Use cases</h2> diff --git a/en/devices/audio/usb.html b/en/devices/audio/usb.html index f1c99ff6..d1dfcd3e 100644 --- a/en/devices/audio/usb.html +++ b/en/devices/audio/usb.html @@ -572,7 +572,9 @@ To enable USB audio, add an entry to the audio policy configuration file. This is typically located here: </p> -<pre>device/oem/codename/audio_policy.conf</pre> +<pre class="devsite-click-to-copy"> +device/oem/codename/audio_policy.conf +</pre> <p> The pathname component "oem" should be replaced by the name of the OEM who manufactures the Android device, @@ -583,7 +585,7 @@ and "codename" should be replaced by the device code name. An example entry is shown here: </p> -<pre> +<pre class="devsite-click-to-copy"> audio_hw_modules { ... usb { @@ -620,7 +622,9 @@ audio_hw_modules { The audio Hardware Abstraction Layer (HAL) implementation for USB audio is located here: </p> -<pre>hardware/libhardware/modules/usbaudio/</pre> +<pre class="devsite-click-to-copy"> +hardware/libhardware/modules/usbaudio/ +</pre> <p> The USB audio HAL relies heavily on <i>tinyalsa</i>, described at <a href="terminology.html">Audio Terminology</a>. diff --git a/en/devices/audio/warmup.html b/en/devices/audio/warmup.html index e139e2f4..7c37cd66 100644 --- a/en/devices/audio/warmup.html +++ b/en/devices/audio/warmup.html @@ -54,7 +54,9 @@ Layer (HAL) <code>write()</code> takes to stabilize. the hardware itself might have its own power logic beyond the three seconds that AudioFlinger has.</li> <li>Press Home, and you should hear a click sound.</li> <li>Run the following command to receive the measured warmup: - <br /><code>adb shell dumpsys media.audio_flinger | grep measuredWarmup</code> +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell dumpsys media.audio_flinger | grep measuredWarmup +</pre> <p> You should see output like this: diff --git a/en/devices/camera/camera3_crop_reprocess.html b/en/devices/camera/camera3_crop_reprocess.html index 00c5bbed..1e24db3b 100644 --- a/en/devices/camera/camera3_crop_reprocess.html +++ b/en/devices/camera/camera3_crop_reprocess.html @@ -24,21 +24,21 @@ <h2 id="output-stream">Output streams</h2> -<p> Unlike the old camera subsystem, which has 3-4 different ways of producing data - from the camera (ANativeWindow-based preview operations, preview callbacks, - video callbacks, and takePicture callbacks), the new subsystem operates solely - on the ANativeWindow-based pipeline for all resolutions and output formats. - Multiple such streams can be configured at once, to send a single frame to many - targets such as the GPU, the video encoder, RenderScript, or app-visible buffers +<p> Unlike the old camera subsystem, which has 3-4 different ways of producing data + from the camera (ANativeWindow-based preview operations, preview callbacks, + video callbacks, and takePicture callbacks), the new subsystem operates solely + on the ANativeWindow-based pipeline for all resolutions and output formats. + Multiple such streams can be configured at once, to send a single frame to many + targets such as the GPU, the video encoder, RenderScript, or app-visible buffers (RAW Bayer, processed YUV buffers, or JPEG-encoded buffers).</p> -<p>As an optimization, these output streams must be configured ahead of time, and - only a limited number may exist at once. This allows for pre-allocation of - memory buffers and configuration of the camera hardware, so that when requests - are submitted with multiple or varying output pipelines listed, there won't be +<p>As an optimization, these output streams must be configured ahead of time, and + only a limited number may exist at once. This allows for pre-allocation of + memory buffers and configuration of the camera hardware, so that when requests + are submitted with multiple or varying output pipelines listed, there won't be delays or latency in fulfilling the request.</p> -<p>To support backwards compatibility with the current camera API, at least 3 - simultaneous YUV output streams must be supported, plus one JPEG stream. This is - required for video snapshot support with the application also receiving YUV +<p>To support backwards compatibility with the current camera API, at least 3 + simultaneous YUV output streams must be supported, plus one JPEG stream. This is + required for video snapshot support with the application also receiving YUV buffers:</p> <ul> <li>One stream to the GPU/SurfaceView (opaque YUV format) for preview</li> @@ -49,48 +49,48 @@ <p>The exact requirements are still being defined since the corresponding API isn't yet finalized.</p> <h2>Cropping</h2> -<p>Cropping of the full pixel array (for digital zoom and other use cases where a - smaller FOV is desirable) is communicated through the ANDROID_SCALER_CROP_REGION - setting. This is a per-request setting, and can change on a per-request basis, +<p>Cropping of the full pixel array (for digital zoom and other use cases where a + smaller FOV is desirable) is communicated through the ANDROID_SCALER_CROP_REGION + setting. This is a per-request setting, and can change on a per-request basis, which is critical for implementing smooth digital zoom.</p> -<p>The region is defined as a rectangle (x, y, width, height), with (x, y) - describing the top-left corner of the rectangle. The rectangle is defined on the - coordinate system of the sensor active pixel array, with (0,0) being the - top-left pixel of the active pixel array. Therefore, the width and height cannot - be larger than the dimensions reported in the ANDROID_SENSOR_ACTIVE_PIXEL_ARRAY - static info field. The minimum allowed width and height are reported by the HAL - through the ANDROID_SCALER_MAX_DIGITAL_ZOOM static info field, which describes - the maximum supported zoom factor. Therefore, the minimum crop region width and +<p>The region is defined as a rectangle (x, y, width, height), with (x, y) + describing the top-left corner of the rectangle. The rectangle is defined on the + coordinate system of the sensor active pixel array, with (0,0) being the + top-left pixel of the active pixel array. Therefore, the width and height cannot + be larger than the dimensions reported in the ANDROID_SENSOR_ACTIVE_PIXEL_ARRAY + static info field. The minimum allowed width and height are reported by the HAL + through the ANDROID_SCALER_MAX_DIGITAL_ZOOM static info field, which describes + the maximum supported zoom factor. Therefore, the minimum crop region width and height are:</p> -<pre> +<pre class="devsite-click-to-copy"> {width, height} = { floor(ANDROID_SENSOR_ACTIVE_PIXEL_ARRAY[0] / ANDROID_SCALER_MAX_DIGITAL_ZOOM), floor(ANDROID_SENSOR_ACTIVE_PIXEL_ARRAY[1] / ANDROID_SCALER_MAX_DIGITAL_ZOOM) } - </pre> -<p>If the crop region needs to fulfill specific requirements (for example, it needs - to start on even coordinates, and its width/height needs to be even), the HAL - must do the necessary rounding and write out the final crop region used in the - output result metadata. Similarly, if the HAL implements video stabilization, it - must adjust the result crop region to describe the region actually included in - the output after video stabilization is applied. In general, a camera-using - application must be able to determine the field of view it is receiving based on +</pre> +<p>If the crop region needs to fulfill specific requirements (for example, it needs + to start on even coordinates, and its width/height needs to be even), the HAL + must do the necessary rounding and write out the final crop region used in the + output result metadata. Similarly, if the HAL implements video stabilization, it + must adjust the result crop region to describe the region actually included in + the output after video stabilization is applied. In general, a camera-using + application must be able to determine the field of view it is receiving based on the crop region, the dimensions of the image sensor, and the lens focal length.</p> -<p>Since the crop region applies to all streams, which may have different aspect - ratios than the crop region, the exact sensor region used for each stream may be - smaller than the crop region. Specifically, each stream should maintain square - pixels and its aspect ratio by minimally further cropping the defined crop - region. If the stream's aspect ratio is wider than the crop region, the stream - should be further cropped vertically, and if the stream's aspect ratio is - narrower than the crop region, the stream should be further cropped +<p>Since the crop region applies to all streams, which may have different aspect + ratios than the crop region, the exact sensor region used for each stream may be + smaller than the crop region. Specifically, each stream should maintain square + pixels and its aspect ratio by minimally further cropping the defined crop + region. If the stream's aspect ratio is wider than the crop region, the stream + should be further cropped vertically, and if the stream's aspect ratio is + narrower than the crop region, the stream should be further cropped horizontally.</p> -<p>In all cases, the stream crop must be centered within the full crop region, and - each stream is only either cropped horizontally or vertical relative to the full +<p>In all cases, the stream crop must be centered within the full crop region, and + each stream is only either cropped horizontally or vertical relative to the full crop region, never both.</p> -<p>For example, if two streams are defined, a 640x480 stream (4:3 aspect), and a - 1280x720 stream (16:9 aspect), below demonstrates the expected output regions - for each stream for a few sample crop regions, on a hypothetical 3 MP (2000 x +<p>For example, if two streams are defined, a 640x480 stream (4:3 aspect), and a + 1280x720 stream (16:9 aspect), below demonstrates the expected output regions + for each stream for a few sample crop regions, on a hypothetical 3 MP (2000 x 1500 pixel array) sensor.</p> </p> Crop region: (500, 375, 1000, 750) (4:3 aspect ratio)<br/> @@ -118,7 +118,7 @@ isn't yet finalized.</p> <strong>Figure 3.</strong> 1:1 aspect ratio </p> <p> - And a final example, a 1024x1024 square aspect ratio stream instead of the 480p + And a final example, a 1024x1024 square aspect ratio stream instead of the 480p stream:<br/> Crop region: (500, 375, 1000, 750) (4:3 aspect ratio)<br/> 1024x1024 stream crop: (625, 375, 750, 750)<br/> @@ -129,9 +129,9 @@ isn't yet finalized.</p> <strong>Figure 4.</strong> 4:3 aspect ratio, square </p> <h2 id="reprocessing">Reprocessing</h2> -<p> Additional support for raw image files is provided by reprocessing support for RAW Bayer - data. This support allows the camera pipeline to process a previously captured - RAW buffer and metadata (an entire frame that was recorded previously), to +<p> Additional support for raw image files is provided by reprocessing support for RAW Bayer + data. This support allows the camera pipeline to process a previously captured + RAW buffer and metadata (an entire frame that was recorded previously), to produce a new rendered YUV or JPEG output.</p> </body> diff --git a/en/devices/camera/camera3_error_stream.html b/en/devices/camera/camera3_error_stream.html index 68b83a68..aebb325c 100644 --- a/en/devices/camera/camera3_error_stream.html +++ b/en/devices/camera/camera3_error_stream.html @@ -24,137 +24,137 @@ <h2 id="error-mgmt">Error management</h2> -<p>Camera HAL device ops functions that have a return value will all return -ENODEV - / NULL in case of a serious error. This means the device cannot continue - operation, and must be closed by the framework. Once this error is returned by - some method, or if notify() is called with ERROR_DEVICE, only the close() method - can be called successfully. All other methods will return -ENODEV / NULL.<br/> - If a device op is called in the wrong sequence, for example if the framework - calls configure_streams() is called before initialize(), the device must return - -ENOSYS from the call, and do nothing.<br/> - Transient errors in image capture must be reported through notify() as follows:</p> +<p>Camera HAL device ops functions that have a return value will all return <code>-ENODEV + / NULL</code> in case of a serious error. This means the device cannot continue + operation and must be closed by the framework. Once this error is returned by + some method, or if <code>notify()</code> is called with <code>ERROR_DEVICE</code>, only the <code>close()</code> method + can be called successfully. All other methods will return <code>-ENODEV / NULL</code>.</p> +<p>If a device op is called in the wrong sequence, for example if the framework +calls <code>configure_streams()</code> before <code>initialize()</code>, the device must return +<code>-ENOSYS</code> from the call, and do nothing.</p> +<p>Transient errors in image capture must be reported through <code>notify()</code> as follows:</p> <ul> - <li>The failure of an entire capture to occur must be reported by the HAL by - calling notify() with ERROR_REQUEST. Individual errors for the result metadata + <li>The failure of an entire capture to occur must be reported by the HAL by + calling <code>notify()</codE> with <code>ERROR_REQUEST</code>. Individual errors for the result metadata or the output buffers must not be reported in this case.</li> - <li>If the metadata for a capture cannot be produced, but some image buffers were - filled, the HAL must call notify() with ERROR_RESULT.</li> - <li>If an output image buffer could not be filled, but either the metadata was - produced or some other buffers were filled, the HAL must call notify() with - ERROR_BUFFER for each failed buffer.</li> + <li>If the metadata for a capture cannot be produced, but some image buffers were + filled, the HAL must call <code>notify()</code> with <code>ERROR_RESULT</code>.</li> + <li>If an output image buffer could not be filled, but either the metadata was + produced or some other buffers were filled, the HAL must call <code>notify()</code> with + <code>ERROR_BUFFER</code> for each failed buffer.</li> </ul> -<p>In each of these transient failure cases, the HAL must still call - process_capture_result, with valid output buffer_handle_t. If the result - metadata could not be produced, it should be NULL. If some buffers could not be - filled, their sync fences must be set to the error state.<br/> - Invalid input arguments result in -EINVAL from the appropriate methods. In that +<p>In each of these transient failure cases, the HAL must still call +<code>process_capture_result</code>, with valid output <code>buffer_handle_t</code>. If the result +metadata could not be produced, it should be <code>NULL</code>. If some buffers could not be + filled, their sync fences must be set to the error state.</p> +<p>Invalid input arguments result in <code>-EINVAL</code> from the appropriate methods. In that case, the framework must act as if that call had never been made.</p> <h2 id="stream-mgmt">Stream management</h2> <h3 id="configure_streams">configure_streams</h3> -<p>Reset the HAL camera device processing pipeline and set up new input and output - streams. This call replaces any existing stream configuration with the streams - defined in the stream_list. This method will be called at least once after - initialize() before a request is submitted with process_capture_request().<br/> - The stream_list must contain at least one output-capable stream, and may not - contain more than one input-capable stream.<br/> - The stream_list may contain streams that are also in the currently-active set of - streams (from the previous call to configure_stream()). These streams will - already have valid values for usage, maxbuffers, and the private pointer. If - such a stream has already had its buffers registered, register_stream_buffers() - will not be called again for the stream, and buffers from the stream can be - immediately included in input requests.<br/> - If the HAL needs to change the stream configuration for an existing stream due - to the new configuration, it may rewrite the values of usage and/or maxbuffers - during the configure call. The framework will detect such a change, and will - then reallocate the stream buffers, and call register_stream_buffers() again - before using buffers from that stream in a request.<br/> - If a currently-active stream is not included in stream_list, the HAL may safely - remove any references to that stream. It will not be reused in a later - configure() call by the framework, and all the gralloc buffers for it will be - freed after the configure_streams() call returns.<br/> - The stream_list structure is owned by the framework, and may not be accessed - once this call completes. The address of an individual camera3streamt - structure will remain valid for access by the HAL until the end of the first - configure_stream() call which no longer includes that camera3streamt in the - stream_list argument. The HAL may not change values in the stream structure - outside of the private pointer, except for the usage and maxbuffers members - during the configure_streams() call itself.<br/> - If the stream is new, the usage, maxbuffer, and private pointer fields of the - stream structure will all be set to 0. The HAL device must set these fields - before the configure_streams() call returns. These fields are then used by the - framework and the platform gralloc module to allocate the gralloc buffers for - each stream.<br/> - Before such a new stream can have its buffers included in a capture request, the - framework will call register_stream_buffers() with that stream. However, the - framework is not required to register buffers for _all streams before - submitting a request. This allows for quick startup of (for example) a preview +<p>Reset the HAL camera device processing pipeline and set up new input and output + streams. This call replaces any existing stream configuration with the streams + defined in the <code>stream_list</code>. This method will be called at least once after + <code>initialize()</code> before a request is submitted with <code>process_capture_request()</code>.</p> +<p>The <code>stream_list</code> must contain at least one output-capable stream, and may not + contain more than one input-capable stream. + The <code>stream_list</code> may contain streams that are also in the currently-active set of + streams (from the previous call to <code>configure_stream()</code>). These streams will + already have valid values for usage, maxbuffers, and the private pointer. If + such a stream has already had its buffers registered, <code>register_stream_buffers()</code> + will not be called again for the stream, and buffers from the stream can be + immediately included in input requests.</p> +<p>If the HAL needs to change the stream configuration for an existing stream due + to the new configuration, it may rewrite the values of usage and/or maxbuffers + during the configure call. The framework will detect such a change, and will + then reallocate the stream buffers, and call <code>register_stream_buffers()</code> again + before using buffers from that stream in a request.</p> +<p>If a currently-active stream is not included in <code>stream_list</code>, the HAL may safely + remove any references to that stream. It will not be reused in a later + <code>configure()</code> call by the framework, and all the gralloc buffers for it will be + freed after the <code>configure_streams()</code> call returns.</p> +<p>The <code>stream_list</code> structure is owned by the framework, and may not be accessed +once this call completes. The address of an individual <code>camera3streamt</code> + structure will remain valid for access by the HAL until the end of the first + <code>configure_stream()</code> call which no longer includes that <code>camera3streamt</code> in the + <code>stream_list</code> argument. The HAL may not change values in the stream structure + outside of the private pointer, except for the usage and maxbuffers members + during the <code>configure_streams()</code> call itself.</p> +<p>If the stream is new, the usage, maxbuffer, and private pointer fields of the + stream structure will all be set to 0. The HAL device must set these fields + before the <code>configure_streams()</code> call returns. These fields are then used by the + framework and the platform gralloc module to allocate the gralloc buffers for + each stream.</p> +<p>Before such a new stream can have its buffers included in a capture request, the +framework will call <code>register_stream_buffers()</code> with that stream. However, the + framework is not required to register buffers for _all streams before + submitting a request. This allows for quick startup of (for example) a preview stream, with allocation for other streams happening later or concurrently.</p> <h4><strong>Preconditions</strong></h4> -<p>The framework will only call this method when no captures are being processed. - That is, all results have been returned to the framework, and all in-flight - input and output buffers have been returned and their release sync fences have - been signaled by the HAL. The framework will not submit new requests for capture - while the configure_streams() call is underway.</p> +<p>The framework will only call this method when no captures are being processed. + That is, all results have been returned to the framework, and all in-flight + input and output buffers have been returned and their release sync fences have + been signaled by the HAL. The framework will not submit new requests for capture + while the <code>configure_streams()</code> call is underway.</p> <h4><strong>Postconditions</strong></h4> -<p>The HAL device must configure itself to provide maximum possible output frame - rate given the sizes and formats of the output streams, as documented in the +<p>The HAL device must configure itself to provide maximum possible output frame + rate given the sizes and formats of the output streams, as documented in the camera device's static metadata.</p> <h4><strong>Performance expectations</strong></h4> -<p>This call is expected to be heavyweight and possibly take several hundred - milliseconds to complete, since it may require resetting and reconfiguring the - image sensor and the camera processing pipeline. Nevertheless, the HAL device - should attempt to minimize the reconfiguration delay to minimize the - user-visible pauses during application operational mode changes (such as +<p>This call is expected to be heavyweight and possibly take several hundred + milliseconds to complete, since it may require resetting and reconfiguring the + image sensor and the camera processing pipeline. Nevertheless, the HAL device + should attempt to minimize the reconfiguration delay to minimize the + user-visible pauses during application operational mode changes (such as switching from still capture to video recording).</p> <h4><strong>Return values</strong></h4> <ul> - <li>0: On successful stream configuration</li> - <li>undefined</li> - <li>-EINVAL: If the requested stream configuration is invalid. Some examples of + <li><code>0</code>: On successful stream configuration</li> + <li><code>undefined</code></li> + <li><code>-EINVAL</code>: If the requested stream configuration is invalid. Some examples of invalid stream configurations include: <ul> - <li>Including more than 1 input-capable stream (INPUT or BIDIRECTIONAL)</li> - <li>Not including any output-capable streams (OUTPUT or BIDIRECTIONAL)</li> - <li>Including streams with unsupported formats, or an unsupported size for + <li>Including more than 1 input-capable stream (<code>INPUT</code> or <code>BIDIRECTIONAL</code>)</li> + <li>Not including any output-capable streams (<code>OUTPUT</code> or <code>BIDIRECTIONAL</code>)</li> + <li>Including streams with unsupported formats, or an unsupported size for that format.</li> <li>Including too many output streams of a certain format.</li> - <li>Note that the framework submitting an invalid stream configuration is not - normal operation, since stream configurations are checked before - configure. An invalid configuration means that a bug exists in the - framework code, or there is a mismatch between the HAL's static metadata + <li>Note that the framework submitting an invalid stream configuration is not + normal operation, since stream configurations are checked before + configure. An invalid configuration means that a bug exists in the + framework code, or there is a mismatch between the HAL's static metadata and the requirements on streams.</li> </ul> </li> - <li>-ENODEV: If there has been a fatal error and the device is no longer - operational. Only close() can be called successfully by the framework after + <li><code>-ENODEV</code>: If there has been a fatal error and the device is no longer + operational. Only <code>close()</code> can be called successfully by the framework after this error is returned.</li> </ul> <h3 id="register-stream">register_stream_buffers</h3> -<p>Register buffers for a given stream with the HAL device. This method is called - by the framework after a new stream is defined by configure_streams, and before - buffers from that stream are included in a capture request. If the same stream - is listed in a subsequent configure_streams() call, register_stream_buffers will - not be called again for that stream.<br/> - The framework does not need to register buffers for all configured streams - before it submits the first capture request. This allows quick startup for - preview (or similar use cases) while other streams are still being allocated.<br/> - This method is intended to allow the HAL device to map or otherwise prepare the - buffers for later use. The buffers passed in will already be locked for use. At - the end of the call, all the buffers must be ready to be returned to the stream. - The bufferset argument is only valid for the duration of this call.<br/> - If the stream format was set to HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED, the - camera HAL should inspect the passed-in buffers here to determine any +<p>Register buffers for a given stream with the HAL device. This method is called +by the framework after a new stream is defined by <code>configure_streams</code>, and before + buffers from that stream are included in a capture request. If the same stream + is listed in a subsequent <code>configure_streams()</code> call, <code>register_stream_buffers</code> will + not be called again for that stream.</p> +<p>The framework does not need to register buffers for all configured streams + before it submits the first capture request. This allows quick startup for + preview (or similar use cases) while other streams are still being allocated.</p> +<p>This method is intended to allow the HAL device to map or otherwise prepare the + buffers for later use. The buffers passed in will already be locked for use. At + the end of the call, all the buffers must be ready to be returned to the stream. + The bufferset argument is only valid for the duration of this call.</p> +<p>If the stream format was set to <code>HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED</code>, the + camera HAL should inspect the passed-in buffers here to determine any platform-private pixel format information.</p> <h4><strong>Return values</strong></h4> <ul> - <li>0: On successful registration of the new stream buffers</li> - <li>-EINVAL: If the streambufferset does not refer to a valid active stream, or + <li><code>0</code>: On successful registration of the new stream buffers</li> + <li><code>-EINVAL</code>: If the streambufferset does not refer to a valid active stream, or if the buffers array is invalid.</li> - <li>-ENOMEM: If there was a failure in registering the buffers. The framework must - consider all the stream buffers to be unregistered, and can try to register + <li><code>-ENOMEM</code>: If there was a failure in registering the buffers. The framework must + consider all the stream buffers to be unregistered, and can try to register again later.</li> - <li>-ENODEV: If there is a fatal error, and the device is no longer operational. - Only close() can be called successfully by the framework after this error is + <li><code>-ENODEV</code>: If there is a fatal error, and the device is no longer operational. + Only <code>close()</code> can be called successfully by the framework after this error is returned.</li> </ul> diff --git a/en/devices/camera/camera3_requests_methods.html b/en/devices/camera/camera3_requests_methods.html index d75376f3..55c0db6b 100644 --- a/en/devices/camera/camera3_requests_methods.html +++ b/en/devices/camera/camera3_requests_methods.html @@ -25,94 +25,94 @@ <h2 id="request-creation">Request creation and submission</h2> <h3 id="default-settings">construct_default_request_settings</h3> -<p>Create capture settings for standard camera use cases. The device must return a - settings buffer that is configured to meet the requested use case, which must be - one of the CAMERA3_TEMPLATE_* enums. All request control fields must be - included.<br/> - The HAL retains ownership of this structure, but the pointer to the structure - must be valid until the device is closed. The framework and the HAL may not - modify the buffer once it is returned by this call. The same buffer may be +<p>Create capture settings for standard camera use cases. The device must return a + settings buffer that is configured to meet the requested use case, which must be + one of the <code>CAMERA3_TEMPLATE_*</code> enums. All request control fields must be + included.</p> +<p>The HAL retains ownership of this structure, but the pointer to the structure + must be valid until the device is closed. The framework and the HAL may not + modify the buffer once it is returned by this call. The same buffer may be returned for subsequent calls for the same template, or for other templates.</p> <h4><strong>Return values</strong></h4> <ul> <li>Valid metadata: On successful creation of a default settings buffer.</li> - <li>NULL: In case of a fatal error. After this is returned, only the close() + <li><code>NULL</code>: In case of a fatal error. After this is returned, only the <code>close()</code> method can be called successfully by the framework.</li> </ul> <h3 id="process-request">process_capture_request</h3> -<p>Send a new capture request to the HAL. The HAL should not return from this call - until it is ready to accept the next request to process. Only one call to - process_capture_request() will be made at a time by the framework, and the calls - will all be from the same thread. The next call to process_capture_request() - will be made as soon as a new request and its associated buffers are available. - In a normal preview scenario, this means the function will be called again by - the framework almost instantly.<br/> - The actual request processing is asynchronous, with the results of capture being - returned by the HAL through the process_capture_result() call. This call - requires the result metadata to be available, but output buffers may simply - provide sync fences to wait on. Multiple requests are expected to be in flight - at once, to maintain full output frame rate.<br/> - The framework retains ownership of the request structure. It is only guaranteed - to be valid during this call. The HAL device must make copies of the information - it needs to retain for the capture processing. The HAL is responsible for - waiting on and closing the buffers' fences and returning the buffer handles to - the framework.<br/> - The HAL must write the file descriptor for the input buffer's release sync fence - into input_buffer->release_fence, if input_buffer is not NULL. If the HAL - returns -1 for the input buffer release sync fence, the framework is free to - immediately reuse the input buffer. Otherwise, the framework will wait on the +<p>Send a new capture request to the HAL. The HAL should not return from this call + until it is ready to accept the next request to process. Only one call to + <code>process_capture_request()</code> will be made at a time by the framework, and the calls + will all be from the same thread. The next call to <code>process_capture_request()</code> + will be made as soon as a new request and its associated buffers are available. + In a normal preview scenario, this means the function will be called again by + the framework almost instantly.</p> +<p>The actual request processing is asynchronous, with the results of capture being +returned by the HAL through the <code>process_capture_result()</code> call. This call + requires the result metadata to be available, but output buffers may simply + provide sync fences to wait on. Multiple requests are expected to be in flight + at once, to maintain full output frame rate.</p> +<p>The framework retains ownership of the request structure. It is only guaranteed + to be valid during this call. The HAL device must make copies of the information + it needs to retain for the capture processing. The HAL is responsible for + waiting on and closing the buffers' fences and returning the buffer handles to + the framework.</p> + The HAL must write the file descriptor for the input buffer's release sync fence + into <code>input_buffer</code>-><code>release_fence</code>, if <code>input_buffer</code> is not <code>NULL</code>. If the HAL + returns <code>-1</code> for the input buffer release sync fence, the framework is free to + immediately reuse the input buffer. Otherwise, the framework will wait on the sync fence before refilling and reusing the input buffer.</p> <h4><strong>Return values</strong></h4> <ul> - <li>0: On a successful start to processing the capture request</li> - <li>-EINVAL: If the input is malformed (the settings are NULL when not allowed, - there are 0 output buffers, etc) and capture processing cannot start. Failures - during request processing should be handled by calling - camera3_callback_ops_t.notify(). In case of this error, the framework will - retain responsibility for the stream buffers' fences and the buffer handles; - the HAL should not close the fences or return these buffers with - process_capture_result.</li> - <li>-ENODEV: If the camera device has encountered a serious error. After this - error is returned, only the close() method can be successfully called by the + <li><code>0</code>: On a successful start to processing the capture request</li> + <li><code>-EINVAL</code>: If the input is malformed (the settings are <code>NULL</code> when not allowed, + there are 0 output buffers, etc) and capture processing cannot start. Failures + during request processing should be handled by calling + <code>camera3_callback_ops_t.notify()</code>. In case of this error, the framework will + retain responsibility for the stream buffers' fences and the buffer handles; + the HAL should not close the fences or return these buffers with + <code>process_capture_result</code>.</li> + <li><code>-ENODEV</code>: If the camera device has encountered a serious error. After this + error is returned, only the <code>close()</code> method can be successfully called by the framework.</li> </ul> <h2 id="misc-methods">Miscellaneous methods</h2> <h3 id="get-metadata">get_metadata_vendor_tag_ops</h3> -<p>Get methods to query for vendor extension metadata tag information. The HAL - should fill in all the vendor tag operation methods, or leave ops unchanged if - no vendor tags are defined. The definition of vendor_tag_query_ops_t can be - found in system/media/camera/include/system/camera_metadata.h.</p> +<p>Get methods to query for vendor extension metadata tag information. The HAL + should fill in all the vendor tag operation methods, or leave ops unchanged if + no vendor tags are defined. The definition of <code>vendor_tag_query_ops_t</code> can be + found in <code>system/media/camera/include/system/camera_metadata.h</code>.</p> <h3 id="dump">dump</h3> -<p>Print out debugging state for the camera device. This will be called by the - framework when the camera service is asked for a debug dump, which happens when - using the dumpsys tool, or when capturing a bugreport. The passed-in file - descriptor can be used to write debugging text using dprintf() or write(). The +<p>Print out debugging state for the camera device. This will be called by the + framework when the camera service is asked for a debug dump, which happens when + using the dumpsys tool, or when capturing a bugreport. The passed-in file + descriptor can be used to write debugging text using <code>dprintf()</code> or <code>write()</code>. The text should be in ASCII encoding only.</p> <h3 id="flush">flush</h3> -<p>Flush all currently in-process captures and all buffers in the pipeline on the - given device. The framework will use this to dump all state as quickly as - possible in order to prepare for a configure_streams() call.<br/> - No buffers are required to be successfully returned, so every buffer held at the - time of flush() (whether successfully filled or not) may be returned with - CAMERA3_BUFFER_STATUS_ERROR. Note the HAL is still allowed to return valid - (STATUS_OK) buffers during this call, provided they are successfully filled.<br/> - All requests currently in the HAL are expected to be returned as soon as - possible. Not-in-process requests should return errors immediately. Any - interruptible hardware blocks should be stopped, and any uninterruptible blocks - should be waited on.<br/> - flush() should only return when there are no more outstanding buffers or - requests left in the HAL. The framework may call configure_streams (as the HAL - state is now quiesced) or may issue new requests.<br/> - A flush() call should only take 100ms or less. The maximum time it can take is 1 +<p>Flush all currently in-process captures and all buffers in the pipeline on the + given device. The framework will use this to dump all state as quickly as + possible in order to prepare for a <code>configure_streams()</code> call.</p> +<p>No buffers are required to be successfully returned, so every buffer held at the +time of <code>flush()</code> (whether successfully filled or not) may be returned with +<code>CAMERA3_BUFFER_STATUS_ERROR</code>. Note the HAL is still allowed to return valid +(<code>STATUS_OK</code>) buffers during this call, provided they are successfully filled.</p> +<p>All requests currently in the HAL are expected to be returned as soon as + possible. Not-in-process requests should return errors immediately. Any + interruptible hardware blocks should be stopped, and any uninterruptible blocks + should be waited on.</p> +<p><code>flush()</code> should only return when there are no more outstanding buffers or +requests left in the HAL. The framework may call <code>configure_streams</code> (as the HAL + state is now quiesced) or may issue new requests.</p> +<p>A <code>flush()</code> call should only take 100ms or less. The maximum time it can take is 1 second.</p> <h4><strong>Version information</strong></h4> -<p>This is available only if device version >= CAMERA_DEVICE_API_VERSION_3_1.</p> +<p>This is available only if device version >= <code>CAMERA_DEVICE_API_VERSION_3_1</code>.</p> <h4><strong>Return values</strong></h4> <ul> - <li>0: On a successful flush of the camera HAL.</li> - <li>-EINVAL: If the input is malformed (the device is not valid).</li> - <li>-ENODEV: If the camera device has encountered a serious error. After this - error is returned, only the close() method can be successfully called by the + <li><code>0</code>: On a successful flush of the camera HAL.</li> + <li><code>-EINVAL</code>: If the input is malformed (the device is not valid).</li> + <li><code>-ENODEV</code>: If the camera device has encountered a serious error. After this + error is returned, only the <code>close()</code> method can be successfully called by the framework.</li> </ul> diff --git a/en/devices/camera/index.html b/en/devices/camera/index.html index dfa557ec..c48e07bd 100644 --- a/en/devices/camera/index.html +++ b/en/devices/camera/index.html @@ -133,7 +133,7 @@ directory to contain your library's source files.</li> <li>Create an <code>Android.mk</code> file to build the shared library. Ensure the Makefile contains the following lines: -<pre> +<pre class="devsite-click-to-copy"> LOCAL_MODULE := camera.<device_name> LOCAL_MODULE_RELATIVE_PATH := hw </pre> @@ -148,7 +148,7 @@ device's Makefile. For example, to specify your device has a camera flash and can autofocus, add the following lines in your device's <code><device>/<company_name>/<device_name>/device.mk</code> Makefile: -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> PRODUCT_COPY_FILES := \ ... PRODUCT_COPY_FILES += \ @@ -168,7 +168,7 @@ framework</a>.</li> <code>device/<company_name>/<device_name>/device.mk</code> Makefile to copy the <code>media_profiles.xml</code> and <code>media_codecs.xml</code> files to the appropriate location: -<pre> +<pre class="devsite-click-to-copy"> # media config xml file PRODUCT_COPY_FILES += \ <device>/<company>/<device>/media_profiles.xml:system/etc/media_profiles.xml @@ -182,7 +182,7 @@ PRODUCT_COPY_FILES += \ <code>PRODUCT_PACKAGES</code> variable in your device's <code>device/<company>/<device>/device.mk</code> Makefile: -<pre> +<pre class="devsite-click-to-copy"> PRODUCT_PACKAGES := \ Gallery2 \ ... diff --git a/en/devices/drm.html b/en/devices/drm.html index a9bfcbf4..42ab3280 100644 --- a/en/devices/drm.html +++ b/en/devices/drm.html @@ -46,7 +46,7 @@ from DRM-protected or non-protected content. See <a href="https://developer.android.com/reference/android/media/MediaDrm.html">MediaDrm</a> for the class to obtain keys for decrypting protected media streams.</p> - <img src="images/ape_fwk_drm.png" alt="Android DRM HAL" /> + <img src="/devices/images/ape_fwk_drm.png" alt="Android DRM HAL" /> <p class="img-caption"><strong>Figure 1.</strong> DRM Hardware Abstraction Layer</p> @@ -121,8 +121,10 @@ and does not have to be aware of each DRM scheme. </p> <p>Plug-ins are loaded automatically when DrmManagerService is launched. As shown in the figure below, the DRM plug-in manager loads/unloads all the available plug-ins. The DRM framework loads plug-ins automatically by finding -them under:<br/> -<code>/system/lib/drm/plugins/native/</code></p> +them under:</p> +<pre class="devsite-click-to-copy"> +/system/lib/drm/plugins/native/ +</pre> <img src="images/ape_fwk_drm_plugins_life.png" alt="Android DRM Plug-in Lifecycle" /> @@ -139,9 +141,9 @@ framework plug-in discovery directory. See implementation instructions below for developers must implement the interfaces specified in IDrmEngine and the listener interfaces specified below. The interface definition is available in the source tree at:<p/> -<code> -<platform_root>/frameworks/av/drm/libdrmframework/plugins/common/include -</code> +<pre class="devsite-click-to-copy"> +<var>PLATFORM_ROOT</var>/frameworks/av/drm/libdrmframework/plugins/common/include +</pre> <h3 id="DrmInfo">DRM Info</h3> <p>DrmInfo is a wrapper class that wraps the protocol for communicating with the @@ -151,12 +153,16 @@ The protocol should be described by the plug-in in XML format. Each DRM plug-in would accomplish the transaction by interpreting the protocol. The DRM framework defines an API to retrieve an instance of DrmInfo called acquireDrmInfo().</p> -<code>DrmInfo* acquireDrmInfo(int uniqueId, const DrmInfoRequest* drmInfoRequest);</code> +<pre class="devsite-click-to-copy prettyprint"> +DrmInfo* acquireDrmInfo(int uniqueId, const DrmInfoRequest* drmInfoRequest); +</pre> <p>Retrieves necessary information for registration, deregistration or rights acquisition information. See <a href="http://developer.android.com/reference/android/drm/DrmInfoRequest.html">DrmInfoRequest</a> for more information.</p> -<code>DrmInfoStatus* processDrmInfo(int uniqueId, const DrmInfo* drmInfo);</code> +<pre class="devsite-click-to-copy prettyprint"> +DrmInfoStatus* processDrmInfo(int uniqueId, const DrmInfo* drmInfo); +</pre> <p>processDrmInfo() behaves asynchronously and the results of the transaction can be retrieved either from OnEventListener or OnErrorListener.</p> @@ -167,8 +173,9 @@ of DRM content. Once the association has been made, the license will be handled the DRM framework so the Media Player application is abstracted from the existence of license.</p> -<code>int checkRightsStatus(int uniqueId, const String8& path, int -action);</code> +<pre class="devsite-click-to-copy prettyprint"> +int checkRightsStatus(int uniqueId, const String8& path, int action); +</pre> <p>Check whether the given content has valid rights or not. The input parameters are the content file path where the content was saved and the action @@ -176,7 +183,9 @@ to query rights for, for example: Action::DEFAULT, Action::PLAY. Returns the status of the rights for the protected content, such as RightsStatus::RIGHTS_VALID, RightsStatus::RIGHTS_EXPIRED.</p> -<code>status_t saveRights(int uniqueId, const DrmRights& drmRights, const String8& rightsPath, const String8& contentPath);</code> +<pre class="devsite-click-to-copy prettyprint"> +status_t saveRights(int uniqueId, const DrmRights& drmRights, const String8& rightsPath, const String8& contentPath); +</pre> <p>Save DRM rights to the specified rights path and make association with content path. The input parameters are the DrmRights to be saved, the rights file path where rights @@ -189,8 +198,10 @@ provides APIs to return constraints associated with input content. See <a href="http://developer.android.com/reference/android/drm/DrmManagerClient.html">DrmManagerClient</a> for more information.</p> -<code>DrmConstraints* getConstraints(int uniqueId, const String path, int -action);</code> +<pre class="devsite-click-to-copy prettyprint"> +DrmConstraints* getConstraints(int uniqueId, const String path, int +action); +</pre> <p>The getConstraint function call returns key-value pairs of constraints embedded in protected content. To retrieve the constraints, the uniqueIds (the Unique identifier for a session and path of the protected content) are required. @@ -200,7 +211,9 @@ The action, defined as Action::DEFAULT, Action::PLAY, etc., is also required.</p <p class="img-caption"><strong>Figure 5.</strong> Retrieve license metadata</p> -<code>DrmMetadata* getMetadata(int uniqueId, const String path);</code> +<pre class="devsite-click-to-copy prettyprint"> +DrmMetadata* getMetadata(int uniqueId, const String path); +</pre> <p>Get metadata information associated with input content for a given path of the protected content to return key-value pairs of metadata.</p> @@ -209,10 +222,10 @@ protected content to return key-value pairs of metadata.</p> invoke openDecryptSession() at the beginning of the decryption sequence. openDecryptSession() asks each DRM plug-in if it can handle input DRM content.</p> -<code> +<pre class="devsite-click-to-copy prettyprint"> status_t openDecryptSession( int uniqueId, DecryptHandle* decryptHandle, int fd, off64_t offset, off64_t length); -</code> +</pre> <p>The above call allows you to save DRM rights to specified rights path and make association with content path. DrmRights parameter is the rights to be saved, @@ -234,29 +247,29 @@ transactions.</li> <h3 id="source">Source</h3> <p>The Android DRM framework includes a couple of samples, a passthru plug-in -and a forward lock plug-in, which can be found at:<br/> -<code> -<platform_root>/frameworks/av/drm/libdrmframework/plugins/passthru<br/> -<platform_root>/frameworks/av/drm/libdrmframework/plugins/forward-lock -</code></p> +and a forward lock plug-in, which can be found at:</p> +<pre class="devsite-click-to-copy"> +<var>PLATFORM_ROOT</var>/frameworks/av/drm/libdrmframework/plugins/passthru +<var>PLATFORM_ROOT</var>/frameworks/av/drm/libdrmframework/plugins/forward-lock +</pre> <h3 id="build">Build and Integration</h3> <p>Add the following to the Android.mk of the plug-in implementation. The passthruplugin is used as a sample.</p> -<code> -PRODUCT_COPY_FILES += -$(TARGET_OUT_SHARED_LIBRARIES)/<plugin_library>:system/lib/drm/plugins/native/<plugin_library> -e.g.,<br/> -PRODUCT_COPY_FILES += $(TARGET_OUT_SHARED_LIBRARIES)/ -libdrmpassthruplugin.so:system/lib/drm/plugins/native/libdrmpassthruplugin.so -</code> -<br/> -<br/> +<pre class="devsite-click-to-copy"> +PRODUCT_COPY_FILES += $(TARGET_OUT_SHARED_LIBRARIES)/<var>PLUGIN_LIBRARY</var>:system/lib/drm/plugins/native/<var>PLUGIN_LIBRARY</var> +</pre> +<p>e.g.,</p> +<pre class="devsite-click-to-copy"> +PRODUCT_COPY_FILES += $(TARGET_OUT_SHARED_LIBRARIES)/libdrmpassthruplugin.so:system/lib/drm/plugins/native/libdrmpassthruplugin.so +</pre> <p>Plug-in developers must locate their respective plug-ins under this -directory like so:<br/> -<code>/system/lib/drm/plugins/native/libdrmpassthruplugin.so</code></p> +directory like so:</p> +<pre class="devsite-click-to-copy"> +/system/lib/drm/plugins/native/libdrmpassthruplugin.so +</pre> </body> </html> diff --git a/en/devices/graphics/arch-gameloops.html b/en/devices/graphics/arch-gameloops.html index 574c5a0c..272a779d 100644 --- a/en/devices/graphics/arch-gameloops.html +++ b/en/devices/graphics/arch-gameloops.html @@ -25,7 +25,7 @@ <p>A very popular way to implement a game loop looks like this:</p> -<pre> +<pre class="devsite-click-to-copy"> while (playing) { advance state by one frame render the new frame @@ -130,7 +130,7 @@ game state can be updated quickly.</p> simple game that did nothing but move a block every 100ms, you could have a dedicated thread that just did this:</p> -<pre> +<pre class="devsite-click-to-copy"> run() { Thread.sleep(100); synchronized (mLock) { diff --git a/en/devices/graphics/automate-tests.html b/en/devices/graphics/automate-tests.html index 1cfdf25d..beee449f 100644 --- a/en/devices/graphics/automate-tests.html +++ b/en/devices/graphics/automate-tests.html @@ -22,9 +22,6 @@ --> - -<h2 id=intro>Introduction</h2> - <p>Deqp test modules can be integrated to automated test systems in multiple ways. The best approach depends on the existing test infrastructure and target environment.</p> @@ -67,9 +64,9 @@ The following examples demonstrate how to use the command line Test Executor <h4 id=example_1_run_gles2_functional_tests>Example 1: Run GLES2 functional tests on an Android device:</h4> -<pre> +<pre class="devsite-terminal devsite-click-to-copy"> executor --connect=127.0.0.1 --port=50016 --binaryname= -com.drawelements.deqp/android.app.NativeActivity +com.drawelements.deqp/android.app.NativeActivity --caselistdir=caselists --testset=dEQP-GLES2.* --out=BatchResult.qpa --cmdline="--deqp-crashhandler=enable --deqp-watchdog=enable @@ -78,9 +75,9 @@ com.drawelements.deqp/android.app.NativeActivity <h4 id=example_2_continue_a_partial_opengl>Example 2: Continue a partial OpenGL ES 2 test run locally:</h4> -<pre> +<pre class="devsite-terminal devsite-click-to-copy"> executor --start-server=execserver/execserver --port=50016 ---binaryname=deqp-gles2 --workdir=modules/opengl +--binaryname=deqp-gles2 --workdir=modules/opengl --caselistdir=caselists --testset=dEQP-GLES2.* --exclude=dEQP-GLES2.performance.* --in=BatchResult.qpa --out=BatchResult.qpa @@ -99,14 +96,14 @@ plain-text format can be selected using the following command line argument: <co <h4 id=example_1_export_test_log_in_csv_format>Example 1: Export test log in CSV format</h4> -<pre> -testlog-to-csv --value=code BatchResult.qpa > Result_statuscodes.csv -testlog-to-csv --value=details BatchResult.qpa > Result_statusdetails.csv +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">testlog-to-csv --value=code BatchResult.qpa > Result_statuscodes.csv</code> +<code class="devsite-terminal">testlog-to-csv --value=details BatchResult.qpa > Result_statusdetails.csv</code> </pre> <h4 id=example_2_list_differences>Example 2: List differences of test results between two test logs</h4> -<pre> +<pre class="devsite-terminal devsite-click-to-copy"> testlog-to-csv --mode=diff --format=text Device_v1.qpa Device_v2.qpa </pre> diff --git a/en/devices/graphics/build-tests.html b/en/devices/graphics/build-tests.html index 3e280ab0..6b5049ea 100644 --- a/en/devices/graphics/build-tests.html +++ b/en/devices/graphics/build-tests.html @@ -35,15 +35,14 @@ compiling the test programs.</p> <p>CMake is an open source build system that supports multiple platforms and toolchains. CMake generates native makefiles or IDE project files from -target-independent configuration files. For more information on CMake, -please see the <a href="http://www.cmake.org/cmake/help/documentation.html">CMake</a> documentation.</p> +target-independent configuration files. For more information on CMake, please see the <a href="http://www.cmake.org/cmake/help/documentation.html">CMake</a> documentation.</p> <p>CMake supports and recommends out-of-source-tree builds, i.e., you should always create makefiles or project files in a separate build directory outside the source tree. CMake does not have any kind of "distclean" target, so removing any files generated by CMake must be done manually.</p> -<p>Configuration options are given to CMake using <code>-D<OPTION_NAME>=<VALUE></code> syntax. Some commonly used options for deqp are listed below.</p> +<p>Configuration options are given to CMake using <code>-D<var>OPTION_NAME</var>=<var>VALUE</var></code> syntax. Some commonly used options for deqp are listed below.</p> <table> <tr> @@ -53,9 +52,9 @@ removing any files generated by CMake must be done manually.</p> <tr> <td><code>DEQP_TARGET</code></td> -<td><p>Target name, for example: "android"</p> +<td><p>Target name, for example: "android"</p> <p>The deqp CMake scripts will include the file -<code>targets/<DEQP_TARGET>/<DEQP_TARGET>.cmake</code> and expect to find target-specific build options from there.</p> +<code>targets/<var>DEQP_TARGET</var>/<var>DEQP_TARGET</var>.cmake</code> and expect to find target-specific build options from there.</p> </td> </tr> <tr> @@ -64,7 +63,7 @@ removing any files generated by CMake must be done manually.</p> </tr> <tr> <td><code>CMAKE_BUILD_TYPE</code></td> -<td><p>Build type for makefile targets. Valid values are: "Debug" and "Release"</p> +<td><p>Build type for makefile targets. Valid values are: "Debug" and "Release"</p> <p>Note the interpretation and default type depend on the targeted build system. See the CMake documentation for details.</p> </td> @@ -75,9 +74,9 @@ See the CMake documentation for details.</p> <p>The deqp build system is configured for new targets using target build files. A target build file defines which features the platform supports and what libraries or -additional include paths are required. Target file names follow the <code>targets/<name>/<name>.cmake</code> format and the target is selected using the <code>DEQP_TARGET</code> build parameter.</p> +additional include paths are required. Target file names follow the <code>targets/<var>NAME</var>/<var>NAME</var>.cmake</code> format and the target is selected using the <code>DEQP_TARGET</code> build parameter.</p> -<p>File paths in target files are relative to the base <code>deqp</code> directory, not the <code>targets/<name></code> directory. The following standard variables can be set by target build file.</p> +<p>File paths in target files are relative to the base <code>deqp</code> directory, not the <code>targets/<var>NAME</var></code> directory. The following standard variables can be set by target build file.</p> <table> <tr> @@ -173,14 +172,14 @@ compiler. The deqp has been tested with Visual Studio 2013.</p> <p>Visual Studio project files can be generated with the following command:</p> -<pre> +<pre class="devsite-terminal devsite-click-to-copy"> cmake path\to\src\deqp -G "Visual Studio 12" </pre> -<p>A 64-bit build can be made by selecting "Visual Studio <ver> Win64" as the build +<p>A 64-bit build can be made by selecting "Visual Studio <var>VERSION</var> Win64" as the build generator:</p> -<pre> +<pre class="devsite-terminal devsite-click-to-copy"> cmake path\to\src\deqp -G "Visual Studio 12 Win64" </pre> @@ -223,7 +222,7 @@ Build-tools <a href="http://developer.android.com/sdk/index.html#Other">packages <li><a href="https://www.python.org/downloads/">Python 2.6</a> or newer in 2.x series; Python 3.x is not supported <li>For Windows: Either NMake or JOM in <code>PATH</code> <ul> - <li><a href="http://qt-project.org/wiki/jom">JOM</a> enables faster builds + <li><a href="http://qt-project.org/wiki/jom">JOM</a> enables faster builds </ul> <li> Optional: Ninja make is also supported on Linux </ul> @@ -231,7 +230,7 @@ Build-tools <a href="http://developer.android.com/sdk/index.html#Other">packages <p>Ant and SDK binaries are located based on the PATH environment variable with certain overriding defaults. The logic is controlled by <code>android/scripts/common.py</code>. </p> -<p>The NDK directory must be either <code>~/android-ndk-<version></code> or <code>C:/android/android-ndk-<version></code> or defined via the <code>ANDROID_NDK_PATH</code> environment variable.</p> +<p>The NDK directory must be either <code>~/android-ndk-<var>VERSION</var></code> or <code>C:/android/android-ndk-<var>VERSION</var></code> or defined via the <code>ANDROID_NDK_PATH</code> environment variable.</p> <p>Deqp on-device components, the test execution service, and test programs are built by executing the <code>android/scripts/build.py</code> script. The final .apk is created in <code>android/package/bin</code> and can be installed by the <code>install.py</code> script. If the <a href="port-tests.html#test_execution_service">command line executor</a> is used, the ExecService is launched with <code>launch.py</code> script on the device via ADB. The scripts can be executed from any directory.</p> @@ -283,12 +282,12 @@ x11_egl_glx</code></td> <p>An example of a full command line used to do a 32-bit debug build against driver headers and libraries in a custom location is the following:</p> -<pre> -$ cmake <path to src>/deqp -DDEQP_TARGET=x11_egl -DCMAKE_C_FLAGS="-m32" +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">cmake <path to src>/deqp -DDEQP_TARGET=x11_egl -DCMAKE_C_FLAGS="-m32" -DCMAKE_CXX_FLAGS="-m32" -DCMAKE_BUILD_TYPE=Debug --DCMAKE_LIBRARY_PATH="<path to driver>/lib" --DCMAKE_INCLUDE_PATH="<path to driver>/inc" -$ make -j4 +-DCMAKE_LIBRARY_PATH="<var>PATH_TO_DRIVER</var>/lib" +-DCMAKE_INCLUDE_PATH="<var>PATH_TO_DRIVER</var>/inc"</code> +<code class="devsite-terminal">make -j4</code> </pre> <h2 id=cross-compiling>Cross-compiling</h2> @@ -334,10 +333,10 @@ DE_PTR_SIZE</code></td> <p>The toolchain file can be selected using the <code>CMAKE_TOOLCHAIN_FILE</code> build parameter. For example, the following would create makefiles for a build using the CodeSourcery cross-compiler for ARM/Linux:</p> -<pre> -cmake <path to src>/deqp –DDEQP_BUILD_TYPE="Release" -–DCMAKE_TOOLCHAIN_FILE=<path to src>/delibs/cmake/toolchain-arm-cs.cmake -–DARM_CC_BASE=<path to cc directory> +<pre class="devsite-terminal devsite-click-to-copy"> +cmake <var>PATH_TO_SRC</var>/deqp –DDEQP_BUILD_TYPE="Release" +–DCMAKE_TOOLCHAIN_FILE=<var>PATH_TO_SRC</var>/delibs/cmake/toolchain-arm-cs.cmake +–DARM_CC_BASE=<var>PATH_TO_CC_DIRECTORY</var> </pre> <h2 id=run-time_linking_of_gles_and_egl_libraries>Run-time linking of GLES and EGL libraries</h2> diff --git a/en/devices/graphics/cts-integration.html b/en/devices/graphics/cts-integration.html index 89169ee9..cf105b19 100644 --- a/en/devices/graphics/cts-integration.html +++ b/en/devices/graphics/cts-integration.html @@ -35,8 +35,8 @@ files can be found under the <code>android/cts</code> directory in the deqp source tree. You can run deqp tests through the <code>cts-tradefed</code> utility with the following command:</p> -<pre> -$ cts-tradefed run cts --plan CTS-DEQP +<pre class="devsite-terminal devsite-click-to-copy"> +cts-tradefed run cts --plan CTS-DEQP </pre> <h2 id=duplicating_runs_without_cts>Duplicating runs without CTS</h2> @@ -44,8 +44,8 @@ $ cts-tradefed run cts --plan CTS-DEQP <p>To replicate the CTS run, install the deqp APK of the CTS package and use the following command:</p> -<pre> -$ adb -d shell am start -n com.drawelements.deqp/android.app.NativeActivity -e \ +<pre class="devsite-terminal devsite-click-to-copy"> +adb -d shell am start -n com.drawelements.deqp/android.app.NativeActivity -e \ cmdLine "deqp --deqp-case=dEQP-GLES3.some_group.* --deqp-gl-config-name=rgba8888d24s8 --deqp-log-filename=/sdcard/dEQP-Log.qpa </pre> diff --git a/en/devices/graphics/implement-hwc.html b/en/devices/graphics/implement-hwc.html index 76c58f55..903d335e 100644 --- a/en/devices/graphics/implement-hwc.html +++ b/en/devices/graphics/implement-hwc.html @@ -206,7 +206,7 @@ composition. SurfaceFlinger may choose to:</p> <li>Change some of the layer composition types and re-validate the display.</li> </ul> -<blockquote><strong><em>OR</strong></em></blockquote> +<em><strong>OR</strong></em> <ul> <li>Call <code>acceptDisplayChanges</code>, which has the same effect as @@ -252,7 +252,7 @@ they are currently performed sequentially for all active displays, even if only the contents of one display are updated.</p> <p>For example, if only the external display is updated, the sequence is:</p> -<pre> +<pre class="devsite-click-to-copy"> // Update state for internal display // Update state for external display validateDisplay(<internal display>) diff --git a/en/devices/graphics/implement-vsync.html b/en/devices/graphics/implement-vsync.html index 9fa1252b..828d8d1c 100644 --- a/en/devices/graphics/implement-vsync.html +++ b/en/devices/graphics/implement-vsync.html @@ -32,7 +32,9 @@ visual performance of graphics.</p> <p>The Hardware Composer (HWC) has a function pointer indicating the function to implement for VSYNC:</p> -<pre class=prettyprint> int (waitForVsync*) (int64_t *timestamp) </pre> +<pre class="prettyprint"> +int (waitForVsync*) (int64_t *timestamp) +</pre> <p>This function blocks until a VSYNC occurs and returns the timestamp of the actual VSYNC. A message must be sent every time VSYNC occurs. A client can @@ -179,7 +181,7 @@ synchronization framework existed, this function would receive dma-bufs, put those buffers on the display, and block while the buffer is visible. For example:</p> -<pre class=prettyprint> +<pre class="prettyprint"> /* * assumes buf is ready to be displayed. returns when buffer is no longer on * screen. @@ -197,7 +199,7 @@ own fence, which is a guarantee of when the buffer will be off of the display. As you queue up buffers, the kernel will list dependencies with the synchronization framework:</p> -<pre class=prettyprint> +<pre class="prettyprint"> /* * will display buf when fence is signaled. returns immediately with a fence * that will signal when buf is no longer displayed. diff --git a/en/devices/graphics/implement-vulkan.html b/en/devices/graphics/implement-vulkan.html index ca5c1a08..918343e1 100644 --- a/en/devices/graphics/implement-vulkan.html +++ b/en/devices/graphics/implement-vulkan.html @@ -81,7 +81,7 @@ for discovering and loading the driver. Preferred paths for 32-bit and 64-bit Vulkan drivers are:</p> <p> -<pre> +<pre class="devsite-click-to-copy"> /vendor/lib/hw/vulkan.<ro.product.platform>.so /vendor/lib64/hw/vulkan.<ro.product.platform>.so </pre> @@ -176,7 +176,7 @@ the platform asks the driver to translate the requested format and image usage flags into gralloc usage flags by calling:</p> <p> -<pre> +<pre class="devsite-click-to-copy"> VkResult VKAPI vkGetSwapchainGrallocUsageANDROID( VkDevice device, VkFormat format, @@ -203,7 +203,7 @@ VK_SWAP_CHAIN_INFO_TYPE_IMAGES_WSI ..)</code>. The WSI implementation allocates the number of native buffers requested for the swapchain, then creates a <code>VkImage</code> for each one:</p> -<p><pre> +<pre class="devsite-click-to-copy"> typedef struct { VkStructureType sType; // must be VK_STRUCTURE_TYPE_NATIVE_BUFFER_ANDROID const void* pNext; @@ -216,12 +216,12 @@ typedef struct { int format; int usage; } VkNativeBufferANDROID; -</pre></p> +</pre> <p>When creating a gralloc-backed image, the <code>VkImageCreateInfo</code> has the following data:</p> -<p><pre> +<pre class="devsite-click-to-copy"> .imageType = VK_IMAGE_TYPE_2D .format = a VkFormat matching the format requested for the gralloc buffer .extent = the 2D dimensions requested for the gralloc buffer @@ -241,7 +241,7 @@ the following data:</p> and imports an externally-signalled native fence into both an existing <code>VkSemaphore</code> object and an existing <code>VkFence</code> object:</p> -<p><pre> +<pre class="devsite-click-to-copy"> VkResult VKAPI vkAcquireImageANDROID( VkDevice device, VkImage image, @@ -249,7 +249,7 @@ VkResult VKAPI vkAcquireImageANDROID( VkSemaphore semaphore, VkFence fence ); -</pre></p> +</pre> <p>This function is called during <code>vkAcquireNextImageWSI</code> to import a native fence into the <code>VkSemaphore</code> and <code>VkFence</code> objects @@ -274,13 +274,13 @@ it is as if the native fence was already signalled.</p> external use, and creates a native fence and schedules it to be signalled when prior work on the queue has completed:</p> -<p><pre> +<pre class="devsite-click-to-copy"> VkResult VKAPI vkQueueSignalReleaseImageANDROID( VkQueue queue, VkImage image, int* pNativeFenceFd ); -</pre></p> +</pre> <p>This API is called during <code>vkQueuePresentWSI</code> on the provided queue. Effects are similar to <code>vkQueueSignalSemaphore</code>, except with a diff --git a/en/devices/graphics/run-tests.html b/en/devices/graphics/run-tests.html index f7846a61..b0d043b2 100644 --- a/en/devices/graphics/run-tests.html +++ b/en/devices/graphics/run-tests.html @@ -209,19 +209,19 @@ the full name of each test on a separate line in a standard ASCII file. As the test sets grow, the repetitive prefixes can be cumbersome. To avoid repeating the prefixes, use a trie (also known as a prefix tree) syntax shown below.</p> -<pre> +<pre class="devsite-click-to-copy"> {nodeName{firstChild{…},…lastChild{…}}} </pre> <p>For example:</p> -<pre> +<pre class="devsite-click-to-copy"> {dEQP-EGL{config-list,create_context{rgb565_depth_stencil}}} </pre> <p>Translates into the following two test cases:</p> -<pre> +<pre class="devsite-click-to-copy"> dEQP-EGL.config_list dEQP-EGL.create_context.rgb565_depth_stencil </pre> @@ -235,20 +235,22 @@ a <code>NativeActivity</code> that uses EGL (requires Android 3.2 or higher).</p <p>The application package can be installed with the following command (name shown is the name of the APK in the Android CTS package; which name depends on the build):</p> -<pre>$ adb –d install –r com.drawelements.deqp.apk</pre> +<pre class="devsite-terminal devsite-click-to-copy"> +adb –d install –r com.drawelements.deqp.apk +</pre> <p>To launch the test execution service and to setup port forwarding, use the following:</p> -<pre> -$ adb –d forward tcp:50016 tcp:50016 -$ adb –d shell am start –n com.drawelements.deqp/.execserver.ServiceStarter +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb –d forward tcp:50016 tcp:50016</code> +<code class="devsite-terminal">adb –d shell am start –n com.drawelements.deqp/.execserver.ServiceStarter</code> </pre> <p>Debug prints can be enabled by executing the following before starting the tests:</p> -<pre> -$ adb –d shell setprop log.tag.dEQP DEBUG +<pre class="devsite-terminal devsite-click-to-copy"> +adb –d shell setprop log.tag.dEQP DEBUG </pre> <h3 id=executing_tests_on_android_without_android_cts>Executing tests on @@ -267,7 +269,8 @@ log.</p> utility. For example, to run <code>dEQP-GLES2.info</code> tests on a platform supporting <code>NativeActivity,</code> use the following commands.</p> -<pre>$ adb -d shell am start -n com.drawelements.deqp/android.app.NativeActivity -e \ +<pre class="devsite-terminal devsite-click-to-copy"> +adb -d shell am start -n com.drawelements.deqp/android.app.NativeActivity -e \ cmdLine "deqp --deqp-case=dEQP-GLES2.info.* --deqp-log-filename=/sdcard/dEQP-Log.qpa </pre> @@ -276,15 +279,16 @@ cmdLine "deqp --deqp-case=dEQP-GLES2.info.* --deqp-log-filename=/sdcard/dEQP-Log <p>To run the tests under the GDB debugger on Android, first compile and install the debug build by running the following two scripts:</p> -<pre> -$ python android/scripts/build.py --native-build-type=Debug -$ python android/scripts/install.py +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">python android/scripts/build.py --native-build-type=Debug</code> +<code class="devsite-terminal">python android/scripts/install.py</code> </pre> <p>After the debug build is installed on the device, to launch the tests under GDB running on the host, run the following command:</p> -<pre>$ python android/scripts/debug.py \ +<pre class="devsite-terminal devsite-click-to-copy"> +python android/scripts/debug.py \ --deqp-commandline="--deqp-log-filename=/sdcard/TestLog.qpa --deqp-case=dEQP-GLES2.functional.*" </pre> @@ -310,8 +314,7 @@ line parameters should be enough.</p> <code><path-to-ndk>/prebuilt/windows/bin</code> to the PATH variable.</p> <p class="note"><strong>Note:</strong> Native code debugging does not work on -stock Android 4.3; for workarounds, refer to -<a href="https://code.google.com/p/android/issues/detail?id=58373">https://code.google.com/p/android/issues/detail?id=58373</a>. +stock Android 4.3; for workarounds, refer to <a href="https://issuetracker.google.com/issues/36976703">this public bug</a>. Android 4.4 and higher do not contain this bug.</p> </body> diff --git a/en/devices/graphics/test-groups.html b/en/devices/graphics/test-groups.html index 943c1140..e39ac440 100644 --- a/en/devices/graphics/test-groups.html +++ b/en/devices/graphics/test-groups.html @@ -35,14 +35,14 @@ allocating certain resources until the driver reports an out-of-memory error.</p can occur: The operating system may kill the test process instead of allowing a driver to handle or otherwise provide an out-of-memory error. On such platforms, tests that are designed to cause out-of-memory errors are disabled -by default, and must be enabled using the <code>--deqp-test-oom=enable</code> command line argument. +by default, and must be enabled using the <code>--deqp-test-oom=enable</code> command line argument. It is recommended that you run such tests manually to check if the system behaves correctly under resource pressure. However, in such a situation, a test process crash should be interpreted as a pass.</p> <h3 id=test_groups>Test groups</h3> -<pre> +<pre class="devsite-click-to-copy"> dEQP-GLES2.stress.memory.* dEQP-GLES3.stress.memory.* </pre> @@ -55,7 +55,7 @@ they can be configured to run indefinitely by supplying the <code>--deqp-test-it <h3 id=test_groups2>Test groups</h3> -<pre> +<pre class="devsite-click-to-copy"> dEQP-GLES2.stress.long.* dEQP-GLES3.stress.long.* </pre> diff --git a/en/devices/input/diagnostics.html b/en/devices/input/diagnostics.html index bd5036df..92780018 100644 --- a/en/devices/input/diagnostics.html +++ b/en/devices/input/diagnostics.html @@ -29,8 +29,8 @@ processing of input events.</p> <h2 id="input">Input</h2> <p>To dump the input system’s state, run the following command:</p> -<pre> -$ adb shell dumpsys input +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell dumpsys input </pre> <h2 id="output">Output</h2> @@ -46,7 +46,7 @@ but consists of three sections:</p> <h3 id="event_hub_state">Event Hub State</h3> -<pre><code> +<pre class="devsite-click-to-copy"> INPUT MANAGER (dumpsys input) Event Hub State: @@ -171,7 +171,7 @@ the touch screen.</p> <p>As an example, this is what a special function keypad looks like:</p> -<pre> +<pre class="devsite-click-to-copy"> Input Reader State ... Device 3: tuna-gpio-keypad @@ -192,7 +192,7 @@ Input Reader State <p>Here is a touch screen. Notice all of the information about the resolution of the device and the calibration parameters that were used.</p> -<pre> +<pre class="devsite-click-to-copy"> Input Reader State ... Device 6: Melfas MMSxxx Touchscreen @@ -264,7 +264,8 @@ Input Reader State <p>Here is an external keyboard / mouse combo HID device. (This device doesn't actually have a mouse but its HID descriptor says it does.)</p> -<pre><code> Device 7: Motorola Bluetooth Wireless Keyboard +<pre class="devsite-click-to-copy"> + Device 7: Motorola Bluetooth Wireless Keyboard IsExternal: true Sources: 0x00002103 KeyboardType: 2 @@ -302,7 +303,8 @@ have a mouse but its HID descriptor says it does.)</p> </code></pre> <p>Here is a joystick. Notice how all of the axes have been scaled to a normalized range. The axis mapping can be configured using key layout files.</p> -<pre><code>Device 18: Logitech Logitech Cordless RumblePad 2 +<pre class="devsite-click-to-copy"> +Device 18: Logitech Logitech Cordless RumblePad 2 IsExternal: true Sources: 0x01000511 KeyboardType: 1 @@ -345,7 +347,8 @@ range. The axis mapping can be configured using key layout files.</p> </code></pre> <p>At the end of the input reader dump there is some information about global configuration parameters such as the mouse pointer speed.</p> -<pre><code> Configuration: +<pre class="devsite-click-to-copy"> + Configuration: ExcludedDeviceNames: [] VirtualKeyQuietTime: 0.0ms PointerVelocityControlParameters: scale=1.000, lowThreshold=500.000, highThreshold=3000.000, acceleration=3.000 @@ -378,7 +381,7 @@ parameters such as the mouse pointer speed.</p> <p>The <code>InputDispatcher</code> is responsible for sending input events to applications. Its state dump shows information about which window is being touched, the state of the input queue, whether an ANR is in progress, and so on.</p> -<pre> +<pre class="devsite-click-to-copy"> Input Dispatcher State: DispatchEnabled: 1 DispatchFrozen: 0 diff --git a/en/devices/input/getevent.html b/en/devices/input/getevent.html index c6f2c369..69746bcd 100644 --- a/en/devices/input/getevent.html +++ b/en/devices/input/getevent.html @@ -30,12 +30,15 @@ expected set of capabilities for each input device and are generating the desired stream of input events.</p> <h2 id="showing-device-capabilities">Showing device capabilities</h2> -<p>Use the <code>-p</code> option to see all of the keys and axes a device -reports. The following example lists the Linux key codes and other events a -particular keyboard says it supports.</p> +<p>Use the <code>-p</code> option with the <code>adb</code> command to see all of the keys and axes a device +reports.</p> + +<pre class="devsite-terminal devsite-click-to-copy">adb shell su -- getevent -p</pre> -<pre><code>$ adb shell su -- getevent -p +<p>The following example lists the Linux key codes and other events a +particular keyboard says it supports.</p> +<pre> name: "Motorola Bluetooth Wireless Keyboard" events: KEY (0001): 0001 0002 0003 0004 0005 0006 0007 0008 @@ -69,15 +72,17 @@ particular keyboard says it supports.</p> LED (0011): 0000 0001 0002 0003 0004 input props: <none> -</code></pre> +</pre> <p>Use the <code>-i</code> option to get more information, including HID mapping tables and debugging information.</p> -<p>Use the <code>-l</code> option to display textual labels for all event codes. -Example:</p> -<pre><code>$ adb shell su -- getevent -lp /dev/input/event1 - +<p>Use the <code>-l</code> option to display textual labels for all event codes.</p> +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell su -- getevent -lp /dev/input/event1 +</pre> +<p>Example:</p> +<pre> name: "Melfas MMSxxx Touchscreen" events: ABS (0003): ABS_MT_SLOT : value 0, min 0, max 9, fuzz 0, flat 0, resolution 0 @@ -95,8 +100,12 @@ touchscreen using the Linux multi-touch input protocol "B". The <code>-l</code> option displays textual labels and the <code>-t</code> option displays timestamps.</p> -<pre><code>$ adb shell su -- getevent -lt /dev/input/event1 +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell su -- getevent -lt /dev/input/event1 +</pre> +<p>Example:</p> +<pre> [ 78826.389007] EV_ABS ABS_MT_TRACKING_ID 0000001f [ 78826.389038] EV_ABS ABS_MT_PRESSURE 000000ab [ 78826.389038] EV_ABS ABS_MT_POSITION_X 000000ab @@ -112,7 +121,7 @@ timestamps.</p> [ 78826.468719] EV_ABS ABS_MT_SLOT 00000001 [ 78826.468719] EV_ABS ABS_MT_TRACKING_ID ffffffff [ 78826.468719] EV_SYN SYN_REPORT 00000000 -</code></pre> +</pre> <p class="note"><strong>Note:</strong> <code>getevent</code> timestamps use the format $SECONDS.$MICROSECONDS in the CLOCK_MONOTONIC timebase. For details, refer to getevent.c.</p> diff --git a/en/devices/input/input-device-configuration-files.html b/en/devices/input/input-device-configuration-files.html index 3e0f6da9..20402dac 100644 --- a/en/devices/input/input-device-configuration-files.html +++ b/en/devices/input/input-device-configuration-files.html @@ -68,8 +68,9 @@ assignments and comments.</p> <h3 id="properties">Properties</h3> <p>Property assignments each consist of a property name, an <code>=</code>, a property value, and a new line. Like this:</p> -<pre><code>property = value -</code></pre> +<pre class="devsite-click-to-copy"> +property = value +</pre> <p>Property names are non-empty literal text identifiers. They must not contain whitespace. Each components of the input system defines a set of properties that are used to configure its function.</p> @@ -78,11 +79,13 @@ They must not contain whitespace or the reserved characters <code>\</code> or <c <p>Property names and values are case-sensitive.</p> <h3 id="comments">Comments</h3> <p>Comment lines begin with '#' and continue to the end of the line. Like this:</p> -<pre><code># A comment! -</code></pre> +<pre class="devsite-click-to-copy"> +# A comment! +</pre> <p>Blank lines are ignored.</p> <h3 id="example">Example</h3> -<pre><code># This is an example of an input device configuration file. +<pre class="devsite-click-to-copy"> +# This is an example of an input device configuration file. # It might be used to describe the characteristics of a built-in touch screen. # This is an internal device, not an external peripheral attached to the USB @@ -96,9 +99,9 @@ touch.orientationAware = 1 # Additional calibration properties... # etc... -</code></pre> +</pre> <h2 id="common-properties">Common Properties</h2> -<p>The following properties are common to all input device classes.</p> +<p>The following property is common to all input device classes.</p> <p>Refer to the documentation of each input device class for information about the special properties used by each class.</p> <h4 id="deviceinternal"><code>device.internal</code></h4> diff --git a/en/devices/input/key-character-map-files.html b/en/devices/input/key-character-map-files.html index 68e370e1..803610e3 100644 --- a/en/devices/input/key-character-map-files.html +++ b/en/devices/input/key-character-map-files.html @@ -50,7 +50,7 @@ id or by input device name.</p> <li><code>/data/system/devices/keychars/Virtual.kcm</code></li> </ul> <p>When constructing a file path that contains the device name, all characters -in the device name other than '0'-'9', 'a'-'z', 'A'-'Z', '-' or '<em>' are replaced by '</em>'.</p> +in the device name other than '0'-'9', 'a'-'z', 'A'-'Z', '-' or '_' are replaced by '_'.</p> <h2 id="generic-key-character-map-file">Generic Key Character Map File</h2> <p>The system provides a special built-in key character map file called <code>Generic.kcm</code>. This key character map is intended to support a variety of standard external @@ -76,8 +76,9 @@ declaration and a set of key declarations.</p> <p>A keyboard type declaration describes the overall behavior of the keyboard. A character map file must contain a keyboard type declaration. For clarity, it is often placed at the top of the file.</p> -<pre><code>type FULL -</code></pre> +<pre class="devsite-click-to-copy"> +type FULL +</pre> <p>The following keyboard types are recognized:</p> <ul> <li> @@ -120,13 +121,14 @@ HOME and POWER that are not actually used for typing.</p> <h3 id="key-declarations">Key Declarations</h3> <p>Key declarations each consist of the keyword <code>key</code> followed by an Android key code name, an open curly brace, a set of properties and behaviors and a close curly brace.</p> -<pre><code>key A { +<pre class="devsite-click-to-copy"> +key A { label: 'A' base: 'a' shift, capslock: 'A' ctrl, alt, meta: none } -</code></pre> +</pre> <h4 id="properties">Properties</h4> <p>Each key property establishes a mapping from a key to a behavior. To make the key character map files more compact, several properties can be mapped to the @@ -254,8 +256,9 @@ key followed by the letter 'a', the result is 'à'.</p> <p>Refer to <code>KeyCharacterMap.getDeadChar</code> for more information about dead key handling.</p> <h3 id="comments">Comments</h3> <p>Comment lines begin with '#' and continue to the end of the line. Like this:</p> -<pre><code># A comment! -</code></pre> +<pre class="devsite-click-to-copy"> +# A comment! +</pre> <p>Blank lines are ignored.</p> <h3 id="how-key-combinations-are-mapped-to-behaviors">How Key Combinations are Mapped to Behaviors</h3> <p>When the user presses a key, the system looks up the behavior associated with @@ -263,13 +266,14 @@ the combination of that key press and the currently pressed modifiers.</p> <h4 id="shift-a">SHIFT + A</h4> <p>Suppose the user pressed A and SHIFT together. The system first locates the set of properties and behaviors associated with <code>KEYCODE_A</code>.</p> -<pre><code>key A { +<pre class="devsite-click-to-copy"> +key A { label: 'A' base: 'a' shift, capslock: 'A' ctrl, alt, meta: none } -</code></pre> +</pre> <p>The system scans the properties from first to last and left to right, ignoring the <code>label</code> and <code>number</code> properties, which are special.</p> <p>The first property encountered is <code>base</code>. The <code>base</code> property always applies to @@ -295,12 +299,13 @@ property appears after <code>base</code> so its behavior overrides the <code>bas <p>So the resulting behavior for the key combination CONTROL + A is <code>none</code>.</p> <h4 id="escape">ESCAPE</h4> <p>Now suppose the user pressed ESCAPE.</p> -<pre><code>key ESCAPE { +<pre class="devsite-click-to-copy"> +key ESCAPE { base: fallback BACK alt, meta: fallback HOME ctrl: fallback MENU } -</code></pre> +</pre> <p>This time the system obtains the behavior <code>fallback BACK</code>, a fallback behavior. Because no character literal appears, no character will be typed.</p> <p>When processing the key, the system will first deliver <code>KEYCODE_ESCAPE</code> to the @@ -317,19 +322,21 @@ the NUM LOCK key is locked.</p> when NUM LOCK is pressed. When NUM LOCK is not pressed, the key is delivered to the application as usual, and if it is not handled, then the fallback key <code>KEYCODE_INSERT</code> is delivered instead.</p> -<pre><code>key NUMPAD_0 { +<pre class="devsite-click-to-copy"> +key NUMPAD_0 { label, number: '0' base: fallback INSERT numlock: '0' ctrl, alt, meta: none } -</code></pre> +</pre> <p>As we can see, fallback key declarations greatly improve compatibility with older applications that do not recognize or directly support all of the keys that are present on a full PC style keyboard.</p> <h3 id="examples">Examples</h3> <h4 id="full-keyboard">Full Keyboard</h4> -<pre><code># This is an example of part of a key character map file for a full keyboard +<pre class="devsite-click-to-copy"> +# This is an example of part of a key character map file for a full keyboard # include a few fallback behaviors for special keys that few applications # handle themselves. @@ -357,9 +364,10 @@ key NUMPAD_9 { numlock: '9' ctrl, alt, meta: none } -</code></pre> +</pre> <h4 id="alphanumeric-keyboard">Alphanumeric Keyboard</h4> -<pre><code># This is an example of part of a key character map file for an alphanumeric +<pre class="devsite-click-to-copy"> +# This is an example of part of a key character map file for an alphanumeric # thumb keyboard. Some keys are combined, such as `A` and `2`. Here we # specify `number` labels to tell the system what to do when the user is # typing a number into a dial pad. @@ -386,9 +394,10 @@ key SPACE { alt: '\uef01' shift+alt: '\uef01' } -</code></pre> +</pre> <h4 id="game-pad">Game Pad</h4> -<pre><code># This is an example of part of a key character map file for a game pad. +<pre class="devsite-click-to-copy"> +# This is an example of part of a key character map file for a game pad. # It defines fallback actions that enable the user to navigate the user interface # by pressing buttons. @@ -409,7 +418,7 @@ key BUTTON_START { key BUTTON_SELECT { base: fallback MENU } -</code></pre> +</pre> <h2 id="compatibility-note">Compatibility Note</h2> <p>Prior to Android Honeycomb 3.0, the Android key character map was specified using a very different syntax and was compiled into a binary file format diff --git a/en/devices/input/key-layout-files.html b/en/devices/input/key-layout-files.html index b9ee2be9..22faf84e 100644 --- a/en/devices/input/key-layout-files.html +++ b/en/devices/input/key-layout-files.html @@ -70,11 +70,12 @@ HID usage and Android key code name. The HID usage is represented as a 32-bit integer, where the high 16-bits represent the HID usage page and the low 16-bits represent the HID usage ID. Either declaration can be followed by an optional set of whitespace-delimited policy flags.</p> -<pre><code>key 1 ESCAPE +<pre class="devsite-click-to-copy"> +key 1 ESCAPE key 114 VOLUME_DOWN key 16 Q VIRTUAL key usage 0x0c006F BRIGHTNESS_UP -</code></pre> +</pre> <p>The following policy flags are recognized:</p> <ul> <li><code>FUNCTION</code>: The key should be interpreted as if the FUNCTION key @@ -95,7 +96,9 @@ including at least one Android axis code name.</p> <p>A basic axis simply maps a Linux axis code to an Android axis code name. The following declaration maps <code>ABS_X</code> (indicated by <code>0x00</code>) to <code>AXIS_X</code> (indicated by <code>X</code>).</p> -<pre><code>axis 0x00 X</code></pre> +<pre class="devsite-click-to-copy"> +axis 0x00 X +</pre> <p>In the above example, if the value of <code>ABS_X</code> is <code>5</code> then <code>AXIS_X</code> is set to <code>5</code>.</p> @@ -108,7 +111,8 @@ device encodes two different mutually exclusive logical axes.</p> (indicated by <code>0x01</code>) to <code>AXIS_GAS</code> when less than <code>0x7f</code> or to <code>AXIS_BRAKE</code> when greater than <code>0x7f</code>.</p> -<pre><code>axis 0x01 split 0x7f GAS BRAKE</code></pre> +<pre class="devsite-click-to-copy"> +axis 0x01 split 0x7f GAS BRAKE</pre> <p>In the above example, if the value of <code>ABS_Y</code> is <code>0x7d</code> then <code>AXIS_GAS</code> is set to <code>2</code> (<code>0x7f - 0x7d</code>) and <code>AXIS_BRAKE</code> is set to <code>0</code>. Conversely, if the value @@ -123,7 +127,9 @@ the split value of <code>0x7f</code> then both <code>AXIS_GAS</code> and declaration maps <code>ABS_RZ</code> (indicated by <code>0x05</code>) to <code>AXIS_BRAKE</code> (indicated by <code>BRAKE</code>), and inverts the output by negating it.</p> -<pre><code>axis 0x05 invert BRAKE</code></pre> +<pre class="devsite-click-to-copy"> +axis 0x05 invert BRAKE +</pre> <p>In the above example, if the value of <code>ABS_RZ</code> is <code>2</code> then <code>AXIS_BRAKE</code> is set to <code>-2</code>.</p> @@ -136,19 +142,24 @@ the center flat position of joystick axes but not all of them do and some of them provide incorrect values. To resolve this issue, an axis declaration may be followed by a <code>flat</code> option that specifies the value of the center flat position for the axis.</p> -<pre><code>axis 0x03 Z flat 4096</code></pre> +<pre class="devsite-click-to-copy"> +axis 0x03 Z flat 4096 +</pre> <p>In the above example, the center flat position is set to <code>4096</code>. </p> <h3 id="comments">Comments</h3> <p>Comment lines begin with # and continue to the end of the line:</p> -<pre><code># A comment!</code></pre> +<pre class="devsite-click-to-copy"> +# A comment! +</pre> <p>Blank lines are ignored.</p> <h3 id="examples">Examples</h3> <h4 id="keyboard">Keyboard</h4> -<pre><code># This is an example of a key layout file for a keyboard. +<pre class="devsite-click-to-copy"> +# This is an example of a key layout file for a keyboard. key 1 ESCAPE key 2 1 @@ -166,29 +177,32 @@ key 13 EQUALS key 14 DEL # etc... -</code></pre> +</pre> <h4 id="system-controls">System Controls</h4> -<pre><code># This is an example of a key layout file for basic system controls, +<pre class="devsite-click-to-copy"> +# This is an example of a key layout file for basic system controls, # such as volume and power keys which are typically implemented as GPIO pins # the device decodes into key presses. key 114 VOLUME_DOWN key 115 VOLUME_UP key 116 POWER -</code></pre> +</pre> <h4 id="capacitive-buttons">Capacitive Buttons</h4> -<pre><code># This is an example of a key layout file for a touch device with capacitive buttons. +<pre class="devsite-click-to-copy"> +# This is an example of a key layout file for a touch device with capacitive buttons. key 139 MENU VIRTUAL key 102 HOME VIRTUAL key 158 BACK VIRTUAL key 217 SEARCH VIRTUAL -</code></pre> +</pre> <h4 id="headset-jack-media-controls">Headset Jack Media Controls</h4> -<pre><code># This is an example of a key layout file for headset mounted media controls. +<pre class="devsite-click-to-copy"> +# This is an example of a key layout file for headset mounted media controls. # A typical headset jack interface might have special control wires or detect known # resistive loads as corresponding to media functions or volume controls. # This file assumes that the driver decodes these signals and reports media @@ -197,10 +211,11 @@ key 217 SEARCH VIRTUAL key 163 MEDIA_NEXT key 165 MEDIA_PREVIOUS key 226 HEADSETHOOK -</code></pre> +</pre> <h4 id="joystick">Joystick</h4> -<pre><code># This is an example of a key layout file for a joystick. +<pre class="devsite-click-to-copy"> +# This is an example of a key layout file for a joystick. # These are the buttons that the joystick supports, represented as keys. key 304 BUTTON_A @@ -231,7 +246,7 @@ axis 0x05 RTRIGGER # Hat. axis 0x10 HAT_X axis 0x11 HAT_Y -</code></pre> +</pre> <h2 id="virtual-soft-keys">Virtual Soft Keys</h2> <p>The input system provides special features for implementing virtual soft keys @@ -268,22 +283,24 @@ time after the most recent touch on the touch screen (this delay is called the <ol> <li>Provide a key layout file for the touch screen or capacitive button input device with the <code>VIRTUAL</code> flag set for each key. -<pre><code>key 139 MENU VIRTUAL +<pre class="devsite-click-to-copy"> +key 139 MENU VIRTUAL key 102 HOME VIRTUAL key 158 BACK VIRTUAL key 217 SEARCH VIRTUAL -</code></pre> +</pre> </li> <li>Set the value of the virtual key quiet time in a resource overlay for the framework <code>config.xml</code> resource. -<pre><code><!-- Specifies the amount of time to disable virtual keys after the screen +<pre class="devsite-click-to-copy"> +<!-- Specifies the amount of time to disable virtual keys after the screen is touched to filter out accidental virtual key presses due to swiping gestures or taps near the edge of the display. May be 0 to disable the feature. It is recommended that this value be no more than 250 ms. This feature should be disabled for most devices. --> <integer name="config_virtualKeyQuietTimeMillis">250</integer> -</code></pre> +</pre> </li> </ol> diff --git a/en/devices/input/keyboard-devices.html b/en/devices/input/keyboard-devices.html index 94ff3178..34f3575b 100644 --- a/en/devices/input/keyboard-devices.html +++ b/en/devices/input/keyboard-devices.html @@ -229,7 +229,8 @@ type of <code>SPECIAL_FUNCTION</code>) will never be registered as the built-in regardless of the setting of this property. This is because a special-function keyboard is by definition not intended to be used for general purpose typing.</p> <h3 id="example-configurations">Example Configurations</h3> -<pre><code># This is an example input device configuration file for a built-in +<pre class="devsite-click-to-copy"> +# This is an example input device configuration file for a built-in # keyboard that has a DPad. # The keyboard is internal because it is part of the device. @@ -245,7 +246,7 @@ keyboard.builtIn = 1 # DPad always means 'up' from the perspective of the user, even when the entire # device has been rotated. keyboard.orientationAware = 1 -</code></pre> +</pre> <h3 id="compatibility-notes">Compatibility Notes</h3> <p>Prior to Honeycomb, the keyboard input mapper did not use any configuration properties. All keyboards were assumed to be physically attached and orientation aware. The default diff --git a/en/devices/input/touch-devices.html b/en/devices/input/touch-devices.html index bc65c5c7..8cbcc66b 100644 --- a/en/devices/input/touch-devices.html +++ b/en/devices/input/touch-devices.html @@ -357,9 +357,10 @@ actually touching the screen or is merely in range and hovering.</p> <p>For a touch screen, the system automatically interpolates the reported touch positions in surface units to obtain touch positions in display pixels according to the following calculation:</p> -<pre><code>displayX = (x - minX) * displayWidth / (maxX - minX + 1) +<pre class="devsite-click-to-copy"> +displayX = (x - minX) * displayWidth / (maxX - minX + 1) displayY = (y - minY) * displayHeight / (maxY - minY + 1) -</code></pre> +</pre> <p>A touch screen may report touches outside of the reported active area.</p> <p>Touches that are initiated outside the active area are not delivered to applications but may be used for virtual keys.</p> @@ -713,7 +714,8 @@ is set, or <code>spots</code> otherwise.</p> <h4 id="calculation">Calculation</h4> <p>The calculation is straightforward: positional information from the touch driver is linearly interpolated to the output coordinate system.</p> -<pre><code>xScale = output.width / raw.width +<pre class="devsite-click-to-copy"> +xScale = output.width / raw.width yScale = output.height / raw.height If not orientation aware or screen rotation is 0 degrees: @@ -729,7 +731,7 @@ Else If rotation is 270 degrees: output.x = (raw.y.max - raw.y) * yScale output.y = (raw.x - raw.x.min) * xScale End If -</code></pre> +</pre> <h3 id="touchmajor-touchminor-toolmajor-toolminor-size-fields"><code>TouchMajor</code>, <code>TouchMinor</code>, <code>ToolMajor</code>, <code>ToolMinor</code>, <code>Size</code> Fields</h3> <p>The <code>TouchMajor</code> and <code>TouchMinor</code> fields describe the approximate dimensions of the contact area in output units (pixels).</p> @@ -807,7 +809,8 @@ that represents their total area or width. This property should only be set to <h4 id="calculation_1">Calculation</h4> <p>The calculation of the <code>TouchMajor</code>, <code>TouchMinor</code>, <code>ToolMajor</code>, <code>ToolMinor</code> and <code>Size</code> fields depends on the specified calibration parameters.</p> -<pre><code>If raw.touchMajor and raw.toolMajor are available: +<pre class="devsite-click-to-copy"> +If raw.touchMajor and raw.toolMajor are available: touchMajor = raw.touchMajor touchMinor = raw.touchMinor toolMajor = raw.toolMajor @@ -879,7 +882,7 @@ Else End If output.size = size -</code></pre> +</pre> <h3 id="pressure-field"><code>Pressure</code> Field</h3> <p>The <code>Pressure</code> field describes the approximate physical pressure applied to the touch device as a normalized value between 0.0 (no touch) and 1.0 (full force).</p> @@ -911,7 +914,7 @@ touch device as a normalized value between 0.0 (no touch) and 1.0 (full force).< <p>The default value is <code>1.0 / raw.pressure.max</code>.</p> <h4 id="calculation_2">Calculation</h4> <p>The calculation of the <code>Pressure</code> field depends on the specified calibration parameters.</p> -<pre><code>If touch.pressure.calibration == "physical" or "amplitude": +<pre class="devsite-click-to-copy">If touch.pressure.calibration == "physical" or "amplitude": output.pressure = raw.pressure * touch.pressure.scale Else If hovering: @@ -920,7 +923,7 @@ Else output.pressure = 1 End If End If -</code></pre> +</pre> <h3 id="orientation-and-tilt-fields"><code>Orientation</code> and <code>Tilt</code> Fields</h3> <p>The <code>Orientation</code> field describes the orientation of the touch and tool as an angular measurement. An orientation of <code>0</code> indicates that the major axis is @@ -959,7 +962,8 @@ A tilt of <code>PI/2</code> indicates that the tool is flat on the surface.</p> <h4 id="calculation_3">Calculation</h4> <p>The calculation of the <code>Orientation</code> and <code>Tilt</code> fields depends on the specified calibration parameters and available input.</p> -<pre><code>If touch.tiltX and touch.tiltY are available: +<pre class="devsite-click-to-copy"> +If touch.tiltX and touch.tiltY are available: tiltXCenter = average(raw.tiltX.min, raw.tiltX.max) tiltYCenter = average(raw.tiltY.min, raw.tiltY.max) tiltXAngle = (raw.tiltX - tiltXCenter) * PI / 180 @@ -1005,7 +1009,7 @@ If orientation aware: output.orientation = output.orientation + PI / 2 End If End If -</code></pre> +</pre> <h3 id="distance-field"><code>Distance</code> Field</h3> <p>The <code>Distance</code> field describes the distance between the tool and the touch device surface. A value of 0.0 indicates direct contact and larger values indicate @@ -1032,14 +1036,15 @@ increasing distance from the surface.</p> <p>The default value is <code>1.0</code>.</p> <h4 id="calculation_4">Calculation</h4> <p>The calculation of the <code>Distance</code> field depends on the specified calibration parameters.</p> -<pre><code>If touch.distance.calibration == "scaled": +<pre class="devsite-click-to-copy">If touch.distance.calibration == "scaled": output.distance = raw.distance * touch.distance.scale Else output.distance = 0 End If -</code></pre> +</pre> <h3 id="example">Example</h3> -<pre><code># Input device configuration file for a touch screen that supports pressure, +<pre class="devsite-click-to-copy"> +# Input device configuration file for a touch screen that supports pressure, # size and orientation. The pressure and size scale factors were obtained # by measuring the characteristics of the device itself and deriving # useful approximations based on the resolution of the touch sensor and the @@ -1070,7 +1075,7 @@ touch.pressure.scale = 0.0125 # Orientation touch.orientation.calibration = vector -</code></pre> +</pre> <h3 id="compatibility-notes">Compatibility Notes</h3> <p>The configuration properties for touch devices changed significantly in Android Ice Cream Sandwich 4.0. <strong>All input device configuration files for touch @@ -1107,16 +1112,18 @@ layout descriptions either separated by newlines or by colons.</p> </ul> <p>All coordinates and sizes are specified in terms of the display coordinate system.</p> <p>Here is a virtual key map file all written on one line.</p> -<pre><code># All on one line +<pre class="devsite-click-to-copy"> +# All on one line 0x01:158:55:835:90:55:0x01:139:172:835:125:55:0x01:102:298:835:115:55:0x01:217:412:835:95:55 -</code></pre> +</pre> <p>The same virtual key map file can also be written on multiple lines.</p> -<pre><code># One key per line +<pre class="devsite-click-to-copy"> +# One key per line 0x01:158:55:835:90:55 0x01:139:172:835:125:55 0x01:102:298:835:115:55 0x01:217:412:835:95:55 -</code></pre> +</pre> <p>In the above example, the touch screen has a resolution of 480x800. Accordingly, all of the virtual keys have a <centerY> coordinate of 835, which is a little bit below the visible area of the touch screen.</p> @@ -1124,20 +1131,22 @@ the visible area of the touch screen.</p> centerY of <code>835</code>, width of <code>90</code> and height of <code>55</code>.</p> <h3 id="example_1">Example</h3> <p>Virtual key map file: <code>/sys/board_properties/virtualkeys.touchyfeely</code>.</p> -<pre><code>0x01:158:55:835:90:55 +<pre class="devsite-click-to-copy"> +0x01:158:55:835:90:55 0x01:139:172:835:125:55 0x01:102:298:835:115:55 0x01:217:412:835:95:55 -</code></pre> +</pre> <p>Key layout file: <code>/system/usr/keylayout/touchyfeely.kl</code>.</p> -<pre><code>key 158 BACK +<pre class="devsite-click-to-copy">key 158 BACK key 139 MENU key 102 HOME key 217 SEARCH -</code></pre> +</pre> <p>Key character map file: <code>/system/usr/keychars/touchyfeely.kcm</code>.</p> -<pre><code>type SPECIAL_FUNCTION -</code></pre> +<pre class="devsite-click-to-copy"> +type SPECIAL_FUNCTION +</pre> <h2 id="indirect-multi-touch-pointer-gestures">Indirect Multi-touch Pointer Gestures</h2> <p>In pointer mode, the system interprets the following gestures:</p> <ol> diff --git a/en/devices/input/validate-keymaps.html b/en/devices/input/validate-keymaps.html index 4eabb401..9aac7e19 100644 --- a/en/devices/input/validate-keymaps.html +++ b/en/devices/input/validate-keymaps.html @@ -29,41 +29,51 @@ maps files and virtual key definition files.</p> <h2 id="compilation">Compilation</h2> <p>To compile <code>validatekeymaps</code>, set up the development environment, download the Android source tree, compile it, then run:</p> -<pre><code>$ mmm frameworks/base/tools/validatekeymaps -</code></pre> +<pre class="devsite-terminal devsite-click-to-copy"> +mmm frameworks/base/tools/validatekeymaps +</pre> <p>This command should compile a host tool called validatekeymaps into the <code>out/host/<os>/bin</code> directory.</p> <h2 id="usage">Usage</h2> <p>If you ran <code>envsetup.sh</code> to set up your development environment, then the <code>validatekeymaps</code> tool should already be on your path. You can verify this by running <code>validatekeymaps</code>.</p> -<pre><code>$ validatekeymaps - +<pre class="devsite-terminal devsite-click-to-copy"> +validatekeymaps +</pre> +<p>You should see the following output:</p> +<pre> Keymap Validation Tool Usage: validatekeymaps [*.kl] [*.kcm] [*.idc] [virtualkeys.*] [...] Validates the specified key layouts, key character maps, input device configurations, or virtual key definitions. -</code></pre> -<p>Then all you need to do is run <code>validatekeymaps</code> an give it the path of +</pre> +<p>Then all you need to do is run <code>validatekeymaps</code> and give it the path of one or more files to validate.</p> -<pre><code>$ validatekeymaps frameworks/base/data/keyboards/Generic.kl - +<pre class="devsite-terminal devsite-click-to-copy"> +validatekeymaps frameworks/base/data/keyboards/Generic.kl +</pre> +<p>Example:</p> +<pre> Validating file 'frameworks/base/data/keyboards/Generic.kl'... No errors. Success. -</code></pre> +</pre> <p>And if there is an error...</p> -<pre><code>$ validatekeymaps Bad.kl - +<pre class="devsite-terminal devsite-click-to-copy"> +validatekeymaps Bad.kl +</pre> +<p>Example:</p> +<pre> Validating file 'Bad.kl'... E/KeyLayoutMap(87688): Bad.kl:24: Expected keyword, got 'ke'. Error -22 parsing key layout file. Failed! -</code></pre> +</pre> <h2 id="automation">Automation</h2> <p>It is a <em>very</em> good idea to run <code>validatekeymaps</code> on all configuration files before installing them on a device.</p> @@ -71,7 +81,8 @@ before installing them on a device.</p> script or a makefile.</p> <p>The following sample makefile is based on the contents of <code>frameworks/base/data/keyboards/Android.mk</code>.</p> -<pre><code># This makefile performs build time validation of framework keymap files. +<pre class="devsite-click-to-copy"> +# This makefile performs build time validation of framework keymap files. LOCAL_PATH := $(call my-dir) @@ -89,7 +100,7 @@ validate_framework_keymaps: $(files) $(hide) $(validatekeymaps) $(files) include $(BUILD_PHONY_PACKAGE) -</code></pre> +</pre> </body> </html> diff --git a/en/devices/media/index.html b/en/devices/media/index.html index f52da0e9..834c5cfb 100644 --- a/en/devices/media/index.html +++ b/en/devices/media/index.html @@ -44,7 +44,7 @@ update</a> process and as part of an Android OS release.</p> <h2 id="architecture">Architecture</h2> <p>Media applications interact with the Android native multimedia framework according to the following architecture.</p> -<img src="images/ape_fwk_media.png" alt="Android media architecture" +<img src="/devices/media/images/ape_fwk_media.png" alt="Android media architecture" id="figure1" /><p class="img-caption"><strong>Figure 1.</strong> Media architecture</p> @@ -98,14 +98,18 @@ service. For the interfaces to create the plugin, see <li>Build your plugin as a shared library with the name <code>libstagefrighthw.so</code> in your product Makefile. For example: <br> -<p><pre>LOCAL_MODULE := libstagefrighthw</pre></p> +<pre class="devsite-click-to-copy"> +LOCAL_MODULE := libstagefrighthw +</pre> <p>In your device's Makefile, ensure you declare the module as a product package:</p> -<pre> +<pre class="devsite-click-to-copy"> PRODUCT_PACKAGES += \ libstagefrighthw \ ... -</pre></li></ol> +</pre> +</li> +</ol> <h2 id="expose">Exposing codecs to the framework</h2> <p>The Stagefright service parses the <code>system/etc/media_codecs.xml</code> @@ -116,7 +120,7 @@ and profiles on the device to app developers via the in the <code>device/<company>/<device>/</code> directory and copy this over to the system image's <code>system/etc</code> directory in your device's Makefile. For example:</p> -<pre> +<pre class="devsite-click-to-copy"> PRODUCT_COPY_FILES += \ device/samsung/tuna/media_profiles.xml:system/etc/media_profiles.xml \ device/samsung/tuna/media_codecs.xml:system/etc/media_codecs.xml \ diff --git a/en/devices/media/oem.html b/en/devices/media/oem.html index 73bcc648..c9d2e424 100644 --- a/en/devices/media/oem.html +++ b/en/devices/media/oem.html @@ -31,14 +31,14 @@ properly implement support for Android media resource manager and related APIs.< <p>The <code>CodecCapabilities.getMaxSupportedInstances</code> interface returns the maximum number of supported concurrent codec instances.</p> -<p>The CTS test +<p>The CTS test <code>testGetMaxSupportedInstances(android.media.cts.MediaCodecCapabilitiesTest)</code> -is used to enforce the proper maximum is set in +is used to enforce the proper maximum is set in <code>/etc/media_codecs.xml</code>.</p> <p>Here is an example:</p> -<pre> +<pre class="devsite-click-to-copy"> ... <MediaCodecs> ... @@ -60,7 +60,7 @@ To do this:</p> <li>Run the test first using cts-tradefed. <li>Evaluate the resulting failure message. Here is an example: -<pre> +<pre class="devsite-click-to-copy"> There was 1 failure: 1) testGetMaxSupportedInstances(android.media.cts.MediaCodecCapabilitiesTest) junit.framework.AssertionFailedError: In order to pass the test, please publish @@ -120,7 +120,7 @@ script to generate the XML file. This is usually done by placing the XML file in the device project (device/<em><vendor></em>/<em><product></em>) and adding a <code>PRODUCT_COPY_FILES</code> line to <code>device.mk</code> like so: -<pre> +<pre class="devsite-click-to-copy"> PRODUCT_COPY_FILES += \ ... device/moto/shamu/media_codecs.xml:system/etc/media_codecs.xml \ @@ -136,7 +136,7 @@ PRODUCT_COPY_FILES += \ If the instance of secure codec and the instance of non-secure codec can’t co-exist at the same time, that should be indicated as global setting in the <code>media_codecs.xml</code> file. -<pre> +<pre class="devsite-click-to-copy"> <MediaCodecs> <Settings> <Setting name="supports-secure-with-non-secure-codec" value="false" /> @@ -147,7 +147,7 @@ co-exist at the same time, that should be indicated as global setting in the <li>supports-multiple-secure-codecs — If co-exist of multiple secure codec instances is not supported, that should be indicated as a global setting in the <code>media_codecs.xml</code> file. -<pre> +<pre class="devsite-click-to-copy"> <MediaCodecs> <Settings> <Setting name="supports-multiple-secure-codecs" value="false" /> diff --git a/en/devices/sensors/hal-interface.html b/en/devices/sensors/hal-interface.html index d229e731..b04686e7 100644 --- a/en/devices/sensors/hal-interface.html +++ b/en/devices/sensors/hal-interface.html @@ -23,7 +23,7 @@ -<p>The HAL interface, declared in <a href="/devices/halref/sensors_8h.html">sensors.h</a>, represents the interface between the Android <a href="sensor-stack.html#framework">framework</a> and the hardware-specific software. A HAL implementation must define each +<p>The HAL interface, declared in <a href="https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/sensors.h">sensors.h</a>, represents the interface between the Android <a href="sensor-stack.html#framework">framework</a> and the hardware-specific software. A HAL implementation must define each function declared in sensors.h. The main functions are:</p> <ul> <li><code>get_sensors_list</code> - Returns the list of all sensors. </li> @@ -46,9 +46,9 @@ <li><code>sensor_t</code></li> <li><code>sensors_event_t</code></li> </ul> -<p>In addition to the sections below, see <a href="/devices/halref/sensors_8h.html">sensors.h</a> for more information on those types.</p> +<p>In addition to the sections below, see <a href="https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/sensors.h">sensors.h</a> for more information on those types.</p> <h2 id="get_sensors_list_list">get_sensors_list(list)</h2> -<pre>int (*get_sensors_list)(struct sensors_module_t* module, struct sensor_t +<pre class="prettyprint">int (*get_sensors_list)(struct sensors_module_t* module, struct sensor_t const** list);</pre> <p>Provides the list of sensors implemented by the HAL. See <a href="#sensor_t">sensor_t</a> for details on how the sensors are defined.</p> <p>The order in which the sensors appear in the list is the order in which the @@ -59,7 +59,7 @@ <code>getDefaultSensor(int sensorType, bool wakeUp)</code>.</p> <p>This function returns the number of sensors in the list.</p> <h2 id="activate_sensor_true_false">activate(sensor, true/false)</h2> -<pre>int (*activate)(struct sensors_poll_device_t *dev, int sensor_handle, int +<pre class="prettyprint">int (*activate)(struct sensors_poll_device_t *dev, int sensor_handle, int enabled);</pre> <p>Activates or deactivates a sensor.</p> <p><code>sensor_handle</code> is the handle of the sensor to activate/deactivate. A sensor’s @@ -79,7 +79,7 @@ and succeeds.</p> <p>This function returns 0 on success and a negative error number otherwise.</p> <h2 id="batch_sensor_flags_sampling_period_maximum_report_latency">batch(sensor, flags, sampling period, maximum report latency)</h2> -<pre> +<pre class="prettyprint"> int (*batch)( struct sensors_poll_device_1* dev, int sensor_handle, @@ -180,7 +180,7 @@ int (*batch)( <p>See <a href="batching.html">Batching</a> for more details on sensor batching, including behaviors in suspend mode and out of suspend mode.</p> <h2 id="setdelay_sensor_sampling_period">setDelay(sensor, sampling period)</h2> -<pre> +<pre class="prettyprint"> int (*setDelay)( struct sensors_poll_device_t *dev, int sensor_handle, @@ -191,7 +191,7 @@ int (*setDelay)( <code>sampling_period_ns</code> parameter.</p> <p>In HAL version 1.0, setDelay was used instead of batch to set <a href="#sampling_period_ns">sampling_period_ns</a>.</p> <h2 id="flush_sensor">flush(sensor)</h2> -<pre>int (*flush)(struct sensors_poll_device_1* dev, int sensor_handle);</pre> +<pre class="prettyprint">int (*flush)(struct sensors_poll_device_1* dev, int sensor_handle);</pre> <p>Add a <a href="#metadata_flush_complete_events">flush complete event</a> to the end of the hardware FIFO for the specified sensor and flushes the FIFO; those events are delivered as usual (i.e.: as if the maximum reporting latency had expired) and removed from the FIFO.</p> @@ -213,7 +213,7 @@ int (*setDelay)( <p>This function returns 0 on success, <code>-EINVAL</code> if the specified sensor is a one-shot sensor or wasn’t enabled, and a negative error number otherwise.</p> <h2 id="poll">poll()</h2> -<pre>int (*poll)(struct sensors_poll_device_t *dev, sensors_event_t* data, int +<pre class="prettyprint">int (*poll)(struct sensors_poll_device_t *dev, sensors_event_t* data, int count);</pre> <p>Returns an array of sensor data by filling the <code>data</code> argument. This function must block until events are available. It will return the number of events read @@ -239,7 +239,7 @@ int (*setDelay)( <code>HAL_MODULE_INFO_SYM</code> of this type to expose the <a href="#get_sensors_list_list">get_sensors_list</a> function. See the definition of <code>sensors_module_t</code> in <a - href="/devices/halref/sensors_8h.html">sensors.h</a> and the + href="https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/sensors.h">sensors.h</a> and the definition of <code>hw_module_t</code> for more information.</p> <h2 id="sensors_poll_device_t_sensors_poll_device_1_t">sensors_poll_device_t / sensors_poll_device_1_t</h2> <p><code>sensors_poll_device_1_t</code> contains the rest of the methods defined above: @@ -267,7 +267,7 @@ non-official sensor types, <code>type</code> must start with <code>SENSOR_TYPE_D <em>Cool-product</em> team at Fictional-Company could use <code>stringType=”com.fictional_company.cool_product.unicorn_detector”</code>. The <code>stringType</code> is used to uniquely identify non-official sensors types. See <a - href="/devices/halref/sensors_8h.html">sensors.h</a> for more + href="https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/sensors.h">sensors.h</a> for more information on types and string types.</p> <p><strong>requiredPermission:</strong> A string representing the permission that applications must possess to see the sensor, register to it and receive its data. An empty string @@ -343,7 +343,7 @@ important fields of <code>sensors_event_t</code>:</p> <code>elapsedRealtimeNano</code> clock, as the sensor clock drifts.</p> <p><strong>data and overlapping fields:</strong> The values measured by the sensor. The meaning and units of those fields are specific to each sensor type. See <a - href="/devices/halref/sensors_8h.html">sensors.h</a> and the + href="https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/sensors.h">sensors.h</a> and the definition of the different <a href="sensor-types.html">Sensor types</a> for a description of the data fields. For some sensors, the accuracy of the readings is also reported as part of the data, through a <code>status</code> field. This diff --git a/en/devices/sensors/index.html b/en/devices/sensors/index.html index 71ca2e7b..1613131a 100644 --- a/en/devices/sensors/index.html +++ b/en/devices/sensors/index.html @@ -24,7 +24,7 @@ <img style="float: right; margin: 0px 15px 15px 15px;" src="images/ape_fwk_hal_sensors.png" alt="Android Sensors HAL icon"/> -<p>Android sensors give applications access to a mobile device's underlying physical sensors. They are data-providing virtual devices defined by <a href="/devices/halref/sensors_8h.html">sensors.h</a>, the sensor Hardware Abstraction Layer (HAL).</p> +<p>Android sensors give applications access to a mobile device's underlying physical sensors. They are data-providing virtual devices defined by <a href="https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/sensors.h">sensors.h</a>, the sensor Hardware Abstraction Layer (HAL).</p> <h2 id="what_are_“android_sensors”">What are Android sensors?</h2> <p>Android sensors are virtual devices that provide data coming from a set of physical sensors: accelerometers, gyroscopes, magnetometers, barometer, humidity, pressure, light, proximity and heart rate sensors.</p> @@ -48,7 +48,7 @@ <p>Each Android sensor has a “type” representing how the sensor behaves and what data it provides.</p> <ul> - <li> The official Android <a href="sensor-types.html">Sensor types</a> are defined in <a href="/devices/halref/sensors_8h.html">sensors.h</a> under the names SENSOR_TYPE_… + <li> The official Android <a href="sensor-types.html">Sensor types</a> are defined in <a href="https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/sensors.h">sensors.h</a> under the names SENSOR_TYPE_… <ul> <li> The vast majority of sensors have an official sensor type. </li> <li> Those types are documented in the Android SDK. </li> @@ -130,7 +130,7 @@ </li> <li> Hardware abstraction layer (HAL) <ul> - <li> <a href="/devices/halref/sensors_8h_source.html">https://source.android.com/devices/halref/sensors_8h_source.html</a></li> + <li> <a href="https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/sensors.h">https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/sensors.h</a></li> <li> Also known as “sensors.h” </li> <li> The source of truth. First document to be updated when new features are developed. </li> diff --git a/en/devices/storage/config-example.html b/en/devices/storage/config-example.html index 16e4c91d..0a5416c9 100644 --- a/en/devices/storage/config-example.html +++ b/en/devices/storage/config-example.html @@ -39,30 +39,34 @@ device which is a physical SD card, like Nexus One.</p> it. <code>vold</code> will then manage the <code>fuse_sdcard0</code> service when media is inserted/removed. <h4>fstab.hardware</h4> -<pre><code>[physical device node] auto vfat defaults voldmanaged=sdcard0:auto,noemulatedsd -</code></pre> +<pre class="devsite-click-to-copy"> +[physical device node] auto vfat defaults voldmanaged=sdcard0:auto,noemulatedsd +</pre> <h4>init.hardware.rc</h4> -<pre><code>on init +<pre class="devsite-click-to-copy"> +on init mkdir /mnt/media_rw/sdcard0 0700 media_rw media_rw mkdir /storage/sdcard0 0700 root root export EXTERNAL_STORAGE /storage/sdcard0 service fuse_sdcard0 /system/bin/sdcard -u 1023 -g 1023 -d /mnt/media_rw/sdcard0 /storage/sdcard0 class late_start disabled -</code></pre> +</pre> <h4>storage_list.xml</h4> -<pre><code><storage +<pre class="devsite-click-to-copy"> +<storage android:mountPoint="/storage/sdcard0" android:storageDescription="@string/storage_sd_card" android:removable="true" android:primary="true" android:maxFileSize="4096" /> -</code></pre> +</pre> <h3 id=android_5_x_emulated>Emulated primary only</h3> <p>This is a typical configuration for a device with single external storage device which is backed by internal storage on the device, like Nexus 4.</p> <h4>init.hardware.rc</h4> -<pre><code>on init +<pre class="devsite-click-to-copy"> +on init mkdir /mnt/shell/emulated 0700 shell shell mkdir /storage/emulated 0555 root root export EXTERNAL_STORAGE /storage/emulated/legacy @@ -72,13 +76,14 @@ on fs setprop ro.crypto.fuse_sdcard true service sdcard /system/bin/sdcard -u 1023 -g 1023 -l /data/media /mnt/shell/emulated class late_start -</code></pre> +</pre> <h4>storage_list.xml</h4> -<pre><code><storage +<pre class="devsite-click-to-copy"> +<storage android:storageDescription="@string/storage_internal" android:emulated="true" android:mtpReserve="100" /> -</code></pre> +</pre> <h3 id=android_5_x_both>Emulated primary, physical secondary</h3> <p>This is a typical configuration for a device with multiple external storage devices, where the primary device is backed by internal storage @@ -88,10 +93,12 @@ on the device, and where the secondary device is a physical SD card, like Xoom.< access it. <code>vold</code> will then manage the <code>fuse_sdcard1</code> service when media is inserted/removed.</p> <h4>fstab.hardware</h4> -<pre><code>[physical device node] auto vfat defaults voldmanaged=sdcard1:auto -</code></pre> +<pre class="devsite-click-to-copy"> +[physical device node] auto vfat defaults voldmanaged=sdcard1:auto +</pre> <h4>init.hardware.rc</h4> -<pre><code>on init +<pre class="devsite-click-to-copy"> +on init mkdir /mnt/shell/emulated 0700 shell shell mkdir /storage/emulated 0555 root root mkdir /mnt/media_rw/sdcard1 0700 media_rw media_rw @@ -107,9 +114,10 @@ service sdcard /system/bin/sdcard -u 1023 -g 1023 -l /data/media /mnt/shell/emul service fuse_sdcard1 /system/bin/sdcard -u 1023 -g 1023 -w 1023 -d /mnt/media_rw/sdcard1 /storage/sdcard1 class late_start disabled -</code></pre> +</pre> <h4>storage_list.xml</h4> -<pre><code><storage +<pre class="devsite-click-to-copy"> +<storage android:storageDescription="@string/storage_internal" android:emulated="true" android:mtpReserve="100" /> @@ -118,7 +126,7 @@ service fuse_sdcard1 /system/bin/sdcard -u 1023 -g 1023 -w 1023 -d /mnt/media_rw android:storageDescription="@string/storage_sd_card" android:removable="true" android:maxFileSize="4096" /> -</code></pre> +</pre> <h2 id=android_6>Android 6.0</h2> <h3 id=android_6_physical>Physical primary only</h3> @@ -126,14 +134,16 @@ service fuse_sdcard1 /system/bin/sdcard -u 1023 -g 1023 -w 1023 -d /mnt/media_rw device which is a physical SD card, like the original Android One. There is no secondary shared storage and the device cannot support multi-user.</p> <h4>fstab.device</h4> -<pre><code>/devices/platform/mtk-msdc.1/mmc_host* auto auto defaults +<pre class="devsite-click-to-copy"> +/devices/platform/mtk-msdc.1/mmc_host* auto auto defaults voldmanaged=sdcard0:auto,encryptable=userdata,noemulatedsd -</code></pre> +</pre> <h4>init.device.rc</h4> -<pre><code>on init +<pre class="devsite-click-to-copy"> +on init # By default, primary storage is physical setprop ro.vold.primary_physical 1 - </code></pre> +</pre> <h3 id=android_6_emulated> Emulated primary only</h3> <p>This is a typical configuration for a device with single external storage device which is backed by internal storage on the device, like Nexus 6.</p> @@ -144,8 +154,9 @@ device which is backed by internal storage on the device, like Nexus 6.</p> <li>Supports multi-user. </ul> <h4>fstab.device</h4> -<pre><code>/devices/*/xhci-hcd.0.auto/usb* auto auto defaults - voldmanaged=usb:auto</code></pre> +<pre class="devsite-click-to-copy">/devices/*/xhci-hcd.0.auto/usb* auto auto defaults + voldmanaged=usb:auto +</pre> <h3 id=android_6_both>Emulated primary, physical secondary</h3> <p>This is a typical configuration for a device with multiple external storage devices, where the primary device is backed by internal storage on the device, @@ -156,9 +167,10 @@ and where the secondary device is a physical SD card, like Xoom.</p> <li>Supports multi-user. </ul> <h4>fstab.device</h4> -<pre><code>/devices/platform/mtk-msdc.1/mmc_host* auto auto defaults +<pre class="devsite-click-to-copy"> +/devices/platform/mtk-msdc.1/mmc_host* auto auto defaults voldmanaged=sdcard1:auto,encryptable=userdata -</code></pre> +</pre> </body> </html> diff --git a/en/devices/storage/config.html b/en/devices/storage/config.html index c9546bbd..49c79e52 100644 --- a/en/devices/storage/config.html +++ b/en/devices/storage/config.html @@ -32,8 +32,9 @@ staging operations to prepare the media before exposing it to apps.</p> <p>For Android 4.2.2 and earlier, the device-specific <code>vold.fstab</code> configuration file defines mappings from sysfs devices to filesystem mount points, and each line follows this format:</p> -<pre><code>dev_mount <label> <mount_point> <partition> <sysfs_path> [flags] -</code></pre> +<pre class="devsite-click-to-copy"> +dev_mount <label> <mount_point> <partition> <sysfs_path> [flags] +</pre> <ul> <li><code>label</code>: Label for the volume.</li> <li><code>mount_point</code>: Filesystem path where the volume should be mounted.</li> @@ -47,8 +48,9 @@ Possible values include <code>nonremovable</code> and <code>encryptable</code>.< recovery were unified in the <code>/fstab.<device></code> file. For external storage volumes that are managed by <code>vold</code>, the entries should have the following format:</p> -<pre><code><src> <mnt_point> <type> <mnt_flags> <fs_mgr_flags> -</code></pre> +<pre class="devsite-click-to-copy"> +<src> <mnt_point> <type> <mnt_flags> <fs_mgr_flags> +</pre> <ul> <li><code>src</code>: A path under sysfs (usually mounted at /sys) to the device that can provide the mount point. The path must start with <code>/</code>.</li> @@ -95,10 +97,11 @@ storage. Only used when mount is marked as emulated.</li> permissionless filesystem backed by internal storage. One possible implementation is provided by the FUSE daemon in <code>system/core/sdcard</code>, which can be added as a device-specific <code>init.rc</code> service:</p> -<pre><code># virtual sdcard daemon running as media_rw (1023) +<pre class="devsite-click-to-copy"> +# virtual sdcard daemon running as media_rw (1023) service sdcard /system/bin/sdcard <source_path> <dest_path> 1023 1023 class late_start -</code></pre> +</pre> <p>Where <code>source_path</code> is the backing internal storage and <code>dest_path</code> is the target mount point.</p> <p>When configuring a device-specific <code>init.rc</code> script, the <code>EXTERNAL_STORAGE</code> @@ -130,9 +133,10 @@ adopted is viewed as portable. </p> <h4 id=adoptable_storage>Adoptable storage </h4> <p>To indicate an adoptable storage device in the <code>fstab</code>, use the <code>encryptable=userdata</code> attribute in the <code>fs_mgr_flags</code> field. Here’s a typical definition:</p> -<pre><code>/devices/platform/mtk-msdc.1/mmc_host* auto auto defaults +<pre class="devsite-click-to-copy"> +/devices/platform/mtk-msdc.1/mmc_host* auto auto defaults voldmanaged=sdcard1:auto,encryptable=userdata -</code></pre> +</pre> <p>When a storage device is adopted, the platform erases the contents and writes a GUID partition table that defines two partitions:</p> <ul> @@ -144,9 +148,10 @@ GUID partition table that defines two partitions:</p> <h4 id=portable_storage>Portable storage </h4> <p>In the <code>fstab</code>, storage devices with the <code>voldmanaged</code> attribute are considered to be portable by default unless another attribute like <code>encryptable=userdata</code> is defined. For example, here’s a typical definition for USB OTG devices:</p> -<pre><code>/devices/*/xhci-hcd.0.auto/usb* auto auto defaults +<pre class="devsite-click-to-copy"> +/devices/*/xhci-hcd.0.auto/usb* auto auto defaults voldmanaged=usb:auto -</code></pre> +</pre> <p>The platform uses <code>blkid</code> to detect filesystem types before mounting, and users can choose to format the media when the filesystem is unsupported.</p> diff --git a/en/devices/tech/admin/implement.html b/en/devices/tech/admin/implement.html index ada8d284..f930e906 100644 --- a/en/devices/tech/admin/implement.html +++ b/en/devices/tech/admin/implement.html @@ -87,7 +87,7 @@ to 1 when the <code>low_ram</code> flag is defined.</p> <h3 id=uses-feature>Uses-feature</h3> <p>Devices must define the following <code>uses-feature</code>:</p> -<pre> +<pre class="devsite-click-to-copy"> android.software.managed_users android.software.device_admin </pre> @@ -100,15 +100,19 @@ device, run: <code>adb shell pm list features</code>.</p> should be enabled as part of provisioning a managed device. OEMs must ensure the managed profile or device has all required applications by modifying:</p> -<pre>vendor_required_apps_managed_profile.xml +<pre class="devsite-click-to-copy"> +vendor_required_apps_managed_profile.xml vendor_required_apps_managed_device.xml </pre> <p>Examples from a Nexus device:</p> -<p><code>packages/apps/ManagedProvisioning/res/values/vendor_required_apps_managed_device.xml</code></p> +<pre class="devsite-click-to-copy"> +packages/apps/ManagedProvisioning/res/values/vendor_required_apps_managed_device.xml +</pre> -<pre><resources> +<pre class="devsite-click-to-copy"> +<resources> <!-- A list of apps to be retained on the managed device --> <string-array name="vendor_required_apps_managed_device"> <item>com.android.vending</item> <!--Google Play --> @@ -121,11 +125,11 @@ vendor_required_apps_managed_device.xml </resources> </pre> -<p><code> +<pre class="devsite-click-to-copy"> packages/apps/ManagedProvisioning/res/values/vendor_required_apps_managed_profile.xml -</code></p> +</pre> -<pre> +<pre class="devsite-click-to-copy"> <resources> <!-- A list of apps to be retained in the managed profile. This includes any Google experience apps required. --> <string-array name="vendor_required_apps_managed_profile"> @@ -150,8 +154,12 @@ feature.</p> <p>Devices with NFC must enable NFC during the out-of-the-box experience (i.e., setup wizard) and be configured to accept managed provisioning intents:</p> -<p><code>packages/apps/Nfc/res/values/provisioning.xml</code></p> -<pre><bool name="enable_nfc_provisioning">true</bool> +<pre class="devsite-click-to-copy"> +packages/apps/Nfc/res/values/provisioning.xml +</pre> + +<pre class="devsite-click-to-copy"> +<bool name="enable_nfc_provisioning">true</bool> <item>application/com.android.managedprovisioning</item> </pre> @@ -167,7 +175,8 @@ which then hands control to the newly-set device owner.</p> <p>To meet setup requirements, add the following code to the device setup's main activity:</p> -<pre>@Override +<pre class="devsite-click-to-copy"> +@Override protected void onStart() { super.onStart(); diff --git a/en/devices/tech/admin/managed-profiles.html b/en/devices/tech/admin/managed-profiles.html index 95c7771f..eb042052 100644 --- a/en/devices/tech/admin/managed-profiles.html +++ b/en/devices/tech/admin/managed-profiles.html @@ -81,11 +81,15 @@ outside the managed profile.</p> <p>Managed profiles are implemented as a new kind of secondary user, such that:</p> -<pre>uid = 100000 * userid + appid</pre> +<pre class="devsite-click-to-copy"> +uid = 100000 * userid + appid +</pre> <p>They have separate app data like regular users:</p> -<pre>/data/user/<userid></pre> +<pre class="devsite-click-to-copy"> +/data/user/<userid> +</pre> <p>The UserId is calculated for all system requests using <code>Binder.getCallingUid()</code>, and all system state and responses are diff --git a/en/devices/tech/admin/multi-user.html b/en/devices/tech/admin/multi-user.html index cc187660..e19eaea4 100644 --- a/en/devices/tech/admin/multi-user.html +++ b/en/devices/tech/admin/multi-user.html @@ -101,7 +101,8 @@ enable it, device manufacturers must define a resource overlay that replaces the following values in <code>frameworks/base/core/res/res/values/config.xml</code>: </p> -<pre><!-- Maximum number of supported users --> +<pre class="devsite-click-to-copy"> +<!-- Maximum number of supported users --> <integer name="config_multiuserMaximumUsers">1</integer> <!-- Whether Multiuser UI should be shown --> <bool name="config_enableMultiUserUI">false</bool> diff --git a/en/devices/tech/admin/multiuser-apps.html b/en/devices/tech/admin/multiuser-apps.html index 546659d7..c3efcd64 100644 --- a/en/devices/tech/admin/multiuser-apps.html +++ b/en/devices/tech/admin/multiuser-apps.html @@ -38,7 +38,7 @@ requests from any user. Only system apps can currently use this feature.</p> <p>See the diagram below for a depiction of permissions flow with multiple users.</p> -<p><img src="images/multi-user-perms.png" alt="Multiple users permissions flow" /> +<p><img src="/devices/tech/admin/images/multi-user-perms.png" alt="Multiple users permissions flow" /> <p class="img-caption"><strong>Figure 1.</strong> Multiple users permissions</p> <h2 id=enabling_a_singleton_component>Enabling a singleton component</h2> @@ -59,7 +59,7 @@ each user, with the UID being in the UID range for that user (such as 1010034).< <p>These permissions are required</p> -<pre> +<pre class="devsite-click-to-copy"> INTERACT_ACROSS_USERS (signature|system) INTERACT_ACROSS_USERS_FULL (signature) </pre> @@ -74,7 +74,7 @@ INTERACT_ACROSS_USERS_FULL (signature) <li> <code>int userHandle = UserHandle.getCallingUserId()</code> </ul> <li> Use new, protected APIs to start services, activities, broadcasts on a specific -user: +user: <ul> <li><code>Context.startActivityAsUser(Intent, UserHandle)</code> <li><code>Context.bindServiceAsUser(Intent, …, UserHandle)</code> @@ -102,5 +102,28 @@ ContentObserver, PackageMonitor, BroadcastReceiver that provide additional information about which user has caused the callback. </ol> +<h3 id="work-profiles">Services in multiple users or profiles</h3> + +<p>Not all services need to run an instance in another user or work profile. If your system service +only needs to run as user 0, disable the service's components when running under other users to +help preserve resources. The following example shows how you might do this at your service's entry +points:</p> + +<pre class="devsite-click-to-copy"> +// Add on all entry points such as boot_completed or other manifest-listed receivers and providers +if (!UserManager.isSystemUser()) { + // Disable the service + ComponentName targetServiceName = new ComponentName(this, TargetService.class); + context.getPackageManager().setComponentEnabledSetting( + targetServiceName, COMPONENT_ENABLED_STATE_DISABLED, 0); +} +</pre> + +<p>The example could also use <code>PackageManager.setApplicationEnabledSetting()</code> to disable +the entire app.</p> + + + + </body> </html> diff --git a/en/devices/tech/admin/provision.html b/en/devices/tech/admin/provision.html index 9ab1937d..e1acd3e7 100644 --- a/en/devices/tech/admin/provision.html +++ b/en/devices/tech/admin/provision.html @@ -94,13 +94,14 @@ managed profile by sending an intent with action: . Below is a sample intent that triggers the creation of the managed profile and sets the DeviceAdminSample as the profile owner:</p> -<pre>adb shell am start -a android.app.action.PROVISION_MANAGED_PROFILE \ +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb shell am start -a android.app.action.PROVISION_MANAGED_PROFILE \ -c android.intent.category.DEFAULT \ -e wifiSsid $(printf '%q' \"WifiSSID\") \ -e deviceAdminPackage "com.google.android.deviceadminsample" \ -e android.app.extra.deviceAdminPackageName $(printf '%q' .DeviceAdminSample\$DeviceAdminSampleReceiver) \ - -e android.app.extra.DEFAULT_MANAGED_PROFILE_NAME "My Organisation" + -e android.app.extra.DEFAULT_MANAGED_PROFILE_NAME "My Organisation"</code> </pre> <h2 id=device_owner_provisioning_via_nfc>Device owner provisioning</h2> @@ -117,7 +118,7 @@ DPC as device owner.</p> <p>A typical NFC bundle includes the following:</p> -<pre> +<pre class="devsite-click-to-copy"> EXTRA_PROVISIONING_DEVICE_ADMIN_PACKAGE_NAME EXTRA_PROVISIONING_DEVICE_ADMIN_PACKAGE_LOCATION EXTRA_PROVISIONING_DEVICE_ADMIN_PACKAGE_CHECKSUM @@ -128,8 +129,10 @@ DPC as device owner.</p> <p>Devices must have NFC configured to accept the managed provisioning mimetype from the setup experience:</p> -<pre>/packages/apps/Nfc/res/values/provisioning.xml - +<pre class="devsite-click-to-copy"> +/packages/apps/Nfc/res/values/provisioning.xml +</pre> +<pre class="devsite-click-to-copy"> <bool name="enable_nfc_provisioning">true</bool> <item>application/com.android.managedprovisioning</item> </pre> diff --git a/en/devices/tech/admin/testing-provision.html b/en/devices/tech/admin/testing-provision.html index d080bad7..a8a219d2 100644 --- a/en/devices/tech/admin/testing-provision.html +++ b/en/devices/tech/admin/testing-provision.html @@ -50,13 +50,13 @@ Android platform has a separate version of AfW Test Harness). For Android 7.0, the branch name is <code>afw-test-harness-nougat-dev</code>. To initialize the repo and download source code for this branch, use:</p> -<pre> -$ mkdir WORKING_DIRECTORY -$ cd WORKING_DIRECTORY -$ git config --global user.name "Your Name" -$ git config --global user.email "you@example.com" -$ repo init -u https://android.googlesource.com/platform/manifest -b afw-test-harness-nougat-dev -$ repo sync -j24 +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">mkdir WORKING_DIRECTORY</code> +<code class="devsite-terminal">cd WORKING_DIRECTORY</code> +<code class="devsite-terminal">git config --global user.name "Your Name"</code> +<code class="devsite-terminal">git config --global user.email "you@example.com"</code> +<code class="devsite-terminal">repo init -u https://android.googlesource.com/platform/manifest -b afw-test-harness-nougat-dev</code> +<code class="devsite-terminal">repo sync -j24</code> </pre> <p>To check out the source code for a different version, specify the branch with @@ -92,9 +92,9 @@ with the source code.</p> <p>To view and edit AfW source code in Android Studio:</p> <ol> <li>Run the following commands -<pre> -$ make idegen -$ development/tools/idegen/idegen.sh +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">make idegen</code> +<code class="devsite-terminal">development/tools/idegen/idegen.sh</code> </pre> </li> <li>In Android Studio, open <code>android.ipr</code>.</li> @@ -109,7 +109,8 @@ successfully, complete the following steps:</p> <ol> <li>Configure the Wi-Fi network in <code>afw-test.props</code> with the following properties: -<pre>wifi_ssid +<pre class="devsite-click-to-copy"> +wifi_ssid wifi_password (optional) wifi_security_type (optional, available options are: NONE, WEP or WPA) </pre> @@ -117,7 +118,7 @@ wifi_security_type (optional, available options are: NONE, WEP or WPA) <li>Obtain at least one account from a domain that is bound to Test DPC as its device policy controller. Specify the details in <code>afw-test.props</code> with the following properties: -<pre> +<pre class="devsite-click-to-copy"> work_account_username work_account_password </pre> @@ -128,15 +129,17 @@ work_account_password <h2 id=build_harness>Building the AfW Test Harness</h2> <p>Initialize the build configuration using:</p> -<pre> -$ source build/envsetup.sh -$ lunch +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">source build/envsetup.sh</code> +<code class="devsite-terminal">lunch</code> </pre> <p>Select a device type and press <strong>Enter</strong>.</p> <p>Build the harness using:</p> -<pre>$ make afw-test-harness -j32</pre> +<pre class="devsite-terminal devsite-click-to-copy"> +make afw-test-harness -j32 +</pre> <p>This creates a directory (<code>out/host/linux-x86/afw-th/android-cts</code>) with all necessary binaries, configuration files, and tools to run the test harness. This directory is also zipped into a file @@ -147,13 +150,17 @@ for distribution.</p> <p>Use the following steps to run the AfW Test Harness:</p> <ol> <li>In your build environment, launch the test runner using: -<pre>$ afw-test-tradefed</pre> +<pre class="devsite-terminal devsite-click-to-copy"> +afw-test-tradefed +</pre> This starts the <code>cts-tf</code> console, loads test plans, test cases, and <code>afw-test.props</code> from <code>out/host/linux-x86/afw-th/android-cts</code>.</li> <li>From the unzipped folder of <code>android-afw-test-harness.zip</code>, launch the test runner using: -<pre>$ cts-tf > ./android‐cts/tools/afw-test‐tradefed</pre> +<pre class="devsite-click-to-copy"> +cts-tf> ./android‐cts/tools/afw-test‐tradefed +</pre> This loads test plans, test cases, and <code>afw-test.props</code> from <code>android-cts</code> directory. Ensure <code>./android‐cts/repository/testcases/afw-test.props</code> has the work @@ -172,14 +179,17 @@ setup and enabling USB debugging.</li> </ul> <br>To run the test plan <code>afw-userdebug-build</code>, use: -<pre>$ cts-tf > run cts --plan afw-userdebug-build</pre> +<pre class="devsite-click-to-copy"> +cts-tf> run cts --plan afw-userdebug-build +</pre> To see all test plans, use the command <code>list plans</code>. To view plan definitions, refer to <code>out/host/linux-x86/afw-th/android-cts/repository/plans</code>. <br> </li> <li>Run a test package. To run a single test package, use -<pre>$ cts-tf > run cts --package com.android.afwtest.NfcProvisioning +<pre class="devsite-click-to-copy"> +cts-tf> run cts --package com.android.afwtest.NfcProvisioning </pre> To view all packages, use the command <code>list packages</code>. For more options, use the command <code>run cts --help</code>.</li> @@ -192,16 +202,23 @@ which you can launch by running <code>afw-test-tradefed</code>.</p> <li>Display more information with the <code>-l INFO</code> or <code>-l DEBUG</code> flags. Example: -<pre>$ cts-tf > run cts ‐‐plan afw-userdebug-build -l DEBUG</pre></li> +<pre class="devsite-click-to-copy"> +cts-tf> run cts ‐‐plan afw-userdebug-build -l DEBUG +</pre> +</li> <li>Run the test harness on a specific device with the <code>-s</code> flag. Example: -<pre>$ cts-tf > run cts ‐‐plan afw-userdebug-build -l DEBUG -s device_sn</pre> +<pre class="devsite-click-to-copy"> +cts-tf> run cts ‐‐plan afw-userdebug-build -l DEBUG -s device_sn +</pre> </li> <li>Run test harness on all connected devices with the <code>--all-devices</code> flag. Example: -<pre>$ cts-tf > run cts ‐‐plan afw-userdebug-build -l DEBUG --all-devices</pre> +<pre class="devsite-click-to-copy"> +cts-tf> run cts ‐‐plan afw-userdebug-build -l DEBUG --all-devices +</pre> </li> <li>View current running executions using <code>list invocations</code> or @@ -246,7 +263,8 @@ Navigating:com.android.afwtest.uiautomator.pages.gms.AddAccountPage</code> </li> <li>If a test failed during the provisioning process, logcat contains an error similar to: -<pre>TestRunner: java.lang.RuntimeException: Failed to load page: com.android.afwtest.uiautomator.pages.packageinstaller.DeviceAccessPage +<pre class="devsite-click-to-copy"> +TestRunner: java.lang.RuntimeException: Failed to load page: com.android.afwtest.uiautomator.pages.packageinstaller.DeviceAccessPage </pre> This is typically caused by errors in a previous UI page or the page that failed to load, so try to find other error messages in logcat before this error, @@ -306,7 +324,7 @@ meaningful text or content description that contains any of the following words: Skip, Finish, Done, Accept, Agree, Next, Continue, or Proceed. Alternatively, you can define a button in <code>afw-test.props</code> to configure the test harness to skip your UI. Example:</em></p> -<pre> +<pre class="devsite-click-to-copy"> oem_widgets=your_btn your_btn.text=your_customized_text your_btn.package=your_package diff --git a/en/devices/tech/admin/testing-setup.html b/en/devices/tech/admin/testing-setup.html index 8a47fcfe..dc89c1a4 100644 --- a/en/devices/tech/admin/testing-setup.html +++ b/en/devices/tech/admin/testing-setup.html @@ -61,7 +61,9 @@ enterprise mobility management (EMM) providers.</p> </ul> </li> <li>Set the TestDPC app as the device owner using the following command:<br> - <pre>$ adb shell dpm set-device-owner "com.afwsamples.testdpc/.DeviceAdminReceiver"</pre> +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell dpm set-device-owner "com.afwsamples.testdpc/.DeviceAdminReceiver" +</pre> </li> <li>Go through device owner setup on the device (encrypt, select Wi-Fi, etc.)</li> </ol> diff --git a/en/devices/tech/config/carrier.html b/en/devices/tech/config/carrier.html index 11a1fd58..81a1ecee 100644 --- a/en/devices/tech/config/carrier.html +++ b/en/devices/tech/config/carrier.html @@ -178,7 +178,7 @@ user adds extra services to their account) <p>An example is below:</p> -<pre> +<pre class="prettyprint"> public class SampleCarrierConfigService extends CarrierService { private static final String TAG = "SampleCarrierConfigService"; @@ -210,7 +210,7 @@ href="https://developer.android.com/reference/android/service/carrier/CarrierSer <p>An example is below:</p> -<pre> +<pre class="prettyprint"> <service android:name=".SampleCarrierConfigService" android:label="@string/service_name" android:permission="android.permission.BIND_CARRIER_SERVICES"> diff --git a/en/devices/tech/config/filesystem.html b/en/devices/tech/config/filesystem.html index c2a3fd3f..98a72baa 100644 --- a/en/devices/tech/config/filesystem.html +++ b/en/devices/tech/config/filesystem.html @@ -139,7 +139,7 @@ overrides. However, this is weak protection; if someone has control over <code>/system</code>, they can typically do anything they want.</li> </ul> -<pre> +<pre class="devsite-click-to-copy"> diff --git a/android_filesystem_config.h b/android_filesystem_config.h new file mode 100644 index 0000000..874195f diff --git a/en/devices/tech/config/kernel.html b/en/devices/tech/config/kernel.html index 2ac4e4cc..14d2ee17 100644 --- a/en/devices/tech/config/kernel.html +++ b/en/devices/tech/config/kernel.html @@ -54,7 +54,9 @@ Document (CDD)</a>.</p> <p>For devices that have a minimalist defconfig, you can use the following to enable options:</p> -<pre><code>ARCH=<em>arch</em> scripts/kconfig/merge_config.sh <em>path</em>/<em>device</em>_defconfig android/configs/android-base.cfg android/configs/android-recommended.cfg</code></pre> +<pre class="devsite-click-to-copy"> +ARCH=<em>arch</em> scripts/kconfig/merge_config.sh <em>path</em>/<em>device</em>_defconfig android/configs/android-base.cfg android/configs/android-recommended.cfg +</pre> <p>This generates a .config file you can use to save a new defconfig or compile a new kernel with Android features enabled.</p> @@ -62,13 +64,16 @@ compile a new kernel with Android features enabled.</p> <h2 id="usb">Enabling USB host mode options</h2> <p>For USB host mode audio, enable the following options:</p> -<pre><code>CONFIG_SND_USB=y +<pre class="devsite-click-to-copy"> +CONFIG_SND_USB=y CONFIG_SND_USB_AUDIO=y # CONFIG_USB_AUDIO is for a peripheral mode (gadget) driver -</code></pre> +</pre> <p>For USB host mode MIDI, enable the following option:</p> -<pre><code>CONFIG_SND_USB_MIDI=y</code></pre> +<pre class="devsite-click-to-copy"> +CONFIG_SND_USB_MIDI=y +</pre> <h2 id="Seccomp-BPF-TSYNC">Seccomp-BPF with TSYNC</h2> <p>Seccomp-BPF is a kernel security technology that enables the creation of diff --git a/en/devices/tech/config/kernel_network_tests.html b/en/devices/tech/config/kernel_network_tests.html index a1e83a24..bc437ad2 100644 --- a/en/devices/tech/config/kernel_network_tests.html +++ b/en/devices/tech/config/kernel_network_tests.html @@ -77,7 +77,9 @@ in the given release. For information on how to run the tests, see the <a href="https://android.googlesource.com/kernel/tests/+/master/net/test/README">kernel network test README file</a>. Basically, from the top of your kernel tree, run:</p> -<pre> <android tree>/kernel/tests/net/test/run_net_test.sh all_tests.sh</pre> +<pre class="devsite-click-to-copy"> +<var>ANDROID_TREE</var>/kernel/tests/net/test/run_net_test.sh all_tests.sh +</pre> <h3 id=passing>Passing the tests</h3> <p>The kernel network test Python source files contain comments that specify kernel commits that are known to be diff --git a/en/devices/tech/config/low-ram.html b/en/devices/tech/config/low-ram.html index 10f1cbfc..100b4ab3 100644 --- a/en/devices/tech/config/low-ram.html +++ b/en/devices/tech/config/low-ram.html @@ -82,9 +82,11 @@ wrong thing). <code>ActivityManager.isLowRamDevice()</code> for applications to determine if they should turn off specific memory-intensive features that work poorly on low-memory devices.</p> -<p>For 512MB devices, this API is expected to return: "true" It can be enabled by - the following system property in the device makefile.<br/> -<code>PRODUCT_PROPERTY_OVERRIDES += ro.config.low_ram=true</code></p> +<p>For 512MB devices, this API is expected to return <code>true</code>. It can be enabled by + the following system property in the device makefile.</p> +<pre class="devsite-click-to-copy"> +PRODUCT_PROPERTY_OVERRIDES += ro.config.low_ram=true +</pre> <h3 id="jit">Disable JIT</h3> @@ -99,8 +101,10 @@ they should turn off specific memory-intensive memory usage, but if set too low will send the JIT into a thrashing mode. For the really low-memory devices, we recommend the JIT be disabled entirely.</p> -<p>This can be achieved by adding the following line to the product makefile:<br/> -<code>PRODUCT_PROPERTY_OVERRIDES += dalvik.vm.jit.codecachesize=0</code></p> +<p>This can be achieved by adding the following line to the product makefile:</p> +<pre class="devsite-click-to-copy"> +PRODUCT_PROPERTY_OVERRIDES += dalvik.vm.jit.codecachesize=0 +</pre> <h3 id="launcher">Launcher Configs</h3> @@ -136,7 +140,7 @@ using live-wallpaper. Low-memory devices should not pre-install any live wallpap <p>These thresholds can be configured via the framework config.xml</p> -<pre> +<pre class="devsite-click-to-copy"> <!-- Device configuration setting the /proc/sys/vm/extra_free_kbytes tunable in the kernel (if it exists). A high value will increase the amount of memory that the kernel tries to keep free, reducing allocation time and causing the @@ -148,7 +152,7 @@ by default. -1 keeps the default. --> <integer name="config_extraFreeKbytesAbsolute">-1</integer> </pre> -<pre> +<pre class="devsite-click-to-copy"> <!-- Device configuration adjusting the /proc/sys/vm/extra_free_kbytes tunable in the kernel (if it exists). 0 uses the default value chosen by ActivityManager. A positive value will increase the amount of memory that the @@ -172,7 +176,7 @@ memory or if more services have been added, the thresholds can be increased. </p backed pages, so that background processes are being killed long before disk thrashing would occur due to the cache getting too small.</p> -<pre> +<pre class="devsite-click-to-copy"> <!-- Device configuration setting the minfree tunable in the lowmemorykiller in the kernel. A high value will cause the lowmemorykiller to fire earlier, keeping more memory in the file cache and preventing I/O thrashing, but @@ -184,7 +188,7 @@ smaller buckets. -1 keeps the default. --> <integer name="config_lowMemoryKillerMinFreeKbytesAbsolute">-1</integer> </pre> -<pre> +<pre class="devsite-click-to-copy"> <!-- Device configuration adjusting the minfree tunable in the lowmemorykiller in the kernel. A high value will cause the lowmemorykiller to fire earlier, keeping more memory in the file cache and preventing I/O @@ -215,7 +219,7 @@ rendering times.</p> <p>To enable KSM, enable <code>CONFIG_KSM</code> in the kernel and then add the following lines to your` <code>init.<device>.rc</code> file:<br> -<pre> +<pre class="devsite-click-to-copy"> write /sys/kernel/mm/ksm/pages_to_scan 100 write /sys/kernel/mm/ksm/sleep_millisecs 500 write /sys/kernel/mm/ksm/run 1 @@ -249,29 +253,35 @@ system.</p> <li><code>CONFIG_ZRAM</code></li> </ul> </li> - <li>Then, you should add a line that looks like this to your fstab:<br /> - <code>/dev/block/zram0 none swap defaults zramsize=<size in bytes>,swapprio=<swap partition priority></code><br /> - <code><br /> - zramsize</code> is mandatory and indicates how much uncompressed memory you want - the zram area to hold. Compression ratios in the 30-50% range are usually - observed.<br /> - <br /> - <code>swapprio</code> is optional and not needed if you don't have more than one swap - area.<br /> - <br /> - You should also be sure to label the associated block device as a swap_block_device + <li>Then, you should add a line that looks like this to your fstab: +<pre class="devsite-click-to-copy"> +/dev/block/zram0 none swap defaults zramsize=<size in bytes>,swapprio=<swap partition priority> +</pre> + <ul> + <li><code>zramsize</code> is mandatory and indicates how much uncompressed memory you want the zram area to hold. Compression ratios in the 30-50% range are usually observed.</li> + <li><code>swapprio</code> is optional and not needed if you don't have more than one swap + area.</li> + </ul> + <p>You should also be sure to label the associated block device as a swap_block_device in the device-specific <a href="/security/selinux/implement.html"> - sepolicy/file_contexts</a> so that it is treated properly by SELinux. <br /> - <code>/dev/block/zram0 u:object_r:swap_block_device:s0</code><br /> - <br /> + sepolicy/file_contexts</a> so that it is treated properly by SELinux.</p> +<pre class="devsite-click-to-copy"> +/dev/block/zram0 u:object_r:swap_block_device:s0 +</pre> </li> <li>By default, the Linux kernel swaps in 8 pages of memory at a time. When using ZRAM, the incremental cost of reading 1 page at a time is negligible and may help in case the device is under extreme memory pressure. To read - only 1 page at a time, add the following to your <code>init.rc</code>:<br /> - <code>write /proc/sys/vm/page-cluster 0</code></li> - <li>In your <code>init.rc</code> after the <code>mount_all /fstab.X</code> line, add:<br /> - <code>swapon_all /fstab.X</code></li> + only 1 page at a time, add the following to your <code>init.rc</code>: +<pre class="devsite-click-to-copy"> +write /proc/sys/vm/page-cluster 0 +</pre> + </li> + <li>In your <code>init.rc</code> after the <code>mount_all /fstab.X</code> line, add: +<pre class="devsite-click-to-copy"> +swapon_all /fstab.X +</pre> + </li> <li>The memory cgroups are automatically configured at boot time if the feature is enabled in kernel.</li> <li>If memory cgroups are available, the ActivityManager will mark lower @@ -324,9 +334,11 @@ development/tools/findunused (should help make the app smaller).</li> <li>Don't enable code that is writing Parcel data to disk and reading it later.</li> <li>Don't subscribe to every package installed, instead use ssp filtering. Add filtering like below: -<br /> - <code><data android:scheme="package" android:ssp="com.android.pkg1" /><br /> - <data android:scheme="package" android:ssp="com.myapp.act1" /></code></li> +<pre class="devsite-click-to-copy"> +<data android:scheme="package" android:ssp="com.android.pkg1" /> +<data android:scheme="package" android:ssp="com.myapp.act1" /> +</pre> +</li> </ul> <h3 id="process-states">Understand the various process states in Android</h3> @@ -387,7 +399,7 @@ services include <code>batterystats</code>, <code>netstats</code>, <code>procstats</code>, and <code>usagestats</code>. You can find them with lines like this:</p> -<pre> +<pre class="devsite-click-to-copy"> ------ CHECKIN BATTERYSTATS (dumpsys batterystats --checkin) ------ 7,0,h,-2558644,97,1946288161,3,2,0,340,4183 7,0,h,-2553041,97,1946288161,3,2,0,340,4183 @@ -403,7 +415,7 @@ long running processes.</p> <p>Run for longer durations and track the memory of the process. Does it increase? Does it stay constant? Create Canonical use cases and run longevity -tests on these scenarios</p> +tests on these scenarios.</p> </body> </html> diff --git a/en/devices/tech/config/runtime_perms.html b/en/devices/tech/config/runtime_perms.html index 68e72c0e..9681b98b 100644 --- a/en/devices/tech/config/runtime_perms.html +++ b/en/devices/tech/config/runtime_perms.html @@ -57,7 +57,8 @@ model. Dangerous permissions are higher-risk permissions (such as <code>READ_CALENDAR</code>) that grant requesting applications access to private user data or control over the device that can negatively impact the user. To view a list of dangerous permissions, run the command:</p> -<pre> + +<pre class="devsite-terminal devsite-click-to-copy"> adb shell pm list permissions -g -d </pre> @@ -159,10 +160,14 @@ strings to AOSP.</p> providers for core OS functionality using the <code>DefaultPermissionGrantPolicy.java</code> in PackageManager. Examples:</p> -<p><code>ACTION_CALL (Dialer) Default</code><br> -<code>Phone, Contacts, SMS, Microphone</code></p> -<p><code>SMS_DELIVER_ACTION (SMS/MMS) Default</code><br> -<code>Phone, Contacts, SMS</code></p> +<pre class="devsite-click-to-copy"> +ACTION_CALL (Dialer) Default +Phone, Contacts, SMS, Microphone +</pre> +<pre class="devsite-click-to-copy"> +SMS_DELIVER_ACTION (SMS/MMS) Default +Phone, Contacts, SMS +</pre> <h3 id="defining-custom-perms">Defining custom permissions</h3> <p>You can define custom permissions and groups as <em>normal</em> or diff --git a/en/devices/tech/config/uicc.html b/en/devices/tech/config/uicc.html index 676d8167..1fa6952c 100644 --- a/en/devices/tech/config/uicc.html +++ b/en/devices/tech/config/uicc.html @@ -74,10 +74,12 @@ access; otherwise both certificate and package name need to match.</p> <h3 id=rule_example>Rule example</h3> <p>The application name is <code>com.google.android.apps.myapp</code> and the SHA-1 certificate in hex string is:</p> -<pre>AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4</pre> +<pre class="devsite-click-to-copy"> +AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4 +</pre> <p>The rule on UICC in hex string is:</p> -<pre> +<pre class="devsite-click-to-copy"> E243 <= 43 is value length in hex E135 C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4 @@ -97,10 +99,13 @@ Access Control Rules File (ACRF) at <code>0x4300</code> and looks for entries with AID <code>FFFFFFFFFFFF</code>. Entries with different AIDs are ignored, so rules for other use cases can co-exist.</p> <p>Example ACRF content in hex string:</p> -<pre>30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10</pre> +<pre class="devsite-click-to-copy"> +30 10 A0 08 04 06 FF FF FF FF FF FF 30 04 04 02 43 10 +</pre> <p>Example Access Control Conditions File (ACCF) content:</p> -<pre>30 16 04 14 61 ED 37 7E 85 D3 86 A8 DF EE 6B 86 4B D8 5B 0B FA A5 AF 81 +<pre class="devsite-click-to-copy"> +30 16 04 14 61 ED 37 7E 85 D3 86 A8 DF EE 6B 86 4B D8 5B 0B FA A5 AF 81 </pre> <p>In above example, <code>0x4310</code> is the address for ACCF, which contains @@ -204,7 +209,7 @@ developer key, with hash value tests also print out the expected certificate hash if certificates on UICC mismatch.</p> <p>Example output:</p> -<pre> +<pre class="devsite-click-to-copy"> junit.framework.AssertionFailedError: This test requires a SIM card with carrier privilege rule on it. Cert hash: 61ed377e85d386a8dfee6b864bd85b0bfaa5af81 </pre> @@ -222,7 +227,9 @@ tests to run only on devices configured with same token. Carrier API CTS tests support the device token <code>sim-card-with-certs</code>. For example, the following device token restricts carrier API tests to run only on device <code>abcd1234</code>:</p> -<pre>cts-tradefed run cts --device-token abcd1234:sim-card-with-certs</pre> +<pre class="devsite-terminal devsite-click-to-copy"> +cts-tradefed run cts --device-token abcd1234:sim-card-with-certs +</pre> <p>When running a test without using a device token, the test runs on all devices.</p> diff --git a/en/devices/tech/connect/block-numbers.html b/en/devices/tech/connect/block-numbers.html index 69e00e6d..2b797545 100644 --- a/en/devices/tech/connect/block-numbers.html +++ b/en/devices/tech/connect/block-numbers.html @@ -91,7 +91,7 @@ based on the block list, that is now possible with this feature.</li></ul> <h2 id="data-flow">Data flow</h2> -<img src="images/block-numbers-flow.png" alt="block numbers data flow" id="block-numbers-flow" /> +<img src="/devices/tech/connect/images/block-numbers-flow.png" alt="block numbers data flow" id="block-numbers-flow" /> <p class="img-caption"> <strong>Figure 1.</strong> Block phone numbers data flow </p> @@ -104,13 +104,13 @@ Here are example calls using the number-blocking new feature: <h3 id="launch-from-app">Launch blocked number manager from app</h3> -<pre> +<pre class="prettyprint"> Context.startActivity(telecomManager.createManageBlockedNumbersIntent(), null); </pre> <h3 id="query-blocked-numbers">Query blocked numbers</h3> -<pre> +<pre class="prettyprint"> Cursor c = getContentResolver().query(BlockedNumbers.CONTENT_URI, new String[]{BlockedNumbers.COLUMN_ID, BlockedNumbers.COLUMN_ORIGINAL_NUMBER, @@ -119,7 +119,7 @@ Cursor c = getContentResolver().query(BlockedNumbers.CONTENT_URI, <h3 id="put-blocked-number">Put blocked number</h3> -<pre> +<pre class="prettyprint"> ContentValues values = new ContentValues(); values.put(BlockedNumbers.COLUMN_ORIGINAL_NUMBER, "1234567890"); Uri uri = getContentResolver().insert(BlockedNumbers.CONTENT_URI, values); @@ -127,7 +127,7 @@ Uri uri = getContentResolver().insert(BlockedNumbers.CONTENT_URI, values); <h3 id="delete-blocked-number">Delete blocked number</h3> -<pre> +<pre class="prettyprint"> ContentValues values = new ContentValues(); values.put(BlockedNumbers.COLUMN_ORIGINAL_NUMBER, "1234567890"); Uri uri = getContentResolver().insert(BlockedNumbers.CONTENT_URI, values); @@ -233,7 +233,7 @@ Implementers can ensure their version of the feature works as intended by running the following CTS tests: </p> -<pre> +<pre class="devsite-click-to-copy"> android.provider.cts.BlockedNumberContractTest com.android.cts.numberblocking.hostside.NumberBlockingTest android.telecom.cts.ExtendedInCallServiceTest#testIncomingCallFromBlockedNumber_IsRejected @@ -244,11 +244,11 @@ android.telephony.cts.SmsManagerTest#testSmsBlocking The <code>BlockedNumberProvider</code> can be manipulated using <code>adb</code> commands after running <code>$ adb root</code>. For example: </p> -<pre> -$ adb root -$ adb shell content query --uri content://com.android.blockednumber/blocked -$ adb shell content insert --uri / content://com.android.blockednumber/blocked --bind / original_number:s:'6501002000' -$ adb shell content delete --uri / content://com.android.blockednumber/blocked/1 +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb root</code> +<code class="devsite-terminal">adb shell content query --uri content://com.android.blockednumber/blocked</code> +<code class="devsite-terminal">adb shell content insert --uri / content://com.android.blockednumber/blocked --bind / original_number:s:'6501002000'</code> +<code class="devsite-terminal">adb shell content delete --uri / content://com.android.blockednumber/blocked/1</code> </pre> </body> diff --git a/en/devices/tech/connect/data-saver.html b/en/devices/tech/connect/data-saver.html index 0d5721be..e9624295 100644 --- a/en/devices/tech/connect/data-saver.html +++ b/en/devices/tech/connect/data-saver.html @@ -62,22 +62,22 @@ Source Project (AOSP). See the screenshots below for examples. These screenshots show the Data Saver mode in use. </p> -<img src="images/data-saver-use.png" width="397" alt="Toggling Data Saver off/on" /> +<img src="/devices/tech/connect/images/data-saver-use.png" width="397" alt="Toggling Data Saver off/on" /> <p class="img-caption"> <strong>Figure 1.</strong> Toggling Data Saver off/on </p> -<img src="images/data-battery-saver.png" width="641" alt="Battery saver and Data Saver are on" /> +<img src="/devices/tech/connect/images/data-battery-saver.png" width="641" alt="Battery saver and Data Saver are on" /> <p class="img-caption"> <strong>Figure 2.</strong> When both battery saver and Data Saver are on </p> -<img src="images/data-saver-app.png" width="376" alt="App-specific data usage screen" /> +<img src="/devices/tech/connect/images/data-saver-app.png" width="376" alt="App-specific data usage screen" /> <p class="img-caption"> <strong>Figure 3.</strong> App-specific data usage screen: Settings > Apps > Data usage </p> -<img src="images/data-saver-quick-settings.png" width="446" alt="Data saver in the Quick Settings" /> +<img src="/devices/tech/connect/images/data-saver-quick-settings.png" width="446" alt="Data saver in the Quick Settings" /> <p class="img-caption"> <strong>Figure 4.</strong> Data saver states on the Quick Settings menu </p> @@ -130,20 +130,22 @@ Implementers can ensure their version of the feature works as intended by running the following CTS test: </p> -<pre> +<pre class="devsite-click-to-copy"> com.android.cts.net.HostsideRestrictBackgroundNetworkTests </pre> <p> In addition, <code>adb</code> commands can be used to conduct tests manually by -first running this command to see all available options:<br> -<code>$ adb shell cmd netpolicy</code> -</p> +first running this command to see all available options:</p> +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell cmd netpolicy +</pre> <p> -For example, this command returns the UIDs of the whitelisted apps:<br> -<code>$ adb shell cmd netpolicy list restrict-background-whitelist</code> -</p> +For example, this command returns the UIDs of the whitelisted apps:</p> +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell cmd netpolicy list restrict-background-whitelist +</pre> </body> </html> diff --git a/en/devices/tech/connect/emergency-affordance.html b/en/devices/tech/connect/emergency-affordance.html index 383449bd..bbaccacf 100644 --- a/en/devices/tech/connect/emergency-affordance.html +++ b/en/devices/tech/connect/emergency-affordance.html @@ -111,12 +111,12 @@ key.</li> </ul> <table> <tr> - <td width="50%"><img src="images/emergency-button.png" alt="emergency + <td width="50%"><img src="/devices/tech/connect/images/emergency-button.png" alt="emergency button" width="246" id="emergency-button" /> <p class="img-caption"> <strong>Figure 1.</strong> Long press the <strong>EMERGENCY</strong> button, highlighted with a red box, on the lock screen.</p></td> - <td width="50%"><img src="images/emergency-option.png" alt="emergency + <td width="50%"><img src="/devices/tech/connect/images/emergency-option.png" alt="emergency option" width="247" id="emergency-option" /> <p class="img-caption"> <strong>Figure 2.</strong> Tap the <strong>Emergency</strong> action item on @@ -125,11 +125,17 @@ the <em>Global Action Menu</em>.</p></td> </table> <p>This feature introduces the following internal components:</p> <ul> -<li>EmergencyAffordanceManager<br> -<code>frameworks/base/core/java/com/android/internal/policy/EmergencyAffordanceManager.java</code> -</li> <li>EmergencyAffordanceService<br> -<code>frameworks/base/services/core/java/com/android/server/emergency/EmergencyAffordanceService.java</code> -</li> </ul> +<li>EmergencyAffordanceManager +<pre class="devsite-click-to-copy"> +frameworks/base/core/java/com/android/internal/policy/EmergencyAffordanceManager.java +</pre> +</li> +<li>EmergencyAffordanceService +<pre class="devsite-click-to-copy"> +frameworks/base/services/core/java/com/android/server/emergency/EmergencyAffordanceService.java +</pre> +</li> +</ul> <h3 id="EmergencyAffordanceManager">EmergencyAffordanceManager</h3> <p>The EmergencyAffordanceManager provides an internal API to use the Emergency @@ -218,23 +224,23 @@ the RIL.</p> <h2 id="validation">Validation</h2> <p>While testing, on a debuggable build, the number that is called can be changed with the following command:</p> -<pre> -$ adb shell settings put global emergency_affordance_number <i><number_to_call></i> +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell settings put global emergency_affordance_number <var>NUMBER_TO_CALL</var> </pre> <p>Although this setting can be set on a normal user build, it will be ignored. To actually connect the call the number must be in the list of emergency numbers provided by the RIL. This can be temporarily set using the following command executed from a root shell on a userdebug device:</p> -<pre> -$ setprop ril.ecclist "$(getprop ril.ecclist),<i><number_to_call></i>" +<pre class="devsite-terminal devsite-click-to-copy"> +setprop ril.ecclist "$(getprop ril.ecclist),<var>NUMBER_TO_CALL</var>" </pre> <p>The following command can also be used to force the Emergency Affordance feature to be enabled even in the absence of an Indian mobile network being detected or an Indian SIM card being inserted.</p> -<pre> -$ adb shell settings put global force_emergency_affordance 1 +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell settings put global force_emergency_affordance 1 </pre> <p>During testing it is recommend that at least the following cases are diff --git a/en/devices/tech/dalvik/configure.html b/en/devices/tech/dalvik/configure.html index 79d61fdf..2018b9c5 100644 --- a/en/devices/tech/dalvik/configure.html +++ b/en/devices/tech/dalvik/configure.html @@ -104,7 +104,7 @@ enabled to work.</p> <p>Example usage (in product’s BoardConfig.mk):</p> -<pre><code>WITH_DEXPREOPT := true</code></pre> +<pre class="devsite-click-to-copy">WITH_DEXPREOPT := true</pre> <h3 id=dont_dexpreopt_prebuilts>DONT_DEXPREOPT_PREBUILTS</h3> @@ -116,8 +116,10 @@ to first boot time.</p> <p>Example usage (in product’s BoardConfig.mk):</p> -<pre><code>WITH_DEXPREOPT := true -DONT_DEXPREOPT_PREBUILTS := true</code></pre> +<pre class="devsite-click-to-copy"> +WITH_DEXPREOPT := true +DONT_DEXPREOPT_PREBUILTS := true +</pre> <h3 id=with_dexpreopt_boot_img_only>WITH_DEXPREOPT_BOOT_IMG_ONLY</h3> @@ -130,8 +132,10 @@ selectively disable app pre-optimization via <p>Example usage (in product’s BoardConfig.mk):</p> -<pre><code>WITH_DEXPREOPT := true -WITH_DEXPREOPT_BOOT_IMG_ONLY := true</code></pre> +<pre class="devsite-click-to-copy"> +WITH_DEXPREOPT := true +WITH_DEXPREOPT_BOOT_IMG_ONLY := true +</pre> <h3 id=local_dex_preopt>LOCAL_DEX_PREOPT</h3> @@ -152,7 +156,9 @@ APK signatures to remain valid.</p> <p>Example usage (in app’s Android.mk):</p> -<pre><code>LOCAL_DEX_PREOPT := false</code></pre> +<pre class="devsite-click-to-copy"> +LOCAL_DEX_PREOPT := false +</pre> <h3 id=product_dex_preopt_*>PRODUCT_DEX_PREOPT_*</h3> @@ -177,8 +183,10 @@ maximally used to improve first boot time.</p> <p>Example usage (in product’s device.mk):</p> -<pre><code>PRODUCT_DEX_PREOPT_DEFAULT_FLAGS := --compiler-filter=interpret-only -$(call add-product-dex-preopt-module-config,services,--compiler-filter=space)</code></pre> +<pre class="devsite-click-to-copy"> +PRODUCT_DEX_PREOPT_DEFAULT_FLAGS := --compiler-filter=interpret-only +$(call add-product-dex-preopt-module-config,services,--compiler-filter=space) +</pre> <p>These flags can also be used to selectively disable pre-optimization of a particular module or package by specifying <code>$(call @@ -187,7 +195,9 @@ product's device.mk file.</p> <p>Example usage (in product’s device.mk):</p> -<pre><code>$(call add-product-dex-preopt-module-config,Calculator,disable)</code></pre> +<pre class="devsite-click-to-copy"> +$(call add-product-dex-preopt-module-config,Calculator,disable) +</pre> <h2 id=other_odex>First boot installation of DEX_PREOPT files</h2> @@ -199,14 +209,17 @@ partition. They are then copied to the data partition on first boot.</p> <p>Example usage (in device-common.mk):</p> -<pre><code>PRODUCT_PACKAGES += \ +<pre class="devsite-click-to-copy"> +PRODUCT_PACKAGES += \ cppreopts.sh PRODUCT_PROPERTY_OVERRIDES += \ ro.cp_system_other_odex=1 -</code></pre> +</pre> <p>And in device's BoardConfig.mk:</p> -<pre><code>BOARD_USES_SYSTEM_OTHER_ODEX := true</code></pre> +<pre class="devsite-click-to-copy"> +BOARD_USES_SYSTEM_OTHER_ODEX := true +</pre> <p>See <a href="/devices/tech/ota/ab_updates.html#compilation">App compilation in background</a> to optionally include the compilation script and @@ -226,7 +239,9 @@ have to have its own copy, again wasting memory.</p> <p>Example usage (in product’s device.mk):</p> -<pre><code>PRODUCT_COPY_FILES += <filename>:system/etc/preloaded-classes</code></pre> +<pre class="devsite-click-to-copy"> +PRODUCT_COPY_FILES += <filename>:system/etc/preloaded-classes +</pre> <p class="note"><strong>Note:</strong> This line must be placed before inheriting any product configuration makefiles that get the default one from @@ -246,7 +261,9 @@ post-L in AOSP, a custom image classes list can be specified using <p>Example usage (in product’s device.mk):</p> -<pre><code>PRODUCT_DEX_PREOPT_BOOT_FLAGS += --image-classes=<filename></code></pre> +<pre class="devsite-click-to-copy"> +PRODUCT_DEX_PREOPT_BOOT_FLAGS += --image-classes=<filename> +</pre> <h2 id=compiled_classes_list>Compiled Classes List</h2> @@ -262,7 +279,9 @@ also be specified using <code>PRODUCT_DEX_PREOPT_BOOT_FLAGS</code>.</p> <p>Example usage (in product’s device.mk):</p> -<pre><code>PRODUCT_COPY_FILES += <filename>:system/etc/compiled-classes</code></pre> +<pre class="devsite-click-to-copy"> +PRODUCT_COPY_FILES += <filename>:system/etc/compiled-classes +</pre> <p class="note"><strong>Note:</strong> This line must be placed before inheriting any product configuration makefiles that get the default one from @@ -280,9 +299,13 @@ methods that are too large to be represented by the compiler’s internal representation. <li><em>speed</em> - compiles most methods and maximizes runtime performance, which is the default option. + <li><em>speed-profile</em> - compiles methods passed from a profile file + through the <em>--profile-file</em> option or <em>--profile-file-fd</em> option. <li><em>balanced</em> - attempts to get the best performance return on compilation investment. <li><em>space</em> - compiles a limited number of methods, prioritizing storage space. <li><em>interpret-only</em> - skips all compilation and relies on the interpreter to run code. + <li><em>verify-profile</em> - skips all compilation and only performs verification of methods passed + from a profile file through the <em>--profile-file</em> option or <em>--profile-file-fd</em> option. <li><em>verify-none</em> - special option that skips verification and compilation, should be used only for trusted system code. </ul> @@ -299,8 +322,10 @@ should enable PIC compilation.</p> <p>Example usage (in product’s device.mk):</p> -<pre><code>WITH_DEXPREOPT := true -WITH_DEXPREOPT_PIC := true</code></pre> +<pre class="devsite-click-to-copy"> +WITH_DEXPREOPT := true +WITH_DEXPREOPT_PIC := true +</pre> <p>Starting in Android 7.0, PIC compilation is enabled by default.</p> @@ -316,14 +341,18 @@ regressions may appear in benchmarking.</p> <p>Example usage (in product’s device.mk):</p> -<pre><code>WITH_ART_SMALL_MODE := true</code></pre> +<pre class="devsite-click-to-copy"> +WITH_ART_SMALL_MODE := true +</pre> <p>In future releases, this build option will be removed since it can be done with this (in product’s device.mk):</p> -<pre><code>PRODUCT_PROPERTY_OVERRIDES += \ +<pre class="devsite-click-to-copy"> +PRODUCT_PROPERTY_OVERRIDES += \ dalvik.vm.dex2oat-filter=interpret-only \ - dalvik.vm.image-dex2oat-filter=speed</code></pre> + dalvik.vm.image-dex2oat-filter=speed +</pre> <h2 id=dalvik_vm_properties>dalvik.vm Properties</h2> @@ -383,23 +412,29 @@ all that is necessary. <p>BoardConfig.mk:</p> -<pre><code>WITH_DEXPREOPT := true</code></pre> +<pre class="devsite-click-to-copy"> +WITH_DEXPREOPT := true +</pre> <p>If this causes the system image to become too large, the next thing to try is disabling pre-optimization of the prebuilts. <p>BoardConfig.mk:</p> -<pre><code>WITH_DEXPREOPT := true -DONT_DEXPREOPT_PREBUILTS := true</code></pre> +<pre class="devsite-click-to-copy"> +WITH_DEXPREOPT := true +DONT_DEXPREOPT_PREBUILTS := true +</pre> <p>Again, if the system image is still too large, try pre-optimizing only the boot image. <p>BoardConfig.mk:</p> -<pre><code>WITH_DEXPREOPT := true -WITH_DEXPREOPT_BOOT_IMG_ONLY := true</code></pre> +<pre class="devsite-click-to-copy"> +WITH_DEXPREOPT := true +WITH_DEXPREOPT_BOOT_IMG_ONLY := true +</pre> <p>However, limiting to pre-optimizing only the boot-image means all apps will have to be optimized on first boot. In order to avoid this, it is possible to @@ -413,12 +448,16 @@ potentially interpreting more code and impacting runtime performance. <p>BoardConfig.mk:</p> -<pre><code>WITH_DEXPREOPT := true -DONT_DEXPREOPT_PREBUILTS := true</code></pre> +<pre class="devsite-click-to-copy"> +WITH_DEXPREOPT := true +DONT_DEXPREOPT_PREBUILTS := true +</pre> <p>device.mk:</p> -<pre><code>PRODUCT_DEX_PREOPT_BOOT_FLAGS := --compiler-filter=space</code></pre> +<pre class="devsite-click-to-copy"> +PRODUCT_DEX_PREOPT_BOOT_FLAGS := --compiler-filter=space +</pre> <p>If a device has very limited system partition space, it’s possible to compile a subset of classes in the boot classpath using the compiled classes list. Boot @@ -427,12 +466,16 @@ could affect runtime performance. <p>BoardConfig.mk:</p> -<pre><code>WITH_DEXPREOPT := true -WITH_DEXPREOPT_BOOT_IMG_ONLY := true</code></pre> +<pre class="devsite-click-to-copy"> +WITH_DEXPREOPT := true +WITH_DEXPREOPT_BOOT_IMG_ONLY := true +</pre> <p>device.mk:</p> -<pre><code>PRODUCT_COPY_FILES += <filename>:system/etc/compiled-classes</code></pre> +<pre class="devsite-click-to-copy"> +PRODUCT_COPY_FILES += <filename>:system/etc/compiled-classes +</pre> <p>If a device has both limited space in the system and data partitions, compiler filter flags can be used to disable compilation of certain apps. This will save @@ -446,13 +489,17 @@ speed. <p>BoardConfig.mk:</p> -<pre><code>WITH_DEXPREOPT := true -DONT_DEXPREOPT_PREBUILTS := true</code></pre> +<pre class="devsite-click-to-copy"> +WITH_DEXPREOPT := true +DONT_DEXPREOPT_PREBUILTS := true +</pre> <p>device.mk:</p> -<pre><code>PRODUCT_DEX_PREOPT_DEFAULT_FLAGS := --compiler-filter=interpret-only -$(call add-product-dex-preopt-module-config,services,--compiler-filter=space)</code></pre> +<pre class="devsite-click-to-copy"> +PRODUCT_DEX_PREOPT_DEFAULT_FLAGS := --compiler-filter=interpret-only +$(call add-product-dex-preopt-module-config,services,--compiler-filter=space) +</pre> <p>For a major version upgrade OTA, it can be useful to blacklist certain apps from being pre-optimized since they will likely be out of date. This can be @@ -461,11 +508,15 @@ done by specifying <code>LOCAL_DEX_PREOPT</code> (for all products) or with <p>BoardConfig.mk:</p> -<pre><code>WITH_DEXPREOPT := true</code></pre> +<pre class="devsite-click-to-copy"> +WITH_DEXPREOPT := true +</pre> <p>Android.mk (of blacklisted apps):</p> -<pre><code>LOCAL_DEX_PREOPT := false</code></pre> +<pre class="devsite-click-to-copy"> +LOCAL_DEX_PREOPT := false +</pre> </body> </html> diff --git a/en/devices/tech/dalvik/dex-format.html b/en/devices/tech/dalvik/dex-format.html index 3ff22c0d..fde14a8b 100644 --- a/en/devices/tech/dalvik/dex-format.html +++ b/en/devices/tech/dalvik/dex-format.html @@ -291,7 +291,7 @@ in the detection of certain forms of corruption. The value also encodes a format version number as three decimal digits, which is expected to increase monotonically over time as the format evolves.</p> -<pre> +<pre class="devsite-click-to-copy"> ubyte[8] DEX_FILE_MAGIC = { 0x64 0x65 0x78 0x0a 0x30 0x33 0x38 0x00 } = "dex\n038\0" </pre> @@ -328,7 +328,7 @@ header whose <code>endian_tag</code> is <code>REVERSE_ENDIAN_CONSTANT</code> instead of <code>ENDIAN_CONSTANT</code>, it would know that the file has been byte-swapped from the expected form.</p> -<pre> +<pre class="devsite-click-to-copy"> uint ENDIAN_CONSTANT = 0x12345678; uint REVERSE_ENDIAN_CONSTANT = 0x78563412; </pre> @@ -345,7 +345,7 @@ an index value is absent.</p> <p>The chosen value for <code>NO_INDEX</code> is representable as a single byte in the <code>uleb128p1</code> encoding.</p> -<pre> +<pre class="devsite-click-to-copy"> uint NO_INDEX = 0xffffffff; // == -1 if treated as a signed int </pre> @@ -2659,7 +2659,7 @@ each register for the <code>DBG_RESTART_LOCAL</code> code.</p> registers by a small amount and then emit a new position table entry. The formula for the increments are as follows:</p> -<pre> +<pre class="devsite-click-to-copy"> DBG_FIRST_SPECIAL = 0x0a // the smallest special opcode DBG_LINE_BASE = -4 // the smallest line number increment DBG_LINE_RANGE = 15 // the number of line increments represented diff --git a/en/devices/tech/dalvik/gc-debug.html b/en/devices/tech/dalvik/gc-debug.html index 029fde29..b1a62fe0 100644 --- a/en/devices/tech/dalvik/gc-debug.html +++ b/en/devices/tech/dalvik/gc-debug.html @@ -216,8 +216,11 @@ to <code>dalvikvm</code> when starting a command line program. When an app gets the ANR request signal (SIGQUIT) it dumps information related to its locks, thread stacks, and GC performance.</p> -<p>The way to get GC timing dumps is to use:<br> -<code>$ adb shell kill -S QUIT <pid></code></p> +<p>The way to get GC timing dumps is to use:</p> + +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell kill -S QUIT <var>PID</var> +</pre> <p>This creates a <code>traces.txt</code> file in <code>/data/anr/</code>. This file contains some ANR dumps as well as GC timings. You can locate the @@ -226,7 +229,7 @@ show a few things that may be of interest. It will show the histogram info for each GC type’s phases and pauses. The pauses are usually more important to look at. For example:</p> -<pre> +<pre class="devsite-click-to-copy"> sticky concurrent mark sweep paused: Sum: 5.491ms 99% C.I. 1.464ms-2.133ms Avg: 1.830ms Max: 2.133ms </pre> @@ -240,14 +243,14 @@ determine if long pauses are caused by the GC being slow or the thread suspending slowly. Here is an example of what a normal time to suspend resembles on a Nexus 5:</p> -<pre> +<pre class="devsite-click-to-copy"> suspend all histogram: Sum: 1.513ms 99% C.I. 3us-546.560us Avg: 47.281us Max: 601us </pre> <p>There are also a few other areas of interest, such as total time spent, GC throughput, etc. Examples:</p> -<pre> +<pre class="devsite-click-to-copy"> Total time spent in GC: 502.251ms Mean GC size throughput: 92MB/s Mean GC object throughput: 1.54702e+06 objects/s @@ -255,15 +258,15 @@ Mean GC object throughput: 1.54702e+06 objects/s <p>Here is an example of how to dump the GC timings of an already running app: -<pre> -$ adb shell kill -s QUIT <pid> -$ adb pull /data/anr/traces.txt +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb shell kill -s QUIT <var>PID</var></code> +<code class="devsite-terminal">adb pull /data/anr/traces.txt</code> </pre> <p>At this point the GC timings are inside of traces.txt. Here is example output from Google maps:</p> -<pre> +<pre class="devsite-click-to-copy"> Start Dumping histograms for 34 iterations for sticky concurrent mark sweep ScanGrayAllocSpaceObjects: Sum: 196.174ms 99% C.I. 0.011ms-11.615ms Avg: 1.442ms Max: 14.091ms FreeList: Sum: 140.457ms 99% C.I. 6us-1676.749us Avg: 128.505us Max: 9886us @@ -342,8 +345,8 @@ reasons. The checks will catch a few errors that could cause heap corruption such as using invalid/stale local and global references. Here is how to enable CheckJNI:</p> -<pre> -$ adb shell setprop dalvik.vm.checkjni true +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell setprop dalvik.vm.checkjni true </pre> <p>Forcecopy mode is another part of CheckJNI that is very useful for detecting @@ -355,8 +358,8 @@ the red zone don’t match what is expected, this usually means a buffer overrun or underrun occurred. This would cause CheckJNI to abort. Here is how to enable forcecopy mode:</p> -<pre> -$ adb shell setprop dalvik.vm.jniopts forcecopy +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell setprop dalvik.vm.jniopts forcecopy </pre> <p>One example of an error that CheckJNI should catch is writing past the end of @@ -388,18 +391,18 @@ that valgrind is orders of magnitude slower than normal execution.</p> <p>Here is an example use:</p> -<pre> +<pre class="devsite-click-to-copy"> # build and install -$ mmm external/valgrind -$ adb remount && adb sync +<code class="devsite-terminal">mmm external/valgrind</code> +<code class="devsite-terminal">adb remount && adb sync</code> # disable selinux -$ adb shell setenforce 0 -$ adb shell setprop wrap.com.android.calculator2 +<code class="devsite-terminal">adb shell setenforce 0</code> +<code class="devsite-terminal">adb shell setprop wrap.com.android.calculator2</code> "TMPDIR=/data/data/com.android.calculator2 logwrapper valgrind" # push symbols -$ adb shell mkdir /data/local/symbols -$ adb push $OUT/symbols /data/local/symbols -$ adb logcat +<code class="devsite-terminal">adb shell mkdir /data/local/symbols</code> +<code class="devsite-terminal">adb push $OUT/symbols /data/local/symbols</code> +<code class="devsite-terminal">adb logcat</code> </pre> @@ -410,7 +413,7 @@ useful information: <code>art E 5955 5955 art/runtime/gc/collector/mark_sweep.cc:383] Tried to mark 0x2 not contained by any spaces</code></p> -<pre> +<pre class="devsite-click-to-copy"> art E 5955 5955 art/runtime/gc/collector/mark_sweep.cc:384] Attempting see if it's a bad root art E 5955 5955 art/runtime/gc/collector/mark_sweep.cc:485] Found invalid @@ -435,7 +438,7 @@ href="https://android-review.googlesource.com/#/c/133932/">https://android-revie <p>In the case where the object isn’t a root, output similar to the following prints:</p> -<pre> +<pre class="devsite-click-to-copy"> 01-15 12:38:00.196 1217 1238 E art : Attempting see if it's a bad root 01-15 12:38:00.196 1217 1238 F art : art/runtime/gc/collector/mark_sweep.cc:381] Can't mark invalid object diff --git a/en/devices/tech/dalvik/jit-compiler.html b/en/devices/tech/dalvik/jit-compiler.html index 6c874d84..9090349c 100644 --- a/en/devices/tech/dalvik/jit-compiler.html +++ b/en/devices/tech/dalvik/jit-compiler.html @@ -54,7 +54,7 @@ JIT/AOT Compilation</a> on developer.android.com for a more thorough overview. <h2 id="architectural-overview">Architectural Overview</h2> -<img src="images/jit-arch.png" alt="JIT architecture" width="633" id="JIT-architecture" /> +<img src="/devices/tech/dalvik/images/jit-arch.png" alt="JIT architecture" width="633" id="JIT-architecture" /> <p class="img-caption"> <strong>Figure 1.</strong> JIT architecture - how it works </p> @@ -83,12 +83,12 @@ application has access to the directory. compilation.</li> </ol> -<img src="images/jit-profile-comp.png" alt="Profile-guided comp" width="452" id="JIT-profile-comp" /> +<img src="/devices/tech/dalvik/images/jit-profile-comp.png" alt="Profile-guided comp" width="452" id="JIT-profile-comp" /> <p class="img-caption"> <strong>Figure 2.</strong> Profile-guided compilation </p> -<img src="images/jit-daemon.png" alt="JIT daemon" width="718" id="JIT-daemon" /> +<img src="/devices/tech/dalvik/images/jit-daemon.png" alt="JIT daemon" width="718" id="JIT-daemon" /> <p class="img-caption"> <strong>Figure 3.</strong> How the daemon works </p> @@ -103,7 +103,7 @@ to behave more like shared libraries. See the following high-level overview of how JIT works in the next diagram. </p> -<img src="images/jit-workflow.png" alt="JIT architecture" width="707" id="JIT-workflow" /> +<img src="/devices/tech/dalvik/images/jit-workflow.png" alt="JIT architecture" width="707" id="JIT-workflow" /> <p class="img-caption"> <strong>Figure 4.</strong> JIT data flow </p> @@ -183,7 +183,7 @@ compilation to a later stage). The compilation levels can be configured via system properties with the defaults being: </p> -<pre> +<pre class="devsite-click-to-copy"> pm.dexopt.install=interpret-only pm.dexopt.bg-dexopt=speed-profile pm.dexopt.ab-ota=speed-profile @@ -211,20 +211,20 @@ copying and pasting. A few common use cases: <h3 id="turn-on-jit-logging">Turn on JIT logging</h3> -<pre> -$ adb root -$ adb shell stop -$ adb shell setprop dalvik.vm.extra-opts -verbose:jit -$ adb shell start +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb root</code> +<code class="devsite-terminal">adb shell stop</code> +<code class="devsite-terminal">adb shell setprop dalvik.vm.extra-opts -verbose:jit</code> +<code class="devsite-terminal">adb shell start</code> </pre> <h3 id="disable-jit-and-run-applications-in-interpreter">Disable JIT</h3> -<pre> -$ adb root -$ adb shell stop -$ adb shell setprop dalvik.vm.usejit false -$ adb shell start +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb root</code> +<code class="devsite-terminal">adb shell stop</code> +<code class="devsite-terminal">adb shell setprop dalvik.vm.usejit false</code> +<code class="devsite-terminal">adb shell start</code> </pre> <h3 id="force-compilation-of-a-specific-package">Force compilation of a specific @@ -232,11 +232,15 @@ package</h3> <ul> <li>Profile-based: -<code>$ adb shell cmd package compile -m speed-profile -f -my-package</code> +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell cmd package compile -m speed-profile -f my-package +</pre> +</li> <li>Full: -<code>$ adb shell cmd package compile -m speed -f -my-package</code></li> +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell cmd package compile -m speed -f my-package +</pre> +</li> </ul> <h3 id="force-compilation-of-all-packages">Force compilation of all @@ -244,20 +248,31 @@ packages</h3> <ul> <li>Profile-based: -<code>$ adb shell cmd package compile -m speed-profile -f --a</code> +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell cmd package compile -m speed-profile -f -a +</pre> +</li> <li>Full: -<code>$ adb shell cmd package compile -m speed -f -a</code></li></ul> +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell cmd package compile -m speed -f -a +</pre> +</li> +</ul> <h3 id="clear-profile-data-and-remove-compiled-code">Clear profile data and remove compiled code</h3> <ul> <li>One package: -<code>$ adb shell cmd package compile --reset my-package</code> +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell cmd package compile --reset my-package +</pre> +</li> <li>All packages -<code>$ adb shell cmd package compile --reset --a</code></li> +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell cmd package compile --reset -a +</pre> +</li> </ul> <h2 id="recommendation">Recommendation</h2> @@ -270,7 +285,7 @@ Note that it is strongly recommended to use the default following support. </p> -<pre> +<pre class="devsite-click-to-copy"> pm.dexopt.install=interpret-only pm.dexopt.bg-dexopt=speed-profile pm.dexopt.boot=verify-profile (or interpret-only) @@ -281,7 +296,7 @@ Here’s a detailed explanation about the <code>pm.dexopt</code> options, and th reasoning for our recommendations: </p> -<pre> +<pre class="devsite-click-to-copy"> pm.dexopt.install </pre> @@ -290,7 +305,7 @@ This is the compilation filter used when installing application through the Play Store. For faster installs we recommend <code>interpret-only</code>. </p> -<pre> +<pre class="devsite-click-to-copy"> pm.dexopt.bg-dexopt </pre> @@ -300,7 +315,7 @@ fully charged. We recommend using <code>speed-profile</code> to take advantage of profile guided compilation and save on storage. </p> -<pre> +<pre class="devsite-click-to-copy"> pm.dexopt.ab-ota </pre> @@ -311,7 +326,7 @@ update. If the device supports A/B OTA, we recommend using save on storage. </p> -<pre> +<pre class="devsite-click-to-copy"> pm.dexopt.nsys-library pm.dexopt.shared-apk pm.dexopt.core-app @@ -324,7 +339,7 @@ the <code>speed</code> filter, as the platform does not support efficient profiling of them. </p> -<pre> +<pre class="devsite-click-to-copy"> pm.dexopt.first-boot </pre> @@ -336,7 +351,7 @@ use the phone for the very first time. Note that if all applications in /system are already speed compiled, <code>pm.dexopt.first-boot</code> has no effect. </p> -<pre> +<pre class="devsite-click-to-copy"> pm.dexopt.boot </pre> @@ -364,11 +379,13 @@ filter. To do this, edit the following files to include these entries. <p>Add the following entry to <code>BoardConfig.mk</code>:</p> -<pre>WITH_DEXPREOPT := true</pre> +<pre class="devsite-click-to-copy"> +WITH_DEXPREOPT := true +</pre> <p>Add the following entry to <code>device.mk</code>:</p> -<pre> +<pre class="devsite-click-to-copy"> PRODUCT_DEX_PREOPT_DEFAULT_FLAGS := --compiler-filter=interpret-only </pre> diff --git a/en/devices/tech/datausage/tags-explained.html b/en/devices/tech/datausage/tags-explained.html index 1d3dc6b9..73fb8e17 100644 --- a/en/devices/tech/datausage/tags-explained.html +++ b/en/devices/tech/datausage/tags-explained.html @@ -35,10 +35,11 @@ the tag's uid_tag portion, and stats are collected for the acct_tag portion separately.</p> <p>Without explicit tagging, the qtaguid module will assume the <code>default_tag: {acct_tag=0, uid_tag=10003}</code></p> -<pre><code> a: {acct_tag=1, uid_tag=10003} +<pre class="devsite-click-to-copy"> + a: {acct_tag=1, uid_tag=10003} b: {acct_tag=2, uid_tag=10003} c: {acct_tag=3, uid_tag=10003} -</code></pre> +</pre> <p><code>a, b, c…</code> represent explicit tags associated with specific sockets.</p> <p><code>default_tag (acct_tag=0)</code> is the default accounting tag that contains the total traffic for that uid, including all untagged diff --git a/en/devices/tech/debug/asan.html b/en/devices/tech/debug/asan.html index 0ab286dc..353aa4bd 100644 --- a/en/devices/tech/debug/asan.html +++ b/en/devices/tech/debug/asan.html @@ -62,7 +62,7 @@ to the build rules. Clang may find bugs in your code that GCC missed.</p> <p>Add <code>LOCAL_SANITIZE:=address</code> to the build rule of the executable.</p> -<pre> +<pre class="devsite-click-to-copy"> LOCAL_SANITIZE:=address </pre> @@ -83,7 +83,7 @@ which are built with ASan, you'll need two copies of the library. The recommended way to do this is to add the following to <code>Android.mk</code> for the module in question:</p> -<pre> +<pre class="devsite-click-to-copy"> LOCAL_SANITIZE:=address LOCAL_MODULE_RELATIVE_PATH := asan </pre> @@ -95,7 +95,7 @@ LOCAL_MODULE_RELATIVE_PATH := asan <p>For system daemons, add the following to the appropriate section of <code>/init.rc</code> or <code>/init.$device$.rc</code>.</p> -<pre> +<pre class="devsite-click-to-copy"> setenv LD_LIBRARY_PATH /system/lib/asan </pre> @@ -111,9 +111,9 @@ sync</code>.</p> when present by reading <code>/proc/$PID/maps</code>. If it's not, you may need to disable SELinux, like so:</p> -<pre> -$ adb root -$ adb shell setenforce 0 +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb root</code> +<code class="devsite-terminal">adb shell setenforce 0</code> # restart the process with adb shell kill $PID # if it is a system service, or may be adb shell stop; adb shell start. </pre> @@ -126,7 +126,7 @@ of Android is built without frame pointers. As a result, you will often get only one or two meaningful frames. To fix this, either rebuild the library with ASan (recommended!), or with:</p> -<pre> +<pre class="devsite-click-to-copy"> LOCAL_CFLAGS:=-fno-omit-frame-pointer LOCAL_ARM_MODE:=arm </pre> @@ -167,7 +167,7 @@ this). Edit the Zygote record in <code>system/core/rootdir/init.zygote(<em>32|64</em>).rc</code> to add the following lines:</p> -<pre> +<pre class="devsite-click-to-copy"> setenv LD_LIBRARY_PATH /system/lib/asan:/system/lib setenv ASAN_OPTIONS allow_user_segv_handler=true @@ -186,10 +186,10 @@ trading some memory overhead for slower application startup.</p> that’s used to run apps under Valgrind. The following example runs the Gmail app under ASan:</p> -<pre> -$ adb root -$ adb shell setenforce 0 # disable SELinux -$ adb shell setprop wrap.com.google.android.gm "asanwrapper" +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb root</code> +<code class="devsite-terminal">adb shell setenforce 0 # disable SELinux</code> +<code class="devsite-terminal">adb shell setprop wrap.com.google.android.gm "asanwrapper"</code> </pre> <p>In this context, asanwrapper rewrites <code>/system/bin/app_process</code> @@ -209,16 +209,16 @@ AddressSanitizer at once.</p> <p>Run the following commands in the same build tree.</p> -<pre> -$ make -j42 -$ SANITIZE_TARGET=address make -j42 +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">make -j42</code> +<code class="devsite-terminal">SANITIZE_TARGET=address make -j42</code> </pre> <p>In this mode, <code>userdata.img</code> contains extra libraries and must be flashed to the device as well. Use the following command line:</p> -<pre> -$ fastboot flash userdata && fastboot flashall +<pre class="devsite-terminal devsite-click-to-copy"> +fastboot flash userdata && fastboot flashall </pre> <p>At the moment of this writing, modern Nexus and Pixel devices boot to the UI in this mode.</p> diff --git a/en/devices/tech/debug/dumpsys.html b/en/devices/tech/debug/dumpsys.html index 80f93e54..e87722ba 100644 --- a/en/devices/tech/debug/dumpsys.html +++ b/en/devices/tech/debug/dumpsys.html @@ -34,8 +34,8 @@ output, specify the service you would like to examine. </p> <p>For example, the following command:</p> -<pre> -$ adb shell dumpsys input +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell dumpsys input </pre> <p>provides system data for input components such as touchscreens or built-in @@ -47,8 +47,12 @@ keyboards.</p> <p>For a complete list of system services that you can use with dumpsys, try the following command:</p> -<pre class="no-pretty-print"> -$ adb shell dumpsys -l +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell dumpsys -l +</pre> + +<p>Example output:</p> +<pre class="devsite-click-to-copy"> Currently running services: DockObserver SurfaceFlinger diff --git a/en/devices/tech/debug/eval_perf.html b/en/devices/tech/debug/eval_perf.html index 44173fe0..79c77de9 100644 --- a/en/devices/tech/debug/eval_perf.html +++ b/en/devices/tech/debug/eval_perf.html @@ -169,8 +169,10 @@ thread enters uninterruptible sleep. It is critical for performance analysis because uninterruptible sleep is a very common indicator of jitter.</li> <li>Ensure you have sufficient tracing for the GPU and display pipelines. On recent Qualcomm SOCs, tracepoints are enabled using:</li> -<pre>$ adb shell "echo 1 > /d/tracing/events/kgsl/enable" -$ adb shell "echo 1 > /d/tracing/events/mdss/enable"</pre> +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb shell "echo 1 > /d/tracing/events/kgsl/enable"</code> +<code class="devsite-terminal">adb shell "echo 1 > /d/tracing/events/mdss/enable"</code> +</pre> <p>These events remain enabled when you run systrace so you can see additional information in the trace about the display pipeline (MDSS) in the diff --git a/en/devices/tech/debug/ftrace.html b/en/devices/tech/debug/ftrace.html index e48362df..2fbaba4b 100644 --- a/en/devices/tech/debug/ftrace.html +++ b/en/devices/tech/debug/ftrace.html @@ -55,10 +55,14 @@ way to determine the correct values other than looking at the appropriate header divided into categories in <code>/d/tracing/events</code>. <p>To enable events on a per-category basis, use: -<pre>$ echo 1 > /d/tracing/events/irq/enable</pre> +<pre class="devsite-terminal devsite-click-to-copy"> +echo 1 > /d/tracing/events/irq/enable +</pre> <p>To enable events on per-event basis, use: -<pre>$ echo 1 > /d/tracing/events/sched/sched_wakeup/enable</pre> +<pre class="devsite-terminal devsite-click-to-copy"> +echo 1 > /d/tracing/events/sched/sched_wakeup/enable +</pre> <p>If extra events have been enabled by writing to sysfs nodes, they will <strong>not</strong> be reset by atrace. A common pattern @@ -66,9 +70,11 @@ for Qualcomm device bringup is to enable <code>kgsl</code> (GPU) and <code>mdss</code> (display pipeline) tracepoints and then use atrace or <a href="/devices/tech/debug/systrace.html">systrace</a>:</p> -<pre>$ adb shell "echo 1 > /d/tracing/events/mdss/enable" -$ adb shell "echo 1 > /d/tracing/events/kgsl/enable" -$ ./systrace.py sched freq idle am wm gfx view binder_driver irq workq ss sync -t 10 -b 96000 -o full_trace.html</pre> +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb shell "echo 1 > /d/tracing/events/mdss/enable"</code> +<code class="devsite-terminal">adb shell "echo 1 > /d/tracing/events/kgsl/enable"</code> +<code class="devsite-terminal">./systrace.py sched freq idle am wm gfx view binder_driver irq workq ss sync -t 10 -b 96000 -o full_trace.html</code> +</pre> <p>You can also use ftrace without atrace or systrace, which is useful when you want kernel-only traces (or if you've taken the time to write @@ -76,13 +82,25 @@ the user-mode tracing property by hand). To run just ftrace:</p> <ol> <li>Set the buffer size to a value large enough for your trace: -<pre>$ echo 96000 > /d/tracing/buffer_size_kb</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +echo 96000 > /d/tracing/buffer_size_kb +</pre> +</li> <li>Enable tracing: -<pre>$ echo 1 > /d/tracing/tracing_on</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +echo 1 > /d/tracing/tracing_on +</pre> +</li> <li>Run your test, then disable tracing: -<pre>$ echo 0 > /d/tracing/tracing_on</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +echo 0 > /d/tracing/tracing_on +</pre> +</li> <li>Dump the trace: -<pre>$ cat /d/tracing/trace > /data/local/tmp/trace_output</pre> +<pre class="devsite-terminal devsite-click-to-copy"> +cat /d/tracing/trace > /data/local/tmp/trace_output +</pre> +</li> </ol> <p>The trace_output gives the trace in text form. To visualize it using @@ -90,7 +108,9 @@ Catapult, get the <a href="https://github.com/catapult-project/catapult/tree/master/">Catapult repository</a> from Github and run trace2html:</p> -<pre>$ catapult/tracing/bin/trace2html ~/path/to/trace_file</pre> +<pre class="devsite-terminal devsite-click-to-copy"> +catapult/tracing/bin/trace2html ~/path/to/trace_file +</pre> <p>By default, this writes <code>trace_file.html</code> in the same directory.</p> @@ -120,7 +140,9 @@ tree</a> (<code>tracing/bin/html2trace</code>) to uncompress the trace.</li> <li>Find a line at the beginning of the trace containing <code>tracing_mark_sync</code>. It should look something like this: -<pre><5134>-5134 (-----) [003] ...1 68.104349: tracing_mark_write: trace_event_clock_sync: parent_ts=68.104286</pre> +<pre class="devsite-click-to-copy"> +<5134>-5134 (-----) [003] ...1 68.104349: tracing_mark_write: trace_event_clock_sync: parent_ts=68.104286 +</pre> <br>If this line does not exist (or if you used ftrace without atrace), then timings will be relative from the first event in the ftrace log. @@ -154,11 +176,16 @@ CONFIG_IRQSOFF_TRACER=y, CONFIG_FUNCTION_PROFILER=y, and CONFIG_PREEMPT_TRACER=y </li> <li>Rebuild and boot the new kernel.</li> <li>Run the following to check for available tracers: -<pre>$ cat /d/tracing/available_tracers</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +cat /d/tracing/available_tracers +</pre> +</li> <li>Confirm the command returns <code>function</code>, <code>irqsoff</code>, <code>preemptoff</code>, and <code>preemptirqsoff</code>.</li> <li>Run the following to ensure dynamic ftrace is working: -<pre>$ cat /d/tracing/available_filter_functions | grep <a function you care about></pre> +<pre class="devsite-terminal devsite-click-to-copy"> +cat /d/tracing/available_filter_functions | grep <a function you care about> +</pre> </li> </ol> @@ -195,22 +222,43 @@ so it's time to use the function profiler:</p> <ol> <li>As functions are sometimes renamed by the compiler, confirm <code>ion_client_destroy</code> is there by using: -<pre>$ cat /d/tracing/available_filter_functions | grep ion_client_destroy</pre> +<pre class="devsite-terminal devsite-click-to-copy"> +cat /d/tracing/available_filter_functions | grep ion_client_destroy +</pre> </li> <li>After confirming it is there, use it as the ftrace filter: -<pre>$ echo ion_client_destroy > /d/tracing/set_ftrace_filter</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +echo ion_client_destroy > /d/tracing/set_ftrace_filter +</pre> +</li> <li>Turn on the function profiler: -<pre>$ echo function > /d/tracing/current_tracer</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +echo function > /d/tracing/current_tracer +</pre> +</li> <li>Turn on stack traces whenever a filter function is called: -<pre>$ echo func_stack_trace > /d/tracing/trace_options</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +echo func_stack_trace > /d/tracing/trace_options +</pre> +</li> <li>Increase the buffer size: -<pre>$ echo 64000 > /d/tracing/buffer_size_kb</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +echo 64000 > /d/tracing/buffer_size_kb +</pre> +</li> <li>Turn on tracing: -<pre>$ echo 1 > /d/tracing/trace_on</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +echo 1 > /d/tracing/trace_on +</pre> +</li> <li>Run the test and get the trace: -<pre>$ cat /d/tracing/trace > /data/local/tmp/trace</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +cat /d/tracing/trace > /data/local/tmp/trace +</pre> +</li> <li>View the trace to see lots and lots of stack traces: -<pre> cameraserver-643 [003] ...1 94.192991: ion_client_destroy <-ion_release +<pre class="devsite-click-to-copy"> + cameraserver-643 [003] ...1 94.192991: ion_client_destroy <-ion_release cameraserver-643 [003] ...1 94.192997: <stack trace> => ftrace_ops_no_ops => ftrace_graph_call @@ -220,7 +268,9 @@ so it's time to use the function profiler:</p> => ____fput => task_work_run => do_notify_resume - => work_pending</pre></li> + => work_pending + </pre> +</li> </ol> <p>Based on inspection of the ion driver, we can see that @@ -286,12 +336,21 @@ the lock trace when ftrace was not running.</p> ftrace:</p> <ol> <li>Enable tracing: -<pre>$ echo 1 > /proc/sys/kernel/lock_stat</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +echo 1 > /proc/sys/kernel/lock_stat +</pre> +</li> <li>Run your test.</li> <li>Disable tracing: -<pre>$ echo 0 > /proc/sys/kernel/lock_stat</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +echo 0 > /proc/sys/kernel/lock_stat +</pre> +</li> <li>Dump your trace: -<pre>$ cat /proc/lock_stat > /data/local/tmp/lock_stat</pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +cat /proc/lock_stat > /data/local/tmp/lock_stat +</pre> +</li> </ol> <p>For help interpreting the resulting output, refer to lockstat documentation diff --git a/en/devices/tech/debug/gdb.html b/en/devices/tech/debug/gdb.html new file mode 100644 index 00000000..27c99328 --- /dev/null +++ b/en/devices/tech/debug/gdb.html @@ -0,0 +1,141 @@ +<html devsite> + <head> + <title>Using GDB</title> + <meta name="project_path" value="/_project.yaml" /> + <meta name="book_path" value="/_book.yaml" /> + </head> + <body> + <!-- + Copyright 2017 The Android Open Source Project + + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. + --> + + +<p>The GNU Project debugger (GDB) is a commonly used Unix debugger. This page +details using <code>gdb</code> to debug Android apps and processes.</p> + +<h2 id=running>Debugging running apps or processes</h2> + +<p>To connect to an already-running app or native daemon, use +<code>gdbclient</code> with a PID. For example, to debug the process with PID +1234, run:</p> + +<pre class="devsite-terminal devsite-click-to-copy"> +gdbclient 1234 +</pre> + +<p>The script sets up port forwarding, starts the appropriate +<code>gdbserver</code> on the device, starts the appropriate <code>gdb</code> on +the host, configures <code>gdb</code> to find symbols, and connects +<code>gdb</code> to the remote <code>gdbserver</code>.</p> + +<h2 id=starts>Debugging native process startup</h2> + +<p>To debug a process as it starts, use <code>gdbserver</code> or +<code>gdbserver64</code> (for 64-bit processes). For example:</p> + +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell gdbserver :5039 /system/bin/<var>MY_TEST_APP</var> +</pre> + +<p>Example output:</p> +<pre class="devsite-click-to-copy"> +Process <var>MY_TEST_APP</var> created; pid = 3460 +Listening on port 5039 +</pre> + +<p>Next, identify the application PID from the <code>gdbserver</code> output and +use it in another terminal window:</p> + +<pre class="devsite-terminal devsite-click-to-copy"> +gdbclient <var>APP_PID</var> +</pre> + +<p>Finally, enter <strong>continue</strong> at the <code>gdb</code> prompt.</p> + +<p class="note"><strong>Note:</strong> If you specify the wrong +<code>gdbserver</code>, you'll get an unhelpful error message (such as +"<code>Reply contains invalid hex digit 59</code>").</p> + +<h2 id="app-startup">Debugging app startup</h2> + +<p>Sometimes you want to debug an app as it starts, such as when there's a crash +and you want to step through code to see what happens <em>before</em> the crash. +<a href="#running">Attaching</a> works in some cases, but in other cases is +impossible because the app crashes before you can attach. The +<code>logwrapper</code> approach (used for <code>strace</code> and +<code>valgrind</code>) does not always work because the app might not have +permissions to open a port, and <code>gdbserver</code> inherits that +restriction.</p> + +<p>To debug app startup, use the developer options in Settings to instruct +the app to wait for a Java debugger to attach:</p> + +<ol> +<li>Go to <em>Settings > Developer options > Select debug app</em> and choose +your app from the list, then press <strong>Wait for debugger</strong>.</li> + +<li>Start the app, either from the launcher or by using the command line to run: +<pre class="devsite-terminal devsite-click-to-copy"> +am start -a android.intent.action.MAIN -n <var>APP_NAME</var>/.<var>APP_ACTIVITY</var> +</pre></li> + +<li>Wait for the app to load and a dialog to appear telling you the app is +waiting for a debugger.</li> + +<li>Attach <code>gdbserver</code>/<code>gdbclient</code> normally, set +breakpoints, then continue the process.</li></ol> + +<p>To let the app actually run, attach a Java Debug Wire Protocol (JDWP) +debugger such as Java Debugger (jdb):</p> +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb forward tcp:12345 jdwp:<var>XXX</var> # (Where XXX is the pid of the debugged process.)</code> +<code class="devsite-terminal">jdb -attach localhost:12345</code> +</pre> + +<h2 id=crash>Debugging apps or processes that crash</h2> + +<p>If you want <code>debuggerd</code> to suspend crashed processes so you can +attach <code>gdb</code>, set the appropriate property:</p> + +<pre class="devsite-click-to-copy"> +# Android 7.0 Nougat and later. +<code class="devsite-terminal">adb shell setprop debug.debuggerd.wait_for_gdb true</code> +</pre> + +<pre class="devsite-click-to-copy"> +# Android 6.0 Marshmallow and earlier. +<code class="devsite-terminal">adb shell setprop debug.db.uid 999999</code> +</pre> + +<p>At the end of the usual crash output, <code>debuggerd</code> provides +instructions on how to connect <code>gdb</code> using the command: +<pre class="devsite-terminal devsite-click-to-copy"> +gdbclient <var>PID</var> +</pre> + + +<h2 id=symbols>Debugging without symbols</h2> + +<p>For 32-bit ARM, if you don’t have symbols, <code>gdb</code> can get confused +about the instruction set it is disassembling (ARM or Thumb). To specify the +instruction set chosen as the default when symbol information is missing, set +the following property:</p> + +<pre class="devsite-terminal devsite-click-to-copy"> +set arm fallback-mode arm # or thumb +</pre> + + </body> +</html> diff --git a/en/devices/tech/debug/index.html b/en/devices/tech/debug/index.html index b2f4c140..268f24ee 100644 --- a/en/devices/tech/debug/index.html +++ b/en/devices/tech/debug/index.html @@ -25,11 +25,11 @@ <p>This section summarizes useful tools and related commands for debugging, tracing, and profiling native Android platform code when developing -platform-level features. This page covers use of <code>debuggerd</code>, a -daemon process for collecting error information after applications crash, and -the GNU Project debugger (GDB).</p> +platform-level features.</p> -<p>Other pages in this section explore system services with +<p>This page covers use of <code>debuggerd</code>, a daemon process for +collecting error information after applications crash. Other pages in this +section explore system services with <a href="/devices/tech/debug/dumpsys.html">Dumpsys</a>, viewing <a href="/devices/tech/debug/native-memory.html">native memory</a>, <a href="/devices/tech/debug/netstats.html">network</a>, and @@ -37,8 +37,9 @@ the GNU Project debugger (GDB).</p> <a href="/devices/tech/debug/asan.html">AddressSanitizer</a> to detect memory bugs in native code, evaluating <a href="/devices/tech/debug/eval_perf.html"> performance issues</a> (includes -<a href="/devices/tech/debug/systrace">systrace</a>), and several other -debugging tools.</p> +<a href="/devices/tech/debug/systrace">systrace</a>), and using +<a href="/devices/tech/debug/gdb.html">GNU Project debugger (GDB)</a> and +other debugging tools.</p> <h2 id=debuggerd>Using debuggerd</h2> @@ -57,7 +58,7 @@ opt out of crash reporting.</p> <p>Example <code>debuggerd</code> output (with timestamps and extraneous information removed):</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Build fingerprint: 'Android/aosp_angler/angler:7.1.1/NYC/enh12211018:eng/test-keys' Revision: '0' @@ -95,8 +96,12 @@ unwind with line number information by pasting the above example into <code>stack</code> will be on your $PATH already so you don't need to give the full path.</p> -<pre> -$ development/tools/stack +<pre class="devsite-terminal devsite-click-to-copy"> +development/tools/stack +</pre> + +<p>Example output:</p> +<pre class="devsite-click-to-copy"> Reading native crash info from stdin 03-02 23:53:49.477 17951 17951 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 03-02 23:53:49.477 17951 17951 F DEBUG : Build fingerprint: 'Android/aosp_angler/angler:7.1.1/NYC/enh12211018:eng/test-keys' @@ -146,93 +151,20 @@ directly from <code>debuggerd</code> without taking up anywhere near as much space as an unstripped version.</p> <p>You can also <code>stack</code> an entire tombstone. Example:</p> -<pre> -$ stack < FS/data/tombstones/tombstone_05 +<pre class="devsite-terminal devsite-click-to-copy"> +stack < FS/data/tombstones/tombstone_05</code> </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 <a href="/devices/tech/debug/native-crash.html">Diagnosing Native Crashes</a>. </p> -<h3>Getting a stack trace/tombstone from a running process</h3> +<h2 id="tombstone">Getting a stack trace/tombstone from a running process</h2> <p>You can also use <code>debuggerd</code> on a running process. From the command line, invoke <code>debuggerd</code> using a process ID (PID) to dump the full tombstone to <code>stdout</code>. To get just the stack for every thread in -the process, include the <code>-b</code> or <code>--backtrace</code> flag. - -<h2 id=native>Using GDB</h2> - -<p>The GNU Project debugger (GDB) is a commonly used Unix debugger.</p> - -<h3 id=running>Debugging a running app</h3> - -<p>To connect to an already-running app or native daemon, use -<code>gdbclient</code> with a PID. For example, to debug the process with PID -1234, run:</p> - -<pre class="no-pretty-print"> -$ gdbclient 1234 -</pre> - -<p>The script sets up port forwarding, starts the appropriate -<code>gdbserver</code> on the device, starts the appropriate <code>gdb</code> on -the host, configures <code>gdb</code> to find symbols, and connects -<code>gdb</code> to the remote <code>gdbserver</code>.</p> - -<h3 id=starts>Debugging a native process as it starts</h3> - -<p>To debug a process as it starts, use <code>gdbserver</code> or -<code>gdbserver64</code> (for 64-bit processes). For example:</p> - -<pre class="no-pretty-print"> -$ adb shell gdbserver :5039 /system/bin/<em>my_test_app</em> -Process my_test_app created; pid = 3460 -Listening on port 5039 -</pre> - -<p>Next, identify the application PID from the <code>gdbserver</code> output and -use it in another terminal window:</p> - -<pre class="no-pretty-print"> -$ gdbclient <em><app pid></em> -</pre> - -<p>Finally, enter <strong>continue</strong> at the <code>gdb</code> prompt.</p> - -<p class="note"><strong>Note:</strong> If you use the wrong -<code>gdbserver</code>, you'll get an unhelpful error message (such as -"<code>Reply contains invalid hex digit 59</code>").</p> - -<h3 id=crash>Debugging processes that crash</h3> - -<p>If you want <code>debuggerd</code> to suspend crashed processes so you can -attach <code>gdb</code>, set the appropriate property:</p> - -<pre class="no-pretty-print"> -# Android 7.0 Nougat and later. -$ adb shell setprop debug.debuggerd.wait_for_gdb true - -# Android 6.0 Marshmallow and earlier. -$ adb shell setprop debug.db.uid 999999 -</pre> - -<p>At the end of the usual crash output, <code>debuggerd</code> provides -instructions on how to connect <code>gdb</code> using the command: -<pre class="no-pretty-print"> -$ gdbclient <pid> -</pre> - -<h3 id=symbols>Debugging without symbols</h3> - -<p>For 32-bit ARM, if you don’t have symbols, <code>gdb</code> can get confused -about the instruction set it is disassembling (ARM or Thumb). To specify the -instruction set chosen as the default when symbol information is missing, set -the following property:</p> - -<pre class="no-pretty-print"> -$ set arm fallback-mode arm # or thumb -</pre> +the process, include the <code>-b</code> or <code>--backtrace</code> flag.</p> </body> </html> diff --git a/en/devices/tech/debug/native-crash.html b/en/devices/tech/debug/native-crash.html index fec60690..c1658cc5 100644 --- a/en/devices/tech/debug/native-crash.html +++ b/en/devices/tech/debug/native-crash.html @@ -59,7 +59,7 @@ Older versions of Android (especially on 32-bit ARM) followed a convoluted path between the original abort call (frame 4 here) and the actual sending of the signal (frame 0 here): </p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> pid: 1656, tid: 1656, name: crasher >>> crasher <<< signal 6 (<i style="color:Orange">SIGABRT</i>), code -6 (SI_TKILL), fault addr -------- <i style="color:Orange">Abort message</i>: 'some_file.c:123: some_function: assertion "false" failed' @@ -85,7 +85,8 @@ href="http://man7.org/linux/man-pages/man2/tgkill.2.html">tgkill(2)</a></code> directly from <code>abort</code>, so there are fewer stack frames for you to skip over before you get to the interesting frames: -<pre class="no-pretty-print">pid: 25301, tid: 25301, name: crasher >>> crasher <<< +<pre class="devsite-click-to-copy"> +pid: 25301, tid: 25301, name: crasher >>> crasher <<< signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr -------- r0 00000000 r1 000062d5 r2 00000006 r3 00000008 r4 ffa09dd8 r5 000062d5 r6 000062d5 r7 0000010c @@ -119,7 +120,8 @@ was called with a null pointer; and this crash should go straight to the author of the calling code. In this case, frame #01 is the bad caller. </p> -<pre class="no-pretty-print">pid: 25326, tid: 25326, name: crasher >>> crasher <<< +<pre class="devsite-click-to-copy"> +pid: 25326, tid: 25326, name: crasher >>> crasher <<< signal 11 (<i style="color:Orange">SIGSEGV</i>), code 1 (SEGV_MAPERR), <i style="color:Orange">fault addr 0x0</i> r0 00000000 r1 00000000 r2 00004c00 r3 00000000 r4 ab088071 r5 fff92b34 r6 00000002 r7 fff92b40 @@ -157,7 +159,9 @@ call actually succeeded first. <p> Here's an example of <code>readdir</code>: </p> -<pre class="no-pretty-print">pid: 25405, tid: 25405, name: crasher >>> crasher <<< + +<pre class="devsite-click-to-copy"> +pid: 25405, tid: 25405, name: crasher >>> crasher <<< signal 11 (<i style="color:Orange">SIGSEGV</i>), code 1 (SEGV_MAPERR), <i style="color:Orange">fault addr 0xc</i> r0 0000000c r1 00000000 r2 00000000 r3 3d5f0000 r4 00000000 r5 0000000c r6 00000002 r7 ff8618f0 @@ -190,7 +194,7 @@ you found the bug: <code>readdir</code> was passed a null pointer by the caller. At this point you can paste the stack into the stack tool to find out <em>where</em> in logcat this happened. -<pre class="no-pretty-print"> +<pre class="prettyprint"> struct DIR { int fd_; size_t available_bytes_; @@ -220,7 +224,8 @@ to perform actually fits. Here's an example where the code tries to <code>read(fd, buf, 32)</code> into a buffer that's actually only 10 bytes long... </p> -<pre class="no-pretty-print">pid: 25579, tid: 25579, name: crasher >>> crasher <<< +<pre class="devsite-click-to-copy"> +pid: 25579, tid: 25579, name: crasher >>> crasher <<< signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr -------- Abort message: '<i style="color:Orange">FORTIFY: read: prevented 32-byte write into 10-byte buffer'</i> r0 00000000 r1 000063eb r2 00000006 r3 00000008 @@ -254,7 +259,8 @@ epilogue to read it back and check that it's not changed. If that value changed, it was overwritten by a buffer overrun, so the epilogue calls <code>__stack_chk_fail</code> to log a message and abort. </p> -<pre class="no-pretty-print">pid: 26717, tid: 26717, name: crasher >>> crasher <<< +<pre class="devsite-click-to-copy"> +pid: 26717, tid: 26717, name: crasher >>> crasher <<< signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr -------- <i style="color:Orange">Abort message: 'stack corruption detected'</i> r0 00000000 r1 0000685d r2 00000006 r3 00000008 @@ -294,7 +300,7 @@ to see the currently supported selection.</p> <p>To introduce the different pieces in a crash dump, let's work through this example crash dump:</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Build fingerprint: 'Android/aosp_flounder/flounder:5.1.51/AOSP/enh08201009:eng/test-keys' Revision: '0' @@ -318,15 +324,14 @@ backtrace: #08 pc 00016795 /system/lib/libc.so (__libc_init+44) #09 pc 00000abc /system/xbin/crasher Tombstone written to: /data/tombstones/tombstone_06 +*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** </pre> -<pre class="no-pretty-print">*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***</pre> - <p>The line of asterisks with spaces is helpful if you're searching a log for native crashes. The string "*** ***" rarely shows up in logs other than at the beginning of a native crash.</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> Build fingerprint: 'Android/aosp_flounder/flounder:5.1.51/AOSP/enh08201009:eng/test-keys' </pre> @@ -334,7 +339,7 @@ Build fingerprint: <p>The fingerprint lets you identify exactly which build the crash occurred on. This is exactly the same as the <code>ro.build.fingerprint</code> system property.</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> Revision: '0' </pre> @@ -343,7 +348,7 @@ usually unused but can be useful to help you automatically ignore bugs known to be caused by bad hardware. This is exactly the same as the <code>ro.revision</code> system property.</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> ABI: 'arm' </pre> @@ -351,7 +356,7 @@ ABI: 'arm' mostly useful for the <code>stack</code> script mentioned above, so that it knows what toolchain to use.</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> pid: 1656, tid: 1656, name: crasher >>> crasher <<< </pre> @@ -364,7 +369,7 @@ which is useful when filing bugs or trying to find the app in Google Play. The pid and tid can also be useful in finding the relevant log lines preceding the crash.</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr -------- </pre> @@ -373,7 +378,7 @@ how it was received (SI_TKILL). The signals reported by <code>debuggerd</code> a SIGBUS, SIGFPE, SIGILL, SIGSEGV, and SIGTRAP. The signal-specific codes vary based on the specific signal.</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> Abort message: 'some_file.c:123: some_function: assertion "false" failed' </pre> @@ -382,7 +387,7 @@ is automatically gathered from the last line of fatal logcat output for this pid/tid, and in the case of a deliberate abort is likely to give an explanation of why the program killed itself.</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> r0 00000000 r1 00000678 r2 00000006 r3 f70b6dc8 r4 f70b6dd0 r5 f70b6d80 r6 00000002 r7 0000010c r8 ffffffed r9 00000000 sl 00000000 fp ff96ae1c @@ -393,7 +398,7 @@ ip 00000006 sp ff96ad18 lr f700ced5 pc f700dc98 cpsr 400b0010 signal was received. (This section varies wildly between ABIs.) How useful these are will depend on the exact crash.<p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> backtrace: #00 pc 00042c98 /system/lib/libc.so (tgkill+12) #01 pc 00041ed1 /system/lib/libc.so (pthread_kill+32) @@ -419,7 +424,7 @@ to find the corresponding assembler instruction.</p> <h2 id=tombstones>Tombstones</h2> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> Tombstone written to: /data/tombstones/tombstone_06 </pre> @@ -434,7 +439,7 @@ and memory dumps around the addresses in registers. Most usefully it also includes a full memory map (similar to <code>/proc/<i>pid</i>/maps</code>). Here's an annotated example from a 32-bit ARM process crash:</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> memory map: (fault address prefixed with --->) --->ab15f000-ab162fff r-x 0 4000 /system/xbin/crasher (BuildId: b9527db01b5cf8f5402f899f64b9b121) @@ -461,7 +466,7 @@ exactly which version of your code crashed. (Platform binaries include a BuildId by default since Android M. NDK r12 and later automatically pass <code>-Wl,--build-id</code> to the linker too.)<p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> ab163000-ab163fff r-- 3000 1000 /system/xbin/crasher ab164000-ab164fff rw- 0 1000 f6c80000-f6d7ffff rw- 0 100000 [anon:libc_malloc] @@ -470,7 +475,7 @@ f6c80000-f6d7ffff rw- 0 100000 [anon:libc_malloc] <p>On Android the heap isn't necessarily a single region. Heap regions will be labeled <code>[anon:libc_malloc]</code>.</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> f6d82000-f6da1fff r-- 0 20000 /dev/__properties__/u:object_r:logd_prop:s0 f6da2000-f6dc1fff r-- 0 20000 /dev/__properties__/u:object_r:default_prop:s0 f6dc2000-f6de1fff r-- 0 20000 /dev/__properties__/u:object_r:logd_prop:s0 @@ -504,7 +509,7 @@ shows the address ranges for the mapping, the second column the permissions (in hex), the fourth column the size of the region (in hex), and the fifth column the file (or other region name).</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> f6f34000-f6f53fff r-x 0 20000 /system/lib/libm.so (BuildId: 76ba45dcd9247e60227200976a02c69b) f6f54000-f6f54fff --- 0 1000 f6f55000-f6f55fff r-- 20000 1000 /system/lib/libm.so @@ -537,7 +542,7 @@ Note that since Android 5.0 (Lollipop), the C library names most of its anonymou regions so there are fewer mystery regions. </p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> f6fcb000-f6fccfff rw- 0 2000 [stack:5081] </pre> @@ -545,7 +550,7 @@ f6fcb000-f6fccfff rw- 0 2000 [stack:5081] Regions named <code>[stack:<i>tid</i>]</code> are the stacks for the given threads. </p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> f6fcd000-f702afff r-x 0 5e000 /system/bin/linker (BuildId: 84f1316198deee0591c8ac7f158f28b7) f702b000-f702cfff r-- 5d000 2000 /system/bin/linker f702d000-f702dfff rw- 5f000 1000 /system/bin/linker diff --git a/en/devices/tech/debug/netstats.html b/en/devices/tech/debug/netstats.html index a396700d..78ddef02 100644 --- a/en/devices/tech/debug/netstats.html +++ b/en/devices/tech/debug/netstats.html @@ -31,8 +31,8 @@ network usage statistics collected since the device booted up.</p> <p>To view network usage statistics, run the following command:</p> -<pre class=prettyprint> -$ adb shell dumpsys netstats detail +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell dumpsys netstats detail </pre> @@ -56,7 +56,7 @@ consists of several sections: </p> <p>Here is sample output for the active interfaces and active UID interfaces sections:</p> -<pre> +<pre class="devsite-click-to-copy"> Active interfaces: iface=wlan0 ident=[{type=WIFI, subType=COMBINED, networkId="GoogleGuest"}] Active UID interfaces: @@ -72,7 +72,7 @@ information in these two section is the same.</p> <p>Here is sample output for the Dev statistics section:</p> -<pre> +<pre class="devsite-click-to-copy"> Dev stats: Pending bytes: 170775 Complete history: @@ -94,7 +94,7 @@ Dev stats: <h3 id=uid_stats>UID stats</h3> -<pre> +<pre class="devsite-click-to-copy"> UID stats: Pending bytes: 744 Complete history: @@ -120,9 +120,11 @@ Then look for the line labeled <code>userId</code>.</p> <p>In our example, suppose we are trying to find network usage for our app “com.example.myapp”. We would run the following command:</p> -<pre> -$ adb shell dumpsys package com.example.myapp | grep userId - +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell dumpsys package com.example.myapp | grep userId +</pre> +<p>This returns the following output:</p> +<pre class="devsite-click-to-copy"> userId=10007 gids=[3003, 1028, 1015] </pre> diff --git a/en/devices/tech/debug/procstats.html b/en/devices/tech/debug/procstats.html index 07250168..285ea7e0 100644 --- a/en/devices/tech/debug/procstats.html +++ b/en/devices/tech/debug/procstats.html @@ -33,8 +33,8 @@ proportional set size (PSS) and unique set size (USS).</p> <p>To get application memory usage stats for the last three hours, in human-readable form, run the following command:</p> -<pre class=prettyprint> -$ adb shell dumpsys procstats --hours 3 +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell dumpsys procstats --hours 3 </pre> @@ -46,7 +46,7 @@ $ adb shell dumpsys procstats --hours 3 time the application was running, while the numbers following show PSS and USS as minPSS-avgPSS-maxPSS/minUSS-avgUSS-maxUSS over samples.</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> AGGREGATED OVER LAST 3 HOURS: * com.android.systemui / u0a20 / v22: TOTAL: 100% (109MB-126MB-159MB/108MB-125MB-157MB over 18) diff --git a/en/devices/tech/debug/strace.html b/en/devices/tech/debug/strace.html index a69a64b4..5f2affb2 100644 --- a/en/devices/tech/debug/strace.html +++ b/en/devices/tech/debug/strace.html @@ -30,16 +30,16 @@ to learn how to collect only data you're actually interested in.</p> <h2 id=build-strace>Building strace</h2> <p>To build strace, run the following: -<pre> -$ mmma -j6 external/strace +<pre class="devsite-terminal devsite-click-to-copy"> +mmma -j6 external/strace </pre> <h2 id=attach-strace>Attaching to a running process</h2> <p>The simplest and most common use case for strace is to attach it to a running process, which you can do with:</p> -<pre> -$ adb shell strace -f -p PID +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell strace -f -p PID </pre> <p>The <code>-f</code> flag tells strace to attach to all the threads in the process, plus any new threads spawned later.</p> @@ -49,16 +49,16 @@ process, plus any new threads spawned later.</p> <ol> <li>Set up a directory for strace logs: -<pre> -$ adb shell setenforce 0 -$ adb shell mkdir /data/local/tmp/strace -$ adb shell chmod 777 /data/local/tmp/strace +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb shell setenforce 0</code> +<code class="devsite-terminal">adb shell mkdir /data/local/tmp/strace</code> +<code class="devsite-terminal">adb shell chmod 777 /data/local/tmp/strace</code> </pre> </li> <li>Choose the process to trace before launching it: -<pre> -$ adb shell setprop wrap.com.google.android.browser "logwrapper strace -f -o /data/local/tmp/strace/strace.com.google.android.browser.txt" +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell setprop wrap.com.google.android.browser "logwrapper strace -f -o /data/local/tmp/strace/strace.com.google.android.browser.txt" </pre> </li> <li>Launch the process normally.</li> @@ -69,9 +69,9 @@ $ adb shell setprop wrap.com.google.android.browser "logwrapper strace -f -o /da line (requires <code>adb shell setenforce 0</code>): </p> -<pre> -$ cd system/core/ -$ patch -p1 <<EOF +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">cd system/core/</code> +<code class="devsite-terminal">patch -p1 <<EOF --- a/rootdir/init.zygote32.rc +++ b/rootdir/init.zygote32.rc @@ -1,4 +1,4 @@ @@ -80,7 +80,7 @@ $ patch -p1 <<EOF class main socket zygote stream 660 root system onrestart write /sys/android_power/request_state wake -EOF +EOF</code> </pre> <h2 id=get-logs-boot>Getting strace logs during Android boot</h2> @@ -93,7 +93,7 @@ EOF SELinux <code>file_context</code> for <code>strace</code>. The solution is to add a new line for strace in <code>system/sepolicy/private/file_contexts</code> and copy the original file context over. Example: -<pre> +<pre class="devsite-click-to-copy"> /dev/socket/zygote u:object_r:zygote_socket:s0 + /system/xbin/strace u:object_r:zygote_socket:s0 </pre> @@ -108,7 +108,7 @@ do this by adding <code>androidboot.selinux=permissive</code>to <br> <br>Example for the Pixel (sailfish) device in <code>/device/google/marlin/sailfish/BoardConfig.mk</code>: -<pre> +<pre class="devsite-click-to-copy"> - BOARD_KERNEL_CMDLINE := .... androidboot.hardware=sailfish ... +BOARD_KERNEL_CMDLINE := .... androidboot.hardware=sailfish ... androidboot.selinux=permissive </pre> diff --git a/en/devices/tech/debug/systrace.html b/en/devices/tech/debug/systrace.html index 4334f9d9..036bd6da 100644 --- a/en/devices/tech/debug/systrace.html +++ b/en/devices/tech/debug/systrace.html @@ -49,7 +49,9 @@ problems. (These features require root access and often a new kernel.)</p> <p>When debugging jitter on Pixel/Pixel XL, start with the following command:</p> -<pre>$ ./systrace.py sched freq idle am wm gfx view sync binder_driver irq workq input -b 96000</pre> +<pre class="devsite-terminal devsite-click-to-copy"> +./systrace.py sched freq idle am wm gfx view sync binder_driver irq workq input -b 96000 +</pre> <p>When combined with the additional tracepoints required for GPU and display pipeline activity, this gives you the ability to trace from user input to frame @@ -106,7 +108,7 @@ back to sleep, waiting for EventThread wakeup.</li> <p>Let's walk through the frame beginning at 15409ms:</p> -<p><img src="images/perf_trace_normal_pipeline.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_normal_pipeline.png"></p> <p class="img-caption"><strong>Figure 1.</strong> Normal UI pipeline, EventThread running.</p> @@ -139,14 +141,14 @@ sleep slice.</p> <p>While EventThread is running, the UI thread for TouchLatency becomes runnable. To see what woke it, click the blue section:</p> -<p><img src="images/perf_trace_tl.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_tl.png"></p> <p class="img-caption"><strong>Figure 2.</strong> UI thread for TouchLatency.</p> <p>Figure 2 shows the TouchLatency UI thread was woken by tid 6843, which corresponds to EventThread. The UI thread wakes:</p> -<p><img src="images/perf_trace_wake_render_enqueue.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_wake_render_enqueue.png"></p> <p class="img-caption"><strong>Figure 3.</strong> UI thread wakes, renders a frame, and enqueues it for SurfaceFlinger to consume.</p> @@ -154,7 +156,7 @@ frame, and enqueues it for SurfaceFlinger to consume.</p> binder transaction to view information on all of the processes involved in that transaction:</p> -<p><img src="images/perf_trace_binder_trans.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_binder_trans.png"></p> <p class="img-caption"><strong>Figure 4.</strong> Binder transaction.</p> <p>Figure 4 shows that, at 15,423.65ms, Binder:6832_1 in SurfaceFlinger becomes @@ -164,7 +166,7 @@ see queueBuffer on both sides of the binder transaction.</p> <p>During the queueBuffer on the SurfaceFlinger side, the number of pending frames from TouchLatency goes from 1 to 2:</p> -<p><img src="images/perf_trace_pending_frames.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_pending_frames.png"></p> <p class="img-caption"><strong>Figure 5.</strong> Pending frames goes from 1 to 2.</p> @@ -176,14 +178,14 @@ further dropped frames.</p> <p>Soon after, SurfaceFlinger's main thread is woken by a second EventThread so it can output the older pending frame to the display:</p> -<p><img src="images/perf_trace_sf_woken_et.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_sf_woken_et.png"></p> <p class="img-caption"><strong>Figure 6.</strong> SurfaceFlinger's main thread is woken by a second EventThread.</p> <p>SurfaceFlinger first latches the older pending buffer, which causes the pending buffer count to decrease from 2 to 1:</p> -<p><img src="images/perf_trace_sf_latches_pend.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_sf_latches_pend.png"></p> <p class="img-caption"><strong>Figure 7.</strong> SurfaceFlinger first latches the older pending buffer.</p> @@ -191,7 +193,7 @@ the older pending buffer.</p> final frame to the display. (Some of these sections are enabled as part of the <code>mdss</code> tracepoint, so they may not be there on your SOC.)</p> -<p><img src="images/perf_trace_sf_comp_submit.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_sf_comp_submit.png"></p> <p class="img-caption"><strong>Figure 8.</strong> SurfaceFlinger sets up composition and submits the final frame.</p> @@ -200,7 +202,7 @@ display pipeline's kernel thread for outputting a rendered frame to the display. We can see <code>mdss_fb0</code> as its own row in the trace (scroll down to view).</p> -<p><img src="images/perf_trace_wake_cpu0.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_wake_cpu0.png"></p> <p class="img-caption"><strong>Figure 9.</strong> <code>mdss_fb0</code> wakes on CPU 0.</p> @@ -215,14 +217,14 @@ the Pixel XL might not be useful to you).</p> <h2 id="example_2">Example: Non-working frame</h2> <p>This example describes a systrace used to debug Pixel/Pixel XL jitter. To -follow along with the example, <a href="perf_traces.zip">download the zip +follow along with the example, <a href="/devices/tech/debug/perf_traces.zip">download the zip file</a> of traces (which also includes other traces referred to in this section), upzip the file, and open the systrace_tutorial.html file in your browser.</p> <p>When you first open the systrace, you'll see something like this:</p> -<p><img src="images/perf_trace_tl_pxl.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_tl_pxl.png"></p> <p class="img-caption"><strong>Figure 10</strong>. TouchLatency running on Pixel XL (most options enabled, including mdss and kgsl tracepoints).</p> @@ -234,7 +236,7 @@ case, FrameMissed is correlated with SurfaceFlinger missing one of its extremely-regular runtimes and an unchanged pending-buffer count for the app (<code>com.prefabulated.touchlatency</code>) at a vsync:</p> -<p><img src="images/perf_trace_fm_sf.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_fm_sf.png"></p> <p class="img-caption"><strong>Figure 11</strong>. FrameMissed correlation with SurfaceFlinger.</p> @@ -250,7 +252,7 @@ SurfaceFlinger wakes and immediately goes to sleep. When viewing the number of pending frames from TouchLatency, there are two frames (a good clue to help figure out what's going on).</p> -<p><img src="images/perf_trace_sf_wake_sleep.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_sf_wake_sleep.png"></p> <p class="img-caption"><strong>Figure 12.</strong> SurfaceFlinger wakes and immediately goes to sleep.</p> @@ -269,7 +271,7 @@ particular events in SurfaceFlinger depends on your SOC and driver stack, so work with your SOC vendor to understand the meaning of fence categories in your traces.</p> -<p><img src="images/perf_traces_fences.png"></p> +<p><img src="/devices/tech/debug/images/perf_traces_fences.png"></p> <p class="img-caption"><strong>Figure 13.</strong> <code>mdss_fb0_retire</code> fences.</p> @@ -277,7 +279,7 @@ fences.</p> Halfway through that slice, that frame should have been replaced by a new one but wasn't. View the previous frame and look for anything interesting:</p> -<p><img src="images/perf_trace_frame_previous.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_frame_previous.png"></p> <p class="img-caption"><strong>Figure 14.</strong> Frame previous to busted frame.</p> @@ -288,7 +290,7 @@ suggests that something is very wrong with the display pipe.</p> <p>Investigate exactly where that fence ends to determine what controls it:</p> -<p><img src="images/perf_trace_fence_end.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_fence_end.png"></p> <p class="img-caption"><strong>Figure 15.</strong> Investigate fence end.</p> <p>A workqueue contains a <code>__vsync_retire_work_handler</code> that is @@ -301,7 +303,7 @@ might not get scheduled accurately.</p> <p>Check the previous frame to determine if that contributed; sometimes jitter can add up over time and eventually cause us to miss a deadline.</p> -<p><img src="images/perf_trace_previous_frame.png"></p> +<p><img src="/devices/tech/debug/images/perf_trace_previous_frame.png"></p> <p class="img-caption"><strong>Figure 16.</strong> Previous frame.</p> <p>The runnable line on the kworker isn't visible because the viewer turns it diff --git a/en/devices/tech/debug/valgrind.html b/en/devices/tech/debug/valgrind.html index d8f1e42b..9ae0f088 100644 --- a/en/devices/tech/debug/valgrind.html +++ b/en/devices/tech/debug/valgrind.html @@ -31,16 +31,16 @@ debugging, most Android platform developers use <h2 id=build-valgrind>Building Valgrind</h2> <p>To build Valgrind:</p> -<pre class="no-pretty-print"> -$ mmma -j6 external/valgrind +<pre class="devsite-terminal devsite-click-to-copy"> +mmma -j6 external/valgrind </pre> <h2 id=app-valgrind>Using on an application</h2> <p>To use Valgrind on an application:</p> -<pre class="no-pretty-print"> -$ adb shell setprop wrap.<em>app_name</em> "logwrapper valgrind" -$ adb shell am start -a android.intent.action.MAIN -n <em>app_name</em>/.MainActivity +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb shell setprop wrap.<em>app_name</em> "logwrapper valgrind"</code> +<code class="devsite-terminal">adb shell am start -a android.intent.action.MAIN -n <em>app_name</em>/.MainActivity</code> </pre> <code><em>app_name</em></code> must be a fully-qualified name such as @@ -49,25 +49,25 @@ $ adb shell am start -a android.intent.action.MAIN -n <em>app_name</em>/.MainAct <h2 id=server-valgrind>Using on the system server</h2> <p>To run the system server with Valgrind:</p> -<pre class="no-pretty-print"> -$ adb shell setprop wrap.system_server "logwrapper valgrind" -$ adb shell stop && adb shell start +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb shell setprop wrap.system_server "logwrapper valgrind"</code> +<code class="devsite-terminal">adb shell stop && adb shell start</code> </pre> <h2 id=symbols-valgrind>Getting debug symbols</h2> <p>For debug symbols, push unstripped libraries to <code>/data/local/symbols</code>:</p> -<pre class="no-pretty-print"> -$ adb shell mkdir /data/local/symbols -$ adb push $OUT/symbols /data/local/symbols +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb shell mkdir /data/local/symbols</code> +<code class="devsite-terminal">adb push $OUT/symbols /data/local/symbols</code> </pre> <h2 id=boot-valgrind>Using during boot up</h2> <p>To use Valgrind during boot up, edit <code>out/target/product/XXXX/root/init.rc</code> by changing</p> -<p><code>service example /system/bin/foo --arg1 --arg2</code></p> +<pre class="devsite-click-to-copy">service example /system/bin/foo --arg1 --arg2</pre> <p>to:</p> -<p><code>service example /system/bin/logwrapper /system/bin/valgrind /system/bin/foo --arg1 --arg2</code></p> +<pre class="devsite-click-to-copy">>service example /system/bin/logwrapper /system/bin/valgrind /system/bin/foo --arg1 --arg2</pre> <p>To see the effects, create a <code>boot.img</code> and reflash the device.</p> diff --git a/en/devices/tech/display/app-shortcuts.html b/en/devices/tech/display/app-shortcuts.html index 7db7bd29..fdabeb86 100644 --- a/en/devices/tech/display/app-shortcuts.html +++ b/en/devices/tech/display/app-shortcuts.html @@ -52,7 +52,8 @@ shortcuts include: You can find the primary implementation of this feature in the following files: </p> -<pre>frameworks/base/services/core/java/com/android/server/policy/ShortcutManager.java +<pre class="devsite-click-to-copy"> +frameworks/base/services/core/java/com/android/server/policy/ShortcutManager.java frameworks/base/services/core/java/com/android/server/pm/ShortcutPackage.java frameworks/base/services/core/java/com/android/server/pm/ShortcutUser.java frameworks/base/services/core/java/com/android/server/pm/ShortcutPackageInfo.java @@ -73,7 +74,7 @@ With the following files providing supporting features (called hidden APIs in <code>ShortcutManager.java</code>): </p> -<pre> +<pre class="devsite-click-to-copy"> packages/apps/Settings/src/com/android/settings/DevelopmentSettings.java frameworks/base/packages/SystemUI/src/com/android/systemui/statusbar/policy/RemoteInputView.java </pre> @@ -83,7 +84,7 @@ And, for an example, the Android Open Source Project Launcher version 3 supports shortcuts: </p> -<pre> +<pre class="devsite-click-to-copy"> packages/apps/Launcher3/ </pre> @@ -91,7 +92,8 @@ packages/apps/Launcher3/ Finally, see the following files for public Javadoc. </p> -<pre>frameworks/base/core/java/android/content/pm/ShortcutManager.java +<pre class="devsite-click-to-copy"> +frameworks/base/core/java/android/content/pm/ShortcutManager.java frameworks/base/core/java/android/content/pm/ShortcutInfo.java frameworks/base/core/java/android/content/pm/LauncherApps.java </pre> @@ -138,7 +140,7 @@ Use the following Android Compatibility Test Suite (CTS) tests to ensure your version of the feature (ShortcutManager and LauncherApps) works as intended: </p> -<pre> +<pre class="devsite-click-to-copy"> cts/tests/tests/shortcutmanager/ cts/hostsidetests/shortcuts/ </pre> @@ -147,20 +149,22 @@ cts/hostsidetests/shortcuts/ And find the unit tests for the AOSP implementation here: </p> -<pre>frameworks/base/services/tests/servicestests/ +<pre class="devsite-click-to-copy"> +frameworks/base/services/tests/servicestests/ </pre> <p> Which includes: </p> -<pre>src/com/android/server/pm/ShortcutManagerTest*.java +<pre class="devsite-click-to-copy"> +src/com/android/server/pm/ShortcutManagerTest*.java </pre> <p> You may also employ the CTS Verifier test for shortcut manager: </p> -<pre> +<pre class="devsite-click-to-copy"> cts/apps/CtsVerifier/src/com/android/cts/verifier/notifications/ShortcutThrottlingResetActivity.java </pre> diff --git a/en/devices/tech/display/circular-icons.html b/en/devices/tech/display/circular-icons.html index 65f79769..eed152a9 100644 --- a/en/devices/tech/display/circular-icons.html +++ b/en/devices/tech/display/circular-icons.html @@ -38,7 +38,7 @@ href="https://android.googlesource.com/platform/frameworks/base/+/master/core/re <p>To enable circular icons, change the <code>config_useRoundIcon</code> setting in your overlay file from <code>false</code> to <code>true</code>:</p> -<pre> +<pre class="devsite-click-to-copy"> <!-- Flag indicating whether round icons should be parsed from the application manifest. --> <bool name="config_useRoundIcon">true</bool> </pre> diff --git a/en/devices/tech/display/hdr.html b/en/devices/tech/display/hdr.html index 6331114e..f85ff1da 100644 --- a/en/devices/tech/display/hdr.html +++ b/en/devices/tech/display/hdr.html @@ -174,13 +174,13 @@ new HDR capable profiles:</p> <h4>Dolby-Vision</h4> -<p><code>MediaFormat</code> mime constant: -<blockquote><pre> +<p><code>MediaFormat</code> mime constant:</p> +<pre class="devsite-click-to-copy"> String MIMETYPE_VIDEO_DOLBY_VISION -</pre></blockquote></p> +</pre> <p><code>MediaCodecInfo.CodecProfileLevel</code> profile constants:</p> -<blockquote><pre> +<pre class="devsite-click-to-copy"> int DolbyVisionProfileDvavPen int DolbyVisionProfileDvavPer int DolbyVisionProfileDvheDen @@ -189,7 +189,7 @@ int DolbyVisionProfileDvheDtb int DolbyVisionProfileDvheDth int DolbyVisionProfileDvheDtr int DolbyVisionProfileDvheStn -</pre></blockquote> +</pre> <p>Dolby Vision video layers and metadata must be concatenated into a single buffer per frames by video applications. This is done automatically by the @@ -197,19 +197,19 @@ Dolby-Vision capable MediaExtractor.</p> <h4>HEVC HDR 10</h4> -<p><code>MediaCodecInfo.CodecProfileLevel</code> profile constants:<p> -<blockquote><pre> +<p><code>MediaCodecInfo.CodecProfileLevel</code> profile constants:</p> +<pre class="devsite-click-to-copy"> int HEVCProfileMain10HDR10 -</pre></blockquote> +</pre> <h4>VP9 HLG & PQ</h4> <p><code>MediaCodecInfo.CodecProfileLevel</code> profile constants:</p> -<blockquote><pre> +<pre class="devsite-click-to-copy"> int VP9Profile2HDR int VP9Profile3HDR -</pre></blockquote> +</pre> <p>If a platform supports an HDR-capable decoder, it shall also support an HDR-capable extractor.</p> @@ -553,7 +553,7 @@ MediaExtractor => MediaCodec pipeline.</p> <h3 id="hdr10decoder">HDR10 decoder pipeline</h3> -<p><img src="../images/hdr10_decoder_pipeline.png"></p> +<p><img src="/devices/tech/images/hdr10_decoder_pipeline.png"></p> <p class="img-caption"><strong>Figure 1.</strong> HDR10 pipeline</p> @@ -588,7 +588,7 @@ the surface later.</li> <h3 id="dvdecoder">Dolby Vision decoder pipeline</h3> -<p><img src="../images/dolby_vision_decoder_pipleline.png"></p> +<p><img src="/devices/tech/images/dolby_vision_decoder_pipleline.png"></p> <p class="img-caption"><strong>Figure 2.</strong> Dolby Vision pipeline</p> @@ -658,7 +658,7 @@ pass this to the display.</li> <h3 id="v9decoder">VP9 decoder pipeline</h3> -<p><img src="../images/vp9-pq_decoder_pipleline.png"></p> +<p><img src="/devices/tech/images/vp9-pq_decoder_pipleline.png"></p> <p class="img-caption"><strong>Figure 3.</strong> VP9-PQ pipeline</p> diff --git a/en/devices/tech/display/multi-window.html b/en/devices/tech/display/multi-window.html index 8d0ecbed..dbb8df30 100644 --- a/en/devices/tech/display/multi-window.html +++ b/en/devices/tech/display/multi-window.html @@ -81,7 +81,7 @@ and set <code>config_freeformWindowManagement</code> to true in <a href="https://android.googlesource.com/platform/frameworks/base/+/master/core/res/res/values/config.xml">config.xml</a>. </p> -<pre> +<pre class="devsite-click-to-copy"> <bool name="config_freeformWindowManagement">true</bool> </pre> diff --git a/en/devices/tech/display/night-light.html b/en/devices/tech/display/night-light.html index 22b34519..8c6609ff 100644 --- a/en/devices/tech/display/night-light.html +++ b/en/devices/tech/display/night-light.html @@ -43,7 +43,8 @@ using the following flags defined in: <code><a href="https://android.googlesource.com/platform/frameworks/base/+/master/core/res/res/values/config.xml"> /android/frameworks/base/core/res/res/values/config.xml</a></code> -<pre><!-- Control whether Night display is available. This should only be enabled +<pre class="devsite-click-to-copy"> +<!-- Control whether Night display is available. This should only be enabled on devices with HWC 2 color transform support. --> <bool name="config_nightDisplayAvailable">false</bool> <!-- Default mode to control how Night display is automatically activated. @@ -63,7 +64,8 @@ using the following flags defined in: <p> The code is divided between framework, system services, SystemUI, and Settings: </p> -<pre>platform/frameworks/base/core +<pre class="devsite-click-to-copy"> +platform/frameworks/base/core ├ java/android/provider/Settings.java ├ java/com/android/internal/app/NightDisplayController.java └ res/res/values/config.xml diff --git a/en/devices/tech/display/retail-mode.html b/en/devices/tech/display/retail-mode.html index 0e8c9acc..b694e616 100644 --- a/en/devices/tech/display/retail-mode.html +++ b/en/devices/tech/display/retail-mode.html @@ -43,7 +43,7 @@ employees.</li></ul> <h2 id="lifecycle">Lifecycle</h2> -<img src="images/retail-demo-flow.png" alt="retail demo mode flow" width="XXX" id="retail-demo-flow" /> +<img src="/devices/tech/display/images/retail-demo-flow.png" alt="retail demo mode flow" width="XXX" id="retail-demo-flow" /> <p class="img-caption"> <strong>Figure 1.</strong> Retail demonstration mode option in Language selection </p> @@ -58,7 +58,7 @@ factory. Once a consumer setup has completed, retail mode may no longer be available. Once selected, the device finishes SUW with an abbreviated flow. </p> -<img src="images/retail-demo-wizard.png" alt="retail demo wizard use" width="XXX" id="retail-demo-wizard" /> +<img src="/devices/tech/display/images/retail-demo-wizard.png" alt="retail demo wizard use" width="XXX" id="retail-demo-wizard" /> <p class="img-caption"> <strong>Figure 2.</strong> Retail demonstration mode option in Language selection @@ -135,9 +135,10 @@ from the boot loader. <h2 id="examples-and-source">Examples and source</h2> <p> -Find the custom launcher that plays a video in a loop within:<br> -<code>/packages/apps/RetailDemo</code> -</p> +Find the custom launcher that plays a video in a loop within:</p> +<pre class="devsite-click-to-copy"> +/packages/apps/RetailDemo +</pre> <h2 id="implementation">Implementation</h2> @@ -165,7 +166,7 @@ An OEM specifies a custom launcher by overriding the framework resource For example, with: </p> -<pre> +<pre class="devsite-click-to-copy"> <!-- Component that is the default launcher when Retail Mode is enabled. --> <string name="config_demoModeLauncherComponent">com.android.retaildemo/.DemoPlayer</string> </pre> @@ -288,7 +289,7 @@ video from can be configured by overriding the following string value in the RetailDemo app: </p> -<pre> +<pre class="devsite-click-to-copy"> <!-- URL where the retail demo video can be downloaded from. --> <string name="retail_demo_video_download_url"></string> </pre> @@ -306,7 +307,7 @@ in <code>res/values-en-rUS/strings.xml</code> and In <code>res/values-en-rUS/strings.xml</code>: </p> -<pre> +<pre class="devsite-click-to-copy"> <string name="retail_demo_video_download_url">download URL for US video goes here</string> </pre> @@ -314,7 +315,7 @@ In <code>res/values-en-rUS/strings.xml</code>: And similarly in <code>res/values-en-rGB/strings.xml</code>: </p> -<pre> +<pre class="devsite-click-to-copy"> <string name="retail_demo_video_download_url">download URL for UK video goes here</string> </pre> diff --git a/en/devices/tech/ota/ab_updates.html b/en/devices/tech/ota/ab_updates.html index 0c538085..282ea5a0 100644 --- a/en/devices/tech/ota/ab_updates.html +++ b/en/devices/tech/ota/ab_updates.html @@ -375,7 +375,7 @@ <li>Implement the state machine as shown in Figure 1:</li> </ul> -<img src="images/ab-updates-state-machine.png"> +<img src="/devices/tech/ota/images/ab-updates-state-machine.png"> <p class="img-caption"><strong>Figure 1.</strong> Bootloader state machine</p> @@ -423,8 +423,9 @@ extra arguments: </p> -<pre>skip_initramfs rootwait ro init=/init root="/dev/dm-0 dm=system none ro,0 1 \ - android-verity <public-key-id> <path-to-system-partition>" +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">skip_initramfs rootwait ro init=/init root="/dev/dm-0 dm=system none ro,0 1 \ + android-verity <public-key-id> <path-to-system-partition>"</code> </pre> <p> @@ -444,19 +445,23 @@ <code>openssl</code> command to convert from <code>.pem</code> to <code>.der</code> format (if the .X509 certificate is formatted in <code>.pem</code> format): - <pre>openssl x509 -in <x509-pem-certificate> -outform der -out <x509-der-certificate></pre> +<pre class="devsite-terminal devsite-click-to-copy"> +openssl x509 -in <x509-pem-certificate> -outform der -out <x509-der-certificate> +</pre> </li> <li> Once copied to the kernel build root, build the <code>zImage</code> to include the certificate as part of the system keyring. This can be verified from the following <code>procfs</code> entry (requires <code>KEYS_CONFIG_DEBUG_PROC_KEYS</code> to be enabled): - <pre>angler:/# cat /proc/keys +<pre class="devsite-click-to-copy"> +angler:/# cat /proc/keys 1c8a217e I------ 1 perm 1f010000 0 0 asymmetri Android: 7e4333f9bba00adfe0ede979e28ed1920492b40f: X509.RSA 0492b40f [] 2d454e3e I------ 1 perm 1f030000 0 0 keyring -.system_keyring: 1/4</pre> +.system_keyring: 1/4 +</pre> </li> </ol> @@ -550,8 +555,10 @@ Android: 7e4333f9bba00adfe0ede979e28ed1920492b40f: X509.RSA 0492b40f [] the A/B-ed partitions. For example: </p> -<pre><path-to-block-device>/vendor /vendor ext4 ro -wait,verify=<path-to-block-device>/metadata,slotselect</pre> +<pre class="devsite-click-to-copy"> +<path-to-block-device>/vendor /vendor ext4 ro +wait,verify=<path-to-block-device>/metadata,slotselect +</pre> <p> Please note that there should be no partition named <code>vendor</code> but @@ -628,7 +635,8 @@ wait,verify=<path-to-block-device>/metadata,slotselect</pre> For example, use the following to generate a full OTA: </p> -<pre>./build/tools/releasetools/ota_from_target_files \ +<pre class="devsite-terminal devsite-click-to-copy"> +./build/tools/releasetools/ota_from_target_files \ dist_output/tardis-target_files.zip ota_update.zip </pre> @@ -636,7 +644,8 @@ wait,verify=<path-to-block-device>/metadata,slotselect</pre> Or, generate an incremental OTA: </p> -<pre>./build/tools/releasetools/ota_from_target_files \ +<pre class="devsite-terminal devsite-click-to-copy"> +./build/tools/releasetools/ota_from_target_files \ -i PREVIOUS-tardis-target_files.zip \ dist_output/tardis-target_files.zip incremental_ota_update.zip </pre> @@ -661,7 +670,8 @@ wait,verify=<path-to-block-device>/metadata,slotselect</pre> configuration: </p> -<pre>AB_OTA_PARTITIONS := \ +<pre class="devsite-click-to-copy"> +AB_OTA_PARTITIONS := \ boot \ system \ bootloader @@ -692,7 +702,8 @@ wait,verify=<path-to-block-device>/metadata,slotselect</pre> applicable): </p> -<pre>AB_OTA_POSTINSTALL_CONFIG += \ +<pre class="devsite-click-to-copy"> +AB_OTA_POSTINSTALL_CONFIG += \ RUN_POSTINSTALL_system=true \ POSTINSTALL_PATH_system=usr/bin/postinst \ FILESYSTEM_TYPE_system=ext4 @@ -706,14 +717,14 @@ additions to the product's device configuration (in the product's device.mk):</p <ol> <li>Include the native components in the build. This ensures the compilation script and binaries are compiled and included in the system image. - <pre> +<pre class="devsite-click-to-copy"> # A/B OTA dexopt package PRODUCT_PACKAGES += otapreopt_script </pre> </li> <li>Connect the compilation script to <code>update_engine</code> such that it is run as a post-install step. - <pre> +<pre class="devsite-click-to-copy"> # A/B OTA dexopt update_engine hookup AB_OTA_POSTINSTALL_CONFIG += \ RUN_POSTINSTALL_system=true \ diff --git a/en/devices/tech/ota/device_code.html b/en/devices/tech/ota/device_code.html index 144f43fc..98f37f0f 100644 --- a/en/devices/tech/ota/device_code.html +++ b/en/devices/tech/ota/device_code.html @@ -38,9 +38,11 @@ used by both the recovery binary and the package-building tools. You can specify the name of the map file in TARGET_RECOVERY_FSTAB in BoardConfig.mk.</p> <p>A sample partition map file might look like this:</p> -<p><code>device/yoyodyne/tardis/recovery.fstab</code></p> +<pre class="devsite-click-to-copy"> +device/yoyodyne/tardis/recovery.fstab +</pre> -<pre> +<pre class="devsite-click-to-copy"> # mount point fstype device [device2] [options (3.0+ only)] /sdcard vfat /dev/block/mmcblk0p1 /dev/block/mmcblk0 @@ -131,9 +133,11 @@ to provide the device-specific functionality. The file <code> makes a good starting point to copy when writing a version of this file for your device.</p> -<p><code>device/yoyodyne/tardis/recovery/recovery_ui.cpp</code></p> +<pre class="devsite-click-to-copy"> +device/yoyodyne/tardis/recovery/recovery_ui.cpp +</pre> -<pre> +<pre class="prettyprint"> #include <linux/input.h> #include "common.h" @@ -147,7 +151,7 @@ your device.</p> appear in the hidden recovery menu. Headers describe how to operate the menu (i.e. controls to change/select the highlighted item).</p> -<pre> +<pre class="prettyprint"> static const char* HEADERS[] = { "Volume up/down to move highlight;", "power button to select.", "", @@ -171,7 +175,7 @@ ScreenRecoveryUIimplementation (see instructions for function to customize from ScreenRecoveryUI is <code>CheckKey()</code>, which does the initial asynchronous key handling:</p> -<pre> +<pre class="prettyprint"> class TardisUI : public ScreenRecoveryUI { public: virtual KeyAction CheckKey(int key) { @@ -212,7 +216,7 @@ setup: the display is toggled by holding down power and pressing volume-up, and the device can be rebooted immediately by pressing the power button five times in a row (with no other intervening keys):</p> -<pre> +<pre class="prettyprint"> class TardisUI : public ScreenRecoveryUI { private: int consecutive_power_keys; @@ -263,7 +267,7 @@ Images</a>.</p> instance of your UI class and return that from the <code>GetUI()</code> function:</p> -<pre> +<pre class="prettyprint"> class TardisDevice : public Device { private: TardisUI* ui; @@ -283,7 +287,7 @@ but before any action has been taken. The default implementation does nothing, so you do not need to provide this in your subclass if you have nothing to do: </p> -<pre> +<pre class="prettyprint"> void StartRecovery() { // ... do something tardis-specific here, if needed .... } @@ -294,7 +298,7 @@ so you do not need to provide this in your subclass if you have nothing to do: of items. In this implementation, it returns the static arrays defined at the top of the file:</p> -<pre> +<pre class="prettyprint"> const char* const* GetMenuHeaders() { return HEADERS; } const char* const* GetMenuItems() { return ITEMS; } </pre> @@ -303,7 +307,7 @@ const char* const* GetMenuItems() { return ITEMS; } <p>Next, provide a <code>HandleMenuKey()</code> function, which takes a keypress and the current menu visibility, and decides what action to take:</p> -<pre> +<pre class="prettyprint"> int HandleMenuKey(int key, int visible) { if (visible) { switch (key) { @@ -350,7 +354,7 @@ use trackball motions as triggers for rebooting or toggling the display.</p> devices pressing Alt-W in recovery would start a data wipe whether the menu was visible or not. YOu could implement like this:</p> -<pre> +<pre class="prettyprint"> int HandleMenuKey(int key, int visible) { if (ui->IsKeyPressed(KEY_LEFTALT) && key == KEY_W) { return 2; // position of the "wipe data" item in the menu @@ -369,7 +373,7 @@ However, you can return the values if desired.</p> positions in the array of items returned by <code>GetMenuItems()</code> to actions. For the array of items in the tardis example, use:</p> -<pre> +<pre class="prettyprint"> BuiltinAction InvokeMenuItem(int menu_position) { switch (menu_position) { case 0: return REBOOT; @@ -409,7 +413,7 @@ should erase it here. You should return 0 to indicate success and another value for failure, though currently the return value is ignored. The user data and cache partitions are wiped whether you return success or failure.</p> -<pre> +<pre class="prettyprint"> int WipeData() { // ... do something tardis-specific here, if needed .... return 0; @@ -421,7 +425,7 @@ and cache partitions are wiped whether you return success or failure.</p> for the <code>make_device()</code> function that creates and returns an instance of your Device class:</p> -<pre> +<pre class="prettyprint"> class TardisDevice : public Device { // ... all the above methods ... }; @@ -436,9 +440,11 @@ Device* make_device() { on your device. In Android.mk, create a static library that contains only this C++ file:</p> -<p><code>device/yoyodyne/tardis/recovery/Android.mk</code></p> +<pre class="devsite-click-to-copy"> +device/yoyodyne/tardis/recovery/Android.mk +</pre> -<pre> +<pre class="devsite-click-to-copy"> LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) @@ -455,7 +461,7 @@ include $(BUILD_STATIC_LIBRARY) <p>Then, in the board configuration for this device, specify your static library as the value of TARGET_RECOVERY_UI_LIB.</p> -<pre> +<pre class="devsite-click-to-copy"> device/yoyodyne/tardis/BoardConfig.mk [...] @@ -483,11 +489,11 @@ and the <strong>installing</strong> animation.</p> <tbody> <tr> <td> -<img src="../images/icon_error.png" alt="image shown during ota error"> +<img src="/devices/tech/images/icon_error.png" alt="image shown during ota error"> <p class="img-caption"><strong>Figure 1.</strong> icon_error.png</p> </td> <td> -<img src="../images/icon_installing_5x.png" alt="image shown during ota install" +<img src="/devices/tech/images/icon_installing_5x.png" alt="image shown during ota install" height="275"> <p class="img-caption"><strong>Figure 2.</strong> icon_installing.png</p> </td> @@ -521,11 +527,11 @@ above) and the <b>installing</b> animation plus several overlay images:</p> <tbody> <tr> <td rowspan="2"> -<img src="../images/icon_installing.png" alt="image shown during ota install"> +<img src="/devices/tech/images/icon_installing.png" alt="image shown during ota install"> <p class="img-caption"><strong>Figure 3.</strong> icon_installing.png</p> </td> <td> -<img src="../images/icon_installing_overlay01.png" alt="image shown as first +<img src="/devices/tech/images/icon_installing_overlay01.png" alt="image shown as first overlay"> <p class="img-caption"><strong>Figure 4.</strong> icon-installing_overlay01.png </p> @@ -533,7 +539,7 @@ overlay"> </tr> <tr> <td> -<img src="../images/icon_installing_overlay07.png" alt="image shown as seventh +<img src="/devices/tech/images/icon_installing_overlay07.png" alt="image shown as seventh overlay"> <p class="img-caption"><strong>Figure 5.</strong> icon_installing_overlay07.png </p> @@ -551,12 +557,12 @@ overlay is placed on top of the base image:</p> <table style="border-collapse:collapse;"> <tbody> <tr> -<td><img align="center" src="../images/composite01.png" alt="composite image of +<td><img align="center" src="/devices/tech/images/composite01.png" alt="composite image of install plus first overlay"> <p class="img-caption"><strong>Figure 6.</strong> Installing animation frame 1 (icon_installing.png + icon_installing_overlay01.png) </td> -<td><img align="center" src="../images/composite07.png" alt="composite image of +<td><img align="center" src="/devices/tech/images/composite07.png" alt="composite image of install plus seventh overlay"> <p class="img-caption"><strong>Figure 7.</strong> Installing animation frame 7 (icon_installing.png + icon_installing_overlay07.png) @@ -593,7 +599,7 @@ strings for that message in each locale.</p> <p>Sample image of recovery text strings:</p> -<img src="../images/installing_text.png" alt="image of recovery text"> +<img src="/devices/tech/images/installing_text.png" alt="image of recovery text"> <p class="img-caption"><strong>Figure 8.</strong> Localized text for recovery messages</p> @@ -623,9 +629,9 @@ in English.</p> <p>Progress bars can appear below the main image (or animation). The progress bar is made by combining two input images, which must be of the same size:</p> -<img src="../images/progress_empty.png" alt="empty progress bar"> +<img src="/devices/tech/images/progress_empty.png" alt="empty progress bar"> <p class="img-caption"><strong>Figure 9.</strong> progress_empty.png</p> -<img src="../images/progress_fill.png" alt="full progress bar"> +<img src="/devices/tech/images/progress_fill.png" alt="full progress bar"> <p class="img-caption"><strong>Figure 10.</strong> progress_fill.png</p> <p>The left end of the <i>fill</i> image is displayed next to the right end of @@ -633,11 +639,11 @@ the <i>empty</i> image to make the progress bar. The position of the boundary between the two images is changed to indicate the progress. For example, with the above pairs of input images, display:</p> -<img src="../images/progress_1.png" alt="progress bar at 1%"> +<img src="/devices/tech/images/progress_1.png" alt="progress bar at 1%"> <p class="img-caption"><strong>Figure 11.</strong> Progress bar at 1%></p> -<img src="../images/progress_10.png" alt="progress bar at 10%"> +<img src="/devices/tech/images/progress_10.png" alt="progress bar at 10%"> <p class="img-caption"><strong>Figure 12.</strong> Progress bar at 10%</p> -<img src="../images/progress_50.png" alt="progress bar at 50%"> +<img src="/devices/tech/images/progress_50.png" alt="progress bar at 50%"> <p class="img-caption"><strong>Figure 13.</strong> Progress bar at 50%</p> <p>You can provide device-specific versions of these images by placing them @@ -678,8 +684,10 @@ doesn't have keys or you want to process them differently.</p> by providing your own extension functions that can be called from within your updater script. Here's a sample function for the tardis device:</p> -<p><code>device/yoyodyne/tardis/recovery/recovery_updater.c</code></p> -<pre> +<pre class="devsite-click-to-copy"> +device/yoyodyne/tardis/recovery/recovery_updater.c +</pre> +<pre class="prettyprint"> #include <stdlib.h> #include <string.h> @@ -691,7 +699,7 @@ by which the function was called, a <code>State*</code> cookie, the number of incoming arguments, and an array of <code>Expr*</code> pointers representing the arguments. The return value is a newly-allocated <code>Value*</code>.</p> -<pre> +<pre class="prettyprint"> Value* ReprogramTardisFn(const char* name, State* state, int argc, Expr* argv[]) { if (argc != 2) { return ErrorAbort(state, "%s() expects 2 args, got %d", name, argc); @@ -711,7 +719,7 @@ ownership of the Value returned and are responsible for eventually calling <p>Suppose the function needs two arguments: a string-valued <b>key</b> and a blob-valued <b>image</b>. You could read arguments like this:</p> -<pre> +<pre class="prettyprint"> Value* key = EvaluateValue(state, argv[0]); if (key == NULL) { return NULL; @@ -738,7 +746,7 @@ blob-valued <b>image</b>. You could read arguments like this:</p> for multiple arguments. The <code>ReadValueArgs()</code> function can make this easier. Instead of the code above, you could have written this:</p> -<pre> +<pre class="prettyprint"> Value* key; Value* image; if (ReadValueArgs(state, argv, 2, &key, &image) != 0) { @@ -763,7 +771,7 @@ number of arguments (it returns an array of <code>Value*</code>).</p> <p>After evaluating the arguments, do the work of the function:</p> -<pre> +<pre class="devsite-click-to-copy"> // key->data is a NUL-terminated string // image->data and image->size define a block of binary data // @@ -781,7 +789,7 @@ copy of the constant string to return, since the caller will <code>free() </code> both. Don't forget to call <code>FreeValue()</code> on the objects you got by evaluating your arguments!</p> -<pre> +<pre class="prettyprint"> FreeValue(key); FreeValue(image); @@ -796,7 +804,7 @@ got by evaluating your arguments!</p> <p>The convenience function <code>StringValue()</code> wraps a string into a new Value object. Use to write the above code more succinctly:</p> -<pre> +<pre class="prettyprint"> FreeValue(key); FreeValue(image); @@ -811,7 +819,7 @@ register each extension function. By convention, name device-specific functions <code><i>device</i>.<i>whatever</i></code> to avoid conflicts with future built-in functions added.</p> -<pre> +<pre class="prettyprint"> void Register_librecovery_updater_tardis() { RegisterFunction("tardis.reprogram", ReprogramTardisFn); } @@ -821,9 +829,11 @@ void Register_librecovery_updater_tardis() { code. (This is the same makefile used to customize the recovery UI in the previous section; your device may have both static libraries defined here.)</p> -<p><code>device/yoyodyne/tardis/recovery/Android.mk</code></p> +<pre class="devsite-click-to-copy"> +device/yoyodyne/tardis/recovery/Android.mk +</pre> -<pre> +<pre class="devsite-click-to-copy"> include $(CLEAR_VARS) LOCAL_SRC_FILES := recovery_updater.c LOCAL_C_INCLUDES += bootable/recovery @@ -832,7 +842,7 @@ LOCAL_C_INCLUDES += bootable/recovery <p>The name of the static library must match the name of the <code>Register_<i>libname</i></code> function contained within it.</p> -<pre> +<pre class="devsite-click-to-copy"> LOCAL_MODULE := librecovery_updater_tardis include $(BUILD_STATIC_LIBRARY) </pre> @@ -847,9 +857,11 @@ their (non-existent) registration function. For example, if your device-specific code wanted to use zlib to decompress data, you would include libz here.</p> -<p><code>device/yoyodyne/tardis/BoardConfig.mk</code></p> +<pre class="devsite-click-to-copy"> +device/yoyodyne/tardis/BoardConfig.mk +</pre> -<pre> +<pre class="devsite-click-to-copy"> [...] # add device-specific extensions to the updater binary @@ -873,8 +885,10 @@ your extension functions.</p> Assuming your data file is in <code>device/yoyodyne/tardis/tardis.dat</code>, declare the following in your device's AndroidBoard.mk:</p> -<p><code>device/yoyodyne/tardis/AndroidBoard.mk</code></p> -<pre> +<pre class="devsite-click-to-copy"> +device/yoyodyne/tardis/AndroidBoard.mk +</pre> +<pre class="devsite-click-to-copy"> [...] $(call add-radio-file,tardis.dat) @@ -886,8 +900,10 @@ loaded no matter what device is being built. (If your tree includes multiple devices, you only want the tardis.dat file added when building the tardis device.)</p> -<p><code>device/yoyodyne/tardis/Android.mk</code></p> -<pre> +<pre class="devsite-click-to-copy"> +device/yoyodyne/tardis/Android.mk +</pre> +<pre class="devsite-click-to-copy"> [...] # an alternative to specifying it in AndroidBoard.mk @@ -907,8 +923,10 @@ multiple times to add as many files as you want.</p> <p>To extend the release tools, write a Python module (must be named releasetools.py) the tools can call into if present. Example:</p> -<p><code>device/yoyodyne/tardis/releasetools.py</code></p> -<pre> +<pre class="devsite-click-to-copy"> +device/yoyodyne/tardis/releasetools.py +</pre> +<pre class="prettyprint"> import common def FullOTA_InstallEnd(info): @@ -924,7 +942,7 @@ def FullOTA_InstallEnd(info): <p>A separate function handles the case of generating an incremental OTA package. For this example, suppose you need to reprogram the tardis only when the tardis.dat file has changed between two builds.</p> -<pre> +<pre class="prettyprint"> def IncrementalOTA_InstallEnd(info): # copy the data into the package. source_tardis_dat = info.source_zip.read("RADIO/tardis.dat") @@ -1016,9 +1034,11 @@ documentation for ZIP archives</a>.</p> <p>Specify the location of your device's releasetools.py script in your BoardConfig.mk file:</p> -<p><code>device/yoyodyne/tardis/BoardConfig.mk</code></p> +<pre class="devsite-click-to-copy"> +device/yoyodyne/tardis/BoardConfig.mk +</pre> -<pre> +<pre class="devsite-click-to-copy"> [...] TARGET_RELEASETOOLS_EXTENSIONS := device/yoyodyne/tardis @@ -1042,30 +1062,15 @@ target-files.</p> picks up the device-specific module from the target_files .zip file and uses it when generating OTA packages:</p> -<pre> -% <b>./build/tools/releasetools/ota_from_target_files \ - -i PREVIOUS-tardis-target_files.zip \ - dist_output/tardis-target_files.zip incremental_ota_update.zip</b> -unzipping target target-files... -<b>using device-specific extensions from target_files</b> -unzipping source target-files... - [...] -done. +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">./build/tools/releasetools/ota_from_target_files -i PREVIOUS-tardis-target_files.zip dist_output/tardis-target_files.zip incremental_ota_update.zip</code> </pre> <p>Alternatively, you can specify device-specific extensions when you run <code>ota_from_target_files</code>.</p> -<pre> -% <b>./build/tools/releasetools/ota_from_target_files \ - -s device/yoyodyne/tardis \ # specify the path to device-specific extensions - -i PREVIOUS-tardis-target_files.zip \ - dist_output/tardis-target_files.zip incremental_ota_update.zip</b> -unzipping target target-files... -<b>loaded device-specific extensions from device/yoyodyne/tardis</b> -unzipping source target-files... - [...] -done. +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">./build/tools/releasetools/ota_from_target_files -s device/yoyodyne/tardis -i PREVIOUS-tardis-target_files.zip dist_output/tardis-target_files.zip incremental_ota_update.zip</code> </pre> <p class="note"><strong>Note:</strong> For a complete list of options, refer diff --git a/en/devices/tech/ota/reduce_size.html b/en/devices/tech/ota/reduce_size.html index 6a4e6182..227c40df 100644 --- a/en/devices/tech/ota/reduce_size.html +++ b/en/devices/tech/ota/reduce_size.html @@ -175,8 +175,8 @@ <p>To use the build diff tool, run the following command:</p> -<pre class=prettyprint> -$ target_files_diff.py dir1 dir2 +<pre class="devsite-terminal devsite-click-to-copy"> +target_files_diff.py dir1 dir2 </pre> <p><code>dir1</code> and <code>dir2</code> are base directories that contain the extracted target diff --git a/en/devices/tech/ota/sign_builds.html b/en/devices/tech/ota/sign_builds.html index 4829547a..fbc0d718 100644 --- a/en/devices/tech/ota/sign_builds.html +++ b/en/devices/tech/ota/sign_builds.html @@ -52,12 +52,12 @@ publicly released or deployed Android OS image with a special set of <p>To generate your own unique set of release-keys, run these commands from the root of your Android tree:</p> -<pre class="no-pretty-print"> -subject='/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/emailAddress=android@android.com' -mkdir ~/.android-certs -for x in releasekey platform shared media; do \ +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">subject='/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/emailAddress=android@android.com'</code> +<code class="devsite-terminal">mkdir ~/.android-certs</code> +<code class="devsite-terminal">for x in releasekey platform shared media; do \ ./development/tools/make_key ~/.android-certs/$x "$subject"; \ -done +done</code> </pre> <p><code>$subject</code> should be changed to reflect your organization's @@ -69,12 +69,12 @@ such as on an air-gapped computer.</p> <p>To generate a release image, use:</p> -<pre class="no-pretty-print"> -make dist -./build/tools/releasetools/sign_target_files_apks \ +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">make dist</code> +<code class="devsite-terminal">./build/tools/releasetools/sign_target_files_apks \ -o \ # explained in the next section -d ~/.android-certs out/dist/*-target_files-*.zip \ - signed-target_files.zip + signed-target_files.zip</code> </pre> <p>The <code>sign_target_files_apks</code> script takes a target-files .zip @@ -87,11 +87,11 @@ been signed with new keys. The newly signed images can be found under A signed target-files zip can be converted into a signed OTA update zip using the following procedure: -<pre class="no-pretty-print"> -./build/tools/releasetools/ota_from_target_files \ +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">./build/tools/releasetools/ota_from_target_files \ -k ~/.android-certs/releasekey \ signed-target_files.zip \ - signed-ota_update.zip + signed-ota_update.zip</code> </pre> <h3 id="signatures-sideloading">Signatures and sideloading</h3> @@ -126,8 +126,10 @@ verification against otacerts.zip). You can specify extra keys to be included only in recovery by setting the PRODUCT_EXTRA_RECOVERY_KEYS variable in your product definition:</p> -<p><code>vendor/yoyodyne/tardis/products/tardis.mk</code></p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> +vendor/yoyodyne/tardis/products/tardis.mk +</pre> +<pre class="devsite-click-to-copy"> [...] PRODUCT_EXTRA_RECOVERY_KEYS := vendor/yoyodyne/security/tardis/sideload @@ -165,8 +167,10 @@ build/target/product/security</code>:</p> in their Android.mk file. (testkey is used if this variable is not set.) You can also specify an entirely different key by pathname, e.g.:</p> -<p><code>device/yoyodyne/apps/SpecialApp/Android.mk</code></p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> +device/yoyodyne/apps/SpecialApp/Android.mk +</pre> +<pre class="devsite-click-to-copy"> [...] LOCAL_CERTIFICATE := device/yoyodyne/security/special @@ -185,7 +189,7 @@ dest_key</i></code> flag specifies key replacements one at a time. The flag replace all those in <code>build/target/product/security</code>; it is equivalent to using <code>-k</code> four times to specify the mappings:</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> build/target/product/security/testkey = dir/releasekey build/target/product/security/platform = dir/platform build/target/product/security/shared = dir/shared @@ -198,7 +202,7 @@ one to replace the additional <code>keydevice/yoyodyne/security/special</code> required by SpecialApp in the example above. If the keys were in the following files:</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> vendor/yoyodyne/security/tardis/releasekey.x509.pem vendor/yoyodyne/security/tardis/releasekey.pk8 vendor/yoyodyne/security/tardis/platform.x509.pem @@ -215,12 +219,12 @@ vendor/yoyodyne/security/special-release.pk8 # password protected <p>Then you would sign all the apps like this:</p> -<pre class="no-pretty-print"> -% <b>./build/tools/releasetools/sign_target_files_apks \ - -d vendor/yoyodyne/security/tardis \ - -k vendor/yoyodyne/special=vendor/yoyodyne/special-release \ - -o \ - tardis-target_files.zip signed-tardis-target_files.zip</b> +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">./build/tools/releasetools/sign_target_files_apks -d vendor/yoyodyne/security/tardis -k vendor/yoyodyne/special=vendor/yoyodyne/special-release -o tardis-target_files.zip signed-tardis-target_files.zip</code> +</pre> + +<p>This brings up the following:</p> +<pre class="devsite-click-to-copy"> Enter password for vendor/yoyodyne/security/special-release key> Enter password for vendor/yoyodyne/security/tardis/media key> Enter password for vendor/yoyodyne/security/tardis/platform key> @@ -267,24 +271,22 @@ flags.</p> certificate/private key pairs using the openssl tool from <a href="https://www.openssl.org/">openssl.org</a>:</p> -<pre class="no-pretty-print"> +<pre class="devsite-click-to-copy"> # generate RSA key -% <b>openssl genrsa -3 -out temp.pem 2048</b> +<code class="devsite-terminal">openssl genrsa -3 -out temp.pem 2048</code> Generating RSA private key, 2048 bit long modulus ....+++ .....................+++ e is 3 (0x3) # create a certificate with the public part of the key -% <b>openssl req -new -x509 -key temp.pem -out releasekey.x509.pem \ - -days 10000 \ - -subj '/C=US/ST=California/L=San Narciso/O=Yoyodyne, Inc./OU=Yoyodyne Mobility/CN=Yoyodyne/emailAddress=yoyodyne@example.com'</b> +<code class="devsite-terminal">openssl req -new -x509 -key temp.pem -out releasekey.x509.pem -days 10000 -subj '/C=US/ST=California/L=San Narciso/O=Yoyodyne, Inc./OU=Yoyodyne Mobility/CN=Yoyodyne/emailAddress=yoyodyne@example.com'</code> # create a PKCS#8-formatted version of the private key -% <b>openssl pkcs8 -in temp.pem -topk8 -outform DER -out releasekey.pk8 -nocrypt</b> +<code class="devsite-terminal">openssl pkcs8 -in temp.pem -topk8 -outform DER -out releasekey.pk8 -nocrypt</code> # securely delete the temp.pem file -% <b>shred --remove temp.pem</b> +<code class="devsite-terminal">shred --remove temp.pem</code> </pre> <p>The openssl pkcs8 command given above creates a .pk8 file with <i>no</i> @@ -315,7 +317,7 @@ the following command from the root of the Android tree: </p> -<pre> +<pre class="devsite-terminal devsite-click-to-copy"> ./build/tools/releasetools/img_from_target_files signed-target-files.zip signed-img.zip </pre> @@ -324,7 +326,7 @@ The resulting file, <code>signed-img.zip</code>, contains all the .img files. To load an image onto a device, use fastboot as follows: -<pre> +<pre class="devsite-terminal devsite-click-to-copy"> fastboot update signed-img.zip </pre> diff --git a/en/devices/tech/ota/tools.html b/en/devices/tech/ota/tools.html index 1b26f918..4ad58d90 100644 --- a/en/devices/tech/ota/tools.html +++ b/en/devices/tech/ota/tools.html @@ -39,26 +39,18 @@ state of the device.</p> <p>Example: Using the release tools to build a full update for the hypothetical <b>tardis</b> device:</p> -<pre> +<pre class="devsite-click-to-copy"> # first, build the target-files .zip -% <b>. build/envsetup.sh && lunch tardis-eng</b> -% <b>mkdir dist_output</b> -% <b>make dist DIST_DIR=dist_output</b> - [...] -% <b>ls -l dist_output/*target_files*</b> --rw-r----- 1 user eng 69965275 Sep 29 15:51 tardis-target_files.zip +<code class="devsite-terminal">. build/envsetup.sh && lunch tardis-eng</code> +<code class="devsite-terminal">mkdir dist_output</code> +<code class="devsite-terminal">make dist DIST_DIR=dist_output</code> </pre> <p>The target-files .zip contains everything needed to construct OTA packages. </p> -<pre> -% <b>./build/tools/releasetools/ota_from_target_files \ - dist_output/tardis-target_files.zip ota_update.zip</b> -unzipping target target-files... -done. -% <b>ls -l ota_update.zip</b> --rw-r----- 1 user eng 62236561 Sep 29 15:58 ota_update.zip +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">./build/tools/releasetools/ota_from_target_files dist_output/tardis-target_files.zip ota_update.zip</code> </pre> <p>The ota_update.zip is now ready to be sent to test devices (everything is @@ -81,16 +73,8 @@ incremental update, you need the target_files .zip from the previous build (the one you want to update <i>from</i>) as well as the target_files .zip from the new build.</p> -<pre> -% <b>./build/tools/releasetools/ota_from_target_files \ - -i PREVIOUS-tardis-target_files.zip \ </b># make incremental from this older version<b> - dist_output/tardis-target_files.zip incremental_ota_update.zip</b> -unzipping target target-files... -unzipping source target-files... - [...] -done. -% <b>ls -l incremental_ota_update.zip</b> --rw-r----- 1 user eng 1175314 Sep 29 16:10 incremental_ota_update.zip +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">./build/tools/releasetools/ota_from_target_files -i PREVIOUS-tardis-target_files.zip dist_output/tardis-target_files.zip incremental_ota_update.zip # make incremental from the older version</code> </pre> <p>This build is very similar to the previous build, and the incremental diff --git a/en/devices/tech/power/batterystats.html b/en/devices/tech/power/batterystats.html index 75c1e9e5..10cf934f 100644 --- a/en/devices/tech/power/batterystats.html +++ b/en/devices/tech/power/batterystats.html @@ -48,8 +48,9 @@ <h2 id="command-line_options">Command input</h2> <p>The basic <code>batterystats</code> command is:</p> - <pre class="prettyprint"> -$ adb shell dumpsys batterystats</pre> +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell dumpsys batterystats +</pre> <p>Supported options:</p> <ul> <li><code>--help</code> displays additional options for tailoring the output. @@ -59,13 +60,15 @@ $ adb shell dumpsys batterystats</pre> </ul> <p>For example, to print battery usage statistics in csv format for all apps since the device was last charged, run the command:</p> - <pre class="prettyprint"> -$ adb shell dumpsys batterystats --charged --checkin</pre> +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell dumpsys batterystats --charged --checkin +</pre> <p>You can also specify a package name to get statistics for a single app. For example, to print battery usage statistics for a given app package since the device was last charged, run the command:</p> - <pre class="prettyprint"> -$ adb shell dumpsys batterystats --charged <package-name></pre> +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell dumpsys batterystats --charged <package-name> +</pre> <h2 id="output">Command output</h2> @@ -101,7 +104,7 @@ $ adb shell dumpsys batterystats --charged <package-name></pre> <p>Sample output:</p> - <pre class="no-pretty-print"> + <pre class="devsite-click-to-copy"> 9,0,i,vers,11,116,K,L 9,0,i,uid,1000,android 9,0,i,uid,1000,com.android.providers.settings 9,0,i,uid,1000,com.android.inputdevices diff --git a/en/devices/tech/power/component.html b/en/devices/tech/power/component.html index 90edf65a..0b69358c 100644 --- a/en/devices/tech/power/component.html +++ b/en/devices/tech/power/component.html @@ -105,8 +105,8 @@ in low-power states inappropriate for measuring active power use. To prevent the suspending while the screen is off, use a temporary partial wakelock. Using a USB cable, connect the device to a development host, then issue the following command:</p> -<pre> -$ adb shell "echo temporary > /sys/power/wake_lock" +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell "echo temporary > /sys/power/wake_lock" </pre> <p>While in <code>wake_lock</code>, the screen off state does not trigger a system suspend. @@ -114,8 +114,8 @@ $ adb shell "echo temporary > /sys/power/wake_lock" <p>To remove the wakelock:</p> -<pre> -$ adb shell "echo temporary > /sys/power/wake_unlock" +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell "echo temporary > /sys/power/wake_unlock" </pre> <h3 id="measure-suspend">Measuring system suspend</h3> @@ -155,7 +155,7 @@ scheduling activity.</p> <p>You must specify the available CPU speeds for your device in the power profile <code>cpu.speeds</code> entry. To get a list of available CPU speeds, run:</p> -<pre> +<pre class="devsite-terminal devsite-click-to-copy"> adb shell cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state </pre> @@ -167,12 +167,12 @@ controlling CPU speed using the userspace cpufreq governor and using sysfs inter speed. For example, to set speed for 200MHz on a system with only 1 CPU or all CPUs sharing a common cpufreq policy, use the system console or adb shell to run the following commands:</p> -<pre> -echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor -echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq -echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq -echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed -cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor</code> +<code class="devsite-terminal">echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq</code> +<code class="devsite-terminal">echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq</code> +<code class="devsite-terminal">echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed</code> +<code class="devsite-terminal">cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq</code> </pre> <p class="note"> @@ -187,7 +187,7 @@ setting the maximum speed.</p> <p>To measure current consumed by a CPU running at various speeds, use the system console to place the CPU in a CPU-bound loop using the command:</p> -<pre> +<pre class="devsite-click-to-copy"> # while true; do true; done </pre> diff --git a/en/devices/tech/power/device.html b/en/devices/tech/power/device.html index 160cbb18..88443663 100644 --- a/en/devices/tech/power/device.html +++ b/en/devices/tech/power/device.html @@ -45,7 +45,7 @@ consumption between configurations.</p> <p>To read power consumption data, insert calls to the API in your testing code.</p> -<pre> +<pre class="prettyprint"> import android.os.BatteryManager; import android.content.Context; BatteryManager mBatteryManager = @@ -59,7 +59,7 @@ Slog.i(TAG, "Remaining energy = " + energy + "nWh"); <p>Android supports the following battery fuel gauge properties:</p> -<pre> +<pre class="devsite-click-to-copy"> BATTERY_PROPERTY_CHARGE_COUNTER Remaining battery capacity in microampere-hours BATTERY_PROPERTY_CURRENT_NOW Instantaneous battery current in microamperes BATTERY_PROPERTY_CURRENT_AVERAGE Average battery current in microamperes diff --git a/en/devices/tech/power/mgmt.html b/en/devices/tech/power/mgmt.html index 21086893..7dd0862b 100644 --- a/en/devices/tech/power/mgmt.html +++ b/en/devices/tech/power/mgmt.html @@ -97,11 +97,11 @@ a period of time. <h3 id=testing_app_standby>Testing App Standby</h3> <p>You can manually test App Standby using the following <code>adb</code> commands:</p> -<pre> -$ adb shell dumpsys battery unplug -$ adb shell am set-idle packageName true -$ adb shell am set-idle packageName false -$ adb shell am get-idle packageName +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">adb shell dumpsys battery unplug</code> +<code class="devsite-terminal">adb shell am set-idle packageName true</code> +<code class="devsite-terminal">adb shell am set-idle packageName false</code> +<code class="devsite-terminal">adb shell am get-idle packageName</code> </pre> <h2 id="doze">Doze</h2> @@ -195,7 +195,7 @@ they can complete their processing.</li> <p>Android 7.0 and later extends Doze by enabling a lightweight sleep mode during screen off, before the device is idle.</p> -<p><img src="../images/doze_lightweight.png"></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> @@ -258,10 +258,10 @@ configuration is necessary.</p> <li>In the device overlay config file <code>overlay/frameworks/base/core/res/res/values/config.xml</code>, set <code>config_enableAutoPowerModes</code> to <strong>true</strong>: -<pre> -bool name="config_enableAutoPowerModes">true</bool> +<pre class="devsite-click-to-copy"> +<bool name="config_enableAutoPowerModes">true</bool> </pre> -<br>In AOSP, this parameter is set to false (Doze disabled) by default.<br> +In AOSP, this parameter is set to false (Doze disabled) by default.<br> </li> <li>Confirm that preloaded apps and services: <ul> diff --git a/en/devices/tech/power/values.html b/en/devices/tech/power/values.html index 472b8207..e4c68426 100644 --- a/en/devices/tech/power/values.html +++ b/en/devices/tech/power/values.html @@ -68,7 +68,7 @@ from the <code>sysfs</code> files in: <p>Example of cluster CPUs and speeds:</p> -<pre> +<pre class="devsite-click-to-copy"> <array name="cpu.active.cluster0"> <value>200</value> <value>300</value> diff --git a/en/devices/tech/test_infra/tradefed/full_example.html b/en/devices/tech/test_infra/tradefed/full_example.html index c8f44f93..f2bbb704 100644 --- a/en/devices/tech/test_infra/tradefed/full_example.html +++ b/en/devices/tech/test_infra/tradefed/full_example.html @@ -58,7 +58,8 @@ your modules against that JAR.</p> tradefed test generally implements the <a href="/reference/com/android/tradefed/testtype/IRemoteTest.html">IRemoteTest</a> interface. Here's an implementation for the HelloWorldTest:</p> -<pre><code>package com.android.tradefed.example; +<pre class="prettyprint"> +package com.android.tradefed.example; import com.android.tradefed.device.DeviceNotAvailableException; import com.android.tradefed.result.ITestInvocationListener; @@ -70,12 +71,14 @@ public class HelloWorldTest implements IRemoteTest { System.out.println("Hello, TF World!"); } } -</code></pre> +</pre> <p>Save this sample code to <code><tree>/tools/tradefederation/core/prod-tests/src/com/android/tradefed/example/HelloWorldTest.java</code> and rebuild tradefed from your shell:</p> -<pre><code>m -jN</code></pre> +<pre class="devsite-terminal devsite-click-to-copy"> +m -jN +</pre> <p>Note that <code>System.out</code> in the example above may not actually direct output to the console. While this is acceptable for this test example, @@ -94,9 +97,10 @@ order.</p> <p>Lets create a new Configuration for our HelloWorldTest (note the full class name of the HelloWorldTest):</p> -<pre><code><configuration description="Runs the hello world test"> +<pre class="prettyprint"> +<configuration description="Runs the hello world test"> <test class="com.android.tradefed.example.HelloWorldTest" /> -</configuration></code></pre> +</configuration></pre> <p>Save this data to a <code>helloworld.xml</code> file anywhere on your local filesystem (e.g. <code>/tmp/helloworld.xml</code>). TF will parse the @@ -106,21 +110,24 @@ reflection, instantiate it, cast it to a <code>IRemoteTest</code>, and call its <h2 id="runconfig">Running the config (R)</h2> <p>From your shell, launch the tradefed console:</p> -<pre><code>$ tradefed.sh -</code></pre> +<pre class="devsite-terminal devsite-click-to-copy"> +tradefed.sh +</pre> <p>Ensure a device is connected to the host machine and is visible to tradefed:</p> -<pre><code>tf >list devices +<pre class="devsite-click-to-copy"> +tf> list devices Serial State Product Variant Build Battery 004ad9880810a548 Available mako mako JDQ39 100 -</code></pre> +</pre> <p>Configurations can be executed using the <code>run <config></code> console command. Try:</p> -<pre><code>tf> run /tmp/helloworld.xml +<pre class="devsite-click-to-copy"> +tf> run /tmp/helloworld.xml 05-12 13:19:36 I/TestInvocation: Starting invocation for target stub on build 0 on device 004ad9880810a548 Hello, TF World! -</code></pre> +</pre> <p>You should see "Hello, TF World!" output on the terminal.</p> <h2 id="addconfig">Adding the config to the Classpath (D, I, R)</h2> @@ -133,13 +140,15 @@ core library (<code><tree>/tools/tradefederation/core/prod-tests/res/config/example/helloworld.xml</code>). Rebuild tradefed, restart the tradefed console, then ask tradefed to display the list of configurations from the classpath:</p> -<pre><code>tf> list configs +<pre class="devsite-click-to-copy"> +tf> list configs […] example/helloworld: Runs the hello world test -</code></pre> +</pre> <p>You can now run the helloworld config using:</p> -<pre><code>tf >run example/helloworld +<pre class="devsite-click-to-copy"> +tf> run example/helloworld 05-12 13:21:21 I/TestInvocation: Starting invocation for target stub on build 0 on device 004ad9880810a548 Hello, TF World! </code></pre> @@ -152,7 +161,8 @@ to the test.</p> <p>Tests can get a reference to an Android device by implementing the <a href="/reference/com/android/tradefed/testtype/IDeviceTest.html">IDeviceTest</a> interface. Here's a sample implementation of what this looks like:</p> -<pre><code>public class HelloWorldTest implements IRemoteTest, IDeviceTest { +<pre class="prettyprint"> +public class HelloWorldTest implements IRemoteTest, IDeviceTest { private ITestDevice mDevice; @Override public void setDevice(ITestDevice device) { @@ -165,7 +175,7 @@ interface. Here's a sample implementation of what this looks like:</p> } … } -</code></pre> +</pre> <p>The Trade Federation framework will inject the <code>ITestDevice</code> reference into your test via the <code>IDeviceTest#setDevice</code> method, @@ -173,25 +183,30 @@ before the <code>IRemoteTest#run</code> method is called.</p> <p>Let's modify the HelloWorldTest print message to display the serial number of the device:</p> -<pre><code>@Override +<pre class="prettyprint"> +@Override public void run(ITestInvocationListener listener) throws DeviceNotAvailableException { System.out.println("Hello, TF World! I have device " + getDevice().getSerialNumber()); } -</code></pre> +</pre> <p>Now rebuild tradefed and check the list of devices:</p> -<pre><code>$ tradefed.sh -tf >list devices +<pre class="devsite-terminal devsite-click-to-copy"> +tradefed.sh +</pre> +<pre class="devsite-click-to-copy"> +tf> list devices Serial State Product Variant Build Battery 004ad9880810a548 Available mako mako JDQ39 100 -</code></pre> +</pre> <p>Take note of the serial number listed as <strong>Available</strong>; that is the device that should be allocated to HelloWorld:</p> -<pre><code>tf >run example/helloworld +<pre class="devsite-click-to-copy"> +tf> run example/helloworld 05-12 13:26:18 I/TestInvocation: Starting invocation for target stub on build 0 on device 004ad9880810a548 Hello, TF World! I have device 004ad9880810a548 -</code></pre> +</pre> <p>You should see the new print message displaying the serial number of the device.</p> @@ -213,7 +228,8 @@ the start and end of each test, and the end of the test run.</p> <p>Here's what the HelloWorldTest implementation might look like with a single failed test result.</p> -<pre><code>@Override +<pre class="prettyprint"> +@Override public void run(ITestInvocationListener listener) throws DeviceNotAvailableException { System.out.println("Hello, TF World! I have device " + getDevice().getSerialNumber()); @@ -223,7 +239,8 @@ public void run(ITestInvocationListener listener) throws DeviceNotAvailableExcep listener.testFailed(testId, "oh noes, test failed"); listener.testEnded(testId, Collections.emptyMap()); listener.testRunEnded(0, Collections.emptyMap()); -}</code></pre> +} +</pre> <p>TF includes several <code>IRemoteTest</code> implementations you can reuse instead of writing your own from scratch. For example, @@ -239,15 +256,18 @@ Types</a>.</p> <a href="/reference/com/android/tradefed/result/TextResultReporter.html">TextResultReporter</a>, which dumps the results of an invocation to stdout. To illustrate, run the HelloWorldTest config from the previous section:</p> -<pre><code>$ ./tradefed.sh -tf >run example/helloworld +<pre class="devsite-terminal devsite-click-to-copy"> +./tradefed.sh +</pre> +<pre class="devsite-click-to-copy"> +tf> run example/helloworld 05-16 20:03:15 I/TestInvocation: Starting invocation for target stub on build 0 on device 004ad9880810a548 Hello, TF World! I have device 004ad9880810a548 05-16 20:03:15 I/InvocationToJUnitResultForwarder: run helloworldrun started: 1 tests Test FAILURE: com.example.TestClassName#sampleTest stack: oh noes, test failed 05-16 20:03:15 I/InvocationToJUnitResultForwarder: run ended 0 ms -</code></pre> +</pre> <p>To store the results of an invocation elsewhere, such as in a file, specify a custom <code>ITestInvocationListener</code> implementation using the @@ -259,14 +279,16 @@ listener, which writes test results to an XML file in a format similar to that used by the <em>ant</em> JUnit XML writer. To specify the result_reporter in the configuration, edit the <code>…/res/config/example/helloworld.xml</code> config:</p> -<pre><code><configuration description="Runs the hello world test"> +<pre class="prettyprint"> +<configuration description="Runs the hello world test"> <test class="com.android.tradefed.example.HelloWorldTest" /> <result_reporter class="com.android.tradefed.result.XmlResultReporter" /> </configuration> -</code></pre> +</pre> <p>Now rebuild tradefed and re-run the hello world sample:</p> -<pre><code>tf >run example/helloworld +<pre class="devsite-click-to-copy"> +tf> run example/helloworld 05-16 21:07:07 I/TestInvocation: Starting invocation for target stub on build 0 on device 004ad9880810a548 Hello, TF World! I have device 004ad9880810a548 05-16 21:07:07 I/XmlResultReporter: Saved device_logcat log to /tmp/0/inv_2991649128735283633/device_logcat_6999997036887173857.txt @@ -276,7 +298,8 @@ Hello, TF World! I have device 004ad9880810a548 <p>Notice the log message stating that an XML file has been generated; the generated file should look like this:</p> -<pre><code><?xml version='1.0' encoding='UTF-8' ?> +<pre class="prettyprint"> +<?xml version='1.0' encoding='UTF-8' ?> <testsuite name="stub" tests="1" failures="1" errors="0" time="9" timestamp="2011-05-17T04:07:07" hostname="localhost"> <properties /> <testcase name="sampleTest" classname="com.example.TestClassName" time="0"> @@ -284,7 +307,7 @@ generated file should look like this:</p> </failure> </testcase> </testsuite> -</code></pre> +</pre> <p>You can also write your own custom invocation listeners—they simply need to implement the @@ -313,19 +336,21 @@ and sends it to the invocation listener for processing. for the ddmlib Log class. Let's convert the previous <code>System.out.println</code> call in HelloWorldTest to a <code>CLog</code> call:</p> -<pre><code>@Override +<pre class="prettyprint"> +@Override public void run(ITestInvocationListener listener) throws DeviceNotAvailableException { CLog.i("Hello, TF World! I have device %s", getDevice().getSerialNumber()); -</code></pre> +</pre> <p><code>CLog</code> handles string interpolation directly, similar to <code>String.format</code>. When you rebuild and rerun TF, you should see the log message on stdout:</p> -<pre><code>tf> run example/helloworld +<pre class="devsite-click-to-copy"> +tf> run example/helloworld … 05-16 21:30:46 I/HelloWorldTest: Hello, TF World! I have device 004ad9880810a548 … -</code></pre> +</pre> <p>By default, tradefed <a href"/reference/com/android/tradefed/log/StdoutLogger.html">outputs host log @@ -334,7 +359,8 @@ messages to a file: <a href="/reference/com/android/tradefed/log/FileLogger.html">FileLogger</a>. To add file logging, add a <code>logger</code> tag to the config, specifying the full class name of <code>FileLogger</code>:</p> -<pre><code><configuration description="Runs the hello world test"> +<pre class="prettyprint"> +<configuration description="Runs the hello world test"> <test class="com.android.tradefed.example.HelloWorldTest" /> <result_reporter class="com.android.tradefed.result.XmlResultReporter" /> <logger class="com.android.tradefed.log.FileLogger" /> @@ -342,7 +368,8 @@ full class name of <code>FileLogger</code>:</p> </code></pre> <p>Now, rebuild and run the helloworld example again:</p> -<pre><code>tf >run example/helloworld +<pre class="devsite-click-to-copy"> +tf >run example/helloworld … 05-16 21:38:21 I/XmlResultReporter: Saved device_logcat log to /tmp/0/inv_6390011618174565918/device_logcat_1302097394309452308.txt 05-16 21:38:21 I/XmlResultReporter: Saved host_log log to /tmp/0/inv_6390011618174565918/host_log_4255420317120216614.txt @@ -350,10 +377,13 @@ full class name of <code>FileLogger</code>:</p> </code></pre> <p>The log message indicates the path of the host log, which, when viewed, should contain your HelloWorldTest log message:</p> -<pre><code>$ more /tmp/0/inv_6390011618174565918/host_log_4255420317120216614.txt +<pre class="devsite-terminal devsite-click-to-copy"> +more /tmp/0/inv_6390011618174565918/host_log_4255420317120216614.txt</pre> +<p>Example output:</p> +<pre class="devsite-click-to-copy"> … 05-16 21:38:21 I/HelloWorldTest: Hello, TF World! I have device 004ad9880810a548 -</code></pre> +</pre> <h2 id="optionhandling">Handling options (D, I, R)</h2> <p>Objects loaded from a TF Configuration (aka <b>Configuration objects</b>) @@ -371,41 +401,46 @@ description of supported types, see </p> <p>Let's add an <code>@Option</code> to HelloWorldTest:</p> -<pre><code>@Option(name="my_option", +<pre class="prettyprint"> +@Option(name="my_option", shortName='m', description="this is the option's help text", // always display this option in the default help text importance=Importance.ALWAYS) private String mMyOption = "thisisthedefault"; -</code></pre> +</pre> <p>Next, let's add a log message to display the value of the option in HelloWorldTest so we can demonstrate it was received correctly:</p> -<pre><code>@Override +<pre class="prettyprint"> +@Override public void run(ITestInvocationListener listener) throws DeviceNotAvailableException { … CLog.logAndDisplay(LogLevel.INFO, "I received option '%s'", mMyOption); -</code></pre> +</pre> <p>Finally, rebuild TF and run helloworld; you should see a log message with the <code>my_option</code> default value:</p> -<pre><code>tf> run example/helloworld +<pre class="devsite-click-to-copy"> +tf> run example/helloworld … 05-24 18:30:05 I/HelloWorldTest: I received option 'thisisthedefault' -</code></pre> +</pre> <h3 id="passclivalues">Passing values from the command line</h3> <p>Pass in a value for <code>my_option</code>; you should see <code>my_option</code> populated with that value:</p> -<pre><code>tf> run example/helloworld --my_option foo +<pre class="devsite-click-to-copy"> +tf> run example/helloworld --my_option foo … 05-24 18:33:44 I/HelloWorldTest: I received option 'foo' -</code></pre> +</pre> <p>TF configurations also include a help system, which automatically displays help text for <code>@Option</code> fields. Try it now, and you should see the help text for <code>my_option</code>:</p> -<pre><code>tf> run example/helloworld --help +<pre class="devsite-click-to-copy"> +tf> run example/helloworld --help Printing help for only the important options. To see help for all options, use the --help-all flag cmd_options options: @@ -432,21 +467,24 @@ all <code>@Option</code> fields, regardless of importance. For details, see <p>You can also specify an Option value within the config by adding a <code><option name="" value=""></code> element. Test it using <code>helloworld.xml</code>:</p> -<pre><code><test class="com.android.tradefed.example.HelloWorldTest" > +<pre class="prettyprint"> +<test class="com.android.tradefed.example.HelloWorldTest" > <option name="my_option" value="fromxml" /> </test> -</code></pre> +</pre> <p>Re-building and running helloworld should now produce this output:</p> -<pre><code>05-24 20:38:25 I/HelloWorldTest: I received option 'fromxml' -</code></pre> +<pre class="devsite-click-to-copy"> +05-24 20:38:25 I/HelloWorldTest: I received option 'fromxml' +</pre> <p>The configuration help should also update to indicate the default value of <code>my_option</code>:</p> -<pre><code>tf> run example/helloworld --help +<pre class="devsite-click-to-copy"> +tf> run example/helloworld --help test options: -m, --my_option this is the option's help text Default: fromxml. -</code></pre> +</pre> <p>Other configuration objects included in the helloworld config, such as <code>FileLogger</code>, also accept options. The option @@ -458,7 +496,8 @@ logging to stdout by passing in the <code>--log-level-display</code> arg.</p> <p>Try this now, and you should see the 'I have device' log message reappear on stdout, in addition to being logged to a file:</p> -<pre><code>tf >run example/helloworld --log-level-display info +<pre class="devsite-click-to-copy"> +tf> run example/helloworld --log-level-display info … 05-24 18:53:50 I/HelloWorldTest: Hello, TF World! I have device 004ad9880810a548 </code></pre> 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 71dcf5c9..47b99bde 100644 --- a/en/devices/tech/test_infra/tradefed/fundamentals/machine_setup.html +++ b/en/devices/tech/test_infra/tradefed/fundamentals/machine_setup.html @@ -33,7 +33,7 @@ <p> From the root directory of the Android source tree: </p> -<pre> +<pre class="devsite-click-to-copy"> <code class="devsite-terminal">source ./build/make/envsetup.sh</code> <code class="devsite-terminal">lunch <device-target></code> <code class="devsite-terminal">make tradefed-all -j8</code> @@ -44,7 +44,7 @@ <p> TradeFed requires the <code>adb</code> utility in your <code>$PATH</code>: </p> -<pre class="devsite-terminal"> +<pre class="devsite-terminal devsite-click-to-copy"> export PATH=$PATH:<path/to/adb> </pre> @@ -52,7 +52,7 @@ export PATH=$PATH:<path/to/adb> Once TradeFed is built, the <code>tradefed.sh</code> launcher script is accessible from your path. To launch the Trade Federation console: </p> -<pre class="devsite-terminal"> +<pre class="devsite-terminal devsite-click-to-copy"> tradefed.sh </pre> <p> diff --git a/en/devices/tech/test_infra/tradefed/fundamentals/options.html b/en/devices/tech/test_infra/tradefed/fundamentals/options.html index fc494f34..bb891b79 100644 --- a/en/devices/tech/test_infra/tradefed/fundamentals/options.html +++ b/en/devices/tech/test_infra/tradefed/fundamentals/options.html @@ -46,7 +46,8 @@ the TF console when the command is run with <code>--help</code> or <code>--help- <p>As an example, let's say we want to build a functional phone test which will dial a variety of phone numbers, and will expect to receive a sequence of DTMF tones from each number after it connects.</p> -<code><pre>public class PhoneCallFuncTest extends IRemoteTest { +<pre class="prettyprint"> +public class PhoneCallFuncTest extends IRemoteTest { @Option(name = "timeout", description = "How long to wait for connection, in millis") private long mWaitTime = 30 * 1000; // 30 seconds @@ -56,7 +57,8 @@ connects.</p> public PhoneCallFuncTest() { mCalls.add("123-456-7890", "01134"); // default - }</pre></code> + } +</pre> <p>That's all that's required for the Developer to set up two points of configuration for that test. They could then go off and use <code>mWaitTime</code> and <code>mCalls</code> as normal, @@ -73,21 +75,24 @@ suppose the Integrator wanted to define a lower-latency test that calls the defa as a long-running test that calls a variety of numbers. They could create a pair of configurations that might look like the following:</p> -<code><pre><?xml version="1.0" encoding="utf-8"?> +<pre class="prettyprint"> +<?xml version="1.0" encoding="utf-8"?> <configuration description="low-latency default test; low-latency.xml"> <test class="com.example.PhoneCallFuncTest"> <option name="timeout" value="5000" /> </test> -</configuration></pre></code> +</configuration></pre> -<code><pre><?xml version="1.0" encoding="utf-8"?> +<pre class="prettyprint"> +<?xml version="1.0" encoding="utf-8"?> <configuration description="call a bunch of numbers; many-numbers.xml"> <test class="com.example.PhoneCallFuncTest"> <option name="call" key="111-111-1111" value="#*#*TEST1*#*#" /> <option name="call" key="222-222-2222" value="#*#*TEST2*#*#" /> <!-- ... --> </test> -</configuration></pre></code> +</configuration> +</pre> <h2 id="testrunner">Test Runner</h2> <p>The Test Runner also has access to these configuration points via the Trade Federation console. @@ -98,11 +103,14 @@ append to fields specified by Lifecycle Objects within each config.</p> <p>To run the low-latency test with the <code>many-numbers</code> phone numbers, the Test Runner could execute:</p> -<code><pre>tf >run low-latency.xml --call 111-111-1111 #*#*TEST1*#*# --call 222-222-2222 #*#*TEST2*#*#</pre></code> +<pre class="devsite-click-to-copy"> +tf> run low-latency.xml --call 111-111-1111 #*#*TEST1*#*# --call 222-222-2222 #*#*TEST2*#*# +</pre> <p>Or, to get a similar effect from the opposite direction, the Test Runner could reduce the wait time for the <code>many-numbers</code> test:</p> -<code><pre>tf >run many-numbers.xml --timeout 5000</code></pre> +<pre class="devsite-click-to-copy"> +tf> run many-numbers.xml --timeout 5000</pre> </body> </html> diff --git a/en/devices/tech/test_infra/tradefed/fundamentals/vts.html b/en/devices/tech/test_infra/tradefed/fundamentals/vts.html index 473db22f..8ba912d8 100644 --- a/en/devices/tech/test_infra/tradefed/fundamentals/vts.html +++ b/en/devices/tech/test_infra/tradefed/fundamentals/vts.html @@ -31,27 +31,41 @@ then test a patch using a VTS plan.</p> <p>To set up a testing environment:</p> <ol> <li>Install Python development kit: -<pre><code>$ sudo apt-get install python-dev</code></pre></li> +<pre class="devsite-terminal devsite-click-to-copy"> +sudo apt-get install python-dev +</pre> +</li> <li>Install Protocol Buffer tools (for Python): -<pre><code>$ sudo apt-get install python-protobuf<br> -$ sudo apt-get install protobuf-compiler -</code></pre></li> +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">sudo apt-get install python-protobuf</code> +<code class="devsite-terminal">sudo apt-get install protobuf-compiler</code> +</pre> +</li> <li>Install Python virtual environment-related tools: -<pre><code>$ sudo apt-get install python-virtualenv<br> -$ sudo apt-get install python-pip -</code></pre></li></ol> +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">sudo apt-get install python-virtualenv</code> +<code class="devsite-terminal">sudo apt-get install python-pip</code> +</pre> +</li> +</ol> <h2 id="test">Testing a patch</h2> <p>To test a patch:</p> <ol> <li>Build a VTS host-side package: -<pre><code>$ . build/envsetup.sh -$ lunch aosp_arm64-userdebug -$ make vts -j</code></pre></li> +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">. build/envsetup.sh</code> +<code class="devsite-terminal">lunch aosp_arm64-userdebug</code> +<code class="devsite-terminal">make vts -j</code> +</pre> +</li> <li>Run the default VTS tests: -<pre><code>$ vts-tradefed<br> -> run vts // where vts is the test plan name -</pre></code></li></ol> +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">vts-tradefed</code> +tf> run vts // where vts is the test plan name +</pre> +</li> +</ol> <h2 id="plans">VTS plans</h2> <p>Available VTS test plans include:</p> diff --git a/en/devices/tv/hdmi-cec.html b/en/devices/tv/hdmi-cec.html index 942626a5..6510901d 100644 --- a/en/devices/tv/hdmi-cec.html +++ b/en/devices/tv/hdmi-cec.html @@ -70,7 +70,7 @@ specifies.</p> controller to an implementation of the simpler HDMI-CEC hardware abstraction layer (HAL).</p> -<img src="images/HDMI_Control_Service.png" alt="Diagram that shows how HDMI-CEC was implemented before and after Android 5.0"> +<img src="/devices/tv/images/HDMI_Control_Service.png" alt="Diagram that shows how HDMI-CEC was implemented before and after Android 5.0"> <p class="img-caption"><strong>Figure 1.</strong> HDMI Control Service replacement</p> @@ -79,7 +79,7 @@ layer (HAL).</p> <p>See the following diagram for a detailed view of the HDMI control service.</p> -<img src="images/HDMI_Control_Service_Flow.png" alt="Image that shows how HDMI Control service details"> +<img src="/devices/tv/images/HDMI_Control_Service_Flow.png" alt="Image that shows how HDMI Control service details"> <p class="img-caption"><strong>Figure 2.</strong> HDMI Control Service details</p> @@ -96,7 +96,7 @@ to use to implement the HAL layer.</li> <p class="note"><strong>Note</strong>: Device manufacturers should add the following line into <code>PRODUCT_COPY_FILES</code> in <code>device.mk</code>.</p> -<pre> +<pre class="devsite-click-to-copy"> PRODUCT_COPY_FILES += \ frameworks/native/data/etc/android.hardware.hdmi.cec.xml:system/etc/permissions/android.hardware.hdmi.cec.xml </pre> @@ -107,13 +107,13 @@ device manufacturers need to set <code>ro.hdmi.device_type</code> in <code>devic <p>For HDMI source devices, like Over the Top (OTT) boxes, set:</p> -<pre> +<pre class="devsite-click-to-copy"> PRODUCT_PROPERTY_OVERRIDES += ro.hdmi.device_type=<strong>4</strong> </pre> <p>For HDMI sink devices, like panel TVs, set:</p> -<pre> +<pre class="devsite-click-to-copy"> PRODUCT_PROPERTY_OVERRIDES += ro.hdmi.device_type=<strong>0</strong></pre> </p> @@ -169,7 +169,7 @@ etc.) to the upper layer through API.</p> <p>Here is an excerpt of the HDMI-CEC HAL definition regarding APIs:</p> -<pre> +<pre class="devsite-click-to-copy"> #ifndef ANDROID_INCLUDE_HARDWARE_HDMI_CEC_H #define ANDROID_INCLUDE_HARDWARE_HDMI_CEC_H diff --git a/en/devices/tv/reference-tv-app.html b/en/devices/tv/reference-tv-app.html index 1989e0df..db4b1763 100644 --- a/en/devices/tv/reference-tv-app.html +++ b/en/devices/tv/reference-tv-app.html @@ -84,10 +84,10 @@ easily select an earlier version by changing the branch from master to a different one listed in the table above.</p> -<pre> -$ mkdir live-tv && cd live-tv -$ repo init -u <a href="https://android.googlesource.com/platform/manifest">https://android.googlesource.com/platform/manifest</a> -b master -$ repo sync -j8 -c +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">mkdir live-tv && cd live-tv</code> +<code class="devsite-terminal">repo init -u <a href="https://android.googlesource.com/platform/manifest">https://android.googlesource.com/platform/manifest</a> -b master</code> +<code class="devsite-terminal">repo sync -j8 -c</code> </pre> @@ -96,10 +96,10 @@ $ repo sync -j8 -c <p>To build the Live TV code, run:</p> -<pre> -$ . build/envsetup.sh -$ tapas LiveTv x86 -$ make LiveTv +<pre class="devsite-click-to-copy"> +<code class="devsite-terminal">. build/envsetup.sh</code> +<code class="devsite-terminal">apas LiveTv x86</code> +<code class="devsite-terminal">make LiveTv</code> </pre> @@ -108,14 +108,16 @@ $ make LiveTv <p>To push Live TV to your test device:</p> -<pre> -$ adb install -r -d $OUT/system/priv-app/LiveTv/LiveTv.apk +<pre class="devsite-terminal devsite-click-to-copy"> +adb install -r -d $OUT/system/priv-app/LiveTv/LiveTv.apk </pre> <p>If the developer wants the LIVE TV app to have system permissions, the first time it is installed it needs to be pushed to /system/priv-app with:</p> -<pre>adb push $OUT/system/priv-app/LiveTv/LiveTv.apk /system/priv-app/LiveTv/</pre> +<pre class="devsite-terminal devsite-click-to-copy"> +adb push $OUT/system/priv-app/LiveTv/LiveTv.apk /system/priv-app/LiveTv/ +</pre> <h2 id=test>Test</h2> @@ -129,8 +131,8 @@ integrated. In addition to running the <a href="/compatibility/cts/index.html">C <p>There are unit and functional tests for the Live TV app. You must have a device (or emulator) connected to run the tests.</p> -<pre> -$ adb shell logcat -c +<pre class="devsite-terminal devsite-click-to-copy"> +adb shell logcat -c m LiveTv TVTestInput TVUnitTests -j20 &&\ adb install -r -d $OUT/system/priv-app/LiveTv/LiveTv.apk &&\ adb install -r -d $OUT/system/app/TVTestInput/TVTestInput.apk && \ @@ -148,7 +150,7 @@ adb shell am instrument \ <h3 id=functional_tests>Functional Tests</h3> -<pre> +<pre class="devsite-terminal devsite-click-to-copy"> $ adb shell logcat -c m LiveTv TVTestInput TVFuncTests -j20 &&\ adb install -r -d $OUT/system/priv-app/LiveTv/LiveTv.apk &&\ @@ -170,7 +172,7 @@ adb shell am instrument \ <p>The Jank tests look for dropped frames and delays in rendering.</p> -<pre> +<pre class="devsite-terminal devsite-click-to-copy"> $ adb shell logcat -c m LiveTv TVTestInput TVJankTests -j20 &&\ adb install -r -d $OUT/system/priv-app/LiveTv/LiveTv.apk &&\ diff --git a/en/security/overview/acknowledgements.html b/en/security/overview/acknowledgements.html index 7524e93e..1460e75d 100644 --- a/en/security/overview/acknowledgements.html +++ b/en/security/overview/acknowledgements.html @@ -71,13 +71,13 @@ of <a href="http://c0reteam.org">C0RE Team</a></p> <p>Daxing Guo (<a href="https://twitter.com/freener0">@freener0</a>) of Xuanwu Lab, Tencent</p> - + <p><a href="mailto:derrek.haxx@gmail.com">derrek</a> (<a href="https://twitter.com/derrekr6">@derrekr6</a>)</p> - + <p>Di Shen (<a href="https://twitter.com/returnsme">@returnsme</a>) of KeenLab (<a href="https://twitter.com/keen_lab">@keen_lab</a>), Tencent</p> - + <p>donfos (Aravind Machiry) of Shellphish Grill Team, UC Santa Barbara</p> <p><a href="http://www.linkedin.com/in/dzima">Dzmitry Lukyanenka</a></p> @@ -136,7 +136,7 @@ href="https://skyeye.360safe.com">Qihoo 360 Skyeye Labs</a></p> <p>Jianqiang Zhao (<a href="https://twitter.com/jianqiangzhao">@jianqiangzhao</a>) of IceSword Lab, Qihoo 360</p> - + <p>Jon Sawyer (<a href="http://twitter.com/jcase">@jcase</a>)</p> <p>Juhu Nie of Xiaomi Inc.</p> @@ -192,10 +192,10 @@ of Tesla Motors Product Security Team</p> <p>Peter Pi (<a href="https://twitter.com/heisecode">@heisecode</a>) of Trend Micro</p> - + <p><a href="http://weibo.com/jfpan">pjf</a> of IceSword Lab, Qihoo 360 Technology Co. Ltd.</p> - + <p>Qidan He (何淇丹) (<a href="https://twitter.com/flanker_hqd">@flanker_hqd</a>) of KeenLab, Tencent (腾讯科恩实验室)</p> @@ -204,8 +204,8 @@ of Tesla Motors Product Security Team</p> <p>Qiwu Huang of Xiaomi Inc.</p> <p>Quhe of Ant-financial Light-Year Security Lab (蚂蚁金服巴斯光年安全实验室)</p> - -<p>Roee Hay of IBM Security X-Force</p> + +<p>Roee Hay of <a href="https://alephsecurity.com/">Aleph Research</a>, HCL Technologies</p> <p>Sagi Kedmi of IBM X-Force Research</p> @@ -226,7 +226,7 @@ Shellphish Grill Team, UC Santa Barbara</p> <p><a href="mailto:smarques84@gmail.com">Stéphane Marques</a> of <a href="http://www.byterev.com">ByteRev</a></p> - + <p>Stephen Morrow</p> <p>Svetoslav Ganov of Google</p> @@ -244,10 +244,10 @@ of <a href="http://c0reteam.org">C0RE Team</a></p> Research Team, <a href="http://www.trendmicro.com">Trend Micro</a></p> <p>wanchouchou of Ant-financial Light-Year Security Lab (蚂蚁金服巴斯光年安全实验室)</p> - + <p>Weichao Sun (<a href="https://twitter.com/sunblate">@sunblate</a>) of Alibaba Inc.</p> - + <p><a href="mailto:vancouverdou@gmail.com">Wenke Dou</a> of <a href="http://c0reteam.org">C0RE Team</a></p> @@ -257,7 +257,7 @@ of Alpha Team, Qihoo 360 Technology Co. Ltd.</p> <p>Wish Wu (<a href="https://twitter.com/wish_wu">@wish_wu</a>) (<a href="http://www.weibo.com/wishlinux">吴潍浠</a> 此彼) of Ant-financial Light-Year Security Lab</p> - + <p><a href="mailto:wisedd@gmail.com">Xiaodong Wang</a> of <a href="http://c0reteam.org">C0RE Team</a></p> @@ -278,7 +278,7 @@ of <a href="http://c0reteam.org">C0RE Team</a></p> <p><a href="mailto:yaojun8558363@gmail.com">Yao Jun</a> of <a href="http://c0reteam.org">C0RE Team</a></p> - + <p>Yong Wang (王勇) (<a href="https://twitter.com/ThomasKing2014">@ThomasKing2014</a>) of Alibaba Inc.</p> @@ -288,7 +288,7 @@ of <a href="http://c0reteam.org">C0RE Team</a></p> <p>Dr. Yossi Oren of Ben Gurion University Cyber Lab</p> <p>Yu Pan of Vulpecker Team, Qihoo 360 Technology Co. Ltd</p> - + <p><a href="mailto:computernik@gmail.com">Yuan-Tsung Lo</a> of <a href="http://c0reteam.org">C0RE Team</a></p> @@ -297,14 +297,14 @@ of <a href="http://c0reteam.org">C0RE Team</a></p> <p>Yuxiang Li (<a href="https://twitter.com/xbalien29">@Xbalien29</a>) of Tencent Security Platform Department</p> - + <p>Zhanpeng Zhao (行之) (<a href="https://twitter.com/0xr0ot">@0xr0ot</a>) of Security Research Lab, <a href="http://www.cmcm.com/">Cheetah Mobile</a></p> <p><a href="mailto:zhouzhenster@gmail.com">Zhen Zhou</a> ( <a href="https://twitter.com/henices">@henices</a>) of <a href="http://www.nsfocus.com">NSFocus</a></p> - + <p><a href="mailto:sundaywind2004@gmail.com">Zhixin Li</a> of <a href="http://www.nsfocus.com">NSFocus</a></p> @@ -314,7 +314,7 @@ of <a href="http://c0reteam.org">C0RE Team</a></p> <p>Zubin Mithra of Google</p> </div> - + <h2 id="2016">2016</h2> <div style="LINE-HEIGHT:25px;"> diff --git a/en/source/jack.html b/en/source/jack.html index 7c3e952d..b7f3f5ab 100644 --- a/en/source/jack.html +++ b/en/source/jack.html @@ -28,9 +28,10 @@ <p class="warning"> <b>The Jack toolchain is deprecated</b>, as per <a href="https://android-developers.googleblog.com/2017/03/future-of-java-8-language-feature.html"> - this announcement</a>. However, you may continue to use it to - <a href="https://developer.android.com/preview/j8-jack.html">enable Java 8 language features</a> - until the replacement is available. + this announcement</a>. You may continue to use it or try the latest + <a href="https://developer.android.com/studio/preview/index.html">preview version of + Android Studio</a>, which provides improved support for <a href="https://developer.android.com/studio/preview/features/java8-support.html"> + Java 8 language features built into the default toolchain</a>. </p> <p>Jack is an Android toolchain that compiles Java |