Merge "Docs: Changes to source.android.com"android-o-mr1-iot-release-1.0.8

43 files changed, 3860 insertions, 811 deletions

diff --git a/en/_index.yaml b/en/_index.yaml
index 1694a614..e5e42f7b 100644
--- a/en/_index.yaml
+++ b/en/_index.yaml
@@ -45,10 +45,10 @@ landing_page:
     items:
     - heading: About the Android Open Source Project
       description: |
-        Android is an open source software stack for mobile devices and a
+        Android is an open source operating system for mobile devices and a
         corresponding open source project led by Google. This site and the
         Android Open Source Project (AOSP) repository offer the information and
-        source code needed to create custom variants of the Android stack, port
+        source code needed to create custom variants of the Android OS, port
         devices and accessories to the Android platform, and ensure devices meet
         the compatibility requirements that keep the Android ecosystem a healthy
         and stable environment for millions of users.
@@ -77,30 +77,29 @@ landing_page:
       image_path: /images/android_stack.png
   - heading: News
     items:
-    - heading: November Security Bulletins
+    - heading: Continuous Integration Dashboard
       description: >
-        The November 2018 Android and Pixel/Nexus Security Bulletins have been
-        published along with links to associated fixes and new build numbers
-        to support the November security release.
+        The Android Open Source Project (AOSP) has published its continuous integration
+        dashboard.
       buttons:
-      - label: November 5th, 2018
-        path: /security/bulletin/2018-11-01
-    - heading: Platform Testing Overview
+      - label: December 14th, 2018
+        path: /setup/build/dashboard
+    - heading: December Security Bulletins
       description: >
-        The Tests section now contains a thorough introduction
-        to all primary test types with end-to-end examples employing the new Soong build system. See
-        the Test Development Workflow.
+        The December 2018 Android and Pixel/Nexus Security Bulletins have been
+        published along with links to associated fixes and new build numbers
+        to support the December security release.
       buttons:
-      - label: November 1st, 2018
-        path: /compatibility/tests
-    - heading: Android 9 Documentation
+      - label: December 5th, 2018
+        path: /security/bulletin/2018-12-01
+    - heading: Test Mapping Made Easy
       description: >
-        Android 9 has been released! This site includes documentation for
-        implementing the features, improvements, and enhancements
-        in the newest version of Android.
+        Test Mapping is a Gerrit-based approach that allows developers to create pre- and
+        post-submit test rules directly in the Android source tree and leave branch and device
+        selection to the test infrastructure.
       buttons:
-      - label: August 6th, 2018
-        path: /setup/start/p-release-notes
+      - label: December 4th, 2018
+        path: /compatibility/tests/development/test-mapping
   - classname: devsite-landing-row-100 tf-row-centered
     items:
     - buttons:
diff --git a/en/compatibility/_toc-compatibility.yaml b/en/compatibility/_toc-compatibility.yaml
index 20f2abb3..3ce35262 100644
--- a/en/compatibility/_toc-compatibility.yaml
+++ b/en/compatibility/_toc-compatibility.yaml
@@ -3,7 +3,77 @@ toc:
   path: /compatibility/overview
 - title: Compatibility Definition Document
   path: /compatibility/cdd/
-- title: CDD in HTML
-  path: /compatibility/android-cdd
-- title: CDD in PDF
-  path: /compatibility/android-cdd.pdf
+- title: CDDs in HTML
+  section:
+  - title: Android 9 (current)
+    path: /compatibility/9/android-9-cdd
+  - title: Android 8.1
+    path: /compatibility/8.1/android-8.1-cdd
+  - title: Android 8.0
+    path: /compatibility/8.0/android-8.0-cdd
+  - title: Android 7.1
+    path: /compatibility/7.1/android-7.1-cdd
+  - title: Android 7.0
+    path: /compatibility/7.0/android-7.0-cdd
+  - title: Android 6.0
+    path: /compatibility/6.0/android-6.0-cdd
+  - title: Android 5.1
+    path: /compatibility/5.1/android-5.1-cdd
+  - title: Android 5.0
+    path: /compatibility/5.0/android-5.0-cdd
+  - title: Android 4.4
+    path: /compatibility/4.4/android-4.4-cdd
+  - title: Android 4.3
+    path: /compatibility/4.3/android-4.3-cdd
+  - title: Android 4.2
+    path: /compatibility/4.2/android-4.2-cdd
+  - title: Android 4.1
+    path: /compatibility/4.1/android-4.1-cdd
+  - title: Android 4.0
+    path: /compatibility/4.0/android-4.0-cdd
+  - title: Android 2.3
+    path: /compatibility/2.3/android-2.3-cdd
+  - title: Android 2.2
+    path: /compatibility/2.2/android-2.2-cdd
+  - title: Android 2.1
+    path: /compatibility/2.1/android-2.1-cdd
+  - title: Android 1.6
+    path: /compatibility/1.6/android-1.6-cdd
+- title: CDDs as PDF
+  section:
+  - title: Android 9 (current)
+    path: /compatibility/9/android-9-cdd.pdf
+  - title: Android 8.1
+    path: /compatibility/8.1/android-8.1-cdd.pdf
+  - title: Android 8.0
+    path: /compatibility/8.0/android-8.0-cdd.pdf
+  - title: Android 7.1
+    path: /compatibility/7.1/android-7.1-cdd.pdf
+  - title: Android 7.0
+    path: /compatibility/7.0/android-7.0-cdd.pdf
+  - title: Android 6.0
+    path: /compatibility/6.0/android-6.0-cdd.pdf
+  - title: Android 5.1
+    path: /compatibility/5.1/android-5.1-cdd.pdf
+  - title: Android 5.0
+    path: /compatibility/5.0/android-5.0-cdd.pdf
+  - title: Android 4.4
+    path: /compatibility/4.4/android-4.4-cdd.pdf
+  - title: Android 4.3
+    path: /compatibility/4.3/android-4.3-cdd.pdf
+  - title: Android 4.2
+    path: /compatibility/4.2/android-4.2-cdd.pdf
+  - title: Android 4.1
+    path: /compatibility/4.1/android-4.1-cdd.pdf
+  - title: Android 4.0
+    path: /compatibility/4.0/android-4.0-cdd.pdf
+  - title: Android 2.3
+    path: /compatibility/2.3/android-2.3-cdd.pdf
+  - title: Android 2.3.3
+    path: /compatibility/2.3/android-2.3.3-cdd.pdf
+  - title: Android 2.2
+    path: /compatibility/2.2/android-2.2-cdd.pdf
+  - title: Android 2.1
+    path: /compatibility/2.1/android-2.1-cdd.pdf
+  - title: Android 1.6
+    path: /compatibility/1.6/android-1.6-cdd.pdf
diff --git a/en/compatibility/_toc-tests.yaml b/en/compatibility/_toc-tests.yaml
index 03c550c7..6d9d575f 100644
--- a/en/compatibility/_toc-tests.yaml
+++ b/en/compatibility/_toc-tests.yaml
@@ -27,6 +27,10 @@ toc:
       path: /compatibility/tests/development/metrics.md
   - title: JAR Host Tests
     path: /compatibility/tests/development/jar.md
+  - title: Mapping Tests
+    path: /compatibility/tests/development/test-mapping
+  - title: Running Tests (Atest)
+    path: /compatibility/tests/development/atest
 - title: Compatibility Test Suite (CTS)
   section:
   - title: Overview
diff --git a/en/compatibility/_translation.yaml b/en/compatibility/_translation.yaml
index b458dee8..320f9ed7 100644
--- a/en/compatibility/_translation.yaml
+++ b/en/compatibility/_translation.yaml
@@ -17,6 +17,7 @@ ignore_paths:
 - /compatibility/8.1/...
 - /compatibility/images/...
 - /compatibility/source/...
+- /compatibility/android-cdd
 enable_continuous_translation: true
 title: Android Open Source Project Compatibility tab
 description: Translations for SAC compatibility tab
@@ -25,5 +26,5 @@ language:
 cc:
 - sac-doc-leads+translation@google.com
 reviewer:
-- daroberts@google.com
+- gdimino@google.com
 product: Android
diff --git a/en/compatibility/cts/audio-framework.html b/en/compatibility/cts/audio-framework.html
index 81d69a75..d0aa2ad1 100644
--- a/en/compatibility/cts/audio-framework.html
+++ b/en/compatibility/cts/audio-framework.html
@@ -353,7 +353,7 @@ have a solid reference to compare the built in microphone against.</p>
  </tr>
 </table>
 
