diff --git a/10_software-compatibility-testing/10_1_compatibility_test_suite.md b/10_software-compatibility-testing/10_1_compatibility_test_suite.md
index 1e4307c..a2159f7 100644
--- a/10_software-compatibility-testing/10_1_compatibility_test_suite.md
+++ b/10_software-compatibility-testing/10_1_compatibility_test_suite.md
@@ -20,4 +20,4 @@
 software is completed.
 
 *    SHOULD use the reference implementation in the Android Open Source tree
-as much as possible.
\ No newline at end of file
+as much as possible.
diff --git a/11_updatable-software/11_0_intro.md b/11_updatable-software/11_0_intro.md
index 1be0c9f..b5637a7 100644
--- a/11_updatable-software/11_0_intro.md
+++ b/11_updatable-software/11_0_intro.md
@@ -16,6 +16,12 @@
 application shared data. Note that the upstream Android software includes an
 update mechanism that satisfies this requirement.
 
+*    [C-0-3] The entire update MUST be signed and the on-device update mechanism
+     MUST verify the update and signature against a public key stored on device.
+*    [C-SR] The signing mechanism is STRONGLY RECOMMENDED to hash the update
+     with SHA-256 and validate the hash against the public key using ECDSA NIST
+     P-256.
+
 If the device implementations includes support for an unmetered data
 connection such as 802.11 or Bluetooth PAN (Personal Area Network) profile,
 then, they:
diff --git a/12_document-changelog/12_0_intro.md b/12_document-changelog/12_0_intro.md
index 4027753..e192f96 100644
--- a/12_document-changelog/12_0_intro.md
+++ b/12_document-changelog/12_0_intro.md
@@ -31,4 +31,3 @@
 
 For best viewing, append the `pretty=full` and `no-merges` URL parameters to your
 changelog URLs.
-
diff --git a/1_introduction/1_0_intro.md b/1_introduction/1_0_intro.md
index 1985ee4..ce2e04d 100644
--- a/1_introduction/1_0_intro.md
+++ b/1_introduction/1_0_intro.md
@@ -40,4 +40,3 @@
 documentation, the SDK documentation is considered authoritative. Any technical
 details provided in the linked resources throughout this document are
 considered by inclusion to be part of this Compatibility Definition.
-
diff --git a/1_introduction/1_1_structure.md b/1_introduction/1_1_structure.md
index 11fdaf8..423d82d 100644
--- a/1_introduction/1_1_structure.md
+++ b/1_introduction/1_1_structure.md
@@ -26,10 +26,11 @@
      *    H: Android Handheld device
      *    T: Android Television device
      *    A: Android Automotive implementation
+     *    W: Android Watch implementation
      *    Tab: Android Tablet implementation
 *    Condition ID
      *    When the requirement is unconditional, this ID is set as 0.
-     *    When the requirement is conditional, 1 is assinged for the 1st
+     *    When the requirement is conditional, 1 is assigned for the 1st
           condition and the number increments by 1 within the same section and
           the same device type.
 *    Requirement ID
diff --git a/2_device-types/2_2_handheld-reqs.md b/2_device-types/2_2_handheld-reqs.md
index 494fe65..48a5097 100644
--- a/2_device-types/2_2_handheld-reqs.md
+++ b/2_device-types/2_2_handheld-reqs.md
@@ -22,10 +22,12 @@
 
 Handheld device implementations:
 
