Merge "CDD: Clarify default dialer language" into pi-dev
diff --git a/2_device-types/2_2_handheld-reqs.md b/2_device-types/2_2_handheld-reqs.md
index e61222c..adea36c 100644
--- a/2_device-types/2_2_handheld-reqs.md
+++ b/2_device-types/2_2_handheld-reqs.md
@@ -26,6 +26,19 @@
 2.5 inches in physical diagonal size.
 *   [[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)
+
+If Handheld device implementations claim support for high dynamic range
+displays through [`Configuration.isScreenHdr()`
+](https://developer.android.com/reference/android/content/res/Configuration.html#isScreenHdr%28%29)
+, they:
+
+*   [[7.1](#7_1_display-and-graphics).4.5/H-1-1] MUST advertise support for the
+    `EGL_EXT_gl_colorspace_bt2020_pq`, `EGL_EXT_surface_SMPTE2086_metadata`,
+    `EGL_EXT_surface_CTA861_3_metadata`, `VK_EXT_swapchain_colorspace`, and
+    `VK_EXT_hdr_metadata` extensions.
+
+Handheld device implementations:
+
 *   [[7.1](#7_1_display-and-graphics).5/H-0-1] MUST include support for legacy
 application compatibility mode as implemented by the upstream Android open
 source code. That is, device implementations MUST NOT alter the triggers or
@@ -207,13 +220,26 @@
 
 Handheld device implementations:
 
+*   [[3.2.3.1](#3_2_3_1_core-application-intents)/H-0-1] MUST have an
+application that handles the [`ACTION_GET_CONTENT`](
+https://developer.android.com/reference/android/content/Intent.html#ACTION_GET_CONTENT),
+[`ACTION_OPEN_DOCUMENT`](
+https://developer.android.com/reference/android/content/Intent#ACTION_OPEN_DOCUMENT),
+[`ACTION_OPEN_DOCUMENT_TREE`](
+https://developer.android.com/reference/android/content/Intent.html#ACTION_OPEN_DOCUMENT_TREE),
+and [`ACTION_CREATE_DOCUMENT`](
+https://developer.android.com/reference/android/content/Intent.html#ACTION_CREATE_DOCUMENT)
+intents as described in the SDK documents, and provide the user affordance
+to access the document provider data by using [`DocumentsProvider`](
+https://developer.android.com/reference/android/provider/DocumentsProvider) API.
 *   [[3.4](#3_4_web-compatibility).1/H-0-1] MUST provide a complete
 implementation of the `android.webkit.Webview` API.
 *   [[3.4](#3_4_web-compatibility).2/H-0-1] MUST include a standalone Browser
 application for general user web browsing.
 *   [[3.8](#3_8_user-interface-compatibility).1/H-SR] Are STRONGLY RECOMMENDED
-to implement a default launcher that supports in-app pinning of shortcuts and
-widgets.
+to implement a default launcher that supports in-app pinning of shortcuts,
+widgets and [widgetFeatures](
+https://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html#widgetFeatures).
 *   [[3.8](#3_8_user-interface-compatibility).1/H-SR] Are STRONGLY RECOMMENDED
 to implement a default launcher that provides quick access to the additional
 shortcuts provided by third-party apps through the [ShortcutManager](
@@ -237,6 +263,19 @@
 notification shade, providing the user the ability to directly control (e.g.
 reply, snooze, dismiss, block) the notifications through user affordance such as
 action buttons or the control panel as implemented in the AOSP.
+*   [[3.8](#3_8_user-interface-compatibility).3/H-0-5] MUST display the choices
+provided through [`RemoteInput.Builder setChoices()`](
+https://developer.android.com/reference/android/app/RemoteInput.Builder.html#setChoices%28java.lang.CharSequence[]%29)
+in the notification shade.
+*   [[3.8](#3_8_user-interface-compatibility).3/H-SR] Are STRONGLY RECOMMENDED
+to display the first choice provided through [`RemoteInput.Builder setChoices()`](
+https://developer.android.com/reference/android/app/RemoteInput.Builder.html#setChoices%28java.lang.CharSequence[]%29)
+in the notification shade without additional user interaction.
+*   [[3.8](#3_8_user-interface-compatibility).3/H-SR] Are STRONGLY RECOMMENDED
+to display all the choices provided through [`RemoteInput.Builder setChoices()`](
+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).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).
@@ -252,6 +291,11 @@
 [device administration](
 http://developer.android.com/guide/topics/admin/device-admin.html)
 policies defined in the Android SDK documentation.
+*   [[3.9](#3_9_device-administration)/H-1-2]  MUST declare the support of
+managed profiles via the `android.software.managed_users` feature flag, except when the device is configured so that it would [report](
+http://developer.android.com/reference/android/app/ActivityManager.html#isLowRamDevice%28%29)
+itself as a low RAM device or so that it allocates internal (non-removable)
+storage as shared storage.
 
 Handheld device implementations:
 
@@ -341,4 +385,3 @@
 response to the [`android.settings.ACTION_USAGE_ACCESS_SETTINGS`](
 https://developer.android.com/reference/android/provider/Settings.html#ACTION_USAGE_ACCESS_SETTINGS)
 intent.
-
diff --git a/2_device-types/2_3_television-reqs.md b/2_device-types/2_3_television-reqs.md
index 0cf24ed..5ce2b20 100644
--- a/2_device-types/2_3_television-reqs.md
+++ b/2_device-types/2_3_television-reqs.md
@@ -1,4 +1,3 @@
-## 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,
@@ -50,6 +49,12 @@
 non-volatile storage available for application private data
 (a.k.a. "/data" partition).
 
+If Television device implementations include a USB port that supports host mode,
+they:
+
+*   [[7.5](#7_5_camera).3/T-1-1] MUST include support for an external camera
+that connects through this USB port but is not necessarily always connected.
+
 If TV device implementations are 32-bit:
 
 *   [[7.6](#7_6_memory-and-storage).1/T-1-1] The memory available to the kernel
@@ -148,27 +153,32 @@
 
 Television device implementations:
 
-*    [[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.
-
-If device implementations are Android Television devices and support 4K
-resolution, they:
-
-*    [[5.8](#5_8_secure-media)/T-1-1] MUST support HDCP 2.2 for all wired
-external displays.
-
-If Television device implementations don't support 4K resolution, they:
-
-*    [[5.8](#5_8_secure-media)/T-2-1] MUST support HDCP 1.4 for all wired
-external displays.
-
-Television device implementations:
-
 *   [[5.5](#5_5_audio-playback).3/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).
+*    [[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.
+*    [[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.
+*    [[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.
+
+If Television device implementations support UHD decoding and have support
+for external displays, 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:
+
+*    [[5.8](#5_8_secure-media)/T-2-1] MUST support HDCP 1.4
+
 
 
 ### 2.3.3\. Software
diff --git a/2_device-types/2_4_watch-reqs.md b/2_device-types/2_4_watch-reqs.md
index 6bfacc8..99468a9 100644
--- a/2_device-types/2_4_watch-reqs.md
+++ b/2_device-types/2_4_watch-reqs.md
@@ -78,3 +78,25 @@
 
 *   [[3.11](#3_11_text-to-speech)/W-0-1] MUST support installation of
 third-party TTS engines.
+
+### 2.4.4\. Performance and Power
+
+Watch device implementations:
+
+*    [[8.4](#8_4_power-consumption-accounting)/W-0-1] MUST provide a
+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)/W-0-2] MUST report all power
+consumption values in milliampere hours (mAh).
+*    [[8.4](#8_4_power-consumption-accounting)/W-0-3] MUST report CPU power
+consumption per each process's UID. The Android Open Source Project meets the
+requirement through the `uid_cputime` kernel module implementation.
+*   [[8.4](#8_4_power-consumption-accounting)/W-0-4] MUST make this power usage
+available via the [`adb shell dumpsys batterystats`](
+http://source.android.com/devices/tech/power/batterystats.html)
+shell command to the app developer.
+*   [[8.4](#8_4_power-consumption-accounting)/W] SHOULD be attributed to the
+hardware component itself if unable to attribute hardware component power usage
+to an application.
diff --git a/2_device-types/2_5_automotive-reqs.md b/2_device-types/2_5_automotive-reqs.md
index d529946..585eac1 100644
--- a/2_device-types/2_5_automotive-reqs.md
+++ b/2_device-types/2_5_automotive-reqs.md
@@ -55,7 +55,7 @@
 
 Automotive device implementations:
 
-*    [[7.3](#7_3_sensors).11/A] SHOULD provide current gear as
+*    [[7.3](#7_3_sensors).11/A-0-1] MUST provide current gear as
 `SENSOR_TYPE_GEAR`.
 
 Automotive device implementations:
@@ -68,16 +68,12 @@
 *    The underlying ambient light sensor MAY be the same as
 [Photometer](#7_3_7_photometer).
 
-*    [[7.3](#7_3_sensors).11.3/A-0-1] MUST support driving status defined as
-     `SENSOR_TYPE_DRIVING_STATUS`, with a default value of
-     `DRIVE_STATUS_UNRESTRICTED` when the vehicle is fully stopped and parked.
-     It is the responsibility of device manufacturers to configure
-     `SENSOR_TYPE_DRIVING_STATUS` in compliance with all laws and regulations
-     that apply to markets where the product is shipping.
-
-*    [[7.3](#7_3_sensors).11.4/A-0-1] MUST provide vehicle speed defined as
+*    [[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
@@ -86,16 +82,32 @@
      * Media playback over Audio Distribution Profile (A2DP).
      * Media playback control over Remote Control Profile (AVRCP).
      * Contact sharing using the Phone Book Access Profile (PBAP).
-*    [[7.4](#7_4_data-connectivity).3/A] SHOULD support Message Access Profile
-(MAP).
+*    [[7.4](#7_4_data-connectivity).3/A-SR] Are STRONGLY RECOMMENDED to support
+Message Access Profile (MAP).
 
 *   [[7.4](#7_4_data-connectivity).5/A] SHOULD include support for cellular
-network based data connectivity.
+network-based data connectivity.
+*   [[7.4](#7_4_data-connectivity).5/A] MAY use the System API
+`NetworkCapabilities#NET_CAPABILITY_OEM_PAID` constant for
+networks that should be available to system apps.
 
 *   [[7.6](#7_6_memory-and-storage).1/A-0-1] MUST have at least 4GB 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.
+
+If Automotive device implementations provide shared external storage via a
+portion of the internal non-removable storage, they:
+
+*   [[7.6](#7_6_memory-and-storage).1/A-SR] Are STRONGLY RECOMMENDED to reduce
+I/O overhead on operations performed on the external storage, for example by
+using `SDCardFS`.
+
 If Automotive device implementations are 32-bit:
 
 *   [[7.6](#7_6_memory-and-storage).1/A-1-1] The memory available to the kernel
@@ -213,8 +225,12 @@
 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 to handle the [Assist action](
-http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST).
+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.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.
@@ -251,12 +267,18 @@
 ### 2.2.5\. Security Model
 
 
-If Automotive device implementations include multiple users, they:
+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.
 
+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.
+
 Automotive device implementations:
 
 *   [[9.14](#9_14_automotive-system-isolation)/A-0-1] MUST gatekeep messages
diff --git a/3_software/3_12_tv-input-framework.md b/3_software/3_12_tv-input-framework.md
index 2e055f5..8051028 100644
--- a/3_software/3_12_tv-input-framework.md
+++ b/3_software/3_12_tv-input-framework.md
@@ -8,100 +8,6 @@
 If device implementations support TIF, they:
 
 *    [C-1-1] MUST declare the platform feature `android.software.live_tv`.
-*    [C-1-2] MUST preload a TV application (TV App) and meet all requirements
-     described in [section 3.12.1](#3_12_tv-input-framework).
-
-### 3.12.1\. TV App
-
-If device implementations support TIF:
-
-*    [C-1-1] The TV App MUST provide facilities to install and use [TV Channels](
-http://developer.android.com/reference/android/media/tv/TvContract.Channels.html)
-and meet the following requirements.
-
-The TV app that is required for Android device implementations declaring the
-`android.software.live_tv` feature flag, MUST meet the following requirements:
-
-*   Device implementations SHOULD allow third-party TIF-based inputs
-    ([third-party inputs](
-    https://source.android.com/devices/tv/index.html#third-party_input_example))
-    to be installed and managed.
-*   Device implementations MAY provide visual separation between pre-installed
-    [TIF-based inputs](
-    https://source.android.com/devices/tv/index.html#tv_inputs)
-    (installed inputs) and third-party inputs.
-*   Device implementations SHOULD NOT display the third-party inputs more than a
-    single navigation action away from the TV App (i.e. expanding a list of
-    third-party inputs from the TV App).
-
-The Android Open Source Project provides an implementation of the TV App that
-meets the above requirements.
-
-#### 3.12.1.1\. Electronic Program Guide
-
-If device implementations support TIF, they:
-
-*    [C-1-1] MUST show an informational and
-interactive overlay, which MUST include an electronic program guide (EPG)
-generated from the values in the [TvContract.Programs](
-https://developer.android.com/reference/android/media/tv/TvContract.Programs.html)
-fields.
-*   [C-1-2] On channel change, device implementations MUST display EPG data for
-    the currently playing program.
-*   [SR] The EPG is STRONGLY RECOMMENDED to display installed inputs and
-    third-party inputs with equal prominence. The EPG SHOULD NOT display the
-    third-party inputs more than a single navigation action away from the
-    installed inputs on the EPG.
-*   The EPG SHOULD display information from all installed inputs and third-party
-    inputs.
-*   The EPG MAY provide visual separation between the installed inputs and
-    third-party inputs.
-
-#### 3.12.1.2\. Navigation
-
-If device implementations support TIF, they:
-
-*    [C-1-1] MUST allow navigation for the following functions via
-the D-pad, Back, and Home keys on the Android Television device’s input
-device(s) (i.e. remote control, remote control application, or game controller):
-
-    *   Changing TV channels
-    *   Opening EPG
-    *   Configuring and tuning to third-party TIF-based inputs (if those inputs are supported)
-    *   Opening Settings menu
-
-*    SHOULD pass key events to HDMI inputs through CEC.
-
-#### 3.12.1.3\. TV input app linking
-
-If device implementations support TIF:
-
-*    [C-1-1] Android Television device implementations MUST support
-[TV input app linking](
-http://developer.android.com/reference/android/media/tv/TvContract.Channels.html#COLUMN_APP_LINK_INTENT_URI),
-which allows all inputs to provide activity links from the current activity to
-another activity (i.e. a link from live programming to related content). The TV
-App SHOULD show TV input app linking when it is provided.
-
-#### 3.12.1.4\. Time shifting
-
-If device implementations support TIF, they:
-
-*    [SR] STRONGLY RECOMMENDED to support time shifting, which allows the user
-to pause and resume live content.
-*    SHOULD provide the user a way to pause and resume the currently playing
-program, if time shifting for that program [is available](
-https://developer.android.com/reference/android/media/tv/TvInputManager.html#TIME_SHIFT_STATUS_AVAILABLE).
-
-#### 3.12.1.5\. TV recording
-
-If device implementations support TIF, they:
-
-*    [SR] STRONGLY RECOMMENDED to support TV recording.
-*    SHOULD provide a user interface to play recorded
-programs.
-*    If the TV input supports recording and the recording of a program is not
-[prohibited](
-https://developer.android.com/reference/android/media/tv/TvContract.Programs.html#COLUMN_RECORDING_PROHIBITED),
-the EPG MAY provide a way to [record a program](
-https://developer.android.com/reference/android/media/tv/TvInputInfo.html#canRecord%28%29).
+*    [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
diff --git a/3_software/3_14_media-ui.md b/3_software/3_14_media-ui.md
index 18d0f14..fb6d358 100644
--- a/3_software/3_14_media-ui.md
+++ b/3_software/3_14_media-ui.md
@@ -14,7 +14,9 @@
 *    [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 drawer to present [MediaBrowser](
+*    [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-5] MUST consider double tap of [`KEYCODE_HEADSETHOOK`](
diff --git a/3_software/3_1_managed-api-compatibility.md b/3_software/3_1_managed-api-compatibility.md
index 05b95c2..e969a98 100644
--- a/3_software/3_1_managed-api-compatibility.md
+++ b/3_software/3_1_managed-api-compatibility.md
@@ -33,3 +33,18 @@
 higher than or equal to the minimum versions allowed per each API level.
 For example, Android 7.0 device implementations, running API level 24 MUST
 include at least version 1.
+
+## 3.1.2\. Android Library
+
+Due to [Apache HTTP client deprecation](https://developer.android.com/preview/behavior-changes#apache-p),
+device implementations:
+
+*   [C-0-1] MUST NOT place the `org.apache.http.legacy` library in the
+bootclasspath.
+*   [C-0-2] MUST add the `org.apache.http.legacy` library to the application
+classpath only when the app satisfies one of the following conditions:
+    *    Targets API level 28 or lower.
+    *    Declares in its manifest that it needs the library by setting the
+    `android:name` attribute of `<uses-library>` to `org.apache.http.legacy`.
+
+The AOSP implementation meets these requirements.
\ No newline at end of file
diff --git a/3_software/3_2_soft-api-compatibility.md b/3_software/3_2_soft-api-compatibility.md
index 8bfa05b..68a9fcc 100644
--- a/3_software/3_2_soft-api-compatibility.md
+++ b/3_software/3_2_soft-api-compatibility.md
@@ -175,10 +175,7 @@
  </tr>
  <tr>
     <td>SERIAL</td>
-    <td>A hardware serial number, which MUST be available and unique across
-    devices with the same MODEL and MANUFACTURER. The value of this field MUST
-    be encodable as 7-bit ASCII and match the regular expression
-    &ldquo;^([a-zA-Z0-9]{6,20})$&rdquo;.</td>
+    <td>MUST return "UNKNOWN".</td>
  </tr>
  <tr>
     <td>TAGS</td>
@@ -237,6 +234,13 @@
     encodable as 7-bit ASCII and match the regular expression
     &ldquo;^[a-zA-Z0-9._-,]+$&rdquo;.</td>
  </tr>
+ <tr>
+    <td><a href="https://developer.android.com/reference/android/os/Build.html#getSerial()">getSerial()</a></td>
+    <td> MUST (be or return) a hardware serial number, which MUST be available
+    and unique across devices with the same MODEL and MANUFACTURER. The value of
+    this field MUST be encodable as 7-bit ASCII and match the regular expression
+    &ldquo;^[a-zA-Z0-9._-,]+$&rdquo;.</td>
+ </tr>
 </table>
 
 ### 3.2.3\. Intent Compatibility
diff --git a/3_software/3_3_native-api-compatibility.md b/3_software/3_3_native-api-compatibility.md
index c1e4f46..1fe7f37 100644
--- a/3_software/3_3_native-api-compatibility.md
+++ b/3_software/3_3_native-api-compatibility.md
@@ -78,8 +78,8 @@
     Note that while all the symbols MUST be present, section 7.1.4.1 describes
     in more detail the requirements for when the full implementation of each
     corresponding functions are expected.
-*   [C-0-12] MUST export function symbols for the core Vulkan 1.0 function
-    symobls, as well as the `VK_KHR_surface`, `VK_KHR_android_surface`,
+*   [C-0-12] MUST export function symbols for the core Vulkan 1.1 function
+    symbols, as well as the `VK_KHR_surface`, `VK_KHR_android_surface`,
     `VK_KHR_swapchain`, `VK_KHR_maintenance1`, and
     `VK_KHR_get_physical_device_properties2` extensions through the
     `libvulkan.so` library.  Note that while all the symbols MUST be present,
diff --git a/3_software/3_5_api-behavioral-compatibility.md b/3_software/3_5_api-behavioral-compatibility.md
index 0e5b9f9..1b3a18e 100644
--- a/3_software/3_5_api-behavioral-compatibility.md
+++ b/3_software/3_5_api-behavioral-compatibility.md
@@ -40,10 +40,30 @@
           task that's visible to the user.
      *    [C-0-8] if the app is targeting API level 25 or higher, they MUST
           release the wakelocks the app holds.
+*    [C-0-9] Devices MUST return the following security providers as the first
+     seven array values from the [`Security.getProviders()`](
+     https://developer.android.com/reference/java/security/Security.html#getProviders%28%29)
+     method, in the given order and with the given names (as returned by
+     [`Provider.getName()`](
+     https://developer.android.com/reference/java/security/Provider.html#getName%28%29))
+     and classes, unless the app has modified the list via
+     [`insertProviderAt()`](
+     https://developer.android.com/reference/java/security/Security.html#insertProviderAt%28java.security.Provider,%2520int%29)
+     or [`removeProvider()`](
+     https://developer.android.com/reference/java/security/Security.html#removeProvider%28java.lang.String%29). Devices
+     MAY return additional providers after the specified list of providers
+     below.
+     1. **AndroidNSSP** - `android.security.net.config.NetworkSecurityConfigProvider`
+     2. **AndroidOpenSSL** - `com.android.org.conscrypt.OpenSSLProvider`
+     3. **CertPathProvider** - `sun.security.provider.CertPathProvider`
+     4. **AndroidKeyStoreBCWorkaround** - `android.security.keystore.AndroidKeyStoreBCWorkaroundProvider`
+     5. **BC** - `com.android.org.bouncycastle.jce.provider.BouncyCastleProvider`
+     6. **HarmonyJSSE** - `com.android.org.conscrypt.JSSEProvider`
+     7. **AndroidKeyStore** - `android.security.keystore.AndroidKeyStoreProvider`
 
 The above list is not comprehensive. The Compatibility Test Suite (CTS) tests
 significant portions of the platform for behavioral compatibility, but not all.
 It is the responsibility of the implementer to ensure behavioral compatibility
 with the Android Open Source Project. For this reason, device implementers
 SHOULD use the source code available via the Android Open Source Project where
-possible, rather than re-implement significant parts of the system.
\ No newline at end of file
+possible, rather than re-implement significant parts of the system.
diff --git a/3_software/3_8_user-interface-compatibility.md b/3_software/3_8_user-interface-compatibility.md
index 9d0a5a1..9b26cfe 100644
--- a/3_software/3_8_user-interface-compatibility.md
+++ b/3_software/3_8_user-interface-compatibility.md
@@ -124,7 +124,7 @@
     further detailed in [section 7](#7_hardware_compatibility).
 *   [C-1-2]  MUST correctly render all [resources](
     https://developer.android.com/guide/topics/resources/available-resources.html)
-    (icons, animation files etc.) provided for in the APIs, or in the
+    (icons, animation files, etc.) provided for in the APIs, or in the
     Status/System Bar [icon style guide](
     http://developer.android.com/design/style/iconography.html), although they
     MAY provide an alternative user experience for notifications than that
@@ -140,6 +140,17 @@
     third-party app's notification per each channel and app package level.
 *   [C-1-6] MUST also provide a user affordance to display deleted notification
     channels.
+*   [C-1-7] MUST correctly render all resources (images, stickers, icons, etc.)
+    provided through [Notification.MessagingStyle](
+    https://developer.android.com/reference/android/app/Notification.MessagingStyle)
+    alongside the notification text without additional user interaction. For
+    example, MUST show all resources including icons provided through
+    [android.app.Person](https://developer.android.com/reference/android/app/Person)
+    in a group conversation that is set through [setGroupConversation](
+    https://developer.android.com/reference/android/app/Notification.MessagingStyle.html?hl=es-AR#setGroupConversation%28boolean%29).
+*   [C-SR] Are STRONGLY RECOMMENDED to automatically surface a user affordance
+    to block a certain third-party app's notification per each channel and app
+    package level after the user dismisses that notification multiple times.
 *   SHOULD support rich notifications.
 *   SHOULD present some higher priority notifications as heads-up notifications.
 *   SHOULD have a user affordance to snooze notifications.
@@ -163,6 +174,12 @@
     as described in the [`Notification.Builder`](
     https://developer.android.com/reference/android/app/Notification.Builder.html)
     API class when heads-up notifications are presented.
+*   [C-3-2] MUST display the actions provided through
+    [`Notification.Builder.addAction()`](
+    https://developer.android.com/reference/android/app/Notification.Builder#addAction%28android.app.Notification.Action%29)
+    together with the notification content without additional user interaction
+    as described in [the SDK](
+    https://developer.android.com/guide/topics/ui/notifiers/notifications.html#Heads-up).
 
 #### 3.8.3.2\. Notification Listener Service
 
@@ -532,3 +549,26 @@
     and minimum width of 240 dp and height of 135 dp for the PIP window when the
     `Configuration.uiMode` is configured as [`UI_MODE_TYPE_TELEVISION`](
     https://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_TELEVISION)
+
+
+### 3.8.15\. Display Cutout
+
+Android supports a Display Cutout as described
+in the SDK document. The [`DisplayCutout`](
+https://developer.android.com/reference/android/view/DisplayCutout) API defines
+an area on the edge of the display that is not functional for displaying
+content.
+
+If device implementations include display cutout(s), they:
+
+*   [C-1-1] MUST only have cutout(s) on the short edge(s) of the device.
+Conversely, if the device's aspect ratio is 1.0(1:1), they MUST NOT have
+cutout(s).
+*   [C-1-2] MUST NOT have more than one cutout per edge.
+*   [C-1-3] MUST honor the display cutout flags set by the app through the
+[`WindowManager.LayoutParams`](
+https://developer.android.com/reference/android/view/WindowManager.LayoutParams)
+API as described in the SDK.
+*   [C-1-4] MUST report correct values for all cutout metrics defined in the
+[`DisplayCutout`](
+https://developer.android.com/reference/android/view/DisplayCutout) API.
\ No newline at end of file
diff --git a/3_software/3_9_device-administration.md b/3_software/3_9_device-administration.md
index eb50d95..98f4030 100644
--- a/3_software/3_9_device-administration.md
+++ b/3_software/3_9_device-administration.md
@@ -13,12 +13,6 @@
 *   [C-1-2] MUST support device owner provisioning as described in
     [section 3.9.1](#3_9_1_device_provisioning) and
     [section 3.9.1.1](#3_9_1_1_device_owner_provisioning).
-*   [C-1-3] MUST declare the support of manged profiles via the
-    `android.software.managed_users` feature flag, except for when the device is
-    configured so that it would [report](
-    http://developer.android.com/reference/android/app/ActivityManager.html#isLowRamDevice%28%29)
-    itself as a low RAM device or so that it allocate internal (non-removable)
-    storage as shared storage.
 
 ### 3.9.1 Device Provisioning
 
@@ -42,9 +36,10 @@
         *    [C-1-6] MUST report `false` for the [`DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE)`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html\#isProvisioningAllowed\(java.lang.String\)).
         *    [C-1-7] MUST not enroll any DPC application as the Device Owner App
              any more.
-*   [C-1-2] MUST NOT set an application (including pre-installed app) as the
-    Device Owner app without explicit consent or action from the user or the
-    administrator of the device.
+*   [C-1-2] MUST require some affirmative action during the provisioning process
+to consent to the app being set as Device Owner. Consent can be via user action
+or by some programmatic means during provisioning but it MUST NOT be hard coded
+or prevent the use of other Device Owner apps.
 
 If device implementations declare `android.software.device_admin`, but also
 include a proprietary Device Owner management solution and provide a mechanism
diff --git a/4_application-packaging/4_0_intro.md b/4_application-packaging/4_0_intro.md
index 1a25035..208b098 100644
--- a/4_application-packaging/4_0_intro.md
+++ b/4_application-packaging/4_0_intro.md
@@ -8,9 +8,13 @@
 http://developer.android.com/tools/help/index.html).
    *   As the above requirement may be challenging, device implementations are
    RECOMMENDED to use the AOSP reference implementation's package management
-   systemDevice implementations.
+   system.
+
+Device implementations:
+
 *    [C-0-2] MUST support verifying “.apk” files using the
-[APK Signature Scheme v2](https://source.android.com/security/apksigning/v2.html)
+[APK Signature Scheme v3](https://source.android.com/security/apksigning/v3.html)
+, [APK Signature Scheme v2](https://source.android.com/security/apksigning/v2.html)
 and [JAR signing](
 https://source.android.com/security/apksigning/v2.html#v1-verification).
 *    [C-0-3] MUST NOT extend either the
@@ -22,7 +26,7 @@
 installing and running correctly on other compatible devices.
 *    [C-0-4] MUST NOT allow apps other than the current
 "installer of record" for the package to silently uninstall the app without any
-prompt, as documented in the SDK for the [`DELETE_PACKAGE`](
+user confirmation, as documented in the SDK for the [`DELETE_PACKAGE`](
 https://developer.android.com/reference/android/Manifest.permission.html#DELETE_PACKAGES)
 permission. The only exceptions are the system package verifier app handling
 [PACKAGE_NEEDS_VERIFICATION](
diff --git a/5_multimedia/5_10_professional-audio.md b/5_multimedia/5_10_professional-audio.md
index 607bd8c..4af9364 100644
--- a/5_multimedia/5_10_professional-audio.md
+++ b/5_multimedia/5_10_professional-audio.md
@@ -14,9 +14,11 @@
 *    [C-1-3] MUST include a USB port(s) supporting USB host mode and USB
 peripheral mode.
 *    [C-1-4] MUST report support for feature `android.software.midi`.
-*    [C-1-5] MUST meet latencies and USB audio requirements using the
+*    [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 API.
+PCM buffer queue and
+[AAudio native audio](https://developer.android.com/ndk/guides/audio/aaudio/aaudio.html)
+APIs.
 *    [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)
@@ -58,6 +60,8 @@
 and output sides of corresponding end-points.
 *    SHOULD minimize touch latency.
 *    SHOULD minimize touch latency variability under load (jitter).
+*    SHOULD have a latency from touch input to audio output of less than or
+equal to 40 ms.
 
 If device implementations meet all of the above requirements, they:
 
@@ -66,12 +70,6 @@
 http://developer.android.com/reference/android/content/pm/PackageManager.html)
 class.
 
-If device implementations meet the requirements via the OpenSL ES PCM buffer
-queue API, they:
-
-*    [SR] STRONGLY RECOMMENDED to also meet the same requirements via the
-[AAudio](https://developer.android.com/ndk/guides/audio/aaudio/aaudio.html) API.
-
 If device implementations include a 4 conductor 3.5mm audio jack, they:
 
 *   [C-2-1] MUST have the continuous round-trip audio latency to be 20
@@ -96,4 +94,5 @@
 If device implementations include an HDMI port, they:
 
 *   [C-4-1] MUST support output in stereo and eight channels at 20-bit or
-24-bit depth and 192 kHz without bit-depth loss or resampling.
\ No newline at end of file
+24-bit depth and 192 kHz without bit-depth loss or resampling,
+in at least one configuration.
diff --git a/5_multimedia/5_1_media-codecs.md b/5_multimedia/5_1_media-codecs.md
index 3b61db4..21d917a 100644
--- a/5_multimedia/5_1_media-codecs.md
+++ b/5_multimedia/5_1_media-codecs.md
@@ -16,13 +16,16 @@
 
 
 If device implementations declare support for the
-`android.hardware.audio.output` feature, they must support the following audio
-decoders:
+`android.hardware.audio.output` feature, they must support decoding the
+following audio formats:
 
 *    [C-1-1] MPEG-4 AAC Profile (AAC LC)
 *    [C-1-2] MPEG-4 HE AAC Profile (AAC+)
 *    [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)
 *    [C-1-5] FLAC
 *    [C-1-6] MP3
 *    [C-1-7] MIDI
@@ -42,10 +45,27 @@
 (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:
-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
+`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`
 
+When decoding USAC audio, MPEG-D (ISO/IEC 23003-4):
+
+*    [C-3-1] Loudness and DRC metadata MUST be interpreted and applied
+according to MPEG-D DRC Dynamic Range Control Profile Level 1.
+*    [C-3-2] The decoder MUST behave according to the configuration
+set with the following `android.media.MediaFormat` keys:
+`KEY_AAC_DRC_TARGET_REFERENCE_LEVEL` and `KEY_AAC_DRC_EFFECT_TYPE`.
+
+MPEG-4 AAC, HE AAC, and HE AACv2 profile decoders:
+
+*    MAY support loudness and dynamic range control using ISO/IEC 23003-4
+Dynamic Range Control Profile.
+
+If ISO/IEC 23003-4 is supported and if both ISO/IEC 23003-4 and
+ISO/IEC 14496-3 metadata are present in a decoded bitstream, then:
+
+*    ISO/IEC 23003-4 metadata SHALL take precedence.
 
 ### 5.1.3\. Audio Codecs Details
 
@@ -88,6 +108,17 @@
     <td></td>
  </tr>
  <tr>
+    <td>USAC</td>
+    <td>Support for mono/stereo content with standard sampling rates from 7.35
+    to 48 kHz.</td>
+    <td>
+    <ul>
+    <li>MPEG-4 (.mp4, .m4a)</li>
+    <li>LATM/LOAS (.loas, .xhe)</li>
+    </ul>
+    </td>
+ </tr>
+ <tr>
     <td>AMR-NB</td>
     <td>4.75 to 12.2 kbps sampled @ 8 kHz</td>
     <td>3GPP (.3gp)</td>
diff --git a/5_multimedia/5_5_audio-playback.md b/5_multimedia/5_5_audio-playback.md
index 5cca863..f510887 100644
--- a/5_multimedia/5_5_audio-playback.md
+++ b/5_multimedia/5_5_audio-playback.md
@@ -37,6 +37,8 @@
 AudioEffect subclasses `Equalizer`, `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
+controllable through the AudioEffect subclass [`DynamicsProcessing`](https://developer.android.com/reference/android/media/audiofx/DynamicsProcessing).
 *   SHOULD support the `EFFECT_TYPE_BASS_BOOST`, `EFFECT_TYPE_ENV_REVERB`,
 `EFFECT_TYPE_PRESET_REVERB`, and `EFFECT_TYPE_VIRTUALIZER` implementations
 controllable through the `AudioEffect` sub-classes `BassBoost`,
diff --git a/5_multimedia/5_6_audio-latency.md b/5_multimedia/5_6_audio-latency.md
index 7edea1e..81c236a 100644
--- a/5_multimedia/5_6_audio-latency.md
+++ b/5_multimedia/5_6_audio-latency.md
@@ -38,6 +38,10 @@
 *   **AAudio native audio API**. The set of
 [AAudio](https://developer.android.com/ndk/guides/audio/aaudio/aaudio.html) APIs
 within [Android NDK](https://developer.android.com/ndk/index.html).
+*   **Timestamp**. A pair consisting of a relative frame position within a
+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).
 
 If device implementations declare `android.hardware.audio.output` they are
 STRONGLY RECOMMENDED to meet or exceed the following requirements:
@@ -45,19 +49,22 @@
 *   [SR] Cold output latency of 100 milliseconds or less
 *   [SR] Continuous output latency of 45 milliseconds or less
 *   [SR] Minimize the cold output jitter
+*   [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.
 
-If device implementations meet the above requirements after any initial
-calibration when using the OpenSL ES PCM buffer queue API, for continuous output
-latency and cold output latency over at least one supported audio output device,
-they are:
+If device implementations meet the above requirements, after any initial
+calibration, when using both the OpenSL ES PCM buffer queue and AAudio native audio APIs,
+for continuous output latency and cold output latency over at least one supported audio
+output device, they are:
 
-*   [SR] STRONGLY RECOMMENDED to report low latency audio by declaring 
+*   [SR] STRONGLY RECOMMENDED to report low latency audio by declaring
 `android.hardware.audio.low_latency` feature flag.
 *   [SR] STRONGLY RECOMMENDED to also meet the requirements for low-latency
     audio via the AAudio API.
 
 If device implementations do not meet the requirements for low-latency audio
-via the OpenSL ES PCM buffer queue API, they:
+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.
 
@@ -67,4 +74,7 @@
    *   [SR] Cold input latency of 100 milliseconds or less
    *   [SR] Continuous input latency of 30 milliseconds or less
    *   [SR] Continuous round-trip latency of 50 milliseconds or less
-   *   [SR] Minimize the cold input jitter
\ No newline at end of file
+   *   [SR] Minimize the cold input jitter
+   *   [SR] 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 +/- 1 ms.
diff --git a/5_multimedia/5_8_secure-media.md b/5_multimedia/5_8_secure-media.md
index e75a775..7722d80 100644
--- a/5_multimedia/5_8_secure-media.md
+++ b/5_multimedia/5_8_secure-media.md
@@ -15,5 +15,6 @@
 If device implementations declare support for `Display.FLAG_SECURE` and
 support wired external display, they:
 
-*    [C-3-1] MUST support HDCP 1.2 or higher for all wired external displays.
+*    [C-3-1] MUST support HDCP 1.2 or higher for all external displays connected
+via a user-accessible wired port.
 
diff --git a/7_hardware-compatibility/7_1_display-and-graphics.md b/7_hardware-compatibility/7_1_display-and-graphics.md
index 853ba1b..a2b0ec6 100644
--- a/7_hardware-compatibility/7_1_display-and-graphics.md
+++ b/7_hardware-compatibility/7_1_display-and-graphics.md
@@ -190,11 +190,11 @@
 
 If device implementations include a screen or video output, they:
 
-*   [C-1-1] MUST support both OpenGL ES 1.0 and 2.0, as embodied and detailed
+*   [C-1-1] MUST support both OpenGL ES 1.1 and 2.0, as embodied and detailed
     in the [Android SDK documentation](
     https://developer.android.com/guide/topics/graphics/opengl.html).
-*   [SR] are STRONGLY RECOMMENDED to support OpenGL ES 3.0.
-*   SHOULD support OpenGL ES 3.1 or 3.2.
+*   [SR] are STRONGLY RECOMMENDED to support OpenGL ES 3.1.
+*   SHOULD support OpenGL ES 3.2.
 
 If device implementations support any of the OpenGL ES versions, they:
 
@@ -238,15 +238,15 @@
 https://www.khronos.org/registry/vulkan/specs/1.0-wsi&lowbarextensions/xhtml/vkspec.html)
 , a low-overhead, cross-platform API for high-performance 3D graphics.
 
-If device implementations support OpenGL ES 3.0 or 3.1, they:
+If device implementations support OpenGL ES 3.1, they:
 
-*    [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.0 .
+*    [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.1.
 
 If device implementations include a screen or video output, they:
 
-*    SHOULD include support for Vulkan 1.0.
+*    SHOULD include support for Vulkan 1.1.
 
-Device implementations, if including support for Vulkan 1.0:
+If device implementations include support for Vulkan 1.0, they:
 
 *   [C-1-1] MUST report the correct integer value with the
     `android.hardware.vulkan.level` and `android.hardware.vulkan.version`
@@ -271,14 +271,22 @@
 *   [C-1-6] MUST report all extension strings that they do support via the
     Vulkan native APIs , and conversely MUST NOT report extension strings
     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
 
-Device implementations, if not including support for Vulkan 1.0:
+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
     `vkEnumeratePhysicalDevices()`.
 
+If device implementations include support for Vulkan 1.1, they:
+
+*   [C-3-1] MUST expose support for the `SYNC_FD` external semaphore and handle types.
+*   [SR] Are STRONGLY RECOMMENDED to support the
+    `VK_ANDROID_external_memory_android_hardware_buffer` extension.
+
 #### 7.1.4.3 RenderScript
 
 *    [C-0-1] Device implementations MUST support [Android RenderScript](
@@ -320,14 +328,15 @@
 , they:
 
 *   [C-1-1] MUST have a color-calibrated display.
-*   [C-1-2] MUST have a display whose gamut covers the sRGB color gamut entirely
-    in CIE 1931 xyY space.
-*   [C-1-3] MUST have a display whose gamut has an area of at least 90% of NTSC
-    1953 in CIE 1931 xyY space.
-*   [C-1-4] MUST support OpenGL ES 3.0, 3.1, or 3.2 and report it properly.
+*   [C-1-2] MUST have a display whose gamut covers the sRGB color gamut
+    entirely in CIE 1931 xyY space.
+*   [C-1-3] MUST have a display whose gamut has an area of at least 90% of
+    DCI-P3 in CIE 1931 xyY space.
+*   [C-1-4] MUST support OpenGL ES 3.1 or 3.2 and report it properly.
 *   [C-1-5] MUST advertise support for the `EGL_KHR_no_config_context`,
-    `EGL_EXT_pixel_format_float`,`EGL_KHR_gl_colorspace`,
-    `EGL_EXT_colorspace_scrgb_linear`, and `EGL_GL_colorspace_display_p3`
+    `EGL_EXT_pixel_format_float`, `EGL_KHR_gl_colorspace`,
+    `EGL_EXT_gl_colorspace_scrgb`, `EGL_EXT_gl_colorspace_scrgb_linear`,
+    `EGL_EXT_gl_colorspace_display_p3`, and `EGL_KHR_gl_colorspace_display_p3`
     extensions.
 *   [SR] Are STRONGLY RECOMMENDED to support `GL_EXT_sRGB`.
 
diff --git a/7_hardware-compatibility/7_3_sensors.md b/7_hardware-compatibility/7_3_sensors.md
index 8da2e19..2227066 100644
--- a/7_hardware-compatibility/7_3_sensors.md
+++ b/7_hardware-compatibility/7_3_sensors.md
@@ -261,6 +261,17 @@
 *    [C-3-4] MUST report all accuracy estimates (including Bearing, Speed, and
 Vertical) as part of each GPS 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
+call.
+*    [C-4-2] MUST report positions and measurements to the
+[GNSS Location Provider](https://developer.android.com/reference/android/location/LocationProvider)
+API's.
 
 ### 7.3.4\. Gyroscope
 
@@ -557,12 +568,16 @@
 
 #### 7.3.11.3\. Driving Status
 
-See [Section 2.5.1](#2_5_1_hardware) for device-specific requirements.
+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.
+
 
 ## 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 6f823fa..e9beb2c 100644
--- a/7_hardware-compatibility/7_4_data-connectivity.md
+++ b/7_hardware-compatibility/7_4_data-connectivity.md
@@ -79,30 +79,53 @@
 If device implementations include support for 802.11 and expose the
 functionality to a third-party application, they:
 
-*   [C-1-1] MUST implement the corresponding Andr:oid API.
+*   [C-1-1] MUST implement the corresponding Android API.
 *   [C-1-2] MUST report the hardware feature flag `android.hardware.wifi`.
-*   [C-1-3] MUST implement the [multicast API](
-http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html)
-as described in the SDK documentation.
+*   [C-1-3] MUST implement the [multicast API](http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html)
+    as described in the SDK documentation.
 *   [C-1-4] MUST support multicast DNS (mDNS) and MUST NOT filter mDNS packets
-(224.0.0.251) at any time of operation including:
+    (224.0.0.251) at any time of operation including:
     *   Even when the screen is not in an active state.
     *   For Android Television device implementations, even when in standby
 power states.
-*   SHOULD randomize the source MAC address and sequence number of probe
-request frames, once at the beginning of each scan, while STA is disconnected.
+*   [C-1-5] MUST NOT treat the [`WifiManager.enableNetwork()`](
+    https://developer.android.com/reference/android/net/wifi/WifiManager.html#enableNetwork%28int%2C%20boolean%29)
+    API method call as a sufficient indication to switch the currently active
+    `Network` that is used by default for application traffic and is returned
+    by [`ConnectivityManager`](https://developer.android.com/reference/android/net/ConnectivityManager)
+    API methods such as [`getActiveNetwork`](https://developer.android.com/reference/android/net/ConnectivityManager#getActiveNetwork%28%29)
+    and [`registerDefaultNetworkCallback`](https://developer.android.com/reference/android/net/ConnectivityManager#registerDefaultNetworkCallback%28android.net.ConnectivityManager.NetworkCallback,%20android.os.Handler%29).
+    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()`](
+    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
+    Internet access, switch to any other available network (e.g. mobile
+    data) that provides Internet access.
+*   [C-SR] Are STRONGLY RECOMMENDED to randomize the source MAC address and
+sequence number of probe request frames, once at the beginning of each scan,
+while STA is disconnected.
     * Each group of probe request frames comprising one scan should use one
     consistent MAC address (SHOULD NOT randomize MAC address halfway through a
     scan).
     * Probe request sequence number should iterate as normal (sequentially)
-    between the probe requests in a scan
+    between the probe requests in a scan.
     * Probe request sequence number should randomize between the last probe
-    request of a scan and the first probe request of the next scan
-*   SHOULD only allow the following information elements in probe request
-frames, while STA is disconnected:
+    request of a scan and the first probe request of the next scan.
+*   [C-SR] Are STRONGLY RECOMMENDED, while STA is disconnected, to allow only
+the following elements in probe request frames:
     * SSID Parameter Set (0)
     * DS Parameter Set (3)
 
+If device implementations support Wi-Fi and use Wi-Fi for location scanning,
+they:
+
+*    [C-2-1] MUST provide a user affordance to enable/disable the value read
+     through the [`WifiManager.isScanAlwaysAvailable`](https://developer.android.com/reference/android/net/wifi/WifiManager.html#isScanAlwaysAvailable%28%29)
+     API method.
+
 #### 7.4.2.1\. Wi-Fi Direct
 
 Device implementations:
@@ -116,7 +139,7 @@
     as described in the SDK documentation.
 *   [C-1-2] MUST report the hardware feature `android.hardware.wifi.direct`.
 *   [C-1-3] MUST support regular Wi-Fi operation.
-*   SHOULD support Wi-Fi and Wi-Fi Direct operations concurrently.
+*   [C-1-4] MUST support Wi-Fi and Wi-Fi Direct operations concurrently.
 
 #### 7.4.2.2\. Wi-Fi Tunneled Direct Link Setup
 
@@ -154,6 +177,20 @@
 *   [C-1-4] MUST randomize the Wi-Fi Aware management interface address at intervals
     no longer then 30 minutes and whenever Wi-Fi Aware is enabled.
 
+If device implementations include support for Wi-Fi Aware and
+Wi-Fi Location as described in [Section 7.4.2.5](#7_4_2_5_Wi-Fi_Location) and
+exposes these functionalities to third-party apps, then they:
+
+*   [C-2-1] MUST implement the location-aware discovery APIs: [setRangingEnabled](
+https://developer.android.com/reference/android/net/wifi/aware/PublishConfig.Builder.html#setRangingEnabled%28boolean%29),
+ [setMinDistanceMm](
+https://developer.android.com/reference/android/net/wifi/aware/SubscribeConfig.Builder#setMinDistanceMm%28int%29),
+ [setMaxDistanceMm](
+https://developer.android.com/reference/android/net/wifi/aware/SubscribeConfig.Builder#setMaxDistanceMm%28int%29)
+, and
+ [onServiceDiscoveredWithinRange](
+https://developer.android.com/reference/android/net/wifi/aware/DiscoverySessionCallback#onServiceDiscoveredWithinRange%28android.net.wifi.aware.PeerHandle,%20byte[],%20java.util.List%3Cbyte[]%3E,%20int%29).
+
 #### 7.4.2.4\. Wi-Fi Passpoint
 
 Device implementations:
@@ -176,6 +213,24 @@
 *    [C-2-1] The implementation of the Passpoint related `WifiManager`
 APIs MUST throw an `UnsupportedOperationException`.
 
+#### 7.4.2.5\. Wi-Fi Location (Wi-Fi Round Trip Time - RTT)
+
+Device implementations:
+
+*    SHOULD include support for [Wi-Fi Location](
+     https://www.wi-fi.org/discover-wi-fi/wi-fi-location).
+
+If device implementations include support for Wi-Fi Location and expose the
+functionality to third-party apps, then they:
+
+*   [C-1-1] MUST implement the `WifiRttManager` APIs as described in the
+[SDK documentation](
+http://developer.android.com/reference/android/net/wifi/rtt/WifiRttManager.html).
+*   [C-1-2] MUST declare the `android.hardware.wifi.rtt` feature flag.
+*   [C-1-3] MUST randomize the source MAC address for each RTT burst
+    which is executed while the Wi-Fi interface on which the RTT is
+    being executed is not associated to an Access Point.
+
 ### 7.4.3\. Bluetooth
 
 If device implementations support Bluetooth Audio profile, they:
@@ -183,6 +238,10 @@
 *    SHOULD support Advanced Audio Codecs and Bluetooth Audio Codecs
 (e.g. LDAC).
 
+If device implementations support HFP, A2DP and AVRCP, they:
+
+*    SHOULD support at least 5 total connected devices.
+
 If device implementations declare `android.hardware.vr.high_performance`
 feature, they:
 
@@ -198,8 +257,7 @@
 (`android.hardware.bluetooth` and `android.hardware.bluetooth_le`
 respectively) and implement the platform APIs.
 *    SHOULD implement relevant Bluetooth profiles such as
-     A2DP, AVCP, OBEX, etc. as appropriate for the device.
-
+     A2DP, AVRCP, OBEX, HFP, etc. as appropriate for the device.
 
 If device implementations include support for Bluetooth Low Energy, they:
 
@@ -227,6 +285,12 @@
 timeout no longer than 15 minutes and rotate the address at timeout to protect
 user privacy.
 
+If device implementations support Bluetooth LE and use Bluetooth LE for
+location scanning, they:
+
+*    [C-4-1] MUST provide a user affordance to enable/disable the value read
+     through the System API `BluetoothAdapter.isBleScanAlwaysAvailable()`.
+
 ### 7.4.4\. Near-Field Communications
 
 Device implementations:
@@ -361,57 +425,56 @@
 
 *   [C-0-1] MUST include support for one or more forms of
 data networking. Specifically, device implementations MUST include support for
-at least one data standard capable of 200Kbit/sec or greater. Examples of
+at least one data standard capable of 200 Kbit/sec or greater. Examples of
     technologies that satisfy this requirement include EDGE, HSPA, EV-DO,
-    802.11g, Ethernet, Bluetooth PAN, etc.
+    802.11g, Ethernet and Bluetooth PAN.
 *   SHOULD also include support for at least one common wireless data
-standard, such as 802.11 (Wi-Fi) when a physical networking standard (such as
-Ethernet) is the primary data connection
+standard, such as 802.11 (Wi-Fi), when a physical networking standard (such as
+Ethernet) is the primary data connection.
 *   MAY implement more than one form of data connectivity.
 *   [C-0-2] MUST include an IPv6 networking stack and support IPv6
 communication using the managed APIs, such as `java.net.Socket` and
 `java.net.URLConnection`, as well as the native APIs, such as `AF_INET6`
 sockets.
 *   [C-0-3] MUST enable IPv6 by default.
-   *   MUST ensure that IPv6 communication is as reliable as IPv4, for example.
+   *   MUST ensure that IPv6 communication is as reliable as IPv4, for example:
       *   [C-0-4] MUST maintain IPv6 connectivity in doze mode.
       *   [C-0-5] Rate-limiting MUST NOT cause the device to lose IPv6
       connectivity on any IPv6-compliant network that uses RA lifetimes of
       at least 180 seconds.
-
-When connected to an IPv6-capable network:
-
-*   [C-1-1] devices MUST provide applications with direct IPv6 connectivity to
-the network, without any form
-of address or port translation happening locally on the device. Both managed
-APIs such as
-[`Socket#getLocalAddress`](https://developer.android.com/reference/java/net/Socket.html#getLocalAddress%28%29)
-or
-[`Socket#getLocalPort`](https://developer.android.com/reference/java/net/Socket.html#getLocalPort%28%29))
+*   [C-0-6] MUST provide third-party applications with direct IPv6 connectivity
+to the network when connected to an IPv6 network, without any form of address or
+port translation happening locally on the device. Both managed APIs such as
+[`Socket#getLocalAddress`](
+https://developer.android.com/reference/java/net/Socket.html#getLocalAddress%28%29)
+or [`Socket#getLocalPort`](
+https://developer.android.com/reference/java/net/Socket.html#getLocalPort%28%29))
 and NDK APIs such as `getsockname()` or `IPV6_PKTINFO` MUST return the IP
 address and port that is actually used to send and receive packets on the
 network.
 
 
-The required level of IPv6 support depends on the network type, as follows:
+The required level of IPv6 support depends on the network type, as shown in
+the following requirements.
 
-If devices implementations support Wi-Fi networks, they:
+If device implementations support Wi-Fi, they:
 
-*   [C-2-1] MUST support dual-stack and IPv6-only operation on Wi-Fi.
+*   [C-1-1] MUST support dual-stack and IPv6-only operation on Wi-Fi.
 
-If device implementations support Ethernet networks, they:
+If device implementations support Ethernet, they:
 
-*   [C-3-1] MUST support dual-stack operation on Ethernet.
+*   [C-2-1] MUST support dual-stack operation on Ethernet.
 
-If device implementations support cellular data, they:
+If device implementations support Cellular data, they:
 
-*   [C-4-1] SHOULD support IPv6 operation (IPv6-only and possibly dual-stack) on
-cellular data.
+*   SHOULD support IPv6 operation (IPv6-only and possibly dual-stack) on
+cellular.
 
-When devices are simultaneously connected to more than one network, (e.g., Wi-Fi
+If device implementations support more than one network type (e.g., Wi-Fi
 and cellular data), they:
-*   [C-5-1] MUST simultaneously meet these requirements on each network to which
-they are connected.
+
+*   [C-3-1] MUST simultaneously meet the above requirements on each network
+when the device is simultaneously connected to more than one network type.
 
 
 ### 7.4.6\. Sync Settings
diff --git a/7_hardware-compatibility/7_5_cameras.md b/7_hardware-compatibility/7_5_cameras.md
index b5da828..dda1f9c 100644
--- a/7_hardware-compatibility/7_5_cameras.md
+++ b/7_hardware-compatibility/7_5_cameras.md
@@ -88,12 +88,15 @@
 *    MAY include support for an external camera that is not necessarily
 always connected.
 
-If device impelmentations include support for an external camera, they:
+If device implementations include support for an external camera, they:
 
 *   [C-1-1] MUST declare the platform feature flag
 `android.hardware.camera.external` and `android.hardware camera.any`.
 *   [C-1-2] MUST support USB Video Class (UVC 1.0 or higher) if the external
-camera connects through the USB port.
+camera connects through the USB host port.
+*   [C-1-3] MUST pass camera CTS tests with a physical external camera device
+connected. Details of camera CTS testing are available at [source.android.com](
+https://source.android.com/compatibility/cts/camera-hal).
 *   SHOULD support video compressions such as MJPEG to enable transfer of
     high-quality unencoded streams (i.e. raw or independently compressed picture
     streams).
@@ -191,6 +194,16 @@
 *   [C-0-10] MUST broadcast the `Camera.ACTION_NEW_VIDEO`
 intent whenever a new video is recorded by the camera and the entry of the
 picture has been added to the media store.
+*   [C-SR] 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`.
 
 ### 7.5.5\. Camera Orientation
 
diff --git a/7_hardware-compatibility/7_7_usb.md b/7_hardware-compatibility/7_7_usb.md
index 20c1be6..90db766 100644
--- a/7_hardware-compatibility/7_7_usb.md
+++ b/7_hardware-compatibility/7_7_usb.md
@@ -42,8 +42,8 @@
 *    SHOULD implement the Android Open Accessory (AOA) API and specification as
 documented in the Android SDK documentation.
 
-If device implementations including a USB port, implement the AOA specification,
-they:
+If device implementations include a USB port and implement the AOA
+specification, they:
 
 *    [C-2-1] MUST declare support for the hardware feature
 [`android.hardware.usb.accessory`](http://developer.android.com/guide/topics/connectivity/usb/accessory.html).
diff --git a/7_hardware-compatibility/7_9_virtual-reality.md b/7_hardware-compatibility/7_9_virtual-reality.md
index 1a8b632..f5d1976 100644
--- a/7_hardware-compatibility/7_9_virtual-reality.md
+++ b/7_hardware-compatibility/7_9_virtual-reality.md
@@ -14,16 +14,18 @@
 
 ### 7.9.2\. Virtual Reality High Performance
 
-If device implementations identify the support of high performance VR
-for longer user periods through the `android.hardware.vr.high_performance`
+The feature flag `android.hardware.vr.high_performance` indicates that the
+device is capable of supporting high quality virtual reality applications.
+
+If device implementations report the `android.hardware.vr.high_performance`
 feature flag, they:
 
 *   [C-1-1] MUST have at least 2 physical cores.
-*   [C-1-2] MUST declare `android.software.vr.mode feature`.
+*   [C-1-2] MUST report the feature flag `android.software.vr.mode`.
 *   [C-1-3] MUST support sustained performance mode.
 *   [C-1-4] MUST support OpenGL ES 3.2.
-*   [C-1-5] MUST support Vulkan Hardware Level 0 and SHOULD support
-    Vulkan Hardware Level 1.
+*   [C-1-5] MUST support `android.hardware.vulkan.level` 0.
+*   SHOULD support `android.hardware.vulkan.level` 1 or higher.
 *   [C-1-6] MUST implement
     [`EGL_KHR_mutable_render_buffer`](https://www.khronos.org/registry/EGL/extensions/KHR/EGL_KHR_mutable_render_buffer.txt),
     [`EGL_ANDROID_front_buffer_auto_refresh`](https://www.khronos.org/registry/EGL/extensions/ANDROID/EGL_ANDROID_front_buffer_auto_refresh.txt),
@@ -32,12 +34,10 @@
     [`EGL_KHR_wait_sync`](https://www.khronos.org/registry/EGL/extensions/KHR/EGL_KHR_wait_sync.txt),
     [`EGL_IMG_context_priority`](https://www.khronos.org/registry/EGL/extensions/IMG/EGL_IMG_context_priority.txt),
     [`EGL_EXT_protected_content`](https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_protected_content.txt),
+    [`EGL_EXT_image_gl_colorspace`](https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_gl_colorspace.txt),
     and expose the extensions in the list of available EGL extensions.
-*   [C-1-7] The GPU and display MUST be able to synchronize access to the shared
-front buffer such that alternating-eye rendering of VR content at 60fps with two
-render contexts will be displayed with no visible tearing artifacts.
 *   [C-1-8] MUST implement
-    [`GL_EXT_multisampled_render_to_texture`](https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_multisampled_render_to_texture.txt),
+    [`GL_EXT_multisampled_render_to_texture2`](https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_multisampled_render_to_texture2.txt),
     [`GL_OVR_multiview`](https://www.khronos.org/registry/OpenGL/extensions/OVR/OVR_multiview.txt),
     [`GL_OVR_multiview2`](https://www.khronos.org/registry/OpenGL/extensions/OVR/OVR_multiview2.txt),
     [`GL_OVR_multiview_multisampled_render_to_texture`](https://www.khronos.org/registry/OpenGL/extensions/OVR/OVR_multiview_multisampled_render_to_texture.txt),
@@ -45,33 +45,56 @@
     [`GL_EXT_EGL_image_array`](https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_EGL_image_array.txt),
     [`GL_EXT_external_buffer`](https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_external_buffer.txt),
     and expose the extensions in the list of available GL extensions.
+*   [C-1-24] MUST implement
+    [`VK_KHR_shared_presentable_image`](https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VK_KHR_shared_presentable_image),
+    [`VK_GOOGLE_display_timing`](https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VK_GOOGLE_display_timing)
+    and expose the extensions in the list of available Vulkan extensions.
+*   [C-1-25] MUST expose at least one Vulkan queue family that where `flags`
+    contain both `VK_QUEUE_GRAPHICS_BIT` and `VK_QUEUE_COMPUTE_BIT`,
+    and `queueCount` is at least 2.
+*   [SR] Are STRONGLY RECOMMENDED to support Vulkan 1.1.
+*   [SR] Are STRONGLY RECOMMENDED to implement
+    [`VK_ANDROID_external_memory_android_hardware_buffer`](https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html/vkspec.html#VK_ANDROID_external_memory_android_hardware_buffer)
+    and expose it in the list of available Vulkan extensions.
+*   [C-1-7] The GPU and display MUST be able to synchronize access to the shared
+    front buffer such that alternating-eye rendering of VR content at 60fps with two
+    render contexts will be displayed with no visible tearing artifacts.
 *   [C-1-9] MUST implement support for [`AHardwareBuffer`](https://developer.android.com/ndk/reference/hardware__buffer_8h.html)
-    flags `AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER` and
-    `AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA` as
-    described in the NDK.
+    flags `AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER`,
+    `AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA` and
+    `AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT`
+    as described in the NDK.
 *   [C-1-10] MUST implement support for `AHardwareBuffers` with more than one
-layer.
-*   [C-1-11] MUST support H.264 decoding at least 3840x2160@30fps-40Mbps
-(equivalent to 4 instances of 1920x1080@30fps-10Mbps or 2 instances of
-1920x1080@60fps-20Mbps).
-*   [C-1-12] MUST support HEVC and VP9, MUST be capable to decode at least
-    1920x1080@30fps-10Mbps and SHOULD be capable to decode
-    3840x2160@30fps-20Mbps (equivalent to
-    4 instances of 1920x1080@30fps-5Mbps).
+    layer and any combination of the usage flags
+    `AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT`,
+    `AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE`,
+    `AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT`
+    for at least the following formats:
+    `AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM`,
+    `AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM`,
+    `AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM`,
+    `AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT`.
+*   [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 
+    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
+    capable of decoding 3840 x 2160 at 30 fps-20 Mbps (equivalent to
+    4 instances of 1920 x 1080 at 30 fps-5 Mbps).
 *   [C-1-13] MUST support `HardwarePropertiesManager.getDeviceTemperatures` API
-and return accurate values for skin temperature.
-*   [C-1-14] MUST have an embedded screen, and its resolution MUST be at least be
-    FullHD(1080p) and STRONGLY RECOMMENDED TO BE  be QuadHD (1440p) or higher.
+    and return accurate values for skin temperature.
+*   [C-1-14] MUST have an embedded screen, and its resolution MUST be at least
+    1920 x 1080.
+*   [SR] Are STRONGLY RECOMMENDED to have a display resolution of at least
+    2560 x 1440.
 *   [C-1-15] The display MUST update at least 60 Hz while in VR Mode.
-*   [C-1-16] The display latency (as measured on Gray-to-Gray, White-to-Black, and
-Black-to-White switching time) MUST be ≤ 6 milliseconds.
 *   [C-1-17] The display MUST support a low-persistence mode with ≤ 5 milliseconds
-persistence, persistence being defined as the amount of time for
-which a pixel is emitting light.
+    persistence, persistence being defined as the amount of time for
+    which a pixel is emitting light.
 *   [C-1-18] MUST support Bluetooth 4.2 and Bluetooth LE Data Length Extension
     [section 7.4.3](#7_4_3_bluetooth).
-*   [C-1-19] MUST support and properly report [Direct Channel Type](
-    https://developer.android.com/reference/android/hardware/Sensor.html#isDirectChannelTypeSupported%28int%29")
+*   [C-1-19] MUST support and properly report
+    [Direct Channel Type](https://developer.android.com/reference/android/hardware/Sensor#isDirectChannelTypeSupported%28int%29)
     for all of the following default sensor types:
       * `TYPE_ACCELEROMETER`
       * `TYPE_ACCELEROMETER_UNCALIBRATED`
@@ -79,13 +102,22 @@
       * `TYPE_GYROSCOPE_UNCALIBRATED`
       * `TYPE_MAGNETIC_FIELD`
       * `TYPE_MAGNETIC_FIELD_UNCALIBRATED`
-*   [C-1-20] MUST support the [`TYPE_HARDWARE_BUFFER`](
-https://developer.android.com/reference/android/hardware/SensorDirectChannel.html#TYPE_HARDWARE_BUFFER)
+*   [C-1-20] MUST support the
+    [`TYPE_HARDWARE_BUFFER`](https://developer.android.com/reference/android/hardware/SensorDirectChannel.html#TYPE_HARDWARE_BUFFER)
     direct channel type for all Direct Channel Types listed above.
-*   [SR] Are STRONGLY RECOMMENDED to support
-    `android.hardware.sensor.hifi_sensors` feature and MUST meet the gyroscope,
-    accelerometer, and magnetometer related requirements for
-    `android.hardware.hifi_sensors`.
+*   [C-1-21] MUST meet the gyroscope, accelerometer, and magnetometer related
+    requirements for `android.hardware.hifi_sensors`, as specified in
+    [section 7.3.9](#7_3_9_high_fidelity_sensors).
+*   [SR] Are STRONGLY RECOMMENDED to support the
+    `android.hardware.sensor.hifi_sensors` feature.
+*   [C-1-22] MUST have end-to-end motion to photon latency not higher than
+    28 milliseconds.
+*   [SR] Are STRONGLY RECOMMENDED to have end-to-end motion to photon latency
+    not higher than 20 milliseconds.
+*   [C-1-23] MUST have first-frame ratio, which is the ratio between the
+    brightness of pixels on the first frame after a transition from black to
+    white and the brightness of white pixels in steady state, of at least 85%.
+*   [SR] Are STRONGLY RECOMMENDED to have first-frame ratio of at least 90%.
 *   MAY provide an exclusive core to the foreground
     application and MAY support the `Process.getExclusiveCores` API to return
     the numbers of the cpu cores that are exclusive to the top foreground
diff --git a/9_security-model/9_10_device-integrity.md b/9_security-model/9_10_device-integrity.md
index 7ac86b0..1d7698b 100644
--- a/9_security-model/9_10_device-integrity.md
+++ b/9_security-model/9_10_device-integrity.md
@@ -9,8 +9,8 @@
 reserved for device implementations upgrading from an earlier version of Android
 where this new system API method did not exist.
 
-Verified boot is a feature that guarantees the integrity of the device
-software. If a device implementation supports the feature, it:
+Verified Boot is a feature that guarantees the integrity of the device
+software. If device implementations support the feature, they:
 
 *    [C-1-1] MUST declare the platform feature flag
 `android.software.verified_boot`.
@@ -28,19 +28,25 @@
 any non-verified storage blocks MUST not be used.
 *    [C-1-7] MUST NOT allow verified partitions on the device to be modified
 unless the user has explicitly unlocked the boot loader.
-*    [SR] If there are multiple discrete chips in the device (e.g. radio,
+*    [C-SR] If there are multiple discrete chips in the device (e.g. radio,
 specialized image processor), the boot process of each of those chips is
 STRONGLY RECOMMENDED to verify every stage upon booting.
-*    [SR] STRONGLY RECOMMENDED to use tamper-evident storage: for when the
+*    [C-SR] Are STRONGLY RECOMMENDED to use tamper-evident storage: for when the
 bootloader is unlocked. Tamper-evident storage means that the boot loader can
 detect if the storage has been tampered with from inside the
 HLOS (High Level Operating System).
-*    [SR] STRONGLY RECOMMENDED to prompt the user, while using the device, and
+*    [C-SR] Are STRONGLY RECOMMENDED to prompt the user, while using the device, and
 require physical confirmation before allowing a transition from boot loader
 locked mode to boot loader unlocked mode.
-*    [SR] STRONGLY RECOMMENDED to implement rollback protection for the HLOS
-(e.g. boot, system partitions) and to use tamper-evident storage for storing the
+*    [C-SR] Are STRONGLY RECOMMENDED to implement rollback protection for the HLOS
+(e.g. boot, Is system partitions) and to 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.
+*    [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
+at all.
 *    SHOULD implement rollback protection for any component with persistent
 firmware (e.g. modem, camera) and SHOULD use tamper-evident storage for
 storing the metadata used for determining the minimum allowable version.
@@ -54,9 +60,9 @@
 https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_RAM_NORMAL)
 , they:
 
-*    [C-2-1] MUST support verified boot for device integrity.
+*    [C-2-1] MUST support Verified Boot for device integrity.
 
-If a device implementation is already launched without supporting verified boot
+If a device implementation is already launched without supporting Verified Boot
 on an earlier version of Android, such a device can not add support for this
 feature with a system software update and thus are exempted from the
 requirement.
diff --git a/9_security-model/9_7_kernel-security-features.md b/9_security-model/9_7_kernel-security-features.md
index 33151fb..8971bac 100644
--- a/9_security-model/9_7_kernel-security-features.md
+++ b/9_security-model/9_7_kernel-security-features.md
@@ -42,7 +42,8 @@
 *   [C-0-10] MUST NOT execute user-space memory when executing
 in the kernel mode (e.g. hardware PXN, or emulated via
 `CONFIG_CPU_SW_DOMAIN_PAN` or `CONFIG_ARM64_SW_TTBR0_PAN`) on devices
-originally shipping with API level 28 or higher.
+originally shipping with API level 28 or higher. For 32-bit ARM linux kernels,
+this means `CONFIG_ARM_LPAE` MUST not be enabled and set to 'n'.
 *   [C-0-11] MUST NOT read or write user-space memory in the
 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`)
diff --git a/9_security-model/9_8_privacy.md b/9_security-model/9_8_privacy.md
index a1799a4..8990a82 100644
--- a/9_security-model/9_8_privacy.md
+++ b/9_security-model/9_8_privacy.md
@@ -8,12 +8,21 @@
 Device implementations:
 
 *   [C-0-1] MUST keep a reasonable retention period of such user history.
+*   [C-0-2] MUST only include the fields marked with `DEST_AUTOMATIC` in the
+    incident report created by the System API class `IncidentManager`.
 *   [SR] Are STRONGLY RECOMMENDED to keep the 14 days retention period as
     configured by default in the AOSP implementation.
 
 
 ### 9.8.2\. Recording
 
+Device implementations:
+
+*   [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.
+
 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:
@@ -74,4 +83,4 @@
      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)
-     attribute to `false`.
\ No newline at end of file
+     attribute to `false`.
diff --git a/9_security-model/9_9_full-disk-encryption.md b/9_security-model/9_9_full-disk-encryption.md
index 8a14713..3f0378c 100644
--- a/9_security-model/9_9_full-disk-encryption.md
+++ b/9_security-model/9_9_full-disk-encryption.md
@@ -1,16 +1,16 @@
 ## 9.9\. Data Storage Encryption
 
-If device implementations support a secure lock screen as described in
-[section 9.11.1](#9_11_1_secure_lock_screen), they:
+Device implementations:
 
-*   [C-1-1] MUST support data storage encryption of the application private
+*   [C-0-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.
 
+If device implementations are already launched on an earlier Android version
+without data storage encryption described above, such a device MAY be exempted.
+
 If device implementations support a secure lock screen as described in
-[section 9.11.1](#9_11_1_secure_lock_screen) and support data storage
-encryption with Advanced Encryption Standard (AES) crypto performance
-above 50MiB/sec, they:
+[section 9.11.1](#9_11_1_secure_lock_screen), they:
 
 *    [C-2-1] MUST enable the data storage encryption by default at the time
 the user has completed the out-of-box setup experience. If device
@@ -49,13 +49,22 @@
 (eg. passcode, pin, pattern or fingerprint) and the `ACTION_USER_UNLOCKED`
 message is broadcasted.
 *    [C-1-3] MUST NOT offer any method to unlock the CE protected storage
-without the user-supplied credentials.
+without either the user-supplied credentials or a registered escrow key.
 *    [C-1-4] MUST support 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 with a key length
-of 256-bits in XTS mode.
-*    [C-1-6] MUST support encrypting file name using AES with a key length of
-256-bits in CBC-CTS mode.
+*    [C-1-5] MUST support encrypting file contents using AES-256-XTS or
+Speck128/256-XTS. AES-256-XTS refers to the Advanced Encryption Standard with
+a 256-bit key length, operated in XTS mode.  Speck128/256-XTS refers to the
+[Speck block cipher](https://eprint.iacr.org/2013/404) with a 128-bit block
+length and 256-bit key length, operated in XTS mode.  In both cases, the full
+length of the XTS key is 512 bits.
+*    [C-1-6] MUST support encrypting file names using AES-256 or Speck128/256,
+in CBC-CTS mode.
+*    [C-1-7] MUST use AES rather than Speck128 for both file contents and file
+names if AES-256-XTS encryption or decryption performance is at least
+50 MiB/s.  Measured AES speeds MUST take advantage of AES instructions (e.g.
+the ARM Cryptography Extensions) if supported by the CPU and they result in
+a faster speed than other AES implementations.
 
 *   The keys protecting CE and DE storage areas:
 
@@ -83,12 +92,17 @@
 http://source.android.com/devices/tech/security/encryption/index.html)
 (FDE), they:
 
-*   [C-1-1] MUST use AES with a key of 128-bits (or greater) and a mode
-designed for storage (for example, AES-XTS, AES-CBC-ESSIV).
+*   [C-1-1] MUST use AES or Speck128 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-3] MUST use AES rather than Speck128 if AES-XTS or AES-CBC encryption
+or decryption performance is at least 50 MiB/s.  Measured AES speeds
+MUST take advantage of AES instructions (e.g. the ARM Cryptography Extensions)
+if supported by the CPU and if using these instructions results in a faster speed
+than other AES implementations.
 *   [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
+   *   [C-1-6] 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).