-<h2>Audio Frequency Unprocessed Test</h2>
+<h2>Audio frequency unprocessed test</h2>
 <p>
 For this test, in addition to the USB reference microphone and external
 speakers, it is necessary to have access to a Sound Pressure Level Meter (SPL
diff --git a/en/compatibility/cts/secure-element.md b/en/compatibility/cts/secure-element.md
index 86f8d68f..01ea9e18 100644
--- a/en/compatibility/cts/secure-element.md
+++ b/en/compatibility/cts/secure-element.md
@@ -172,7 +172,7 @@ applet with the following application identifiers (AIDs):
         </tr>
         <tr>
         <td>0x00F30E06</td>
-        <td>0x6282</td>
+        <td>0x6286</td>
         <td>No</td>
         </tr>
         <tr>
@@ -252,7 +252,7 @@ applet with the following application identifiers (AIDs):
         </tr>
         <tr>
         <td>0x00F30E0A01AA</td>
-        <td>0x6282</td>
+        <td>0x6286</td>
         <td>No</td>
         </tr>
         <tr>
@@ -332,7 +332,7 @@ applet with the following application identifiers (AIDs):
         </tr>
         <tr>
         <td>0x00F30E0800</td>
-        <td>0x6282</td>
+        <td>0x6286</td>
         <td>Yes</td>
         </tr>
         <tr>
@@ -412,7 +412,7 @@ applet with the following application identifiers (AIDs):
         </tr>
         <tr>
         <td>0x00F30E0C01AA00</td>
-        <td>0x6282</td>
+        <td>0x6286</td>
         <td>Yes*</td>
         </tr>
         <tr>
@@ -467,12 +467,12 @@ applet with the following application identifiers (AIDs):
         <tr>
         <td>0x00C27FFF00</td>
         <td>0x9000</td>
-        <td>2048</td>
+        <td>32767</td>
         </tr>
         <tr>
         <td>0x00CF080000</td>
         <td>0x9000</td>
-        <td>32767</td>
+        <td>2048</td>
         </tr>
         <tr>
         <td>0x94C2080000</td>
@@ -482,9 +482,9 @@ applet with the following application identifiers (AIDs):
         </tbody>
         </table>
       </li>
-      <li>The applet should return success status word <code>0x9000</code> for
-      the given
-        APDU: 0x00F40000</li>
+      <li>The applet should return the value of P2 received in the SELECT
+      command + the success status word (i.e <code>0x009000</code>) for the given
+      APDU: 0x00F4000000</li>
     </ol>
   <li>A000000476416E64726F696443545332
     <ol>
@@ -527,6 +527,9 @@ Create an instance of the applet under these AIDs:
 -   0xA000000476416E64726F69644354534E
 -   0xA000000476416E64726F69644354534F
 
+When selected, any of these AIDs should return a select response greater than
+2 bytes that are correctly formatted using BER and TLV.
+
 ### `CtsSecureElementAccessControlTestCases1`
 
 -   **Hash of the APK:** 0x4bbe31beb2f753cfe71ec6bf112548687bb6c34e
@@ -768,7 +771,7 @@ Run installation command for each applet.
 
 Command to install applet
 
-<code>80E60C00300C6F6D617069636172646C65740B<var>module_AID</var>10<var>AID</var>010002C90000</code><br>
+<code>80E60C00300C6F6D617069636172646C65740B<var>module_AID</var>10<var>AID</var>01000EEF0AA008810101A5038201C0C9000000</code><br>
 **Module_AID**: 6F 6D 61 70 69 4A 53 52 31 37 37  
 **AID:** A000000476416E64726F696443545331
 
@@ -778,7 +781,7 @@ Command to install applet
 
 ##### AccessControl tests (template using PKCS#15 structure)
 
-<code>80E60C003C0C6F6D617069636172646C65740B<var>module_AID</var>10<var>AID</var>01000EEF0AA008810101A5038201C0C90000</code><br>
+<code>80E60C003C0C6F6D617069636172646C65740B<var>module_AID</var>10<var>AID</var>01000EEF0AA008810101A5038201C0C9000000</code><br>
 **Module_AID**: 6F 6D 61 70 69 4A 53 52 31 37 37
 
 **AIDs:**
diff --git a/en/compatibility/tests/development/atest.md b/en/compatibility/tests/development/atest.md
new file mode 100644
index 00000000..8c3fe385
--- /dev/null
+++ b/en/compatibility/tests/development/atest.md
@@ -0,0 +1,418 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+{% include "_versions.html" %}
+
+<!--
+  Copyright 2018 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.
+-->
+
+# Atest
+
+Atest is a command line tool that allows users to build, install, and run
+Android tests locally, greatly speeding test re-runs without requiring knowledge
+of [Trade Federation test harness](/devices/tech/test_infra/tradefed) command
+line options. This page explains how to use Atest to run Android tests.
+
+For general information on writing tests for Android, see
+[Android Platform Testing](/compatibility/tests/index.md).
+
+For information on the overall structure of Atest, see
+[Atest Developer Guide](https://android.googlesource.com/platform/tools/tradefederation/+/master/atest/docs/atest_structure.md){: .external}.
+
+And to add a feature to Atest, follow
+[Atest Developer Workflow](https://android.googlesource.com/platform/tools/tradefederation/+/master/atest/docs/developer_workflow.md){: .external}.
+
+## Setting up your environment
+
+To run Atest, follow the steps in the sections below to set up your environment.
+
+### Set environment variable
+
+Set test_suite for [Soong](/compatibility/tests/development/blueprints) or
+LOCAL_COMPATIBILITY_SUITE for Make per
+[Packaging build script rules](/compatibility/tests/development/test-mapping#packaging_build_script_rules).
+
+### 1. Run envsetup.sh
+
+From the root of the Android source checkout, run:
+
+<pre>
+<code class="devsite-terminal">source build/envsetup.sh</code>
+</pre>
+
+### 2. Run lunch
+
+Run the `$ lunch` command to bring up a menu of supported devices. Find the
+device and run that command.
+
+For example, if you have an ARM device connected, run the following command:
+
+<pre>
+<code class="devsite-terminal">lunch aosp_arm64-eng</code>
+</pre>
+
+This sets various environment variables required for running Atest and adds the
+Atest command to your `$PATH`.
+
+## Basic usage
+
+Atest commands take the following form:
+
+<pre>
+<code class="devsite-terminal">atest [<var>optional-arguments</var>] <var>test-to-run</var></code>
+</pre>
+
+### Optional arguments
+
+You can use the following optional arguments with Atest commands.
+
+| Option | Long option              | Description                              |
+| :----: | :----------------------- | ---------------------------------------- |
+| `-b`   | `--build`                | Builds test targets.                     |
+| `-i`   | `--install`              | Installs test artifacts (APKs) on        |
+:        :                          : device.                                  :
+| `-t`   | `--test`                 | Runs the tests.                          |
+| `-s`   | `--serial`               | Runs the tests on the specified device.  |
+:        :                          : One device can be tested at a time.      :
+| `-d`   | `--disable-teardown`     | Disables test teardown and cleanup.      |
+| <c>    | `--info`                 | Shows the relevant info of the specified |
+:        :                          : targets and exits.                       :
+| <c>    | `--dry-run`              | A synonym of --info.                     |
+| `-m`   | `--rebuild-module-info`  | Forces a rebuild of the module-info.json |
+:        :                          : file.                                    :
+| `-w`   | `--wait-for-debugger`    | Waits for debugger prior to execution.   |
+:        :                          : Only for instrumentation tests.          :
+| `-v`   | `--verbose`              | Displays DEBUG level logging.            |
+| <c>    | `--generate-baseline`    | Generates baseline metrics, runs 5       |
+:        :                          : iterations by default.                   :
+| <c>    | `--generate-new-metrics` | Generates new metrics, run 5 iterations  |
+:        :                          : by default.                              :
+| <c>    | `--detect-regression`    | Runs regression detection algorithm.     |
+| <c>    | `--[CUSTOM_ARGS]`        | Specifies custom args for the test       |
+:        :                          : runners.                                 :
+| `-a`   | `--all-abi`              | Runs the tests for all available device  |
+:        :                          : architectures.                           :
+| `-h`   | `--help`                 | Shows help message and exits.            |
+| <c>    | `--host`                 | Runs the test completely on the host     |
+:        :                          : without a device.<br>(Note\: Running a   :
+:        :                          : host test that requires a device with    :
+:        :                          : --host will fail.)                       :
+
+For more information on `-b`, `-i` and `-t`, see
+[Specifying steps: build, install, or run.](#specifying_steps_build_install_or_run)
+
+### Tests to run
+
+You can run one or more tests using <var>test-to-run</var>. To run multiple
+tests, separate test references with spaces. For example:
+
+<pre>
+<code class="devsite-terminal">atest <var>test-to-run-1</var> <var>test-to-run-2</var></code>
+</pre>
+
+Here are some examples:
+
+<pre>
+<code class="devsite-terminal">atest FrameworksServicesTests</code>
+<code class="devsite-terminal">atest example/reboot</code>
+<code class="devsite-terminal">atest FrameworksServicesTests CtsJankDeviceTestCases</code>
+<code class="devsite-terminal">atest FrameworksServicesTests:ScreenDecorWindowTests</code>
+</pre>
+
+For more information on how to reference a test, see
+[Identifying tests.](#identifying_tests)
+
+## Identifying tests
+
+You can specify the <var>test-to-run</var> argument with the test's module name,
+Module:Class, class name, TF integration test, file path or package name.
+
+### Module name
+
+To run an entire test module, use its module name. Input the name as it appears
+in the `LOCAL_MODULE` or `LOCAL_PACKAGE_NAME` variables in that test's
+`Android.mk` or `Android.bp` file.
+
+Note: Use **TF Integration Test** to run non-module tests integrated directly
+into TradeFed.
+
+Examples:
+
+<pre>
+<code class="devsite-terminal">atest FrameworksServicesTests</code>
+<code class="devsite-terminal">atest CtsJankDeviceTestCases</code>
+</pre>
+
+### Module:Class
+
+To run a single class within a module, use **Module:Class**. **Module** is the
+same as described in [Module name](#module_name). **Class** is the name of the
+test class in the `.java` file and can be the fully qualified class name or the
+basic name.
+
+Examples:
+
+<pre>
+<code class="devsite-terminal">atest FrameworksServicesTests:ScreenDecorWindowTests</code>
+<code class="devsite-terminal">atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests</code>
+<code class="devsite-terminal">atest CtsJankDeviceTestCases:CtsDeviceJankUi</code>
+</pre>
+
+### Class name
+
+To run a single class without explicitly stating a module name, use the class
+name.
+
+Examples:
+
+<pre>
+<code class="devsite-terminal">atest ScreenDecorWindowTests</code>
+<code class="devsite-terminal">atest CtsDeviceJankUi</code>
+</pre>
+
+Using the **Module:Class** reference is recommended whenever possible since
+Atest requires more time to search the complete source tree for potential
+matches if no module is stated.
+
+Examples (ordered from fastest to slowest):
+
+<pre>
+<code class="devsite-terminal">atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests</code>
+<code class="devsite-terminal">atest FrameworksServicesTests:ScreenDecorWindowTests</code>
+<code class="devsite-terminal">atest ScreenDecorWindowTests</code>
+</pre>
+
+### TF integration test
+
+To run tests that are integrated directly into TradeFed (non-modules), input the
+name as it appears in the output of the `tradefed.sh list configs` command. For
+example:
+
+To run the
+[`reboot.xml` test](https://android.googlesource.com/platform/tools/tradefederation/contrib/+/master/res/config/example/reboot.xml){: .external}:
+
+<pre>
+<code class="devsite-terminal">atest example/reboot</code>
+</pre>
+
+To run the
+[`native-benchmark.xml` test](https://android.googlesource.com/platform/tools/tradefederation/+/master/res/config/native-benchmark.xml){: .external}:
+
+<pre>
+<code class="devsite-terminal">atest native-benchmark</code>
+</pre>
+
+### File path
+
+You can run both module-based tests and integration-based tests by inputting the
+path to their test file or directory as appropriate. You can also run a single
+class by specifying the path to the class's Java file. Both relative and
+absolute paths are supported.
+
+Example: Two ways to run the `CtsJankDeviceTestCases` module via path
+
+1.  Run module from android <var>repo-root</var>:
+
+    <pre>
+    <code class="devsite-terminal">atest cts/tests/jank</code>
+    </pre>
+
+2.  From android <var>repo-root</var>/cts/tests/jank:
+
+    <pre>
+    <code class="devsite-terminal">atest .</code>
+    </pre>
+
+Example: Run a specific class within `CtsJankDeviceTestCases` module via path.
+From android <var>repo-root</var>:
+
+<pre>
+<code class="devsite-terminal">atest cts/tests/jank/src/android/jank/cts/ui/CtsDeviceJankUi.java</code>
+</pre>
+
+Example: Run an integration test via path. From android <var>repo-root</var>:
+
+<pre>
+<code class="devsite-terminal">atest tools/tradefederation/contrib/res/config/example/reboot.xml</code>
+</pre>
+
+### Package name
+
+Atest supports searching tests by package name.
+
+Examples:
+
+<pre>
+<code class="devsite-terminal">atest com.android.server.wm</code>
+<code class="devsite-terminal">atest android.jank.cts</code>
+</pre>
+
+## Specifying steps: Build, install, or run
+
+You can specify which steps to run by using the `-b`, `-i`, and `-t` options. If
+you don't specify an option, then all steps run.
+
+Note: You can run `-b` and `-t` alone, but `-i` needs `-t` to run.
+
+-   Build targets only: <code>atest -b <var>test-to-run</var></code>
+-   Run tests only: <code>atest -t <var>test-to-run</var></code>
+-   Install apk and run tests: <code>atest -it <var>test-to-run</var></code>
+-   Build and run, but don't install: <code>atest -bt
+    <var>test-to-run</var></code>
+
+Atest can force a test to skip the cleanup/teardown step. Many tests, such as
+CTS, clean up the device after the test is run, so trying to rerun your test
+with `-t` will fail without the `--disable-teardown` parameter. Use `-d` before
+`-t` to skip the test clean up step and test iteratively.
+
+<pre>
+<code class="devsite-terminal">atest -d <var>test-to-run</var></code>
+<code class="devsite-terminal">atest -t <var>test-to-run</var></code>
+</pre>
+
+Note: `-t` disables both **setup/install** and **teardown/cleanup** of the
+device so you can rerun your test with <code>atest -t
+<var>test-to-run</var></code> as many times as you want.
+
+## Running specific methods
+
+You can run specific methods within a test class. Although the whole module
+needs to be built, this reduces the time needed to run the tests. To run
+specific methods, identify the class using any of the ways supported for
+identifying a class (Module:Class, file path, etc) and append the name of the
+method.
+
+<pre>
+<code class="devsite-terminal">atest <var>reference-to-class</var>#<var>method1</var></code>
+</pre>
+
+You can specify multiple methods with commas.
+
+<pre>
+<code class="devsite-terminal">atest <var>reference-to-class</var>#<var>method1</var>,<var>method2</var>,<var>method3</var></code>
+</pre>
+
+Examples:
+
+<pre>
+<code class="devsite-terminal">atest com.android.server.wm.ScreenDecorWindowTests#testMultipleDecors</code>
+<code class="devsite-terminal">atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval</code>
+</pre>
+
+The following two examples show the preferred ways to run a single method,
+`testFlagChange`. These examples are preferred over only using the class name
+because specifying the module or the Java file location allows Atest to find the
+test much faster:
+
+1.  Using Module:Class
+
+    <pre>
+    <code class="devsite-terminal">atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange</code>
+    </pre>
+
+1.  From android <var>repo-root</var>
+
+    <pre>
+    <code class="devsite-terminal">atest frameworks/base/services/tests/servicestests/src/com/android/server/wm/ScreenDecorWindowTests.java#testFlagChange</code>
+    </pre>
+
+Multiple methods can be run from different classes and modules:
+
+<pre>
+<code class="devsite-terminal">atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors</code>
+</pre>
+
+## Running multiple classes
+
+To run multiple classes, separate them with spaces in the same way as running
+multiple tests. Atest builds and runs classes efficiently, so specifying a
+subset of classes in a module improves performance over running the whole
+module.
+
+Examples:
+
+-   Two classes in the same module:
+
+    <pre>
+    <code class="devsite-terminal">atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests</code>
+    </pre>
+
+-   Two classes in different modules:
+
+    <pre>
+    <code class="devsite-terminal">atest FrameworksServicesTests:ScreenDecorWindowTests CtsJankDeviceTestCases:CtsDeviceJankUi</code>
+    </pre>
+
+## Running native tests
+
+Atest can run native tests.
+
+Examples:
+
+-   Input tests:
+
+    <pre>
+    <code class="devsite-terminal">atest -a libinput_tests inputflinger_tests</code>
+    </pre>
+
+Use `-a` to run the tests for all available device architectures, which in this
+example is armeabi-v7a (ARM 32-bit) and arm64-v8a (ARM 64-bit).
+
+## Detecting metrics regression
+
+You can generate pre-patch or post-patch metrics without running regression
+detection. You can specify the number of iterations, but the default is five.
+
+Examples:
+
+<pre>
+<code class="devsite-terminal">atest <var>test-to-run</var> --generate-baseline <var>[optional-iteration]</var></code>
+<code class="devsite-terminal">atest <var>test-to-run</var> --generate-new-metrics <var>[optional-iteration]</var></code>
+</pre>
+
+Local regression detection can be run in three options:
+
+1.  Generate baseline (pre-patch) metrics and place them in a folder. Atest runs
+    the tests through the specified iterations, generates post-patch metrics,
+    and compares those against existing metrics.
+
+    Example:
+
+    <pre>
+    <code class="devsite-terminal">atest <var>test-to-run</var> --detect-regression <var>/path/to/baseline</var> --generate-new-metrics <var>[optional-iteration]</var></code>
+    </pre>
+
+2.  Using a folder containing previously generated post-patch metrics, Atest
+    runs the tests _n_ iterations, generates a new set of pre-patch metrics, and
+    compares those against those provided.
+
+    Note: The developer needs to revert the device/tests to pre-patch state to
+    generate baseline metrics.
+
+    Example:
+
+    <pre>
+    <code class="devsite-terminal">atest <var>test-to-run</var> --detect-regression <var>/path/to/new</var> --generate-baseline <var>[optional-iteration]</var></code>
+    </pre>
+
+3.  Using two folders containing both pre-patch and post-patch metrics, Atest
+    runs the regression detection algorithm without any tests.
+
+    Example:
+
+    <pre>
+    <code class="devsite-terminal">atest --detect-regression <var>/path/to/baseline</var> <var>/path/to/new</var></code>
+    </pre>
diff --git a/en/compatibility/tests/development/index.md b/en/compatibility/tests/development/index.md
index 12f1b610..6fc66d6c 100644
--- a/en/compatibility/tests/development/index.md
+++ b/en/compatibility/tests/development/index.md
@@ -19,10 +19,16 @@ Book: /_book.yaml
   limitations under the License.
 -->
 
-# Test Types and Guidelines
+# Test Development Workflow
 
 To integrate tests into a platform continuous testing service, they should meet
-the following guidelines.
+the guidelines on this page and follow this recommended flow.
+
+1.  Use the [Soong build system](https://android.googlesource.com/platform/build/soong/)
+    for [Simple Test Configuration](blueprints).
+1.  Employ [Test Mapping](test-mapping) to easily create pre- and post-submit
+    test rules directly in the Android source tree.
+1.  Run tests locally using [Atest](atest).
 
 ## Test types
 
diff --git a/en/compatibility/tests/development/instr-app-e2e.md b/en/compatibility/tests/development/instr-app-e2e.md
index b61d6644..11839be1 100644
--- a/en/compatibility/tests/development/instr-app-e2e.md
+++ b/en/compatibility/tests/development/instr-app-e2e.md
@@ -56,8 +56,8 @@ manifest file. If you name the file as `AndroidManifest.xml` and provide it next
 to `Android.mk` for your test tmodule, it will get included automatically by the
 `BUILD_PACKAGE` core makefile.
 
-Before proceeding further, it's highly recommended to go through the external
-[documentation on manifest file](https://developer.android.com/guide/topics/manifest/manifest-intro.html)
+Before proceeding further, it's highly recommended to go through the
+[App Manifest Overview](https://developer.android.com/guide/topics/manifest/manifest-intro.html){: .external}
 first.
 
 This gives an overview of basic components of a manifest file and their
@@ -156,12 +156,12 @@ sufficient. See [Simple Test Configuration](blueprints.md) for details.
 Important: The instructions in this section are needed only for CTS tests or those
 that require special setup, such as disabling Bluetooth or collecting sample data.
 All other cases can be covered through the
-[Simple Test Configuration](blueprints.md). See the
-[Complex Test Configuration](compatibility/tests/development/test-config) for
+[Simple Test Configuration](blueprints). See the
+[Complex Test Configuration](test-config) for
 more details applicable to this section.
 
-For more complex tests, you also need write a test configuration
-file for Android's test harness, [Trade Federation](https://source.android.com/devices/tech/test_infra/tradefed/).
+For more complex tests, you also need to write a test configuration
+file for Android's test harness, [Trade Federation](/devices/tech/test_infra/tradefed/).
 
 The test configuration can specify special device setup options and default
 arguments to supply the test class.
@@ -285,7 +285,7 @@ stored. Through this class, you can also call:
 ## Build and test locally
 
 For the most common use cases, employ
-[Atest](https://android.googlesource.com/platform/tools/tradefederation/+/master/atest/README.md).
+[Atest](/compatibility/tests/development/atest).
 
 For more complex cases requiring heavier customization, follow the
 [instrumentation instructions](instrumentation.md).
diff --git a/en/compatibility/tests/development/instr-self-e2e.md b/en/compatibility/tests/development/instr-self-e2e.md
index 6c8885e9..b68a94df 100644
--- a/en/compatibility/tests/development/instr-self-e2e.md
+++ b/en/compatibility/tests/development/instr-self-e2e.md
@@ -95,8 +95,8 @@ manifest file. If you name the file as `AndroidManifest.xml` and provide it next
 to `Android.mk` for your test tmodule, it will get included automatically by the
 `BUILD_PACKAGE` core makefile.
 
-Before proceeding further, it's highly recommended to go through the external
-[documentation on manifest file](https://developer.android.com/guide/topics/manifest/manifest-intro.html)
+Before proceeding further, it's highly recommended to go through the
+[App Manifest Overview](https://developer.android.com/guide/topics/manifest/manifest-intro.html){: .external}
 first.
 
 This gives an overview of basic components of a manifest file and their
@@ -191,12 +191,12 @@ sufficient. See [Simple Test Configuration](blueprints.md) for details.
 Important: The instructions in this section are needed only for CTS tests or those
 that require special setup, such as disabling Bluetooth or collecting sample data.
 All other cases can be covered through the
-[Simple Test Configuration](blueprints.md). See the
-[Complex Test Configuration](compatibility/tests/development/test-config) for
+[Simple Test Configuration](blueprints). See the
+[Complex Test Configuration](test-config) for
 more details applicable to this section.
 
 For these more complex cases, you also need to write a test configuration
-file for Android's test harness, [Trade Federation](https://source.android.com/devices/tech/test_infra/tradefed/).
+file for Android's test harness, [Trade Federation](/devices/tech/test_infra/tradefed/).
 
 The test configuration can specify special device setup options and default
 arguments to supply the test class. See the example at
@@ -324,7 +324,7 @@ Instrumentation instrumentation = InstrumentationRegistry.getInstrumentation()
 ## Build and test locally
 
 For the most common use cases, employ
-[Atest](https://android.googlesource.com/platform/tools/tradefederation/+/master/atest/README.md).
+[Atest](/compatibility/tests/development/atest).
 
 For more complex cases requiring heavier customization, follow the
 [instrumentation instructions](instrumentation.md).
diff --git a/en/compatibility/tests/development/instrumentation.md b/en/compatibility/tests/development/instrumentation.md
index 70439a7c..6a468758 100644
--- a/en/compatibility/tests/development/instrumentation.md
+++ b/en/compatibility/tests/development/instrumentation.md
@@ -91,8 +91,7 @@ and APIs to manipulate the application process under test.
 
 1. Run the tests:
    *  The simplest solution is to use
-      [Atest](https://android.googlesource.com/platform/tools/tradefederation/+/master/atest/README.md){: .external}
-      like so:
+   [Atest](/compatibility/tests/development/atest) like so:
 
       ```
       atest FrameworksCoreTests
diff --git a/en/compatibility/tests/development/native-func-e2e.md b/en/compatibility/tests/development/native-func-e2e.md
index 7f143c3e..a6b03108 100644
--- a/en/compatibility/tests/development/native-func-e2e.md
+++ b/en/compatibility/tests/development/native-func-e2e.md
@@ -173,7 +173,7 @@ arguments to supply the test class.
 ## Build and test locally
 
 For the most common use cases, employ
-[Atest](https://android.googlesource.com/platform/tools/tradefederation/+/master/atest/README.md).
+[Atest](/compatibility/tests/development/atest).
 
 For more complex cases requiring heavier customization, follow the
 [instrumentation instructions](instrumentation.md).
diff --git a/en/compatibility/tests/development/native.md b/en/compatibility/tests/development/native.md
index cb798694..399e6664 100644
--- a/en/compatibility/tests/development/native.md
+++ b/en/compatibility/tests/development/native.md
@@ -51,9 +51,7 @@ incremental or full build), e.g.:
    ```shell
    make hwui_unit_tests -j
    ```
-1.  Use
-    [Atest](https://android.googlesource.com/platform/tools/tradefederation/+/master/atest/README.md)
-    to run the test locally:
+1.  Use [Atest](/compatibility/tests/development/atest) to run the test locally:
 
     ```
     atest hwui_unit_tests
diff --git a/en/compatibility/tests/development/test-mapping.md b/en/compatibility/tests/development/test-mapping.md
new file mode 100644
index 00000000..5f843199
--- /dev/null
+++ b/en/compatibility/tests/development/test-mapping.md
@@ -0,0 +1,270 @@
+Project: /_project.yaml
+Book: /_book.yaml
+
+{% include "_versions.html" %}
+
+<!--
+  Copyright 2018 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.
+-->
+
+# Test Mapping
+
+This is a brief introduction of Test Mapping and an explanation of how to get
+started configuring tests easily in the Android Open Source Project (AOSP).
+
+## What is Test Mapping?
+
+Test Mapping is a Gerrit-based approach that allows developers to create pre-
+and post-submit test rules directly in the Android source tree and leave the
+decisions of branches and devices to be tested to the test infrastructure
+itself. Test Mapping definitions are JSON files named TEST_MAPPING that can be
+placed in any source directory.
+
+[Atest](atest) can use the TEST_MAPPING files to run presubmit tests in the
+associated directories. With Test Mapping, you can add the same set of tests to
+presubmit checks with a simple change inside the Android source tree.
+
+See these examples:
+
+[Add presubmit tests to TEST_MAPPING for services.core](https://android.googlesource.com/platform/frameworks/base/+/master/services/core/java/com/android/server/pm/dex/TEST_MAPPING)
+
+[Add presubmit and postsubmit tests to TEST_MAPPING for startop/iorap](https://android.googlesource.com/platform/frameworks/base/+/master/startop/iorap/TEST_MAPPING)
+
+## Defining test groups
+
+Test Mapping groups tests via a **test group**. The name of a test group can be
+any string. For example, *presubmit* can be for a group of tests to run when
+validating changes. And *postsubmit* tests can be used to validate the
+builds after changes are merged.
+
+## Packaging build script rules
+
+In order for the [Trade Federation Test Harness](/devices/tech/test_infra/tradefed)
+to run Test Mapping's test modules for a given build, these modules must have
+**test_suite** set for [Soong](blueprints) or **LOCAL_COMPATIBILITY_SUITE** set
+for Make to one of these two suites:
+
+*   **device-tests** - built against a specific device CPU
+*   **general-tests** - built against any application binary interface (ABI)
+
+When in doubt, put gtests in _device-tests_ and APK tests in _general-tests_.
+
+Examples:
+
+```
+Android.bp: test_suites: ["device-tests"],
+Android.mk: LOCAL_COMPATIBILITY_SUITE := device-tests
+```
+
+
+## Creating Test Mapping files
+
+For the directory requiring test coverage, simply add a TEST_MAPPING JSON file
+resembling the example below. These rules will ensure the tests run in presubmit
+checks when any files are touched in that directory or any of its subdirectories.
+
+### Following an example
+
+Here is a sample TEST_MAPPING file:
+
+```
+{
+  "presubmit": [
+    {
+      "name": "CtsWindowManagerDeviceTestCases",
+      "options": [
+        {
+          "include-annotation": "android.platform.test.annotations.RequiresDevice"
+        }
+      ]
+    }
+  ],
+  "postsubmit": [
+    {
+      "name": "CtsWindowManagerDeviceTestCases"
+    }
+  ],
+  "imports": [
+    {
+      "path": "frameworks/base/services/core/java/com/android/server/am"
+    }
+  ]
+}
+```
+
+### Setting attributes
+
+In the above example, `presubmit` and `postsubmit` are the names of each **test
+group**. Note that a test run for `postsubmit` will automatically include all
+tests in the `presubmit` group. See
+[Defining test groups](#defining_test_groups) for more information about test
+groups.
+
+The **name** of the **test module** or **Trade Federation integration test
+name** (resource path to the test XML file, e.g.,
+[uiautomator/uiautomator-demo](https://android.googlesource.com/platform/tools/tradefederation/contrib/+/master/res/config/uiautomator/uiautomator-demo.xml))
+can be set in the value of the `name` attribute. Note the **name** field cannot
+use class `name` or test method `name`. To narrow down the tests to run, you can
+use options such as `include-filter` here. See
+([include-filter sample usage](https://android.googlesource.com/platform/frameworks/base/+/master/services/core/java/com/android/server/pm/dex/TEST_MAPPING#7)).
+
+The `imports` attribute allows you to include tests in other TEST_MAPPING files
+without copying the content. Note that the TEST_MAPPING files in the parent
+directories of the imported path will also be included.
+
+The `options` attribute contains additional TradeFed command line options. In
+the above example, only tests with annotation `Presubmit` will run in presubmit;
+all tests will run in postsubmit.
+
+To get a complete list of available options for a given test, run:
+
+<pre>
+<code class="devsite-terminal">tradefed.sh run commandAndExit [test_module] --help</code>
+</pre>
+
+Refer to
+[TradeFed Option Handling ](/devices/tech/test_infra/tradefed/fundamentals/options)
+for more details about how options work.
+
+## Running tests with Atest
+
+To execute the presubmit test rules locally:
+
+1.  Go to the directory containing the TEST_MAPPING file.
+1.  Run the command:
+
+<pre>
+<code class="devsite-terminal">atest</code>
+</pre>
+
+All presubmit tests configured in the TEST_MAPPING files of the current
+directory and its parent directories are run. Atest will locate and run two tests
+for presubmit (A and B).
+
+This is the simplest way to run presubmit tests in TEST_MAPPING files in the
+current working directory (CWD) and parent directories. Atest will locate and
+use the TEST_MAPPING file in CWD and all of its parent directories, unless a
+TEST_MAPPING file has `inherit_parent` set to false.
+
+### Structuring source code
+
+The following example shows how TEST_MAPPING files can be configured across the
+source tree.
+
+```
+src
+├── project_1
+│   └── TEST_MAPPING
+├── project_2
+│   └── TEST_MAPPING
+└── TEST_MAPPING
+```
+
+Content of `src/TEST_MAPPING`:
+
+```
+{
+  "presubmit": [
+    {
+      "name": "A"
+    }
+  ]
+}
+```
+
+Content of `src/project_1/TEST_MAPPING`:
+
+```
+{
+  "presubmit": [
+    {
+      "name": "B"
+    }
+  ],
+  "postsubmit": [
+    {
+      "name": "C"
+    }
+  ],
+  "other_group": [
+    {
+      "name": "X"
+    }
+  ]}
+```
+
+Content of `src/project_2/TEST_MAPPING`:
+
+```
+{
+  "presubmit": [
+    {
+      "name": "D"
+    }
+  ],
+  "import": [
+    {
+      "path": "src/project_1"
+    }
+  ]}
+```
+
+### Specifying target directories
+
+You can specify a target directory to run tests in TEST_MAPPING files in that
+directory. The following command will run two tests (A, B).
+
+<pre>
+<code class="devsite-terminal">atest --test-mapping src/project_1</code>
+</pre>
+
+### Running postsubmit test rules
+
+You can also use this command to run the postsubmit test rules defined in
+TEST_MAPPING in `src_path` (default to CWD)
+and its parent directories:
+
+<pre>
+<code class="devsite-terminal">atest [--test-mapping] [src_path]:postsubmit</code>
+</pre>
+
+### Identifying test groups
+
+You can specify test groups in the Atest command. Note that presubmit tests are
+part of postsubmit tests, as well. The following command will run all
+**postsubmit** tests related to files in directory src/project_1, which are
+three tests (A, B, C).
+
+Or you can use **:all** to run all tests regardless of group. The following
+command runs four tests (A, B, C, X):
+
+<pre>
+<code class="devsite-terminal">atest --test-mapping src/project_1:all</code>
+</pre>
+
+### Including subdirectories
+
+By default, running tests in TEST_MAPPING with Atest will run only presubmit
+tests configured in the TEST_MAPPING file in CWD (or
+given directory) and its parent directories. If you want to run tests in all
+TEST_MAPPING files in the sub-directories, use the option `--include-subdir` to
+force Atest to include those tests too.
+
+<pre>
+<code class="devsite-terminal">atest --include-subdir</code>
+</pre>
+
+Without the `--include-subdir` option, Atest will run only test A. With the
+`--include-subdir` option, Atest will run two tests (A, B).
diff --git a/en/compatibility/tests/index.md b/en/compatibility/tests/index.md
index ac6bbe60..778d9064 100644
--- a/en/compatibility/tests/index.md
+++ b/en/compatibility/tests/index.md
@@ -44,7 +44,7 @@ Make solution.
 
 ### Atest
 
-[Atest](https://android.googlesource.com/platform/tools/tradefederation/+/master/atest/README.md){: .external}
+[Atest](/compatibility/tests/development/atest)
 is a command line tool that allows users to build, install and run Android tests
 locally. It is the recommended standard for initial testing of your feature.
 
diff --git a/en/devices/_toc-graphics.yaml b/en/devices/_toc-graphics.yaml
index f249cfaa..dc30a6bd 100644
--- a/en/devices/_toc-graphics.yaml
+++ b/en/devices/_toc-graphics.yaml
@@ -53,3 +53,5 @@ toc:
     path: /devices/graphics/test-groups
   - title: Integrating with Android CTS
     path: /devices/graphics/cts-integration
+- title: Tracing Window Transitions
+  path: /devices/graphics/tracing-win-transitions
diff --git a/en/devices/accessories/headset/usb-headset-spec.html b/en/devices/accessories/headset/usb-headset-spec.html
index 9302fe09..cd5b36af 100644
--- a/en/devices/accessories/headset/usb-headset-spec.html
+++ b/en/devices/accessories/headset/usb-headset-spec.html
@@ -46,6 +46,17 @@ specification only covers mandated basic features:
  <li>Function buttons for volume, playback, and call control</li>
 </ul>
 
+<h2 id="terminal-types">USB Audio Class terminal types</h2>
+<p>
+Headphones and headsets must report these USB Audio Class (UAC) terminal types:
+</p>
+
+<ul>
+ <li><strong>Headphones</strong>. Low impedance transducers, &lt; 100 ohms, no
+ microphone: 0x0302</li>
+ <li><strong>Headset</strong>. Low impedance transducers with microphone: 0x0402</li>
+</ul>
+
 <h2 id="control-function">Control functions</h2>
 <p>Headsets can come with varying number of buttons to control specific
 functions, such as volume and play/pause.<p>
diff --git a/en/devices/architecture/vintf/objects.html b/en/devices/architecture/vintf/objects.html
index 825b20d9..3bfeff64 100644
--- a/en/devices/architecture/vintf/objects.html
+++ b/en/devices/architecture/vintf/objects.html
@@ -167,7 +167,7 @@ specify product-specific HALs).</p>
             &lt;instance>legacy/0&lt;/instance>
         &lt;/interface>
     &lt;/hal>
-    &lt;!-- NFC is disabled -->
+    &lt;!-- NFC is declared to be disabled -->
     &lt;hal override="true">
         &lt;name>android.hardware.nfc&lt;/name>
         &lt;transport>hwbinder&lt;/transport>
@@ -281,7 +281,8 @@ depending on the <code>format</code> attribute.</dd>
  <li><code>true</code>: override other <code>&lt;hal></code> elements with
   the same <code>&lt;name></code> and major version. If no
   <code>&lt;version></code> or <code>&lt;fqname></code> are in this
-  <code>&lt;hal></code> element, then this HAL is disabled.</li>
+  <code>&lt;hal></code> element, then the <code>&lt;hal></code> element
+   declares this HAL to be disabled.</li>
  <li><code>false</code>: do not override other <code>&lt;hal></code> elements
   with the same <code>&lt;name></code> and major version.</li>
  </ul>
diff --git a/en/devices/architecture/vndk/build-system.html b/en/devices/architecture/vndk/build-system.html
index 72737be6..98e95b63 100644
--- a/en/devices/architecture/vndk/build-system.html
+++ b/en/devices/architecture/vndk/build-system.html
@@ -506,18 +506,19 @@ $(call add-clean-step, rm -rf $(TARGET_OUT_VENDOR)/lib/libvndk.so)
 </p>
 
 <ul>
-  <li>core variant (e.g. <code>/system/lib[64]/libexample.so</code>)</li>
-  <li>vendor variant (e.g.
+  <li>Core variant (e.g. <code>/system/lib[64]/libexample.so</code>)</li>
+  <li>Vendor variant (e.g.
   <code>/system/lib[64]/vndk[-sp]-${VER}/libexample.so</code>)</li>
   <li>VNDK extension (e.g. <code>/vendor/lib[64]/vndk[-sp]/libexample.so</code>)
   </li>
 </ul>
 
+
 <h4 id="conditional-cflags">Conditional compiler flags</h4>
 
 <p>
   The Android build system defines <code>__ANDROID_VNDK__</code> for vendor
-  variants (including VNDK extensions) by default. You may guard the code
+  variants and VNDK extensions by default. You may guard the code
   with the C preprocessor guards:
 </p>
 
@@ -537,15 +538,18 @@ void vndk_only() { }
   In addition to <code>__ANDROID_VNDK__</code>, different <code>cflags</code> or
   <code>cppflags</code> may be specified in <code>Android.bp</code>. The
   <code>cflags</code> or <code>cppflags</code> specified in
-  <code>target.vendor</code> is specific to the vendor variant. For example, the
-  following code example is the <code>Android.bp</code> module definition for
+  <code>target.vendor</code> is specific to the vendor variant.
+</p>
+
+<p>
+  For example, the following <code>Android.bp</code> defines
   <code>libexample</code> and <code>libexample_ext</code>:
 </p>
 
 <pre class="prettyprint">
 cc_library {
     name: "libexample",
-    srcs: ["example.c"],
+    srcs: ["src/example.c"],
     vendor_available: true,
     vndk: {
         enabled: true,
@@ -559,7 +563,7 @@ cc_library {
 
 cc_library {
     name: "libexample_ext",
-    srcs: ["example.c"],
+    srcs: ["src/example.c"],
     vendor: true,
     vndk: {
         enabled: true,
@@ -573,7 +577,7 @@ cc_library {
 </pre>
 
 <p>
-  Code listing of <code>example.c</code>:
+  And this is the code listing of <code>src/example.c</code>:
 </p>
 
 <pre class="prettyprint">
@@ -593,7 +597,8 @@ void vndk_ext() { }
 </pre>
 
 <p>
-  Exported symbols for each variant:
+  According to these two files, the build system generates shared libraries
+  with following exported symbols:
 </p>
 
 <table>
@@ -618,19 +623,34 @@ void vndk_ext() { }
  </tr>
 </table>
 
+
+<h4 id="exported-symbols">Requirements on the exported symbols</h4>
+
 <p>
-  The VNDK ABI compliance checker compares the ABI of VNDK and VNDK
-  extensions to the ABI dumps under <code>prebuilts/abi-dumps/vndk</code>:
+  The <a href="/devices/architecture/vndk/abi-stability">VNDK ABI checker</a>
+  compares the ABI of <em>VNDK vendor variants</em> and
+  <em>VNDK extensions</em> to the reference ABI dumps under
+  <code>prebuilts/abi-dumps/vndk</code>.
 </p>
 
 <ul>
-  <li>Symbols exported by original VNDK shared libraries must be identical to
-  (not the supersets of) the symbols defined in ABI dumps.</li>
-  <li>Symbols exported by VNDK extensions must be supersets of the symbols
-  defined in ABI dumps.</li>
+  <li>Symbols exported by <em>VNDK vendor variants</em> (e.g.
+  <code>/system/lib[64]/vndk-${VER}/libexample.so</code>) must be identical
+  to (not the supersets of) the symbols defined in ABI dumps.</li>
+
+  <li>Symbols exported by <em>VNDK extensions</em> (e.g.
+  <code>/vendor/lib[64]/vndk/libexample.so</code>) must be supersets of the
+  symbols defined in ABI dumps.</li>
 </ul>
 
-<h4 id="excluding">Excluding source files or shared libs</h4>
+<p>
+  If <em>VNDK vendor variants</em> or <em>VNDK extensions</em> fail to follow
+  the requirements above, VNDK ABI checker emits build errors and stops the
+  build.
+</p>
+
+
+<h4 id="excluding">Excluding source files or shared libraries from vendor variants</h4>
 
 <p>
   To exclude source files from the vendor variant, add them to the
@@ -641,7 +661,7 @@ void vndk_ext() { }
 
 <pre class="prettyprint">
 cc_library {
-    name: "libcond_exclude_example",
+    name: "libexample_cond_exclude",
     srcs: ["fwk.c", "both.c"],
     shared_libs: ["libfwk_only", "libboth"],
     target: {
@@ -654,17 +674,168 @@ cc_library {
 </pre>
 
 <p>
-  In this example, the core variant of <code>libcond_exclude_example</code>
+  In this example, the core variant of <code>libexample_cond_exclude</code>
   includes the code from <code>fwk.c</code> and <code>both.c</code> and depends
   on the shared libraries <code>libfwk_only</code> and <code>libboth</code>. The
-  vendor variant of <code>libcond_exclude_example</code> includes only the code
+  vendor variant of <code>libexample_cond_exclude</code> includes only the code
   from <code>both.c</code> because <code>fwk.c</code> is excluded by the
   <code>exclude_srcs</code> property. Similarly,
-  <code>libcond_exclude_example</code> depends only on the shared library
+  <code>libexample_cond_exclude</code> depends only on the shared library
   <code>libboth</code> because <code>libfwk_only</code> is excluded by the
   <code>exclude_shared_libs</code> property.
 </p>
 
+<h4 id="export-headers-from-vndk-extension">Export headers from VNDK extensions</h4>
+
+<p>
+  A VNDK extension may add new classes or new functions to a VNDK shared
+  library. It is suggested to keep those declarations in independent headers
+  and avoid changing the existing headers.
+</p>
+
+<p>
+  For example, a new header file
+  <code>include-ext/example/ext/feature_name.h</code> is created for the VNDK
+  extension <code>libexample_ext</code>:
+</p>
+
+<ul>
+  <li>Android.bp</li>
+  <li><strong>include-ext/example/ext/feature_name.h</strong></li>
+  <li>include/example/example.h</li>
+  <li>src/example.c</li>
+  <li><strong>src/ext/feature_name.c</strong></li>
+</ul>
+
+<p>
+  In the following <code>Android.bp</code>, <code>libexample</code> exports
+  only <code>include</code>, whereas <code>libexample_ext</code> exports both
+  <code>include</code> and <code>include-ext</code>. This ensures
+  <code>feature_name.h</code> won't be incorrectly included by the users of
+  <code>libexample</code>:
+</p>
+
+<pre class="prettyprint">
+cc_library {
+    name: "libexample",
+    srcs: ["src/example.c"],
+    export_include_dirs: ["include"],
+    vendor_available: true,
+    vndk: {
+        enabled: true,
+    },
+}
+
+cc_library {
+    name: "libexample_ext",
+    srcs: [
+        "src/example.c",
+        "src/ext/feature_name.c",
+    ],
+    export_include_dirs: [
+        "include",
+        "include-ext",
+    ],
+    vendor: true,
+    vndk: {
+        enabled: true,
+        extends: "libexample",
+    },
+}
+</pre>
+
+<p>
+  If separating extensions to independent header files is not feasible, an
+  alternative is to add <code>#ifdef</code> guards. However, make sure that all
+  VNDK extension users add the define flags. You may define
+  <code>cc_defaults</code> to add define flags to <code>cflags</code> and link
+  shared libraries with <code>shared_libs</code>.
+</p>
+
+<p>
+  For example, to add a new member function <code>Example2::get_b()</code> to
+  the VNDK extension <code>libexample2_ext</code>, you must modify the existing
+  header file and add a <code>#ifdef</code> guard:
+</p>
+
+<pre class="prettyprint">
+#ifndef LIBEXAMPLE2_EXAMPLE_H_
+#define LIBEXAMPLE2_EXAMPLE_H_
+
+class Example2 {
+ public:
+  Example2();
+
+  void get_a();
+
+#ifdef LIBEXAMPLE2_ENABLE_VNDK_EXT
+  void get_b();
+#endif
+
+ private:
+  void *impl_;
+};
+
+#endif  // LIBEXAMPLE2_EXAMPLE_H_
+</pre>
+
+<p>
+  A <code>cc_defaults</code> named <code>libexample2_ext_defaults</code> is
+  defined for the users of <code>libexample2_ext</code>:
+</p>
+
+<pre class="prettyprint">
+cc_library {
+    name: "libexample2",
+    srcs: ["src/example2.cpp"],
+    export_include_dirs: ["include"],
+    vendor_available: true,
+    vndk: {
+        enabled: true,
+    },
+}
+
+cc_library {
+    name: "libexample2_ext",
+    srcs: ["src/example2.cpp"],
+    export_include_dirs: ["include"],
+    vendor: true,
+    vndk: {
+        enabled: true,
+        extends: "libexample2",
+    },
+    cflags: [
+        "-DLIBEXAMPLE2_ENABLE_VNDK_EXT=1",
+    ],
+}
+
+cc_defaults {
+    name: "libexample2_ext_defaults",
+    shared_libs: [
+        "libexample2_ext",
+    ],
+    cflags: [
+        "-DLIBEXAMPLE2_ENABLE_VNDK_EXT=1",
+    ],
+}
+</pre>
+
+<p>
+  The users of <code>libexample2_ext</code> may simply include
+  <code>libexample2_ext_defaults</code> in their <code>defaults</code>
+  property:
+</p>
+
+<pre class="prettyprint">
+cc_binary {
+    name: "example2_user_executable",
+    defaults: ["libexample2_ext_defaults"],
+    vendor: true,
+}
+</pre>
+
+
+
 <h3 id="product-packages">Product packages</h3>
 
 <p>
diff --git a/en/devices/architecture/vndk/linker-namespace.html b/en/devices/architecture/vndk/linker-namespace.html
index b0d82512..a460e158 100644
--- a/en/devices/architecture/vndk/linker-namespace.html
+++ b/en/devices/architecture/vndk/linker-namespace.html
@@ -46,7 +46,7 @@ hiding their implementation details within their linker namespaces.</p>
 
 <p>For example, <code>/system/lib[64]/libcutils.so</code> and
 <code>/system/lib[64]/vndk-sp-${VER}/libcutils.so</code> are two shared
-libraries. These two libraries may have different symbols. They will be loaded
+libraries. These two libraries may have different symbols. They are loaded
 into different linker namespaces so that framework modules can depend on
 <code>/system/lib[64]/libcutils.so</code> and SP-HAL shared libraries can
 depend on <code>/system/lib[64]/vndk-sp-${VER}/libcutils.so</code>.</p>
@@ -55,7 +55,7 @@ depend on <code>/system/lib[64]/vndk-sp-${VER}/libcutils.so</code>.</p>
 public libraries that is exported by a linker namespace and imported into
 many linker namespaces. The dependencies of
 <code>/system/lib[64]/libc.so</code>, such as <code>libnetd_client.so</code>,
-will be loaded into the namespace in which <code>/system/lib[64]/libc.so</code>
+is loaded into the namespace in which <code>/system/lib[64]/libc.so</code>
 resides. Other namespaces won't have accesses to those dependencies. This
 mechanism encapsulates the implementation details while providing the public
 interfaces.</p>
@@ -69,10 +69,10 @@ interfaces.</p>
 <p>The dynamic linker is responsible for loading the shared libraries specified
 in <code>DT_NEEDED</code> entries or the shared libraries specified by the
 argument of <code>dlopen()</code> or <code>android_dlopen_ext()</code>. In both
-cases, the dynamic linker will find the linker namespace where the caller
+cases, the dynamic linker finds the linker namespace where the caller
 resides and try to load the dependencies into the same linker namespace. If
 the dynamic linker cannot load the shared library into the specified linker
-namespace, it will ask the <em>linked linker namespace</em> for exported shared
+namespace, it asks the <em>linked linker namespace</em> for exported shared
 libraries.</p>
 
 
@@ -86,130 +86,408 @@ configuration file looks like:</p>
 
 <pre class="prettyprint">
 dir.system = /system/bin
+dir.system = /system/xbin
 dir.vendor = /vendor/bin
 
 [system]
-additional.namespaces = sphal
+additional.namespaces = sphal,vndk
 
 namespace.default.isolated = true
-namespace.default.search.paths = /system/${LIB}:/vendor/${LIB}
-namespace.default.permitted.paths = /system/${LIB}:/vendor/${LIB}
+namespace.default.search.paths = /system/${LIB}
+namespace.default.permitted.paths = /system/${LIB}/hw
+namespace.default.asan.search.paths = /data/asan/system/${LIB}:/system/${LIB}
+namespace.default.asan.permitted.paths = /data/asan/system/${LIB}/hw:/system/${LIB}/hw
 
 namespace.sphal.isolated = true
 namespace.sphal.visible = true
-namespace.sphal.search.paths = /vendor/${LIB}
-namespace.sphal.permitted.paths = /vendor/${LIB}
-namespace.sphal.links = default
+namespace.sphal.search.paths = /odm/${LIB}:/vendor/${LIB}
+namespace.sphal.permitted.paths = /odm/${LIB}:/vendor/${LIB}
+namespace.sphal.asan.search.paths  = /data/asan/odm/${LIB}:/odm/${LIB}
+namespace.sphal.asan.search.paths += /data/asan/vendor/${LIB}:/vendor/${LIB}
+namespace.sphal.asan.permitted.paths  = /data/asan/odm/${LIB}:/odm/${LIB}
+namespace.sphal.asan.permitted.paths += /data/asan/vendor/${LIB}:/vendor/${LIB}
+namespace.sphal.links = default,vndk
 namespace.sphal.link.default.shared_libs = libc.so:libm.so
+namespace.sphal.link.vndk.shared_libs = libbase.so:libcutils.so
+
+namespace.vndk.isolated = true
+namespace.vndk.search.paths = /system/${LIB}/vndk-sp-29
+namespace.vndk.permitted.paths = /system/${LIB}/vndk-sp-29
+namespace.vndk.links = default
+namespace.vndk.link.default.shared_libs = libc.so:libm.so
 
 [vendor]
 namespace.default.isolated = false
 namespace.default.search.paths = /vendor/${LIB}:/system/${LIB}
-namespace.default.permitted.paths = /vendor/${LIB}:/system/${LIB}
 </pre>
 
-<p>First, there are several <code>dir.${section}</code> properties at the
-beginning of <code>ld.config.txt</code>:</p>
+<p>The configuration file includes:</p>
 
-<pre class="prettyprint">
-dir.${section} = /path/to/bin/directory
-</pre>
+<ul>
+ <li>Several directory-section mapping properties at the beginning for the
+  dynamic linker to select the effective section.</li>
 
-<p>These properties decide which set of rules will be applied to the process.
-For example, if a <em>main executable</em> resides in <code>/system/bin</code>,
-the rules in the <code>[system]</code> section are applied. Similarly, if a
-<em>main executable</em> resides in <code>/vendor/bin</code>, the rules in the
-<code>[vendor]</code> section are applied.</p>
+ <li>
+  Several linker namespaces configuration sections:
 
-<p>Second, for each section, in addition to the <code>default</code> linker
-namespace, <code>addition.namespaces</code> specifies the extra linker
-namespaces (separated by comma) that will be created by the dynamic
-linker:</p>
+  <ul>
+   <li>Each section contains several namespaces (graph vertices) and several
+   fallback links between namespaces (graph arcs).</li>
 
-<pre class="prettyprint">
-additional.namespaces = namespace1,namespace2,namespace3
-</pre>
+   <li>Each namespace has its own isolation, search paths, permitted paths,
+   and visibility settings.</li>
+  </ul>
+ </li>
+</ul>
 
-<p>In the example above, the dynamic linker creates two linker namespaces
-(<code>default</code> and <code>sphal</code>) for the executables in
-<code>/system/bin</code>.</p>
+<p>The tables below describe the meaning of each property in detail.</p>
 
-<p>Third, for each linker namespace, following properties can be configured:</p>
 
-<pre class="prettyprint">
-namespace.${name}.search.paths = /path1/${LIB}:/path2/${LIB}
-namespace.${name}.permitted.paths = /path1:/path2
-namespace.${name}.isolated = true|false
-namespace.${name}.links = namespace1,namespace2
-namespace.${name}.link.${other}.shared_libs = lib1.so:lib2.so
-namespace.${name}.link.${other}.allow_all_shared_libs = true
-namespace.${name}.visible = true|false
-</pre>
 
-<p><code>namespace.${name}.search.paths</code> denotes the directories that
-will be prepended to the library name. Directories are separated by colons.
-<code>${LIB}</code> is a special placeholder. If the process is running a
-32-bit executable, <code>${LIB}</code> is substituted by
-<code>lib</code>. Similarly, if the process is running a 64-bit executable,
-<code>${LIB}</code> is substituted by <code>lib64</code>.</p>
-
-<p>In the example above, if a 64-bit executable in <code>/system/bin</code>
-links with <code>libexample.so</code>, the dynamic linker searches for
-<code>/system/lib64/libexample.so</code> first. If
-<code>/system/lib64/libexample.so</code> is not available, the dynamic
-linker searches for <code>/vendor/lib64/libexample.so</code>.</p>
-
-<p>If <code>namespace.${name}.isolated</code> is <code>true</code>, the
-dynamic linker loads only the shared libraries in the directories specified
-in <code>namespace.${name}.search.paths</code> or the shared libraries under
-the directories specified in
-<code>namespace.${name}.permitted.paths</code>.</p>
-
-<p>In the example above, a shared library that is loaded in the
-<code>sphal</code> linker namespace won't be able to link to shared libraries
-in <code>/system/lib[64]</code> because <code>namespace.sphal.isolated</code>
-is <code>true</code> and <code>/system/lib[64]</code> is in neither
-<code>namespace.sphal.permitted.paths</code> nor
-<code>namespace.sphal.search.paths</code>.</p>
-
-<p><code>namespace.${name}.links</code> specifies a comma-separated list of
-linker namespaces that the <code>${name}</code> linker namespace links to.</p>
-
-<p>In the example above, <code>namespace.sphal.links</code> specifies that the
-<code>sphal</code> linker namespace links to the <code>default</code> linker
-namespace.</p>
-
-<p><code>namespace.${name}.link.${other}.shared_libs</code> specifies the
-shared library names (separated by colons) that may utilize the fallback link.
-If a shared library can't be loaded into the <code>${name}</code> linker
-namespace and its name is in
-<code>namespace.${name}.link.${other}.shared_libs</code>, the dynamic linker
-will try to import the library from the <code>${other}</code> linker
-namespace.</p>
-
-<p>In the example above, <code>namespace.sphal.link.default.shared_libs</code>
-specifies that <code>libc.so</code> and <code>libm.so</code> may be exported by
-the <code>default</code> linker namespace. If a shared library loaded in the
-<code>sphal</code> linker namespace links to <code>libc.so</code> and the
-dynamic linker cannot find <code>libc.so</code> in
-<code>/vendor/lib[64]</code>, the dynamic linker will walk through the
-fallback link and find the <code>libc.so</code> exported by the
-<code>default</code> linker namespace.</p>
-
-<p>If <code>namespace.${name}.link.${other}.allow_all_shared_libs</code> is
-<code>true</code>, all shared library names may utilize the fallback link. If
-a shared library can't be loaded into the <code>${name}</code> linker
-namespace, the dynamic linker will try to import the library from the
-<code>${other}</code> linker namespace.</p>
-
-<p>If <code>namespace.${name}.visible</code> is <code>true</code>, the
-program will be able to obtain a linker namespace handle, which can be passed
-to <code>android_dlopen_ext()</code> later.</p>
-
-<p>In the example above, the <code>namespace.sphal.visible</code> is
-<code>true</code> so that <code>android_load_sphal_library()</code> can
-explicitly ask the dynamic linker to load a shared library in the
-<code>sphal</code> linker namespace.</p>
+<h3 id="directory-section-mapping-property">Directory-section mapping property</h3>
+
+<table>
+ <tr>
+  <th>Property</th>
+  <th>Description</th>
+  <th>Example</th>
+ </tr>
+
+ <tr>
+  <td><p><code>dir.<var>name</var></code></p></td>
+
+  <td>
+   <p>A path to a directory that the <code>[<var>name</var>]</code> section
+   applies to.</p>
+
+   <p>Each property maps the executables under the directory to a linker
+   namespaces configuration section. There might be two (or more) properties
+   with the same <code><var>name</var></code> but point to different
+   directories.</p>
+  </td>
+
+  <td>
+   <p>
+    <code>dir.system = /system/bin</code><br/>
+    <code>dir.system = /system/xbin</code><br/>
+    <code>dir.vendor = /vendor/bin</code><br/>
+   </p>
+
+   <p>This indicates that the configuration specified in the
+   <code>[system]</code> section applies to the executables that are loaded
+   from either <code>/system/bin</code> or <code>/system/xbin</code>.</p>
+
+   <p>The configuration specified in the <code>[vendor]</code> section applies
+   to the executables that are loaded from <code>/vendor/bin</code>.</p>
+  </td>
+ </tr>
+</table>
+
+
+
+<h3 id="relation-properties">Relation properties</h3>
+
+<table>
+ <tr>
+  <th>Property</th>
+  <th>Description</th>
+  <th>Example</th>
+ </tr>
+
+ <tr>
+  <td><code>additional.<wbr/>namespaces</code></td>
+
+  <td>
+   <p>A comma-separated list of additional namespaces (in addition to the
+   <code>default</code> namespace) for the section.</p>
+  </td>
+
+  <td>
+   <p><code>additional.<wbr/>namespaces = sphal,<wbr/>vndk</code></p>
+
+   <p>This indicates there are three namespaces (<code>default</code>,
+   <code>sphal</code>, and <code>vndk</code>) in the <code>[system]</code>
+   configuration.</p>
+  </td>
+ </tr>
+
+ <tr>
+  <td><code>namespace.<wbr/><var>name</var>.<wbr/>links</code></td>
+
+  <td>
+   <p>A comma-separated list of fallback namespaces.</p>
+
+   <p>If a shared library cannot be found in the current namespace, the dynamic
+   linker tries to load the shared library from the fallback namespaces. The
+   namespace specified at the beginning of the list has higher priority.</p>
+
+   <aside class="note">Note: Fallback namespaces are not transitive. For
+   example, namespace <em>A</em> links to namespace <em>B</em> and namespace
+   <em>B</em> links to namespace <em>C</em>. If the dynamic linker can not
+   find the library in namespace <em>A</em>, it ONLY searches namespace
+   <em>B</em>. It doesn't search namespace <em>C</em>.</aside>
+  </td>
+
+  <td>
+   <p><code>namespace.<wbr/>sphal.<wbr/>links = default,<wbr/>vndk</code></p>
+
+   <p>If a shared library or an executable requests a shared library that
+   cannot be loaded into the <code>sphal</code> namespace, the dynamic linker
+   tries to load the shared library from the <code>default</code>
+   namespace.</p>
+
+   <p>And then, if the shared library cannot be loaded from the
+   <code>default</code> namespace either, the dynamic linker tries to load the
+   shared library from the <code>vndk</code> namespace.</p>
+
+   <p>Finally, if all attempts fail, the dynamic linker returns an error.</p>
+  </td>
+ </tr>
+
+ <tr>
+  <td><code>namespace.<wbr/><var>name</var>.<wbr/>link.<wbr/><var>other</var>.<wbr/>shared_libs</code></td>
+
+  <td>
+   <p>A colon-separated list of shared libraries that can be searched in the
+   <code>other</code> namespaces when those libraries cannot be found in the
+   <code>name</code> namespace.</p>
+
+   <p>This property cannot be used with
+   <code>namespace.<wbr/><var>name</var>.<wbr/>link.<wbr/><var>other</var>.<wbr/>allow_all_shared_libs</code>.</p>
+
+   <aside class="note"><p>Note: This property shares the same underlying
+   implementation with
+   <a href="/devices/tech/config/namespaces_libraries">public.libraries.txt</a>
+   files. Both mechanisms control the imported shared libraries by specifying a
+   link with a library name filter.</p>
+
+   <p>The difference is that <code>ld.config.txt</code> is loaded by the
+   dynamic linker and all namespaces are created when a program starts. On the
+   contrary, <code>libnativeloader</code> creates a linker namespace when the
+   Zygote process is forked and specialized for an application. The namespace
+   for the application native libraries has a link that only allows the library
+   names specified in <code>public.libraries.txt</code>.</p></aside>
+  </td>
+
+  <td>
+   <p><code>namespace.<wbr/>sphal.<wbr/>link.<wbr/>default.<wbr/>shared_libs = libc.so:<wbr/>libm.so</code></p>
+
+   <p>This indicates that the fallback link only accepts <code>libc.so</code>
+   or <code>libm.so</code> as the requested library name. The dynamic linker
+   ignores the fallback link from <code>sphal</code> to
+   <code>default</code> namespace if the requested library name is not
+   <code>libc.so</code> nor <code>libm.so</code>.</p>
+  </td>
+ </tr>
+
+ <tr>
+  <td><code>namespace.<wbr/><var>name</var>.<wbr/>link.<wbr/><var>other</var>.<wbr/>allow_all_shared_libs</code></td>
+
+  <td>
+   <p>A boolean value that indicates whether all shared libraries can be
+   searched in the <code><var>other</var></code> namespace when those libraries cannot
+   be found in the <code><var>name</var></code> namespace.</p>
+
+   <p>This property cannot be used with
+   <code>namespace.<wbr/><var>name</var>.<wbr/>link.<wbr/><var>other</var>.<wbr/>shared_libs</code>.</p>
+  </td>
+
+  <td>
+   <p><code>namespace.<wbr/>vndk.<wbr/>link.<wbr/>sphal.<wbr/>allow_all_shared_libs = true</code></p>
+
+   <p>This indicates all library names can walk through the fallback link
+   from <code>vndk</code> to <code>sphal</code> namespace.</p>
+  </td>
+ </tr>
+</table>
+
+
+
+<h3 id="namespace-properties">Namespace properties</h3>
+
+<table>
+ <tr>
+  <th>Property</th>
+  <th>Description</th>
+  <th>Example</th>
+ </tr>
+
+ <tr>
+  <td><code>namespace.<wbr/><var>name</var>.<wbr/>isolated</code></td>
+
+  <td>
+   <p>A boolean value that indicates whether the dynamic linker should check
+   where the shared library resides.</p>
+
+   <p>If <code>isolated</code> is <code>true</code>, only the shared libraries
+   that are <em>in</em> one of the <code>search.paths</code> directories
+   (excluding sub-directories) or are <em>under</em> one of the
+   <code>permitted.paths</code> directories (including sub-directories) can be
+   loaded.</p>
+
+   <p>If <code>isolated</code> is <code>false</code> (default), the dynamic
+   linker doesn't check the path of shared libraries.</p>
+  </td>
+
+  <td>
+   <p><code>namespace.<wbr/>sphal.<wbr/>isolated = true</code></p>
+
+   <p>This indicates that only the shared libraries in
+   <code>search.paths</code> or under <code>permitted.paths</code> can be
+   loaded into the <code>sphal</code> namespace.</p>
+  </td>
+ </tr>
+
+ <tr>
+  <td><code>namespace.<wbr/><var>name</var>.<wbr/>search.paths</code></td>
+
+  <td>
+   <p>A colon-separated list of directories to search for shared
+   libraries.</p>
+
+   <p>The directories specified in <code>search.paths</code> are prepended
+   to the requested library name if function calls to <code>dlopen()</code> or
+   <code>DT_NEEDED</code> entries do not specify the full path. The directory
+   specified at the beginning of the list has higher priority.</p>
+
+   <p>When <code>isolated</code> is <code>true</code>, shared libraries that
+   are <em>in</em> one of the <code>search.paths</code> directories (excluding
+   sub-directories) can be loaded regardless the <code>permitted.paths</code>
+   property.</p>
+
+   <p>For example, if <code>search.paths</code> is
+   <code>/system/${LIB}</code> and <code>permitted.paths</code> is empty,
+   <code>/system/${LIB}/libc.so</code> can be loaded but
+   <code>/system/${LIB}/vndk/libutils.so</code> cannot be loaded.</p>
+
+   <aside class="note">Note: <code>${LIB}</code> is a built-in
+   placeholder. It is replaced by <code>lib</code> for 32-bit processes and
+   <code>lib64</code> for 64-bit processes.</aside>
+  </td>
+
+  <td>
+   <p><code>namespace.<wbr/>default.<wbr/>search.paths = /system/${LIB}</code></p>
+
+   <p>This indicates that the dynamic linker searches
+   <code>/system/${LIB}</code> for shared libraries.</p>
+  </td>
+ </tr>
+
+ <tr>
+  <td><code>namespace.<wbr/><var>name</var>.<wbr/>asan.search.paths</code></td>
+
+  <td>
+   <p>A colon-separated list of directories to search for shared libraries when
+   <a href="/devices/tech/debug/asan">Address Sanitizer</a> is enabled.</p>
+
+   <p><code>namespace.<wbr/><var>name</var>.<wbr/>search.paths</code> is
+   ignored when <a href="/devices/tech/debug/asan">Address Sanitizer</a> is
+   enabled.</p>
+  </td>
+
+  <td>
+   <p><code>namespace.<wbr/>default.<wbr/>asan.search.paths = /data/asan/system/${LIB}:<wbr/>/system/${LIB}</code></p>
+
+   <p>This indicates that when
+   <a href="/devices/tech/debug/asan">Address Sanitizer</a> is enabled the
+   dynamic linker searches <code>/data/asan/system/${LIB}</code> first and
+   then searches <code>/system/${LIB}</code>.</p>
+  </td>
+ </tr>
+
+ <tr>
+  <td><code>namespace.<wbr/><var>name</var>.<wbr/>permitted.paths</code></td>
+
+  <td>
+   <p>A colon-separated list of directories (including sub-directories) where
+   the dynamic linker can load the shared libraries (in addition to
+   <code>search.paths</code>) when <code>isolated</code> is
+   <code>true</code>.</p>
+
+   <p>The shared libraries that are under the sub-directories of
+   <code>permitted.paths</code> can be loaded too. For example, if
+   <code>permitted.paths</code> is <code>/system/${LIB}</code>,
+   both <code>/system/${LIB}/libc.so</code> and
+   <code>/system/${LIB}/vndk/libutils.so</code> can be loaded.</p>
+
+   <p>If <code>isolated</code> is <code>false</code>,
+   <code>permitted.paths</code> are ignored and a warning is emitted.</p>
+
+   <aside class="note">Note: <code>permitted.paths</code> are NOT
+   prepended to the requested library names when the dynamic linker is
+   searching for a shared library. Its main purpose is to allow programers to
+   load shared libraries into an isolated namespace by specifying the full path
+   of the shared library.</aside>
+  </td>
+
+  <td>
+   <p><code>namespace.<wbr/>default.<wbr/>permitted.paths = /system/${LIB}/hw</code></p>
+
+   <p>This indicates that the shared libraries under
+   <code>/system/${LIB}/hw</code> can be loaded into the isolated
+   <code>default</code> namespace.</p>
+
+   <p>For example, without <code>permitted.paths</code>,
+   <code>libaudiohal.so</code> won't be able to load
+   <code>/system/${LIB}/hw/audio.a2dp.default.so</code> into the
+   <code>default</code> namespace.</p>
+  </td>
+ </tr>
+
+ <tr>
+  <td><code>namespace.<wbr/><var>name</var>.<wbr/>asan.permitted.paths</code></td>
+
+  <td>
+   <p>A colon-separated list of directories where the dynamic linker can load
+   the shared libraries when <a href="/devices/tech/debug/asan">Address
+   Sanitizer</a> is enabled.</p>
+
+   <p><code>namespace.<wbr/><var>name</var>.<wbr/>permitted.paths</code> is
+   ignored when <a href="/devices/tech/debug/asan">Address Sanitizer</a> is
+   enabled.</p>
+  </td>
+
+  <td>
+   <p><code>namespace.<wbr/>default.<wbr/>asan.permitted.paths = /data/asan/system/${LIB}/hw:<wbr/>/system/${LIB}/hw</code></p>
+
+   <p>This indicates that when
+   <a href="/devices/tech/debug/asan">Address Sanitizer</a> is enabled shared
+   libraries under <code>/data/asan/system/${LIB}/hw</code> or
+   <code>/system/${LIB}/hw</code> can be loaded to the isolated
+   <code>default</code> namespace.</p>
+  </td>
+ </tr>
+
+ <tr>
+  <td><code>namespace.<wbr/><var>name</var>.<wbr/>visible</code></td>
+
+  <td>
+   <p>A boolean value that indicates whether the program (other than
+   <code>libc</code>) can obtain a linker namespace handle with
+   <code>android_get_exported_namespace()</code> and open a shared library in
+   the linker namespace by passing the handle to
+   <code>android_dlopen_ext()</code>.</p>
+
+   <p>If <code>visible</code> is <code>true</code>,
+   <code>android_get_exported_namespace()</code> always returns the handle if
+   the namespace exists.</p>
+
+   <p>If <code>visible</code> is <code>false</code> (default),
+   <code>android_get_exported_namespace()</code> always returns
+   <code>NULL</code> regardless the presence of the namespace. Shared libraries
+   can only be loaded into this namespace if (1) they are requested by another
+   linker namespace that has a fallback link to this namespace or (2) they are
+   requested by other shared libraries or executables in this namespace.</p>
+  </td>
+
+  <td>
+   <p><code>namespace.<wbr/>sphal.<wbr/>visible = true</code></p>
+
+   <p>This indicates that <code>android_get_exported_namespace("sphal")</code>
+   can return a valid linker namespace handle.</p>
+  </td>
+ </tr>
+</table>
 
 
 
@@ -217,11 +495,11 @@ explicitly ask the dynamic linker to load a shared library in the
 
 <h2 id="linker-namespace-isolation">Linker namespace isolation</h2>
 
-<p>There are three configurations in
+<p>There are three configuration files in
 <code>${android-src}/system/core/rootdir/etc</code>. Depending on the value of
 <code>PRODUCT_TREBLE_LINKER_NAMESPACES</code>, <code>BOARD_VNDK_VERSION</code>,
 and <code>BOARD_VNDK_RUNTIME_DISABLE</code> in <code>BoardConfig.mk</code>,
-different configurations will be selected:</p>
+different configurations are selected:</p>
 
 <table>
  <tr>
@@ -282,7 +560,7 @@ BOARD_VNDK_RUNTIME_DISABLE := true
 
 <p>If <code>BOARD_VNDK_RUNTIME_DISABLE</code> is <code>true</code>,
 <code>${android-src}/system/core/rootdir/etc/ld.config.vndk_lite.txt</code>
-will be installed.</p>
+is installed.</p>
 
 
 
@@ -436,7 +714,7 @@ processes, which is excerpted from the <code>[system]</code> section in
    <code>/product/app</code><br/>
    <code>/product/priv-app</code><br/>
    <code>/data</code><br/>
-   <code>/mnt/expand
+   <code>/mnt/expand</code>
   </td>
  </tr>
 
diff --git a/en/devices/graphics/images/winscope_screenshot.png b/en/devices/graphics/images/winscope_screenshot.png
new file mode 100644
index 00000000..23dcb9b0
--- /dev/null
+++ b/en/devices/graphics/images/winscope_screenshot.png
diff --git a/en/devices/graphics/tracing-win-transitions.html b/en/devices/graphics/tracing-win-transitions.html
new file mode 100644
index 00000000..f86c9741
--- /dev/null
+++ b/en/devices/graphics/tracing-win-transitions.html
@@ -0,0 +1,137 @@
+<html devsite>
+  <head>
+    <title>Tracing Window Transitions</title>
+    <meta name="project_path" value="/_project.yaml" />
+    <meta name="book_path" value="/_book.yaml" />
+  </head>
+  <body>
+  <!--
+      Copyright 2018 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>You can trace window transitions with WinScope, which provides infrastructure and tools to
+    record and analyze Window Manager and Surface Flinger states during and after transitions.
+    WinScope records all pertinent system service states to a trace file, which you can use to
+    replay and step through the transition.
+
+  </p>
+
+  <h2 id="capture_trace">Capturing traces</h2>
+  <p>You can capture traces through Quick Settings or ADB on devices running userdebug or eng
+    builds.
+  </p>
+
+  <h3 id="capture_trace_quick_settings">From Quick Settings</h3>
+  <ol>
+    <li><a href="https://developer.android.com/studio/debug/dev-options#enable"
+           class="external">Enable developer options</a></li>
+    <li>Go to <b>Developer options</b> -> <b>Quick settings developer tiles</b></li>
+    <li>Enable WinScope Trace</li>
+    <li>Open Quick Settings</li>
+    <li>Tap <b>Winscope Trace</b> to enable tracing</li>
+    <li>Run window transitions on the device</li>
+    <li>After you are finished, open Quick Settings and tap <b>Winscope Trace</b> to disable
+      tracing
+    </li>
+  </ol>
+  <p>Traces are written to <code>/data/misc/wmtrace/wm_trace.pb</code> and
+    <code>/data/misc/wmtrace/layers_trace.pb</code>. They are also included in any bugreports.
+  </p>
+
+  <h3 id="capture_trace_quick_adb">From ADB</h3>
+  <h4 id="capture_trace_quick_adb_wm">Window Manager trace</h4>
+  <ol>
+    <li>Enable trace
+      <pre class="devsite-terminal devsite-click-to-copy">adb shell cmd window tracing start</pre>
+    </li>
+    <li>Disable trace
+      <pre class="devsite-terminal devsite-click-to-copy">adb shell cmd window tracing stop</pre>
+    </li>
+    <li>Grab trace file
+      <pre class="devsite-terminal devsite-click-to-copy">adb pull /data/misc/wmtrace/wm_trace.pb wm_trace.pb</pre>
+    </li>
+  </ol>
+  <h4 id="capture_trace_quick_adb_sf">Surface Flinger trace</h4>
+  <ol>
+    <li>Enable trace
+      <pre class="devsite-terminal devsite-click-to-copy">adb shell su root service call SurfaceFlinger 1025 i32 1</pre>
+    </li>
+    <li>Disable trace
+      <pre class="devsite-terminal devsite-click-to-copy">adb shell su root service call SurfaceFlinger 1025 i32 0</pre>
+    </li>
+    <li>Grab trace file
+      <pre class="devsite-terminal devsite-click-to-copy">adb pull /data/misc/wmtrace/layers_trace.pb layers_trace.pb</pre>
+    </li>
+  </ol>
+
+  <h3 id="capture_trace_gen_state">Generating state dumps</h3>
+  <p><p>WinScope can read a snapshot of Window Manager and Surface Flinger's current state from
+    bugreports. The bugreport stores the states as separate proto files inside the
+    <code>proto</code> folder. To generate the state dumps using ADB, run these commands.</p>
+    <h4 id="window_manager_dump">Window Manager</h4>
+    <pre class="devsite-terminal devsite-click-to-copy">adb exec-out dumpsys window --proto > window_dump.pb</pre>
+    <h4 id="surface_flinger_dump">Surface Flinger</h4>
+    <pre class="devsite-terminal devsite-click-to-copy">adb exec-out dumpsys SurfaceFlinger --proto > sf_dump.pb</pre>
+  </p>
+
+  <h2 id="analyze_traces">Analyzing traces</h2>
+  <p>To analyze a trace file, use the WinScope web app. The app can be built from source or opened 
+    from the prebuilt directory.
+  </p>
+  <ol>
+    <li>Download prebuilt artifact from Android source repository
+      <pre class="devsite-terminal devsite-click-to-copy">curl 'https://android.googlesource.com/platform/prebuilts/misc/+/master/common/winscope/winscope.html?format=TEXT' | base64 -d > winscope.html</pre>
+    </li>
+    <li>Open downloaded artifact in a web browser</li>
+    <li>After WinScope opens, click <b>OPEN FILE</b> to load a trace file</li>
+  </ol>
+
+  <h3 id="using_winscope">Using WinScope</h3>
+  <p>After opening a trace file in WinScope, you can analyze the trace in several ways.</p>
+  <img src="images/winscope_screenshot.png" alt="WinScope Screenshot">
+  <p><em>Timeline</em></p>
+  <p>Use arrow keys or click each entry to navigate through the timeline.</p>
+  <p><em>Screen</em></p>
+  <p>Provides a visual representation of every visible window on the screen. Click a window to
+    select the source window in the hierarchy.</p>
+  <p><em>Hierarchy</em></p>
+  <p>Represents each window known to the system. Some windows do not contain buffers, but
+    exist to set policies on its children. Visible windows are marked with the <code>V</code> icon.
+  </p>
+  <p><em>Properties</em></p>
+  <p>Shows state information for the selected entry in the hierarchy.</p>
+
+  <h2 id="winscope_dev">Developing WinScope</h2>
+  <p>
+    When the trace is enabled, Window Manager and Surface Flinger capture and save current state to
+    a file at each point of interest.
+    <code>frameworks/base/core/proto/android/server/windowmanagertrace.proto</code> and
+    <code>frameworks/native/services/surfaceflinger/layerproto/layerstrace.proto</code> contain the
+    proto definitions for their internal states.
+  </p>
+  <h3 id="winscope_dev_checkout">Checking out code and setting up environment</h3>
+    <ol>
+      <li>Install <a href="https://yarnpkg.com" class="external">Yarn</a>, a JS package manager</li>
+      <li><a href="/setup/build/downloading.html">Download Android source</a></li>
+      <li>Navigate to <code>development/tools/winscope</code></li>
+      <li>Run <pre class="devsite-terminal devsite-click-to-copy">yarn install</pre></li>
+    </ol>
+  <h3 id="winscope_dev_build">Building &amp; testing changes</h3>
+    <ol>
+      <li>Navigate to <code>development/tools/winscope</code></li>
+      <li>Run <pre class="devsite-terminal devsite-click-to-copy">yarn run dev</pre></li>
+    </ol>
+ </body>
+</html>
diff --git a/en/devices/tech/admin/enterprise-telephony.html b/en/devices/tech/admin/enterprise-telephony.html
index 95d73bd0..b1b7abe0 100644
--- a/en/devices/tech/admin/enterprise-telephony.html
+++ b/en/devices/tech/admin/enterprise-telephony.html
@@ -24,16 +24,15 @@
 
 
 <p>
-This document outlines the changes made to the telephony-related parts of the
-Android framework in the 7.0 release to support enterprise use cases. This
-document is targeted at manufacturers and focuses entirely on framework-related
-telephony changes. In addition, this document outlines the changes that OEMs
-will need to make to their preloaded applications that handle telephony-related
-functions.
+This document outlines the telephony-related parts of the Android framework that
+support enterprise use cases. This document is targeted at manufacturers and
+focuses entirely on framework-related telephony changes. In addition, this
+document outlines the changes that OEMs will need to make to their preloaded
+applications that handle telephony-related functions.
 </p>
 
 <p>
-Android 7.0 introduces several new features to support enterprise telephony use
+Android 7.0 introduced several new features to support enterprise telephony use
 cases, in particular:
 </p>
 
@@ -41,19 +40,32 @@ cases, in particular:
 <li>Cross profile contact search - Allows applications in the personal profile
 to search for contacts that are supplied by the managed profile contacts
 provider, which can be backed by any datastore, for example local to the device
-or perhaps within an enterprise directory
+or perhaps within an enterprise directory.</li>
 <li>Cross profile contact badging - Allows work contacts to be clearly
-distinguished from personal contacts
+distinguished from personal contacts.</li>
 <li>Making Connection Service managed profile aware - Allows applications within
 the Managed Profile to offer telephony features, such as to provide a separate
 work dialer and work ConnectionService</li>
 </ul>
 
+<p>
+Android 5.0 supported the following enterprise telephony feature:
+</p>
+
+<ul>
+<li>Work contact name lookup for telephone numbers using
+<a
+  class="external"
+  href="https://developer.android.com/reference/android/provider/ContactsContract.PhoneLookup#ENTERPRISE_CONTENT_FILTER_URI">
+<code>ENTERPRISE_CONTENT_FILTER_URI</code></a>
+</li>
+</ul>
+
 <h2 id="examples-and-source">Examples and source</h2>
 
 <p>
 The Android Open Source Project (AOSP) implementations of Dialer, Contacts, and
-Messaging apps have integrated the cross profile contact search  and badging
+Messaging apps have integrated the cross profile contact search and badging
 capability.
 </p>
 
@@ -76,9 +88,9 @@ for contacts in their Dialer Contacts and SMS/MMS Messaging apps.</p>
 <p>
 Cross profile contact search should be implemented using the Enterprise Contacts
 API (<code>ContactsContract.Contacts.ENTERPRISE_CONTENT_FILTER_URI</code> etc.), which can be found
-in the <a
-href="https://developers.google.com/android/work/overview#contacts">EMM developer's overview</a>
-on the Android EMM Developers site.
+in the
+<a class="external" href="https://developer.android.com/work/contacts">Work
+profile contacts</a> guide on the Android Developers site.
 </p>
 
 <h3 id="work-profile-contact-badging">Work profile contact badging</h3>
@@ -86,9 +98,11 @@ on the Android EMM Developers site.
 <p>
 Work profile contact badging can be implemented by checking
 <code>ContactsContract.Directory.isEntepriseDirectoryId()</code> if available or
-<code><a
-href="http://developer.android.com/reference/android/provider/ContactsContract.Contacts.html#isEnterpriseContactId(long)">isEnterpriseContactId</a></code>
-.
+<a
+    class="external"
+    href="http://developer.android.com/reference/android/provider/ContactsContract.Contacts.html#isEnterpriseContactId(long)">
+<code>isEnterpriseContactId()</code></a>. To learn more, see
+<a class="external" href="https://developer.android.com/work/contacts">Work profile contacts</a>.
 </p>
 
 <h3 id="managed-profile-aware-connectionservice">Managed Profile Aware
@@ -108,7 +122,8 @@ The cross profile contact search and badging feature can be validated by:
 
 <ol>
 <li>Setting up a managed profile on a test device using <a
-href="https://github.com/googlesamples/android-testdpc">TestDPC</a>.
+href="https://github.com/googlesamples/android-testdpc"
+class="external">TestDPC</a>.
 <li>Enabling cross profile contact search.
 <li>Adding a local work contact within the managed profile.
 <li>Searching for that contact within the system Dialer Contacts and SMS/MMS
diff --git a/en/devices/tech/config/update.html b/en/devices/tech/config/update.html
index db1a9cd9..e3c6513a 100644
--- a/en/devices/tech/config/update.html
+++ b/en/devices/tech/config/update.html
@@ -30,22 +30,16 @@ in the Android Open Source Project (AOSP).</p>
 
 <p>To update APN information or your CarrierConfig, you need
 to submit the request using a Google Account with an active corporate email
-address (e.g., An APN update request from Acme Company should come from an
+address (e.g., an APN update request from Acme Company should come from an
 email address such as <em>foobar@acme.com</em>).</p>
 <p>If you do not have a Google Account that links to your corporate email
-address, sign out of all Gmail accounts from your browser (we recommend you use
-a private browsing feature such as an incognito window to avoid confusion with
+address, sign out of all Gmail accounts from your browser (we recommend using
+a private browsing feature, such as an incognito window, to avoid confusion with
 your other accounts) and then
-<a href="https://accounts.google.com/SignUpWithoutGmail?hl=en"> create a Google
+<a href="https://accounts.google.com/SignUpWithoutGmail?hl=en">create a Google
 account with your corporate email address</a>.</p>
-<!--<ol>-->
-  <!--<li>Sign out of all gmail accounts from your browser. (We recommend you use a private browsing
-  feature such as an incognito window to avoid confusion with your other accounts.)</li>-->
-  <!--<li>Create a Google account with your corporate email address using:
-  <a href="https://accounts.google.com/SignUpWithoutGmail?hl=en">
-  https://accounts.google.com/SignUpWithoutGmail?hl=en</a></li>-->
-<!--</ol>-->
-<aside class="note"><strong>Note:</strong> Do NOT associate any Gmail accounts with this
+
+<aside class="caution"><strong>Caution:</strong> Do NOT associate any Gmail accounts with this
 newly created account.</aside>
 
 <h2 id="local-environment">Prepare a local development environment</h2>
@@ -98,7 +92,7 @@ requesting.</p>
 
 <h2 id="submit-changes">Submit changes</h2>
 
-<p>When you're ready to make changes, follow these steps:</p>
+<p>To make changes:</p>
 <ol>
   <li>Identify which file to change.</li>
   <li>Make changes to the file.</li>
diff --git a/en/devices/tech/connect/esim-overview.md b/en/devices/tech/connect/esim-overview.md
index 0aa91fcc..11498351 100644
--- a/en/devices/tech/connect/esim-overview.md
+++ b/en/devices/tech/connect/esim-overview.md
@@ -363,8 +363,8 @@ support is disabled.
 
 To implement the LUI, you must provide an activity for the following actions:
 
-+   `android.telephony.euicc.action.MANAGE_EMBEDDED_SUBSCRIPTIONS`
-+   `android.telephony.euicc.action.PROVISION_EMBEDDED_SUBSCRIPTION`
++   `android.service.euicc.action.MANAGE_EMBEDDED_SUBSCRIPTIONS`
++   `android.service.euicc.action.PROVISION_EMBEDDED_SUBSCRIPTION`
 
 As with the service, each activity must require the
 `android.permission.BIND_EUICC_SERVICE` system permission. Each should have an
@@ -380,10 +380,8 @@ For example:
           android:exported="true"
           android:permission="android.permission.BIND_EUICC_SERVICE">
     <intent-filter android:priority="100">
-        <action android:name=
-             "android.telephony.euicc.action.MANAGE_EMBEDDED_SUBSCRIPTIONS" />
-        <action android:name=
-             "android.telephony.euicc.action.PROVISION_EMBEDDED_SUBSCRIPTION" />
+        <action android:name="android.service.euicc.action.MANAGE_EMBEDDED_SUBSCRIPTIONS" />
+        <action android:name="android.service.euicc.action.PROVISION_EMBEDDED_SUBSCRIPTION" />
         <category android:name="android.intent.category.DEFAULT" />
         <category android:name="android.service.euicc.category.EUICC_UI" />
     </intent-filter>
diff --git a/en/legal.html b/en/legal.html
index 181d4bf7..d71ccc0c 100644
--- a/en/legal.html
+++ b/en/legal.html
@@ -40,7 +40,7 @@
 style="margin:0;padding:0 2px;vertical-align:baseline" /> logo, and
 <a href="http://www.google.com/permissions/">other trademarks</a> are property of Google LLC.</p>
 
-<p>See the <a href="/setup/brands.html">Brand Guidelines</a> for additional details.</p>
+<p>See the <a href="/setup/start/brands.html">Brand Guidelines</a> for additional details.</p>
 
 <h2 id="WebSite">Web Site Content</h2>
 
diff --git a/en/security/_toc-bulletins.yaml b/en/security/_toc-bulletins.yaml
index 5914969e..fd95a0ae 100644
--- a/en/security/_toc-bulletins.yaml
+++ b/en/security/_toc-bulletins.yaml
@@ -11,6 +11,8 @@ toc:
   section:
   - title: 2018 Bulletins
     section:
+    - title: December
+      path: /security/bulletin/2018-12-01
     - title: November
       path: /security/bulletin/2018-11-01
     - title: October
@@ -111,6 +113,8 @@ toc:
     path: /security/bulletin/pixel/index
   - title: 2018 Bulletins
     section:
+    - title: December
+      path: /security/bulletin/pixel/2018-12-01
     - title: November
       path: /security/bulletin/pixel/2018-11-01
     - title: October
diff --git a/en/security/apksigning/index.html b/en/security/apksigning/index.html
index 53130c78..2086d0a5 100644
--- a/en/security/apksigning/index.html
+++ b/en/security/apksigning/index.html
@@ -26,9 +26,10 @@
 <p>
 Application signing allows developers to identify the author of the application
 and to update their application without creating complicated interfaces and
-permissions. Every application that is run on the Android platform must be <a
-href="https://developer.android.com/studio/publish/app-signing.html">signed by
-the developer</a>. Applications that attempt to install without being signed
+permissions. Every application that is run on the Android platform must be
+<a class="external" href="https://developer.android.com/studio/publish/app-signing">
+signed by the developer</a>.
+Applications that attempt to install without being signed
 will be rejected by either Google Play or the package installer on the Android
 device.
 </p>
@@ -64,19 +65,19 @@ does not perform CA verification for application certificates.
 Applications are also able to declare security permissions at the Signature
 protection level, restricting access only to applications signed with the same
 key while maintaining distinct UIDs and Application Sandboxes. A closer
-relationship with a shared Application Sandbox is allowed via the <a
-href="https://developer.android.com/guide/topics/manifest/manifest-element.html#uid">shared
-UID feature</a> where two or more applications signed with same developer key
-can declare a shared UID in their manifest.
+relationship with a shared Application Sandbox is allowed via the
+<a class="external" href="https://developer.android.com/guide/topics/manifest/manifest-element#uid">
+shared UID feature</a> where two or more applications signed with same
+developer key can declare a shared UID in their manifest.
 </p>
 <h2 id="schemes">APK signing schemes</h2>
 <p>
 Android supports three application signing schemes:</p>
 <ul>
   <li>v1 scheme: based on JAR signing</li>
-  <li>v2 scheme: <a href="/security/apksigning/v2.html">APK Signature Scheme v2</a>,
+  <li>v2 scheme: <a href="/security/apksigning/v2">APK Signature Scheme v2</a>,
       which was introduced in Android 7.0.</li>
-  <li>v3 scheme: <a href="/security/apksigning/v3.html">APK Signature Scheme v3</a>,
+  <li>v3 scheme: <a href="/security/apksigning/v3">APK Signature Scheme v3</a>,
     which was introduced in Android 9.</li>
 </ul>
 
@@ -89,11 +90,12 @@ contain v1 signatures.
 </p>
 <h3 id="v1">JAR signing (v1 scheme)</h3>
 <p>
-APK signing has been a part of Android from the beginning. It is based on <a
+APK signing has been a part of Android from the beginning. It is based on <a class="external"
 href="https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#Signed_JAR_File">
-signed JAR</a>. For details on using this scheme, see the Android Studio documentation on
-<a href="https://developer.android.com/studio/publish/app-signing.html">Signing
-your app</a>.
+signed JAR</a>. For details on using this scheme, see the Android Studio
+documentation on
+<a  class="external" href="https://developer.android.com/studio/publish/app-signing">
+Signing your app</a>.
 </p>
 <p>
 v1 signatures do not protect some parts of the APK, such as ZIP metadata. The
@@ -110,8 +112,8 @@ scheme) and later. (v2 scheme was updated to v3 in Android P to include
 additional information in the signing block, but otherwise works the same.) The
 contents of the APK are hashed and signed, then the resulting APK Signing Block
 is inserted into the APK. For details on applying the v2+ scheme to an app, see
-<a href="https://developer.android.com/about/versions/nougat/android-7.0.html#apk_signature_v2">APK
-Signature Scheme v2</a>.
+<a  class="external" href="https://developer.android.com/about/versions/nougat/android-7.0#apk_signature_v2">
+APK Signature Scheme v2</a>.
 </p>
 <p>
 During validation, v2+ scheme treats the APK file as a blob and performs signature
@@ -126,7 +128,7 @@ format can be installed on older Android devices (which simply ignore the extra
 data added to the APK), as long as these APKs are also v1-signed.
 </p>
 <p>
-  <img src="../images/apk-validation-process.png" alt="APK signature verification process" id="figure1" />
+  <img src="/security/images/apk-validation-process.png" alt="APK signature verification process" id="figure1" />
 </p>
 <p class="img-caption"><strong>Figure 1.</strong> APK signature verification
 process</p>
@@ -141,7 +143,7 @@ APK was v2-signed, which makes Android 7.0 and newer refuse to verify APKs
 using their v1 signatures.
 </p>
 
-<p>For details on the APK signature verification process, see the <a href="v2.html#verification">
+<p>For details on the APK signature verification process, see the <a href="/security/apksigning/v2#verification">
 Verification section</a> of APK Signature Scheme v2.</p>
 
   </body>
diff --git a/en/security/bulletin/2018-12-01.html b/en/security/bulletin/2018-12-01.html
new file mode 100644
index 00000000..ac427bb9
--- /dev/null
+++ b/en/security/bulletin/2018-12-01.html
@@ -0,0 +1,848 @@
+<html devsite>
+  <head>
+    <title>Android Security Bulletin—December 2018</title>
+    <meta name="project_path" value="/_project.yaml" />
+    <meta name="book_path" value="/_book.yaml" />
+  </head>
+  <body>
+  <!--
+      Copyright 2018 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
+
+          //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><em>Published December 3, 2018 | Updated December 5, 2018</em></p>
+
+<p>
+The Android Security Bulletin contains details of security vulnerabilities
+affecting Android devices. Security patch levels of 2018-12-05 or later address
+all of these issues. To learn how to check a device's security patch level, see
+<a href="https://support.google.com/pixelphone/answer/4457705"
+   class="external">Check and update your Android version</a>.
+</p>
+<p>Android partners are notified of all issues at least a month before
+publication. Source code patches for these issues have been released to the
+Android Open Source Project (AOSP) repository and linked from this bulletin.
+This bulletin also includes links to patches outside of AOSP.</p>
+<p>
+The most severe of these issues is a critical security vulnerability in Media
+framework that could enable a remote attacker using a specially crafted file to
+execute arbitrary code within the context of a privileged process. The
+<a href="/security/overview/updates-resources.html#severity">severity
+assessment</a> is based on the effect that exploiting the vulnerability would
+possibly have on an affected device, assuming the platform and service
+mitigations are turned off for development purposes or if successfully bypassed.
+</p>
+<p>
+We have had no reports of active customer exploitation or abuse of these newly
+reported issues. Refer to the
+<a href="#mitigations">Android and Google Play Protect mitigations</a>
+section for details on the
+<a href="/security/enhancements/">Android security platform protections</a>
+and Google Play Protect, which improve the security of the Android platform.
+</p>
+<p class="note">
+<strong>Note:</strong> Information on the latest over-the-air update (OTA) and
+firmware images for Google devices is available in the
+<a href="/security/bulletin/pixel/2018-12-01">December 2018
+Pixel&hairsp;/&hairsp;Nexus Security Bulletin</a>.
+</p>
+
+<h2 id="mitigations">Android and Google service mitigations</h2>
+
+<p>
+This is a summary of the mitigations provided by the
+<a href="/security/enhancements/">Android security platform</a>
+and service protections such as
+<a href="https://www.android.com/play-protect" class="external">Google Play
+Protect</a>. These capabilities reduce the likelihood that security
+vulnerabilities could be successfully exploited on Android.
+</p>
+<ul>
+<li>Exploitation for many issues on Android is made more difficult by
+enhancements in newer versions of the Android platform. We encourage all users
+to update to the latest version of Android where possible.</li>
+<li>The Android security team actively monitors for abuse through
+<a href="https://www.android.com/play-protect" class="external">Google Play
+Protect</a> and warns users about
+<a href="/security/reports/Google_Android_Security_PHA_classifications.pdf">Potentially
+Harmful Applications</a>. Google Play Protect is enabled by default on devices
+with <a href="http://www.android.com/gms" class="external">Google Mobile
+Services</a>, and is especially important for users who install apps from
+outside of Google Play.</li>
+</ul>
+<h2 id="2018-12-01-details">2018-12-01 security patch level vulnerability details</h2>
+<p>
+In the sections below, we provide details for each of the security
+vulnerabilities that apply to the 2018-12-01 patch level. Vulnerabilities are
+grouped under the component they affect. There is a description of the
+issue and a table with the CVE, associated references,
+<a href="#type">type of vulnerability</a>,
+<a href="/security/overview/updates-resources.html#severity">severity</a>,
+and updated AOSP versions (where applicable). When available, we link the public
+change that addressed the issue to the bug ID, such as the AOSP change list. When
+multiple changes relate to a single bug, additional references are linked to
+numbers following the bug ID.
+</p>
+
+<h3 id="framework">Framework</h3>
+
+<p>The most severe vulnerability in this section could enable a local malicious
+application to execute arbitrary code within the context of a privileged
+process.</p>
+
+<table>
+<col width="21%">
+<col width="21%">
+<col width="14%">
+<col width="14%">
+<col width="30%">
+  <tr>
+    <th>CVE</th>
+    <th>References</th>
+    <th>Type</th>
+    <th>Severity</th>
+    <th>Updated AOSP versions</th>
+  </tr>
+  <tr>
+    <td>CVE-2018-9547</td>
+    <td><a
+      href="https://android.googlesource.com/platform/frameworks/native/+/e6eb42cb2e57747e52e488d54da314bc6eabb546"
+      class="external">A-114223584</a></td>
+    <td>EoP</td>
+    <td>High</td>
+    <td>8.1, 9</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-9548</td>
+    <td><a
+      href="https://android.googlesource.com/platform/frameworks/base/+/c97efaa05124e020d7cc8c6e08be9c3b55ac4ea7" class="external">A-112555574</a></td>
+    <td>ID</td>
+    <td>High</td>
+    <td>7.0, 7.1.1, 7.1.2, 8.0, 8.1, 9</td>
+  </tr>
+</table>
+
+<h3 id="media-framework">Media framework</h3>
+<p>The most severe vulnerability in this section could enable a remote attacker
+using a specially crafted file to execute arbitrary code within the context of
+a privileged process.</p>
+
+<table>
+<col width="21%">
+<col width="21%">
+<col width="14%">
+<col width="14%">
+<col width="30%">
+  <tr>
+    <th>CVE</th>
+    <th>References</th>
+    <th>Type</th>
+    <th>Severity</th>
+    <th>Updated AOSP versions</th>
+  </tr>
+  <tr>
+    <td>CVE-2018-9549</td>
+    <td><a
+      href="https://android.googlesource.com/platform/external/aac/+/6f6d220a3255e7cbd31bcd1220ffb83af0a2779a"
+      class="external">A-112160868</a></td>
+    <td>RCE</td>
+    <td>Critical</td>
+    <td>7.0, 7.1.1, 7.1.2, 8.0, 8.1, 9</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-9550</td>
+    <td><a
+      href="https://android.googlesource.com/platform/external/aac/+/ce97e7d55e1f69683b5bc8f19cc8da8c85bc2cd4"
+      class="external">A-112660981</a></td>
+    <td>RCE</td>
+    <td>Critical</td>
+    <td>9</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-9551</td>
+    <td><a
+      href="https://android.googlesource.com/platform/external/aac/+/0e5db9fee912d367a572b88f0d86f9a33006fa29"
+      class="external">A-112891548</a></td>
+    <td>RCE</td>
+    <td>Critical</td>
+    <td>9</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-9552</td>
+    <td><a
+      href="https://android.googlesource.com/platform/external/libhevc/+/d15da6f960dd2d5b77faced4e799f8bf53785d9c"
+      class="external">A-113260892</a></td>
+    <td>ID</td>
+    <td>Critical</td>
+    <td>7.0, 7.1.1, 7.1.2, 8.0, 8.1, 9</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-9553</td>
+    <td><a
+      href="https://android.googlesource.com/platform/external/libvpx/+/c4c92b2c6ed72a78ea430c3cdce564ec11866a24"
+      class="external">A-116615297</a></td>
+    <td>RCE</td>
+    <td>High</td>
+    <td>7.0, 7.1.1, 7.1.2, 8.0, 8.1, 9</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-9538</td>
+    <td><a
+      href="https://android.googlesource.com/platform/external/v4l2_codec2/+/0a7d252adb774338c2c69a17651aceca3aec1b23"
+      class="external">A-112181526</a></td>
+    <td>EoP</td>
+    <td>High</td>
+    <td>8.1, 9</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-9554</td>
+    <td><a
+      href="https://android.googlesource.com/platform/frameworks/av/+/16f9b39c69626093ae9225b458739707c9a3b4e7"
+      class="external">A-114770654</a></td>
+    <td>ID</td>
+    <td>High</td>
+    <td>7.0, 7.1.1, 7.1.2, 8.0, 8.1</td>
+  </tr>
+</table>
+
+<h3 id="system">System</h3>
+<p>The most severe vulnerability in this section could enable a remote attacker
+using a specially crafted transmission to execute arbitrary code within the
+context of a privileged process.</p>
+
+<table>
+<col width="21%">
+<col width="21%">
+<col width="14%">
+<col width="14%">
+<col width="30%">
+  <tr>
+    <th>CVE</th>
+    <th>References</th>
+    <th>Type</th>
+    <th>Severity</th>
+    <th>Updated AOSP versions</th>
+  </tr>
+  <tr>
+    <td>CVE-2018-9555</td>
+    <td><a
+      href="https://android.googlesource.com/platform/system/bt/+/02fc52878d8dba16b860fbdf415b6e4425922b2c"
+      class="external">A-112321180</a></td>
+    <td>RCE</td>
+    <td>Critical</td>
+    <td>7.0, 7.1.1, 7.1.2, 8.0, 8.1, 9</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-9556</td>
+    <td><a
+      href="https://android.googlesource.com/platform/system/update_engine/+/840a7eae5a6d8250490e8ea430193531f0c4ccd6"
+      class="external">A-113118184</a></td>
+    <td>RCE</td>
+    <td>Critical</td>
+    <td>9</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-9557</td>
+    <td>A-35385357<a href="#asterisk">*</a></td>
+    <td>EoP</td>
+    <td>High</td>
+    <td>7.0, 7.1.1, 7.1.2</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-9558</td>
+    <td><a
+      href="https://android.googlesource.com/platform/system/nfc/+/ce7fcb95d5111ad8c554e7ec8ff02f9b40196cdc"
+      class="external">A-112161557</a></td>
+    <td>EoP</td>
+    <td>High</td>
+    <td>7.0, 7.1.1, 7.1.2, 8.0, 8.1, 9</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-9559</td>
+    <td><a
+      href="https://android.googlesource.com/platform/system/vold/+/c2e37da22aadcdb4a5b7f61a61f824ab8e9b8af9"
+      class="external">A-112731440</a></td>
+    <td>EoP</td>
+    <td>High</td>
+    <td>7.0, 7.1.1, 7.1.2, 8.0, 8.1, 9</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-9560</td>
+    <td><a href="https://android.googlesource.com/platform/system/bt/+/9009da96e00434501d9398bbfbc636902c757632"
+      class="external">A-79946737</a></td>
+    <td>EoP</td>
+    <td>High</td>
+    <td>9</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-9562</td>
+    <td><a
+      href="https://android.googlesource.com/platform/system/bt/+/1bb14c41a72978c6075c5753a8301ddcbb10d409"
+      class="external">A-113164621</a></td>
+    <td>ID</td>
+    <td>High</td>
+    <td>9</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-9566</td>
+    <td><a
+      href="https://android.googlesource.com/platform/system/bt/+/314336a22d781f54ed7394645a50f74d6743267d"
+      class="external">A-74249842</a></td>
+    <td>ID</td>
+    <td>High</td>
+    <td>7.0, 7.1.1, 7.1.2, 8.0, 8.1, 9</td>
+  </tr>
+</table>
+
+<h2 id="2018-12-05-details">2018-12-05 security patch level vulnerability details</h2>
+
+<p>
+In the sections below, we provide details for each of the security
+vulnerabilities that apply to the 2018-12-05 patch level. Vulnerabilities are
+grouped under the component they affect and include details such as the
+CVE, associated references, <a href="#type">type of vulnerability</a>,
+<a href="/security/overview/updates-resources.html#severity">severity</a>,
+component (where applicable), and updated AOSP versions (where applicable). When
+available, we link the public change that addressed the issue to the bug ID,
+such as the AOSP change list. When multiple changes relate to a single bug,
+additional references are linked to numbers following the bug ID.
+</p>
+
+<h3 id="system-05">System</h3>
+
+<p>The most severe vulnerability in this section could lead to remote
+information disclosure with no additional execution privileges needed.</p>
+
+<table>
+<col width="21%">
+<col width="21%">
+<col width="14%">
+<col width="14%">
+<col width="30%">
+  <tr>
+    <th>CVE</th>
+    <th>References</th>
+    <th>Type</th>
+    <th>Severity</th>
+    <th>Component</th>
+  </tr>
+  <tr>
+    <td>CVE-2018-9565</td>
+    <td>A-16680558<a href="#asterisk">*</a></td>
+    <td>ID</td>
+    <td>High</td>
+    <td>OMA-DM</td>
+  </tr>
+</table>
+
+<h3 id="htc-components">HTC components</h3>
+
+<p>The most severe vulnerability in this section could enable a local attacker
+to bypass user interaction requirements in order to gain access to additional
+permissions.</p>
+
+<table>
+<col width="21%">
+<col width="21%">
+<col width="14%">
+<col width="14%">
+<col width="30%">
+  <tr>
+    <th>CVE</th>
+    <th>References</th>
+    <th>Type</th>
+    <th>Severity</th>
+    <th>Component</th>
+  </tr>
+  <tr>
+    <td>CVE-2018-9567</td>
+    <td>A-65543936<a href="#asterisk">*</a></td>
+    <td>EoP</td>
+    <td>High</td>
+    <td>Bootloader</td>
+  </tr>
+</table>
+
+<h3 id="kernel-components">Kernel components</h3>
+
+<p>The most severe vulnerability in this section could enable a local attacker
+to execute arbitrary code within the context of a privileged process.</p>
+
+<table>
+<col width="21%">
+<col width="21%">
+<col width="14%">
+<col width="14%">
+<col width="30%">
+  <tr>
+    <th>CVE</th>
+    <th>References</th>
+    <th>Type</th>
+    <th>Severity</th>
+    <th>Component</th>
+  </tr>
+  <tr>
+    <td>CVE-2018-10840</td>
+    <td>A-116406508<br />
+<a href="https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10840">Upstream kernel</a></td>
+    <td>EoP</td>
+    <td>High</td>
+    <td>ext4 filesystem</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-9568</td>
+    <td>A-113509306<br />
+<a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/net/core/sock.c?id=9d538fa60bad4f7b23193c89e843797a1cf71ef3">Upstream kernel</a></td>
+    <td>EoP</td>
+    <td>High</td>
+    <td>network</td>
+  </tr>
+</table>
+
+<h3 id="qualcomm-components">Qualcomm components</h3>
+
+<p>These vulnerabilities affect Qualcomm components and are described in
+further detail in the appropriate Qualcomm security bulletin or security alert.
+The severity assessment of these issues is provided directly by Qualcomm.</p>
+
+<table>
+<col width="21%">
+<col width="21%">
+<col width="14%">
+<col width="14%">
+<col width="30%">
+  <tr>
+    <th>CVE</th>
+    <th>References</th>
+    <th>Type</th>
+    <th>Severity</th>
+    <th>Component</th>
+  </tr>
+  <tr>
+    <td>CVE-2018-11960</td>
+    <td>A-114042002<br />
+<a href="https://source.codeaurora.org/quic/la/kernel/msm-3.18/commit/?id=18ce15db603e19cfac9a2f4076f255e879100495">QC-CR#2264832</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>HWEngines</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-11961</td>
+    <td>A-114040881<br />
+<a href="https://source.codeaurora.org/quic/le/platform/hardware/qcom/gps/commit/?id=c57ee0a5d3261ab20c35b451d1b3ae2b02a21591">QC-CR#2261813</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>GPS_AP_LINUX</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-11963</td>
+    <td>A-114041685<br />
+<a href="https://source.codeaurora.org/quic/la/kernel/msm-4.4/commit/?id=c9ac3476a91c384a3f2760fabaecef0ad8698d7b">QC-CR#2220770</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>Automotive Multimedia</td>
+  </tr>
+</table>
+
+<h3 id="qualcomm-closed-source-components">Qualcomm closed-source components</h3>
+
+<p>These vulnerabilities affect Qualcomm components and are described in
+further detail in the appropriate Qualcomm security bulletin or security
+alert. The severity assessment of these issues is provided directly by
+Qualcomm.</p>
+
+<table>
+<col width="21%">
+<col width="21%">
+<col width="14%">
+<col width="14%">
+<col width="30%">
+  <tr>
+    <th>CVE</th>
+    <th>References</th>
+    <th>Type</th>
+    <th>Severity</th>
+    <th>Component</th>
+  </tr>
+  <tr>
+    <td>CVE-2017-8248</td>
+    <td>A-78135902<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>Critical</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2017-11004</td>
+    <td>A-66913713<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>Critical</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2017-18141</td>
+    <td>A-67712316<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>Critical</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-5913</td>
+    <td>A-79419833<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>Critical</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-11279</td>
+    <td>A-109678200<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>Critical</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2017-18319</td>
+    <td>A-78284753<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2017-18321</td>
+    <td>A-78283451<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2017-18322</td>
+    <td>A-78285196<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2017-18323</td>
+    <td>A-78284194<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2017-18324</td>
+    <td>A-78284517<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2017-18327</td>
+    <td>A-78240177<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2017-18331</td>
+    <td>A-78239686<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2017-18332</td>
+    <td>A-78284545<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2017-18160</td>
+    <td>A-109660689<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2017-18326</td>
+    <td>A-78240324<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2017-8276</td>
+    <td>A-68141338<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2017-18328</td>
+    <td>A-78286046<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2017-18329</td>
+    <td>A-73539037<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2017-18330</td>
+    <td>A-73539235<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-3595</td>
+    <td>A-71501115<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2017-18320</td>
+    <td>A-33757308<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-11999</td>
+    <td>A-74236942<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-5867</td>
+    <td>A-77485184<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-5868</td>
+    <td>A-77484529<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-5869</td>
+    <td>A-33385206<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2017-5754</td>
+    <td>A-79419639<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-5915</td>
+    <td>A-79420511<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-11267</td>
+    <td>A-109678338<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>Closed-source component</td>
+  </tr>
+  <tr>
+    <td>CVE-2018-11922</td>
+    <td>A-112279564<a href="#asterisk">*</a></td>
+    <td>N/A</td>
+    <td>High</td>
+    <td>Closed-source component</td>
+  </tr>
+</table>
+
+<h2 id="common-questions-and-answers">Common questions and answers</h2>
+
+<p>This section answers common questions that may occur after reading this
+bulletin.</p>
+<p><strong>1. How do I determine if my device is updated to address these
+issues?</strong></p>
+<p>To learn how to check a device's security patch level, see
+<a href="https://support.google.com/pixelphone/answer/4457705#pixel_phones&nexus_devices"
+   class="external">Check and update your Android version</a>.</p>
+<ul>
+<li>Security patch levels of 2018-12-01 or later address all issues associated
+with the 2018-12-01 security patch level.</li>
+<li>Security patch levels of 2018-12-05 or later address all issues associated
+with the 2018-12-05 security patch level and all previous patch levels.</li>
+</ul>
+<p>Device manufacturers that include these updates should set the patch string
+level to:</p>
+<ul>
+ <li>[ro.build.version.security_patch]:[2018-12-01]</li>
+ <li>[ro.build.version.security_patch]:[2018-12-05]</li>
+</ul>
+<p><strong>2. Why does this bulletin have two security patch levels?</strong></p>
+<p>
+This bulletin has two security patch levels so that Android partners have the
+flexibility to fix a subset of vulnerabilities that are similar across all
+Android devices more quickly. Android partners are encouraged to fix all issues
+in this bulletin and use the latest security patch level.
+</p>
+<ul>
+<li>Devices that use the 2018-12-01 security patch level must include all
+issues associated with that security patch level, as well as fixes for all
+issues reported in previous security bulletins.</li>
+<li>Devices that use the security patch level of 2018-12-05 or newer must
+include all applicable patches in this (and previous) security
+bulletins.</li>
+</ul>
+<p>
+Partners are encouraged to bundle the fixes for all issues they are addressing
+in a single update.
+</p>
+<p id="type">
+<strong>3. What do the entries in the <em>Type</em> column mean?</strong>
+</p>
+<p>
+Entries in the <em>Type</em> column of the vulnerability details table
+reference the classification of the security vulnerability.
+</p>
+<table>
+  <col width="25%">
+  <col width="75%">
+  <tr>
+   <th>Abbreviation</th>
+   <th>Definition</th>
+  </tr>
+  <tr>
+   <td>RCE</td>
+   <td>Remote code execution</td>
+  </tr>
+  <tr>
+   <td>EoP</td>
+   <td>Elevation of privilege</td>
+  </tr>
+  <tr>
+   <td>ID</td>
+   <td>Information disclosure</td>
+  </tr>
+  <tr>
+   <td>DoS</td>
+   <td>Denial of service</td>
+  </tr>
+  <tr>
+   <td>N/A</td>
+   <td>Classification not available</td>
+  </tr>
+</table>
+<p>
+<strong>4. What do the entries in the <em>References</em> column mean?</strong>
+</p>
+<p>
+Entries under the <em>References</em> column of the vulnerability details table
+may contain a prefix identifying the organization to which the reference value
+belongs.
+</p>
+<table>
+  <col width="25%">
+  <col width="75%">
+  <tr>
+   <th>Prefix</th>
+   <th>Reference</th>
+  </tr>
+  <tr>
+   <td>A-</td>
+   <td>Android bug ID</td>
+  </tr>
+  <tr>
+   <td>QC-</td>
+   <td>Qualcomm reference number</td>
+  </tr>
+  <tr>
+   <td>M-</td>
+   <td>MediaTek reference number</td>
+  </tr>
+  <tr>
+   <td>N-</td>
+   <td>NVIDIA reference number</td>
+  </tr>
+  <tr>
+   <td>B-</td>
+   <td>Broadcom reference number</td>
+  </tr>
+</table>
+<p id="asterisk">
+<strong>5. What does a * next to the Android bug ID in the <em>References</em>
+column mean?</strong>
+</p>
+<p>
+Issues that are not publicly available have a * next to the Android bug ID in
+the <em>References</em> column. The update for that issue is generally
+contained in the latest binary drivers for Pixel&hairsp;/&hairsp;Nexus devices
+available from the
+<a href="https://developers.google.com/android/drivers" class="external">Google
+Developer site</a>.
+</p>
+<p>
+<strong>6. Why are security vulnerabilities split between this bulletin and
+device&hairsp;/&hairsp;partner security bulletins, such as the
+Pixel&hairsp;/&hairsp;Nexus bulletin?</strong>
+</p>
+<p>
+Security vulnerabilities that are documented in this security bulletin are
+required to declare the latest security patch level on Android
+devices. Additional security vulnerabilities that are documented in the
+device&hairsp;/&hairsp;partner security bulletins are not required for
+declaring a security patch level. Android device and chipset manufacturers are
+encouraged to document the presence of other fixes on their devices through
+their own security websites, such as the
+<a href="https://security.samsungmobile.com/securityUpdate.smsb"
+   class="external">Samsung</a>,
+<a href="https://lgsecurity.lge.com/security_updates.html"
+   class="external">LGE</a>, or
+<a href="/security/bulletin/pixel/"
+   class="external">Pixel&hairsp;/&hairsp;Nexus</a> security bulletins.
+</p>
+
+<h2 id="versions">Versions</h2>
+
+<table>
+  <col width="25%">
+  <col width="25%">
+  <col width="50%">
+  <tr>
+   <th>Version</th>
+   <th>Date</th>
+   <th>Notes</th>
+  </tr>
+  <tr>
+    <td>1.0</td>
+    <td>December 3, 2018</td>
+    <td>Bulletin published</td>
+  </tr>
+  <tr>
+    <td>1.1</td>
+    <td>December 5, 2018</td>
+    <td>Bulletin revised to include AOSP links.</td>
+  </tr>
+</table>
+</body></html>
diff --git a/en/security/bulletin/2018.html b/en/security/bulletin/2018.html
index 8feee59b..3eeceac6 100644
--- a/en/security/bulletin/2018.html
+++ b/en/security/bulletin/2018.html
@@ -36,6 +36,20 @@ of all bulletins, see the <a href="/security/bulletin/index.html">Android Securi
     <th>Published date</th>
     <th>Security patch level</th>
  </tr>
+<tr>
+    <td><a href="/security/bulletin/2018-12-01.html">December 2018</a></td>
+    <td>
+     <a href="/security/bulletin/2018-12-01.html">English</a>&nbsp;/
+     <a href="/security/bulletin/2018-12-01.html?hl=ja">日本語</a>&nbsp;/
+     <a href="/security/bulletin/2018-12-01.html?hl=ko">한국어</a>&nbsp;/
+     <a href="/security/bulletin/2018-12-01.html?hl=ru">ру́сский</a>&nbsp;/
+     <a href="/security/bulletin/2018-12-01.html?hl=zh-cn">中文&nbsp;(中国)</a>&nbsp;/
+     <a href="/security/bulletin/2018-12-01.html?hl=zh-tw">中文&nbsp;(台灣)</a>
+    </td>
+    <td>December 3, 2018</td>
+    <td>2018-12-01<br>
+        2018-12-05</td>
+ </tr>
  <tr>
     <td><a href="/security/bulletin/2018-11-01.html">November 2018</a></td>
     <td>
diff --git a/en/security/bulletin/_translation.yaml b/en/security/bulletin/_translation.yaml
index 7ff6379d..1a07c4e8 100644
--- a/en/security/bulletin/_translation.yaml
+++ b/en/security/bulletin/_translation.yaml
@@ -53,7 +53,7 @@ language:
 cc:
 - daroberts@google.com
 - sac-doc-leads+translation@google.com
-- shaileshs@google.com
+- lhaviland@google.com
 reviewer:
 - daroberts
 product: Android
diff --git a/en/security/bulletin/index.html b/en/security/bulletin/index.html
index 3b13b8df..6fdea4d0 100644
--- a/en/security/bulletin/index.html
+++ b/en/security/bulletin/index.html
@@ -36,13 +36,6 @@ vulnerability details specific to their products, such as:</p>
   <li><a href="https://security.samsungmobile.com/securityUpdate.smsb">Samsung</a></li>
 </ul>
 
-<h3 id="notification">Notifications</h3>
-<p>To get notifications when a new Android bulletin is published, join the
-<a href="https://groups.google.com/forum/#!forum/android-security-updates">Android
-Security Updates group</a>, and set your email delivery preference to receive
-all updates.
-</p>
-
 <h3 id="sources">Sources</h3>
 
 <p>Fixes listed in the public bulletin come from various different sources: the
@@ -68,7 +61,20 @@ Android Open Source Project (AOSP), the upstream Linux kernel, and system-on-chi
     <th>Published date</th>
     <th>Security patch level</th>
  </tr>
-  <tr>
+<tr>
+    <td><a href="/security/bulletin/2018-12-01.html">December 2018</a></td>
+    <td>
+     <a href="/security/bulletin/2018-12-01.html">English</a>&nbsp;/
+     <a href="/security/bulletin/2018-12-01.html?hl=ja">日本語</a>&nbsp;/
+     <a href="/security/bulletin/2018-12-01.html?hl=ko">한국어</a>&nbsp;/
+     <a href="/security/bulletin/2018-12-01.html?hl=ru">ру́сский</a>&nbsp;/
+     <a href="/security/bulletin/2018-12-01.html?hl=zh-cn">中文&nbsp;(中国)</a>&nbsp;/
+     <a href="/security/bulletin/2018-12-01.html?hl=zh-tw">中文&nbsp;(台灣)</a>
+    <td>December 3, 2018</td>
+    <td>2018-12-01<br>
+        2018-12-05</td>
+ </tr>
+ <tr>
     <td><a href="/security/bulletin/2018-11-01.html">November 2018</a></td>
     <td>
      <a href="/security/bulletin/2018-11-01.html">English</a>&nbsp;/
diff --git a/en/security/bulletin/pixel/2018-12-01.html b/en/security/bulletin/pixel/2018-12-01.html
new file mode 100644
index 00000000..3be66d93
--- /dev/null
+++ b/en/security/bulletin/pixel/2018-12-01.html
@@ -0,0 +1,325 @@
+<html devsite>
+  <head>
+    <title>Pixel&hairsp;/&hairsp;Nexus Security Bulletin—December 2018</title>
+    <meta name="project_path" value="/_project.yaml" />
+    <meta name="book_path" value="/_book.yaml" />
+  </head>
+  <body>
+  <!--
+      Copyright 2018 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
+
+          //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><em>Published December 3, 2018</em></p>
+
+<p>
+The Pixel&hairsp;/&hairsp;Nexus Security Bulletin contains details of security
+vulnerabilities and functional improvements affecting <a
+href="https://support.google.com/pixelphone/answer/4457705#pixel_phones&nexus_devices"
+class="external">supported Google Pixel and Nexus devices</a> (Google devices).
+For Google devices, security patch levels of 2018-12-05 or later address all
+issues in this bulletin and all issues in the December 2018 Android Security
+Bulletin. To learn how to check a device's security patch level, see <a
+href="https://support.google.com/pixelphone/answer/4457705"
+class="external">Check & update your Android version</a>.
+</p>
+<p>
+All supported Google devices will receive an update to the 2018-12-05 patch
+level. We encourage all customers to accept these updates to their devices.
+</p>
+<p class="note">
+<strong>Note:</strong> The Google device firmware images are available on the
+<a href="https://developers.google.com/android/images" class="external">Google
+Developer site</a>.
+</p>
+
+<h2 id="announcements">Announcements</h2>
+
+<p>In addition to the security vulnerabilities described in the
+<a href="/security/bulletin/2018-12-01">December 2018 Android Security
+Bulletin</a>, Google devices also contain patches for the security
+vulnerabilities described below. Partners were notified of these issues at
+least a month ago and may choose to incorporate them as part of their device
+updates.
+</p>
+
+<h2 id="security-patches">Security patches</h2>
+<p>
+Vulnerabilities are grouped under the component they affect. There is a
+description of the issue and a table with the CVE, associated references,
+<a href="#type">type of vulnerability</a>,
+<a href="/security/overview/updates-resources#severity">severity</a>,
+and updated Android Open Source Project (AOSP) versions (where applicable).
+When available, we link the public change that addressed the issue to the bug
+ID, such as the AOSP change list. When multiple changes relate to a single bug,
+additional references are linked to numbers following the bug ID.
+</p>
+
+<h3 id="qualcomm-components">Qualcomm components</h3>
+
+<table>
+<col width="21%">
+<col width="21%">
+<col width="14%">
+<col width="14%">
+<col width="30%">
+  <tr>
+    <th>CVE</th>
+    <th>References</th>
+    <th>Type</th>
+    <th>Severity</th>
+    <th>Component</th>
+  </tr>
+  <tr>
+    <td>CVE-2018-11987</td>
+    <td>A-70638103<br />
+<a
+href="https://source.codeaurora.org/quic/la/kernel/msm-4.9/commit/?id=5e9ffcfa152ecb2832990c42fcd8a0f2e63c2c04">
+QC-CR#2258691</a></td>
+    <td>EoP</td>
+    <td>Moderate</td>
+    <td>ION</td>
+  </tr>
+</table>
+
+<h2 id="functional-patches">Functional patches</h2>
+
+<p>The functional patches are included for affected Pixel devices to address
+functionality issues not related to the security of Pixel devices. The patches
+listed in the table below include associated references, the affected category,
+and the affected devices.</p>
+
+<table>
+<col width="15%">
+<col width="15%">
+<col width="40%">
+<col width="30%">
+  <tr>
+   <th>References</th>
+   <th>Category</th>
+   <th>Improvements</th>
+   <th>Devices</th>
+  </tr>
+   <tr>
+   <td>A-112646910</td>
+   <td>Security</td>
+   <td>Improved pattern unlock recognition after reset</td>
+   <td>Pixel, Pixel XL</td>
+  </tr>
+  <tr>
+   <td>A-117522738</td>
+   <td>Performance</td>
+   <td>Improved memory performance in certain circumstances</td>
+   <td>Pixel 2, Pixel 2 XL, Pixel 3, Pixel 3 XL</td>
+  </tr>
+   <tr>
+   <td>A-110969183</td>
+   <td>Camera</td>
+   <td>Improved camera capture performance</td>
+   <td>Pixel 2, Pixel 2 XL, Pixel 3, Pixel 3 XL</td>
+  </tr>
+   <tr>
+   <td>A-111008450</td>
+   <td>Pixel Stand</td>
+   <td>Improved notification visibility when using Pixel Stand</td>
+   <td>Pixel 3, Pixel 3 XL</td>
+  </tr>
+  <tr>
+   <td>A-112376366</td>
+   <td>Android Auto</td>
+   <td>Improved Android Auto compatibility</td>
+   <td>Pixel 2, Pixel 2 XL, Pixel 3, Pixel 3 XL</td>
+  </tr>
+    <tr>
+   <td>A-115666282</td>
+   <td>Camera</td>
+   <td>Adjusted autofocus behavior</td>
+   <td>Pixel 3, Pixel 3 XL</td>
+  </tr>
+    <tr>
+   <td>A-115624433</td>
+   <td>Pixel Stand</td>
+   <td>Improved hotword performance when using Pixel Stand</td>
+   <td>Pixel 3, Pixel 3 XL</td>
+  </tr>
+    <tr>
+   <td>A-116758282</td>
+   <td>Display</td>
+   <td>Improved Always On Display triggering</td>
+   <td>Pixel 3, Pixel 3 XL</td>
+  </tr>
+    <tr>
+   <td>A-111964925</td>
+   <td>Audio</td>
+   <td>Improved USB-C Audio accessory detection</td>
+   <td>Pixel 3 XL</td>
+  </tr>
+    <tr>
+   <td>A-111716107</td>
+   <td>Bluetooth</td>
+   <td>Adjusted volume behavior when toggling Bluetooth</td>
+   <td>Pixel, Pixel XL, Pixel 2, Pixel 2 XL, Pixel 3, Pixel 3 XL</td>
+  </tr>
+    <tr>
+   <td>A-111159723</td>
+   <td>Android Auto</td>
+   <td>Improved audio performance for when using Android Auto in certain vehicles</td>
+   <td>Pixel 3, Pixel 3 XL</td>
+  </tr>
+    <tr>
+   <td>A-112228430</td>
+   <td>Media</td>
+   <td>Improved contouring on HDR color on certain media apps</td>
+   <td>Pixel 3, Pixel 3 XL</td>
+  </tr>
+    <tr>
+   <td>A-113151604</td>
+   <td>Camera</td>
+   <td>Improved camera shutter performance</td>
+   <td>Pixel 3, Pixel 3 XL</td>
+  </tr>
+    <tr>
+   <td>A-111277984</td>
+   <td>Performance</td>
+   <td>Improve unlocking performance when using Bluetooth</td>
+   <td>Pixel, Pixel XL, Pixel 2, Pixel 2 XL, Pixel 3, Pixel 3 XL</td>
+  </tr>
+</table>
+
+<h2 id="common-questions-and-answers">Common questions and answers</h2>
+<p>
+This section answers common questions that may occur after reading this
+bulletin.
+</p>
+<p>
+<strong>1. How do I determine if my device is updated to address these issues?
+</strong>
+</p>
+<p>
+Security patch levels of 2018-12-05 or later address all issues associated with
+the 2018-12-05 security patch level and all previous patch levels. To learn how
+to check a device's security patch level, read the instructions on the <a
+href="https://support.google.com/pixelphone/answer/4457705#pixel_phones&nexus_devices"
+class="external">Pixel and Nexus update schedule</a>.
+</p>
+<p id="type">
+<strong>2. What do the entries in the <em>Type</em> column mean?</strong>
+</p>
+<p>
+Entries in the <em>Type</em> column of the vulnerability details table reference
+the classification of the security vulnerability.
+</p>
+<table>
+  <col width="25%">
+  <col width="75%">
+  <tr>
+   <th>Abbreviation</th>
+   <th>Definition</th>
+  </tr>
+  <tr>
+   <td>RCE</td>
+   <td>Remote code execution</td>
+  </tr>
+  <tr>
+   <td>EoP</td>
+   <td>Elevation of privilege</td>
+  </tr>
+  <tr>
+   <td>ID</td>
+   <td>Information disclosure</td>
+  </tr>
+  <tr>
+   <td>DoS</td>
+   <td>Denial of service</td>
+  </tr>
+  <tr>
+   <td>N/A</td>
+   <td>Classification not available</td>
+  </tr>
+</table>
+<p>
+<strong>3. What do the entries in the <em>References</em> column mean?</strong>
+</p>
+<p>
+Entries under the <em>References</em> column of the vulnerability details table
+may contain a prefix identifying the organization to which the reference value
+belongs.
+</p>
+<table>
+  <col width="25%">
+  <col width="75%">
+  <tr>
+   <th>Prefix</th>
+   <th>Reference</th>
+  </tr>
+  <tr>
+   <td>A-</td>
+   <td>Android bug ID</td>
+  </tr>
+  <tr>
+   <td>QC-</td>
+   <td>Qualcomm reference number</td>
+  </tr>
+  <tr>
+   <td>M-</td>
+   <td>MediaTek reference number</td>
+  </tr>
+  <tr>
+   <td>N-</td>
+   <td>NVIDIA reference number</td>
+  </tr>
+  <tr>
+   <td>B-</td>
+   <td>Broadcom reference number</td>
+  </tr>
+</table>
+<p id="asterisk">
+<strong>4. What does a * next to the Android bug ID in the <em>References</em>
+column mean?</strong>
+</p>
+<p>
+Issues that are not publicly available have a * next to the Android bug ID in
+the <em>References</em> column. The update for that issue is generally contained
+in the latest binary drivers for Pixel&hairsp;/&hairsp;Nexus devices available
+from the <a href="https://developers.google.com/android/drivers"
+class="external">Google Developer site</a>.
+</p>
+<p>
+<strong>5. Why are security vulnerabilities split between this bulletin and the
+Android Security Bulletins?</strong>
+</p>
+<p>
+Security vulnerabilities that are documented in the Android Security Bulletins
+are required to declare the latest security patch level on Android
+devices. Additional security vulnerabilities, such as those documented in this
+bulletin are not required for declaring a security patch level.
+</p>
+<h2 id="versions">Versions</h2>
+<table>
+  <col width="25%">
+  <col width="25%">
+  <col width="50%">
+  <tr>
+   <th>Version</th>
+   <th>Date</th>
+   <th>Notes</th>
+  </tr>
+  <tr>
+   <td>1.0</td>
+   <td>December 3, 2018</td>
+   <td>Bulletin published.</td>
+  </tr>
+</table>
+</body>
+</html>
diff --git a/en/security/bulletin/pixel/2018.html b/en/security/bulletin/pixel/2018.html
index a7854882..a1cace8f 100644
--- a/en/security/bulletin/pixel/2018.html
+++ b/en/security/bulletin/pixel/2018.html
@@ -38,7 +38,20 @@ Bulletins</a> homepage.</p>
     <th>Published date</th>
     <th>Security patch level</th>
  </tr>
-  <tr>
+<tr>
+    <td><a href="/security/bulletin/pixel/2018-12-01.html">December 2018</a></td>
+    <td>
+     <a href="/security/bulletin/pixel/2018-12-01.html">English</a>&nbsp;/
+     <a href="/security/bulletin/pixel/2018-12-01.html?hl=ja">日本語</a>&nbsp;/
+     <a href="/security/bulletin/pixel/2018-12-01.html?hl=ko">한국어</a>&nbsp;/
+     <a href="/security/bulletin/pixel/2018-12-01.html?hl=ru">ру́сский</a>&nbsp;/
+     <a href="/security/bulletin/pixel/2018-12-01.html?hl=zh-cn">中文&nbsp;(中国)</a>&nbsp;/
+     <a href="/security/bulletin/pixel/2018-12-01.html?hl=zh-tw">中文&nbsp;(台灣)</a>
+    </td>
+    <td>December 3, 2018</td>
+    <td>2018-12-05</td>
+ </tr>
+ <tr>
     <td><a href="/security/bulletin/pixel/2018-11-01.html">November 2018</a></td>
     <td>
      <a href="/security/bulletin/pixel/2018-11-01.html">English</a>&nbsp;/
diff --git a/en/security/bulletin/pixel/index.html b/en/security/bulletin/pixel/index.html
index f89274e6..a32aa036 100644
--- a/en/security/bulletin/pixel/index.html
+++ b/en/security/bulletin/pixel/index.html
@@ -58,7 +58,20 @@ AOSP 24&ndash;48 hours after the Pixel&hairsp;/&hairsp;Nexus bulletin is release
     <th>Published date</th>
     <th>Security patch level</th>
  </tr>
-  <tr>
+<tr>
+    <td><a href="/security/bulletin/pixel/2018-12-01.html">December 2018</a></td>
+    <td>
+     <a href="/security/bulletin/pixel/2018-12-01.html">English</a>&nbsp;/
+     <a href="/security/bulletin/pixel/2018-12-01.html?hl=ja">日本語</a>&nbsp;/
+     <a href="/security/bulletin/pixel/2018-12-01.html?hl=ko">한국어</a>&nbsp;/
+     <a href="/security/bulletin/pixel/2018-12-01.html?hl=ru">ру́сский</a>&nbsp;/
+     <a href="/security/bulletin/pixel/2018-12-01.html?hl=zh-cn">中文&nbsp;(中国)</a>&nbsp;/
+     <a href="/security/bulletin/pixel/2018-12-01.html?hl=zh-tw">中文&nbsp;(台灣)</a>
+   </td>
+    <td>December 3, 2018</td>
+    <td>2018-12-05</td>
+ </tr>
+ <tr>
     <td><a href="/security/bulletin/pixel/2018-11-01.html">November 2018</a></td>
     <td>
      <a href="/security/bulletin/pixel/2018-11-01.html">English</a>&nbsp;/
diff --git a/en/security/overview/acknowledgements.html b/en/security/overview/acknowledgements.html
index d63ad8f0..b6f7074e 100644
--- a/en/security/overview/acknowledgements.html
+++ b/en/security/overview/acknowledgements.html
@@ -37,6 +37,60 @@ Rewards</a> program.</p>
 <p>In 2018, the security acknowledgements are listed by month. In prior years,
 acknowledgements were listed together.</p>
 
+<h4 id="dec-2018">December</h4>
+
+<table>
+  <tr>
+   <th>Researchers</th>
+   <th>CVEs</th>
+  </tr>
+  <tr>
+   <td>Baozeng Ding (<a href="https://twitter.com/sploving1" class="external">@sploving1</a>)
+   </td>
+   <td>CVE-2017-18320</td>
+  </tr>
+  <tr>
+   <td>Daniel Micay (<a href="https://twitter.com/DanielMicay" class="external">@DanielMicay</a>)
+   </td>
+   <td>CVE-2018-9567</td>
+  </tr>
+  <tr>
+   <td>Hao Chen and Guang Gong of Alpha Team, Qihoo 360 Technology Co. Ltd.</td>
+   <td>CVE-2018-9557</td>
+  </tr>
+  <tr>
+   <td>Joydeep Mitra and Venkatesh-Prasad Ranganath of Ghera project at
+   Kansas State University, USA</td>
+   <td>CVE-2018-9548</td>
+  </tr>
+  <tr>
+   <td>Mingjian Zhou (周明建) (
+     <a href="https://twitter.com/Mingjian_Zhou"
+       class="external">@Mingjian_Zhou</a>)
+   of <a href="http://c0reteam.org/" class="external">C0RE Team</a></td>
+   <td>CVE-2018-9547</td>
+  </tr>
+  <tr>
+   <td>Newroot (<a href="https://twitter.com/newroot" class="external">@newroot</a>)</td>
+   <td>CVE-2018-9560</td>
+  </tr>
+  <tr>
+   <td>Scott Bauer (<a href="https://twitter.com/ScottyBauer1" class="external">@ScottyBauer1</a>)</td>
+   <td>CVE-2018-9555, CVE-2018-9558, CVE-2018-9566</td>
+  </tr>
+  <tr>
+   <td>Yong Wang (王勇) (<a href="https://twitter.com/ThomasKing2014" class="external">@ThomasKing2014</a>)
+   of Alibaba Inc.</td>
+   <td>CVE-2018-9568</td>
+  </tr>
+  <tr>
+   <td>Zinuo Han (<a href="http://weibo.com/ele7enxxh"
+                    class="external">weibo.com/ele7enxxh</a>)
+       of Chengdu Security Response Center, Qihoo 360 Technology Co. Ltd.</td>
+   <td>CVE-2018-9549, CVE-2018-9552, CVE-2018-9553, CVE-2018-9562</td>
+  </tr>
+</table>
+
 <h4 id="nov-2018">November</h4>
 
 <table>
diff --git a/en/setup/_toc-build.yaml b/en/setup/_toc-build.yaml
index 5f4050ac..70abeba2 100644
--- a/en/setup/_toc-build.yaml
+++ b/en/setup/_toc-build.yaml
@@ -11,3 +11,5 @@ toc:
   path: /setup/build/building-kernels
 - title: See Known Issues
   path: /setup/build/known-issues
+- title: Continuous Integration Dashboard
+  path: /setup/build/dashboard
diff --git a/en/setup/build/building-kernels.html b/en/setup/build/building-kernels.html
index cb795c79..a340e5df 100644
--- a/en/setup/build/building-kernels.html
+++ b/en/setup/build/building-kernels.html
@@ -327,7 +327,7 @@ projects. Use <a href="/setup/develop/repo#init">repo</a> to download the
 kernel source for the appropriate branch (as of this writing, <code><var>VERSION</var></code> should be
 <code>4.9-pie-qpr1</code>):</p>
 
-<pre class="devsite-terminal devsite-click-to-copy">repo init -u https://android.googlesource.com/platform/manifest -b android-msm-bluecross-$<var>VERSION</var></pre>
+<pre class="devsite-terminal devsite-click-to-copy">repo init -u https://android.googlesource.com/kernel/manifest -b android-msm-bluecross-$<var>VERSION</var></pre>
 <pre class="devsite-terminal devsite-click-to-copy">repo sync</pre>
 
 <p>Then build the kernel with:</p>
diff --git a/en/setup/build/dashboard.html b/en/setup/build/dashboard.html
new file mode 100644
index 00000000..7dee5bee
--- /dev/null
+++ b/en/setup/build/dashboard.html
@@ -0,0 +1,64 @@
+<html devsite>
+  <head>
+    <title>Continuous Integration Dashboard</title>
+    <meta name="project_path" value="/_project.yaml" />
+    <meta name="book_path" value="/_book.yaml" />
+  </head>
+  <body>
+  <!--
+      Copyright 2018 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>This dashboard provides visibility into the
+  <a href="https://en.wikipedia.org/wiki/Continuous_integration" class="external">continuous
+    integration</a> system used by the Android Open Source Project (AOSP).</p>
+
+<p>Contributors to AOSP can use this dashboard to monitor when their submissions are integrated
+  into the tree. The status color shows whether the integrated change has built successfully
+  across all of our build types. For convenience, the build artifacts
+  from each build are available for download.</p>
+
+<p>Each row represents a build that is completed on
+  Android's automated builders. Each column represents a build target/buildtype combination.
+  Within the grid, in-progress and completed builds are shown. In-progress builds are color-coded
+  with a yellow background, failed builds with a red background, and successful builds with a green
+  background. When a build is completed you can download the build artifacts by clicking the
+  <span class="material-icons">get_app</span>(<strong>View artifacts</strong>) icon, which links to
+  a page where the artifacts can be downloaded. Selecting a square opens a panel at the bottom of
+  the screen with tabs for "Details" where the logs are kept, "Changes" which lists what changes
+  went into a build, and another link to the build artifacts. The dashboard refreshes automatically
+  as new builds are completed.</p>
+
+<p>The dashboard can be found at <a href="https://ci.android.com"
+                                    class="external">ci.android.com</a></p>
+
+<figure><img src="../images/dashboard.png" alt="Image of dashboard"/><figcaption><b>Figure 1</b>:
+  Continuous Integration Dashboard</figcaption></figure>
+
+<p>The attributes of the dashboard include:<p>
+<ul>
+  <li><b>Branch name</b>: Name of the git branch where the builds happen</li>
+  <li><b>Build artifacts</b>: Link to see and download artifacts from this build</li>
+  <li><b>Build ID</b>: Unique ID for each build</li>
+  <li><b>Build target</b>: Device configuration</li>
+  <li><b>Buildtype</b>: Exact configuration of the target, which can be user, userdebug, or eng.
+    For more details, see <a href="/setup/build/building#choose-a-target">Choose a
+    Target</a></li>
+  <li><b>Changes link</b>: Link to the changes included in this build</li>
+  <li><b>Perm link</b>: Permanent link to this build’s page on
+    <a href="https://ci.android.com" class="external">ci.android.com</a></li>
+
+  </body>
+</html>
diff --git a/en/setup/contribute/code-style.html b/en/setup/contribute/code-style.html
index bc9ad880..112c30fe 100644
--- a/en/setup/contribute/code-style.html
+++ b/en/setup/contribute/code-style.html
@@ -23,92 +23,126 @@
 
 
 
-<p>The code styles below are strict rules for contributing Java code to the
-Android Open Source Project (AOSP).  Contributions to the Android platform that
-do not adhere to these rules are generally <em>not accepted</em>. We recognize
-that not all existing code follows these rules, but we expect all new code to
-be compliant.</p>
-
-<p class="note"><strong>Note:</strong> These rules are intended for the Android
-platform and are not required of Android app developers. App developers may
-follow the standard of their choosing, such as the <a
-href="https://google.github.io/styleguide/javaguide.html">Google Java Style
-Guide</a>.</p>
+<p>
+  The code styles below are strict rules for contributing Java code to the
+  Android Open Source Project (AOSP).  Contributions to the Android platform
+  that do not adhere to these rules are generally <em>not accepted</em>. We
+  recognize that not all existing code follows these rules, but we expect all
+  new code to be compliant.
+</p>
+
+<aside class="note">
+  <strong>Note:</strong> These rules are intended for the Android platform and
+  are not required of Android app developers. App developers may follow the
+  standard of their choosing, such as the <a
+  href="https://google.github.io/styleguide/javaguide.html" class="external">Google
+  Java Style Guide</a>.
+</aside>
 
 <h2 id="java-language-rules">Java language rules</h2>
-<p>Android follows standard Java coding conventions with the additional rules
-described below.</p>
 
-<h3 id="dont-ignore-exceptions">Don't ignore exceptions</h3>
-<p>It can be tempting to write code that completely ignores an exception, such
-as:</p>
-<pre><code>void setServerPort(String value) {
+  <p>
+    Android follows standard Java coding conventions with the additional rules
+    described below.
+  </p>
+
+  <h3 id="dont-ignore-exceptions">Don't ignore exceptions</h3>
+
+    <p>
+      It can be tempting to write code that completely ignores an exception, such as:
+    </p>
+
+<pre class="prettyprint">
+  void setServerPort(String value) {
     try {
         serverPort = Integer.parseInt(value);
     } catch (NumberFormatException e) { }
-}
-</code></pre>
-<p>Do not do this. While you may think your code will never encounter this error
-condition or that it is not important to handle it, ignoring exceptions as above
-creates mines in your code for someone else to trigger some day. You must handle
-every Exception in your code in a principled way; the specific handling varies
-depending on the case.</p>
-<p><em>Anytime somebody has an empty catch clause they should have a
-creepy feeling. There are definitely times when it is actually the correct
-thing to do, but at least you have to think about it. In Java you can't escape
-the creepy feeling.</em> -<a href="http://www.artima.com/intv/solid4.html">James Gosling</a></p>
-<p>Acceptable alternatives (in order of preference) are:</p>
-<ul>
-<li>Throw the exception up to the caller of your method.
-<pre><code>void setServerPort(String value) throws NumberFormatException {
-    serverPort = Integer.parseInt(value);
-}
-</code></pre>
-</li>
-<li>Throw a new exception that's appropriate to your level of abstraction.
-<pre><code>void setServerPort(String value) throws ConfigurationException {
+  }
+</pre>
+
+    <p>
+      Do not do this. While you may think your code will never encounter this
+      error condition or that it is not important to handle it, ignoring
+      exceptions as above creates mines in your code for someone else to
+      trigger some day. You must handle every Exception in your code in a
+      principled way; the specific handling varies depending on the case.
+    </p>
+
+    <p class="inline-block">
+      "<em>Anytime somebody has an empty catch clause they should have a creepy
+      feeling. There are definitely times when it is actually the correct
+      thing to do, but at least you have to think about it. In Java you can't
+      escape the creepy feeling.</em>" &mdash;
+      <a href="http://www.artima.com/intv/solid4.html" class="external">James
+      Gosling</a>
+    </p>
+
+    <p>Acceptable alternatives (in order of preference) are:</p>
+
+    <ul>
+      <li>Throw the exception up to the caller of your method.
+<pre class="prettyprint">
+  void setServerPort(String value) throws NumberFormatException {
+      serverPort = Integer.parseInt(value);
+  }
+</pre>
+      </li>
+      <li>
+        Throw a new exception that's appropriate to your level of abstraction.
+<pre class="prettyprint">
+  void setServerPort(String value) throws ConfigurationException {
     try {
         serverPort = Integer.parseInt(value);
     } catch (NumberFormatException e) {
         throw new ConfigurationException("Port " + value + " is not valid.");
     }
-}
-</code></pre>
-</li>
-<li>Handle the error gracefully and substitute an appropriate value in the
-catch {} block.
-<pre><code>/** Set port. If value is not a valid number, 80 is substituted. */
-
-void setServerPort(String value) {
+  }
+</pre>
+      </li>
+      <li>
+        Handle the error gracefully and substitute an appropriate value in the
+        <code>catch {}</code> block.
+<pre class="prettyprint">
+  /** Set port. If value is not a valid number, 80 is substituted. */
+
+  void setServerPort(String value) {
     try {
         serverPort = Integer.parseInt(value);
     } catch (NumberFormatException e) {
         serverPort = 80;  // default port for server
     }
-}
-</code></pre>
-</li>
-<li>Catch the Exception and throw a new <code>RuntimeException</code>. This is
-dangerous, so do it only if you are positive that if this error occurs the
-appropriate thing to do is crash.
-<pre><code>/** Set port. If value is not a valid number, die. */
-
-void setServerPort(String value) {
+  }
+</pre>
+      </li>
+      <li>
+        Catch the Exception and throw a new <code>RuntimeException</code>.
+        This is dangerous, so do it only if you are positive that if this
+        error occurs the appropriate thing to do is crash.
+
+<pre class="prettyprint">
+  /** Set port. If value is not a valid number, die. */
+
+  void setServerPort(String value) {
     try {
         serverPort = Integer.parseInt(value);
     } catch (NumberFormatException e) {
         throw new RuntimeException("port " + value " is invalid, ", e);
     }
-}
-</code></pre>
-<p class="note"><strong>Note</strong> The original exception is passed to the
-constructor for RuntimeException. If your code must compile under Java 1.3, you
-must omit the exception that is the cause.</p>
-</li>
-<li>As a last resort, if you are confident that ignoring the exception is
-appropriate then you may ignore it, but you must also comment why with a good
-reason:
-<pre><code>/** If value is not a valid number, original port number is used. */
+  }
+</pre>
+        <aside class="note">
+          <strong>Note:</strong> The original exception is passed to the
+          constructor for RuntimeException. If your code must compile under
+          Java 1.3, you must omit the exception that is the cause.
+        </aside>
+      </li>
+      <li>
+        As a last resort, if you are confident that ignoring the exception is
+        appropriate then you may ignore it, but you must also comment why with
+        a good reason:
+<pre class="prettyprint">
+/** If value is not a valid number, original port number is used. */
+
 void setServerPort(String value) {
     try {
         serverPort = Integer.parseInt(value);
@@ -117,97 +151,144 @@ void setServerPort(String value) {
         // serverPort will just be unchanged.
     }
 }
-</code></pre>
-</li>
-</ul>
-
-<h3 id="dont-catch-generic-exception">Don't catch generic exception</h3>
-<p>It can also be tempting to be lazy when catching exceptions and do
-something like this:</p>
-<pre><code>try {
-    someComplicatedIOFunction();        // may throw IOException
-    someComplicatedParsingFunction();   // may throw ParsingException
-    someComplicatedSecurityFunction();  // may throw SecurityException
-    // phew, made it all the way
-} catch (Exception e) {                 // I'll just catch all exceptions
-    handleError();                      // with one generic handler!
-}
-</code></pre>
-<p>Do not do this. In almost all cases it is inappropriate to catch generic
-Exception or Throwable (preferably not Throwable because it includes Error
-exceptions). It is very dangerous because it means that Exceptions
-you never expected (including RuntimeExceptions like ClassCastException) get
-caught in application-level error handling. It obscures the failure handling
-properties of your code, meaning if someone adds a new type of Exception in the
-code you're calling, the compiler won't help you realize you need to handle the
-error differently. In most cases you shouldn't be handling different types of
-exception the same way.</p>
-<p>The rare exception to this rule is test code and top-level code where you
-want to catch all kinds of errors (to prevent them from showing up in a UI, or
-to keep a batch job running). In these cases you may catch generic Exception
-(or Throwable) and handle the error appropriately. Think very carefully before
-doing this, though, and put in comments explaining why it is safe in this place.</p>
-<p>Alternatives to catching generic Exception:</p>
-<ul>
-<li>
-<p>Catch each exception separately as separate catch blocks after a single
-try. This can be awkward but is still preferable to catching all Exceptions.
-Beware repeating too much code in the catch blocks.</li></p>
-</li>
-<li>
-<p>Refactor your code to have more fine-grained error handling, with multiple
-try blocks. Split up the IO from the parsing, handle errors separately in each
-case.</p>
-</li>
-<li>
-<p>Rethrow the exception. Many times you don't need to catch the exception at
-this level anyway, just let the method throw it.</p>
-</li>
-</ul>
-<p>Remember: exceptions are your friend! When the compiler complains you're
-not catching an exception, don't scowl. Smile: the compiler just made it
-easier for you to catch runtime problems in your code.</p>
-<h3 id="dont-use-finalizers">Don't use finalizers</h3>
-<p>Finalizers are a way to have a chunk of code executed when an object is
-garbage collected. While they can be handy for doing cleanup (particularly of
-external resources), there are no guarantees as to when a finalizer will be
-called (or even that it will be called at all).</p>
-<p>Android doesn't use finalizers. In most cases, you can do what
-you need from a finalizer with good exception handling. If you absolutely need
-it, define a close() method (or the like) and document exactly when that
-method needs to be called (see InputStream for an example). In this case it is
-appropriate but not required to print a short log message from the finalizer,
-as long as it is not expected to flood the logs.</p>
-
-<h3 id="fully-qualify-imports">Fully qualify imports</h3>
-<p>When you want to use class Bar from package foo,there
-are two possible ways to import it:</p>
-<ul>
-<li><code>import foo.*;</code>
-<p>Potentially reduces the number of import statements.</p></li>
-<li><code>import foo.Bar;</code>
-<p>Makes it obvious what classes are actually used and the code is more readable
-for maintainers.</p></li></ul>
-<p>Use <code>import foo.Bar;</code> for importing all Android code. An explicit
-exception is made for java standard libraries (<code>java.util.*</code>,
-<code>java.io.*</code>, etc.) and unit test code
-(<code>junit.framework.*</code>).</p>
+</pre>
+      </li>
+    </ul>
+
+  <h3 id="dont-catch-generic-exception">Don't catch generic exception</h3>
+
+    <p>
+      It can also be tempting to be lazy when catching exceptions and do
+      something like this:
+    </p>
+
+<pre class="prettyprint">
+  try {
+      someComplicatedIOFunction();        // may throw IOException
+      someComplicatedParsingFunction();   // may throw ParsingException
+      someComplicatedSecurityFunction();  // may throw SecurityException
+      // phew, made it all the way
+  } catch (Exception e) {                 // I'll just catch all exceptions
+      handleError();                      // with one generic handler!
+  }
+</pre>
+
+    <p>
+      Do not do this. In almost all cases it is inappropriate to catch generic
+      Exception or Throwable (preferably not Throwable because it includes
+      Error exceptions). It is very dangerous because it means that Exceptions
+      you never expected (including RuntimeExceptions like ClassCastException)
+      get caught in application-level error handling. It obscures the failure
+      handling properties of your code, meaning if someone adds a new type of
+      Exception in the code you're calling, the compiler won't help you
+      realize you need to handle the error differently. In most cases you
+      shouldn't be handling different types of exception the same way.
+    </p>
+
+    <p>
+      The rare exception to this rule is test code and top-level code where
+      you want to catch all kinds of errors (to prevent them from showing up
+      in a UI, or to keep a batch job running). In these cases you may catch
+      generic Exception (or Throwable) and handle the error appropriately.
+      Think very carefully before doing this, though, and put in comments
+      explaining why it is safe in this place.
+    </p>
+
+    <p>Alternatives to catching generic Exception:</p>
+
+    <ul>
+      <li>
+        Catch each exception separately as part of a multi-catch block, for example:
+<pre class="prettyprint">
+try {
+    ...
+} catch (ClassNotFoundException | NoSuchMethodException e) {
+    ...
+}</pre>
+      </li>
+      <li>
+        Refactor your code to have more fine-grained error handling, with
+        multiple try blocks. Split up the IO from the parsing, handle errors
+        separately in each case.
+      </li>
+      <li>
+        Rethrow the exception. Many times you don't need to catch the
+        exception at this level anyway, just let the method throw it.
+      </li>
+    </ul>
+
+    <p>
+      Remember: exceptions are your friend! When the compiler complains you're
+      not catching an exception, don't scowl. Smile: the compiler just made it
+      easier for you to catch runtime problems in your code.
+    </p>
+
+  <h3 id="dont-use-finalizers">Don't use finalizers</h3>
+
+    <p>
+      Finalizers are a way to have a chunk of code executed when an object is
+      garbage collected. While they can be handy for doing cleanup
+      (particularly of external resources), there are no guarantees as to when
+      a finalizer will be called (or even that it will be called at all).
+    </p>
+
+    <p>
+      Android doesn't use finalizers. In most cases, you can do what you need
+      from a finalizer with good exception handling. If you absolutely need
+      it, define a close() method (or the like) and document exactly when that
+      method needs to be called (see InputStream for an example). In this case
+      it is appropriate but not required to print a short log message from the
+      finalizer, as long as it is not expected to flood the logs.
+    </p>
+
+  <h3 id="fully-qualify-imports">Fully qualify imports</h3>
+
+    <p>
+      When you want to use class Bar from package foo, there are two possible
+      ways to import it:
+    </p>
+
+    <ul>
+      <li><code>import foo.*;</code>
+        <p>Potentially reduces the number of import statements.</p>
+      </li>
+      <li><code>import foo.Bar;</code>
+        <p>
+          Makes it obvious what classes are actually used and the code is more
+          readable for maintainers.
+        </p>
+      </li>
+    </ul>
+
+    <p>
+      Use <code>import foo.Bar;</code> for importing all Android code. An
+      explicit exception is made for java standard libraries (<code>java.util.
+      </code>, <code>java.io.*</code>, etc.) and unit test code
+      (<code>junit.framework.*</code>).
+    </p>
 
 <h2 id="java-library-rules">Java library rules</h2>
-<p>There are conventions for using Android's Java libraries and tools. In some
-cases, the convention has changed in important ways and older code might use a
-deprecated pattern or library. When working with such code, it's okay to
-continue the existing style. When creating new components however, never use
-deprecated libraries.</p>
+
+  <p>
+    There are conventions for using Android's Java libraries and tools. In
+    some cases, the convention has changed in important ways and older code
+    might use a deprecated pattern or library. When working with such code,
+    it's okay to continue the existing style. When creating new components
+    however, never use deprecated libraries.
+  </p>
 
 <h2 id="java-style-rules">Java style rules</h2>
 
-<h3 id="use-javadoc-standard-comments">Use Javadoc standard comments</h3>
-<p>Every file should have a copyright statement at the top, followed by package
-and import statements (each block separated by a blank line) and finally the
-class or interface declaration. In the Javadoc comments, describe what the class
-or interface does.</p>
-<pre><code>/*
+  <h3 id="use-javadoc-standard-comments">Use Javadoc standard comments</h3>
+
+    <p>
+      Every file should have a copyright statement at the top, followed by
+      package and import statements (each block separated by a blank line) and
+      finally the class or interface declaration. In the Javadoc comments,
+      describe what the class or interface does.
+    </p>
+<pre class="prettyprint">
+/*
  * Copyright 2018 The Android Open Source Project
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
@@ -238,62 +319,99 @@ import java.sql.SQLException;
 public class Foo {
     ...
 }
-</code></pre>
-<p>Every class and nontrivial public method you write <em>must</em> contain a
-Javadoc comment with at least one sentence describing what the class or method
-does. This sentence should start with a third person descriptive verb.</p>
-<p>Examples:</p>
-<pre><code>/** Returns the correctly rounded positive square root of a double value. */
+</pre>
+
+    <p>
+      Every class and nontrivial public method you write <em>must</em> contain
+      a Javadoc comment with at least one sentence describing what the class
+      or method does. This sentence should start with a third person
+      descriptive verb.
+    </p>
+
+    <p><strong>Examples</strong></p>
+
+<pre class="prettyprint">
+/** Returns the correctly rounded positive square root of a double value. */
+
 static double sqrt(double a) {
     ...
 }
-</code></pre>
-<p>or</p>
-<pre><code>/**
+</pre>
+
+    <p>or</p>
+
+<pre class="prettyprint">
+/**
  * Constructs a new String by converting the specified array of
  * bytes using the platform's default character encoding.
  */
 public String(byte[] bytes) {
     ...
 }
-</code></pre>
-<p>You do not need to write Javadoc for trivial get and set methods such as
-<code>setFoo()</code> if all your Javadoc would say is "sets Foo". If the method
-does something more complex (such as enforcing a constraint or has an important
-side effect), then you must document it. If it's not obvious what the property
-"Foo" means, you should document it.
-<p>Every method you write, public or otherwise, would benefit from Javadoc.
-Public methods are part of an API and therefore require Javadoc. Android does
-not currently enforce a specific style for writing Javadoc comments, but you
-should follow the instructions <a
-href="http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html">How
-to Write Doc Comments for the Javadoc Tool</a>.</p>
-
-<h3 id="write-short-methods">Write short methods</h3>
-<p>When feasible, keep methods small and focused. We recognize that long methods
-are sometimes appropriate, so no hard limit is placed on method length. If a
-method exceeds 40 lines or so, think about whether it can be broken up without
-harming the structure of the program.</p>
-
-<h3 id="define-fields-in-standard-places">Define fields in standard places</h3>
-<p>Define fields either at the top of the file or immediately before the
-methods that use them.</p>
-
-<h3 id="limit-variable-scope">Limit variable scope</h3>
-<p>Keep the scope of local variables to a minimum. By doing so, you
-increase the readability and maintainability of your code and reduce the
-likelihood of error. Each variable should be declared in the innermost block
-that encloses all uses of the variable.</p>
-<p>Local variables should be declared at the point they are first used. Nearly
-every local variable declaration should contain an initializer. If you don't
-yet have enough information to initialize a variable sensibly, postpone the
-declaration until you do.</p>
-<p>The exception is try-catch statements. If a variable is initialized with the
-return value of a method that throws a checked exception, it must be initialized
-inside a try block. If the value must be used outside of the try block, then it
-must be declared before the try block, where it cannot yet be sensibly
-initialized:</p>
-<pre><code>// Instantiate class cl, which represents some sort of Set
+</pre>
+
+    <p>
+      You do not need to write Javadoc for trivial get and set methods such as
+      <code>setFoo()</code> if all your Javadoc would say is "sets Foo". If
+      the method does something more complex (such as enforcing a constraint
+      or has an important side effect), then you must document it. If it's not
+      obvious what the property "Foo" means, you should document it.
+    </p>
+
+    <p>
+      Every method you write, public or otherwise, would benefit from Javadoc.
+      Public methods are part of an API and therefore require Javadoc. Android
+      does not currently enforce a specific style for writing Javadoc
+      comments, but you should follow the instructions <a
+      href="http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html" class="external">How
+      to Write Doc Comments for the Javadoc Tool</a>.
+    </p>
+
+  <h3 id="write-short-methods">Write short methods</h3>
+
+    <p>
+      When feasible, keep methods small and focused. We recognize that long
+      methods are sometimes appropriate, so no hard limit is placed on method
+      length. If a method exceeds 40 lines or so, think about whether it can
+      be broken up without harming the structure of the program.
+    </p>
+
+  <h3 id="define-fields-in-standard-places">
+    Define fields in standard places
+  </h3>
+
+    <p>
+      Define fields either at the top of the file or immediately before the
+      methods that use them.
+    </p>
+
+  <h3 id="limit-variable-scope">Limit variable scope</h3>
+
+    <p>
+      Keep the scope of local variables to a minimum. By doing so, you
+      increase the readability and maintainability of your code and reduce the
+      likelihood of error. Each variable should be declared in the innermost
+      block that encloses all uses of the variable.
+    </p>
+
+    <p>
+      Local variables should be declared at the point they are first used.
+      Nearly every local variable declaration should contain an initializer.
+      If you don't yet have enough information to initialize a variable
+      sensibly, postpone the declaration until you do.
+    </p>
+
+    <p>
+      The exception is try-catch statements. If a variable is initialized with
+      the return value of a method that throws a checked exception, it must be
+      initialized inside a try block. If the value must be used outside of the
+      try block, then it must be declared before the try block, where it
+      cannot yet be sensibly initialized:
+    </p>
+
+<pre class="prettyprint">
+// Instantiate class cl, which represents some sort of Set
+
 Set s = null;
 try {
     s = (Set) cl.newInstance();
@@ -305,10 +423,15 @@ try {
 
 // Exercise the set
 s.addAll(Arrays.asList(args));
-</code></pre>
-<p>However, even this case can be avoided by encapsulating the try-catch block
-in a method:</p>
-<pre><code>Set createSet(Class cl) {
+</pre>
+
+    <p>
+      However, even this case can be avoided by encapsulating the try-catch
+      block in a method:
+    </p>
+
+<pre class="prettyprint">
+Set createSet(Class cl) {
     // Instantiate class cl, which represents some sort of Set
     try {
         return (Set) cl.newInstance();
@@ -324,103 +447,142 @@ in a method:</p>
 // Exercise the set
 Set s = createSet(cl);
 s.addAll(Arrays.asList(args));
-</code></pre>
-<p>Loop variables should be declared in the for statement itself unless there
-is a compelling reason to do otherwise:</p>
-<pre><code>for (int i = 0; i < n; i++) {
+</pre>
+
+    <p>
+      Loop variables should be declared in the for statement itself unless
+      there is a compelling reason to do otherwise:
+    </p>
+
+<pre class="prettyprint">
+for (int i = 0; i < n; i++) {
     doSomething(i);
 }
-</code></pre>
-<p>and</p>
-<pre><code>for (Iterator i = c.iterator(); i.hasNext(); ) {
+</pre>
+
+    <p>and</p>
+
+<pre class="prettyprint">
+for (Iterator i = c.iterator(); i.hasNext(); ) {
     doSomethingElse(i.next());
 }
-</code></pre>
-
-<h3 id="order-import-statements">Order import statements</h3>
-<p>The ordering of import statements is:</p>
-<ol>
-<li>
-<p>Android imports</p>
-</li>
-<li>
-<p>Imports from third parties (<code>com</code>, <code>junit</code>,
-<code>net</code>, <code>org</code>)</p>
-</li>
-<li>
-<p><code>java</code> and <code>javax</code></p>
-</li>
-</ol>
-<p>To exactly match the IDE settings, the imports should be:</p>
-<ul>
-<li>
-<p>Alphabetical within each grouping, with capital letters before lower case
-letters (e.g. Z before a).</p>
-</li>
-<li>
-<p>Separated by a blank line between each major grouping (<code>android</code>,
-<code>com</code>, <code>junit</code>, <code>net</code>, <code>org</code>,
-<code>java</code>, <code>javax</code>).</p>
-</li>
-</ul>
-<p>Originally, there was no style requirement on the ordering, meaning IDEs were
-either always changing the ordering or IDE developers had to disable the
-automatic import management features and manually maintain the imports. This was
-deemed bad. When java-style was asked, the preferred styles varied wildly and it
-came down to Android needing to simply "pick an ordering and be consistent." So
-we chose a style, updated the style guide, and made the IDEs obey it. We expect
-that as IDE users work on the code, imports in all packages will match this
-pattern without extra engineering effort.</p>
-<p>This style was chosen such that:</p>
-<ul>
-<li>
-<p>The imports people want to look at first tend to be at the top
-(<code>android</code>).</p>
-</li>
-<li>
-<p>The imports people want to look at least tend to be at the bottom
-(<code>java</code>).</p>
-</li>
-<li>
-<p>Humans can easily follow the style.</p>
-</li>
-<li>
-<p>IDEs can follow the style.</p>
-</li>
-</ul>
-<p>Put static imports above all the other imports ordered the same way as
-regular imports.</p>
-
-<h3 id="use-spaces-for-indentation">Use spaces for indentation</h3>
-<p>We use four (4) space indents for blocks and never tabs. When in doubt, be
-consistent with the surrounding code.</p>
-<p>We use eight (8) space indents for line wraps, including function calls and
-assignments. For example, this is correct:</p>
-<pre><code>Instrument i =
+</pre>
+
+  <h3 id="order-import-statements">Order import statements</h3>
+
+    <p>The ordering of import statements is:</p>
+
+    <ol>
+      <li>
+        Android imports
+      </li>
+      <li>
+        Imports from third parties (<code>com</code>, <code>junit</code>,
+        <code>net</code>, <code>org</code>)
+      </li>
+      <li>
+        <code>java</code> and <code>javax</code>
+      </li>
+    </ol>
+
+    <p>To exactly match the IDE settings, the imports should be:</p>
+
+    <ul>
+      <li>
+        Alphabetical within each grouping, with capital letters before lower
+        case letters (e.g. Z before a).
+      </li>
+      <li>
+        Separated by a blank line between each major grouping
+        (<code>android</code>, <code>com</code>, <code>junit</code>,
+        <code>net</code>, <code>org</code>, <code>java</code>,
+        <code>javax</code>).
+      </li>
+    </ul>
+
+    <p>
+      Originally, there was no style requirement on the ordering, meaning IDEs
+      were either always changing the ordering or IDE developers had to
+      disable the automatic import management features and manually maintain
+      the imports. This was deemed bad. When java-style was asked, the
+      preferred styles varied wildly and it came down to Android needing to
+      simply "pick an ordering and be consistent." So we chose a style,
+      updated the style guide, and made the IDEs obey it. We expect that as
+      IDE users work on the code, imports in all packages will match this
+      pattern without extra engineering effort.
+    </p>
+
+    <p>This style was chosen such that:</p>
+
+    <ul>
+      <li>
+        The imports people want to look at first tend to be at the top
+        (<code>android</code>).
+        </li>
+      <li>
+        The imports people want to look at least tend to be at the bottom
+        (<code>java</code>).
+      </li>
+      <li>
+        Humans can easily follow the style.
+      </li>
+      <li>
+        IDEs can follow the style.
+      </li>
+    </ul>
+
+    <p>
+      Put static imports above all the other imports ordered the same way as
+      regular imports.
+    </p>
+
+  <h3 id="use-spaces-for-indentation">Use spaces for indentation</h3>
+
+    <p>
+      We use four (4) space indents for blocks and never tabs. When in doubt,
+      be consistent with the surrounding code.
+    </p>
+
+    <p>
+      We use eight (8) space indents for line wraps, including function calls
+      and assignments.
+    </p>
+
+    <p><span class="compare-better">Recommended</span></p>
+
+<pre class="prettyprint">
+Instrument i =
         someLongExpression(that, wouldNotFit, on, one, line);
-</code></pre>
-<p>and this is not correct:</p>
-<pre><code>Instrument i =
+</pre>
+
+    <p><span class="compare-worse">Not recommended</span></p>
+
+<pre class="prettyprint">
+Instrument i =
     someLongExpression(that, wouldNotFit, on, one, line);
-</code></pre>
-
-<h3 id="follow-field-naming-conventions">Follow field naming conventions</h3>
-<ul>
-<li>
-<p>Non-public, non-static field names start with m.</p>
-</li>
-<li>
-<p>Static field names start with s.</p>
-</li>
-<li>
-<p>Other fields start with a lower case letter.</p>
-</li>
-<li>
-<p>Public static final fields (constants) are ALL_CAPS_WITH_UNDERSCORES.</p>
-</li>
-</ul>
-<p>For example:</p>
-<pre><code>public class MyClass {
+</pre>
+
+  <h3 id="follow-field-naming-conventions">Follow field naming conventions</h3>
+
+    <ul>
+      <li>
+      Non-public, non-static field names start with m.
+    </li>
+    <li>
+      Static field names start with s.
+    </li>
+    <li>
+      Other fields start with a lower case letter.
+    </li>
+    <li>
+      Public static final fields (constants) are ALL_CAPS_WITH_UNDERSCORES.
+    </li>
+  </ul>
+
+  <p>For example:</p>
+
+<pre class="prettyprint">
+public class MyClass {
     public static final int SOME_CONSTANT = 42;
     public int publicField;
     private static MyClass sSingleton;
@@ -428,11 +590,17 @@ assignments. For example, this is correct:</p>
     private int mPrivate;
     protected int mProtected;
 }
-</code></pre>
-<h3 id="use-standard-brace-style">Use standard brace style</h3>
-<p>Braces do not go on their own line; they go on the same line as the code
-before them:</p>
-<pre><code>class MyClass {
+</pre>
+
+  <h3 id="use-standard-brace-style">Use standard brace style</h3>
+
+    <p>
+      Braces do not go on their own line; they go on the same line as the code
+      before them:
+    </p>
+
+<pre class="prettyprint">
+class MyClass {
     int func() {
         if (something) {
             // ...
@@ -443,272 +611,398 @@ before them:</p>
         }
     }
 }
-</code></pre>
-<p>We require braces around the statements for a conditional. Exception: If the
-entire conditional (the condition and the body) fit on one line, you may (but
-are not obligated to) put it all on one line. For example, this is acceptable:</p>
-<pre><code>if (condition) {
+</pre>
+
+    <p>
+      We require braces around the statements for a conditional. Exception: If
+      the entire conditional (the condition and the body) fit on one line, you
+      may (but are not obligated to) put it all on one line. For example, this
+      is acceptable:
+    </p>
+
+<pre class="prettyprint">
+if (condition) {
     body();
 }
-</code></pre>
-<p>and this is acceptable:</p>
-<pre><code>if (condition) body();
-</code></pre>
-<p>but this is not acceptable:</p>
-<pre><code>if (condition)
+</pre>
+
+    <p>and this is acceptable:</p>
+
+<pre class="prettyprint">if (condition) body();</pre>
+
+    <p>but this is not acceptable:</p>
+
+<pre class="prettyprint">
+if (condition)
     body();  // bad!
-</code></pre>
-
-<h3 id="limit-line-length">Limit line length</h3>
-<p>Each line of text in your code should be at most 100 characters long. While
-much discussion has surrounded this rule, the decision remains that 100
-characters is the maximum <em>with the following exceptions</em>:</p>
-<ul>
-<li>If a comment line contains an example command or a literal URL
-longer than 100 characters, that line may be longer than 100 characters for
-ease of cut and paste.</li>
-<li>Import lines can go over the limit because humans rarely see them (this also
-simplifies tool writing).</li>
-</ul>
-
-<h3 id="use-standard-java-annotations">Use standard Java annotations</h3>
-<p>Annotations should precede other modifiers for the same language element.
-Simple marker annotations (e.g. @Override) can be listed on the same line with
-the language element. If there are multiple annotations, or parameterized
-annotations, they should each be listed one-per-line in alphabetical
-order.</p>
-<p>Android standard practices for the three predefined annotations in Java are:</p>
-<ul>
-<li><code>@Deprecated</code>: The @Deprecated annotation must be used whenever
-the use of the annotated element is discouraged. If you use the @Deprecated
-annotation, you must also have a @deprecated Javadoc tag and it should name an
-alternate implementation. In addition, remember that a @Deprecated method is
-<em>still supposed to work</em>. If you see old code that has a @deprecated
-Javadoc tag, please add the @Deprecated annotation.
-</li>
-<li><code>@Override</code>: The @Override annotation must be used whenever a
-method overrides the declaration or implementation from a super-class. For
-example, if you use the @inheritdocs Javadoc tag, and derive from a class (not
-an interface), you must also annotate that the method @Overrides the parent
-class's method.</li>
-<li><code>@SuppressWarnings</code>: The @SuppressWarnings annotation should be
-used only under circumstances where it is impossible to eliminate a warning. If
-a warning passes this "impossible to eliminate" test, the @SuppressWarnings
-annotation <em>must</em> be used, so as to ensure that all warnings reflect
-actual problems in the code.
-<p>When a @SuppressWarnings annotation is necessary, it must be prefixed with
-a TODO comment that explains the "impossible to eliminate" condition. This
-will normally identify an offending class that has an awkward interface. For
-example:</p>
-<pre><code>// TODO: The third-party class com.third.useful.Utility.rotate() needs generics
+</pre>
+
+  <h3 id="limit-line-length">Limit line length</h3>
+
+    <p>
+      Each line of text in your code should be at most 100 characters long.
+      While much discussion has surrounded this rule, the decision remains
+      that 100 characters is the maximum <em>with the following
+      exceptions</em>:
+    </p>
+
+    <ul>
+      <li>
+        If a comment line contains an example command or a literal URL longer
+        than 100 characters, that line may be longer than 100 characters for
+        ease of cut and paste.
+      </li>
+      <li>
+        Import lines can go over the limit because humans rarely see them
+        (this also simplifies tool writing).
+      </li>
+    </ul>
+
+  <h3 id="use-standard-java-annotations">Use standard Java annotations</h3>
+
+    <p>
+      Annotations should precede other modifiers for the same language
+      element. Simple marker annotations (e.g. @Override) can be listed on the
+      same line with the language element. If there are multiple annotations,
+      or parameterized annotations, they should each be listed one-per-line in
+      alphabetical order.
+    </p>
+
+    <p>
+      Android standard practices for the three predefined annotations in Java
+      are:
+    </p>
+
+    <ul>
+      <li>
+        <code>@Deprecated</code>: The @Deprecated annotation must be used
+        whenever the use of the annotated element is discouraged. If you use
+        the @Deprecated annotation, you must also have a @deprecated Javadoc
+        tag and it should name an alternate implementation. In addition,
+        remember that a @Deprecated method is <em>still supposed to work</em>.
+        If you see old code that has a @deprecated Javadoc tag, please add the
+        @Deprecated annotation.
+      </li>
+      <li>
+        <code>@Override</code>: The @Override annotation must be used whenever
+        a method overrides the declaration or implementation from a
+        super-class. For example, if you use the @inheritdocs Javadoc tag, and
+        derive from a class (not an interface), you must also annotate that
+        the method @Overrides the parent class's method.
+      </li>
+      <li>
+        <code>@SuppressWarnings</code>: The @SuppressWarnings annotation
+        should be used only under circumstances where it is impossible to
+        eliminate a warning. If a warning passes this "impossible to
+        eliminate" test, the @SuppressWarnings annotation <em>must</em> be
+        used, so as to ensure that all warnings reflect actual problems in the
+        code.
+
+        <p>
+          When a @SuppressWarnings annotation is necessary, it must be
+          prefixed with a TODO comment that explains the "impossible to
+          eliminate" condition. This will normally identify an offending class
+          that has an awkward interface. For example:
+        </p>
+
+<pre class="prettyprint">
+// TODO: The third-party class com.third.useful.Utility.rotate() needs generics
 &#64;SuppressWarnings("generic-cast")
 List&lt;String&gt; blix = Utility.rotate(blax);
-</code></pre>
-<p>When a @SuppressWarnings annotation is required, the code should be
-refactored to isolate the software elements where the annotation applies.</p>
-</li>
-</ul>
-
-<h3 id="treat-acronyms-as-words">Treat acronyms as words</h3>
-<p>Treat acronyms and abbreviations as words in naming variables, methods, and
-classes to make names more readable:</p>
-<table>
-<thead>
-<tr>
-<th>Good</th>
-<th>Bad</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td>XmlHttpRequest</td>
-<td>XMLHTTPRequest</td>
-</tr>
-<tr>
-<td>getCustomerId</td>
-<td>getCustomerID</td>
-</tr>
-<tr>
-<td>class Html</td>
-<td>class HTML</td>
-</tr>
-<tr>
-<td>String url</td>
-<td>String URL</td>
-</tr>
-<tr>
-<td>long id</td>
-<td>long ID</td>
-</tr>
-</tbody>
-</table>
-<p>As both the JDK and the Android code bases are very inconsistent around
-acronyms, it is virtually impossible to be consistent with the surrounding
-code. Therefore, always treat acronyms as words.</p>
-
-<h3 id="use-todo-comments">Use TODO comments</h3>
-<p>Use TODO comments for code that is temporary, a short-term solution, or
-good-enough but not perfect. TODOs should include the string TODO in all caps,
-followed by a colon:</p>
-<pre><code>// TODO: Remove this code after the UrlTable2 has been checked in.
-</code></pre>
-<p>and</p>
-<pre><code>// TODO: Change this to use a flag instead of a constant.
-</code></pre>
-<p>If your TODO is of the form "At a future date do something" make sure that
-you either include a very specific date ("Fix by November 2005") or a very
-specific event ("Remove this code after all production mixers understand
-protocol V7.").</p>
-
-<h3 id="log-sparingly">Log sparingly</h3>
-<p>While logging is necessary, it has a significantly negative impact on
-performance and quickly loses its usefulness if not kept reasonably
-terse. The logging facilities provides five different levels of logging:</p>
-<ul>
-<li><code>ERROR</code>:
-Use when something fatal has happened, i.e. something will have user-visible
-consequences and won't be recoverable without explicitly deleting some data,
-uninstalling applications, wiping the data partitions or reflashing the entire
-device (or worse). This level is always logged. Issues that justify some logging
-at the ERROR level are typically good candidates to be reported to a
-statistics-gathering server.</li>
-<li><code>WARNING</code>:
-Use when something serious and unexpected happened, i.e. something that will
-have user-visible consequences but is likely to be recoverable without data loss
-by performing some explicit action, ranging from waiting or restarting an app
-all the way to re-downloading a new version of an application or rebooting the
-device. This level is always logged. Issues that justify some logging at the
-WARNING level might also be considered for reporting to a statistics-gathering
-server.</li>
-<li><code>INFORMATIVE:</code>
-Use to note that something interesting to most people happened, i.e. when a
-situation is detected that is likely to have widespread impact, though isn't
-necessarily an error. Such a condition should only be logged by a module that
-reasonably believes that it is the most authoritative in that domain (to avoid
-duplicate logging by non-authoritative components). This level is always logged.
-</li>
-<li><code>DEBUG</code>:
-Use to further note what is happening on the device that could be relevant to
-investigate and debug unexpected behaviors. You should log only what is needed
-to gather enough information about what is going on about your component. If
-your debug logs are dominating the log then you probably should be using verbose
-logging.
-<p>This level will be logged, even on release builds, and is required to be
-surrounded by an <code>if (LOCAL_LOG)</code> or <code>if (LOCAL_LOGD)</code>
-block, where <code>LOCAL_LOG[D]</code> is defined in your class or subcomponent,
-so that there can exist a possibility to disable all such logging. There must
-therefore be no active logic in an <code>if (LOCAL_LOG)</code> block. All the
-string building for the log also needs to be placed inside the <code>if
-(LOCAL_LOG)</code> block. The logging call should not be re-factored out into a
-method call if it is going to cause the string building to take place outside
-of the <code>if (LOCAL_LOG)</code> block.</p>
-<p>There is some code that still says <code>if (localLOGV)</code>. This is
-considered acceptable as well, although the name is nonstandard.</p>
-</li>
-<li><code>VERBOSE</code>:
-Use for everything else. This level will only be logged on debug builds and
-should be surrounded by an <code>if (LOCAL_LOGV)</code> block (or equivalent) so
-it can be compiled out by default. Any string building will be stripped out of
-release builds and needs to appear inside the <code>if (LOCAL_LOGV)</code> block.
-</li>
-</ul>
-<p><em>Notes:</em> </p>
-<ul>
-<li>Within a given module, other than at the VERBOSE level, an
-error should only be reported once if possible. Within a single chain of
-function calls within a module, only the innermost function should return the
-error, and callers in the same module should only add some logging if that
-significantly helps to isolate the issue.</li>
-<li>In a chain of modules, other than at the VERBOSE level, when a
-lower-level module detects invalid data coming from a higher-level module, the
-lower-level module should only log this situation to the DEBUG log, and only
-if logging provides information that is not otherwise available to the caller.
-Specifically, there is no need to log situations where an exception is thrown
-(the exception should contain all the relevant information), or where the only
-information being logged is contained in an error code. This is especially
-important in the interaction between the framework and applications, and
-conditions caused by third-party applications that are properly handled by the
-framework should not trigger logging higher than the DEBUG level. The only
-situations that should trigger logging at the INFORMATIVE level or higher is
-when a module or application detects an error at its own level or coming from
-a lower level.</li>
-<li>When a condition that would normally justify some logging is
-likely to occur many times, it can be a good idea to implement some
-rate-limiting mechanism to prevent overflowing the logs with many duplicate
-copies of the same (or very similar) information.</li>
-<li>Losses of network connectivity are considered common, fully expected, and
-should not be logged gratuitously. A loss of network connectivity
-that has consequences within an app should be logged at the DEBUG or VERBOSE
-level (depending on whether the consequences are serious enough and unexpected
-enough to be logged in a release build).</li>
-<li>Having a full filesystem on a filesystem that is accessible to or on
-behalf of third-party applications should not be logged at a level higher than
-INFORMATIVE.</li>
-<li>Invalid data coming from any untrusted source (including any
-file on shared storage, or data coming through just about any network
-connection) is considered expected and should not trigger any logging at a
-level higher than DEBUG when it's detected to be invalid (and even then
-logging should be as limited as possible).</li>
-<li>Keep in mind that the <code>+</code> operator, when used on Strings,
-implicitly creates a <code>StringBuilder</code> with the default buffer size (16
-characters) and potentially other temporary String objects, i.e.
-that explicitly creating StringBuilders isn't more expensive than relying on
-the default '+' operator (and can be a lot more efficient in fact). Keep
-in mind that code that calls <code>Log.v()</code> is compiled and executed on
-release builds, including building the strings, even if the logs aren't being
-read.</li>
-<li>Any logging that is meant to be read by other people and to be
-available in release builds should be terse without being cryptic, and should
-be reasonably understandable. This includes all logging up to the DEBUG
-level.</li>
-<li>When possible, logging should be kept on a single line if it
-makes sense. Line lengths up to 80 or 100 characters are perfectly acceptable,
-while lengths longer than about 130 or 160 characters (including the length of
-the tag) should be avoided if possible.</li>
-<li>Logging that reports successes should never be used at levels
-higher than VERBOSE.</li>
-<li>Temporary logging used to diagnose an issue that is hard to reproduce should
-be kept at the DEBUG or VERBOSE level and should be enclosed by if blocks that
-allow for disabling it entirely at compile time.</li>
-<li>Be careful about security leaks through the log. Private
-information should be avoided. Information about protected content must
-definitely be avoided. This is especially important when writing framework
-code as it's not easy to know in advance what will and will not be private
-information or protected content.</li>
-<li><code>System.out.println()</code> (or <code>printf()</code> for native code)
-should never be used. System.out and System.err get redirected to /dev/null, so
-your print statements will have no visible effects. However, all the string
-building that happens for these calls still gets executed.</li>
-<li><em>The golden rule of logging is that your logs may not
-unnecessarily push other logs out of the buffer, just as others may not push
-out yours.</em></li>
-</ul>
-
-<h3 id="be-consistent">Be consistent</h3>
-<p>Our parting thought: BE CONSISTENT. If you're editing code, take a few
-minutes to look at the surrounding code and determine its style. If that code
-uses spaces around the if clauses, you should too. If the code comments have
-little boxes of stars around them, make your comments have little boxes of stars
-around them too.</p>
-<p>The point of having style guidelines is to have a common vocabulary of
-coding, so people can concentrate on what you're saying, rather than on how
-you're saying it. We present global style rules here so people know the
-vocabulary, but local style is also important. If the code you add to a file
-looks drastically different from the existing code around it, it throws
-readers out of their rhythm when they go to read it. Try to avoid this.</p>
+</pre>
+
+        <p>
+          When a @SuppressWarnings annotation is required, the code should be
+          refactored to isolate the software elements where the annotation
+          applies.
+        </p>
+      </li>
+    </ul>
+
+  <h3 id="treat-acronyms-as-words">Treat acronyms as words</h3>
+
+    <p>
+      Treat acronyms and abbreviations as words in naming variables, methods,
+      and classes to make names more readable:
+    </p>
+
+    <table>
+      <thead>
+        <tr>
+          <th>Good</th>
+          <th>Bad</th>
+        </tr>
+      </thead>
+      <tbody>
+        <tr>
+          <td>XmlHttpRequest</td>
+          <td>XMLHTTPRequest</td>
+        </tr>
+        <tr>
+          <td>getCustomerId</td>
+          <td>getCustomerID</td>
+        </tr>
+        <tr>
+          <td>class Html</td>
+          <td>class HTML</td>
+        </tr>
+        <tr>
+          <td>String url</td>
+          <td>String URL</td>
+        </tr>
+        <tr>
+          <td>long id</td>
+          <td>long ID</td>
+        </tr>
+      </tbody>
+    </table>
+
+    <p>
+      As both the JDK and the Android code bases are very inconsistent around
+      acronyms, it is virtually impossible to be consistent with the
+      surrounding code. Therefore, always treat acronyms as words.
+    </p>
+
+  <h3 id="use-todo-comments">Use TODO comments</h3>
+
+    <p>
+      Use TODO comments for code that is temporary, a short-term solution, or
+      good-enough but not perfect. TODOs should include the string TODO in all
+      caps, followed by a colon:
+    </p>
+
+<pre class="prettyprint">
+// TODO: Remove this code after the UrlTable2 has been checked in.
+</pre>
+
+    <p>and</p>
+
+<pre class="prettyprint">
+// TODO: Change this to use a flag instead of a constant.
+</pre>
+
+    <p>
+      If your TODO is of the form "At a future date do something" make sure
+      that you either include a very specific date ("Fix by November 2005") or
+      a very specific event ("Remove this code after all production mixers
+      understand protocol V7.").
+    </p>
+
+  <h3 id="log-sparingly">Log sparingly</h3>
+
+    <p>
+      While logging is necessary, it has a significantly negative impact on
+      performance and quickly loses its usefulness if not kept reasonably
+      terse. The logging facilities provides five different levels of logging:
+    </p>
+
+    <ul>
+      <li>
+        <code>ERROR</code>: Use when something fatal has happened, i.e.
+        something will have user-visible consequences and won't be recoverable
+        without explicitly deleting some data, uninstalling applications,
+        wiping the data partitions or reflashing the entire device (or worse).
+        This level is always logged. Issues that justify some logging at the
+        ERROR level are typically good candidates to be reported to a
+        statistics-gathering server.
+      </li>
+      <li>
+        <code>WARNING</code>: Use when something serious and unexpected
+        happened, i.e. something that will have user-visible consequences but
+        is likely to be recoverable without data loss by performing some
+        explicit action, ranging from waiting or restarting an app all the way
+        to re-downloading a new version of an application or rebooting the
+        device. This level is always logged. Issues that justify some logging
+        at the WARNING level might also be considered for reporting to a
+        statistics-gathering server.
+      </li>
+      <li>
+        <code>INFORMATIVE:</code> Use to note that something interesting to
+        most people happened, i.e. when a situation is detected that is likely
+        to have widespread impact, though isn't necessarily an error. Such a
+        condition should only be logged by a module that reasonably believes
+        that it is the most authoritative in that domain (to avoid duplicate
+        logging by non-authoritative components). This level is always logged.
+      </li>
+      <li>
+        <code>DEBUG</code>: Use to further note what is happening on the
+        device that could be relevant to investigate and debug unexpected
+        behaviors. You should log only what is needed to gather enough
+        information about what is going on about your component. If your debug
+        logs are dominating the log then you probably should be using verbose
+        logging.
+
+        <p>
+          This level will be logged, even on release builds, and is required
+          to be surrounded by an <code>if (LOCAL_LOG)</code> or <code>if 
+          LOCAL_LOGD)</code> block, where <code>LOCAL_LOG[D]</code> is defined
+          in your class or subcomponent, so that there can exist a possibility
+          to disable all such logging. There must therefore be no active logic
+          in an <code>if (LOCAL_LOG)</code> block. All the string building for
+          the log also needs to be placed inside the
+          <code>if (LOCAL_LOG)</code> block. The logging call should not be
+          re-factored out into a method call if it is going to cause the
+          string building to take place outside of the
+          <code>if (LOCAL_LOG)</code> block.
+        </p>
+
+        <p>
+          There is some code that still says <code>if (localLOGV)</code>. This
+          is considered acceptable as well, although the name is nonstandard.
+        </p>
+      </li>
+      <li>
+        <code>VERBOSE</code>: Use for everything else. This level will only be
+        logged on debug builds and should be surrounded by an
+        <code>if (LOCAL_LOGV)</code> block (or equivalent) so it can be
+        compiled out by default. Any string building will be stripped out of
+        release builds and needs to appear inside the
+        <code>if (LOCAL_LOGV)</code> block.
+      </li>
+    </ul>
+
+    <h4="log-sparingly-notes">Notes</h4>
+
+      <ul>
+        <li>
+          Within a given module, other than at the VERBOSE level, an error
+          should only be reported once if possible. Within a single chain of
+          function calls within a module, only the innermost function should
+          return the error, and callers in the same module should only add
+          some logging if that significantly helps to isolate the issue.
+        </li>
+        <li>
+          In a chain of modules, other than at the VERBOSE level, when a
+          lower-level module detects invalid data coming from a higher-level
+          module, the lower-level module should only log this situation to the
+          DEBUG log, and only if logging provides information that is not
+          otherwise available to the caller. Specifically, there is no need to
+          log situations where an exception is thrown (the exception should
+          contain all the relevant information), or where the only information
+          being logged is contained in an error code. This is especially
+          important in the interaction between the framework and applications,
+          and conditions caused by third-party applications that are properly
+          handled by the framework should not trigger logging higher than the
+          DEBUG level. The only situations that should trigger logging at the
+          INFORMATIVE level or higher is when a module or application detects
+          an error at its own level or coming from a lower level.
+        </li>
+        <li>
+          When a condition that would normally justify some logging is likely
+          to occur many times, it can be a good idea to implement some
+          rate-limiting mechanism to prevent overflowing the logs with many
+          duplicate copies of the same (or very similar) information.
+        </li>
+        <li>
+          Losses of network connectivity are considered common, fully
+          expected, and should not be logged gratuitously. A loss of network
+          connectivity that has consequences within an app should be logged at
+          the DEBUG or VERBOSE level (depending on whether the consequences
+          are serious enough and unexpected enough to be logged in a release
+          build).
+        </li>
+        <li>
+          Having a full filesystem on a filesystem that is accessible to or on
+          behalf of third-party applications should not be logged at a level
+          higher than INFORMATIVE.
+        </li>
+        <li>
+          Invalid data coming from any untrusted source (including any file on
+          shared storage, or data coming through just about any network
+          connection) is considered expected and should not trigger any
+          logging at a level higher than DEBUG when it's detected to be
+          invalid (and even then logging should be as limited as possible).
+        </li>
+        <li>
+          Keep in mind that the <code>+</code> operator, when used on Strings,
+          implicitly creates a <code>StringBuilder</code> with the default
+          buffer size (16 characters) and potentially other temporary String
+          objects, i.e. that explicitly creating StringBuilders isn't more
+          expensive than relying on the default '+' operator (and can be a lot
+          more efficient in fact). Keep in mind that code that calls
+          <code>Log.v()</code> is compiled and executed on release builds,
+          including building the strings, even if the logs aren't being read.
+        </li>
+        <li>
+          Any logging that is meant to be read by other people and to be
+          available in release builds should be terse without being cryptic,
+          and should be reasonably understandable. This includes all logging
+          up to the DEBUG level.
+        </li>
+        <li>
+          When possible, logging should be kept on a single line if it
+          makes sense. Line lengths up to 80 or 100 characters are perfectly
+          acceptable, while lengths longer than about 130 or 160 characters 
+          including the length of the tag) should be avoided if possible.
+        </li>
+        <li>
+          Logging that reports successes should never be used at levels higher
+          than VERBOSE.
+        </li>
+        <li>
+          Temporary logging used to diagnose an issue that is hard to
+          reproduce should be kept at the DEBUG or VERBOSE level and should be
+          enclosed by if blocks that allow for disabling it entirely at
+          compile time.
+        </li>
+        <li>
+          Be careful about security leaks through the log. Private
+          information should be avoided. Information about protected content
+          must definitely be avoided. This is especially important when
+          writing framework code as it's not easy to know in advance what will
+          and will not be private information or protected content.
+        </li>
+        <li>
+          <code>System.out.println()</code> (or <code>printf()</code> for
+          native code) should never be used. System.out and System.err get
+          redirected to /dev/null, so your print statements will have no
+          visible effects. However, all the string building that happens for
+          these calls still gets executed.
+        </li>
+        <li>
+          <em>The golden rule of logging is that your logs may not
+          unnecessarily push other logs out of the buffer, just as others may
+          not push out yours.</em>
+        </li>
+      </ul>
+
+  <h3 id="be-consistent">Be consistent</h3>
+
+    <p>
+      Our parting thought: BE CONSISTENT. If you're editing code, take a few
+      minutes to look at the surrounding code and determine its style. If that
+      code uses spaces around the if clauses, you should too. If the code
+      comments have little boxes of stars around them, make your comments have
+      little boxes of stars around them too.
+    </p>
+
+    <p>
+      The point of having style guidelines is to have a common vocabulary of
+      coding, so people can concentrate on what you're saying, rather than on
+      how you're saying it. We present global style rules here so people know
+      the vocabulary, but local style is also important. If the code you add
+      to a file looks drastically different from the existing code around it,
+      it throws readers out of their rhythm when they go to read it. Try to
+      avoid this.
+    </p>
 
 <h2 id="javatests-style-rules">Javatests style rules</h2>
-<p>Follow test method naming conventions and use an underscore to separate what
-is being tested from the specific case being tested. This style makes it easier
-to see exactly what cases are being tested. For example:</p>
-<pre><code>testMethod_specificCase1 testMethod_specificCase2
+
+  <p>
+    Follow test method naming conventions and use an underscore to separate
+    what is being tested from the specific case being tested. This style makes
+    it easier to see exactly what cases are being tested. For example:
+  </p>
+
+<pre class="prettyprint">
+testMethod_specificCase1 testMethod_specificCase2
 
 void testIsDistinguishable_protanopia() {
     ColorMatcher colorMatcher = new ColorMatcher(PROTANOPIA)
     assertFalse(colorMatcher.isDistinguishable(Color.RED, Color.BLACK))
     assertTrue(colorMatcher.isDistinguishable(Color.X, Color.Y))
 }
-</code></pre>
+</pre>
 
   </body>
 </html>
diff --git a/en/setup/images/dashboard.png b/en/setup/images/dashboard.png
new file mode 100644
index 00000000..b6fda151
--- /dev/null
+++ b/en/setup/images/dashboard.png
diff --git a/en/setup/start/build-numbers.html b/en/setup/start/build-numbers.html
index 31f53d26..2b114631 100644
--- a/en/setup/start/build-numbers.html
+++ b/en/setup/start/build-numbers.html
@@ -241,6 +241,30 @@ following table.
   </thead>
   <tbody>
     <tr>
+      <td>PQ1A.181205.006.A1</td>
+      <td>android-9.0.0_r22</td>
+      <td>Pie</td>
+      <td>Pixel 3 XL, Pixel 3</td>
+    </tr>
+    <tr>
+      <td>PQ1A.181205.006</td>
+      <td>android-9.0.0_r21</td>
+      <td>Pie</td>
+      <td>Pixel 3 XL, Pixel 3</td>
+    </tr>
+    <tr>
+      <td>PQ1A.181205.002.A1</td>
+      <td>android-9.0.0_r20</td>
+      <td>Pie</td>
+      <td>Pixel XL, Pixel</td>
+    </tr>
+    <tr>
+      <td>PQ1A.181205.002</td>
+      <td>android-9.0.0_r19</td>
+      <td>Pie</td>
+      <td>Pixel 2 XL, Pixel 2</td>
+    </tr>
+    <tr>
       <td>PPR2.181005.003.A1</td>
       <td>android-9.0.0_r18</td>
       <td>Pie</td>
@@ -339,6 +363,18 @@ following table.
       <td>2018-08-05</td>
     </tr>
     <tr>
+      <td>OPM8.181205.001</td>
+      <td>android-8.1.0_r53</td>
+      <td>Oreo</td>
+      <td>Pixel C</td>
+    </tr>
+    <tr>
+      <td>OPM7.181205.001</td>
+      <td>android-8.1.0_r52</td>
+      <td>Oreo</td>
+      <td>Nexus 5X, Nexus 6P</td>
+    </tr>
+    <tr>
       <td>OPM8.181105.002</td>
       <td>android-8.1.0_r51</td>
       <td>Oreo</td>
diff --git a/en/setup/start/p-release-notes.md b/en/setup/start/p-release-notes.md
index 5e42ed73..86ff573e 100644
--- a/en/setup/start/p-release-notes.md
+++ b/en/setup/start/p-release-notes.md
@@ -271,9 +271,8 @@ provide more Settings functionality and easier implementation.
 
 ### Atest
 
-[Atest](https://android.googlesource.com/platform/tools/tradefederation/+/master/atest/README.md){: .external}
-is a new command line tool that allows users to build, install and run Android
-tests locally.
+[Atest](/compatibility/tests/development/atest) is a new command line tool that
+allows users to build, install and run Android tests locally, greatly speeding test re-runs without requiring knowledge of Trade Federation test harness command line options.
 
 ### Compatibility Test Suite (CTS)
 
@@ -769,7 +768,7 @@ vehicle HAL interface.
 
 When working with new Global Navigation Satellite System (GNSS) HALs (v1.1+),
 the Android Framework will monitor Android Settings. Partners can change the
-Settings from Google Play Services or other system updatees. These settings
+Settings from Google Play Services or other system updates. These settings
 tell the GNSS HAL if certain GNSS satellites should not be used. This can be
 useful in case of persistent GNSS satellite or constellation errors, or to
 react more rapidly to GNSS HAL implementation issues that may occur when