-*   [[7.1](#7_1_display_and_graphics).1.1/H-0-1] MUST have a screen at least
-2.5 inches in physical diagonal size.
+*   [[7.1](#7_1_display_and_graphics).1.1/H-0-1] MUST have at least one
+Android-compatible display at least 2.5 inches in physical diagonal size and
+each Android-compatible display MUST meet all requirements described on this
+document.
 *   [[7.1](#7_1_display_and_graphics).1.3/H-SR] Are STRONGLY RECOMMENDED to
-provide users an affordance to change the display size.(Screen Density)
+provide users an affordance to change the display size (screen density).
 
 If Handheld device implementations claim support for high dynamic range
 displays through [`Configuration.isScreenHdr()`
@@ -46,8 +48,11 @@
 behavior of the compatibility mode itself.
 *   [[7.2](#7_2_input_devices).1/H-0-1] MUST include support for third-party
 Input Method Editor (IME) applications.
-*   [[7.2](#7_2_input_devices).3/H-0-1] MUST provide the Home, Recents, and Back
-functions.
+*   [[7.2](#7_2_input_devices).3/H-0-3] MUST provide the Home function on
+    all the Android-compatible displays that provide the home screen.
+*   [[7.2](#7_2_input_devices).3/H-0-4] MUST provide the Back function on all
+    the Android-compatible displays and the Recents function on at least one of
+    the Android-compatible displays.
 *   [[7.2](#7_2_input_devices).3/H-0-2] MUST send both the normal and long press
 event of the Back function ([`KEYCODE_BACK`](
 http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK))
@@ -69,7 +74,19 @@
 *  [[7.3](#7_3_sensors).1/H-1-1] MUST be able to report events up to a frequency
 of at least 100 Hz.
 
-If Handheld device implementations include a gyroscope, they:
+If Handheld device implementations include a GPS/GNSS receiver and report the
+capability to applications through the `android.hardware.location.gps` feature
+flag, they:
+
+*  [[7.3](#7_3_sensors).3/H-2-1] MUST report GNSS measurements, as soon as they
+are found, even if a location calculated from GPS/GNSS is not yet reported.
+*  [[7.3](#7_3_sensors).3/H-2-2] MUST report GNSS pseudoranges and pseudorange
+rates, that, in open-sky conditions after determining the location, while
+stationary or moving with less than 0.2 meter per second squared of
+acceleration, are sufficient to calculate position within 20 meters, and speed
+within 0.2 meters per second, at least 95% of the time.
+
+If Handheld device implementations include a 3-axis gyroscope, they:
 
 *  [[7.3](#7_3_sensors).4/H-1-1] MUST be able to report events up to a frequency
 of at least 100 Hz.
@@ -81,7 +98,7 @@
 
 Handheld device implementations:
 
-*  [[7.3](#7_3_sensors).12/H-SR] Are RECOMMENDED to support pose sensor with 6
+*  [[7.3](#7_3_sensors).11/H-SR] Are RECOMMENDED to support pose sensor with 6
 degrees of freedom.
 *  [[7.4](#7_4_data_connectivity).3/H] SHOULD include support for Bluetooth and
 Bluetooth LE.
@@ -90,6 +107,15 @@
 
 *  [[7.4](#7_4_data_connectivity).7/H-1-1] MUST provide the data saver mode.
 
+If Handheld device implementations include a logical camera device that lists
+capabilities using
+[`CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA`](
+https://developer.android.com/reference/android/hardware/camera2/CameraMetadata#REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA),
+they:
+
+*   [[7.5](#7_5_camera).4/H-1-1] MUST have normal field of view (FOV) by default
+    and it MUST be between 50 and 90 degrees.
+
 Handheld device implementations:
 
 *  [[7.6](#7_6_memory_and_storage).1/H-0-1] MUST have at least 4 GB of
@@ -175,6 +201,13 @@
 *   [[7.7](#7_7_usb).1/H-1-1] MUST implement the Android Open Accessory (AOA)
 API.
 
+If Handheld device implementations include a USB port supporting host mode,
+they:
+
+*   [[7.7](#7_7_usb).2/H-1-1] MUST implement the [USB audio class](
+http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO)
+as documented in the Android SDK documentation.
+
 Handheld device implementations:
 
 *   [[7.8](#7_8_audio).1/H-0-1] MUST include a microphone.
@@ -190,29 +223,156 @@
 implementing `android.service.vr.VrListenerService` that can be enabled by VR
 applications via `android.app.Activity#setVrModeEnabled`.
 
+If Handheld device implementations include one or more USB-C port(s) in host
+mode and implement (USB audio class), in addition to requirements in
+[section 7.7.2](#7_7_2_USB_host_mode), they:
+
+*    [[7.8](#7_8_audio).2.2/H-1-1] MUST provide the following software mapping
+of HID codes:
+
+<table>
+  <tr>
+   <th>Function</th>
+   <th>Mappings</th>
+   <th>Context</th>
+   <th>Behavior</th>
+  </tr>
+  <tr>
+   <td rowspan="6">A</td>
+   <td rowspan="6"><strong>HID usage page</strong>: 0x0C<br>
+       <strong>HID usage</strong>: 0x0CD<br>
+       <strong>Kernel key</strong>: <code>KEY_PLAYPAUSE</code><br>
+       <strong>Android key</strong>: <code>KEYCODE_MEDIA_PLAY_PAUSE</code></td>
+   <td rowspan="2">Media playback</td>
+   <td><strong>Input</strong>: Short press<br>
+       <strong>Output</strong>: Play or pause</td>
+  </tr>
+  <tr>
+   <td><strong>Input</strong>: Long press<br>
+       <strong>Output</strong>: Launch voice command<br>
+       <strong>Sends</strong>:
+       <code>android.speech.action.VOICE_SEARCH_HANDS_FREE</code> if the device
+       is locked or its screen is off. Sends
+       <code>android.speech.RecognizerIntent.ACTION_WEB_SEARCH</code> otherwise</td>
+  </tr>
+  <tr>
+   <td rowspan="2">Incoming call</td>
+   <td><strong>Input</strong>: Short press<br>
+       <strong>Output</strong>: Accept call</td>
+  </tr>
+  <tr>
+   <td><strong>Input</strong>: Long press<br>
+       <strong>Output</strong>: Reject call</td>
+  </tr>
+  <tr>
+   <td rowspan="2">Ongoing call</td>
+   <td><strong>Input</strong>: Short press<br>
+       <strong>Output</strong>: End call</td>
+  </tr>
+  <tr>
+   <td><strong>Input</strong>: Long press<br>
+       <strong>Output</strong>: Mute or unmute microphone</td>
+  </tr>
+  <tr>
+   <td>B</td>
+   <td><strong>HID usage page</strong>: 0x0C<br>
+       <strong>HID usage</strong>: 0x0E9<br>
+       <strong>Kernel key</strong>: <code>KEY_VOLUMEUP</code><br>
+       <strong>Android key</strong>: <code>VOLUME_UP</code></td>
+   <td>Media playback, Ongoing call</td>
+   <td><strong>Input</strong>: Short or long press<br>
+       <strong>Output</strong>: Increases the system or headset volume</td>
+  </tr>
+  <tr>
+   <td>C</td>
+   <td><strong>HID usage page</strong>: 0x0C<br>
+       <strong>HID usage</strong>: 0x0EA<br>
+       <strong>Kernel key</strong>: <code>KEY_VOLUMEDOWN</code><br>
+       <strong>Android key</strong>: <code>VOLUME_DOWN</code></td>
+   <td>Media playback, Ongoing call</td>
+   <td><strong>Input</strong>: Short or long press<br>
+       <strong>Output</strong>: Decreases the system or headset volume</td>
+  </tr>
+  <tr>
+   <td>D</td>
+   <td><strong>HID usage page</strong>: 0x0C<br>
+       <strong>HID usage</strong>: 0x0CF<br>
+       <strong>Kernel key</strong>: <code>KEY_VOICECOMMAND</code><br>
+       <strong>Android key</strong>: <code>KEYCODE_VOICE_ASSIST</code></td>
+   <td>All. Can be triggered in any instance.</td>
+   <td><strong>Input</strong>: Short or long press<br>
+       <strong>Output</strong>: Launch voice command</td>
+  </tr>
+</table>
+
+*    [[7.8](#7_8_audio).2.2/H-1-2] MUST trigger [ACTION_HEADSET_PLUG](https://developer.android.com/reference/android/content/Intent#ACTION_HEADSET_PLUG)
+upon a plug insert, but only after the USB audio interfaces and endpoints have
+been properly enumerated in order to identify the type of terminal connected.
+
+When the USB audio terminal types 0x0302 is detected, they:
+
+*    [[7.8](#7_8_audio).2.2/H-2-1] MUST broadcast Intent ACTION_HEADSET_PLUG with
+"microphone" extra set to 0.
+
+When the USB audio terminal types 0x0402 is detected, they:
+
+*    [[7.8](#7_8_audio).2.2/H-3-1] MUST broadcast Intent ACTION_HEADSET_PLUG with
+"microphone" extra set to 1.
+
+When API AudioManager.getDevices() is called while the USB peripheral is
+connected they:
+
+*    [[7.8](#7_8_audio).2.2/H-4-1] MUST list a device of type [AudioDeviceInfo.TYPE_USB_HEADSET](https://developer.android.com/reference/android/media/AudioDeviceInfo#TYPE_USB_HEADSET)
+and role isSink() if the USB audio terminal type field is 0x0302.
+
+*    [[7.8](#7_8_audio).2.2/H-4-2] MUST list a device of type
+AudioDeviceInfo.TYPE_USB_HEADSET and role isSink() if the USB audio terminal
+type field is 0x0402.
+
+*    [[7.8](#7_8_audio).2.2/H-4-3] MUST list a device of type
+AudioDeviceInfo.TYPE_USB_HEADSET and role isSource() if the USB audio terminal
+type field is 0x0402.
+
+*    [[7.8](#7_8_audio).2.2/H-4-4] MUST list a device of type [AudioDeviceInfo.TYPE_USB_DEVICE](
+https://developer.android.com/reference/android/media/AudioDeviceInfo#TYPE_USB_DEVICE)
+and role isSink() if the USB audio terminal type field is 0x603.
+
+*    [[7.8](#7_8_audio).2.2/H-4-5] MUST list a device of type
+AudioDeviceInfo.TYPE_USB_DEVICE and role isSource() if the USB audio terminal
+type field is 0x604.
+
+*    [[7.8](#7_8_audio).2.2/H-4-6] MUST list a device of type
+AudioDeviceInfo.TYPE_USB_DEVICE and role isSink() if the USB audio terminal type
+field is 0x400.
+
+*    [[7.8](#7_8_audio).2.2/H-4-7] MUST list a device of type
+AudioDeviceInfo.TYPE_USB_DEVICE and role isSource() if the USB audio terminal
+type field is 0x400.
+
+*    [[7.8](#7_8_audio).2.2/H-SR] Are STRONGLY RECOMMENDED upon connection of a
+USB-C audio peripheral, to perform enumeration of USB descriptors, identify
+terminal types and broadcast Intent ACTION_HEADSET_PLUG in less than
+1000 milliseconds.
 
 ### 2.2.2\. Multimedia
 
-Handheld device implementations MUST support the following audio encoding:
+Handheld device implementations MUST support the following audio encoding and
+decoding formats and make them available to third-party applications:
 
-*    [[5.1](#5_1_media_codecs).1/H-0-1] AMR-NB
-*    [[5.1](#5_1_media_codecs).1/H-0-2] AMR-WB
-*    [[5.1](#5_1_media_codecs).1/H-0-3] MPEG-4 AAC Profile (AAC LC)
-*    [[5.1](#5_1_media_codecs).1/H-0-4] MPEG-4 HE AAC Profile (AAC+)
-*    [[5.1](#5_1_media-codecs).1/H-0-5] AAC ELD (enhanced low delay AAC)
+*    [[5.1](#5_1_media_codecs)/H-0-1] AMR-NB
+*    [[5.1](#5_1_media_codecs)/H-0-2] AMR-WB
+*    [[5.1](#5_1_media_codecs)/H-0-3] MPEG-4 AAC Profile (AAC LC)
+*    [[5.1](#5_1_media_codecs)/H-0-4] MPEG-4 HE AAC Profile (AAC+)
+*    [[5.1](#5_1_media-codecs)/H-0-5] AAC ELD (enhanced low delay AAC)
 
-Handheld device implementations MUST support the following audio decoding:
-
-*    [[5.1](#5_1_media_codecs).2/H-0-1] AMR-NB
-*    [[5.1](#5_1_media_codecs).2/H-0-2] AMR-WB
-
-Handheld device implementations MUST support the following video encoding and
-make it available to third-party applications:
+Handheld device implementations MUST support the following video encoding
+formats and make them available to third-party applications:
 
 *    [[5.2](#5_2_video_encoding)/H-0-1] H.264 AVC
 *    [[5.2](#5_2_video_encoding)/H-0-2] VP8
 
-Handheld device implementations MUST support the following video decoding:
+Handheld device implementations MUST support the following video decoding
+formats and make them available to third-party applications:
 
 *    [[5.3](#5_3_video_decoding)/H-0-1] H.264 AVC
 *    [[5.3](#5_3_video_decoding)/H-0-2] H.265 HEVC
@@ -280,6 +440,10 @@
 https://developer.android.com/reference/android/app/RemoteInput.Builder.html#setChoices%28java.lang.CharSequence[]%29)
 in the notification shade when the user expands all notifications in the
 notification shade.
+*   [[3.8](#3_8_user_interface_compatibility).3.1/H-SR] Are STRONGLY RECOMMENDED
+    to display actions for which [`Notification.Action.Builder.setContextual`](https://developer.android.com/reference/android/app/Notification.Action.Builder.html#setContextual%28boolean%29)
+    is set as `true` in-line with the replies displayed by
+    [`Notification.Remoteinput.Builder.setChoices`](https://developer.android.com/reference/android/app/RemoteInput.Builder.html#setChoices%28java.lang.CharSequence[]%29).
 *   [[3.8](#3_8_user_interface_compatibility).4/H-SR] Are STRONGLY RECOMMENDED
 to implement an assistant on the device to handle the [Assist action](
 http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST).
@@ -333,6 +497,19 @@
 *   [[3.15](#3_15_instant_apps)/H-1-1] MUST support the companion device pairing
 feature.
 
+If the navigation function is provided as an on-screen, gesture-based action:
+
+*   [[7.2](#7_2_input_devices).3/H] The gesture recognition zone for the Home
+    function SHOULD be no higher than 32 dp in height from the bottom of the
+    screen.
+
+If Handheld device implementations provide a navigation function as a gesture
+from anywhere on the left and right edges of the screen:
+
+*   [[7.2](#7_2_input_devices).3/H-0-1] The navigation function's gesture area
+    MUST be less than 40 dp in width on each side. The gesture area SHOULD be
+    24 dp in width by default.
+
 ### 2.2.4\. Performance and Power
 
 *   [[8.1](#8_1_user_experience_consistency)/H-0-1] **Consistent frame latency**.
@@ -404,6 +581,46 @@
 https://developer.android.com/reference/android/provider/Settings.html#ACTION&lowbar;USAGE&lowbar;ACCESS&lowbar;SETTINGS)
 intent.
 
+Handheld device implementations (\* Not applicable for Tablet):
+
+*    [[9.11](#9_11_permissions)/H-0-2]\* MUST back up the keystore implementation
+     with an isolated execution environment.
+*    [[9.11](#9_11_permissions)/H-0-3]\* MUST have implementations of RSA, AES,
+     ECDSA, and HMAC cryptographic algorithms and MD5, SHA1, and SHA-2 family
+     hash functions to properly support the Android Keystore system's supported
+     algorithms in an area that is securely isolated from the code running on
+     the kernel and above. Secure isolation MUST block all potential mechanisms
+     by which kernel or userspace code might access the internal state of the
+     isolated environment, including DMA. The upstream Android Open Source
+     Project (AOSP) meets this requirement by using the [Trusty](
+     https://source.android.com/security/trusty/) implementation, but another
+     ARM TrustZone-based solution or a third-party reviewed secure
+     implementation of a proper hypervisor-based isolation are alternative
+     options.
+*    [[9.11](#9_11_permissions)/H-0-4]\* MUST perform the lock screen
+     authentication in the isolated execution environment and only when
+     successful, allow the authentication-bound keys to be used. Lock screen
+     credentials MUST be stored in a way that allows only the isolated execution
+     environment to perform lock screen authentication. The upstream Android
+     Open Source Project provides the
+     [Gatekeeper Hardware Abstraction Layer (HAL)](
+     http://source.android.com/devices/tech/security/authentication/gatekeeper.html)
+     and Trusty, which can be used to satisfy this requirement.
+*    [[9.11](#9_11_permissions)/H-0-5]\* MUST support key attestation where the
+     attestation signing key is protected by secure hardware and signing is
+     performed in secure hardware. The attestation signing keys MUST be shared
+     across large enough number of devices to prevent the keys from being used
+     as device identifiers. One way of meeting this requirement is to share the
+     same attestation key unless at least 100,000 units of a given SKU are
+     produced. If more than 100,000 units of an SKU are produced, a different
+     key MAY be used for each 100,000 units.
+
+Note that if a device implementation is already launched on an earlier Android
+version, such a device is exempted from the requirement to have a keystore
+backed by an isolated execution environment and support the key attestation,
+unless it declares the `android.hardware.fingerprint` feature which requires a
+keystore backed by an isolated execution environment.
+
 When Handheld device implementations support a secure lock screen, they:
 
 *   [[9.11](#9_11_permissions)/H-1-1] MUST allow the user to choose the shortest
@@ -414,3 +631,29 @@
     primary authentication described in
     [9.11.1 Secure Lock Screen](#9_11_1_secure-lock-screen). The AOSP meets the
     requirement as lockdown mode.
+
+### 2.2.6\. Developer Tools and Options Compatibility
+
+Handheld device implementations (\* Not applicable for Tablet):
+
+*   [[6.1](#6_1_developer_tools)/H-0-1]\* MUST support the shell command
+    `cmd testharness`.
+
+Handheld device implementations  (\* Not applicable for Tablet):
+
+*    [**Perfetto**](https://developer.android.com/studio/command-line/perfetto)
+    *   [[6.1](#6_1_developer_tools)/H-0-2]\* MUST expose a `/system/bin/perfetto`
+        binary to the shell user which cmdline complies with
+        [the perfetto documentation](
+        https://developer.android.com/studio/command-line/perfetto).
+    *   [[6.1](#6_1_developer_tools)/H-0-3]\* The perfetto binary MUST accept as
+        input a protobuf config that complies with the schema defined in
+        [the perfetto documentation](
+        https://developer.android.com/studio/command-line/perfetto).
+    *   [[6.1](#6_1_developer_tools)/H-0-4]\* The perfetto binary MUST write as
+        output a protobuf trace that complies with the schema defined in
+        [the perfetto documentation](
+        https://developer.android.com/studio/command-line/perfetto).
+    *   [[6.1](#6_1_developer_tools)/H-0-5]\* MUST provide, through the perfetto
+        binary, at least the data sources described  in [the perfetto documentation](
+        https://developer.android.com/studio/command-line/perfetto).
diff --git a/2_device-types/2_3_television-reqs.md b/2_device-types/2_3_television-reqs.md
index 853173c..3bb595d 100644
--- a/2_device-types/2_3_television-reqs.md
+++ b/2_device-types/2_3_television-reqs.md
@@ -1,3 +1,4 @@
+## 2.3\. Television Requirements
 
 An **Android Television device** refers to an Android device implementation that
 is an entertainment interface for consuming digital media, movies, games, apps,
@@ -35,7 +36,7 @@
 [core navigation keys](#7_2_3_navigation_keys) inputs.
 
 
-If Television device implementations include a gyroscope, they:
+If Television device implementations include a 3-axis gyroscope, they:
 
 *   [[7.3](#7_3_sensors).4/T-1-1] MUST be able to report events up to a
 frequency of at least 100 Hz.
@@ -87,16 +88,18 @@
 
 ### 2.3.2\. Multimedia
 
-Television device implementations MUST support the following audio encoding formats:
+Television device implementations MUST support the following audio encoding
+and decoding formats and make them available to third-party applications:
 
 *    [[5.1](#5_1_media_codecs)/T-0-1] MPEG-4 AAC Profile (AAC LC)
 *    [[5.1](#5_1_media_codecs)/T-0-2] MPEG-4 HE AAC Profile (AAC+)
 *    [[5.1](#5_1_media_codecs)/T-0-3] AAC ELD (enhanced low delay AAC)
 
 
-Television device implementations MUST support the following video encoding formats:
+Television device implementations MUST support the following video encoding
+formats and make them available to third-party applications:
 
-*    [[5.2](#5_2_video_encoding)/T-0-1] H.264 
+*    [[5.2](#5_2_video_encoding)/T-0-1] H.264
 *    [[5.2](#5_2_video_encoding)/T-0-2] VP8
 
 Television device implementations:
@@ -104,83 +107,102 @@
 *   [[5.2](#5_2_video_encoding).2/T-SR] Are STRONGLY RECOMMENDED to support
 H.264 encoding of 720p and 1080p resolution videos at 30 frames per second.
 
-Television device implementations MUST support the following video decoding formats:
+Television device implementations MUST support the following video decoding
+formats and make them available to third-party applications:
 
 *    [[5.3.3](#5_3_video_decoding)/T-0-1] MPEG-4 SP
 *    [[5.3.4](#5_3_video_decoding)/T-0-2] H.264 AVC
 *    [[5.3.5](#5_3_video_decoding)/T-0-3] H.265 HEVC
 *    [[5.3.6](#5_3_video_decoding)/T-0-4] VP8
 *    [[5.3.7](#5_3_video_decoding)/T-0-5] VP9
+*    [[5.3.1](#5_3_video_decoding)/T-0-6] MPEG-2
 
-Television device implementations are STRONGLY RECOMMENDED to support the
-following video decoding formats:
+Television device implementations MUST support MPEG-2 decoding, as detailed in
+Section 5.3.1, at standard video frame rates and resolutions up to and
+including:
 
-*    [[5.3.1](#5_3_video_decoding)/T-SR] MPEG-2
+*   [[5.3.1](#5_3_video_decoding).4/T-1-1] HD 1080p at 59.94 frames per second
+with Main Profile High Level.
+*   [[5.3.1](#5_3_video_decoding).4/T-1-2] HD 1080i at 59.94 frames per second
+with Main Profile High Level. They MUST deinterlace interlaced MPEG-2 video to
+its progressive equivalent (e.g. from 1080i at 59.94 frames per second to 1080p
+at 29.97 frames per second) and make it available to third-party applications.
 
-Television device implementations MUST support H.264 decoding, as detailed in Section 5.3.4, 
-at standard video frame rates and resolutions up to and including:
+Television device implementations MUST support H.264 decoding, as detailed in
+Section 5.3.4, at standard video frame rates and resolutions up to and
+including:
 
-*   [[5.3.4](#5_3_video_decoding).4/T-1-1] HD 1080p at 60 frames per second with Basline Profile
-*   [[5.3.4](#5_3_video_decoding).4/T-1-2] HD 1080p at 60 frames per second with Main Profile 
-*   [[5.3.4](#5_3_video_decoding).4/T-1-3] HD 1080p at 60 frames per second with High Profile Level 4.2
+*   [[5.3.4](#5_3_video_decoding)/T-1-1] HD 1080p at 60 frames per second with
+    Baseline Profile
+*   [[5.3.4](#5_3_video_decoding)/T-1-2] HD 1080p at 60 frames per second with
+    Main Profile
+*   [[5.3.4](#5_3_video_decoding)/T-1-3] HD 1080p at 60 frames per second with
+    High Profile Level 4.2
 
-Television device implementations  with H.265 hardware decoders MUST support H.265 decoding, 
-as detailed in Section 5.3.5, at standard video frame rates and resolutions up to and including:
+Television device implementations  with H.265 hardware decoders MUST support
+H.265 decoding, as detailed in Section 5.3.5, at standard video frame rates
+and resolutions up to and including:
 
-*   [[5.3.5](#5_3_video_decoding).4/T-1-1] HD 1080p at 60 frames per second with Main Profile Level 4.1
+*   [[5.3.5](#5_3_video_decoding)/T-1-1] HD 1080p at 60 frames per second with
+    Main Profile Level 4.1
 
-If Television device implementations with H.265 hardware decoders support 
+If Television device implementations with H.265 hardware decoders support
 H.265 decoding and the UHD decoding profile, they:
 
-*   [[5.3.5](#5_3_video_decoding).5/T-2-1] MUST support UHD 3480p at 60 frames per second with Main10 Level 5
-Main Tier profile.
+*   [[5.3.5](#5_3_video_decoding)/T-2-1] MUST support UHD 3480p at 60 frames per
+    second with Main10 Level 5 Main Tier profile
 
-Television device implementations MUST support VP8 decoding, as detailed in Section 5.3.6, 
-at standard video frame rates and resolutions up to and including:
+Television device implementations MUST support VP8 decoding, as detailed in
+Section 5.3.6, at standard video frame rates and resolutions up to and
+including:
 
-*   [[5.3.6](#5_3_video_decoding).4/T-1-1] HD 1080p at 60 frames per second decoding profile
+*   [[5.3.6](#5_3_video_decoding)/T-1-1] HD 1080p at 60 frames per second decoding profile
 
-Television device implementations  with VP9 hardware decoders MUST support VP9 decoding, as detailed in Section 5.3.7, 
-at standard video frame rates and resolutions up to and including:
+Television device implementations  with VP9 hardware decoders MUST support VP9
+decoding, as detailed in Section 5.3.7, at standard video frame rates and
+resolutions up to and including:
 
-*   [[5.3.7](#5_3_video_decoding).4/T-1-1] HD 1080p at 60 frames per second with profile 0 (8 bit colour depth) 
+*   [[5.3.7](#5_3_video_decoding)/T-1-1] HD 1080p at 60 frames per second with
+    profile 0 (8 bit color depth)
 
-If Television device implementations with VP9 hardware decoders support VP9 decoding and the UHD decoding
-profile, they:
+If Television device implementations with VP9 hardware decoders support VP9
+decoding and the UHD decoding profile, they:
 
-*   [[5.3.7](#5_3_video_decoding).5/T-2-1] MUST support UHD 3480p at 60 frames per second with profile 0 (8 bit colour depth).
-*   [[5.3.7](#5_3_video_decoding).5/T-2-1] Are STRONGLY RECOMMENDED to support UHD 3480p at 60 frames per second with profile 2 (10 bit colour depth).
+*   [[5.3.7](#5_3_video_decoding)/T-2-1] MUST support UHD 3480p at 60 frames per
+    second with profile 0 (8 bit color depth).
+*   [[5.3.7](#5_3_video_decoding)/T-2-1] Are STRONGLY RECOMMENDED to support UHD
+    3480p at 60 frames per second with profile 2 (10 bit color depth).
 
 Television device implementations:
 
-*   [[5.5](#5_5_audio_playback).3/T-0-1] MUST include support for system Master
+*   [[5.5](#5_5_audio_playback)/T-0-1] MUST include support for system Master
 Volume and digital audio output volume attenuation on supported outputs,
 except for compressed audio passthrough output (where no audio decoding is done
 on the device).
+
+Television device implementations which do not have a built in display,
+but instead support an external display connected via HDMI; they:
+
 *    [[5.8](#5_8_secure_media)/T-0-1] MUST set the HDMI output mode to
-select the maximum resolution that can be supported with either 50Hz or 60Hz
-refresh rate for all wired displays.
+select the maximum resolution that can be supported with either a 50Hz or 60Hz
+refresh rate.
 *    [[5.8](#5_8_secure_media)/T-SR] Are STRONGLY RECOMMENDED to provide a user
-configurable HDMI refresh rate selector for all wired displays.
-*    [[5.8](#5_8_secure_media)/T-SR] Are STRONGLY RECOMMENDED to support
-simultaneous decoding of secure streams. At minimum, simultaneous decoding of
-two steams is STRONGLY RECOMMENDED.
+configurable HDMI refresh rate selector.
 *    [[5.8](#5_8_secure_media)] SHOULD set the HDMI output mode refresh rate
 to either 50Hz or 60Hz, depending on the video refresh rate for the region the
-device is sold in for all wired displays.
+device is sold in.
 
-If Television device implementations support UHD decoding and have support
-for external displays, they:
+If Television device implementations  who do not have a built in display,
+but instead support an external display connected via HDMI; they:
 
 *    [[5.8](#5_8_secure_media)/T-1-1] MUST support HDCP 2.2.
 
-If Television device implementations do not support UHD decoding but have
-support for external displays, they:
+If Television device implementations which do not support UHD decoding but have
+but instead support an external display connected via HDMI; they:
 
 *    [[5.8](#5_8_secure_media)/T-2-1] MUST support HDCP 1.4
 
 
-
 ### 2.3.3\. Software
 
 Television device implementations:
@@ -244,7 +266,16 @@
 
 * [[8.3](#8_3_power_saving_modes)/T-1-1] MUST provide user affordance to enable
   and disable the battery saver feature.
-* [[8.3](#8_3_power_saving_modes)/T-1-2] MUST provide user affordance to display
+
+If Television device implementations do not have a battery they:
+
+* [[8.3](#8_3_power_saving_modes)/T-1-2] MUST register the device as
+a batteryless device as described in [Supporting Batteryless Devices](
+https://source.android.com/devices/tech/power/batteryless).
+
+If Television device implementations have a battery they:
+
+* [[8.3](#8_3_power_saving_modes)/T-1-3] MUST provide user affordance to display
   all apps that are exempted from App Standby and Doze power-saving modes.
 
 Television device implementations:
@@ -266,3 +297,72 @@
 available via the [`adb shell dumpsys batterystats`](
 http://source.android.com/devices/tech/power/batterystats.html)
 shell command to the app developer.
+
+### 2.3.5\. Security Model
+
+Television device implementations:
+
+*    [[9.11](#9_11_permissions)/T-0-1] MUST back up the keystore implementation
+     with an isolated execution environment.
+*    [[9.11](#9_11_permissions)/T-0-2] MUST have implementations of RSA, AES,
+     ECDSA and HMAC cryptographic algorithms and MD5, SHA1, and SHA-2 family
+     hash functions to properly support the Android Keystore system's supported
+     algorithms in an area that is securely isolated from the code running on
+     the kernel and above. Secure isolation MUST block all potential mechanisms
+     by which kernel or userspace code might access the internal state of the
+     isolated environment, including DMA. The upstream Android Open Source
+     Project (AOSP) meets this requirement by using the [Trusty](
+     https://source.android.com/security/trusty/) implementation, but another
+     ARM TrustZone-based solution or a third-party reviewed secure
+     implementation of a proper hypervisor-based isolation are alternative
+     options.
+*    [[9.11](#9_11_permissions)/T-0-3] MUST perform the lock screen
+     authentication in the isolated execution environment and only when
+     successful, allow the authentication-bound keys to be used. Lock screen
+     credentials MUST be stored in a way that allows only the isolated execution
+     environment to perform lock screen authentication. The upstream Android
+     Open Source Project provides the
+     [Gatekeeper Hardware Abstraction Layer (HAL)](
+     http://source.android.com/devices/tech/security/authentication/gatekeeper.html)
+     and Trusty, which can be used to satisfy this requirement.
+*    [[9.11](#9_11_permissions)/T-0-4] MUST support key attestation where the
+     attestation signing key is protected by secure hardware and signing is
+     performed in secure hardware. The attestation signing keys MUST be shared
+     across large enough number of devices to prevent the keys from being used
+     as device identifiers. One way of meeting this requirement is to share the
+     same attestation key unless at least 100,000 units of a given SKU are
+     produced. If more than 100,000 units of an SKU are produced, a different
+     key MAY be used for each 100,000 units.
+
+Note that if a device implementation is already launched on an earlier Android
+version, such a device is exempted from the requirement to have a keystore
+backed by an isolated execution environment and support the key attestation,
+unless it declares the `android.hardware.fingerprint` feature which requires a
+keystore backed by an isolated execution environment.
+
+If Television device implementations support a secure lock screen, they:
+
+*    [[9.11](#9_11_permissions)/T-1-1] MUST allow the user to choose the Sleep
+     timeout for transition from the unlocked to the locked state, with a
+     minimum allowable timout up to 15 seconds or less.
+
+### 2.3.6\. Developer Tools and Options Compatibility
+
+Television device implementations:
+
+*    [**Perfetto**](https://developer.android.com/studio/command-line/perfetto)
+    *   [[6.1](#6_1_developer_tools)/T-0-1] MUST expose a `/system/bin/perfetto`
+        binary to the shell user which cmdline complies with
+        [the perfetto documentation](
+        https://developer.android.com/studio/command-line/perfetto).
+    *   [[6.1](#6_1_developer_tools)/T-0-2] The perfetto binary MUST accept as
+        input a protobuf config that complies with the schema defined in
+        [the perfetto documentation](
+        https://developer.android.com/studio/command-line/perfetto).
+    *   [[6.1](#6_1_developer_tools)/T-0-3] The perfetto binary MUST write as
+        output a protobuf trace that complies with the schema defined in
+        [the perfetto documentation](
+        https://developer.android.com/studio/command-line/perfetto).
+    *   [[6.1](#6_1_developer_tools)/T-0-4] MUST provide, through the perfetto
+        binary, at least the data sources described  in [the perfetto documentation](
+        https://developer.android.com/studio/command-line/perfetto).
diff --git a/2_device-types/2_4_watch-reqs.md b/2_device-types/2_4_watch-reqs.md
index 1d44f71..afaeb18 100644
--- a/2_device-types/2_4_watch-reqs.md
+++ b/2_device-types/2_4_watch-reqs.md
@@ -28,6 +28,18 @@
 *   [[7.3](#7_3_sensors).1/W-SR] Are STRONGLY RECOMMENDED to include a 3-axis
 accelerometer.
 
+If Watch device implementations include a GPS/GNSS receiver and report the
+capability to applications through the `android.hardware.location.gps` feature
+flag, they:
+
+*  [[7.3](#7_3_sensors).3/W-1-1] MUST report GNSS measurements, as soon as they
+are found, even if a location calculated from GPS/GNSS is not yet reported.
+*  [[7.3](#7_3_sensors).3/W-1-2] MUST report GNSS pseudoranges and pseudorange
+rates, that, in open-sky conditions after determining the location, while
+stationary or moving with less than 0.2 meter per second squared of
+acceleration, are sufficient to calculate position within 20 meters, and speed
+within 0.2 meters per second, at least 95% of the time.
+
 *   [[7.4](#7_4_data_connectivity).3/W-0-1] MUST support Bluetooth.
 
 *   [[7.6](#7_6_memory_and_storage).1/W-0-1] MUST have at least 1 GB of
diff --git a/2_device-types/2_5_automotive-reqs.md b/2_device-types/2_5_automotive-reqs.md
index 3b6d56e..ee2ddcc 100644
--- a/2_device-types/2_5_automotive-reqs.md
+++ b/2_device-types/2_5_automotive-reqs.md
@@ -29,9 +29,28 @@
 event of the Back function ([`KEYCODE_BACK`](
 http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK))
 to the foreground application.
-
-*   [[7.3](#7_3_sensors).1/A-SR] Are STRONGLY RECOMMENDED to include a 3-axis
-accelerometer.
+*   [[7.3](#7_3_sensors)/A-0-1] MUST implement and report
+[`GEAR_SELECTION`](https://developer.android.com/reference/android/car/VehiclePropertyIds.html#GEAR_SELECTION),
+[`NIGHT_MODE`](https://developer.android.com/reference/android/car/VehiclePropertyIds.html#NIGHT_MODE),
+[`PERF_VEHICLE_SPEED`](https://developer.android.com/reference/android/car/VehiclePropertyIds.html#PERF_VEHICLE_SPEED)
+and [`PARKING_BRAKE_ON`](https://developer.android.com/reference/android/car/VehiclePropertyIds.html#PARKING_BRAKE_ON).
+*    [[7.3](#7_3_sensors)/A-0-2] The value of the
+[`NIGHT_MODE`](https://developer.android.com/reference/android/car/VehiclePropertyIds.html#NIGHT_MODE)
+flag MUST be consistent with dashboard day/night mode and SHOULD be based on
+ambient light sensor input. The underlying ambient light sensor MAY be the same
+as [Photometer](#7_3_7_photometer).
+*   [[7.3](#7_3_sensors)/A-0-3] MUST provide sensor additional info field
+[`TYPE_SENSOR_PLACEMENT`](https://developer.android.com/reference/android/hardware/SensorAdditionalInfo.html#TYPE_SENSOR_PLACEMENT)
+as part of SensorAdditionalInfo for every sensor provided.
+*   [[7.3](#7_3_sensors)/A-0-1] MAY dead reckon [Location](https://developer.android.com/reference/android/location/Location)
+by fusing GPS/GNSS with additional sensors. If [Location](https://developer.android.com/reference/android/location/Location)
+is dead reckoned, it is STRONGLY RECOMMENDED to implement and report the
+corresponding [Sensor](https://developer.android.com/reference/android/hardware/Sensor)
+types and/or [Vehicle Property IDs](https://developer.android.com/reference/android/car/VehiclePropertyIds)
+used.
+*   [[7.3](#7_3_sensors)/A-0-2] The [Location](https://developer.android.com/reference/android/location/Location)
+requested via [LocationManager#requestLocationUpdates()](https://developer.android.com/reference/android/location/LocationManager)
+MUST NOT be map matched.
 
 If Automotive device implementations include a 3-axis accelerometer, they:
 
@@ -41,39 +60,17 @@
 [car sensor coordinate system](
 http://source.android.com/devices/sensors/sensor-types.html#auto_axes).
 
-If Automotive device implementations include a GPS/GNSS receiver and report
-the capability to applications through the `android.hardware.location.gps`
-feature flag:
-
-*   [[7.3](#7_3_sensors).3/A-1-1] GNSS technology generation MUST be the year
-"2017" or newer.
-
-If Automotive device implementations include a gyroscope, they:
-
+If Automotive device implementations include a 3-axis gyroscope, they:
 *   [[7.3](#7_3_sensors).4/A-1-1] MUST be able to report events up to a
 frequency of at least 100 Hz.
+*   [[7.3](#7_3_sensors).4/A-1-2] MUST also implement the
+[`TYPE_GYROSCOPE_UNCALIBRATED`](https://developer.android.com/reference/android/hardware/Sensor.html#TYPE_GYROSCOPE_UNCALIBRATED)
+sensor.
+*   [[7.3](#7_3_sensors).4] SHOULD have a measurement range between -250 and +250
+degrees per second (dps).
+
 
 Automotive device implementations:
-
-*    [[7.3](#7_3_sensors).11/A-0-1] MUST provide current gear as
-`SENSOR_TYPE_GEAR`.
-
-Automotive device implementations:
-
-*    [[7.3](#7_3_sensors).11.2/A-0-1] MUST support day/night mode defined as
-`SENSOR_TYPE_NIGHT`.
-*    [[7.3](#7_3_sensors).11.2/A-0-2] The value of the `SENSOR_TYPE_NIGHT` flag
-MUST be consistent with dashboard day/night mode and SHOULD be based on ambient
-light sensor input.
-*    The underlying ambient light sensor MAY be the same as
-[Photometer](#7_3_7_photometer).
-
-*    [[7.3](#7_3_sensors).11.4/A-0-1] MUST provide vehicle speed as defined by
-`SENSOR_TYPE_CAR_SPEED`.
-
-*    [[7.3](#7_3_sensors).11.5/A-0-1] MUST provide parking brake status as
-defined by `SENSOR_TYPE_PARKING_BRAKE`.
-
 *    [[7.4](#7_4_data_connectivity).3/A-0-1] MUST support Bluetooth and SHOULD
 support Bluetooth LE.
 *    [[7.4](#7_4_data_connectivity).3/A-0-2] Android Automotive implementations
@@ -91,12 +88,36 @@
 `NetworkCapabilities#NET_CAPABILITY_OEM_PAID` constant for
 networks that should be available to system apps.
 
+An exterior view camera is a camera that images scenes outside of the device
+implementation, like a dashcam.
+
+Automotive device implementations:
+
+*   SHOULD include one or more exterior view cameras.
+
+If Automotive device implementations include an exterior view camera, for such
+a camera, they:
+
+*   [[7.5](#7_5_cameras)/A-1-1] MUST NOT have exterior view cameras accessible
+via the [Android Camera APIs](
+https://developer.android.com/guide/topics/media/camera),unless they comply
+with camera [core requirements](#7_5_cameras).
+*   [[7.5](#7_5_cameras)/A-SR] Are STRONGLY RECOMMENDED not to rotate or
+horizontally mirror the camera preview.
+*   [[7.5](#7_5_cameras).5/A-SR] Are STRONGLY RECOMMENDED to be oriented so that
+the long dimension of the camera aligns with the horizon.
+*   [[7.5](#7_5_cameras)/A-SR] Are STRONGLY RECOMMENDED to have a resolution
+of at least 1.3 megapixels.
+*   SHOULD have either fixed-focus or EDOF (extended depth of field) hardware.
+*   MAY have either hardware auto-focus or software auto-focus implemented in
+the camera driver.
+
+Automotive device implementations:
+
 *   [[7.6](#7_6_memory_and_storage).1/A-0-1] MUST have at least 4 GB of
 non-volatile storage available for application private data
 (a.k.a. "/data" partition).
 
-Automotive device implementations:
-
 *   [[7.6](#7_6_memory_and_storage).1/A] SHOULD format the data partition
 to offer improved performance and longevity on flash storage, for example
 using `f2fs` file-system.
@@ -181,18 +202,21 @@
 
 ### 2.5.2\. Multimedia
 
-Automotive device implementations MUST support the following audio encoding:
+Automotive device implementations MUST support the following audio encoding
+and decoding formats and make them available to third-party applications:
 
 *    [[5.1](#5_1_media_codecs)/A-0-1] MPEG-4 AAC Profile (AAC LC)
 *    [[5.1](#5_1_media_codecs)/A-0-2] MPEG-4 HE AAC Profile (AAC+)
 *    [[5.1](#5_1_media_codecs)/A-0-3] AAC ELD (enhanced low delay AAC)
 
-Automotive device implementations MUST support the following video encoding:
+Automotive device implementations MUST support the following video encoding
+formats and make them available to third-party applications:
 
 *    [[5.2](#5_2_video_encoding)/A-0-1] H.264 AVC
 *    [[5.2](#5_2_video_encoding)/A-0-2] VP8
 
-Automotive device implementations MUST support the following video decoding:
+Automotive device implementations MUST support the following video decoding
+formats and make them available to third-party applications:
 
 *    [[5.3](#5_3_video_decoding)/A-0-1] H.264 AVC
 *    [[5.3](#5_3_video_decoding)/A-0-2] MPEG-4 SP
@@ -219,6 +243,10 @@
 [`android.car.*`](https://developer.android.com/reference/android/car/package-summary)
 namespace.
 
+*   [[3.2](#3_2_soft_api_compatibility).1/A-0-1] MUST support and enforce all
+permissions constants as documented by the [Automotive Permission reference page](
+https://developer.android.com/reference/android/car/Car).
+
 *   [[3.4](#3_4_web_compatibility).1/A-0-1] MUST provide a complete
 implementation of the `android.webkit.Webview` API.
 
@@ -227,13 +255,9 @@
 https://developer.android.com/reference/android/app/Notification.CarExtender.html)
 API when requested by third-party applications.
 
-*   [[3.8](#3_8_user_interface_compatibility).4/A-0-1] MUST implement an
-assistant on the device that provides a default implementation of the
-[`VoiceInteractionSession`](https://developer.android.com/reference/android/service/voice/VoiceInteractionSession)
-service.
-
-*   [[3.13](#3_13_quick_settings)/A-SR] Are STRONGLY RECOMMENDED to include a
-Quick Settings UI component.
+*   [[3.8](#3_8_user-interface-compatibility).4/A-SR] Are Strongly Recommended
+to implement an assistant on the device to handle the [Assist action](
+http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST).
 
 If Automotive device implementations include a push-to-talk button, they:
 
@@ -245,21 +269,76 @@
 
 Automotive device implementations:
 
+*   [[3.8.3.1](#3_8_3_1_presentation_of_notifications)/A-0-1] MUST correctly
+render resources as described in the [`Notifications on Automotive OS`](
+https://developer.android.com/training/cars/notifications)
+SDK documentation.
+*   [[3.8.3.1](#3_8_3_1_presentation_of_notifications)/A-0-2] MUST display
+PLAY and MUTE for notification actions in the place of those provided through
+[`Notification.Builder.addAction()`](
+https://developer.android.com/reference/android/app/Notification.Builder#addAction%28android.app.Notification.Action%29)
+*   [[3.8.3.1](#3_8_3_1_presentation_of_notifications)/A] SHOULD restrict the
+use of rich management tasks such as per-notification-channel controls.
+MAY use UI affordance per application to reduce controls.
+
+Automotive device implementations:
+
 *   [[3.14](#3_14_media_ui)/A-0-1] MUST include a UI framework to support
 third-party apps using the media APIs as described in section
 [3.14](#3_14_media_ui).
+*   [[3.14](#3_14_media_ui)/A-0-2] MUST allow the user to safely interact
+with Media Applications while driving.
+*   [[3.14](#3_14_media_ui)/A-0-3] MUST support the
+[`CAR_INTENT_ACTION_MEDIA_TEMPLATE`](https://developer.android.com/reference/android/car/Car#CAR_INTENT_ACTION_MEDIA_TEMPLATE)
+implicit Intent action with the
+[`CAR_EXTRA_MEDIA_PACKAGE`](https://developer.android.com/reference/android/car/Car#CAR_EXTRA_MEDIA_PACKAGE)
+extra.
+*   [[3.14](#3_14_media_ui)/A-0-4] MUST provide an affordance to navigate into
+a Media Application’s
+[preference
+activity](https://developer.android.com/reference/android/content/Intent.html#ACTION_APPLICATION_PREFERENCES),
+but MUST only enable it when Car UX Restrictions are not in effect.
+*   [[3.14](#3_14_media_ui)/A-0-5] MUST display
+[error messages](https://developer.android.com/reference/android/support/v4/media/session/PlaybackStateCompat.html#getErrorMessage(\))
+set by Media Applications, and MUST support the optional extras
+[`ERROR_RESOLUTION_ACTION_LABEL`](https://developer.android.com/training/cars/media#require-sign-in)
+and [`ERROR_RESOLUTION_ACTION_INTENT`](https://developer.android.com/training/cars/media#require-sign-in).
+*   [[3.14](#3_14_media_ui)/A-0-6] MUST support an in-app search affordance for
+apps that support searching.
+*   [[3.14](#3_14_media_ui)/A-0-7] MUST respect
+[`CONTENT_STYLE_BROWSABLE_HINT`](
+https://developer.android.com/training/cars/media#default-content-style)
+and [`CONTENT_STYLE_PLAYABLE_HINT`](
+https://developer.android.com/training/cars/media#default-content-style)
+definitions when displaying the [MediaBrowser](
+https://developer.android.com/reference/android/media/browse/MediaBrowser.html)
+hierarchy.
+
+If Automotive device implementations include a default launcher app, they:
+
+*   [[3.14](#3_14_media_ui)/A-1-1] MUST include media services and open them
+with the [`CAR_INTENT_ACTION_MEDIA_TEMPLATE`](
+https://developer.android.com/reference/android/car/Car#CAR_INTENT_ACTION_MEDIA_TEMPLATE)
+intent.
+
+Automotive device implementations:
+
+*    [[3.8](#3_8_user-interface-compatibility)/A] MAY restrict the application
+     requests to limit the ability to enter a full screen mode as described in
+     [`immersive documentation`](
+     https://developer.android.com/training/system-ui/immersive).
+*   [[3.8](#3_8_user-interface-compatibility)/A] MAY keep the status bar and
+    the navigation bar visible at all times.
+*   [[3.8](#3_8_user-interface-compatibility)/A] MAY restrict the application
+    requests to limit the ability to change the colors behind the system UI
+    elements, to ensure those elements are clearly visible at all times,
+    as described in the [`WindowManager.LayoutParams#FLAG_TRANSLUCENT_STATUS`](
+    https://developer.android.com/reference/android/view/WindowManager.LayoutParams#FLAG_TRANSLUCENT_STATUS)
+    and [`WindowManager.LayoutParams#FLAG_TRANSLUCENT_NAVIGATION`](
+    https://developer.android.com/reference/android/view/WindowManager.LayoutParams#FLAG_TRANSLUCENT_NAVIGATION).
 
 ### 2.5.4\. Performance and Power
 
-If Automotive device implementations include features to improve device power
-management that are included in AOSP or extend the features that are included
-in AOSP, they:
-
-* [[8.3](#8_3_power_saving_modes)/A-1-1] MUST provide user affordance to enable
-  and disable the battery saver feature.
-* [[8.3](#8_3_power_saving_modes)/A-1-2] MUST provide user affordance to display
-  all apps that are exempted from App Standby and Doze power-saving modes.
-
 Automotive device implementations:
 
 *   [[8.2](#8_2_file_i/o_access_performance)/A-0-1] MUST report the number of
@@ -267,9 +346,15 @@
 stats are available to developers through System API
 `android.car.storagemonitoring.CarStorageMonitoringManager`. The Android Open
 Source Project meets the requirement through the `uid_sys_stats` kernel module.
+*   [[8.3](#8_3_power_saving_modes)/A-1-3] MUST enter [Garage Mode](https://source.android.com/devices/automotive/garage_mode)
+at least once before the car is powered down.
+*   [[8.3](#8_3_power_saving_modes)/A-1-4] MUST be in [Garage Mode](https://source.android.com/devices/automotive/garage_mode)
+for at least 15 minutes unless:
+    *    The battery is drained.
+    *    No idle jobs are scheduled.
+    *    The driver exits Garage Mode.
 *   [[8.4](#8_4_power_consumption_accounting)/A-0-1] MUST provide a
-per-component power profile that defines the [current consumption value](
-http://source.android.com/devices/tech/power/values.html)
+per-component power profile that defines the [current consumption value](http://source.android.com/devices/tech/power/values.html)
 for each hardware component and the approximate battery drain caused by the
 components over time as documented in the Android Open Source Project site.
 *   [[8.4](#8_4_power_consumption_accounting)/A-0-2] MUST report all power
@@ -281,24 +366,68 @@
 hardware component itself if unable to attribute hardware component power usage
 to an application.
 *   [[8.4](#8_4_power_consumption_accounting)/A-0-4] MUST make this power usage
-available via the [`adb shell dumpsys batterystats`](
-http://source.android.com/devices/tech/power/batterystats.html)
+available via the [`adb shell dumpsys batterystats`](http://source.android.com/devices/tech/power/batterystats.html)
 shell command to the app developer.
 
 ### 2.5.5\. Security Model
 
-
 If Automotive device implementations support multiple users, they:
 
-*   [[9.5](#9_5_multi_user_support)/A-1-1] MUST include a guest account that
-allows all functions provided by the vehicle system without requiring a user to
-log in.
+*   [[9.5](#9_5_multi-user_support)/A-1-1] MUST NOT allow users to interact with
+nor switch into the [Headless System User](https://source.android.com/devices/tech/admin/multi-user#user_types),
+except for [device provisioning](https://source.android.com/devices/tech/admin/provision).
+*   [[9.5](#9_5_multi-user_support)/A-1-2] MUST switch into a [Secondary User](https://source.android.com/devices/tech/admin/multi-user#user_types)
+before [`BOOT_COMPLETED`](https://developer.android.com/reference/android/content/Intent.html#ACTION_BOOT_COMPLETED).
+*   [[9.5](#9_5_multi-user_support)/A-1-3] MUST support the ability to create
+a [Guest User](https://source.android.com/devices/tech/admin/multi-user#user_types)
+even when the maximum number of Users on a device has been reached.
+
+
+Automotive device implementations:
+
+*    [[9.11](#9_11_permissions)/A-0-1] MUST back up the keystore implementation
+     with an isolated execution environment.
+*    [[9.11](#9_11_permissions)/A-0-2] MUST have implementations of RSA, AES,
+     ECDSA and HMAC cryptographic algorithms and MD5, SHA1, and SHA-2 family
+     hash functions to properly support the Android Keystore system's supported
+     algorithms in an area that is securely isolated from the code running on
+     the kernel and above. Secure isolation MUST block all potential mechanisms
+     by which kernel or userspace code might access the internal state of the
+     isolated environment, including DMA. The upstream Android Open Source
+     Project (AOSP) meets this requirement by using the [Trusty](
+     https://source.android.com/security/trusty/) implementation, but another
+     ARM TrustZone-based solution or a third-party reviewed secure
+     implementation of a proper hypervisor-based isolation are alternative
+     options.
+*    [[9.11](#9_11_permissions)/A-0-3] MUST perform the lock screen
+     authentication in the isolated execution environment and only when
+     successful, allow the authentication-bound keys to be used. Lock screen
+     credentials MUST be stored in a way that allows only the isolated execution
+     environment to perform lock screen authentication. The upstream Android
+     Open Source Project provides the
+     [Gatekeeper Hardware Abstraction Layer (HAL)](
+     http://source.android.com/devices/tech/security/authentication/gatekeeper.html)
+     and Trusty, which can be used to satisfy this requirement.
+*    [[9.11](#9_11_permissions)/A-0-4] MUST support key attestation where the
+     attestation signing key is protected by secure hardware and signing is
+     performed in secure hardware. The attestation signing keys MUST be shared
+     across large enough number of devices to prevent the keys from being used
+     as device identifiers. One way of meeting this requirement is to share the
+     same attestation key unless at least 100,000 units of a given SKU are
+     produced. If more than 100,000 units of an SKU are produced, a different
+     key MAY be used for each 100,000 units.
+
+Note that if a device implementation is already launched on an earlier Android
+version, such a device is exempted from the requirement to have a keystore
+backed by an isolated execution environment and support the key attestation,
+unless it declares the `android.hardware.fingerprint` feature which requires a
+keystore backed by an isolated execution environment.
 
 If Automotive device implementations support a secure lock screen, they:
 
-*   [[9.9](#9_9_full_disk_encryption).2/A-1-1] MUST support encryption per
-user-specific authentication keys. [File-Based Encryption (FBE)](
-https://source.android.com/security/encryption/file-based) is one way to do it.
+*    [[9.11](#9_11_permissions)/A-1-1] MUST allow the user to choose the Sleep
+     timeout for transition from the unlocked to the locked state, with a
+     minimum allowable timeout up to 15 seconds or less.
 
 Automotive device implementations:
 
@@ -309,3 +438,24 @@
 denial of service attacks from the Android framework or third-party apps. This
 guards against malicious software flooding the vehicle network with traffic,
 which may lead to malfunctioning vehicle subsystems.
+
+### 2.5.6\. Developer Tools and Options Compatibility
+
+Automotive device implementations:
+
+*    [**Perfetto**](https://developer.android.com/studio/command-line/perfetto)
+    *   [[6.1](#6_1_developer_tools)/A-0-1] MUST expose a `/system/bin/perfetto`
+        binary to the shell user which cmdline complies with
+        [the perfetto documentation](
+        https://developer.android.com/studio/command-line/perfetto).
+    *   [[6.1](#6_1_developer_tools)/A-0-2] The perfetto binary MUST accept as
+        input a protobuf config that complies with the schema defined in
+        [the perfetto documentation](
+        https://developer.android.com/studio/command-line/perfetto).
+    *   [[6.1](#6_1_developer_tools)/A-0-3] The perfetto binary MUST write as
+        output a protobuf trace that complies with the schema defined in
+        [the perfetto documentation](
+        https://developer.android.com/studio/command-line/perfetto).
+    *   [[6.1](#6_1_developer_tools)/A-0-4] MUST provide, through the perfetto
+        binary, at least the data sources described  in [the perfetto documentation](
+        https://developer.android.com/studio/command-line/perfetto).
diff --git a/2_device-types/2_6_tablet-reqs.md b/2_device-types/2_6_tablet-reqs.md
index c993ad0..fa4d2ee 100644
--- a/2_device-types/2_6_tablet-reqs.md
+++ b/2_device-types/2_6_tablet-reqs.md
@@ -10,10 +10,10 @@
 *   Have a physical diagonal screen size in the range of 7 to 18 inches.
 
 Tablet device implementations have similar requirements to handheld device
-implementations. The exceptions are in indicated by and \* in that section
+implementations. The exceptions are indicated by an \* in that section
 and noted for reference in this section.
 
-### 2.4.1\. Hardware
+### 2.6.1\. Hardware
 
 **Screen Size**
 
@@ -38,4 +38,6 @@
 
 Virtual reality requirements are not applicable to tablets.
 
+**Keys and Credentials (Section 9.11)**
 
+Refer to Section [[9.11](#9_11_permissions)].
diff --git a/3_software/3_0_intro.md b/3_software/3_0_intro.md
index de6e301..4c896e9 100644
--- a/3_software/3_0_intro.md
+++ b/3_software/3_0_intro.md
@@ -1,2 +1 @@
 # 3\. Software
-
diff --git a/3_software/3_11_text-to-speech.md b/3_software/3_11_text-to-speech.md
index 0774b7b..85a6522 100644
--- a/3_software/3_11_text-to-speech.md
+++ b/3_software/3_11_text-to-speech.md
@@ -15,4 +15,3 @@
 
 *   [C-2-1] MUST provide user affordance to allow the user to select a TTS
     engine for use at system level.
-
diff --git a/3_software/3_12_tv-input-framework.md b/3_software/3_12_tv-input-framework.md
index 8051028..6a66e74 100644
--- a/3_software/3_12_tv-input-framework.md
+++ b/3_software/3_12_tv-input-framework.md
@@ -10,4 +10,4 @@
 *    [C-1-1] MUST declare the platform feature `android.software.live_tv`.
 *    [C-1-2] MUST support all TIF APIs such that an application which uses
 these APIs and the [third-party TIF-based inputs](https://source.android.com/devices/tv/index.html#third-party_input_example)
-service can be installed and used on the device.
\ No newline at end of file
+service can be installed and used on the device.
diff --git a/3_software/3_14_media-ui.md b/3_software/3_14_media-ui.md
index fb6d358..00e03a5 100644
--- a/3_software/3_14_media-ui.md
+++ b/3_software/3_14_media-ui.md
@@ -1,29 +1,25 @@
 ## 3.14\. Media UI
 
 
-If device implementations include the UI framework that supports third-party
-apps that depend on [`MediaBrowser`](
-http://developer.android.com/reference/android/media/browse/MediaBrowser.html)
-and [`MediaSession`](
-http://developer.android.com/reference/android/media/session/MediaSession.html)
-, they:
+If device implementations include non-voice-activated applications (the Apps) that interact with
+third-party applications through [`MediaBrowser`](http://developer.android.com/reference/android/media/browse/MediaBrowser.html)
+or [`MediaSession`](http://developer.android.com/reference/android/media/session/MediaSession.html),
+the Apps:
 
-*    [C-1-1] MUST display [MediaItem](
-     http://developer.android.com/reference/android/media/browse/MediaBrowser.MediaItem.html)
-     icons and notification icons unaltered.
-*    [C-1-2] MUST display those items as described by MediaSession, e.g.,
-     metadata, icons, imagery.
-*    [C-1-3] MUST show app title.
-*    [C-1-4] MUST have a drawer or other mechanism to present [MediaBrowser](
-     http://developer.android.com/reference/android/media/browse/MediaBrowser.html)
-     hierarchy and provide user affordance for the [MediaBrowser](
-     http://developer.android.com/reference/android/media/browse/MediaBrowser.html)
-     hierarchy.
+*    [C-1-2] MUST clearly display icons obtained via getIconBitmap() or getIconUri() and titles
+     obtained via getTitle() as described in [`MediaDescription`](http://developer.android.com/reference/android/media/MediaDescription.html).
+     May shorten titles to comply with safety regulations (e.g. driver distraction).
+
+*    [C-1-3] MUST show the third-party application icon whenever displaying content provided by
+     this third-party application.
+
+*    [C-1-4] MUST allow the user to interact with the entire [`MediaBrowser`](http://developer.android.com/reference/android/media/browse/MediaBrowser.html)
+     hierarchy. MAY restrict the access to part of the hierarchy to comply with safety regulations
+     (e.g. driver distraction), but MUST NOT give preferential treatment based on content or
+     content provider.
+
 *    [C-1-5] MUST consider double tap of [`KEYCODE_HEADSETHOOK`](
      https://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_HEADSETHOOK)
-     or [`KEYCODE_MEDIA_PLAY_PAUSE`](
-     https://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_MEDIA_PLAY_PAUSE)
-     as [`KEYCODE_MEDIA_NEXT`](
-     https://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_MEDIA_NEXT)
-     for [`MediaSession.Callback#onMediaButtonEvent`](
-     https://developer.android.com/reference/android/media/session/MediaSession.Callback.html#onMediaButtonEvent%28android.content.Intent%29).
\ No newline at end of file
+     or [`KEYCODE_MEDIA_PLAY_PAUSE`](https://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_MEDIA_PLAY_PAUSE)
+     as [`KEYCODE_MEDIA_NEXT`](https://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_MEDIA_NEXT)
+     for [`MediaSession.Callback#onMediaButtonEvent`](https://developer.android.com/reference/android/media/session/MediaSession.Callback.html#onMediaButtonEvent%28android.content.Intent%29).
diff --git a/3_software/3_15_instant-apps.md b/3_software/3_15_instant-apps.md
index 1091e81..53ea0dc 100644
--- a/3_software/3_15_instant-apps.md
+++ b/3_software/3_15_instant-apps.md
@@ -13,6 +13,23 @@
     *   The target is explicitly exposed with [android:visibleToInstantApps](https://developer.android.com/reference/android/R.attr.html#visibleToInstantApps)
 *   [C-0-3] Instant Apps MUST NOT interact explicitly with installed apps unless the
     component is exposed via android:visibleToInstantApps.
-*   [C-0-4] IInstalled Apps MUST NOT see details about Instant Apps on the
+*   [C-0-4] Installed Apps MUST NOT see details about Instant Apps on the
     device unless the Instant App explicitly connects to the
     installed application.
+*   Device implementations MUST provide the following user affordances for
+    interacting with Instant Apps. The AOSP meets the requirements with the
+    default System UI, Settings, and Launcher. Device implementations:
+    *   [C-0-5] MUST provide a user affordance to view and delete Instant Apps
+        locally cached for each individual app package.
+    *   [C-0-6] MUST provide a persistent user notification that can be
+        collapsed while an Instant App is running in the foreground. This user
+        notification MUST include that Instant Apps do not require installation
+        and provide a user affordance that directs the user to the application
+        info screen in Settings. For Instant Apps launched via web intents, as
+        defined by using an intent with action set to `Intent.ACTION_VIEW` and
+        with a scheme of "http" or "https", an additional user affordance
+        SHOULD allow the user not to launch the Instant App and
+        launch the associated link with the configured web browser, if a browser
+        is available on the device.
+    *   [C-0-7] MUST allow running Instant Apps to be accessed from the Recents
+        function if the Recents function is available on the device.
diff --git a/3_software/3_17_Heavyweight_apps.md b/3_software/3_17_Heavyweight_apps.md
index 011b58a..f7d77d7 100644
--- a/3_software/3_17_Heavyweight_apps.md
+++ b/3_software/3_17_Heavyweight_apps.md
@@ -28,4 +28,4 @@
 
 *    [C-1-1] MUST ignore the [`cantSaveState`](https://developer.android.com/reference/android/R.attr#cantSaveState)
      attribute set by apps and MUST NOT change the app behavior based on that
-     attribute.
\ No newline at end of file
+     attribute.
diff --git a/3_software/3_1_managed-api-compatibility.md b/3_software/3_1_managed-api-compatibility.md
index 5e7a27a..a2eabb6 100644
--- a/3_software/3_1_managed-api-compatibility.md
+++ b/3_software/3_1_managed-api-compatibility.md
@@ -25,24 +25,33 @@
      includes APIs are omitted. See [section 7](#7_hardware_compatibility)
      for specific requirements for this scenario.
 
-*    [C-0-5] MUST restrict the use of 3rd-party app usage of hidden APIs,
-     defined as APIs in the android namespace decorated with the `@hidden`
-     annotation but not with a `@SystemAPI` or `@TestApi`, as described in the
-     [SDK documents](https://developer.android.com/preview/restrictions-non-sdk-interfaces)
-     and ship with each and every hidden API on the same restricted lists as
-     provided via the light-greylist, dark-greylist, and blacklist files in the
-     `prebuilts/runtime/appcompat/` path for the appropriate API level branch
-     in the AOSP. However they:
+*    [C-0-5] MUST NOT allow third-party apps to use non-SDK interfaces, which
+     are defined as methods and fields in the Java language packages that are
+     in the boot classpath in AOSP, and that do not form part of the public
+     SDK. This includes APIs decorated with the `@hide` annotation but not with
+     a `@SystemAPI`, as described in the [SDK documents](https://developer.android.com/distribute/best-practices/develop/restrictions-non-sdk-interfaces)
+     and private and package-private class members.
+
+*    [C-0-6] MUST ship with each and every non-SDK interface on the same restricted
+     lists as provided via the `greylist`, `greylist-max-o`, `greylist-max-p`,
+     and blacklist flags in `prebuilts/runtime/appcompat/hiddenapi-flags.csv`
+     path for the appropriate API level branch in the AOSP.
+
+*    [C-0-7] MUST support the [signed config](https://source.android.com/devices/tech/dalvik/signed-config)
+     dynamic update mechanism to remove non-SDK interfaces from a restricted list
+     by embedding signed configuration in any APK, using the existing public keys
+     present in AOSP.
+
+     However they:
 
      *   MAY, if a hidden API is absent or implemented differently on the device
          implementation, move the hidden API into the blacklist or omit it from
          all restricted lists (i.e. light-grey, dark-grey, black).
      *   MAY, if a hidden API does not already exist in the AOSP, add the hidden
          API to any of the restricted lists (i.e. light-grey, dark-grey, black).
-     *   MAY implement a dynamic update mechanism that moves a hidden API from a
-         restricted list into a less restrictive list, except for the whitelist.
-    
-## 3.1.1\. Android Extensions
+
+
+### 3.1.1\. Android Extensions
 
 Android includes the support of extending the managed APIs while keeping the
 same API level version.
@@ -53,7 +62,7 @@
 For example, Android 7.0 device implementations, running API level 24 MUST
 include at least version 1.
 
-## 3.1.2\. Android Library
+### 3.1.2\. Android Library
 
 Due to [Apache HTTP client deprecation](https://developer.android.com/preview/behavior-changes#apache-p),
 device implementations:
diff --git a/3_software/3_2_soft-api-compatibility.md b/3_software/3_2_soft-api-compatibility.md
index 27262b7..2846636 100644
--- a/3_software/3_2_soft-api-compatibility.md
+++ b/3_software/3_2_soft-api-compatibility.md
@@ -52,9 +52,9 @@
     of the currently-executing Android system, in human-readable format. This
     value MUST NOT be reused for different builds made available to end users. A
     typical use of this field is to indicate which build number or
-    source-control change identifier was used to generate the build. There are
-    no requirements on the specific format of this field, except that it MUST
-    NOT be null or the empty string ("").</td>
+    source-control change identifier was used to generate the build. The value
+    of this field MUST be encodable as printable 7-bit ASCII and match the
+    regular expression &ldquo;^[^ :\/~]+$&rdquo;.</td>
  </tr>
  <tr>
     <td>BOARD</td>
@@ -120,11 +120,8 @@
     <p>For example:</p>
 <p class="small">acme/myproduct/<br>
       &nbsp;&nbsp;&nbsp;&nbsp;mydevice:ANDROID_VERSION/LMYXX/3359:userdebug/test-keys</p>
-      <p>The fingerprint MUST NOT include whitespace characters. If other fields
-      included in the template above have whitespace characters, they MUST be
-      replaced in the build fingerprint with another character, such as the
-      underscore ("_") character. The value of this field MUST be encodable as
-      7-bit ASCII.</p></td>
+      <p>The fingerprint MUST NOT include whitespace characters. The value of
+      this field MUST be encodable as 7-bit ASCII.</p></td>
  </tr>
  <tr>
     <td>HARDWARE</td>
@@ -180,9 +177,10 @@
  <tr>
     <td>TAGS</td>
     <td>A comma-separated list of tags chosen by the device implementer that
-    further distinguishes the build. This field MUST have one of the values
-    corresponding to the three typical Android platform signing configurations:
-    release-keys, dev-keys, test-keys.</td>
+    further distinguishes the build. The tags MUST be encodable as 7-bit ASCII
+    and match the regular expression &ldquo;^[a-zA-Z0-9._-]+&rdquo; and MUST
+    have one of the values corresponding to the three typical Android platform
+    signing configurations: release-keys, dev-keys, and test-keys.</td>
  </tr>
  <tr>
     <td>TIME</td>
@@ -207,7 +205,7 @@
     that the build is not in any way vulnerable to any of the issues described
     up through the designated Android Public Security Bulletin. It MUST be in
     the format [YYYY-MM-DD], matching a defined string documented in the
-    <a href="source.android.com/security/bulletin"> Android Public Security
+    <a href="http://source.android.com/security/bulletin"> Android Public Security
     Bulletin</a> or in the <a href="http://source.android.com/security/advisory">
     Android Security Advisory</a>, for example "2015-11-01".</td>
  </tr>
@@ -386,12 +384,12 @@
 use to place outgoing calls. The AOSP implementation meets this requirement by
 including a "Calling Accounts option" menu within the "Calls" settings menu.
 
-*   [C-2-4] MUST allow the ['android.telecom.CallRedirectionService'](
+*   [C-2-4] MUST allow [`android.telecom.CallRedirectionService`](
     https://developer.android.com/reference/android/telecom/CallRedirectionService) for an app
     that holds the [`android.app.role.CALL_REDIRECTION`](
     https://developer.android.com/reference/android/app/role/RoleManager#ROLE_CALL_REDIRECTION)
     role.
-*   [C-2-5] MUST provide the user affordance to allow user to choose an app
+*   [C-2-5] MUST provide the user affordance to choose an app
     that holds the [`android.app.role.CALL_REDIRECTION`](
     https://developer.android.com/reference/android/app/role/RoleManager#ROLE_CALL_REDIRECTION)
     role.
@@ -409,11 +407,11 @@
     https://developer.android.com/reference/android/provider/Settings.html#ACTION_VOICE_INPUT_SETTINGS)
     intent to show a default app settings menu for voice input and assist.
 
-### 3.2.4\. Activities on secondary displays
+### 3.2.4\. Activities on secondary/multiple displays
 
 If device implementations allow launching normal [Android Activities](
-https://developer.android.com/reference/android/app/Activity.html) on secondary
-displays, they:
+https://developer.android.com/reference/android/app/Activity.html) on more than
+one display, they:
 
 *   [C-1-1] MUST set the `android.software.activities_on_secondary_displays`
     feature flag.
@@ -424,17 +422,14 @@
     display via the [`ActivityOptions.setLaunchDisplayId()`](
     https://developer.android.com/reference/android/app/ActivityOptions.html#setLaunchDisplayId%28int%29)
     API.
-*   [C-1-4] MUST destory all activities, when a display with the
+*   [C-1-4] MUST destroy all activities, when a display with the
     [`Display.FLAG_PRIVATE`](http://developer.android.com/reference/android/view/Display.html#FLAG_PRIVATE)
     flag is removed.
-*   [C-1-5] MUST resize accordingly all activities on a [`VirtualDisplay`](
-    https://developer.android.com/reference/android/hardware/display/VirtualDisplay.html)
-    if the display itself is resized.
-*   MAY show an IME (input method editor, a user control that enables users to
-    enter text) on the primary display, when a text input field becomes focused
-    on a secondary display.
-*   SHOULD implement the input focus on the secondary display independently of
-    the primary display, when touch or key inputs are supported.
+*   [C-1-5] MUST securely hide content on all screens when the device is locked
+    with a secure lock screen, unless the app opts in to show on top of lock
+    screen using [`Activity#setShowWhenLocked()`](
+    https://developer.android.com/reference/android/app/Activity#setShowWhenLocked%28boolean%29)
+    API.
 *   SHOULD have [`android.content.res.Configuration`](
     https://developer.android.com/reference/android/content/res/Configuration.html)
     which corresponds to that display in order to be displayed, operate
@@ -443,15 +438,6 @@
 
 If device implementations allow launching normal [Android Activities](
 https://developer.android.com/reference/android/app/Activity.html) on secondary
-displays and primary and secondary displays have different
-[android.util.DisplayMetrics](https://developer.android.com/reference/android/util/DisplayMetrics.html):
-
-*   [C-2-1] Non-resizeable activities (that have `resizeableActivity=false` in
-    `AndroidManifest.xml`) and apps targeting API level 23 or lower MUST NOT be
-    allowed on secondary displays.
-
-If device implementations allow launching normal [Android Activities](
-https://developer.android.com/reference/android/app/Activity.html) on secondary
 displays and a secondary display has the [android.view.Display.FLAG_PRIVATE](
 https://developer.android.com/reference/android/view/Display.html#FLAG_PRIVATE)
 flag:
diff --git a/3_software/3_3_native-api-compatibility.md b/3_software/3_3_native-api-compatibility.md
index d0c9c9f..fd1e785 100644
--- a/3_software/3_3_native-api-compatibility.md
+++ b/3_software/3_3_native-api-compatibility.md
@@ -41,6 +41,8 @@
     available to apps that include native code:
 
      *   libaaudio.so (AAudio native audio support)
+     *   libamidi.so (native MIDI support, if feature `android.software.midi`
+         is claimed as described in Section 5.9)
      *   libandroid.so (native Android activity support)
      *   libc (C library)
      *   libcamera2ndk.so
diff --git a/3_software/3_4_web-compatibility.md b/3_software/3_4_web-compatibility.md
index 0746841..0deaa46 100644
--- a/3_software/3_4_web-compatibility.md
+++ b/3_software/3_4_web-compatibility.md
@@ -32,6 +32,18 @@
      possible and if it supports the feature SHOULD conform to the
      [HTML5 specification](http://html.spec.whatwg.org/multipage/).
 
+*    [C-1-3] MUST render the provided content or remote URL content in a process
+     that is distinct from the application that instantiates the WebView. Specifically
+     the separate renderer process MUST hold lower privilege, run
+     as a separate user ID, have no access to the app's data directory,
+     have no direct network access, and only have access to the minimum-required
+     system services over Binder. The AOSP implementation of WebView meets
+     this requirement.
+
+Note that if device implementations are 32-bit or declare the feature flag
+`android.hardware.ram.low`, they are exempted from C-1-3.
+
+
 ### 3.4.2\. Browser Compatibility
 
 If device implementations include a standalone Browser application for general
diff --git a/3_software/3_5_api-behavioral-compatibility.md b/3_software/3_5_api-behavioral-compatibility.md
index 0d51391..cb5ab46 100644
--- a/3_software/3_5_api-behavioral-compatibility.md
+++ b/3_software/3_5_api-behavioral-compatibility.md
@@ -87,8 +87,8 @@
 *    [C-1-2] MUST provide user affordance to turn on / off the restrictions
 on each app.
 *    [C-1-3] MUST not automatically apply restrictions without evidence of poor
-system health behaviour, but MAY apply the restrictions on apps upon detection
-of poor system health behaviour like stuck wakelocks, long running services, and
+system health behavior, but MAY apply the restrictions on apps upon detection
+of poor system health behavior like stuck wakelocks, long running services, and
 other criteria. The criteria MAY be determined by device implementers but MUST
 be related to the app’s impact on the system health. Other criteria that is not
 purely related to the　system health, such as the app’s lack of popularity in
@@ -110,4 +110,4 @@
 https://developer.android.com/reference/android/app/usage/UsageStats). If device
 implementations extend the app restrictions that are implemented in AOSP, MUST
 follow the implementation described in [this document](
-https://souce.android.com/devices/tech/power/app_mgmt.html).
\ No newline at end of file
+https://source.android.com/devices/tech/power/app_mgmt.html).
diff --git a/3_software/3_6_api-namespaces.md b/3_software/3_6_api-namespaces.md
index a010e0d..cd2867d 100644
--- a/3_software/3_6_api-namespaces.md
+++ b/3_software/3_6_api-namespaces.md
@@ -50,4 +50,4 @@
 Note that the restrictions above correspond to standard conventions for naming
 APIs in the Java programming language; this section simply aims to reinforce
 those conventions and make them binding through inclusion in this Compatibility
-Definition.
\ No newline at end of file
+Definition.
diff --git a/3_software/3_7_runtime-compatibility.md b/3_software/3_7_runtime-compatibility.md
index 0bcfd7d..d049820 100644
--- a/3_software/3_7_runtime-compatibility.md
+++ b/3_software/3_7_runtime-compatibility.md
@@ -30,19 +30,31 @@
     <th>Minimum Application Memory</th>
  </tr>
  <tr>
-    <td rowspan="12">Android Watch</td>
+    <td rowspan="16">Android Watch</td>
     <td>120 dpi (ldpi)</td>
-    <td rowspan="3">32MB</td>
+    <td rowspan="6">32MB</td>
+ </tr>
+ <tr>
+    <td>140 dpi (140dpi)</td>
  </tr>
  <tr>
     <td>160 dpi (mdpi)</td>
  </tr>
  <tr>
+    <td>180 dpi (180dpi)</td>
+ </tr>
+ <tr>
+    <td>200 dpi (200dpi)</td>
+ </tr>
+ <tr>
     <td>213 dpi (tvdpi)</td>
  </tr>
  <tr>
+    <td>220 dpi (220dpi)</td>
+    <td rowspan="3">36MB</td>
+ </tr>
+ <tr>
     <td>240 dpi (hdpi)</td>
-    <td rowspan="2">36MB</td>
  </tr>
  <tr>
     <td>280 dpi (280dpi)</td>
@@ -75,16 +87,28 @@
     <td>154MB</td>
  </tr>
  <tr>
-    <td rowspan="12">small/normal</td>
+    <td rowspan="16">small/normal</td>
     <td>120 dpi (ldpi)</td>
-    <td rowspan="2">32MB</td>
+    <td rowspan="3">32MB</td>
+ </tr>
+ <tr>
+    <td>140 dpi (140dpi)</td>
  </tr>
  <tr>
     <td>160 dpi (mdpi)</td>
  </tr>
  <tr>
+    <td>180 dpi (180dpi)</td>
+    <td rowspan="6">48MB</td>
+ </tr>
+ <tr>
+    <td>200 dpi (200dpi)</td>
+ </tr>
+ <tr>
     <td>213 dpi (tvdpi)</td>
-    <td rowspan="3">48MB</td>
+ </tr>
+ <tr>
+    <td>220 dpi (220dpi)</td>
  </tr>
  <tr>
     <td>240 dpi (hdpi)</td>
@@ -120,17 +144,29 @@
     <td>256MB</td>
  </tr>
  <tr>
-    <td rowspan="12">large</td>
+    <td rowspan="16">large</td>
     <td>120 dpi (ldpi)</td>
     <td>32MB</td>
  </tr>
  <tr>
+    <td>140 dpi (140dpi)</td>
+    <td rowspan="2">48MB</td>
+ </tr>
+ <tr>
     <td>160 dpi (mdpi)</td>
-    <td>48MB</td>
+ </tr>
+ <tr>
+    <td>180 dpi (180dpi)</td>
+    <td rowspan="5">80MB</td>
+ </tr>
+ <tr>
+    <td>200 dpi (200dpi)</td>
  </tr>
  <tr>
     <td>213 dpi (tvdpi)</td>
-    <td rowspan="2">80MB</td>
+ </tr>
+ <tr>
+    <td>220 dpi (220dpi)</td>
  </tr>
  <tr>
     <td>240 dpi (hdpi)</td>
@@ -168,17 +204,29 @@
     <td>512MB</td>
  </tr>
  <tr>
-    <td rowspan="12">xlarge</td>
+    <td rowspan="16">xlarge</td>
     <td>120 dpi (ldpi)</td>
     <td>48MB</td>
  </tr>
  <tr>
+    <td>140 dpi (140dpi)</td>
+    <td rowspan="2">80MB</td>
+ </tr>
+ <tr>
     <td>160 dpi (mdpi)</td>
-    <td>80MB</td>
+ </tr>
+ <tr>
+    <td>180 dpi (180dpi)</td>
+    <td rowspan="5">96MB</td>
+ </tr>
+ <tr>
+    <td>200 dpi (200dpi)</td>
  </tr>
  <tr>
     <td>213 dpi (tvdpi)</td>
-    <td rowspan="2">96MB</td>
+ </tr>
+ <tr>
+    <td>220 dpi (220dpi)</td>
  </tr>
  <tr>
     <td>240 dpi (hdpi)</td>
diff --git a/3_software/3_8_user-interface-compatibility.md b/3_software/3_8_user-interface-compatibility.md
index 74ad322..2d32654 100644
--- a/3_software/3_8_user-interface-compatibility.md
+++ b/3_software/3_8_user-interface-compatibility.md
@@ -168,7 +168,7 @@
     https://developer.android.com/reference/android/app/Notification.Style.html)
     API class and its subclasses.
 
-If device impelementations support heads-up notifications: they:
+If device implementations support heads-up notifications: they:
 
 *   [C-3-1] MUST use the heads-up notification view and resources
     as described in the [`Notification.Builder`](
@@ -480,6 +480,26 @@
 
 *   SHOULD provide an input method to the user for these emoji characters.
 
+Android includes support to render Myanmar fonts. Myanmar has several
+non-Unicode compliant fonts, commonly known as “Zawgyi,” for rendering Myanmar
+languages.
+
+If device implementations include support for Burmese, they:
+
+    * [C-2-1] MUST render text with Unicode compliant font as default;
+      non-Unicode compliant font MUST NOT be set as default font unless the user
+      chooses it in the language picker.
+    * [C-2-2] MUST support a Unicode font and a non-Unicode compliant font if a
+      non-Unicode compliant font is supported on the device.  Non-Unicode
+      compliant font MUST NOT remove or overwrite the Unicode font.
+    * [C-2-3] MUST render text with non-Unicode compliant font ONLY IF a
+      language code with [script code Qaag](
+      http://unicode.org/reports/tr35/#unicode_script_subtag_validity) is
+      specified (e.g. my-Qaag). No other ISO language or region codes (whether
+      assigned, unassigned, or reserved) can be used to refer to non-Unicode
+      compliant font for Myanmar. App developers and web page authors can
+      specify my-Qaag as the designated language code as they would for any
+      other language.
 
 ### 3.8.14\. Multi-windows
 
@@ -491,17 +511,15 @@
     [multi-window mode support documentation](
     https://developer.android.com/guide/topics/ui/multi-window.html) and meet
     the following requirements:
-*   [C-1-2] Applications can indicate whether they are capable of operating in
-    multi-window mode in the `AndroidManifest.xml` file, either explicitly via
-    setting the [`android:resizeableActivity`](https://developer.android.com/reference/android/R.attr.html#resizeableActivity)
-    attribute to `true` or implicitly by having the targetSdkVersion > 24. Apps that
-    explicitly set this attribute to `false` in their manifest MUST NOT be
-    launched in multi-window mode. Older apps with targetSdkVersion < 24 that
-    did not set this `android:resizeableActivity` attribute MAY be launched in
-    multi-window mode, but the system MUST provide warning that the app may not
-    work as expected in multi-window mode.
+*   [C-1-2] MUST honor [`android:resizeableActivity`](
+    https://developer.android.com/reference/android/R.attr.html#resizeableActivity)
+    that is set by an app in the `AndroidManifest.xml` file as described in
+    [this SDK](https://developer.android.com/guide/topics/manifest/application-element#resizeableActivity).
 *   [C-1-3] MUST NOT offer split-screen or freeform mode if
-    the screen height < 440 dp and the screen width < 440 dp.
+    the screen height is less than 440 dp and the screen width is less than 440
+    dp.
+*   [C-1-4] An activity MUST NOT be resized to a size smaller than 220dp in
+    multi-window modes other than Picture-in-Picture.
 *   Device implementations with screen size `xlarge` SHOULD support freeform
     mode.
 
diff --git a/3_software/3_9_device-administration.md b/3_software/3_9_device-administration.md
index 9b66b25..c9fd8d5 100644
--- a/3_software/3_9_device-administration.md
+++ b/3_software/3_9_device-administration.md
@@ -140,7 +140,7 @@
     notifications, contacts and messaging apps they SHOULD be badged with the
     same badge used to indicate managed profile applications.
 
-## 3.9.3 Managed User Support
+### 3.9.3 Managed User Support
 
 If device implementations declare `android.software.managed_users`, they:
 
diff --git a/4_application-packaging/4_0_intro.md b/4_application-packaging/4_0_intro.md
index be0b3d7..27ae4f2 100644
--- a/4_application-packaging/4_0_intro.md
+++ b/4_application-packaging/4_0_intro.md
@@ -62,4 +62,4 @@
 by the same system API `PackageManager.setHarmfulAppWarning` as potentially
 harmful.
 *    SHOULD provide a user affordance to choose to uninstall or launch an
-application on the warning dialog.
\ No newline at end of file
+application on the warning dialog.
diff --git a/5_multimedia/5_0_intro.md b/5_multimedia/5_0_intro.md
index e56d278..b864b91 100644
--- a/5_multimedia/5_0_intro.md
+++ b/5_multimedia/5_0_intro.md
@@ -8,12 +8,11 @@
 *   [C-0-2] MUST declare and report support of the encoders, decoders available
     to third-party applications via [`MediaCodecList`](
     http://developer.android.com/reference/android/media/MediaCodecList.html).
-*   [C-0-3] MUST be able to decode and make available to third-party apps all
-    the formats it can encode. This includes all bitstreams that its encoders
-    generate and the profiles reported in its [`CamcorderProfile`](
+*   [C-0-3] MUST be able to properly decode and make available to third-party
+    apps all the formats it can encode. This includes all bitstreams that its
+    encoders generate and the profiles reported in its [`CamcorderProfile`](
     http://developer.android.com/reference/android/media/CamcorderProfile.html).
 
-
 Device implementations:
 
 *   SHOULD aim for minimum codec latency, in others words, they
diff --git a/5_multimedia/5_10_professional-audio.md b/5_multimedia/5_10_professional-audio.md
index 4af9364..eaf0537 100644
--- a/5_multimedia/5_10_professional-audio.md
+++ b/5_multimedia/5_10_professional-audio.md
@@ -16,20 +16,27 @@
 *    [C-1-4] MUST report support for feature `android.software.midi`.
 *    [C-1-5] MUST meet latencies and USB audio requirements using both the
 [OpenSL ES](https://developer.android.com/ndk/guides/audio/opensl-for-android.html)
-PCM buffer queue and
-[AAudio native audio](https://developer.android.com/ndk/guides/audio/aaudio/aaudio.html)
-APIs.
+PCM buffer queue API and at least one path of the [AAudio native audio](https://developer.android.com/ndk/guides/audio/aaudio/aaudio.html)
+API.
+*    [SR] Are STRONGLY RECOMMENDED to meet latencies and USB audio requirements
+using the [AAudio native audio](https://developer.android.com/ndk/guides/audio/aaudio/aaudio.html)
+API over the [MMAP path](https://source.android.com/devices/audio/aaudio).
+*    [C-1-6] MUST have Cold output latency of 200 milliseconds or less.
+*    [C-1-7] MUST have Cold input latency of 200 milliseconds or less.
 *    [SR] Are STRONGLY RECOMMENDED to provide a consistent level of CPU
 performance while audio is active and CPU load is varying. This should be tested
-using [SimpleSynth](https://github.com/googlesamples/android-audio-high-performance/tree/master/SimpleSynth)
-commit [1bd6391](https://github.com/googlesamples/android-audio-high-performance/commit/1bd6391f8ba9512f9f8798e979bc55b899f856d1).
-The SimpleSynth app needs to be run with below parameters and achieve zero
-underruns after 10 minutes:
-    * Work cycles: 200,000
-    * Variable load: ON (this will switch between 100% and 10% of the work
-      cycles value every 2 seconds and is designed to test CPU governor
-      behavior)
-    * Stabilized load: OFF
+using the Android app version of [SynthMark](https://github.com/google/synthmark)
+commit id [09b13c6f49ea089f8c31e5d035f912cc405b7ab8](https://github.com/google/synthmark/commit/09b13c6f49ea089f8c31e5d035f912cc405b7ab8).
+SynthMark uses a software synthesizer running on a simulated audio framework
+that measures system performance. The SynthMark app needs to be run using the
+“Automated Test” option and achieve the following results:
+    * voicemark.90 &gt;= 32 voices
+    * latencymark.fixed.little &lt;= 15 msec
+    * latencymark.dynamic.little &lt;= 50 msec
+
+See the SynthMark [documentation](https://github.com/google/synthmark/blob/master/docs/README.md)
+for an explanation of the benchmarks.
+
 *    SHOULD minimize audio clock inaccuracy and drift relative to standard time.
 *    SHOULD minimize audio clock drift relative to the CPU `CLOCK_MONOTONIC`
 when both are active.
@@ -38,8 +45,7 @@
 *    SHOULD document audio latency measurements over all paths.
 *    SHOULD minimize jitter in audio buffer completion callback entry times, as this
 affects usable percentage of full CPU bandwidth by the callback.
-*    SHOULD provide zero audio underruns (output) or overruns (input) under normal use
-at reported latency.
+*    SHOULD provide zero audio glitches under normal use at reported latency.
 *    SHOULD provide zero inter-channel latency difference.
 *    SHOULD minimize MIDI mean latency over all transports.
 *    SHOULD minimize MIDI latency variability under load (jitter) over all transports.
@@ -90,9 +96,12 @@
 milliseconds or less over the USB host mode port using USB audio class.
 *   The continuous round-trip audio latency SHOULD be 10 milliseconds
 or less over the USB host mode port using USB audio class.
+*   [C-SR] Are STRONGLY RECOMMENDED to support simultaneous I/O up to 8 channels
+    each direction, 96 kHz sample rate, and 24-bit or 32-bit depth, when used
+    with USB audio peripherals that also support these requirements.
 
 If device implementations include an HDMI port, they:
 
-*   [C-4-1] MUST support output in stereo and eight channels at 20-bit or
+*   SHOULD support output in stereo and eight channels at 20-bit or
 24-bit depth and 192 kHz without bit-depth loss or resampling,
 in at least one configuration.
diff --git a/5_multimedia/5_11_unprocessed-audio.md b/5_multimedia/5_11_unprocessed-audio.md
index fdbb2c3..b90b625 100644
--- a/5_multimedia/5_11_unprocessed-audio.md
+++ b/5_multimedia/5_11_unprocessed-audio.md
@@ -60,4 +60,4 @@
 *    [C-2-1] MUST return `null` for the `AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED)`
 API method, to properly indicate the lack of support.
 *    [SR] are still STRONGLY RECOMMENDED to satisfy as many of the requirements
-for the signal path for the unprocessed recording source.
\ No newline at end of file
+for the signal path for the unprocessed recording source.
diff --git a/5_multimedia/5_1_media-codecs.md b/5_multimedia/5_1_media-codecs.md
index 62573d7..e1e9ba5 100644
--- a/5_multimedia/5_1_media-codecs.md
+++ b/5_multimedia/5_1_media-codecs.md
@@ -5,9 +5,18 @@
 See more details in [5.1.3. Audio Codecs Details](#5_1_3_audio_codecs_details).
 
 If device implementations declare `android.hardware.microphone`,
-they MUST support the following audio encoding:
+they MUST support encoding the following audio formats and make them available
+to third-party apps:
 
 *    [C-1-1] PCM/WAVE
+*    [C-1-2] FLAC
+*    [C-1-3] Opus
+
+All audio encoders MUST support:
+
+*  [C-3-1] PCM 16-bit native byte order audio frames via the [`android.media.MediaCodec`](
+https://developer.android.com/reference/android/media/MediaCodec.html#raw-audio-buffers)
+API.
 
 
 ### 5.1.2\. Audio Decoding
@@ -24,13 +33,16 @@
 *    [C-1-3] MPEG-4 HE AACv2 Profile (enhanced AAC+)
 *    [C-1-4] AAC ELD (enhanced low delay AAC)
 *    [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, which includes
-             the USAC Baseline Profile, and ISO/IEC 23003-4 Dynamic Range Control
-             Profile)
+             the USAC Baseline Profile, and ISO/IEC 23003-4 Dynamic Range
+             Control Profile)
 *    [C-1-5] FLAC
 *    [C-1-6] MP3
 *    [C-1-7] MIDI
 *    [C-1-8] Vorbis
-*    [C-1-9] PCM/WAVE
+*    [C-1-9] PCM/WAVE including high-resolution audio
+formats up to 24 bits, 192 kHz sample rate, and 8 channels.
+Note that this requirement is for decoding only, and that a device
+is permitted to downsample and downmix during the playback phase.
 *    [C-1-10] Opus
 
 If device implementations support the decoding of AAC input buffers of
@@ -44,10 +56,12 @@
 *    [C-2-2] Dynamic range metadata MUST be as defined in "Dynamic Range Control
 (DRC)" in ISO/IEC 14496-3, and the `android.media.MediaFormat` DRC keys to
 configure the dynamic range-related behaviors of the audio decoder. The
-AAC DRC keys were introduced in API 21,and are:
+AAC DRC keys were introduced in API 21, and are:
 `KEY_AAC_DRC_ATTENUATION_FACTOR`, `KEY_AAC_DRC_BOOST_FACTOR`,
 `KEY_AAC_DRC_HEAVY_COMPRESSION`, `KEY_AAC_DRC_TARGET_REFERENCE_LEVEL` and
 `KEY_AAC_ENCODED_TARGET_LEVEL`.
+*    [SR] It is STRONGLY RECOMMENDED that requirements C-2-1 and C-2-2 above are
+satisfied by all AAC audio decoders.
 
 When decoding USAC audio, MPEG-D (ISO/IEC 23003-4):
 
@@ -67,13 +81,19 @@
 
 *    ISO/IEC 23003-4 metadata SHALL take precedence.
 
+All audio decoders MUST support outputting:
+
+*  [C-6-1] PCM 16-bit native byte order audio frames via the [`android.media.MediaCodec`](
+https://developer.android.com/reference/android/media/MediaCodec.html#raw-audio-buffers)
+API.
+
 ### 5.1.3\. Audio Codecs Details
 
 <table>
  <tr>
     <th>Format/Codec</th>
     <th>Details</th>
-    <th>Supported File Types/Container Formats</th>
+    <th>File Types/Container Formats to be supported</th>
  </tr>
  <tr>
     <td>MPEG-4 AAC Profile<br />(AAC LC)</td>
@@ -84,14 +104,19 @@
     <li class="table_list">3GPP (.3gp)</li>
     <li class="table_list">MPEG-4 (.mp4, .m4a)</li>
     <li class="table_list">ADTS raw AAC (.aac, ADIF not supported)</li>
-    <li class="table_list">MPEG-TS (.ts, not seekable)</li></ul>
+    <li class="table_list">MPEG-TS (.ts, not seekable, decode only)</li>
+    <li class="table_list">Matroska (.mkv, decode only)</li></ul>
     </td>
  </tr>
  <tr>
     <td>MPEG-4 HE AAC Profile (AAC+)</td>
     <td>Support for mono/stereo/5.0/5.1 content with standard
     sampling rates from 16 to 48 kHz.</td>
-    <td></td>
+    <td>
+    <ul>
+    <li class="table_list">3GPP (.3gp)</li>
+    <li class="table_list">MPEG-4 (.mp4, .m4a)</li></ul>
+    </td>
  </tr>
  <tr>
     <td>MPEG-4 HE AACv2<br />
@@ -99,13 +124,21 @@
 Profile (enhanced AAC+)</td>
     <td>Support for mono/stereo/5.0/5.1 content with standard
     sampling rates from 16 to 48 kHz.</td>
-    <td></td>
+    <td>
+    <ul>
+    <li class="table_list">3GPP (.3gp)</li>
+    <li class="table_list">MPEG-4 (.mp4, .m4a)</li></ul>
+    </td>
  </tr>
  <tr>
     <td>AAC ELD (enhanced low delay AAC)</td>
     <td>Support for mono/stereo content with standard sampling rates from 16 to
     48 kHz.</td>
-    <td></td>
+    <td>
+    <ul>
+    <li class="table_list">3GPP (.3gp)</li>
+    <li class="table_list">MPEG-4 (.mp4, .m4a)</li></ul>
+    </td>
  </tr>
  <tr>
     <td>USAC</td>
@@ -122,21 +155,32 @@
  </tr>
  <tr>
     <td>AMR-WB</td>
-    <td>9 rates from 6.60 kbit/s to 23.85 kbit/s sampled @ 16 kHz</td>
-    <td></td>
+    <td>9 rates from 6.60 kbit/s to 23.85 kbit/s sampled @ 16 kHz, as defined at
+      <a href="https://www.loc.gov/preservation/digital/formats/fdd/fdd000255.shtml">
+      AMR-WB, Adaptive Multi-Rate - Wideband Speech Codec</a></td>
+    <td>3GPP (.3gp)</td>
  </tr>
  <tr>
     <td>FLAC</td>
-    <td>Mono/Stereo (no multichannel). Sample rates up to 48 kHz (but up to 44.1
-    kHz is RECOMMENDED on devices with 44.1 kHz output, as the 48 to 44.1 kHz
-    downsampler does not include a low-pass filter). 16-bit RECOMMENDED; no
-    dither applied for 24-bit.</td>
-    <td>FLAC (.flac) only</td>
+    <td>For both encoder and decoder: at least Mono and Stereo modes MUST be
+      supported. Sample rates up to 192 kHz MUST be supported; 16-bit and 24-bit
+      resolution MUST be supported. FLAC 24-bit audio data handling MUST be
+      available with floating point audio configuration.</td>
+    <td>
+    <ul>
+    <li class="table_list">FLAC (.flac)</li>
+    <li class="table_list">MPEG-4 (.mp4, .m4a, decode only)</li>
+    <li class="table_list">Matroska (.mkv, decode only)</li></ul>
+    </td>
  </tr>
  <tr>
     <td>MP3</td>
     <td>Mono/Stereo 8-320Kbps constant (CBR) or variable bitrate (VBR)</td>
-    <td>MP3 (.mp3)</td>
+    <td>
+    <ul>
+    <li class="table_list">MP3 (.mp3)</li>
+    <li class="table_list">MPEG-4 (.mp4, .m4a, decode only)</li>
+    <li class="table_list">Matroska (.mkv, decode only)</li></td>
  </tr>
  <tr>
     <td>MIDI</td>
@@ -151,21 +195,30 @@
  <tr>
     <td>Vorbis</td>
     <td></td>
-    <td><ul>
+    <td>
+    <ul>
     <li class="table_list">Ogg (.ogg)</li>
-    <li class="table_list">Matroska (.mkv, Android 4.0+)</li></ul></td>
+    <li class="table_list">MPEG-4 (.mp4, .m4a, decode only)</li>
+    <li class="table_list">Matroska (.mkv)</li>
+    <li class="table_list">Webm (.webm)</li></ul></td>
  </tr>
  <tr>
     <td>PCM/WAVE</td>
-    <td>16-bit linear PCM (rates up to limit of hardware). Devices MUST support
-    sampling rates for raw PCM recording at 8000, 11025, 16000, and 44100 Hz
-    frequencies.</td>
+    <td>PCM codec MUST support 16-bit linear PCM and 16-bit float. WAVE
+      extractor must support 16-bit, 24-bit, 32-bit linear PCM and 32-bit float
+      (rates up to limit of hardware). Sampling rates MUST be supported from
+      8 kHz to 192 kHz.</td>
     <td>WAVE (.wav)</td>
  </tr>
  <tr>
     <td>Opus</td>
     <td></td>
-    <td>Matroska (.mkv), Ogg(.ogg)</td>
+    <td>
+    <ul>
+    <li class="table_list">Ogg (.ogg)</li>
+    <li class="table_list">MPEG-4 (.mp4, .m4a, decode only)</li>
+    <li class="table_list">Matroska (.mkv)</li>
+    <li class="table_list">Webm (.webm)</li></ul></td>
  </tr>
 </table>
 
@@ -179,11 +232,22 @@
 *    [C-0-2] PNG
 *    [C-0-3] WebP
 
+If device implementations support HEIC encoding via `android.media.MediaCodec`
+for media type [`MIMETYPE_IMAGE_ANDROID_HEIC`](
+https://developer.android.com/reference/android/media/MediaFormat.html#MIMETYPE_IMAGE_ANDROID_HEIC),
+they:
+
+*    [C-1-1] MUST provide a hardware-accelerated HEVC encoder codec that
+supports [`BITRATE_MODE_CQ`](https://developer.android.com/reference/android/media/MediaCodecInfo.EncoderCapabilities.html#BITRATE_MODE_CQ)
+bitrate control mode, [`HEVCProfileMainStill`](
+https://developer.android.com/reference/android/media/MediaCodecInfo.CodecProfileLevel.html#HEVCProfileMainStill)
+profile and 512 x 512 px frame size.
+
 ### 5.1.5\. Image Decoding
 
 See more details in [5.1.6. Image Codecs Details](#5_1_6_image_codecs_details).
 
-Device impelementations MUST support decoding the following image encoding:
+Device implementations MUST support decoding the following image encoding:
 
 *    [C-0-1] JPEG
 *    [C-0-2] GIF
@@ -193,6 +257,13 @@
 *    [C-0-6] Raw
 *    [C-0-7] HEIF (HEIC)
 
+Image decoders that support a high bit-depth format (9+ bits per channel)
+
+*   [C-1-1] MUST support outputting an 8-bit equivalent format if requested by
+the application, for example, via the [`ARGB_8888`](
+https://developer.android.com/reference/android/graphics/Bitmap.Config.html#ARGB_8888)
+config of `android.graphics.Bitmap`.
+
 ### 5.1.6\. Image Codecs Details
 
 <table>
@@ -239,7 +310,21 @@
  </tr>
 </table>
 
+Image encoder and decoders exposed through the [MediaCodec](
+https://developer.android.com/reference/android/media/MediaCodec) API
 
+*   [C-1-1] MUST support YUV420 8:8:8 flexible color
+format (`COLOR_FormatYUV420Flexible`) through [`CodecCapabilities`](
+https://developer.android.com/reference/android/media/MediaCodecInfo.CodecCapabilities).
+
+*   [SR] STRONGLY RECOMMENDED to support RGB888 color format for input Surface
+mode.
+
+*   [C-1-3] MUST support at least one of a planar or semiplanar
+YUV420 8:8:8 color format: `COLOR_FormatYUV420PackedPlanar` (equivalent to
+`COLOR_FormatYUV420Planar`) or `COLOR_FormatYUV420PackedSemiPlanar` (equivalent
+to `COLOR_FormatYUV420SemiPlanar`). They are STRONGLY RECOMMENDED to support
+both.
 
 ### 5.1.7\. Video Codecs
 
@@ -253,8 +338,24 @@
 accommodate the largest feasible compressed and uncompressed frame as dictated
 by the standard and configuration but also not overallocate.
 
-*   [C-1-2] Video encoders and decoders MUST support YUV420 flexible color
-format (COLOR_FormatYUV420Flexible).
+*   [C-1-2] Video encoders and decoders MUST support YUV420 8:8:8 flexible color
+formats (`COLOR_FormatYUV420Flexible`) through [`CodecCapabilities`](
+https://developer.android.com/reference/android/media/MediaCodecInfo.CodecCapabilities).
+
+*   [C-1-3] Video encoders and decoders MUST support at least one of a planar or
+semiplanar YUV420 8:8:8 color format: `COLOR_FormatYUV420PackedPlanar`
+(equivalent to `COLOR_FormatYUV420Planar`) or
+`COLOR_FormatYUV420PackedSemiPlanar` (equivalent to `COLOR_FormatYUV420SemiPlanar`).
+They are STRONGLY RECOMMENDED to support both.
+
+*   [SR] Video encoders and decoders are STRONGLY RECOMMENDED to support
+at least one of a hardware optimized planar or semiplanar YUV420 8:8:8 color
+format (YV12, NV12, NV21 or equivalent vendor optimized format.)
+
+*   [C-1-5] Video decoders that support a high bit-depth format
+(9+ bits per channel) MUST support outputting an 8-bit equivalent format if
+requested by the application. This MUST be reflected by supporting an
+YUV420 8:8:8 color format via `android.media.MediaCodecInfo`.
 
 If device implementations advertise HDR profile support through
 [`Display.HdrCapabilities`](
@@ -271,7 +372,14 @@
 *   [C-3-1] MUST support the refresh periods in the range of 10 - 60 frames and
 accurately operate within 20% of configured refresh period.
 
+Unless the application specifies otherwise using the [`KEY_COLOR_FORMAT`](
+https://developer.android.com/reference/android/media/MediaFormat.html#KEY_COLOR_FORMAT)
+format key, video decoder implementations
 
+*   [C-4-1] MUST default to the color format optimized for hardware display
+if configured using Surface output
+*   [C-4-2] MUST default to a YUV420 8:8:8 color format optimized for CPU
+reading if configured to not use Surface output.
 
 ### 5.1.8\. Video Codecs List
 
@@ -280,14 +388,15 @@
  <tr>
     <th>Format/Codec</th>
     <th>Details</th>
-    <th>Supported File Types/<br>Container Formats</th>
+    <th>File Types/Container Formats to be supported</th>
  </tr>
  <tr>
     <td>H.263</td>
     <td></td>
     <td><ul>
     <li class="table_list">3GPP (.3gp)</li>
-    <li class="table_list">MPEG-4 (.mp4)</li></ul></td>
+    <li class="table_list">MPEG-4 (.mp4)</li>
+    <li class="table_list">Matroska (.mkv, decode only)</li></ul></td>
  </tr>
  <tr>
     <td>H.264 AVC</td>
@@ -296,23 +405,31 @@
     <td><ul>
     <li class="table_list">3GPP (.3gp)</li>
     <li class="table_list">MPEG-4 (.mp4)</li>
-    <li class="table_list">MPEG-2 TS (.ts, AAC audio only, not seekable, Android
-    3.0+)</li></ul></td>
+    <li class="table_list">MPEG-2 TS (.ts, not seekable)</li>
+    <li class="table_list">Matroska (.mkv, decode only)</li></ul></td>
  </tr>
  <tr>
     <td>H.265 HEVC</td>
     <td>See <a href="#5_3_video_decoding">section 5.3</a> for details</td>
-    <td>MPEG-4 (.mp4)</td>
+    <td><ul>
+    <li class="table_list">MPEG-4 (.mp4)</li>
+    <li class="table_list">Matroska (.mkv, decode only)</li></ul></td>
  </tr>
-<tr>
-  <td>MPEG-2</td>
-  <td>Main Profile</td>
-  <td>MPEG2-TS</td>
-</tr>
+ <tr>
+    <td>MPEG-2</td>
+    <td>Main Profile</td>
+    <td><ul>
+    <li class="table_list">MPEG2-TS (.ts, not seekable)</li>
+    <li class="table_list">MPEG-4 (.mp4, decode only)</li>
+    <li class="table_list">Matroska (.mkv, decode only)</li></ul></td>
+ </tr>
  <tr>
     <td>MPEG-4 SP</td>
     <td></td>
-    <td>3GPP (.3gp)</td>
+    <td><ul>
+    <li class="table_list">3GPP (.3gp)</li>
+    <li class="table_list">MPEG-4 (.mp4)</li>
+    <li class="table_list">Matroska (.mkv, decode only)</li></ul></td>
  </tr>
  <tr>
     <td>VP8</td>
@@ -336,3 +453,115 @@
 </table>
 
 
+### 5.1.9\. Media Codec Security
+
+Device implementations MUST ensure compliance with media codec security features
+as described below.
+
+Android includes support for OMX, a cross-platform multimedia acceleration API,
+as well as Codec 2.0, a low-overhead multimedia acceleration API.
+
+If device implementations support multimedia, they:
+
+*   [C-1-1] MUST provide support for media codecs either via OMX or Codec 2.0
+APIs (or both) as in the Android Open Source Project and not disable or
+circumvent the security protections. This specifically does not mean that every
+codec MUST use either the OMX or Codec 2.0 API, only that support for at least
+one of these APIs MUST be available, and support for the available APIs MUST
+include the security protections present.
+*   [C-SR] Are STRONGLY RECOMMENDED to include support for Codec 2.0 API.
+
+If device implementations do not support the Codec 2.0 API, they:
+
+*   [C-2-1] MUST include the corresponding OMX software codec from the Android
+Open Source Project (if it is available) for each media format and type
+(encoder or decoder) supported by the device.
+*   [C-2-2] Codecs that have names starting with "OMX.google." MUST be based
+on their Android Open Source Project source code.
+*   [C-SR]  Are STRONGLY RECOMMENDED that the OMX software codecs run in a codec
+process that does not have access to hardware drivers other than memory mappers.
+
+If device implementations support Codec 2.0 API, they:
+
+*   [C-3-1] MUST include the corresponding Codec 2.0 software codec from the
+Android Open Source Project (if it is available) for each media format and type
+(encoder or decoder) supported by the device.
+*   [C-3-2] MUST house the Codec 2.0 software codecs in the software codec
+process as provided in the Android Open Source Project to make it possible
+to more narrowly grant access to software codecs.
+*   [C-3-3] Codecs that have names starting with "c2.android." MUST be based
+on their Android Open Source Project source code.
+
+### 5.1.10\. Media Codec Characterization
+
+If device implementations support media codecs, they:
+
+*  [C-1-1] MUST return correct values of media codec characterization via the
+   [`MediaCodecInfo`](
+   https://developer.android.com/reference/android/media/MediaCodecInfo)
+   API.
+
+In particular:
+
+*  [C-1-2] Codecs with names starting with "OMX." MUST use the OMX APIs
+and have names that conform to OMX IL naming guidelines.
+*  [C-1-3] Codecs with names starting with "c2." MUST use the Codec 2.0 API and
+have names that conform to Codec 2.0 naming guidelines for Android.
+*  [C-1-4] Codecs with names starting with "OMX.google." or "c2.android." MUST
+NOT be characterized as vendor or as hardware-accelerated.
+*  [C-1-5] Codecs that run in a codec process (vendor or system) that have
+access to hardware drivers other than memory allocators and mappers MUST NOT
+be characterized as software-only.
+*  [C-1-6] Codecs not present in the Android Open Source Project or not based
+on the source code in that project MUST be characterized as vendor.
+*  [C-1-7] Codecs that utilize hardware acceleration MUST be characterized
+as hardware accelerated.
+*  [C-1-8] Codec names MUST NOT be misleading. For example, codecs named
+"decoders" MUST support decoding, and those named "encoders" MUST support
+encoding. Codecs with names containing media formats MUST support those
+formats.
+
+If device implementations support video codecs:
+
+*  [C-2-1] All video codecs MUST publish achievable frame rate data for the
+following sizes if supported by the codec:
+
+<table>
+  <tr>
+    <th></th>
+    <th>SD (low quality)</th>
+    <th>SD (high quality)</th>
+    <th>HD 720p</th>
+    <th>HD 1080p</th>
+    <th>UHD</th>
+  </tr>
+  <tr>
+    <th>Video resolution</th>
+    <td><ul>
+    <li class="table_list">176 x 144 px (H263, MPEG2, MPEG4)</li>
+    <li class="table_list">352 x 288 px (MPEG4 encoder, H263, MPEG2)</li>
+    <li class="table_list">320 x 180 px (VP8, VP8)</li>
+    <li class="table_list">320 x 240 px (other)</li></ul>
+    </td>
+    <td><ul>
+    <li class="table_list">704 x 576 px (H263)</li>
+    <li class="table_list">640 x 360 px (VP8, VP9)</li>
+    <li class="table_list">640 x 480 px (MPEG4 encoder)</li>
+    <li class="table_list">720 x 480 px (other)</li></ul>
+    </td>
+    <td><ul>
+    <li class="table_list">1408 x 1152 px (H263)</li>
+    <li class="table_list">1280 x 720 px (other)</li></ul>
+    </td>
+    <td>1920 x 1080 px (other than MPEG4)</td>
+    <td>3840 x 2160 px (HEVC, VP9)</td>
+  </tr>
+</table>
+
+*  [C-2-2] Video codecs that are characterized as hardware accelerated MUST
+publish performance points information. They MUST each list all supported
+standard performance points (listed in [`PerformancePoint`](
+https://developer.android.com/reference/android/media/MediaCodecInfo.VideoCapabilities)
+API), unless they are covered by another supported standard performance point.
+*  Additionally they SHOULD publish extended performance points if they
+support sustained video performance other than one of the standard ones listed.
diff --git a/5_multimedia/5_2_video-encoding.md b/5_multimedia/5_2_video-encoding.md
index 3bc9d79..ba96566 100644
--- a/5_multimedia/5_2_video-encoding.md
+++ b/5_multimedia/5_2_video-encoding.md
@@ -3,9 +3,9 @@
 If device implementations support any video encoder and make it available
 to third-party apps, they:
 
-*   SHOULD NOT be, over two sliding windows, more than ~15% over the bitrate
+*   SHOULD NOT be, over two sliding windows, more than 15% over the bitrate
 between intraframe (I-frame) intervals.
-*   SHOULD NOT be more than ~100% over the bitrate over a sliding window
+*   SHOULD NOT be more than 100% over the bitrate over a sliding window
 of 1 second.
 
 If device implementations include an embedded screen display with the
@@ -31,6 +31,14 @@
 
 *   SHOULD support dynamically configurable bitrates for the supported encoder.
 
+If device implementations provide hardware accelerated video or image encoders,
+and support one or more attached or pluggable hardware camera(s) exposed through
+the `android.camera` APIs:
+
+*   [C-4-1] all hardware accelerated video and image encoders MUST support
+encoding frames from the hardware camera(s).
+*   SHOULD support encoding frames from the hardware camera(s) through all video
+or image encoders.
 
 ### 5.2.1\. H.263
 
@@ -41,15 +49,15 @@
 *   SHOULD support dynamically configurable bitrates for the supported encoder.
 
 
-### 5.2.2\. H-264
+### 5.2.2\. H.264
 
 If device implementations support H.264 codec, they:
 
 *   [C-1-1] MUST support Baseline Profile Level 3.
-    However, support for ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock
-    Ordering) and RS (Redundant Slices) is OPTIONAL. Moreover, to maintain
-    compatibility with other Android devices, it is RECOMMENDED that ASO, FMO
-    and RS are not used for Baseline Profile by encoders.
+    However, support for ASO (Arbitrary Slice Ordering), FMO (Flexible
+    Macroblock Ordering) and RS (Redundant Slices) is OPTIONAL. Moreover, to
+    maintain compatibility with other Android devices, it is RECOMMENDED that
+    ASO, FMO and RS are not used for Baseline Profile by encoders.
 *   [C-1-2] MUST support the SD (Standard Definition) video encoding profiles
 in the following table.
 *   SHOULD support Main Profile Level 4.
@@ -93,15 +101,14 @@
  </tr>
 </table>
 
-
 ### 5.2.3\. VP8
 
 If device implementations support VP8 codec, they:
 
 *   [C-1-1] MUST support the SD video encoding profiles.
 *   SHOULD support the following HD (High Definition) video encoding profiles.
-*   SHOULD support writing Matroska WebM files.
-*   SHOULD use a hardware VP8 codec that meets the
+*   [C-1-2] MUST support writing Matroska WebM files.
+*   SHOULD provide a hardware VP8 codec that meets the
 [WebM project RTC hardware coding requirements](
 http://www.webmproject.org/hardware/rtc-coding-requirements), to ensure
 acceptable quality of web video streaming and video-conference services.
@@ -142,10 +149,92 @@
  </tr>
 </table>
 
-
 ### 5.2.4\. VP9
 
 If device implementations support VP9 codec, they:
 
-*   SHOULD support writing Matroska WebM files.
+*   [C-1-2] MUST support Profile 0 Level 3.
+*   [C-1-1] MUST support writing Matroska WebM files.
+*   [C-1-3] MUST generate [CodecPrivate](
+https://www.webmproject.org/docs/container/#vp9-codec-feature-metadata-codecprivate
+) data.
+*   SHOULD support the HD decoding profiles as indicated in the following table.
+*   [SR] are STRONGLY RECOMMENDED to support the HD decoding profiles as
+indicated in the following table if there is a hardware encoder.
 
+<table>
+ <tr>
+    <th></th>
+    <th>SD</th>
+    <th>HD 720p</th>
+    <th>HD 1080p</th>
+    <th>UHD</th>
+ </tr>
+ <tr>
+    <th>Video resolution</th>
+    <td>720 x 480 px</td>
+    <td>1280 x 720 px</td>
+    <td>1920 x 1080 px</td>
+    <td>3840 x 2160 px</td>
+ </tr>
+ <tr>
+    <th>Video frame rate</th>
+    <td>30 fps</td>
+    <td>30 fps</td>
+    <td>30 fps</td>
+    <td>30 fps</td>
+ </tr>
+ <tr>
+    <th>Video bitrate</th>
+    <td>1.6 Mbps</td>
+    <td>4 Mbps</td>
+    <td>5 Mbps</td>
+    <td>20 Mbps</td>
+ </tr>
+</table>
+
+
+If device implementations claim to support Profile 2 or Profile 3 through the
+Media APIs:
+
+*   Support for 12-bit format is OPTIONAL.
+
+### 5.2.5\. H.265
+
+If device implementations support H.265 codec, they:
+
+*   [C-1-1] MUST support Main Profile Level 3.
+*   SHOULD support the HD encoding profiles as indicated in the following table.
+*   [SR] are STRONGLY RECOMMENDED to support the HD encoding profiles as
+indicated in the following table if there is a hardware encoder.
+
+<table>
+ <tr>
+    <th></th>
+    <th>SD</th>
+    <th>HD 720p</th>
+    <th>HD 1080p</th>
+    <th>UHD</th>
+ </tr>
+ <tr>
+    <th>Video resolution</th>
+    <td>720 x 480 px</td>
+    <td>1280 x 720 px</td>
+    <td>1920 x 1080 px</td>
+    <td>3840 x 2160 px</td>
+ </tr>
+ <tr>
+    <th>Video frame rate</th>
+    <td>30 fps</td>
+    <td>30 fps</td>
+    <td>30 fps</td>
+    <td>30 fps</td>
+ </tr>
+ <tr>
+    <th>Video bitrate</th>
+    <td>1.6 Mbps</td>
+    <td>4 Mbps</td>
+    <td>5 Mbps</td>
+    <td>20 Mbps</td>
+ </tr>
+</table>
diff --git a/5_multimedia/5_3_video-decoding.md b/5_multimedia/5_3_video-decoding.md
index 30adfe2..445a391 100644
--- a/5_multimedia/5_3_video-decoding.md
+++ b/5_multimedia/5_3_video-decoding.md
@@ -7,16 +7,6 @@
 H.264, and H.265 codecs in real time and up to the maximum resolution supported
 by each codec on the device.
 
-If device implementations declare support for the Dolby Vision decoder through
-[`HDR_TYPE_DOLBY_VISION`](https://developer.android.com/reference/android/view/Display.HdrCapabilities.html#HDR_TYPE_DOLBY_VISION)
-, they:
-
-*   [C-2-1] MUST provide a Dolby Vision-capable extractor.
-*   [C-2-2] MUST properly display Dolby Vision content on the device screen or
-on a standard video output port (e.g., HDMI).
-*   [C-2-3] MUST set the track index of backward-compatible base-layer(s) (if
-present) to be the same as the combined Dolby Vision layer's track index.
-
 ### 5.3.1\. MPEG-2
 
 If device implementations support MPEG-2 decoders, they:
@@ -140,6 +130,14 @@
  </tr>
 </table>
 
+If device implementations claim to support an HDR Profile through the Media
+APIs:
+
+*   [C-3-1] Device implementations MUST accept the required HDR metadata from
+the application, as well as support extracting and outputting the required HDR
+metadata from the bitstream and/or container.
+*   [C-3-2] Device implementations MUST properly display HDR content on the
+device screen or on a standard video output port (e.g., HDMI).
 
 ### 5.3.6\. VP8
 
@@ -245,3 +243,46 @@
     <td>20 Mbps</td>
  </tr>
 </table>
+
+If device implementations claim to support `VP9Profile2` or `VP9Profile3`
+through the ['CodecProfileLevel'](
+https://developer.android.com/reference/android/media/MediaCodecInfo.CodecProfileLevel)
+media APIs:
+
+*   Support for 12-bit format is OPTIONAL.
+
+If device implementations claim to support an HDR Profile (`VP9Profile2HDR`,
+`VP9Profile2HDR10Plus`, `VP9Profile3HDR`, `VP9Profile3HDR10Plus`) through the
+media APIs:
+
+*   [C-4-1] Device implementations MUST accept the required HDR metadata
+([`KEY_HDR_STATIC_INFO`](
+https://developer.android.com/reference/android/media/MediaFormat.html#KEY_HDR_STATIC_INFO)
+for all HDR profiles, as well as
+['KEY_HDR10_PLUS_INFO'](
+https://developer.android.com/reference/android/media/MediaFormat.html#KEY_HDR10_PLUS_INFO)
+for HDR10Plus profiles)
+from the application. They also MUST support extracting and outputting the
+required HDR metadata from the bitstream and/or container.
+*   [C-4-2] Device implementations MUST properly display HDR content on the
+device screen or on a standard video output port (e.g., HDMI).
+
+
+## 5.3.8\.  Dolby Vision
+
+If device implementations declare support for the Dolby Vision decoder through
+[`HDR_TYPE_DOLBY_VISION`](
+https://developer.android.com/reference/android/view/Display.HdrCapabilities.html#HDR_TYPE_DOLBY_VISION)
+, they:
+
+*   [C-1-1] MUST provide a Dolby Vision-capable extractor.
+*   [C-1-2] MUST properly display Dolby Vision content on the device screen or
+on a standard video output port (e.g., HDMI).
+*   [C-1-3] MUST set the track index of backward-compatible base-layer(s) (if
+present) to be the same as the combined Dolby Vision layer's track index.
+
+### 5.3.9\. AV1
+
+If device implementations support AV1 codec, they:
+
+*   [C-1-1] MUST support Profile 0 including 10-bit content.
diff --git a/5_multimedia/5_4_audio-recording.md b/5_multimedia/5_4_audio-recording.md
index 51a13e5..7241d65 100644
--- a/5_multimedia/5_4_audio-recording.md
+++ b/5_multimedia/5_4_audio-recording.md
@@ -7,7 +7,7 @@
 will not be able to attain Android compatibility when upgraded to the future
 version.
 
-### 5.4.1\. Raw Audio Capture
+### 5.4.1\. Raw Audio Capture and Microphone Information
 
 If device implementations declare `android.hardware.microphone`, they:
 
@@ -35,7 +35,17 @@
      *   **Format**: Linear PCM, 16-bit
      *   **Sampling rates**: 22050, 48000 Hz
      *   **Channels**: Stereo
-
+*   [C-1-4] MUST honor the [`MicrophoneInfo`](
+    https://developer.android.com/reference/android/media/MicrophoneInfo) API
+    and properly fill in information for the available microphones on device
+    accessible to the third party applications via the
+    [`AudioManager.getMicrophones()`](
+    https://developer.android.com/reference/android/media/AudioManager#getMicrophones%28%29)
+    API, and the currently active microphones which are accessible to the third
+    party applications via the [`AudioRecord.getActiveMicrophones()`](
+    https://developer.android.com/reference/android/media/AudioRecord#getActiveMicrophones%28%29)
+    and [`MediaRecorder.getActiveMicrophones()`](https://developer.android.com/reference/android/media/MediaRecorder#getActiveMicrophones%28%29)
+    APIs.
 If device implementations allow AM radio and DVD quality capture of raw audio
 content, they:
 
@@ -69,12 +79,12 @@
     distortion (THD) less than 1% for 1 kHz at 90 dB SPL input level at the
     microphone.
 
-If device impelementations declare `android.hardware.microphone` and noise
+If device implementations declare `android.hardware.microphone` and noise
 suppression (reduction) technologies tuned for speech recognition, they:
 
 *   [C-2-1] MUST allow this audio affect to be controllable with the
     `android.media.audiofx.NoiseSuppressor` API.
-*   [C-2-2] MUST uniquely identfiy each noise suppression technology
+*   [C-2-2] MUST uniquely identify each noise suppression technology
     implementation via the `AudioEffect.Descriptor.uuid` field.
 
 ### 5.4.3\. Capture for Rerouting of Playback
@@ -93,3 +103,68 @@
     * `AudioManager.STREAM_ALARM`
     * `AudioManager.STREAM_NOTIFICATION`
 
+### 5.4.4\. Acoustic Echo Canceler
+
+If device implementations declare `android.hardware.microphone`, they:
+
+*   SHOULD implement an [Acoustic Echo Canceler](https://en.wikipedia.org/wiki/Echo_suppression_and_cancellation)
+(AEC) technology tuned for voice communication and applied to the capture path
+when capturing using `AudioSource.VOICE_COMMUNICATION`
+
+If device implementations provides an Acoustic Echo Canceler which is
+inserted in the capture audio path when `AudioSource.VOICE_COMMUNICATION`
+is selected, they:
+
+*   [C-SR] are STRONGLY_RECOMMENDED to declare this via [AcousticEchoCanceler](https://developer.android.com/reference/android/media/audiofx/AcousticEchoCanceler)
+API method [AcousticEchoCanceler.isAvailable()](https://developer.android.com/reference/android/media/audiofx/AcousticEchoCanceler.html#isAvailable())
+*   [C-SR] are STRONGLY_RECOMMENDED to allow this audio effect to be
+controllable with the [AcousticEchoCanceler](https://developer.android.com/reference/android/media/audiofx/AcousticEchoCanceler)
+API.
+*   [C-SR] are STRONGLY_RECOMMENDED to uniquely identify each AEC technology
+implementation via the [AudioEffect.Descriptor.uuid](https://developer.android.com/reference/android/media/audiofx/AudioEffect.Descriptor.html#uuid)
+field.
+
+### 5.4.5\. Concurrent Capture
+
+If device implementations declare `android.hardware.microphone`,they MUST
+implement concurrent capture as described in [this document](
+https://developer.android.com/features/sharing-audio-input). Specifically:
+
+*   [C-1-1] MUST allow concurrent access to microphone by an accessibility
+    service capturing with `AudioSource.VOICE_RECOGNITION` and at least one
+    application capturing with any `AudioSource`.
+*   [C-1-2] MUST allow concurrent access to microphone by a pre-installed
+    application that holds an Assistant role and at least one application
+    capturing with any `AudioSource` except for
+    `AudioSource.VOICE_COMMUNICATION` or `AudioSource.CAMCORDER`.
+*   [C-1-3] MUST silence the audio capture for any other application, except for
+    an accessibility service, while an application is capturing with
+    `AudioSource.VOICE_COMMUNICATION` or `AudioSource.CAMCORDER`. However, when
+    an app is capturing via `AudioSource.VOICE_COMMUNICATION` then another app
+    can capture the voice call if it is a privileged (pre-installed) app with
+    permission `CAPTURE_AUDIO_OUTPUT`.
+*   [C-1-4] If two or more applications are capturing concurrently and if
+    neither app has an UI on top, the one that started capture the most recently
+    receives audio.
+
+### 5.4.6\. Microphone Gain Levels
+
+If device implementations declare `android.hardware.microphone`, they:
+
+*   SHOULD exhibit approximately flat amplitude-versus-frequency
+    characteristics in the mid-frequency range: specifically ±3dB from 100
+    Hz to 4000 Hz for each and every microphone used to record the voice
+    recognition audio source.
+*   SHOULD set audio input sensitivity such that a 1000 Hz sinusoidal
+    tone source played at 90 dB Sound Pressure Level (SPL) yields a response
+    with RMS of 2500 for 16 bit-samples (or -22.35 dB Full Scale for floating
+    point/double precision samples) for each and every microphone used to
+    record the voice recognition audio source.
+*   [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the low
+    frequency range: specifically from ±20 dB from 5 Hz to 100 Hz compared
+    to the mid-frequency range for each and every microphone used to record
+    the voice recognition audio source.
+*   [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the
+    high frequency range: specifically from ±30 dB from 4000 Hz to 22 KHz
+    compared to the mid-frequency range for each and every microphone used
+    to record the voice recognition audio source.
diff --git a/5_multimedia/5_5_audio-playback.md b/5_multimedia/5_5_audio-playback.md
index 4411726..3d76160 100644
--- a/5_multimedia/5_5_audio-playback.md
+++ b/5_multimedia/5_5_audio-playback.md
@@ -34,7 +34,7 @@
 
 *   [C-1-1] MUST support the `EFFECT_TYPE_EQUALIZER` and
 `EFFECT_TYPE_LOUDNESS_ENHANCER` implementations controllable through the
-AudioEffect subclasses `Equalizer`, `LoudnessEnhancer`.
+AudioEffect subclasses `Equalizer` and `LoudnessEnhancer`.
 *   [C-1-2] MUST support the visualizer API implementation, controllable through
 the `Visualizer` class.
 *   [C-1-3] MUST support the `EFFECT_TYPE_DYNAMICS_PROCESSING` implementation
@@ -43,6 +43,8 @@
 `EFFECT_TYPE_PRESET_REVERB`, and `EFFECT_TYPE_VIRTUALIZER` implementations
 controllable through the `AudioEffect` sub-classes `BassBoost`,
 `EnvironmentalReverb`, `PresetReverb`, and `Virtualizer`.
+*  [C-SR] Are STRONGLY RECOMMENDED to support effects in floating-point and
+multichannel.
 
 ### 5.5.3\. Audio Output Volume
 
diff --git a/5_multimedia/5_6_audio-latency.md b/5_multimedia/5_6_audio-latency.md
index a1aefab..bc14b83 100644
--- a/5_multimedia/5_6_audio-latency.md
+++ b/5_multimedia/5_6_audio-latency.md
@@ -42,13 +42,28 @@
 stream and the estimated time when that frame enters or leaves the
 audio processing pipeline on the associated endpoint.  See also
 [AudioTimestamp](https://developer.android.com/reference/android/media/AudioTimestamp).
+*   **glitch**. A temporary interruption or incorrect sample value in the audio signal,
+typically caused by a
+[buffer underrun](https://en.wikipedia.org/wiki/Buffer_underrun) for output,
+buffer overrun for input, or any other source of digital or analog noise.
+
+If device implementations declare `android.hardware.audio.output`, they
+MUST meet or exceed the following requirements:
+
+*   [C-1-1] The output timestamp returned by
+[AudioTrack.getTimestamp](https://developer.android.com/reference/android/media/AudioTrack.html#getTimestamp(android.media.AudioTimestamp))
+and `AAudioStream_getTimestamp` is accurate to +/- 2 ms.
+*   [C-1-2] Cold output latency of 500 milliseconds or less.
 
 If device implementations declare `android.hardware.audio.output` they are
 STRONGLY RECOMMENDED to meet or exceed the following requirements:
 
-*   [C-SR] Cold output latency of 100 milliseconds or less
-*   [C-SR] Continuous output latency of 45 milliseconds or less
-*   [C-SR] Minimize the cold output jitter
+*   [C-SR] Cold output latency of 100 milliseconds or less. Existing and new
+    devices that run this version of Android are VERY STRONGLY RECOMMENDED
+    to meet these requirements now. In a future platform release in 2021, we
+    will require Cold output latency of 200 ms or less as a MUST.
+*   [C-SR] Continuous output latency of 45 milliseconds or less.
+*   [C-SR] Minimize the cold output jitter.
 *   [C-SR] The output timestamp returned by
 [AudioTrack.getTimestamp](https://developer.android.com/reference/android/media/AudioTrack.html#getTimestamp(android.media.AudioTimestamp))
 and `AAudioStream_getTimestamp` is accurate to +/- 1 ms.
@@ -72,12 +87,24 @@
 If device implementations do not meet the requirements for low-latency audio
 via both the OpenSL ES PCM buffer queue and AAudio native audio APIs, they:
 
-*   [C-1-1] MUST NOT report support for low-latency audio.
+*   [C-2-1] MUST NOT report support for low-latency audio.
+
+If device implementations include `android.hardware.microphone`, they
+MUST meet these input audio requirements:
+
+*   [C-3-1] Limit the error in input timestamps, as returned by
+[AudioRecord.getTimestamp](https://developer.android.com/reference/android/media/AudioRecord.html#getTimestamp(android.media.AudioTimestamp,%20int))
+or `AAudioStream_getTimestamp`, to +/- 2 ms.
+"Error" here means the deviation from the correct value.
+*   [C-3-2] Cold input latency of 500 milliseconds or less.
 
 If device implementations include `android.hardware.microphone`, they are
 STRONGLY RECOMMENDED to meet these input audio requirements:
 
-   *   [C-SR] Cold input latency of 100 milliseconds or less.
+   *   [C-SR] Cold input latency of 100 milliseconds or less. Existing and new
+       devices that run this version of Android are VERY STRONGLY RECOMMENDED
+       to meet these requirements now. In a future platform release in 2021 we
+       will require Cold input latency of 200 ms or less as a MUST.
    *   [C-SR] Continuous input latency of 30 milliseconds or less.
    *   [C-SR] Continuous round-trip latency of 50 milliseconds or less.
    *   [C-SR] Minimize the cold input jitter.
diff --git a/5_multimedia/5_7_network-protocols.md b/5_multimedia/5_7_network-protocols.md
index 191c286..2e9e607 100644
--- a/5_multimedia/5_7_network-protocols.md
+++ b/5_multimedia/5_7_network-protocols.md
@@ -10,7 +10,7 @@
 [section 5.1](#5_1_media_codecs) over HTTP(S).
 
 *    [C-1-2] MUST support the media segment formats shown in
-the Media Segmant Formats table below over
+the Media Segment Formats table below over
 [HTTP Live Streaming draft protocol, Version 7](
 http://tools.ietf.org/html/draft-pantos-http-live-streaming-07).
 
diff --git a/5_multimedia/5_8_secure-media.md b/5_multimedia/5_8_secure-media.md
index 7722d80..9a42ebd 100644
--- a/5_multimedia/5_8_secure-media.md
+++ b/5_multimedia/5_8_secure-media.md
@@ -17,4 +17,3 @@
 
 *    [C-3-1] MUST support HDCP 1.2 or higher for all external displays connected
 via a user-accessible wired port.
-
diff --git a/5_multimedia/5_9_midi.md b/5_multimedia/5_9_midi.md
index 205d074..ec13b0a 100644
--- a/5_multimedia/5_9_midi.md
+++ b/5_multimedia/5_9_midi.md
@@ -14,3 +14,5 @@
 
 *    [C-1-2] MUST support the inter-app MIDI software transport
 (virtual MIDI devices)
+
+*    [C-1-3] MUST include libamidi.so (native MIDI support)
diff --git a/6_dev-tools-and-options/6_0_intro.md b/6_dev-tools-and-options/6_0_intro.md
index 0c155b6..c8010fb 100644
--- a/6_dev-tools-and-options/6_0_intro.md
+++ b/6_dev-tools-and-options/6_0_intro.md
@@ -1,2 +1 @@
 # 6\. Developer Tools and Options Compatibility
-
diff --git a/6_dev-tools-and-options/6_1_developer_tools.md b/6_dev-tools-and-options/6_1_developer_tools.md
index 9b028e8..0cabcb9 100644
--- a/6_dev-tools-and-options/6_1_developer_tools.md
+++ b/6_dev-tools-and-options/6_1_developer_tools.md
@@ -8,11 +8,13 @@
     *   [C-0-2] MUST support adb as documented in the Android SDK and the shell
         commands provided in the AOSP, which can be used by app developers,
         including [`dumpsys`](https://source.android.com/devices/input/diagnostics.html)
-        and `cmd stats`.
+        `cmd stats`
+    *   [C-SR] Are STRONGLY RECOMENDED to support the shell command
+    `cmd testharness`.
     *   [C-0-3] MUST NOT alter the format or the contents of device system
         events (batterystats , diskstats, fingerprint, graphicsstats, netstats,
         notification, procstats) logged via the dumpsys command.
-    *   [C-0-10] MUST record, without ommmission, and make the following events
+    *   [C-0-10] MUST record, without omission, and make the following events
         accessible and available to the `cmd stats` shell command and the
         `StatsManager` System API class.
         *   ActivityForegroundStateChanged
@@ -65,6 +67,32 @@
     *   [C-0-9] MUST support the systrace tool as documented in the Android SDK.
     Systrace must be inactive by default and there MUST be a user-accessible
     mechanism to turn on Systrace.
+*    [**Perfetto**](https://developer.android.com/studio/command-line/perfetto)
+    *   [C-SR] Are STRONGLY RECOMMENDED to expose a `/system/bin/perfetto`
+        binary to the shell user which cmdline complies with
+        [the perfetto documentation](
+        https://developer.android.com/studio/command-line/perfetto).
+    *   [C-SR] The perfetto binary is STRONGLY RECOMMENDED to accept as input a
+        protobuf config that complies with the schema defined in
+        [the perfetto documentation](
+        https://developer.android.com/studio/command-line/perfetto).
+    *   [C-SR] The perfetto binary is STRONGLY RECOMMENDED to write as output a
+        protobuf trace that complies with the schema defined in
+        [the perfetto documentation](
+        https://developer.android.com/studio/command-line/perfetto).
+    *   [C-SR] Are STRONGLY RECOMMENDED to provide, through the perfetto binary,
+        at least the data sources described  in [the perfetto documentation](
+        https://developer.android.com/studio/command-line/perfetto).
+
+*    [**Test Harness Mode**](https://source.android.com/compatibility/cts/harness)
+
+    If device implementations support the shell command `cmd testharness` and
+    run `cmd testharness enable`, they:
+
+    *   [C-2-1] MUST return `true` for
+        `ActivityManager.isRunningInUserTestHarness()`
+    *   [C-2-2] MUST implement Test Harness Mode as described in [harness mode documentation](
+        https://source.android.com/compatibility/cts/harness).
 
 If device implementations report the support of Vulkan 1.0 or higher via the
 `android.hardware.vulkan.version` feature flags, they:
diff --git a/6_dev-tools-and-options/6_2_developer_options.md b/6_dev-tools-and-options/6_2_developer_options.md
index 974ad6f..6c309b2 100644
--- a/6_dev-tools-and-options/6_2_developer_options.md
+++ b/6_dev-tools-and-options/6_2_developer_options.md
@@ -22,4 +22,4 @@
 Options is enabled and the safety of the user is of concern.
 *   MAY temporarily limit access to the Developer Options menu, by visually
 hiding or disabling the menu, to prevent distraction for scenarios where the
-safety of the user is of concern.
\ No newline at end of file
+safety of the user is of concern.
diff --git a/7_hardware-compatibility/7_0_intro.md b/7_hardware-compatibility/7_0_intro.md
index e4fd642..41732f3 100644
--- a/7_hardware-compatibility/7_0_intro.md
+++ b/7_hardware-compatibility/7_0_intro.md
@@ -29,4 +29,4 @@
 
 A typical example of a scenario where these requirements apply is the telephony
 API: Even on non-phone devices, these APIs must be implemented as reasonable
-no-ops.
\ No newline at end of file
+no-ops.
diff --git a/7_hardware-compatibility/7_1_display-and-graphics.md b/7_hardware-compatibility/7_1_display-and-graphics.md
index 9211ba4..c470f95 100644
--- a/7_hardware-compatibility/7_1_display-and-graphics.md
+++ b/7_hardware-compatibility/7_1_display-and-graphics.md
@@ -2,9 +2,11 @@
 
 Android includes facilities that automatically adjust application assets and UI
 layouts appropriately for the device to ensure that third-party applications
-run well on a [variety of hardware configurations](http://developer.android.com/guide/practices/screens_support.html).
-Devices MUST properly implement these APIs and behaviors, as detailed in this
-section.
+run well on a [variety of hardware configurations](
+http://developer.android.com/guide/practices/screens_support.html).
+On the Android-compatible display(s) where all third-party Android-compatible
+applications can run, device implementations MUST properly implement these APIs
+and behaviors, as detailed in this section.
 
 The units referenced by the requirements in this section are defined as follows:
 
@@ -51,10 +53,10 @@
  attribute in the AndroidManifest.xml, as described
  in the Android SDK documentation.
 
-*    MAY have a display with rounded corners.
+*    MAY have the Android-compatible display(s) with rounded corners.
 
-If device implementations support `UI_MODE_TYPE_NORMAL` and include a display
-with rounded corners, they:
+If device implementations support `UI_MODE_TYPE_NORMAL` and include the
+Android-compatible display(s) with rounded corners, they:
 
 *    [C-1-1] MUST ensure that the radius of the rounded corners is less than or
 equal to 38 dp.
@@ -63,34 +65,45 @@
 
 #### 7.1.1.2\. Screen Aspect Ratio
 
-While there is no restriction to the screen aspect ratio value of the physical
-screen display, the screen aspect ratio of the logical display that third-party
-apps are rendered within, as can be derived from the height and width values
-reported through the [`view.Display`](
+While there is no restriction to the aspect ratio of the physical display for
+the Android-compatible display(s), the aspect ratio of the logical display
+where third-party apps are rendered, which can be derived from the height and
+width values reported through the [`view.Display`](
 https://developer.android.com/reference/android/view/Display.html)
 APIs and [Configuration](
 https://developer.android.com/reference/android/content/res/Configuration.html)
-API, MUST meet the following requirements:
+APIs, MUST meet the following requirements:
 
-*   [C-0-1] Device implementations with the `Configuration.uiMode` set as
-    `UI_MODE_TYPE_NORMAL` MUST have an aspect ratio value between 1.3333 (4:3)
-    and 1.86 (roughly 16:9), unless the app can be deemed as ready to be
-    stretched longer by meeting one of the following conditions:
+*   [C-0-1] Device implementations with `Configuration.uiMode` set to
+    `UI_MODE_TYPE_NORMAL` MUST have an aspect ratio value less than or equal
+    to 1.86 (roughly 16:9), unless the app meets one of the following
+    conditions:
 
      *  The app has declared that it supports a larger screen aspect ratio
      through  the [`android.max_aspect`](
-     https://developer.android.com/guide/practices/screens&lowbar;support.html#MaxAspectRatio)
+     https://developer.android.com/guide/practices/screens-distribution)
      metadata value.
      *  The app declares it is resizeable via the [android:resizeableActivity](
      https://developer.android.com/guide/topics/ui/multi-window.html#configuring)
      attribute.
-     *  The app is targeting API level 24 or higher and does not declare a
-     [`android:MaxAspectRatio`](
+     *  The app targets API level 24 or higher and does not declare an
+     [`android:maxAspectRatio`](
      https://developer.android.com/reference/android/R.attr.html#maxAspectRatio)
      that would restrict the allowed aspect ratio.
 
+*   [C-0-2] Device implementations with `Configuration.uiMode` set to
+    `UI_MODE_TYPE_NORMAL` MUST have an aspect ratio value equal to or greater
+    than 1.3333 (4:3), unless the app can be stretched wider by meeting one of
+    the following conditions:
 
-*   [C-0-2] Device implementations with the `Configuration.uiMode` set as
+     *  The app declares it is resizeable via the [android:resizeableActivity](
+     https://developer.android.com/guide/topics/ui/multi-window.html#configuring)
+     attribute.
+     *  The app declares an [`android:minAspectRatio`](
+     https://developer.android.com/reference/android/R.attr.html#minAspectRatio)
+     that would restrict the allowed aspect ratio.
+
+*   [C-0-3] Device implementations with the `Configuration.uiMode` set as
     `UI_MODE_TYPE_WATCH` MUST have an aspect ratio value set as 1.0 (1:1).
 
 #### 7.1.1.3\. Screen Density
@@ -107,8 +120,12 @@
 made by the user (for example, display size) set after initial boot.
 
     *   120 dpi (ldpi)
+    *   140 dpi (140dpi)
     *   160 dpi (mdpi)
+    *   180 dpi (180dpi)
+    *   200 dpi (200dpi)
     *   213 dpi (tvdpi)
+    *   220 dpi (220dpi)
     *   240 dpi (hdpi)
     *   260 dpi (260dpi)
     *   280 dpi (280dpi)
@@ -148,22 +165,23 @@
 
 ### 7.1.2\. Display Metrics
 
-If device implementations include a screen or video output, they:
+If device implementations include the Android-compatible display(s) or
+video output to the Android-compatible display screen(s), they:
 
-*    [C-1-1] MUST report correct values for all display metrics defined in the
+*    [C-1-1] MUST report correct values for all Android-compatible display
+metrics defined in the
  [`android.util.DisplayMetrics`](
  https://developer.android.com/reference/android/util/DisplayMetrics.html) API.
 
 If device implementations does not include an embedded screen or video output,
 they:
 
-*    [C-2-1] MUST report reasonable values for all display metrics defined in
- the [`android.util.DisplayMetrics`](
+*    [C-2-1] MUST report correct values of the Android-compatible display
+ as defined in the [`android.util.DisplayMetrics`](
  https://developer.android.com/reference/android/util/DisplayMetrics.html) API
  for the emulated default `view.Display`.
 
 
-
 ### 7.1.3\. Screen Orientation
 
 Device implementations:
@@ -216,8 +234,8 @@
 *   [C-2-2] MUST support the `EGL_KHR_image`, `EGL_KHR_image_base`,
     `EGL_ANDROID_image_native_buffer`, `EGL_ANDROID_get_native_client_buffer`,
     `EGL_KHR_wait_sync`, `EGL_KHR_get_all_proc_addresses`,
-    `EGL_ANDROID_presentation_time`, `EGL_KHR_swap_buffers_with_damage` and
-    `EGL_ANDROID_recordable` extensions.
+    `EGL_ANDROID_presentation_time`, `EGL_KHR_swap_buffers_with_damage`,
+    `EGL_ANDROID_recordable`, and `EGL_ANDROID_GLES_layers` extensions.
 *   [C-SR] Are STRONGLY RECOMMENDED to support the `EGL_KHR_partial_update` and
     `OES_EGL_image_external` extensions.
 *   SHOULD accurately report via the `getString()` method, any texture
@@ -266,7 +284,7 @@
 *   [C-1-1] MUST report the correct integer value with the
     `android.hardware.vulkan.level` and `android.hardware.vulkan.version`
     feature flags.
-*   [C-1-2] MUST enumarate, at least one `VkPhysicalDevice` for the Vulkan
+*   [C-1-2] MUST enumerate, at least one `VkPhysicalDevice` for the Vulkan
     native API [`vkEnumeratePhysicalDevices()`](
     https://www.khronos.org/registry/vulkan/specs/1.0/man/html/vkEnumeratePhysicalDevices.html)
     .
@@ -288,12 +306,14 @@
     that they do not correctly support.
 *   [C-1-7] MUST support the VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain,
     and VK_KHR_incremental_present extensions.
+*   [C-SR] Are STRONGLY RECOMMENDED to support the VK_KHR_driver_properties and
+    VK_GOOGLE_display_timing extensions.
 
 If device implementations do not include support for Vulkan 1.0, they:
 
 *   [C-2-1] MUST NOT declare any of the Vulkan feature flags (e.g.
     `android.hardware.vulkan.level`, `android.hardware.vulkan.version`).
-*   [C-2-2] MUST NOT enumarate any `VkPhysicalDevice` for the Vulkan native API
+*   [C-2-2] MUST NOT enumerate any `VkPhysicalDevice` for the Vulkan native API
     `vkEnumeratePhysicalDevices()`.
 
 If device implementations include support for Vulkan 1.1 and declare any of the
@@ -371,22 +391,22 @@
 ### 7.1.6\. Screen Technology
 
 The Android platform includes APIs that allow applications to render rich
-graphics to the display. Devices MUST support all of these APIs as defined by
-the Android SDK unless specifically allowed in this document.
+graphics to an Android-compatible display. Devices MUST support all of these
+APIs as defined by the Android SDK unless specifically allowed in this document.
 
-Device implementations:
+All of a device implementation's Android-compatible displays:
 
-*   [C-0-1] MUST support displays capable of rendering 16-bit color graphics.
+*   [C-0-1] MUST be capable of rendering 16-bit color graphics.
 *   SHOULD support displays capable of 24-bit color graphics.
-*   [C-0-2] MUST support displays capable of rendering animations.
-*   [C-0-3] MUST use the display technology that have a pixel aspect ratio (PAR)
+*   [C-0-2] MUST be capable of rendering animations.
+*   [C-0-3] MUST have a pixel aspect ratio (PAR)
     between 0.9 and 1.15\. That is, the pixel aspect ratio MUST be near square
     (1.0) with a 10 ~ 15% tolerance.
 
 ### 7.1.7\. Secondary Displays
 
-Android includes support for secondary display to enable media sharing
-capabilities and developer APIs for accessing external displays.
+Android includes support for secondary Android-compatible displays to enable
+media sharing capabilities and developer APIs for accessing external displays.
 
 If device implementations support an external display either via a wired,
 wireless, or an embedded additional display connection, they:
diff --git a/7_hardware-compatibility/7_2_input-devices.md b/7_hardware-compatibility/7_2_input-devices.md
index 05d53fc..8534275 100644
--- a/7_hardware-compatibility/7_2_input-devices.md
+++ b/7_hardware-compatibility/7_2_input-devices.md
@@ -93,6 +93,7 @@
 
 If device implementations provide the [Assist function](http://developer.android.com/reference/android/view/KeyEvent.html#`KEYCODE_ASSIST`),
 they:
+
 *    [C-4-1] MUST make the Assist function accessible with a single action
 (e.g. tap, double-click or gesture) when other navigation keys are accessible.
 *    [SR] STRONGLY RECOMMENDED to use long press on HOME function as this
@@ -111,6 +112,64 @@
     (a.k.a. the navigation bar) is properly hidden away as documented in
     the SDK.
 
+If the navigation function is provided as an on-screen, gesture-based action:
+
+*   [C-6-1]
+    [`WindowInsets#getMandatorySystemGestureInsets()`](https://developer.android.com/reference/android/view/WindowInsets.html#getMandatorySystemGestureInsets())
+    MUST only be used to report the Home gesture recognition area.
+*   [C-6-2] Gestures that start within an exclusion rect as provided by the
+    foreground application via
+    [`View#setSystemGestureExclusionRects()`](https://developer.android.com/reference/android/view/View.html#setSystemGestureExclusionRects(java.util.List%3Candroid.graphics.Rect%3E)),
+    but outside of
+    [`WindowInsets#getMandatorySystemGestureInsets()`](https://developer.android.com/reference/android/view/WindowInsets.html#getMandatorySystemGestureInsets()),
+    MUST NOT be intercepted for the navigation function as long as the exclusion
+    rect is allowed within the max exclusion limit as specified in the
+    documentation for
+    [`View#setSystemGestureExclusionRects()`](https://developer.android.com/reference/android/view/View.html#setSystemGestureExclusionRects(java.util.List%3Candroid.graphics.Rect%3E)).
+*   [C-6-3] MUST send the foreground app a
+    [`MotionEvent.ACTION_CANCEL`](https://developer.android.com/reference/android/view/MotionEvent.html#ACTION_CANCEL)
+    event once touches start being intercepted for a system gesture,
+    if the foreground app was previously sent an
+    [`MotionEvent.ACTION_DOWN`](https://developer.android.com/reference/android/view/MotionEvent.html#ACTION_DOWN)
+    event.
+*   [C-6-4] MUST provide a user affordance to switch to an on-screen,
+    button-based navigation (for example, in Settings).
+*   SHOULD provide Home function as a swipe up from the bottom edge of the
+    current orientation of the screen.
+*   SHOULD provide Recents function as a swipe up and hold before release, from
+    the same area as the Home gesture.
+*   Gestures that start within
+    [`WindowInsets#getMandatorySystemGestureInsets()`](https://developer.android.com/reference/android/view/WindowInsets.html#getMandatorySystemGestureInsets())
+    SHOULD NOT be affected by exclusion rects provided by the foreground
+    application via
+    [`View#setSystemGestureExclusionRects()`](https://developer.android.com/reference/android/view/View.html#setSystemGestureExclusionRects(java.util.List%3Candroid.graphics.Rect%3E)).
+
+If a navigation function is provided from anywhere on the left and right edges
+of the current orientation of the screen:
+
+*   [C-7-1] The navigation function MUST be Back and provided as a swipe from
+    both left and right edges of the current orientation of the screen.
+*   [C-7-2] If custom swipeable system panels are provided on the left or
+    right edges, they MUST be placed within the top 1/3rd of the screen with
+    a clear, persistent visual indication that dragging in would invoke the
+    aforementioned panels, and hence not Back. A system panel MAY be
+    configured by a user such that it lands below the top 1/3rd of the screen
+    edge(s) but the system panel MUST NOT use longer than 1/3rd of the edge(s).
+*   [C-7-3] When the foreground app has either the
+    [`View.SYSTEM_UI_FLAG_IMMERSIVE`](https://developer.android.com/reference/android/view/View.html#SYSTEM_UI_FLAG_IMMERSIVE)
+    or
+    [`View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY`](https://developer.android.com/reference/android/view/View.html#SYSTEM_UI_FLAG_IMMERSIVE_STICKY)
+    flags set, swiping from the edges MUST behave as implemented in AOSP,
+    which is documented in
+    [the SDK](https://developer.android.com/training/system-ui/immersive).
+*   [C-7-4] When the foreground app has either the
+    [`View.SYSTEM_UI_FLAG_IMMERSIVE`](https://developer.android.com/reference/android/view/View.html#SYSTEM_UI_FLAG_IMMERSIVE)
+    or
+    [`View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY`](https://developer.android.com/reference/android/view/View.html#SYSTEM_UI_FLAG_IMMERSIVE_STICKY)
+    flags set, custom swipeable system panels MUST be hidden until the
+    user brings in the system bars (a.k.a. navigation and status bar) as
+    implemented in AOSP.
+
 ### 7.2.4\. Touchscreen Input
 
 Android includes support for a variety of pointer input systems, such as
@@ -352,4 +411,3 @@
 ### 7.2.7\. Remote Control
 
 See [Section 2.3.1](#2_3_1_hardware) for device-specific requirements.
-
diff --git a/7_hardware-compatibility/7_3_sensors.md b/7_hardware-compatibility/7_3_sensors.md
index b8ac710..0409b6f 100644
--- a/7_hardware-compatibility/7_3_sensors.md
+++ b/7_hardware-compatibility/7_3_sensors.md
@@ -27,9 +27,9 @@
 using the relevant International System of Units (metric) values for each
 sensor type as defined in the Android SDK documentation.
 *   [C-1-2] MUST report sensor data with a maximum latency of 100
-milliseconds + 2 * sample_time for the case of a sensor streamed with a minimum
-required latency of 5 ms + 2 * sample_time when the application processor is
-active. This delay does not include any filtering delays.
+milliseconds + 2 * sample_time for the case of a sensor stream with a
+maximum requested latency of 0 ms when the application processor is active.
+This delay does not include any filtering delays.
 *   [C-1-3] MUST report the first sensor sample within 400 milliseconds + 2 *
 sample_time of the sensor being activated. It is acceptable for this sample to
 have an accuracy of 0.
@@ -81,7 +81,9 @@
 
 ### 7.3.1\. Accelerometer
 
-*   Device implementations SHOULD include a 3-axis accelerometer.
+Device implementations:
+
+*   [C-SR] Are STRONGLY RECOMMENDED to include a 3-axis accelerometer.
 
 If device implementations include a 3-axis accelerometer, they:
 
@@ -100,9 +102,11 @@
 collected over a period of at least 3 seconds at the fastest sampling rate.
 *   [SR] are **STRONGLY RECOMMENDED** to implement the `TYPE_SIGNIFICANT_MOTION`
     composite sensor.
-*   [SR] are STRONGLY RECOMMENDED to implement the
-    `TYPE_ACCELEROMETER_UNCALIBRATED` sensor if online accelerometer calibration
-    is available.
+*   [SR] are STRONGLY RECOMMENDED to implement and report [`TYPE_ACCELEROMETER_UNCALIBRATED`]
+(https://developer.android.com/reference/android/hardware/Sensor.html#STRING_TYPE_ACCELEROMETER_UNCALIBRATED)
+sensor. Android devices are STRONGLY RECOMMENDED to meet this requirement so
+they will be able to upgrade to the future platform release where this might
+become REQUIRED.
 *   SHOULD implement the `TYPE_SIGNIFICANT_MOTION`, `TYPE_TILT_DETECTOR`,
 `TYPE_STEP_DETECTOR`, `TYPE_STEP_COUNTER` composite sensors as described
 in the Android SDK document.
@@ -112,9 +116,6 @@
 the life cycle and compensated, and preserve the compensation parameters
 between device reboots.
 *   SHOULD be temperature compensated.
-*   SHOULD also implement [`TYPE_ACCELEROMETER_UNCALIBRATED`](
-https://developer.android.com/reference/android/hardware/Sensor.html#STRING_TYPE_ACCELEROMETER_UNCALIBRATED)
-    sensor.
 
 If device implementations include a 3-axis accelerometer and any of the
 `TYPE_SIGNIFICANT_MOTION`, `TYPE_TILT_DETECTOR`, `TYPE_STEP_DETECTOR`,
@@ -124,25 +125,27 @@
 *   SHOULD each be below 2 mW and 0.5 mW for when the device is in a dynamic or
     static condition.
 
-If device implementations include a 3-axis accelerometer and a gyroscope sensor,
+If device implementations include a 3-axis accelerometer and a 3-axis gyroscope sensor,
 they:
 
 *   [C-3-1] MUST implement the `TYPE_GRAVITY` and `TYPE_LINEAR_ACCELERATION`
 composite sensors.
-*   SHOULD implement the `TYPE_GAME_ROTATION_VECTOR` composite sensor.
-*   [SR] Existing and new Android devices are STRONGLY RECOMMENDED to
-implement the `TYPE_GAME_ROTATION_VECTOR` sensor.
+*   [C-SR] Are STRONGLY RECOMMENDED to implement the [`TYPE_GAME_ROTATION_VECTOR`](
+https://developer.android.com/reference/android/hardware/Sensor.html#TYPE_GAME_ROTATION_VECTOR)
+composite sensor.
 
-If device implementations include a 3-axis accelerometer, a gyroscope sensor
+If device implementations include a 3-axis accelerometer, a 3-axis gyroscope sensor,
 and a magnetometer sensor, they:
 
 *   [C-4-1] MUST implement a `TYPE_ROTATION_VECTOR` composite sensor.
 
 ### 7.3.2\. Magnetometer
 
-*   Device implementations SHOULD include a 3-axis magnetometer (compass).
+Device implementations:
 
-If device impelementations include a 3-axis magnetometer, they:
+*   [C-SR] Are STRONGLY RECOMMENDED to include a 3-axis magnetometer (compass).
+
+If device implementations include a 3-axis magnetometer, they:
 
 *   [C-1-1] MUST implement the `TYPE_MAGNETIC_FIELD` sensor.
 *   [C-1-2] MUST be able to report events up to a frequency of at least 10 Hz
@@ -170,16 +173,16 @@
     `TYPE_MAGNETIC_FIELD_UNCALIBRATED` sensor.
 
 
-If device impelementations include a 3-axis magnetometer, an accelerometer
-sensor and a gyroscope sensor, they:
+If device implementations include a 3-axis magnetometer, an accelerometer
+sensor, and a 3-axis gyroscope sensor, they:
 
 *   [C-2-1] MUST implement a `TYPE_ROTATION_VECTOR` composite sensor.
 
-If device impelementations include a 3-axis magnetometer, an accelerometer, they:
+If device implementations include a 3-axis magnetometer, an accelerometer, they:
 
 *   MAY implement the `TYPE_GEOMAGNETIC_ROTATION_VECTOR` sensor.
 
-If device impelementations include a 3-axis magnetometer, an accelerometer and
+If device implementations include a 3-axis magnetometer, an accelerometer and
 `TYPE_GEOMAGNETIC_ROTATION_VECTOR` sensor, they:
 
 *   [C-3-1] MUST consume less than 10 mW.
@@ -189,7 +192,7 @@
 
 Device implementations:
 
-*   SHOULD include a GPS/GNSS receiver.
+*   [C-SR] Are STRONGLY RECOMMENDED to include a GPS/GNSS receiver.
 
 If device implementations include a GPS/GNSS receiver and report the capability
 to applications through the `android.hardware.location.gps` feature flag, they:
@@ -220,71 +223,40 @@
        * SHOULD be able to simultaneously track at least 24 satellites, from
        multiple constellations (e.g. GPS + at least one of Glonass, Beidou,
        Galileo).
-*   [C-1-5] MUST report the GNSS technology generation through the test API
-‘getGnssYearOfHardware’.
-*    [SR] Continue to deliver normal GPS/GNSS location outputs during an
-emergency phone call.
-*    [SR] Report GNSS measurements from all constellations tracked (as reported
-in GnssStatus messages), with the exception of SBAS.
-*    [SR] Report AGC, and Frequency of GNSS measurement.
-*    [SR] Report all accuracy estimates (including Bearing, Speed, and Vertical)
-as part of each GPS/GNSS location.
-*    [SR] are STRONGLY RECOMMENDED to meet as many as possible from the
-additional mandatory requirements for devices reporting the year "2016" or
-"2017" through the Test API `LocationManager.getGnssYearOfHardware()`.
-
-If device implementations include a GPS/GNSS receiver and report the capability
-to applications through the `android.hardware.location.gps` feature flag and the
-`LocationManager.getGnssYearOfHardware()` Test API reports the year "2016" or
-newer, they:
-
-*    [C-2-1] MUST report GNSS measurements, as soon as they are found, even if a
-location calculated from GPS/GNSS is not yet reported.
-*    [C-2-2] MUST report GNSS pseudoranges and pseudorange rates, that, in
-open-sky conditions after determining the location, while stationary or moving
-with less than 0.2 meter per second squared of acceleration, are sufficient to
-calculate position within 20 meters, and speed within 0.2 meters per second,
-at least 95% of the time.
-
-If device implementations include a GPS/GNSS receiver and report the capability
-to applications through the `android.hardware.location.gps` feature flag and the
-`LocationManager.getGnssYearOfHardware()` Test API reports the year "2017" or
-newer, they:
-
-*    [C-3-1] MUST continue to deliver normal GPS/GNSS location outputs during an
-emergency phone call.
-*    [C-3-2] MUST report GNSS measurements from all constellations tracked (as
-reported in
-     GnssStatus messages), with the exception of SBAS.
-*    [C-3-3] MUST report AGC, and Frequency of GNSS measurement.
-*    [C-3-4] MUST report all accuracy estimates (including Bearing, Speed, and
-Vertical) as part of each GPS/GNSS location.
-
-If device implementations include a GPS/GNSS receiver and report the capability
-to applications through the `android.hardware.location.gps` feature flag and the
-`LocationManager.getGnssYearOfHardware()` Test API reports the year "2018" or
-newer, they:
-
-*    [C-4-1] MUST continue to deliver normal GPS/GNSS outputs to applications
-during a Mobile Station Based (MS-Based) Network Initiated emergency session
+*    [C-SR] Are STRONGLY RECOMMENDED to continue to deliver normal GPS/GNSS
+location outputs through GNSS Location Provider API's during an emergency phone
 call.
-*    [C-4-2] MUST report positions and measurements to the
-[GNSS Location Provider](https://developer.android.com/reference/android/location/LocationProvider)
-API's.
+*    [C-SR] Are STRONGLY RECOMMENDED to report GNSS measurements from all
+constellations tracked (as reported in GnssStatus messages), with the exception
+of SBAS.
+*    [C-SR] Are STRONGLY RECOMMENDED to report AGC, and Frequency of GNSS
+measurement.
+*    [C-SR] Are STRONGLY RECOMMENDED to report all accuracy estimates
+(including Bearing, Speed, and Vertical) as part of each GPS/GNSS location.
+*    [C-SR] Are STRONGLY RECOMMENDED to report GNSS measurements, as soon as
+they are found, even if a location calculated from GPS/GNSS is not yet
+reported.
+*    [C-SR] Are STRONGLY RECOMMENDED to report GNSS pseudoranges and
+pseudorange rates, that, in open-sky conditions after determining the location,
+while stationary or moving with less than 0.2 meter per second squared of
+acceleration, are sufficient to calculate position within 20 meters, and speed
+within 0.2 meters per second, at least 95% of the time.
+
 
 ### 7.3.4\. Gyroscope
 
 Device implementations:
 
-*    SHOULD include a gyroscope (angular change sensor).
-*    SHOULD NOT include a gyroscope sensor unless a 3-axis accelerometer is
-also included.
+*   [C-SR] Are STRONGLY RECOMMENDED to include a gyroscope sensor unless a
+3-axis accelerometer is also included.
 
-If device implementations include a gyroscope, they:
+If device implementations include a 3-axis gyroscope, they:
 
 *   [C-1-1] MUST be able to report events up to a frequency of at least 50 Hz.
-*   [C-1-2] MUST implement the `TYPE_GYROSCOPE` sensor and SHOULD also implement
-`TYPE_GYROSCOPE_UNCALIBRATED` sensor.
+*   [C-1-2] MUST implement the `TYPE_GYROSCOPE` sensor and are STRONGLY
+    RECOMMENDED to also implement the
+    [`TYPE_GYROSCOPE_UNCALIBRATED`](https://developer.android.com/reference/android/hardware/Sensor.html#TYPE_GYROSCOPE_UNCALIBRATED)
+    sensor.
 *   [C-1-3] MUST be capable of measuring orientation changes up to 1,000 degrees
 per second.
 *   [C-1-4] MUST have a resolution of 12-bits or more and SHOULD have a
@@ -297,29 +269,30 @@
 sampling rate, but MUST be constrained by this value. In other words, if you
 measure the variance of the gyro at 1 Hz sampling rate it SHOULD be no greater
 than 1e-7 rad^2/s^2.
-*   [SR] Existing and new Android devices are STRONGLY RECOMMENDED to
-implement the `SENSOR_TYPE_GYROSCOPE_UNCALIBRATED` sensor.
 *   [SR] Calibration error is STRONGLY RECOMMENDED to be less than 0.01 rad/s
 when device is stationary at room temperature.
 *   SHOULD report events up to at least 200 Hz.
 
-If device implementations include a gyroscope, an accelerometer sensor and a
+If device implementations include a 3-axis gyroscope, an accelerometer sensor and a
 magnetometer sensor, they:
 
 *   [C-2-1] MUST implement a `TYPE_ROTATION_VECTOR` composite sensor.
 
-If device implementations include a gyroscope and a accelerometer sensor, they:
+If device implementations include a 3-axis accelerometer and a 3-axis gyroscope
+sensor, they:
 
 *   [C-3-1] MUST implement the `TYPE_GRAVITY` and
 `TYPE_LINEAR_ACCELERATION` composite sensors.
-*   [SR] Existing and new Android devices are STRONGLY RECOMMENDED to implement
-the `TYPE_GAME_ROTATION_VECTOR` sensor.
-*   SHOULD implement the `TYPE_GAME_ROTATION_VECTOR` composite sensor.
+*   [C-SR] Are STRONGLY RECOMMENDED to implement the
+    [`TYPE_GAME_ROTATION_VECTOR`](https://developer.android.com/reference/android/hardware/Sensor.html#TYPE_GAME_ROTATION_VECTOR)
+    composite sensor.
 
 ### 7.3.5\. Barometer
 
-*    Device implementations SHOULD include a barometer (ambient air pressure
-sensor).
+Device implementations:
+
+*   [C-SR] Are STRONGLY RECOMMENDED to include a barometer (ambient air pressure
+    sensor).
 
 If device implementations include a barometer, they:
 
@@ -335,6 +308,7 @@
 ### 7.3.6\. Thermometer
 
 Device implementations:
+
 *   MAY include an ambient thermometer (temperature sensor).
 *   MAY but SHOULD NOT include a CPU temperature sensor.
 
@@ -453,10 +427,7 @@
     *   MUST implement a non-wake-up form of this sensor with a buffering
         capability of at least 300 sensor events.
     *   MUST have a batching power consumption not worse than 2 mW.
-*   [C-2-8] MUST have a `TYPE_GAME_ROTATION_VECTOR` sensor which:
-    *   MUST implement a non-wake-up form of this sensor with a buffering
-        capability of at least 300 sensor events.
-    *   MUST have a batching power consumption not worse than 4 mW.
+*   [C-2-8] MUST have a `TYPE_GAME_ROTATION_VECTOR` sensor.
 *   [C-2-9] MUST have a `TYPE_SIGNIFICANT_MOTION` sensor which:
     *   MUST have a power consumption not worse than 0.5 mW when device is
         static and 1.5 mW when device is moving.
@@ -520,131 +491,138 @@
 
 ### 7.3.10\. Biometric Sensors
 
-#### 7.3.10.1\. Fingerprint Sensors
+
+For additional background on Measuring Biometric Unlock Security, please see
+[Measuring Biometric Security documentation](https://source.android.com/security/biometric/measure).
 
 If device implementations include a secure lock screen, they:
 
-*    SHOULD include a fingerprint sensor.
+*   SHOULD include a biometric sensor
 
-If device implementations include a fingerprint sensor and make the sensor
-available to third-party apps, they:
+Biometric sensors can be classified as **Strong**, **Weak**, or **Convenience**
+based on their spoof and imposter acceptance rates, and on the security of the
+biometric pipeline. This classification determines the capabilities the
+biometric sensor has to interface with the platform and with third-party
+applications. Sensors are classified as **Convenience** by default, and need
+to meet additional requirements as detailed below if they wish to be classified
+as either **Weak** or **Strong**. Both **Weak** and **Strong** biometrics get
+additional capabilities as detailed below.
 
-*   [C-1-1] MUST declare support for the `android.hardware.fingerprint` feature.
-*   [C-1-2] MUST fully implement the
-[corresponding API](
-https://developer.android.com/reference/android/hardware/fingerprint/package-summary.html)
-as described in the Android SDK documentation.
-*   [C-1-3] MUST have a false acceptance rate not higher than 0.002%.
-*   [SR] Are STRONGLY RECOMMENDED to have a spoof and imposter acceptance rate
-not higher than 7%.
-*   [C-1-4] MUST disclose that this mode may be less secure than a strong PIN,
-pattern, or password and clearly enumerate the risks of enabling it, if the
-spoof and imposter acceptance rates are higher than 7%.
-*   [C-1-5] MUST rate limit attempts for at least 30 seconds after five false
-trials for fingerprint verification.
-*   [C-1-6] MUST have a hardware-backed keystore implementation, and perform the
-fingerprint matching in a Trusted Execution Environment (TEE) or on a chip with
-a secure channel to the TEE.
-*   [C-1-7] MUST have all identifiable fingerprint data encrypted and
-cryptographically authenticated such that they cannot be acquired, read or
-altered outside of the Trusted Execution Environment (TEE), or a chip with a
-secure channel to the TEE as documented in the [implementation guidelines](
-https://source.android.com/devices/tech/security/authentication/fingerprint-hal.html)
-on the Android Open Source Project site.
-*   [C-1-8] MUST prevent adding a fingerprint without first establishing a chain
-of trust by having the user confirm existing or add a new device credential
-(PIN/pattern/password) that's secured by TEE; the Android Open Source Project
-    implementation provides the mechanism in the framework to do so.
-*   [C-1-9] MUST NOT enable 3rd-party applications to distinguish between
-individual fingerprints.
-*   [C-1-10] MUST honor the DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT
-flag.
-*   [C-1-11] MUST, when upgraded from a version earlier than Android 6.0, have
-the fingerprint data securely migrated to meet the above requirements or
-removed.
-*   [C-1-12] MUST completely remove all identifiable fingerprint data for a
-user when the user's account is removed (including via a factory reset).
-*   [C-1-13] MUST not allow unencrypted access to identifiable fingerprint data
-or any data derived from it (such as embeddings) to the Application Processor.
-*   [SR] Are STRONGLY RECOMMENDED to have a false rejection rate of less than 10%,
-as measured on the device.
-*   [SR] Are STRONGLY RECOMMENDED to have a latency below 1 second, measured from
-when the fingerprint sensor is touched until the screen is unlocked, for one
-enrolled finger.
-*   SHOULD use the Android Fingerprint icon provided in the Android Open Source
-Project.
 
-#### 7.3.10.2\. Other Biometric Sensors
+To make a biometric sensor available to third-party applications, device
+implementations:
 
-If device implementations include one or more non-fingerprint-based-biometric
-sensors and make them available to third-party apps they:
+*   [C-0-1] MUST meet the requirements for **Strong** or **Weak** biometric as
+    defined in this document.
 
-*   [C-1-1] MUST have a false acceptance rate not higher than 0.002%.
-*   [C-SR] Are STRONGLY RECOMMENDED to have a spoof and imposter acceptance rate
-not higher than 7%.
+
+To allow access to keystore keys to third-party applications,
+device implementations:
+
+*   [C-0-2] MUST meet the requirements for **Strong** as defined in this
+    document.
+
+Additionally:
+
+*   [C-0-3] MUST be paired with an explicit confirm action (e.g. a button press)
+    if that **Strong** biometric is passive (e.g. face or iris where no
+    explicit signal of the user's intent exists).
+     *   [C-SR] The confirm action for passive biometrics is STRONGLY
+     RECOMMENDED to be secured such that an operating system or kernel
+     compromise cannot spoof it. For example, this means that the confirm action
+     based on a physical button is routed through an input-only general-purpose
+     input/output (GPIO) pin of a secure element (SE) that cannot be driven
+     by any other means than a physical button press.
+
+If device implementations wish to treat a biometric sensor as **Convenience**,
+they:
+
+*   [C-1-1] MUST have a false acceptance rate less than 0.002%.
 *   [C-1-2] MUST disclose that this mode may be less secure than a strong PIN,
-pattern, or password and clearly enumerate the risks of enabling it, if the
-spoof and imposter acceptance rates are higher than 7%.
+    pattern, or password and clearly enumerate the risks of enabling it, if the
+    spoof and imposter acceptance rates are higher than 7%.
 *   [C-1-3] MUST rate limit attempts for at least 30 seconds after five false
-trials for biometric verification - where a false trial is one with an adequate
-capture quality
-(ACQUIRED_GOOD) that does not match an enrolled biometric
-*   [C-1-4] MUST have a hardware-backed keystore implementation, and perform the
-biometric matching in a Trusted Execution Environment (TEE) or on a chip with
-a secure channel to the TEE.
-* [C-1-5] MUST have all identifiable data encrypted and cryptographically
-authenticated such that they cannot be acquired, read or altered outside of the
-Trusted Execution Environment (TEE), or a chip with a secure channel to the TEE
-as documented in the [implementation guidelines](
-https://source.android.com/devices/tech/security/authentication/fingerprint-hal.html)
-on the Android Open Source Project site.
-* [C-1-6] MUST prevent adding new biometrics without first establishing a chain
-of trust by having the user confirm existing or add a new device credential
-(PIN/pattern/password) that's secured by TEE; the Android Open Source Project
-implementation provides the mechanism in the framework to do so.
-*   [C-1-7] MUST NOT enable third-party applications to distinguish between
-biometric enrollments.
-*   [C-1-8] MUST honor the individual flag for that biometric (ie:
-`DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT`,
-`DevicePolicymanager.KEYGUARD_DISABLE_FACE`, or
-`DevicePolicymanager.KEYGUARD_DISABLE_IRIS`).
-*   [C-1-9] MUST completely remove all identifiable biometric data for a user when
-the user's account is removed (including via a factory reset).
-*   [C-1-10] MUST not allow unencrypted access to identifiable biometric data or any
-data derived from it (such as embeddings) to the Application Processor outside
-the context of the TEE.
-*   [C-SR] Are STRONGLY RECOMMENDED to have a false rejection rate of less than 10%,
-as measured on the device.
-*   [C-SR] Are STRONGLY RECOMMENDED to have a latency below 1 second, measured from
-when the biometric is detected, until the screen is unlocked, for each
-enrolled biometric.
+    trials for biometric verification - where a false trial is one with an
+    adequate capture quality ([`BIOMETRIC_ACQUIRED_GOOD`](
+    https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt.html#BIOMETRIC_ACQUIRED_GOOD))
+    that does not match an enrolled biometric.
+*   [C-1-4] MUST prevent adding new biometrics without first establishing a
+    chain of trust by having the user confirm existing or add a new device
+    credential (PIN/pattern/password) that's secured by TEE; the Android Open
+    Source Project implementation provides the mechanism in the framework to do
+    so.
+*   [C-1-5] MUST completely remove all identifiable biometric data for a user
+    when the user's account is removed (including via a factory reset).
+*   [C-1-6] MUST honor the individual flag for that biometric (i.e.
+    [`DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT`](
+    https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#KEYGUARD_DISABLE_FINGERPRINT),
+    [`DevicePolicymanager.KEYGUARD_DISABLE_FACE`](
+    https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#KEYGUARD_DISABLE_FACE)
+    , or
+    [`DevicePolicymanager.KEYGUARD_DISABLE_IRIS`](
+    https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#KEYGUARD_DISABLE_IRIS)
+    ).
+*   [C-1-7] MUST challenge the user for the recommended primary
+    authentication (e.g. PIN, pattern, password) once every 24 hours
+    or less for new devices launching with Android version 10, once every
+    72 hours or less for devices upgrading from earlier Android version.
+*   [C-1-8] MUST challenge the user for the recommended primary
+     authentication (eg: PIN, pattern, password) after one of the
+     follwing:
+     *    a 4-hour idle timeout period, OR
+     *    3 failed biometric authentication attempts.
+     *    The idle timeout period and the failed authentication count is reset
+          after any successful confirmation of the device credentials.
+*   [C-SR] Are STRONGLY RECOMMENDED to have a false rejection rate of less than
+    10%, as measured on the device.
+*   [C-SR] Are STRONGLY RECOMMENDED to have a latency below 1 second, measured
+    from when the biometric is detected, until the screen is unlocked, for each
+    enrolled biometric.
 
+If device implementations wish to treat a biometric sensor as **Weak**, they:
 
-### 7.3.11\. Android Automotive-only sensors
+*   [C-2-1] MUST meet all requirements for **Convenience** above, except
+    for [C-1-2].
+*   [C-2-2] MUST have a spoof and imposter acceptance rate not higher than 20%.
+*   [C-2-3] MUST have a hardware-backed keystore implementation, and perform the
+    biometric matching in an isolated execution environment outside Android user
+    or kernel space, such as the Trusted Execution Environment (TEE), or on a
+    chip with a secure channel to the isolated execution environment.
+*   [C-2-4] MUST have all identifiable data encrypted and cryptographically
+    authenticated such that they cannot be acquired, read or altered outside of
+    the isolated execution environment or a chip with a secure channel to the
+    isolated execution environment as documented in the [implementation
+    guidelines](https://source.android.com/security/biometric#hal-implementation)
+    on the Android Open Source Project site.
+*   [C-2-5] For camera based biometrics, while biometric based authentication or
+    enrollment is happening:
+    *    MUST operate the camera in a mode that prevents camera frames from
+    being read or altered outside the isolated execution environment or a chip
+    with a secure channel to the isolated execution environment.
+    *    For RGB single-camera solutions, the camera frames CAN be
+    readable outside the isolated execution environment to support operations
+    such as preview for enrollment, but MUST still NOT be alterable.
+*   [C-2-6] MUST NOT enable third-party applications to distinguish between
+    individual biometric enrollments.
+*   [C-2-7] MUST NOT allow unencrypted access to identifiable
+    biometric data or any data derived from it (such as embeddings) to
+    the Application Processor outside the context of the TEE.
+*   [C-2-8] MUST have a secure processing pipeline such that an operating
+    system or kernel compromise cannot allow data to be directly injected to
+    falsely authenticate as the user.
 
-Automotive-specific sensors are defined in the
-`android.car.CarSensorManager API`.
+    If device implementations are already launched on an earlier Android version
+    and cannot meet the requirement C-2-8 through a system software update, they
+    MAY be exempted from the requirement.
 
-#### 7.3.11.1\. Current Gear
+If device implementations wish to treat a biometric sensor as **Strong**, they:
 
-See [Section 2.5.1](#2_5_1_hardware) for device-specific requirements.
-
-#### 7.3.11.2\. Day Night Mode
-
-See [Section 2.5.1](#2_5_1_hardware) for device-specific requirements.
-
-#### 7.3.11.3\. Driving Status
-
-This requirement is deprecated.
-
-#### 7.3.11.4\. Wheel Speed
-
-See [Section 2.5.1](#2_5_1_hardware) for device-specific requirements.
-
-#### 7.3.11.5\. Parking Brake
-
-See [Section 2.5.1](#2_5_1_hardware) for device-specific requirements.
-
+*   [C-3-1] MUST meet all the requirements of **Weak** above. Upgrading
+    devices from an earlier Android version is not exempted from C-2-7.
+*   [C-3-2] MUST have a spoof and imposter acceptance rate not higher than 7%.
+*   [C-3-3] MUST challenge the user for the recommended primary
+    authentication (e.g. PIN, pattern, password) once every 72 hours
+    or less.
 
 ## 7.3.12\. Pose Sensor
 
diff --git a/7_hardware-compatibility/7_4_data-connectivity.md b/7_hardware-compatibility/7_4_data-connectivity.md
index 746bb7d..044d7de 100644
--- a/7_hardware-compatibility/7_4_data-connectivity.md
+++ b/7_hardware-compatibility/7_4_data-connectivity.md
@@ -25,6 +25,13 @@
 
 *    [C-2-1] MUST implement the full APIs as no-ops.
 
+If device implementations support eUICCs or eSIMs/embedded SIMs and include
+a proprietary mechanism to make eSIM functionality available for third-party
+developers, they:
+
+*    [C-3-1] MUST provide a complete implementation of the [`EuiccManager API`](
+https://developer.android.com/reference/android/telephony/euicc/EuiccManager).
+
 #### 7.4.1.1\. Number Blocking Compatibility
 
 If device implementations report the `android.hardware.telephony feature`, they:
@@ -66,6 +73,8 @@
     specified via
     [`CAPABILITY_SUPPORT_HOLD`](
     https://developer.android.com/reference/android/telecom/Connection.html#CAPABILITY_SUPPORT_HOLD).
+*   [C-1-3] MUST have an application that implements
+    [InCallService](https://developer.android.com/reference/android/telecom/InCallService).
 *   [C-SR] Are STRONGLY RECOMMENDED to notify the user that answering an
     incoming call will drop an ongoing call.
 
@@ -120,7 +129,8 @@
     In other words, they MAY only disable the Internet access provided by any
     other network provider (e.g. mobile data) if they successfully validate
     that the Wi-Fi network is providing Internet access.
-*   [C-1-6] MUST, when the [`ConnectivityManager.reportNetworkConnectivity()`](
+*   [C-1-6] Are STRONGLY RECOMMENDED to, when the
+    [`ConnectivityManager.reportNetworkConnectivity()`](
     https://developer.android.com/reference/android/net/ConnectivityManager.html#reportNetworkConnectivity%28android.net.Network%2C%20boolean%29)
     API method is called, re-evaluate the Internet access on the `Network` and,
     once the evaluation determines that the current `Network` no longer provides
@@ -141,6 +151,24 @@
     * SSID Parameter Set (0)
     * DS Parameter Set (3)
 
+If device implementations include support for Wi-Fi power save mode as defined
+in IEEE 802.11 standard, they:
+
+*   [C-3-1] MUST turn off Wi-Fi power save mode whenever an app acquires
+    `WIFI_MODE_FULL_HIGH_PERF` lock or `WIFI_MODE_FULL_LOW_LATENCY` lock
+    via [`WifiManager.createWifiLock()`](
+    https://developer.android.com/reference/android/net/wifi/WifiManager.html#createWifiLock\(int,%2520java.lang.String\))
+    and  [`WifiManager.WifiLock.acquire()`](
+    https://developer.android.com/reference/android/net/wifi/WifiManager.WifiLock.html#acquire\(\))
+    APIs and the lock is active.
+*   [C-3-2] The average round trip latency between the device
+    and an access point while the device is in a Wi-Fi Low Latency Lock
+    (`WIFI_MODE_FULL_LOW_LATENCY`) mode MUST be smaller than the
+    latency during a Wi-Fi High Perf Lock (`WIFI_MODE_FULL_HIGH_PERF`) mode.
+*   [C-SR] Are STRONGLY RECOMMENDED to minimize Wi-Fi round trip latency
+    whenever a Low Latency Lock (`WIFI_MODE_FULL_LOW_LATENCY`) is acquired
+    and takes effect.
+
 If device implementations support Wi-Fi and use Wi-Fi for location scanning,
 they:
 
@@ -253,6 +281,45 @@
     which is executed while the Wi-Fi interface on which the RTT is
     being executed is not associated to an Access Point.
 
+#### 7.4.2.6\. Wi-Fi Keepalive Offload
+
+Device implementations:
+
+*   SHOULD include support for Wi-Fi keepalive offload.
+
+If device implementations include support for Wi-Fi keepalive offload and
+expose the functionality to third-party apps, they:
+
+*   [C-1-1] MUST support the
+[SocketKeepAlive](https://developer.android.google.com/reference/android/net/SocketKeepalive.html) API.
+
+*   [C-1-2] MUST support at least three concurrent keepalive slots over Wi-Fi and
+at least one keepalive slot over cellular.
+
+If device implementations do not include support for Wi-Fi keepalive offload,
+they:
+
+*   [C-2-1] MUST return [`ERROR_UNSUPPORTED`](
+https://developer.android.google.com/reference/android/net/SocketKeepalive.html#ERROR_UNSUPPORTED).
+
+#### 7.4.2.7\. Wi-Fi Easy Connect (Device Provisioning Protocol)
+
+Device implementations:
+
+*    SHOULD include support for [Wi-Fi Easy Connect (DPP)](
+     https://www.wi-fi.org/file/wi-fi-certified-easy-connect-technology-overview).
+
+If device implementations include support for Wi-Fi Easy Connect and expose the
+functionality to third-party apps, they:
+
+*   [C-1-1] MUST implement the [`Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI`](
+    https://developer.android.com/reference/android/provider/Settings.html#ACTION_PROCESS_WIFI_EASY_CONNECT_URI)
+    Intent APIs as described in the SDK documentation.
+*   [C-1-2] MUST have the [WifiManager#isEasyConnectSupported\(\)](
+    https://developer.android.com/reference/android/net/wifi/WifiManager.html#isEasyConnectSupported\(\))
+    method return `true`.
+
+
 ### 7.4.3\. Bluetooth
 
 If device implementations support Bluetooth Audio profile, they:
@@ -313,6 +380,15 @@
 *    [C-4-1] MUST provide a user affordance to enable/disable the value read
      through the System API `BluetoothAdapter.isBleScanAlwaysAvailable()`.
 
+If device implementations include support for Bluetooth LE and Hearing Aids
+Profile, as described in
+[Hearing Aid Audio Support Using Bluetooth LE](
+https://source.android.com/devices/bluetooth/asha), they:
+
+*   [C-5-1] MUST return `true` for
+[BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID)](
+https://developer.android.com/reference/android/bluetooth/BluetoothAdapter.html#getProfileProxy(android.content.Context,%20android.bluetooth.BluetoothProfile.ServiceListener,%20int)).
+
 ### 7.4.4\. Near-Field Communications
 
 Device implementations:
@@ -350,54 +426,6 @@
     Android are very strongly encouraged to meet these requirements now so
     they will be able to upgrade to the future platform releases.
 
-*   [C-1-3] MUST be capable of transmitting and receiving data via the
-    following peer-to-peer standards and protocols:
-     *   ISO 18092
-     *   LLCP 1.2 (defined by the NFC Forum)
-     *   SDP 1.0 (defined by the NFC Forum)
-     *   [NDEF Push Protocol](
-          http://static.googleusercontent.com/media/source.android.com/en/us/compatibility/ndef-push-protocol.pdf)
-     *   SNEP 1.0 (defined by the NFC Forum)
-*   [C-1-4] MUST include support for [Android Beam](
-    http://developer.android.com/guide/topics/connectivity/nfc/nfc.html) and
-    SHOULD enable Android Beam by default.
-*   [C-1-5] MUST be able to send and receive using Android Beam,
-    when Android Beam is enabled or another proprietary NFC P2p mode is
-    turned on.
-*   [C-1-6] MUST implement the SNEP default server. Valid NDEF messages
-received by the default SNEP server MUST be dispatched to applications using
-the `android.nfc.ACTION_NDEF_DISCOVERED` intent. Disabling Android Beam in
-settings MUST NOT disable dispatch of incoming NDEF message.
-*   [C-1-7] MUST honor the `android.settings.NFCSHARING_SETTINGS` intent to
-    show [NFC sharing settings](
-    http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS).
-*   [C-1-8] MUST implement the NPP server. Messages received by the NPP
-    server MUST be processed the same way as the SNEP default server.
-*   [C-1-9] MUST implement a SNEP client and attempt to send outbound P2P
-    NDEF to the default SNEP server when Android Beam is enabled. If no default
-    SNEP server is found then the client MUST attempt to send to an NPP server.
-*   [C-1-10] MUST allow foreground activities to set the outbound P2P NDEF
-message using `android.nfc.NfcAdapter.setNdefPushMessage`, and
-`android.nfc.NfcAdapter.setNdefPushMessageCallback`, and
-`android.nfc.NfcAdapter.enableForegroundNdefPush`.
-*   SHOULD use a gesture or on-screen confirmation, such as 'Touch to
-Beam', before sending outbound P2P NDEF messages.
-*   [C-1-11] MUST support NFC Connection handover to Bluetooth when the
-    device supports Bluetooth Object Push Profile.
-*   [C-1-12] MUST support connection handover to Bluetooth when using
-    `android.nfc.NfcAdapter.setBeamPushUris`, by implementing the
-    “[Connection Handover version 1.2](
-    http://members.nfc-forum.org/specs/spec_list/#conn_handover)” and
-    “[Bluetooth Secure Simple Pairing Using NFC version 1.0](
-    http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf)”
-    specs from the NFC Forum. Such an implementation MUST implement the handover
-    LLCP service with service name “urn:nfc:sn:handover” for exchanging the
-    handover request/select records over NFC, and it MUST use the Bluetooth Object
-    Push Profile for the actual Bluetooth data transfer. For legacy reasons (to
-    remain compatible with Android 4.1 devices), the implementation SHOULD still
-   accept SNEP GET requests for exchanging the handover request/select records
-   over NFC. However an implementation itself SHOULD NOT send SNEP GET requests
-   for performing connection handover.
 *   [C-1-13] MUST poll for all supported technologies while in NFC discovery
     mode.
 *   SHOULD be in NFC discovery mode while the device is awake with the
@@ -428,7 +456,6 @@
 https://developer.android.com/reference/android/nfc/cardemulation/NfcFCardEmulation.html)
 as defined in the Android SDK.
 
-
 If device implementations include general NFC support as described in this
 section and support MIFARE technologies (MIFARE Classic,
 MIFARE Ultralight, NDEF on MIFARE Classic) in the reader/writer role, they:
diff --git a/7_hardware-compatibility/7_5_cameras.md b/7_hardware-compatibility/7_5_cameras.md
index b07927b..3b1339f 100644
--- a/7_hardware-compatibility/7_5_cameras.md
+++ b/7_hardware-compatibility/7_5_cameras.md
@@ -7,6 +7,14 @@
 3 RGBA_8888 bitmaps equal to the size of the images produced by the
 largest-resolution camera sensor on the device, while camera is open for the
 purpose of basic preview and still capture.
+*   [C-1-3] MUST ensure that the preinstalled default camera application
+handling intents [`MediaStore.ACTION_IMAGE_CAPTURE`](https://developer.android.com/reference/android/provider/MediaStore.html#ACTION_IMAGE_CAPTURE),
+[`MediaStore.ACTION_IMAGE_CAPTURE_SECURE`](https://developer.android.com/reference/android/provider/MediaStore.html#ACTION_IMAGE_CAPTURE_SECURE),
+or
+[`MediaStore.ACTION_VIDEO_CAPTURE`](https://developer.android.com/reference/android/provider/MediaStore.html#ACTION_VIDEO_CAPTURE),
+is responsible for removing the user location in the image metadata before
+sending it to the receiving application when the receiving application does not
+have [`ACCESS_FINE_LOCATION`](https://developer.android.com/reference/android/Manifest.permission.html#ACCESS_FINE_LOCATION).
 
 ### 7.5.1\. Rear-Facing Camera
 
@@ -163,10 +171,11 @@
 cameras; for instance, even though most front-facing cameras do not support
 autofocus, the API callbacks must still be “faked” as described.
 *   [C-0-6] MUST recognize and honor each parameter name
-defined as a constant on the
+defined as a constant in the
 [`android.hardware.Camera.Parameters`](
-http://developer.android.com/reference/android/hardware/Camera.Parameters.html)
-class.
+https://developer.android.com/reference/android/hardware/Camera.Parameters.html)
+class and the [`android.hardware.camera2.CaptureRequest`](
+https://developer.android.com/reference/android/hardware/camera2/CaptureRequest) class.
 Conversely, device implementations MUST NOT honor or recognize string constants
 passed to the `android.hardware.Camera.setParameters()` method other than those
 documented as constants on the `android.hardware.Camera.Parameters`. That is,
@@ -198,16 +207,12 @@
 [`android.hardware.Camera`](https://developer.android.com/reference/android/hardware/Camera)
 API also accessible via the [`android.hardware.camera2`](https://developer.android.com/reference/android/hardware/camera2/package-summary)
 API.
-*   [C-SR] Are STRONGLY RECOMMENDED to support a logical camera device that lists
+*   [C-SR] For devices with multiple RGB cameras facing in the same direction,
+are STRONGLY RECOMMENDED to support a logical camera device that lists
 capability
 [`CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA`](
 https://developer.android.com/reference/android/hardware/camera2/CameraMetadata#REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA),
-for devices with multiple cameras facing the same direction, consisting of each
-physical camera facing that direction, as long as the physical camera type is
-supported by the framework and
-[`CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL`](
-https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics#INFO_SUPPORTED_HARDWARE_LEVEL)
-for the physical cameras is either `LIMITED`, `FULL`, or `LEVEL_3`.
+consisting of all of the RGB cameras facing that direction as physical sub-devices.
 
 If device implementations provide a proprietary camera API to 3rd-party apps,
 they:
diff --git a/7_hardware-compatibility/7_6_memory-and-storage.md b/7_hardware-compatibility/7_6_memory-and-storage.md
index 292b175..b3f4a41 100644
--- a/7_hardware-compatibility/7_6_memory-and-storage.md
+++ b/7_hardware-compatibility/7_6_memory-and-storage.md
@@ -67,7 +67,7 @@
     on the box and other material available at time of purchase that the storage
     medium has to be purchased separately.
 
-If device implementations use a protion of the non-removable storage to satisfy
+If device implementations use a portion of the non-removable storage to satisfy
 the above requirements, they:
 
 *   SHOULD use the AOSP implementation of the internal application shared
diff --git a/7_hardware-compatibility/7_7_usb.md b/7_hardware-compatibility/7_7_usb.md
index 90db766..59faf56 100644
--- a/7_hardware-compatibility/7_7_usb.md
+++ b/7_hardware-compatibility/7_7_usb.md
@@ -71,9 +71,9 @@
      to a standard type-A port.
 *   [C-1-3] MUST NOT ship with an adapter converting from USB type A or
 micro-AB ports to a type-C port (receptacle).
-*   [SR] STRONGLY RECOMMENDED to implement the [USB audio class](
-http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO)
-as documented in the Android SDK documentation.
+*   [C-SR] Are STRONGLY RECOMMENDED to implement the [USB audio class](
+    http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO)
+    as documented in the Android SDK documentation.
 *   SHOULD support charging the connected USB peripheral device while in host
     mode; advertising a source current of at least 1.5A as specified in the
     Termination Parameters section of the
diff --git a/7_hardware-compatibility/7_8_audio.md b/7_hardware-compatibility/7_8_audio.md
index b1ec118..72d9537 100644
--- a/7_hardware-compatibility/7_8_audio.md
+++ b/7_hardware-compatibility/7_8_audio.md
@@ -89,6 +89,14 @@
 *   [C-2-1] MUST support the detection of microphone on the plugged in audio
 accessory.
 
+#### 7.8.2.2\. Digital Audio Ports
+
+In order to be compatible with the headsets and other audio accessories using
+USB-C connectors and implementing (USB audio class) across the Android ecosystem
+as defined in [Android USB headset specification](https://source.android.com/devices/accessories/headset/usb-device).
+
+See Section [2.2.1](#2_2_1_hardware) for device-specific requirements.
+
 ### 7.8.3\. Near-Ultrasound
 
 Near-Ultrasound audio is the 18.5 kHz to 20 kHz band.
@@ -114,5 +122,133 @@
 http://developer.android.com/reference/android/media/AudioManager.html#PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND)
 is "true":
 
-*    [C-2-1] The speaker's mean response in 18.5 kHz - 20 kHz MUST be no lower
-than 40 dB below the response at 2 kHz.
+*    [C-2-1] The speaker's mean response in 18.5 kHz - 20 kHz MUST be no lower than 40 dB below the response at 2 kHz.
+
+### 7.8.4\. Signal Integrity
+
+Device implementations:
+*   SHOULD provide a glitch-free audio signal path for both input
+    and output streams on handheld devices, as defined by zero glitches
+    measured during a test of one minute per path.
+    Test using [OboeTester]
+    (https://github.com/google/oboe/tree/master/apps/OboeTester)
+    “Automated Glitch Test”.
+
+The test requires an [audio loopback dongle]
+(https://source.android.com/devices/audio/latency/loopback),
+used directly in a 3.5mm jack, and/or in combination with a USB-C to 3.5mm adapter.
+All audio output ports SHOULD be tested.
+
+OboeTester currently supports AAudio paths, so the
+following combinations SHOULD be tested for glitches using AAudio:
+
+<table>
+ <tr>
+  <th>Perf Mode
+  <th>Sharing
+  <th>Out Sample Rate
+  <th>In Chans
+  <th>Out Chans
+ </tr>
+ <tr>
+  <td>LOW_LATENCY</td>
+  <td>EXCLUSIVE</td>
+  <td>UNSPECIFIED</td>
+  <td>1</td>
+  <td>2</td>
+ </tr>
+ <tr>
+  <td>LOW_LATENCY</td>
+  <td>EXCLUSIVE</td>
+  <td>UNSPECIFIED</td>
+  <td>2</td>
+  <td>1</td>
+ </tr>
+ <tr>
+  <td>LOW_LATENCY</td>
+  <td>SHARED</td>
+  <td>UNSPECIFIED</td>
+  <td>1</td>
+  <td>2</td>
+ </tr>
+ <tr>
+  <td>LOW_LATENCY</td>
+  <td>SHARED</td>
+  <td>UNSPECIFIED</td>
+  <td>2</td>
+  <td>1</td>
+ </tr>
+ <tr>
+  <td>NONE</td>
+  <td>SHARED</td>
+  <td>48000</td>
+  <td>1</td>
+  <td>2</td>
+ </tr>
+ <tr>
+  <td>NONE</td>
+  <td>SHARED</td>
+  <td>48000</td>
+  <td>2</td>
+  <td>1</td>
+ </tr>
+ <tr>
+  <td>NONE</td>
+  <td>SHARED</td>
+  <td>44100</td>
+  <td>1</td>
+  <td>2</td>
+ </tr>
+ <tr>
+  <td>NONE</td>
+  <td>SHARED</td>
+  <td>44100</td>
+  <td>2</td>
+  <td>1</td>
+ </tr>
+ <tr>
+  <td>NONE</td>
+  <td>SHARED</td>
+  <td>16000</td>
+  <td>1</td>
+  <td>2</td>
+ </tr>
+ <tr>
+  <td>NONE</td>
+  <td>SHARED</td>
+  <td>16000</td>
+  <td>2</td>
+  <td>1</td>
+ </tr>
+</table>
+
+A reliable stream SHOULD meet the following criteria for Signal to Noise
+Ratio (SNR) and Total Harmonic Distortion (THD) for 2000 Hz sine.
+
+<table>
+ <tr>
+  <th>Transducer</th>
+  <th>THD</th>
+  <th>SNR</th>
+ </tr>
+ <tr>
+  <td>primary built-in speaker, measured using an external reference microphone</td>
+  <td>&lt; 3.0%</td>
+  <td>&gt;= 50 dB</td>
+ </tr>
+ <tr>
+  <td>primary built-in microphone, measured using an external reference speaker</td>
+  <td>&lt; 3.0%</td>
+  <td>&gt;= 50 dB</td>
+ </tr>
+ <tr>
+  <td>built-in analog 3.5 mm jacks, tested using loopback adapter</td>
+  <td>&lt; 1%</td>
+  <td>&gt;= 60 dB</td>
+ </tr>
+ <tr>
+  <td>USB adapters supplied with the phone, tested using loopback adapter</td>
+  <td>&lt; 1.0%</td>
+  <td>&gt;= 60 dB</td>
+ </tr>
+</table>
diff --git a/7_hardware-compatibility/7_9_virtual-reality.md b/7_hardware-compatibility/7_9_virtual-reality.md
index 0704d10..ccc9a75 100644
--- a/7_hardware-compatibility/7_9_virtual-reality.md
+++ b/7_hardware-compatibility/7_9_virtual-reality.md
@@ -73,7 +73,7 @@
 *   [C-SR] Are STRONGLY RECOMMENDED to support the allocation of `AHardwareBuffer`s
     with more than one layer and flags and formats specified in C-1-10.
 *   [C-1-11] MUST support H.264 decoding at least 3840 x 2160 at 30fps,
-    compressed to an average of 40Mbps (equivalent to 4 instances of 
+    compressed to an average of 40Mbps (equivalent to 4 instances of
     1920 x1080 at 30 fps-10 Mbps or 2 instances of 1920 x 1080 at 60 fps-20 Mbps).
 *   [C-1-12] MUST support HEVC and VP9, MUST be capable of decoding at least
     1920 x 1080 at 30 fps compressed to an average of 10 Mbps and SHOULD be
diff --git a/8_performance-and-power/8_0_intro.md b/8_performance-and-power/8_0_intro.md
index 02a85b8..0138558 100644
--- a/8_performance-and-power/8_0_intro.md
+++ b/8_performance-and-power/8_0_intro.md
@@ -2,4 +2,4 @@
 
 Some minimum performance and power criteria are critical to the user experience
 and impact the baseline assumptions developers would have when developing an
-app.
\ No newline at end of file
+app.
diff --git a/8_performance-and-power/8_1_user-experience-consistency.md b/8_performance-and-power/8_1_user-experience-consistency.md
index 85f8a14..ce81e1e 100644
--- a/8_performance-and-power/8_1_user-experience-consistency.md
+++ b/8_performance-and-power/8_1_user-experience-consistency.md
@@ -5,4 +5,3 @@
 applications and games. Device implementations, depending on the device type,
 MAY have measurable requirements for the user interface latency and task
 switching as described in [section 2](#2_device-types).
-
diff --git a/8_performance-and-power/8_2_file-io-access-performance.md b/8_performance-and-power/8_2_file-io-access-performance.md
index c667ec5..3ada554 100644
--- a/8_performance-and-power/8_2_file-io-access-performance.md
+++ b/8_performance-and-power/8_2_file-io-access-performance.md
@@ -15,4 +15,3 @@
 10MB write buffer.
 *    **Random read performance**. Measured by reading a 256MB file using 4KB
 write buffer.
-
diff --git a/8_performance-and-power/8_3_power-saving-modes.md b/8_performance-and-power/8_3_power-saving-modes.md
index f5d90ba..1765d95 100644
--- a/8_performance-and-power/8_3_power-saving-modes.md
+++ b/8_performance-and-power/8_3_power-saving-modes.md
@@ -30,10 +30,31 @@
 implement any or all of the 4 sleeping power states as defined by the Advanced
 Configuration and Power Interface (ACPI).
 
-If device implementations implement S3 and S4 power states as defined by the
+If device implementations implement S4 power states as defined by the
 ACPI, they:
 
-*   [C-1-1] MUST enter these states only after the user has taken an explicit action
+*   [C-1-1] MUST enter this state only after the user has taken an explicit action
     to put the device in an inactive state (e.g. by closing a lid that is physically
-    part of the device or turning off a vehicle or television) and before the user re-activates the
-    device (e.g. by opening the lid or turning the vehicle or television back on).
\ No newline at end of file
+    part of the device or turning off a vehicle or television) and before the
+    user re-activates the device (e.g. by opening the lid or turning the vehicle
+    or television back on).
+
+If device implementations implement S3 power states as defined by the
+ACPI, they:
+
+*   [C-2-1] MUST meet C-1-1 above, or, MUST enter S3 state only when third-party
+    applications do not need the system resources (e.g. the screen, CPU).
+
+    Conversely, MUST exit from S3 state when third-party applications need the
+    system resources, as described on this SDK.
+
+    For example, while the third party applications request to keep the screen
+    on through `FLAG_KEEP_SCREEN_ON` or keep CPU running through
+    `PARTIAL_WAKE_LOCK`, the device MUST NOT enter S3 state unless, as described
+    in C-1-1, the user has taken explicit action to put the device in an
+    inactive state. Conversely, at a time when a task that third party apps
+    implement through JobScheduler is triggered or Firebase Cloud Messaging is
+    delivered to third party apps, the device MUST exit the S3 state unless the
+    user has put the device in an inactive state. These are not comprehensive
+    examples and AOSP implements extensive wake-up signals that trigger a wakeup
+    from this state.
diff --git a/8_performance-and-power/8_4_power-consumption-accounting.md b/8_performance-and-power/8_4_power-consumption-accounting.md
index 0e688fe..6afd1a6 100644
--- a/8_performance-and-power/8_4_power-consumption-accounting.md
+++ b/8_performance-and-power/8_4_power-consumption-accounting.md
@@ -23,6 +23,3 @@
 shell command to the app developer.
 *   SHOULD be attributed to the hardware component itself if unable to
 attribute hardware component power usage to an application.
-
-
-
diff --git a/8_performance-and-power/8_5_consistent-performance.md b/8_performance-and-power/8_5_consistent-performance.md
index e9101a0..05524e8 100644
--- a/8_performance-and-power/8_5_consistent-performance.md
+++ b/8_performance-and-power/8_5_consistent-performance.md
@@ -43,4 +43,4 @@
 *    [C-3-1] MUST return an empty list through the
 [`Process.getExclusiveCores()`](
 https://developer.android.com/reference/android/os/Process.html#getExclusiveCores%28%29)
-     API method.
\ No newline at end of file
+     API method.
diff --git a/9_security-model/9_10_device-integrity.md b/9_security-model/9_10_device-integrity.md
index 077514f..4a0a214 100644
--- a/9_security-model/9_10_device-integrity.md
+++ b/9_security-model/9_10_device-integrity.md
@@ -1,6 +1,6 @@
 ## 9.10\. Device Integrity
 
-The following requirements ensures there is transparancy to the status of the
+The following requirements ensure there is transparency to the status of the
 device integrity. Device implementations:
 
 *    [C-0-1] MUST correctly report through the System API method
@@ -48,7 +48,7 @@
 (e.g. boot, system partitions) and use tamper-evident storage for storing the
 metadata used for determining the minimum allowable OS version.
 *    [C-SR] Are STRONGLY RECOMMENDED to verify all privileged app APK files with
-a chain of trust rooted in `/system`, which is protected by Verified Boot.
+a chain of trust rooted in partitions protected by Verified Boot.
 *    [C-SR] Are STRONGLY RECOMMENDED to verify any executable artifacts loaded by
 a privileged app from outside its APK file (such as dynamically loaded code or
 compiled code) before executing them or STRONGLY RECOMMENDED not to execute them
@@ -79,8 +79,11 @@
 *    [C-3-1] MUST report `true` for the [`ConfirmationPrompt.isSupported()`](
 https://developer.android.com/reference/android/security/ConfirmationPrompt.html#isSupported%28android.content.Context%29)
 API.
-*    [C-3-2] MUST ensure that secure hardware takes full control of display in
-such a way that Android OS cannot block it without detection by the
-secure hardware.
-*    [C-3-3] MUST ensure that secure hardware takes full control of the touch
-screen.
\ No newline at end of file
+
+*    [C-3-2] MUST ensure that code running in the Android OS including its
+     kernel, malicious or otherwise, cannot generate a positive response without
+     user interaction.
+
+*    [C-3-3] MUST ensure that the user has been able to review and approve the
+     prompted message even in the event that the Android OS, including its kernel,
+     is compromised.
diff --git a/9_security-model/9_11_keys-and-credentials.md b/9_security-model/9_11_keys-and-credentials.md
index ac91c15..fe42b8f 100644
--- a/9_security-model/9_11_keys-and-credentials.md
+++ b/9_security-model/9_11_keys-and-credentials.md
@@ -40,9 +40,6 @@
 requirement is to share the same attestation key unless at least 100,000 units
 of a given SKU are produced. If more than 100,000 units of an SKU are produced,
 a different key MAY be used for each 100,000 units.
-*    [C-1-5] MUST allow the user to choose the Sleep timeout for transition from
-     the unlocked to the locked state, with a minimum allowable timout up to
-     15 seconds.
 
 Note that if a device implementation is already launched on an earlier Android
 version, such a device is exempted from the requirement to have a keystore
@@ -50,7 +47,11 @@
 unless it declares the `android.hardware.fingerprint` feature which requires a
 keystore backed by an isolated execution environment.
 
-### 9.11.1\. Secure Lock Screen
+*    [C-1-5] MUST allow the user to choose the Sleep timeout for transition from
+     the unlocked to the locked state, with a minimum allowable timeout up to
+     15 seconds.
+
+### 9.11.1\. Secure Lock Screen and Authentication
 
 The AOSP implementation follows a tiered authentication model where a
 knowledge-factory based primary authentication can be backed by either a
@@ -100,58 +101,32 @@
      https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordQuality%28android.content.ComponentName,%20int%29)
      method with a more restrictive quality constant than
     `PASSWORD_QUALITY_SOMETHING`.
+*    [C-3-5] New authentication methods MUST either fall back to the
+     recommended primary authentication methods (i.e. PIN, pattern,
+     password) once every 72 hours or less OR clearly disclose to the
+     user that some data will not be backed up in order to preserve
+     the privacy of their data.
 
 If device implementations add or modify the recommended primary authentication
 methods to unlock the lock screen and use a new authentication method that is
 based on biometrics to be treated as a secure way to lock the screen, the new
 method:
 
-*    [C-4-1] MUST meet all requirements described in
-     [section 7.3.10.2](#7_3_10_2_other_biometric_sensors).
+*    [C-4-1] MUST meet all requirements described in [section
+     7.3.10](#7_3_10_biometric_sensors) for **Convenience**.
 *    [C-4-2] MUST have a fall-back mechanism to use one of the recommended
      primary authentication methods which is based on a known secret.
 *    [C-4-3] MUST be disabled and only allow the recommended primary
      authentication to unlock the screen when the Device Policy Controller (DPC)
-     application has set the keguard feature policy by calling the method
+     application has set the keyguard feature policy by calling the method
      [`DevicePolicyManager.setKeyguardDisabledFeatures()`](
      http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setKeyguardDisabledFeatures%28android.content.ComponentName,%20int%29)
      , with any of the associated biometric flags (i.e.
      `KEYGUARD_DISABLE_BIOMETRICS`, `KEYGUARD_DISABLE_FINGERPRINT`,
      `KEYGUARD_DISABLE_FACE`, or `KEYGUARD_DISABLE_IRIS`).
-*    [C-4-4] MUST challenge the user for the recommended primary authentication
-     (e.g. PIN, pattern, password) at least once very 72 hours or less.
-*    [C-4-5] MUST have a false acceptance rate that is equal or stronger than
-     what is required for a fingerprint sensor as described in section
-     [section 7.3.10](#7_3_10_biometric_sensors),
-     or otherwise
-     MUST be disabled and only allow the recommended primary authentication
-     to unlock the screen when the Device Policy Controller (DPC) application
-     has set the password quality policy via the
-    [`DevicePolicyManager.setPasswordQuality()`](
-    https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html\#setPasswordQuality%28android.content.ComponentName,%20int%29)
-    method with a more restrictive quality constant than
-   `PASSWORD_QUALITY_BIOMETRIC_WEAK`.
-*    [C-SR] Are STRONGLY RECOMMENDED to have spoof and imposter acceptance rates
-     that are equal to or stronger than what is required for a fingerprint
-     sensor as described in [section 7.3.10](#7_3_10_biometric_sensors).
-*    [C-4-6] MUST have a secure processing pipeline such that an operating
-     system or kernel compromise cannot allow data to be directly injected to
-     falsely authenticate as the user.
-*    [C-4-7] MUST be paired with an explicit confirm action (eg: a button press)
-     to allow access to keystore keys if the application sets `true` for
-     [`KeyGenParameterSpec.Built.setUserAuthenticationRequired()`](
-     https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired%28boolean%29)
-     and the biometric is passive (e.g. face or iris where no explicit
-     signal of intent exists).
-*    [C-SR] The confirm action for passive biometrics is STRONGLY RECOMMENDED to
-     be secured such that an operating system or kernel compromise cannot spoof
-     it. For example, this means that the confirm action based on a physical
-     button is routed through an input-only general-purpose input/output (GPIO)
-     pin of a secure element (SE) that cannot be driven by any other means
-     than a physical button press.
 
-If the biometric authentication methods do not meet the spoof and imposter
-acceptance rates as described in [section 7.3.10](#7_3_10_biometric_sensors):
+If the biometric authentication methods do not meet the requirements
+for **Strong** as described in [section 7.3.10](#7_3_10_biometric_sensors):
 
 *    [C-5-1] The methods MUST be disabled if the Device Policy Controller (DPC)
      application has set the password quality policy via the [`DevicePolicyManager.setPasswordQuality()`](
@@ -184,7 +159,7 @@
      method with a more restrictive quality constant than
      `PASSWORD_QUALITY_UNSPECIFIED`.
 *    [C-6-3] The user MUST be challenged for one of the recommended primary
-     authentication methods (e.g.PIN, pattern, password) at least once every 72
+     authentication methods (e.g.PIN, pattern, password) at least once every 4
      hours or less.
 *    [C-6-4] The new method MUST NOT be treated as a secure lock screen and MUST
      follow the constraints listed in C-8 below.
@@ -209,9 +184,9 @@
      Automotive device).
 *    [C-7-4] MUST encrypt all stored tokens added by
      `TrustAgentService.addEscrowToken()`.
-*    [C-7-5] MUST NOT store the encryption key on the same device where the key
-     is used. For example, it is allowed for a key stored on a phone to unlock a
-     user account on a TV.
+*    [C-7-5] MUST NOT store the encryption key or escrow token on the
+     same device where the key is used. For example, it is allowed for
+     a key stored on a phone to unlock a user account on a TV.
 *    [C-7-6] MUST inform the user about the security implications before
      enabling the escrow token to decrypt the data storage.
 *    [C-7-7] MUST have a fall-back mechanism to use one of the recommended
@@ -225,6 +200,14 @@
      confirmation of the device credentials.
 *    [C-7-10] MUST NOT be treated as a secure lock screen and MUST follow the
      constraints listed in C-8 below.
+*    [C-7-11] MUST NOT allow TrustAgents on primary personal devices
+     (e.g: handheld) to unlock the device, and can only use them to
+     keep an already unlocked device in the unlocked state for up to a
+     maximum of 4 hours. The default implementation of
+     TrustManagerService in AOSP meets this requirement.
+*    [C-7-12] MUST use a cryptographically secure (e.g UKEY2)
+     communication channel to pass the escrow token from the storage
+     device to the target device.
 
 If device implementations add or modify the authentication methods to unlock
 the lock screen that is not a secure lock screen as described above, and use
@@ -239,21 +222,23 @@
 *    [C-8-2] They MUST NOT reset the password expiration timers set by
      [`DevicePolicyManager.setPasswordExpirationTimeout()`](
      http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordExpirationTimeout%28android.content.ComponentName,%20long%29).
-*    [C-8-3] They MUST NOT authenticate access to keystores when the application
-     sets `true` for
-     [`KeyGenParameterSpec.Builder.setUserAuthenticationRequired()`](
-     https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired%28boolean%29)).
+*    [C-8-3] They MUST NOT expose an API for use by third-party apps to
+     determine the lock state.
 
 ### 9.11.2\. StrongBox
 
 The [Android Keystore System](
 https://developer.android.com/training/articles/keystore.html) allows
 app developers to store cryptographic keys in a dedicated secure processor as
-well as the isolated execution environment described above.
+well as the isolated execution environment described above.  Such a
+dedicated secure processor is called "StrongBox".  Requirements C-1-3
+through C-1-11 below define the requirements a device must meet to
+qualify as a StrongBox.
 
-Device implementations:
+Device implementations that have a dedicated secure processor:
 
-*    [C-SR] Are STRONGLY RECOMMENDED to support StrongBox.
+*    [C-SR] Are STRONGLY RECOMMENDED to support StrongBox. StrongBox will
+     likely become a requirement in a future release.
 
 If device implementations support StrongBox, they:
 
@@ -261,7 +246,8 @@
 https://developer.android.com/reference/kotlin/android/content/pm/PackageManager#FEATURE_STRONGBOX_KEYSTORE%3Akotlin.String).
 
 *    [C-1-2] MUST provide dedicated secure hardware that is used to back
-keystore and secure user authentication.
+keystore and secure user authentication.  The dedicated secure
+hardware may be used for other purposes as well.
 
 *    [C-1-3] MUST have a discrete CPU that shares no cache, DRAM, coprocessors
 or other core resources with the application processor (AP).
diff --git a/9_security-model/9_12_data-deletion.md b/9_security-model/9_12_data-deletion.md
index 43c9caa..9ae130e 100644
--- a/9_security-model/9_12_data-deletion.md
+++ b/9_security-model/9_12_data-deletion.md
@@ -3,11 +3,7 @@
 All device implementations:
 
 *   [C-0-1] MUST provide users a mechanism to perform a "Factory Data Reset".
-*   [C-0-2] MUST delete all generated data. That is, all data except for
-    the following:
-     *    The system image
-     *    Any operating system files required by the system image that are on
-          read-only filesystems
+*   [C-0-2] MUST delete all data on the userdata filesystem.
 *   [C-0-3] MUST delete the data in such a way that will satisfy relevant
     industry standards such as NIST SP800-88\.
 *   [C-0-4] MUST trigger the above "Factory Data Reset" process when the
diff --git a/9_security-model/9_14_automotive-system-isolation.md b/9_security-model/9_14_automotive-system-isolation.md
index 046ebd4..164bc73 100644
--- a/9_security-model/9_14_automotive-system-isolation.md
+++ b/9_security-model/9_14_automotive-system-isolation.md
@@ -7,4 +7,3 @@
 The data exchange can be secured by implementing security features below the
 Android framework layers to prevent malicious or unintentional interaction with
 these subsystems.
-
diff --git a/9_security-model/9_1_permissions.md b/9_security-model/9_1_permissions.md
index 30bc5a9..75ccf99 100644
--- a/9_security-model/9_1_permissions.md
+++ b/9_security-model/9_1_permissions.md
@@ -47,6 +47,47 @@
      https://developer.android.com/preview/features/security/ckv-whitepaper.html)
      to prevent brute-force attacks on the lockscreen knowledge factor.
 
+Device implementations:
+
+*   [C-0-7] MUST adhere to [Android location permission](
+    https://developer.android.com/privacy/device-location) properties when an app
+    requests the location or physical activity data through standard Android API
+    or proprietary mechanism. Such data includes but not limited to:
+
+    *  Device's location (e.g. latitude and longitude).
+    *  Information that can be used to determine or estimate the device's
+       location (e.g. SSID, BSSID, Cell ID, or location of the network that the
+       device is connected to).
+    *  User's physical activity or classification of the physical activity.
+
+More specifically, device implementations:
+
+        *   [C-0-8] MUST obtain user consent to allow an app to access the
+            location or physical activity data.
+        *   [C-0-9] MUST grant a runtime permission ONLY to the app that holds
+            sufficient permission as described on SDK.
+            For example,
+[TelephonyManager#getServiceState](https://developer.android.com/reference/android/telephony/TelephonyManager.html#getAllCellInfo())
+            requires `android.permission.ACCESS_FINE_LOCATION`).
+
+Permissions can be marked as restricted altering their behavior.
+
+*   [C-0-10] Permissions marked with the flag `hardRestricted` MUST NOT be
+     granted to an app unless:
+     *   An app APK file is in the system partition.
+     *   The user assigns a role that is associated with the `hardRestricted`
+         permissions to an app.
+     *   The installer grants the `hardRestricted` to an app.
+     *   An app is granted the `hardRestricted` on an earlier Android version.
+
+*   [C-0-11] Apps holding a `softRestricted` permission MUST get only limited
+    access and MUST NOT gain full access until whitelisted as described in the
+    SDK, where full and limited access is defined for each `softRestricted`
+    permission (for example, [`WRITE_EXTERNAL_STORAGE`](
+    https://developer.android.com/reference/android/Manifest.permission.html#WRITE_EXTERNAL_STORAGE)
+    and [`READ_EXTERNAL_STORAGE`](
+    https://developer.android.com/reference/android/Manifest.permission#READ_EXTERNAL_STORAGE)).
+
 If device implementations include a pre-installed app or wish to allow
 third-party apps to access the usage statistics, they:
 
diff --git a/9_security-model/9_4_alternate-execution-environments.md b/9_security-model/9_4_alternate-execution-environments.md
index c762598..6349003 100644
--- a/9_security-model/9_4_alternate-execution-environments.md
+++ b/9_security-model/9_4_alternate-execution-environments.md
@@ -49,4 +49,4 @@
 separate Android sandboxes (Linux user IDs, etc.).
 
 *    Alternate runtimes MAY provide a single Android sandbox shared by all
-applications using the alternate runtime.
\ No newline at end of file
+applications using the alternate runtime.
diff --git a/9_security-model/9_5_multi-user-support.md b/9_security-model/9_5_multi-user-support.md
index d266b0c..d971f4d 100644
--- a/9_security-model/9_5_multi-user-support.md
+++ b/9_security-model/9_5_multi-user-support.md
@@ -47,4 +47,3 @@
 *   [C-3-1] MUST NOT support restricted profiles but MUST align with the AOSP
 implementation of controls to enable /disable other users from accessing the
 voice calls and SMS.
-
diff --git a/9_security-model/9_7_security-features.md b/9_security-model/9_7_security-features.md
index c7d743e..4322158 100644
--- a/9_security-model/9_7_security-features.md
+++ b/9_security-model/9_7_security-features.md
@@ -50,18 +50,32 @@
 kernel outside of normal usercopy access APIs (e.g. hardware PAN, or
 emulated via `CONFIG_CPU_SW_DOMAIN_PAN` or `CONFIG_ARM64_SW_TTBR0_PAN`)
 on devices originally shipping with API level 28 or higher.
-*   [C-0-12] MUST implement kernel page table isolation on all devices
-originally shipping with API level 28 or higher
-(e.g. `CONFIG_PAGE_TABLE_ISOLATION` or `CONFIG_UNMAP_KERNEL_AT_EL0).
+*   [C-0-12] MUST implement kernel page table isolation if the hardware is
+vulnerable to CVE-2017-5754 on all devices originally shipping with API level
+28 or higher (e.g. `CONFIG_PAGE_TABLE_ISOLATION` or
+`CONFIG_UNMAP_KERNEL_AT_EL0`).
+*   [C-0-13] MUST implement branch prediction hardening if the hardware is
+vulnerable to CVE-2017-5715 on all devices originally shipping with API level
+28 or higher (e.g. `CONFIG_HARDEN_BRANCH_PREDICTOR`).
 *   [SR] STRONGLY RECOMMENDED to keep kernel data
 which is written only during initialization marked read-only after
 initialization (e.g. `__ro_after_init`).
-*   [SR] STRONGLY RECOMMENDED to randomize the layout of the kernel code and
+*   [C-SR] Are STRONGLY RECOMMENDED to randomize the layout of the kernel code and
 memory, and to avoid exposures that would compromise the randomization
 (e.g. `CONFIG_RANDOMIZE_BASE` with bootloader entropy via the
 [`/chosen/kaslr-seed Device Tree node`](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/chosen.txt)
 or [`EFI_RNG_PROTOCOL`](https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/efi-rng-protocol)).
 
+*   [C-SR] Are STRONGLY RECOMMENDED to enable control flow integrity (CFI) in
+the kernel to provide additional protection against code-reuse attacks
+(e.g. `CONFIG_CFI_CLANG` and `CONFIG_SHADOW_CALL_STACK`).
+*   [C-SR] Are STRONGLY RECOMMENDED not to disable Control-Flow Integrity (CFI),
+Shadow Call Stack (SCS) or Integer Overflow Sanitization (IntSan) on
+components that have it enabled.
+*   [C-SR] Are STRONGLY RECOMMENDED to enable CFI, SCS, and IntSan for any
+additional security-sensitive userspace components as explained in
+[CFI](https://source.android.com/devices/tech/debug/cfi) and
+[IntSan](https://source.android.com/devices/tech/debug/intsan).
 
 If device implementations use a Linux kernel, they:
 
@@ -86,15 +100,5 @@
 *   [C-2-1] MUST use an mandatory access control system that is
 equivalent to SELinux.
 
-Android contains mutiple defense-in-depth features that are integral to device
+Android contains multiple defense-in-depth features that are integral to device
 security.
-
-Device implementations:
-
-*    [C-SR] Are STRONGLY RECOMMENDED not to disable Control-Flow Integrity (CFI)
-     or Integer Overflow Sanitization (IntSan) on components that have it
-     enabled.
-*    [C-SR] Are STRONGLY RECOMMENDED to enable both CFI and IntSan for any
-     additional security-sensitive userspace components as explained in
-     [CFI](https://source.android.com/devices/tech/debug/cfi) and
-     [IntSan](https://source.android.com/devices/tech/debug/intsan).
diff --git a/9_security-model/9_8_privacy.md b/9_security-model/9_8_privacy.md
index 61a9b5f..814fb4c 100644
--- a/9_security-model/9_8_privacy.md
+++ b/9_security-model/9_8_privacy.md
@@ -30,18 +30,29 @@
 
 *   [C-0-1] MUST NOT preload or distribute software components out-of-box that
     send the user's private information (e.g. keystrokes, text displayed on the
-    screen) off the device without the user's consent or clear ongoing
-    notifications.
+    screen, bugreport) off the device without the user's consent or clear
+    ongoing notifications.
+*   [C-0-2] MUST display and obtain explicit user consent that includes exactly
+    the same message as AOSP whenever screen casting or screen recording is
+    enabled via [`MediaProjection`](https://developer.android.com/reference/android/media/projection/MediaProjection)
+    or proprietary APIs. MUST NOT provide users an affordance to
+    disable future display of the user consent.
+*   [C-0-3] MUST have an ongoing notification to the user while screen casting
+    or screen recording is enabled. AOSP meets this requirement by showing an
+    ongoing notification icon in the status bar.
 
-If device implementations include functionality in the system that captures
-the contents displayed on the screen and/or records the audio stream played
-on the device, they:
+If device implementations include functionality in the system that either
+captures the contents displayed on the screen and/or records the audio stream
+played on the device other than via the System API `ContentCaptureService`, or
+other proprietary means described in
+[Section 9.8.6 Content Capture](#9_8_6_content_capture), they:
 
 *   [C-1-1] MUST have an ongoing notification to the user whenever this
     functionality is enabled and actively capturing/recording.
 
 If device implementations include a component enabled out-of-box, capable of
-recording ambient audio to infer useful information about user’s context, they:
+recording ambient audio and/or record the audio played on the device
+to infer useful information about user’s context, they:
 
 *   [C-2-1] MUST NOT store in persistent on-device storage or transmit off the
     device the recorded raw audio or any format that can be converted back into
@@ -61,8 +72,7 @@
 Device implementations:
 
 *   [C-0-1] MUST preinstall the same root certificates for the system-trusted
-    Certificate Authority (CA) store as [provided](
-    https://source.android.com/security/overview/app-security.html#certificate-authorities)
+    Certificate Authority (CA) store as [provided](https://source.android.com/security/overview/app-security.html#certificate-authorities)
     in the upstream Android Open Source Project.
 *   [C-0-2] MUST ship with an empty user root CA store.
 *   [C-0-3] MUST display a warning to the user indicating the network traffic
@@ -81,8 +91,7 @@
 
 *    [C-2-1] MUST ask for the user's consent before enabling that mechanism,
      unless that VPN is enabled by the Device Policy Controller via the
-     [`DevicePolicyManager.setAlwaysOnVpnPackage()`](
-     https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setAlwaysOnVpnPackage%28android.content.ComponentName, java.lang.String, boolean%29)
+     [`DevicePolicyManager.setAlwaysOnVpnPackage()`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setAlwaysOnVpnPackage%28android.content.ComponentName, java.lang.String, boolean%29)
      , in which case the user does not need to provide a separate consent, but
      MUST only be notified.
 
@@ -91,6 +100,111 @@
 
 *    [C-3-1] MUST disable this user affordance for apps that do not support
      always-on VPN service in the `AndroidManifest.xml` file via setting the
-     [`SERVICE_META_DATA_SUPPORTS_ALWAYS_ON`](
-     https://developer.android.com/reference/android/net/VpnService.html#SERVICE_META_DATA_SUPPORTS_ALWAYS_ON)
+     [`SERVICE_META_DATA_SUPPORTS_ALWAYS_ON`](https://developer.android.com/reference/android/net/VpnService.html#SERVICE_META_DATA_SUPPORTS_ALWAYS_ON)
      attribute to `false`.
+
+### 9.8.5\. Device Identifiers
+
+Device implementations:
+
+*   [C-0-1] MUST prevent access to the device serial number and, where
+    applicable, IMEI/MEID, SIM serial number, and International Mobile
+    Subscriber Identity (IMSI) from an app, unless it meets one of the following
+    requirements:
+    * is a signed carrier app that is verified by device manufacturers.
+    * has been granted the `READ_PRIVILEGED_PHONE_STATE` permission.
+    * has carrier privileges as defined in [`UICC Carrier Privileges`](https://source.android.com/devices/tech/config/uicc).
+    * is a device owner or profile owner that has been granted the
+      `READ_PHONE_STATE` permission.
+
+### 9.8.6\. Content Capture
+
+Android, through the System API `ContentCaptureService`, or by other proprietary
+means, supports a mechanism for device implementations to capture the
+following interactions between the applications and the user.
+
+*    Text and graphics rendered on-screen, including but not limited to,
+     notifications and assist data via [`AssistStructure`](
+     https://developer.android.com/reference/android/app/assist/AssistStructure)
+     API.
+*    Media data, such as audio or video, recorded or played by the device.
+*    Input events (e.g. key, mouse, gesture, voice, video, and accessibility).
+*    Any other events that an application provides to the system via the
+     [`Content Capture`](
+     https://developer.android.com/reference/android/view/contentcapture/package-summary)
+     API or a similarly capable, proprietary API.
+
+If device implementations capture the data above, they:
+
+*    [C-0-1] MUST encrypt all such data when stored in the device. This
+     encryption MAY be carried out using Android File Based Encryption, or any
+     of the ciphers listed as API version 26+ described in [Cipher SDK](
+     https://developer.android.com/reference/javax/crypto/Cipher).
+*    [C-0-2] MUST NOT back up either raw or encrypted data using
+     [Android backup methods](
+     https://developer.android.com/guide/topics/data/backup) or any other back
+     up methods.
+*    [C-0-3] MUST only send all such data and the log of the device using a
+     privacy-preserving mechanism. The privacy-preserving mechanism
+     is defined as “those which allow only analysis in aggregate and prevent
+     matching of logged events or derived outcomes to individual users”, to
+     prevent any per-user data being introspectable (e.g., implemented using
+     a differential privacy technology such as [`RAPPOR`](
+     https://github.com/google/rappor)).
+*    [C-0-4] MUST NOT associate such data with any user identity (such
+     as [`Account`](https://developer.android.com/reference/android/accounts/Account))
+     on the device, except with explicit user consent each time the data is
+     associated.
+*    [C-0-5] MUST NOT share such data with other apps, except with
+     explicit user consent every time it is shared.
+*    [C-0-6] MUST provide user affordance to erase such data that
+     the `ContentCaptureService` or the proprietary means collects if the
+     data is stored in any form on the device.
+
+If device implementations include a service that implements the System API
+`ContentCaptureService`, or any proprietary service that captures the data
+as described as above, they:
+
+*    [C-1-1] MUST NOT allow users to replace the content capture service with a
+     user-installable application or service and MUST only allow the preloaded
+     service to capture such data.
+*    [C-1-2] MUST NOT allow any apps other than the preloaded content capture
+     service mechanism to be able to capture such data.
+*    [C-1-3] MUST provide user affordance to disable the content capture
+     service.
+*    [C-1-4] MUST NOT omit user affordance to manage Android permissions that
+     are held by the content capture service and follow Android permissions
+     model as described in [Section 9.1. Permission](#9_1_permissions.md).
+*    [C-SR] Are STRONGLY RECOMMENDED to keep the content capturing service
+     components separate, for example, not binding the service or sharing process
+     IDs, from other system components except for the following:
+
+     *    Telephony, Contacts, System UI, and Media
+
+### 9.8.7\. Clipboard Access
+
+Device implementations:
+
+  * [C-0-1] MUST NOT return a clipped data on the clipboard (e.g. via the
+    [`ClipboardManager`](
+    https://developer.android.com/reference/android/content/ClipboardManager)
+    API) unless the app is the default IME or is the app that currently has
+    focus.
+
+### 9.8.8\. Location
+
+Device implementations:
+
+*   [C-0-1] MUST NOT turn on/off device location setting and Wi-Fi/Bluetooth
+scanning settings without explicit user consent or user initiation.
+*   [C-0-2] MUST provide the user affordance to access location related
+information including recent location requests, app level permissions and usage
+of Wi-Fi/Bluetooth scanning for determining location.
+*   [C-0-3] MUST ensure that the application using Emergency Location Bypass API
+[LocationRequest.setLocationSettingsIgnored()] is a user initiated emergency
+session (e.g. dial 911 or text to 911).
+*   [C-0-4] MUST preserve the Emergency Location Bypass API's ability to
+bypass device location settings without changing the settings.
+*   [C-0-5] MUST schedule a notification that reminds the user after an app in
+the background has accessed their location using the
+[`ACCESS_BACKGROUND_LOCATION`] permission.
diff --git a/9_security-model/9_9_full-disk-encryption.md b/9_security-model/9_9_full-disk-encryption.md
index 60e39ba..ea2837a 100644
--- a/9_security-model/9_9_full-disk-encryption.md
+++ b/9_security-model/9_9_full-disk-encryption.md
@@ -1,27 +1,10 @@
 ## 9.9\. Data Storage Encryption
 
-If Advanced Encryption Standard (AES) crypto performance, measured with the most
-performant AES technology available on the device (e.g. the ARM Cryptography
-Extensions), is above 50 MiB/sec, device implementations:
-
-*   [C-1-1] MUST support data storage encryption of the application private
-data (`/data` partition), as well as the application shared storage partition
-(`/sdcard` partition) if it is a permanent, non-removable part of the device,
-except for device implementations that are typically shared (e.g.
-Television).
-*   [C-1-2] MUST enable the data storage encryption by default at the time
-the user has completed the out-of-box setup experience, except for device
-implementations that are typically shared (e.g. Television).
-
-If device implementations are already launched on an earlier Android version
-and cannot meet the requirement through a system software update, they MAY be
-exempted from the above requirements.
-
-Device implementations:
-
-*    SHOULD meet the above data storage encryption
-requirement via implementing [File Based Encryption](
-https://source.android.com/security/encryption/file-based.html) (FBE).
+All devices MUST meet the requirements of section 9.9.1.
+Devices which launched on an API level earlier than that of this document are
+exempted from the requirements of sections 9.9.2 and 9.9.3; instead they
+MUST meet the requirements in section 9.9 of the Android Compatibility
+Definition document corresponding to the API level on which the device launched.
 
 ### 9.9.1\. Direct Boot
 
@@ -38,9 +21,22 @@
 Device Encrypted (DE) and Credential Encrypted (CE) storage locations are
 available for user.
 
-### 9.9.2\. File Based Encryption
+### 9.9.2\. Encryption requirements
 
-If device implementations support FBE, they:
+Device implementations:
+
+*   [C-0-1] MUST encrypt the application private
+data (`/data` partition), as well as the application shared storage partition
+(`/sdcard` partition) if it is a permanent, non-removable part of the device.
+*   [C-0-2] MUST enable the data storage encryption by default at the time
+the user has completed the out-of-box setup experience.
+*   [C-0-3] MUST meet the above data storage encryption
+requirement via implementing [File Based Encryption](
+https://source.android.com/security/encryption/file-based.html) (FBE).
+
+### 9.9.3\. File Based Encryption
+
+Encrypted devices:
 
 *    [C-1-1] MUST boot up without challenging the user for credentials and
 allow Direct Boot aware apps to access to the Device Encrypted (DE) storage
@@ -51,13 +47,20 @@
 message is broadcasted.
 *    [C-1-3] MUST NOT offer any method to unlock the CE protected storage
 without either the user-supplied credentials or a registered escrow key.
-*    [C-1-4] MUST support Verified Boot and ensure that DE keys are
+*    [C-1-4] MUST use Verified Boot and ensure that DE keys are
 cryptographically bound to the device's hardware root of trust.
-*    [C-1-5] MUST support encrypting file contents using AES-256-XTS.
-AES-256-XTS refers to the Advanced Encryption Standard with
-a 256-bit key length, operated in XTS mode.  The full length of the XTS key
-is 512 bits.
-*    [C-1-6] MUST support encrypting file names using AES-256 in CBC-CTS mode.
+*    [C-1-5] MUST encrypt file contents using AES-256-XTS or
+Adiantum.  AES-256-XTS refers to the Advanced Encryption Standard with a
+256-bit cipher key length, operated in XTS mode; the full length of the key
+is 512 bits.  Adiantum refers to Adiantum-XChaCha12-AES, as specified at
+https://github.com/google/adiantum.
+*    [C-1-6] MUST encrypt file names using AES-256-CBC-CTS
+or Adiantum.
+*    [C-1-12] MUST use AES-256-XTS for file contents and AES-256-CBC-CTS for
+file names (instead of Adiantum) if the device has Advanced Encryption Standard
+(AES) instructions.  AES instructions are ARMv8 Cryptography Extensions on
+ARM-based devices, or AES-NI on x86-based devices.  If the device does not
+have AES instructions, the device MAY use Adiantum.
 
 *   The keys protecting CE and DE storage areas:
 
@@ -67,42 +70,14 @@
 not specified lock screen credentials.
    *   [C-1-10] MUST be unique and distinct, in other words no user's CE or DE
    key matches any other user's CE or DE keys.
-
    *    [C-1-11] MUST use the mandatorily supported ciphers, key lengths and
-   modes by default.
+   modes.
 *    [C-SR] Are STRONGLY RECOMMENDED to encrypt file system metadata, such as
 file sizes, ownership, modes, and Extended attributes (xattrs), with a key
 cryptographically bound to the device's hardware root of trust.
 
 *    SHOULD make preloaded essential apps (e.g. Alarm, Phone, Messenger)
 Direct Boot aware.
-*    MAY support alternative ciphers, key lengths and modes for file content
-and file name encryption.
 
 The upstream Android Open Source project provides a preferred implementation of
-this feature based on the Linux kernel ext4 encryption feature.
-
-### 9.9.3\. Full Disk Encryption
-
-If device implementations support [full disk encryption](
-http://source.android.com/devices/tech/security/encryption/index.html)
-(FDE), they:
-
-*   [C-1-1] MUST use AES in a mode designed for storage (for example, XTS
-or CBC-ESSIV), and with a cipher key length of 128 bits or greater.
-*   [C-1-2] MUST use a default passcode to wrap the encryption key and
-MUST NOT write the encryption key to storage at any time
-without being encrypted.
-*   [C-1-3] MUST AES encrypt the encryption key by default unless the user
-   explicitly opts out, except when it is in active use, with the lock screen
-   credentials stretched using a slow stretching algorithm
-   (e.g. PBKDF2 or scrypt).
-*   [C-1-4] The above default password stretching algorithm MUST be
-cryptographically bound to that keystore when the user has not specified a lock
-screen credentials or has disabled use of the passcode for encryption and
-the device provides a hardware-backed keystore.
-*   [C-1-5] MUST NOT send encryption key off the device
-(even when wrapped with the user passcode and/or hardware bound key).
-
-The upstream Android Open Source project provides a preferred implementation
-of this feature, based on the Linux kernel feature dm-crypt.
+this feature based on the Linux kernel "fscrypt" encryption feature.
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..0fc495c
--- /dev/null
+++ b/README.md
@@ -0,0 +1 @@
+See instructions in cdd\_gen.sh
diff --git a/cdd_gen.sh b/cdd_gen.sh
index c133e3f..5d9d7dd 100755
--- a/cdd_gen.sh
+++ b/cdd_gen.sh
@@ -6,8 +6,11 @@
 #
 # where version is the version number and branch is the name of the AOSP branch.
 #
-# To run this script, you must install the jinja2 and wkhtmltopdf  packages
-# using the apt-get install command.
+# To run this script, you must install these packages as shown:
+#   sudo apt-get install wkhtmltopdf
+#   pip install Jinja2
+#   pip install markdown
+#   pip install pytidylib
 #
 
 POSITIONAL=()
diff --git a/make_cdd.py b/make_cdd.py
index 959d8ec..f2e143c 100755
--- a/make_cdd.py
+++ b/make_cdd.py
@@ -23,6 +23,7 @@
 
 
 HEADERS_FOR_TOC = ['h1', 'h2', 'h3', 'h4', 'h5', 'h6', 'h7']
+global ANDROID_VERSION
 ANDROID_VERSION = "7.0, (N)"
 TOC_PER_COL = 34
 
@@ -179,6 +180,7 @@
 
 def main():
   # Read version and branch info and output file name.
+  global ANDROID_VERSION
   (ANDROID_VERSION, CURRENT_BRANCH, output_filename) = get_version_branch_and_output()
 
   # Scan current directory for source files and compile info for the toc..