Merge "CDD: Tighten SR to MUST for HOT GNSS TTFF to 5 sec to keep consistency with CTS" 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..946e26c 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
@@ -155,24 +168,15 @@
 *   [[7.8](#7_8_audio).2/H-0-1] MUST have an audio output and declare
 `android.hardware.audio.output`.
 
-If Handheld device implementations include support for the VR mode, they:
+If Handheld device implementations are capable of meeting all the performance
+requirements for supporting VR mode and include support for it, they:
 
 *   [[7.9](#7_9_virtual-reality).1/H-1-1] MUST declare the
-`android.software.vr.mode` feature.
-
-
-If device implementations declare `android.software.vr.mode` feature, they:
-
-*   [[7.9](#7_9_virtual-reality).1/H-2-1] MUST include an application
-implementing `android.service.vr.VrListenerService`
-that can be enabled by VR applications via
-`android.app.Activity#setVrModeEnabled`.
-
-If Handheld device implementations are capable of meeting all the requirements
-to declare the `android.hardware.vr.high_performance` feature flag, they:
-
-*   [[7.9](#7_9_virtual-reality).2/-1-1] MUST declare the
 `android.hardware.vr.high_performance` feature flag.
+*   [[7.9](#7_9_virtual-reality).1/H-1-2] MUST include an application
+implementing `android.service.vr.VrListenerService` that can be enabled by VR
+applications via `android.app.Activity#setVrModeEnabled`.
+
 
 ### 2.2.2\. Multimedia
 
@@ -207,13 +211,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,10 +254,33 @@
 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).
 
+If Handheld device implementations support Assist action, they:
+
+*   [[3.8](#3_8_user-interface-compatibility).4/H-SR] Are STRONGLY RECOMMENDED
+to use long press on `HOME` key as the designated interaction to launch the
+assist app as described in [section 7.2.3](#7_2_3_navigation_keys) MUST launch
+the user-selected assist app, in other words the app that implements
+[`VoiceInteractionService`](
+https://developer.android.com/reference/android/service/voice/VoiceInteractionService)
+, or an activity handling the `ACTION_ASSIST` intent.
+
 If Android Handheld device implementations support a lock screen, they:
 
 *   [[3.8](#3_8_user-interface-compatibility).10/H-1-1] MUST display the Lock
@@ -252,6 +292,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 +386,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..30c9403 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,13 +225,28 @@
 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.
+
+If Automotive device implementations include a push-to-talk button, they:
+
+*   [[3.8](#3_8_user-interface-compatibility).4/A-1-1] MUST use a short press of
+the push-to-talk button as the designated interaction to launch the
+user-selected assist app, in other words the app that implements
+[`VoiceInteractionService`](
+https://developer.android.com/reference/android/service/voice/VoiceInteractionService).
+
+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.
+third-party apps using the media APIs as described in section
+[3.14](#3_14_media_ui).
 
-### 2.2.4\. Performance and Power
+### 2.5.4\. Performance and Power
 
 Automotive device implementations:
 
@@ -248,15 +275,21 @@
 http://source.android.com/devices/tech/power/batterystats.html)
 shell command to the app developer.
 
-### 2.2.5\. Security Model
+### 2.5.6\. 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
@@ -265,4 +298,4 @@
 *   [[9.14](#9_14_automotive-system-isolation)/A-0-2] MUST watchdog against
 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.
+which may lead to malfunctioning vehicle subsystems.
\ No newline at end of file
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 0d4a3ce..9b05496 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
@@ -360,13 +364,16 @@
 
 *   [C-2-1] MUST provide a settings menu that will call the
 [`android.provider.Telephony.ACTION_CHANGE_DEFAULT`](
-http://developer.android.com/reference/android/provider/Telephony.Sms.Intents.html)
+http://developer.android.com/reference/android/provider/Telephony.Sms.Intents.html#ACTION_CHANGE_DEFAULT)
 intent to show a dialog to change the default SMS application.
 
 *   [C-2-2] MUST honor the [`android.telecom.action.CHANGE_DEFAULT_DIALER`](
 https://developer.android.com/reference/android/telecom/TelecomManager.html#ACTION_CHANGE_DEFAULT_DIALER)
 intent to show a dialog to allow the user to change the default Phone
 application.
+    *    MUST use the user-selected default Phone app's UI for incoming and
+    outgoing calls except for emergency calls, which would use the
+    preloaded Phone app.
 
 *   [C-2-3] MUST honor the [android.telecom.action.CHANGE_PHONE_ACCOUNTS](
 https://developer.android.com/reference/android/telecom/TelecomManager.html#ACTION_CHANGE_PHONE_ACCOUNTS)
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_6_api-namespaces.md b/3_software/3_6_api-namespaces.md
index e1e2e17..a010e0d 100644
--- a/3_software/3_6_api-namespaces.md
+++ b/3_software/3_6_api-namespaces.md
@@ -9,6 +9,7 @@
 *   `javax.*`
 *   `sun.*`
 *   `android.*`
+*   `androidx.*`
 *   `com.android.*`
 
 That is, they:
diff --git a/3_software/3_8_user-interface-compatibility.md b/3_software/3_8_user-interface-compatibility.md
index 9d0a5a1..76c32c2 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
 
@@ -259,8 +276,6 @@
     in [section 7.2.3](#7_2_3_navigation_keys) MUST launch the user-selected
     assist app, in other words the app that implements `VoiceInteractionService`,
     or an activity handling the `ACTION_ASSIST` intent.
-*   [C-SR] STRONGLY RECOMMENDED to use long press on `HOME` key as this designated
-    interaction.
 
 ### 3.8.5\. Alerts and Toasts
 
@@ -433,11 +448,14 @@
 ### 3.8.12\. Location
 
 If device implementations include a hardware sensor (e.g. GPS) that is capable
-of providing the location coordinates:
+of providing the location coordinates, they
 
-*   [C-1-1] [location modes](
-    http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE)
-    MUST be displayed in the Location menu within Settings.
+*   [C-1-2] MUST display the [current status of location](
+    https://developer.android.com/reference/android/location/LocationManager.html#isLocationEnabled%28%29)
+    in the Location menu within Settings.
+*   [C-1-3] MUST NOT display [location modes](
+    https://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE)
+    in the Location menu within Settings.
 
 ### 3.8.13\. Unicode and Font
 
@@ -532,3 +550,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..f0d4a7b 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
@@ -88,7 +83,7 @@
         https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setShortSupportMessage%28android.content.ComponentName, java.lang.CharSequence%29).
     *   The DPC application’s icon.
 
-## 3.9.2 Managed Profile Support
+### 3.9.2 Managed Profile Support
 
 If device implementations declare `android.software.managed_users`, they:
 
@@ -144,3 +139,14 @@
     in the preinstalled call log, in-call UI, in-progress and missed-call
     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
+
+If device implementations declare `android.software.managed_users`, they:
+
+*   [C-1-1] MUST provide a user affordance to logout from the current user and
+    switch back to the primary user in multiple-user session when
+    [`isLogoutEnabled`](
+    https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isLogoutEnabled%28%29)
+    returns `true`. The user affordance MUST be accessible from the lockscreen
+    without unlocking the device.
\ No newline at end of file
diff --git a/4_application-packaging/4_0_intro.md b/4_application-packaging/4_0_intro.md
index 1a25035..be0b3d7 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](
@@ -46,10 +50,16 @@
 
 *    SHOULD provide a user affordance to grant/revoke the permission to
 install apps from unknown sources per application, but MAY choose to implement
-this as a no-op and return `RESULT_CANCELED` for
-[`startActivityForResult()`](http://developer.android.com/reference/android/app/Activity.html#startActivityForResult%28android.content.Intent,
-int%29),
+this as a no-op and return `RESULT_CANCELED` for [`startActivityForResult()`](
+http://developer.android.com/reference/android/app/Activity.html#startActivityForResult%28android.content.Intent,int%29),
 if the device implementation does not want to allow users to have this choice.
 However, even in such cases, they SHOULD indicate to the user why there is no
-such
-choice presented.
+such choice presented.
+
+*    [C-0-7] MUST display a warning dialog with the warning string that is
+provided through the system API `PackageManager.setHarmfulAppWarning`
+to the user before launching an activity in an application that has been marked
+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
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..5e0699d 100644
--- a/5_multimedia/5_6_audio-latency.md
+++ b/5_multimedia/5_6_audio-latency.md
@@ -38,33 +38,49 @@
 *   **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:
 
-*   [SR] Cold output latency of 100 milliseconds or less
-*   [SR] Continuous output latency of 45 milliseconds or less
-*   [SR] Minimize the cold output jitter
+*   [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] 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 
-`android.hardware.audio.low_latency` feature flag.
-*   [SR] STRONGLY RECOMMENDED to also meet the requirements for low-latency
+*   [C-SR] STRONGLY RECOMMENDED to report low-latency audio by declaring
+    `android.hardware.audio.low_latency` feature flag.
+*   [C-SR] STRONGLY RECOMMENDED to meet the requirements for low-latency
     audio via the AAudio API.
+*   [C-SR] STRONGLY RECOMMENDED to ensure that for streams that return
+    [`AAUDIO_PERFORMANCE_MODE_LOW_LATENCY`](https://developer.android.com/ndk/guides/audio/aaudio/aaudio#performance-mode)
+    from [`AAudioStream_getPerformanceMode()`](https://developer.android.com/ndk/reference/group/audio#aaudiostream_getperformancemode),
+    the value returned by [`AAudioStream_getFramesPerBurst()`](https://developer.android.com/ndk/reference/group/audio#aaudiostream_getframesperburst)
+    is less than or equal to the value returned by [`android.media.AudioManager.getProperty(String)`](https://developer.android.com/reference/android/media/AudioManager.html#getProperty%28java.lang.String%29)
+    for property key [`AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER`](https://developer.android.com/reference/android/media/AudioManager.html#PROPERTY_OUTPUT_FRAMES_PER_BUFFER).
 
 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.
 
 If device implementations include `android.hardware.microphone`, they are
 STRONGLY RECOMMENDED to meet these input audio requirements:
 
-   *   [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
+   *   [C-SR] Cold input latency of 100 milliseconds or less
+   *   [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
+   *   [C-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/6_dev-tools-and-options/6_1_developer_tools.md b/6_dev-tools-and-options/6_1_developer_tools.md
index 2e1477e..ff9a191 100644
--- a/6_dev-tools-and-options/6_1_developer_tools.md
+++ b/6_dev-tools-and-options/6_1_developer_tools.md
@@ -32,6 +32,20 @@
     *   [C-0-8] MUST include the Monkey framework and make it available for
     applications to use.
 *    [**SysTrace**](http://developer.android.com/tools/help/systrace.html)
-    *   [C-0-9] MUST support systrace tool as documented in the Android SDK.
+    *   [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.
\ No newline at end of file
+    mechanism to turn on Systrace.
+
+If device implementations report the support of Vulkan 1.0 or higher via the
+`android.hardware.vulkan.version` feature flags, they:
+
+*   [C-1-1] MUST provide an affordance for the app developer to enable/disable
+    GPU debug layers.
+*   [C-1-2] MUST, when the GPU debug layers are enabled, enumerate layers in
+    libraries provided by external tools (i.e. not part of the platform or
+    application package) found in debuggable applications' base directory to
+    support [vkEnumerateInstanceLayerProperties()](
+    https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/vkEnumerateInstanceLayerProperties.html)
+    and [vkCreateInstance()](
+    https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/vkCreateInstance.html)
+    API methods.
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 c42d2f0..974ad6f 100644
--- a/6_dev-tools-and-options/6_2_developer_options.md
+++ b/6_dev-tools-and-options/6_2_developer_options.md
@@ -12,8 +12,14 @@
 implementation hides the Developer Options menu by default and enables users to
 launch Developer Options after pressing seven (7) times on the **Settings** >
 **About Device** > **Build Number** menu item.
-*   [C-0-2] MUST hide Developer Options by default and MUST provide a mechanism
-to enable Developer Options without the need for any special whitelisting.
+*   [C-0-2] MUST hide Developer Options by default.
+*   [C-0-3] MUST provide a clear mechanism that does not give preferential
+treatment to one third-party app as opposed to another to enable Developer
+Options. MUST provide a public visible document or website that describes how to
+enable Developer Options. This document or website MUST be linkable from
+the Android SDK documents.
+*   SHOULD have an ongoing visual notification to the user when Developer
+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
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_2_input-devices.md b/7_hardware-compatibility/7_2_input-devices.md
index 3a415de..664d7c5 100644
--- a/7_hardware-compatibility/7_2_input-devices.md
+++ b/7_hardware-compatibility/7_2_input-devices.md
@@ -115,7 +115,7 @@
 
 Android includes support for a variety of pointer input systems, such as
 touchscreens, touch pads, and fake touch input devices.
-[Touchscreen-based device implementations](http://source.android.com/devices/tech/input/touch-devices.html)
+[Touchscreen-based device implementations](https://source.android.com/devices/input/touch-devices)
 are associated with a display such that the user has the impression of directly
 manipulating items on screen. Since the user is directly touching the screen,
 the system does not require any additional affordances to indicate the objects
diff --git a/7_hardware-compatibility/7_3_sensors.md b/7_hardware-compatibility/7_3_sensors.md
index ffcbc2f..f902c1c 100644
--- a/7_hardware-compatibility/7_3_sensors.md
+++ b/7_hardware-compatibility/7_3_sensors.md
@@ -260,6 +260,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
 
@@ -370,21 +381,27 @@
 they:
 
 *   [C-2-1] MUST have a `TYPE_ACCELEROMETER` sensor which:
-    *   MUST have a measurement range between at least -8g and +8g.
-    *   MUST have a measurement resolution of at least 1024 LSB/G.
+    *   MUST have a measurement range between at least -8g and +8g, SHOULD have
+        a measurement range between at least -16g and +16g.
+    *   MUST have a measurement resolution of at least 2048 LSB/g.
     *   MUST have a minimum measurement frequency of 12.5 Hz or lower.
-    *   MUST have a maximum measurement frequency of 400 Hz or higher.
-    *   MUST have a measurement noise not above 400 uG/√Hz.
+    *   MUST have a maximum measurement frequency of 400 Hz or higher; SHOULD
+        support the SensorDirectChannel [`RATE_VERY_FAST`](
+        https://developer.android.com/reference/android/hardware/SensorDirectChannel.html#RATE_VERY_FAST).
+    *   MUST have a measurement noise not above 400 μg/√Hz.
     *   MUST implement a non-wake-up form of this sensor with a buffering
         capability of at least 3000 sensor events.
     *   MUST have a batching power consumption not worse than 3 mW.
-    *   SHOULD have a stationary noise bias stability of \<15 μg √Hz from 24hr static
-        dataset.
-    *   SHOULD have a bias change vs. temperature of ≤ +/- 1mg / °C.
+    *   [C-SR] Is STRONGLY RECOMMENDED to have 3dB measurement bandwidth of at
+        least 80% of Nyquist frequency, and white noise spectrum within this
+        bandwidth.
+    *   SHOULD have an acceleration random walk less than 30 μg √Hz tested at
+        room temperature.
+    *   SHOULD have a bias change vs. temperature of ≤ +/- 1 mg/°C.
     *   SHOULD have a best-fit line non-linearity of ≤ 0.5%, and sensitivity change vs. temperature of ≤
         0.03%/C°.
-    *   SHOULD have white noise spectrum to ensure adequate qualification
-        of sensor’s noise integrity.
+    *   SHOULD have cross-axis sensitivity of < 2.5 % and variation of
+        cross-axis sensitivity < 0.2% in device operation temperature range.
 
 *   [C-2-2] MUST have a `TYPE_ACCELEROMETER_UNCALIBRATED` with the same
 quality requirements as `TYPE_ACCELEROMETER`.
@@ -393,22 +410,29 @@
     *   MUST have a measurement range between at least -1000 and +1000 dps.
     *   MUST have a measurement resolution of at least 16 LSB/dps.
     *   MUST have a minimum measurement frequency of 12.5 Hz or lower.
-    *   MUST have a maximum measurement frequency of 400 Hz or higher.
+    *   MUST have a maximum measurement frequency of 400 Hz or higher; SHOULD
+        support the SensorDirectChannel [`RATE_VERY_FAST`](
+        https://developer.android.com/reference/android/hardware/SensorDirectChannel.html#RATE_VERY_FAST).
     *   MUST have a measurement noise not above 0.014°/s/√Hz.
-    *   SHOULD have a stationary bias stability of < 0.0002 °/s √Hz from 24-hour static dataset.
+    *   [C-SR] Is STRONGLY RECOMMENDED to have 3dB measurement bandwidth of at
+        least 80% of Nyquist frequency, and white noise spectrum within this
+        bandwidth.
+    *   SHOULD have a rate random walk less than 0.001 °/s √Hz tested at room
+        temperature.
     *   SHOULD have a bias change vs. temperature of ≤ +/- 0.05 °/ s / °C.
     *   SHOULD have a sensitivity change vs. temperature of ≤ 0.02% / °C.
     *   SHOULD have a best-fit line non-linearity of ≤ 0.2%.
     *   SHOULD have a noise density of ≤ 0.007 °/s/√Hz.
-    *   SHOULD have white noise spectrum to ensure adequate qualification
-        of sensor’s noise integrity.
     *   SHOULD have calibration error less than 0.002 rad/s in
         temperature range 10 ~ 40 ℃ when device is stationary.
-
+    *   SHOULD have g-sensitivity less than 0.1°/s/g.
+    *   SHOULD have cross-axis sensitivity of < 4.0 % and cross-axis sensitivity
+        variation < 0.3% in device operation temperature range.
 *   [C-2-4] MUST have a `TYPE_GYROSCOPE_UNCALIBRATED` with the same quality
 requirements as `TYPE_GYROSCOPE`.
+
 *   [C-2-5] MUST have a `TYPE_GEOMAGNETIC_FIELD` sensor which:
-    *   MUST have a measurement range between at least -900 and +900 uT.
+    *   MUST have a measurement range between at least -900 and +900 μT.
     *   MUST have a measurement resolution of at least 5 LSB/uT.
     *   MUST have a minimum measurement frequency of 5 Hz or lower.
     *   MUST have a maximum measurement frequency of 50 Hz or higher.
@@ -417,8 +441,9 @@
 requirements as `TYPE_GEOMAGNETIC_FIELD` and in addition:
     *   MUST implement a non-wake-up form of this sensor with a buffering
         capability of at least 600 sensor events.
-    *   SHOULD have white noise spectrum to ensure adequate qualification
-        of sensor’s noise integrity.
+    *   [C-SR] Is STRONGLY RECOMMENDED to have white noise spectrum from 1 Hz to
+        at least 10 Hz when the report rate is 50 Hz or higher.
+
 *   [C-2-7] MUST have a `TYPE_PRESSURE` sensor which:
     *   MUST have a measurement range between at least 300 and 1100 hPa.
     *   MUST have a measurement resolution of at least 80 LSB/hPa.
@@ -448,8 +473,10 @@
     *   MUST have a power consumption not worse than 0.5 mW when device is
         static and 1.5 mW when device is moving.
 *   [C-2-13] The event timestamp of the same physical event reported by the
-Accelerometer, Gyroscope sensor and Magnetometer MUST be within 2.5
-milliseconds of each other.
+Accelerometer, Gyroscope, and Magnetometer MUST be within 2.5 milliseconds
+of each other. The event timestamp of the same physical event reported by
+the Accelerometer and Gyroscope SHOULD be within 0.25 milliseconds of each
+other.
 *   [C-2-14] MUST have Gyroscope sensor event timestamps on the same time
 base as the camera subsystem and within 1 milliseconds of error.
 *   [C-2-15] MUST deliver samples to applications within 5 milliseconds from
@@ -556,12 +583,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..a3e168f 100644
--- a/7_hardware-compatibility/7_4_data-connectivity.md
+++ b/7_hardware-compatibility/7_4_data-connectivity.md
@@ -58,6 +58,27 @@
 
 If device implementations report `android.hardware.telephony`, they:
 
+*   [C-1-1] MUST support the `ConnectionService` APIs described in the [SDK](
+    https://developer.android.com/guide/topics/connectivity/telecom/selfManaged.html).
+*   [C-1-2] MUST display a new incoming call and provide user affordance to
+    accept or reject the incoming call when the user is on an ongoing call
+    that is made by a third-party app that does not support the hold feature
+    specified via
+    [`CAPABILITY_SUPPORT_HOLD`](
+    https://developer.android.com/reference/android/telecom/Connection.html#CAPABILITY_SUPPORT_HOLD).
+*   [C-SR] Are STRONGLY RECOMMENDED to notify the user that answering an
+    incoming call will drop an ongoing call.
+
+    The AOSP implementation meets these requirements by a heads-up notification
+    which indicates to the user that answering an incoming call will cause the
+    the other call to be dropped.
+
+*   [C-SR] Are STRONGLY RECOMMENDED to preload the default dialer app that
+    shows a call log entry and the name of a third-party app in its call log
+    when the third-party app sets the
+    [`EXTRA_LOG_SELF_MANAGED_CALLS`](
+    https://developer.android.com/reference/android/telecom/PhoneAccount.html#EXTRA_LOG_SELF_MANAGED_CALLS)
+    extras key on its `PhoneAccount` to `true`.
 *   [C-SR] Are STRONGLY RECOMMENDED to handle the the audio headset's
     `KEYCODE_MEDIA_PLAY_PAUSE` and `KEYCODE_HEADSETHOOK` events for the
     [`android.telecom`](https://developer.android.com/reference/android/telecom/package-summary.html)
@@ -70,6 +91,7 @@
         when a long press of the key event is detected during an incoming call.
     *   Toggle the mute status of the [`CallAudioState`](https://developer.android.com/reference/android/telecom/CallAudioState.html)
 
+
 ### 7.4.2\. IEEE 802.11 (Wi-Fi)
 
 Device implementations:
@@ -79,30 +101,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 +161,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 +199,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 +235,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 +260,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 +279,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 +307,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 +447,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
@@ -450,3 +535,12 @@
 *   [C-2-3] MUST have an activity that handles the
 `Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS`
     intent but MAY implement it as a no-op.
+
+### 7.4.8\. Secure Elements
+
+If device implementations support [Open Mobile API](https://developer.android.com/reference/android/se/omapi/package-summary)
+capable secure elements and make them available to 3rd-party apps, they:
+
+*   [C-1-1] MUST enumerate the available Secure Elements readers when
+[`android.se.omapi.SEService.getReaders()`](https://developer.android.com/reference/android/se/omapi/SEService#getReaders%28%29)
+method is called.
\ No newline at end of file
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_8_audio.md b/7_hardware-compatibility/7_8_audio.md
index 84c08b7..b1ec118 100644
--- a/7_hardware-compatibility/7_8_audio.md
+++ b/7_hardware-compatibility/7_8_audio.md
@@ -49,10 +49,12 @@
 #### 7.8.2.1\. Analog Audio Ports
 
 In order to be compatible with the [headsets and other audio accessories](
-http://source.android.com/accessories/headset-spec.html)
-using the 3.5mm audio plug across the Android ecosystem, if a device
-implementation includes one or more analog audio ports, at least one of the
-audio port(s) SHOULD be a 4 conductor 3.5mm audio jack.
+https://source.android.com/devices/accessories/headset/plug-headset-spec)
+using the 3.5mm audio plug across the Android ecosystem, if device
+implementations include one or more analog audio ports, they:
+
+*   [C-SR] Are STRONGLY RECOMMENDED to include at least one of the
+audio port(s) to be a 4 conductor 3.5mm audio jack.
 
 If device implementations have a 4 conductor 3.5mm audio jack, they:
 
@@ -71,13 +73,14 @@
 *   [C-1-5] MUST be capable of driving at least 150mV ± 10% of output voltage on
 a 32 ohm speaker impedance.
 *   [C-1-6] MUST have a microphone bias voltage between 1.8V ~ 2.9V.
-*   [SR] STRONGLY RECOMMENDED to detect and map to the keycode for the following
+*   [C-1-7] MUST detect and map to the keycode for the following
 range of equivalent impedance between the microphone and ground conductors
 on the audio plug:
     *   **110-180 ohm:** `KEYCODE_VOICE_ASSIST`
-*   SHOULD support audio plugs with the OMTP pin-out order.
-*   SHOULD support audio recording from stereo headsets with a microphone.
-
+*   [C-SR] Are STRONGLY RECOMMENDED to support audio plugs with the OMTP
+    pin-out order.
+*   [C-SR] Are STRONGLY RECOMMEND to support audio recording from stereo
+    headsets with a microphone.
 
 If device implementations have a 4 conductor 3.5mm audio jack and support a
 microphone, and broadcast the `android.intent.action.HEADSET_PLUG` with the
diff --git a/7_hardware-compatibility/7_9_virtual-reality.md b/7_hardware-compatibility/7_9_virtual-reality.md
index 1a8b632..ff9deb2 100644
--- a/7_hardware-compatibility/7_9_virtual-reality.md
+++ b/7_hardware-compatibility/7_9_virtual-reality.md
@@ -12,18 +12,16 @@
 a feature which handles stereoscopic rendering of notifications and disables
 monocular system UI components while a VR application has user focus.
 
-### 7.9.2\. Virtual Reality High Performance
+### 7.9.2\. Virtual Reality Mode - High Performance
 
-If device implementations identify the support of high performance VR
-for longer user periods through the `android.hardware.vr.high_performance`
-feature flag, they:
+If device implementations support VR mode, 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 declare the `android.hardware.vr.high_performance` feature.
 *   [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 +30,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 +41,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.
+*   [C-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 +98,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..e40d1b8 100644
--- a/9_security-model/9_10_device-integrity.md
+++ b/9_security-model/9_10_device-integrity.md
@@ -9,8 +9,15 @@
 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:
+*    [C-0-2] MUST support Verified Boot for device integrity.
+
+If device implementations are already launched without supporting Verified Boot
+on an earlier version of Android and can not add support for this
+feature with a system software update, they MAY be exempted from the
+requirement.
+
+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 +35,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.
@@ -48,15 +61,4 @@
 The upstream Android Open Source Project provides a preferred implementation of
 this feature in the [`external/avb/`](http://android.googlesource.com/platform/external/avb/)
 repository, which can be integrated into the boot loader used for loading
-Android.
-
-If device implementations report the feature flag [`android.hardware.ram.normal`](
-https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_RAM_NORMAL)
-, they:
-
-*    [C-2-1] MUST support verified boot for device integrity.
-
-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.
+Android.
\ No newline at end of file
diff --git a/9_security-model/9_11_keys-and-credentials.md b/9_security-model/9_11_keys-and-credentials.md
index d409563..67338a6 100644
--- a/9_security-model/9_11_keys-and-credentials.md
+++ b/9_security-model/9_11_keys-and-credentials.md
@@ -6,7 +6,7 @@
 or the [Keystore API](https://developer.android.com/reference/java/security/KeyStore.html).
 Device implementations:
 
-*    [C-0-1] MUST at least allow more than 8,192 keys to be imported.
+*    [C-0-1] MUST allow at least 8,192 keys to be imported or generated.
 *    [C-0-2] The lock screen authentication MUST rate-limit attempts and MUST
 have an exponential backoff algorithm. Beyond 150 failed attempts, the delay
 MUST be at least 24 hours per attempt.
@@ -14,7 +14,8 @@
 
 When the device implementation supports a secure lock screen, it:
 
-*    [C-1-1] MUST back up the keystore implementation with secure hardware.
+*    [C-1-1] MUST back up the keystore implementation with an isolated
+     execution environment.
 *    [C-1-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
@@ -41,10 +42,10 @@
 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
-hardware-backed keystore and support the key attestation, unless it declares
-the `android.hardware.fingerprint` feature which requires a hardware-backed
-keystore.
+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.
 
 ### 9.11.1\. Secure Lock Screen
 
@@ -132,7 +133,7 @@
 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`.
-*    [SR] Are STRONGLY RECOMMENDED to have spoof and imposter acceptance rates
+*    [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.
 
@@ -164,3 +165,75 @@
 [`DevicePolicyManager.setPasswordExpirationTimeout()`](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordExpirationTimeout%28android.content.ComponentName,%20long%29).
 *    [C-7-4] MUST NOT authenticate access to keystores if the application has
 called [`KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true)`](https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired%28boolean%29)).
+
+### 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.
+
+Device implementations:
+
+*    [C-SR] Are STRONGLY RECOMMENDED to support StrongBox.
+
+If device implementations support StrongBox, they:
+
+*    [C-1-1] MUST declare [FEATURE_STRONGBOX_KEYSTORE](
+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.
+
+*    [C-1-3] MUST have a discrete CPU that shares no cache, DRAM, coprocessors
+or other core resources with the application processor (AP).
+
+*    [C-1-4] MUST ensure that any peripherals shared with the AP cannot alter
+StrongBox processing in any way, or obtain any information from the StrongBox.
+The AP MAY disable or block access to StrongBox.
+
+*    [C-1-5] MUST have an internal clock with reasonable accuracy (+-10%)
+that is immune to manipulation by the AP.
+
+*    [C-1-6] MUST have a true random number generator that produces
+uniformly-distributed and unpredictable output.
+
+*    [C-1-7] MUST have tamper resistance, including resistance against
+physical penetration, and glitching.
+
+*    [C-1-8] MUST have side-channel resistance, including resistance against
+leaking information via power, timing, electromagnetic radiation, and thermal
+radiation side channels.
+
+*    [C-1-9] MUST have secure storage which ensures confidentiality,
+integrity, authenticity, consistency, and freshness of the
+contents. The storage MUST NOT be able to be read or altered, except
+as permitted by the StrongBox APIs.
+
+*    To validate compliance with [C-1-3] through [C-1-9], device
+     implementations:
+
+    *    [C-1-10] MUST include the hardware that is certified against the
+         Secure IC Protection Profile [BSI-CC-PP-0084-2014](
+         https://www.commoncriteriaportal.org/files/ppfiles/pp0084b_pdf.pdf) or
+         evaluated by a nationally accredited testing laboratory incorporating
+         High attack potential vulnerability assessment according to the
+         [Common Criteria Application of Attack Potential to Smartcards](
+       https://www.commoncriteriaportal.org/files/supdocs/CCDB-2013-05-002.pdf).
+    *    [C-1-11] MUST include the firmware that is evaluated by a
+         nationally accredited testing laboratory incorporating High attack
+         potential vulnerability assessment according to the
+         [Common Criteria Application of Attack Potential to Smartcards](
+         https://www.commoncriteriaportal.org/files/supdocs/CCDB-2013-05-002.pdf).
+    *    [C-SR] Are STRONGLY RECOMMENDED to include the hardware that is
+         evaluated using a Security Target, Evaluation Assurance Level
+         (EAL) 5, augmented by AVA_VAN.5.  EAL 5 certification will likely
+         become a requirement in a future release.
+
+*    [C-SR] are STRONGLY RECOMMENDED to provide insider attack resistance (IAR),
+which means that an insider with access to firmware signing keys cannot produce
+firmware that causes the StrongBox to leak secrets, to bypass functional
+security requirements or otherwise enable access to sensitive user data. The
+recommended way to implement IAR is to allow firmware updates only when the
+primary user password is provided via the IAuthSecret HAL. IAR will likely
+become a requirement in a future release.
\ No newline at end of file
diff --git a/9_security-model/9_7_kernel-security-features.md b/9_security-model/9_7_security-features.md
similarity index 87%
rename from 9_security-model/9_7_kernel-security-features.md
rename to 9_security-model/9_7_security-features.md
index 33151fb..c3e6f9f 100644
--- a/9_security-model/9_7_kernel-security-features.md
+++ b/9_security-model/9_7_security-features.md
@@ -1,4 +1,6 @@
-## 9.7\. Kernel Security Features
+## 9.7\. Security Features
+Device implementations MUST ensure compliance with security features in both the
+kernel and platform as described below.
 
 The Android Sandbox includes features that use the Security-Enhanced Linux
 (SELinux) mandatory access control (MAC) system, seccomp sandboxing, and other
@@ -83,3 +85,16 @@
 
 *   [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
+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/de
\ No newline at end of file
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..1fd7378 100644
--- a/9_security-model/9_9_full-disk-encryption.md
+++ b/9_security-model/9_9_full-disk-encryption.md
@@ -49,7 +49,7 @@
 (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
@@ -68,6 +68,9 @@
 
    *    [C-1-11] MUST use the mandatorily supported ciphers, key lengths and
    modes by default.
+*    [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.