diff --git a/2_device-types/2_2_handheld-reqs.md b/2_device-types/2_2_handheld-reqs.md
index 528a53c..5f079ac 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
@@ -38,8 +51,16 @@
 *   [[7.2](#7_2_input-devices).3/H-0-2] MUST send both the normal and long press
 event of the Back function ([`KEYCODE_BACK`](
 http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK))
-to the foreground application.
+to the foreground application. These events MUST NOT be consumed by the system
+and CAN be triggerred by outside of the Android device (e.g. external hardware
+keyboard connected to the Android device).
 *   [[7.2](#7_2_input-devices).4/H-0-1] MUST support touchscreen input.
+*   [[7.2](#7_2_input-devices).4/H-SR] Are STRONGLY RECOMMENDED to launch the
+user-selected assist app, in other words the app that implements
+VoiceInteractionService, or an activity handling the [`ACTION_ASSIST`](https://developer.android.com/reference/android/content/Intent#ACTION_ASSIST)
+on long-press of [`KEYCODE_MEDIA_PLAY_PAUSE`](https://developer.android.com/reference/android/view/KeyEvent#KEYCODE_MEDIA_PLAY_PAUSE)
+or [`KEYCODE_HEADSETHOOK`](https://developer.android.com/reference/android/view/KeyEvent#KEYCODE_HEADSETHOOK)
+if the foreground activity does not handle those long-press events.
 *  [[7.3](#7_3_sensors).1/H-SR] Are STRONGLY RECOMMENDED to include a 3-axis
 accelerometer.
 
@@ -155,24 +176,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,6 +219,18 @@
 
 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
@@ -255,6 +279,16 @@
 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
@@ -317,11 +351,15 @@
 performance of at least 15 MB/s.
 *   [[8.2](#8_2_file-io-access-performance)/H-0-4] MUST ensure a random read
 performance of at least 3.5 MB/s.
-*   [[8.3](#8_3_power-saving-modes)/H-0-1] All Apps exempted from App Standby
-and Doze power-saving modes MUST be made visible to the end user.
-*   [[8.3](#8_3_power-saving-modes)/H-0-2] The triggering, maintenance, wakeup
-algorithms and the use of global system settings of App Standby and Doze
-power-saving modes MUST not deviate from the Android Open Source Project.
+
+If Handheld device implementations include features to improve device power
+management that are included in AOSP or extend the features that are included
+in AOSP, they:
+
+* [[8.3](#8_3_power-saving-modes)/H-1-1] MUST provide user affordance to enable
+  and disable the battery saver feature.
+* [[8.3](#8_3_power-saving-modes)/H-1-2] MUST provide user affordance to display
+  all apps that are exempted from App Standby and Doze power-saving modes.
 
 Handheld device implementations:
 
@@ -361,3 +399,13 @@
 https://developer.android.com/reference/android/provider/Settings.html#ACTION&lowbar;USAGE&lowbar;ACCESS&lowbar;SETTINGS)
 intent.
 
+When Handheld device implementations support a secure lock screen, they:
+
+*   [[9.11](#9_11_permissions)/H-1-1] MUST allow the user to choose the shortest
+    sleep timeout, that is a transition time from the unlocked to the locked
+    state, as 15 seconds or less.
+*   [[9.11](#9_11_permissions)/H-1-2] MUST provide user affordance to hide
+    notifications and disable all forms of authentication except for the
+    primary authentication described in
+    [9.11.1 Secure Lock Screen](#9_11_1_secure-lock-screen). The AOSP meets the
+    requirement as lockdown mode.
\ No newline at end of file
diff --git a/2_device-types/2_3_television-reqs.md b/2_device-types/2_3_television-reqs.md
index 5ce2b20..0856947 100644
--- a/2_device-types/2_3_television-reqs.md
+++ b/2_device-types/2_3_television-reqs.md
@@ -224,7 +224,7 @@
 *    [[3.12](#3_12_tv-input-framework)/T-0-1] MUST support TV Input Framework.
 
 
-### 2.2.4\. Performance and Power
+### 2.3.4\. Performance and Power
 
 *   [[8.1](#8_1_user-experience-consistency)/T-0-1] **Consistent frame latency**.
    Inconsistent frame latency or a delay to render frames MUST NOT happen more
@@ -238,12 +238,14 @@
 *   [[8.2](#8_2_file-io-access-performance)/T-0-4] MUST ensure a random read
    performance of at least 3.5MB/s.
 
+If Television device implementations include features to improve device power
+management that are included in AOSP or extend the features that are included
+in AOSP, they:
 
-*   [[8.3](#8_3_power-saving-modes)/T-0-1] All apps exempted from App Standby
-and Doze power-saving modes MUST be made visible to the end user.
-*   [[8.3](#8_3_power-saving-modes)/T-0-2] The triggering, maintenance, wakeup
-algorithms and use of global system settings of App Standby and Doze
-power-saving modes MUST not deviate from the Android Open Source Project.
+* [[8.3](#8_3_power-saving-modes)/T-1-1] MUST provide user affordance to enable
+  and disable the battery saver feature.
+* [[8.3](#8_3_power-saving-modes)/T-1-2] MUST provide user affordance to display
+  all apps that are exempted from App Standby and Doze power-saving modes.
 
 Television device implementations:
 
diff --git a/2_device-types/2_4_watch-reqs.md b/2_device-types/2_4_watch-reqs.md
index 99468a9..aa5912a 100644
--- a/2_device-types/2_4_watch-reqs.md
+++ b/2_device-types/2_4_watch-reqs.md
@@ -81,11 +81,21 @@
 
 ### 2.4.4\. Performance and Power
 
+If Watch device implementations include features to improve device power
+management that are included in AOSP or extend the features that are included
+in AOSP, they:
+
+*   [[8.3](#8_3_power-saving-modes)/W-SR] Are STRONGLY RECOMMENDED to provide
+    user affordance to display all apps that are exempted from App Standby and
+    Doze power-saving modes.
+*   [[8.3](#8_3_power-saving-modes)/W-SR] Are STRONGLY RECOMMENDED to provide
+    user affordance to enable and disable the battery saver feature.
+
 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)
+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
diff --git a/2_device-types/2_5_automotive-reqs.md b/2_device-types/2_5_automotive-reqs.md
index b6f839e..9246a37 100644
--- a/2_device-types/2_5_automotive-reqs.md
+++ b/2_device-types/2_5_automotive-reqs.md
@@ -86,7 +86,10 @@
 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
@@ -208,10 +211,13 @@
 
 *   [[3](#3_0_intro)/A-0-1] MUST declare the feature
 `android.hardware.type.automotive`.
-*   [[3](#3_0_intro)/A-0-2] MUST support uiMode = [UI_MODE_TYPE_CAR](
+
+*   [[3](#3_0_intro)/A-0-2] MUST support uiMode = [`UI_MODE_TYPE_CAR`](
 http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR).
-*   [[3](#3_0_intro)/A-0-3] Android Automotive implementations MUST support all
-public APIs in the `android.car.*` namespace.
+
+*   [[3](#3_0_intro)/A-0-3] MUST support all public APIs in the
+[`android.car.*`](https://developer.android.com/reference/android/car/package-summary)
+namespace.
 
 *   [[3.4](#3_4_web-compatibility).1/A-0-1] MUST provide a complete
 implementation of the `android.webkit.Webview` API.
@@ -229,20 +235,38 @@
 *   [[3.13](#3_13_quick_settings)/A-SR] Are STRONGLY RECOMMENDED to include a
 Quick Settings UI component.
 
-*   [[3.14](#3_14_media_ui)/A-0-1] MUST include a UI framework to support
-third-party apps using the media APIs as described in section 3.14.
+If Automotive device implementations include a push-to-talk button, they:
 
-### 2.2.4\. Performance and Power
+*   [[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:
 
-*   [[8.3](#8_3_power-saving-modes)/A-0-1] All Apps exempted from App Standby
-and Doze power-saving modes MUST be made visible to the end user.
-*   [[8.3](#8_3_power-saving-modes)/A-0-2] The triggering, maintenance, wakeup
-algorithms and the use of global system settings of App Standby and Doze
-power-saving modes MUST not deviate from the Android Open Source Project.
+*   [[3.14](#3_14_media_ui)/A-0-1] MUST include a UI framework to support
+third-party apps using the media APIs as described in section
+[3.14](#3_14_media_ui).
 
+### 2.5.4\. Performance and Power
 
+If Automotive device implementations include features to improve device power
+management that are included in AOSP or extend the features that are included
+in AOSP, they:
+
+* [[8.3](#8_3_power-saving-modes)/A-1-1] MUST provide user affordance to enable
+  and disable the battery saver feature.
+* [[8.3](#8_3_power-saving-modes)/A-1-2] MUST provide user affordance to display
+  all apps that are exempted from App Standby and Doze power-saving modes.
+
+Automotive device implementations:
+
+*   [[8.2](#8.2_File I/O Access Performance)/A-0-1] MUST report the number of
+bytes read and written to non-volatile storage per each process's UID so the
+stats are available to developers through System API
+`android.car.storagemonitoring.CarStorageMonitoringManager`. The Android Open
+Source Project meets the requirement through the `uid_sys_stats` kernel module.
 *   [[8.4](#8_4_power-consumption-accounting)/A-0-1] MUST provide a
 per-component power profile that defines the [current consumption value](
 http://source.android.com/devices/tech/power/values.html)
@@ -261,15 +285,21 @@
 http://source.android.com/devices/tech/power/batterystats.html)
 shell command to the app developer.
 
-### 2.2.5\. Security Model
+### 2.5.5\. Security Model
 
 
-If Automotive device implementations include multiple users, they:
+If Automotive device implementations support multiple users, they:
 
 *   [[9.5](#9_5_multi-user-support)/A-1-1] MUST include a guest account that
 allows all functions provided by the vehicle system without requiring a user to
 log in.
 
+If Automotive device implementations support a secure lock screen, they:
+
+*   [[9.9](#9_9_full-disk-encryption).2/A-1-1] MUST support encryption per
+user-specific authentication keys. [File-Based Encryption (FBE)](
+https://source.android.com/security/encryption/file-based) is one way to do it.
+
 Automotive device implementations:
 
 *   [[9.14](#9_14_automotive-system-isolation)/A-0-1] MUST gatekeep messages
@@ -278,4 +308,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_15_instant-apps.md b/3_software/3_15_instant-apps.md
index f8d290f..1091e81 100644
--- a/3_software/3_15_instant-apps.md
+++ b/3_software/3_15_instant-apps.md
@@ -3,8 +3,9 @@
 Device implementations MUST satisfy the following requirements:
 
 *   [C-0-1] Instant Apps MUST only be granted permissions that have the
-    [`android:protectionLevel`](https://developer.android.com/guide/topics/manifest/permission-element.html#plevel)
-    set to `"ephemeral"`.
+    [`android:protectionLevel`](
+    https://developer.android.com/reference/android/R.attr#protectionLevel)
+    set to `"instant"`.
 *   [C-0-2] Instant Apps MUST NOT interact with installed apps via [implicit intents](https://developer.android.com/reference/android/content/Intent.html)
     unless one of the following is true:
     *   The component's intent pattern filter is exposed and has CATEGORY_BROWSABLE
diff --git a/3_software/3_17_Heavyweight_apps.md b/3_software/3_17_Heavyweight_apps.md
new file mode 100644
index 0000000..011b58a
--- /dev/null
+++ b/3_software/3_17_Heavyweight_apps.md
@@ -0,0 +1,31 @@
+## 3.17\. Heavyweight Apps
+
+If device implementations declare the feature [`FEATURE_CANT_SAVE_STATE`](
+https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_CANT_SAVE_STATE),
+then they:
+
+*    [C-1-1] MUST have only one installed app that specifies
+     [`cantSaveState`](https://developer.android.com/reference/android/R.attr#cantSaveState)
+     running in the system at a time. If the user
+     leaves such an app without explicitly exiting it (for example by pressing
+     home while leaving an active activity the system, instead of pressing back
+     with no remaining active activities in the system), then
+     device implementations MUST prioritize that app in RAM as they do for other
+     things that are expected to remain running, such as foreground services.
+     While such an app is in the background, the system can still apply power
+     management features to it, such as limiting CPU and network access.
+*    [C-1-2] MUST provide a UI affordance to chose the app that won't
+     participate in the normal state save/restore mechanism once the user
+     launches a second app declared with [`cantSaveState`](https://developer.android.com/reference/android/R.attr#cantSaveState)
+     attribute.
+*    [C-1-3] MUST NOT apply other changes in policy to apps that specify
+     [`cantSaveState`](https://developer.android.com/reference/android/R.attr#cantSaveState),
+     such as changing CPU performance or changing scheduling prioritization.
+
+If device implementations don't declare the feature [`FEATURE_CANT_SAVE_STATE`](
+https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_CANT_SAVE_STATE),
+then they:
+
+*    [C-1-1] MUST ignore the [`cantSaveState`](https://developer.android.com/reference/android/R.attr#cantSaveState)
+     attribute set by apps and MUST NOT change the app behavior based on that
+     attribute.
\ No newline at end of file
diff --git a/3_software/3_1_managed-api-compatibility.md b/3_software/3_1_managed-api-compatibility.md
index 05b95c2..92eb603 100644
--- a/3_software/3_1_managed-api-compatibility.md
+++ b/3_software/3_1_managed-api-compatibility.md
@@ -5,24 +5,43 @@
 set of Android platform interfaces exposed to applications running in the
 managed runtime environment.
 
-*    [C-0-1] Device implementations MUST provide complete implementations,
-including all documented behaviors, of any documented API exposed by the
-[Android SDK](http://developer.android.com/reference/packages.html)
-or any API decorated with the “@SystemApi” marker in the upstream Android
-source code.
+Device implementations:
 
-*    [C-0-2] Device implementations MUST support/preserve all classes,
-methods, and associated elements marked by the TestApi annotation (@TestApi).
+*    [C-0-1] MUST provide complete implementations, including all documented
+     behaviors, of any documented API exposed by the [Android SDK](
+     http://developer.android.com/reference/packages.html)
+     or any API decorated with the “@SystemApi” marker in the upstream Android
+     source code.
 
-*    [C-0-3] Device implementations MUST NOT omit any managed APIs, alter
-API interfaces or signatures, deviate from the documented behavior, or include
-no-ops, except where specifically allowed by this Compatibility Definition.
+*    [C-0-2] MUST support/preserve all classes, methods, and associated elements
+     marked by the TestApi annotation (@TestApi).
 
-*    [C-0-4]  Device implementations MUST still keep the APIs present and behave
+*    [C-0-3] MUST NOT omit any managed APIs, alter API interfaces or signatures,
+     deviate from the documented behavior, or include no-ops, except where
+     specifically allowed by this Compatibility Definition.
+
+*    [C-0-4] MUST still keep the APIs present and behave
      in a reasonable way, even when some hardware features for which Android
      includes APIs are omitted. See [section 7](#7_hardware_compatibility)
      for specific requirements for this scenario.
 
+*    [C-0-5] MUST restrict the use of 3rd-party app usage of hidden APIs,
+     defined as APIs in the android namespace decorated with the `@hidden`
+     annotation but not with a `@SystemAPI` or `@TestApi`, as described in the
+     [SDK documents](https://developer.android.com/preview/restrictions-non-sdk-interfaces)
+     and ship with each and every hidden API on the the same restricted lists as
+     provided via the light-greylist, dark-greylist, and blacklist files in the
+     `prebuilts/runtime/appcompat/` path for the appropriate API level branch
+     in the AOSP. However they:
+
+     *   MAY, if a hidden API is absent or implemented differently on the device
+         implementation, move the hidden API into the blacklist or omit it from
+         all restricted lists (i.e. light-grey, dark-grey, black).
+     *   MAY, if a hidden API does not already exist in the AOSP, add the hidden
+         API to any of the restricted lists (i.e. light-grey, dark-grey, black).
+     *   MAY implement a dynamic update mechanism that moves a hidden API from a
+         restricted list into a less restrictive list, except for the whitelist.
+    
 ## 3.1.1\. Android Extensions
 
 Android includes the support of extending the managed APIs while keeping the
@@ -33,3 +52,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 b414414..169347b 100644
--- a/3_software/3_2_soft-api-compatibility.md
+++ b/3_software/3_2_soft-api-compatibility.md
@@ -270,8 +270,9 @@
 
 *   [C-0-1] As Android is an extensible platform, device implementations MUST
 allow each intent pattern referenced in [section 3.2.3.1](#3_2_3_1_core_application_intents)
-to be overridden by third-party applications. The upstream Android open source
-implementation allows this by default.
+, except for Settings, to be overridden by third-party applications. The
+upstream Android open source implementation allows this by default.
+
 *   [C-0-2] Dvice implementers MUST NOT attach special privileges to system
 applications' use of these intent patterns, or prevent third-party applications
 from binding to and assuming control of these patterns. This prohibition
@@ -364,13 +365,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 1fe7f37..5a8eb57 100644
--- a/3_software/3_3_native-api-compatibility.md
+++ b/3_software/3_3_native-api-compatibility.md
@@ -24,20 +24,19 @@
 *   [C-0-3] MUST be source-compatible (i.e. header-compatible) and
     binary-compatible (for the ABI) with each required library in the list
     below.
-*   [C-0-4] MUST support the equivalent 32-bit ABI if any 64-bit ABI is
-    supported.
 *   [C-0-5]  MUST accurately report the native Application Binary Interface
     (ABI) supported by the device, via the `android.os.Build.SUPPORTED_ABIS`,
     `android.os.Build.SUPPORTED_32_BIT_ABIS`, and
     `android.os.Build.SUPPORTED_64_BIT_ABIS` parameters, each a comma separated
     list of ABIs ordered from the most to the least preferred one.
-*   [C-0-6] MUST report, via the above parameters, only those ABIs documented
-    and described in the latest version of the
-    [Android NDK ABI Management documentation](
-    https://developer.android.com/ndk/guides/abis.html), and MUST include
-    support for the [Advanced SIMD](
-    http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/Beijfcja.html)
-    (a.k.a. NEON) extension.
+*   [C-0-6] MUST report, via the above parameters, a subset of the following
+    list of ABIs and MUST NOT report any ABI not on the list.
+
+    *   `armeabi`
+    *   `armeabi-v7a`
+    *   `arm64-v8a`
+    *   `x86`
+    *   `x86-64`
 *   [C-0-7] MUST make all the following libraries, providing native APIs,
     available to apps that include native code:
 
@@ -78,7 +77,7 @@
     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.1 function
+*   [C-0-12] MUST export function symbols for the core Vulkan 1.0 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
@@ -88,32 +87,35 @@
 *   SHOULD be built using the source code and header files available in the
     upstream Android Open Source Project
 
-Note that future releases of the Android NDK may introduce support for
-additional ABIs.
+Note that future releases of Android may introduce support for additional
+ABIs.
 
 ### 3.3.2. 32-bit ARM Native Code Compatibility
 
-If device implementations are 64-bit ARM devices, then:
+If device implementations report the support of the `armeabi` ABI, they:
 
-*    [C-1-1] Although the ARMv8 architecture deprecates several CPU operations,
-     including some operations used in existing native code, the following
-     deprecated operations MUST remain available to 32-bit native ARM code,
-     either through native CPU support or through software emulation:
+*    [C-3-1] MUST also support `armeabi-v7a` and report its support, as
+     `armeabi` is only for backwards compatibility with older apps.
 
-     *   SWP and SWPB instructions
-     *   SETEND instruction
-     *   CP15ISB, CP15DSB, and CP15DMB barrier operations
+If device implementations report the support of the `armeabi-v7a` ABI, for apps
+using this ABI, they:
 
-If device implementations include a 32-bit ARM ABI, they:
-
-*    [C-2-1] MUST include the following lines in `/proc/cpuinfo` when it is read
-     by 32-bit ARM applications to ensure compatibility with applications built
-     using legacy versions of Android NDK.
+*    [C-2-1] MUST include the following lines in `/proc/cpuinfo`, and SHOULD NOT
+     alter the values on the same device, even when they are read by other ABIs.
 
      *   `Features: `, followed by a list of any optional ARMv7 CPU features
-     supported by the device.
+         supported by the device.
      *   `CPU architecture: `, followed by an integer describing the device's
-     highest supported ARM architecture (e.g., "8" for ARMv8 devices).
+         highest supported ARM architecture (e.g., "8" for ARMv8 devices).
 
-*    SHOULD not alter `/proc/cpuinfo` when read by 64-bit ARM or non-ARM
-     applications.
+*    [C-2-2] MUST always keep the following operations available, even in the
+     case where the ABI is implemented on an ARMv8 architecture, either through
+     native CPU support or through software emulation:
+
+     *   SWP and SWPB instructions.
+     *   SETEND instruction.
+     *   CP15ISB, CP15DSB, and CP15DMB barrier operations.
+
+*    [C-2-3] MUST include support for the [Advanced SIMD](
+     http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/Beijfcja.html)
+     (a.k.a. NEON) extension.
\ No newline at end of file
diff --git a/3_software/3_5_api-behavioral-compatibility.md b/3_software/3_5_api-behavioral-compatibility.md
index 0e5b9f9..0d51391 100644
--- a/3_software/3_5_api-behavioral-compatibility.md
+++ b/3_software/3_5_api-behavioral-compatibility.md
@@ -1,5 +1,14 @@
 ## 3.5\. API Behavioral Compatibility
 
+Device implementations:
+
+*    [C-0-9] MUST ensure that API behavioral compatibility is applied for all
+installed apps unless they are restricted as described in
+[Section 3.5.1](#3_5_1-background-restriction).
+*    [C-0-10] MUST NOT implement the whitelisting approach that ensures API
+behavioral compatibility only for apps that are selected by device
+implementers.
+
 The behaviors of each of the API types (managed, soft, native, and web) must be
 consistent with the preferred implementation of the upstream
 [Android Open Source Project](http://source.android.com/). Some specific areas
@@ -40,10 +49,65 @@
           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.
+
+## 3.5.1\. Background Restriction
+
+If device implementations implement the app restrictions that are included in
+AOSP or extend the app restrictions, they:
+
+*    [C-1-1] MUST provide user affordance where the user can see the list of
+restricted apps.
+*    [C-1-2] MUST provide user affordance to turn on / off the restrictions
+on each app.
+*    [C-1-3] MUST not automatically apply restrictions without evidence of poor
+system health behaviour, but MAY apply the restrictions on apps upon detection
+of poor system health behaviour like stuck wakelocks, long running services, and
+other criteria. The criteria MAY be determined by device implementers but MUST
+be related to the app’s impact on the system health. Other criteria that is not
+purely related to the　system health, such as the app’s lack of popularity in
+the market, MUST NOT be used as criteria.
+*    [C-1-4] MUST not automatically apply app restrictions for apps when a user
+has turned off app restrictions manually, and MAY suggest the user to apply
+app restrictions.
+*    [C-1-5] MUST inform users if app restrictions are applied to an app
+automatically.
+*    [C-1-6] MUST return `true` for [`ActivityManager.isBackgroundRestricted()`](
+https://developer.android.com/reference/android/app/ActivityManager.html#isBackgroundRestricted%28%29)
+when the restricted app calls this API.
+*    [C-1-7] MUST NOT restrict the top foreground app that is explicitly used
+by the user.
+*    [C-1-8] MUST suspend restrictions on an app that becomes the top foreground
+application when the user explicitly starts to use the app that used to be
+restricted.
+*    [C-1-9] MUST report all app restriction events via [`UsageStats`](
+https://developer.android.com/reference/android/app/usage/UsageStats). If device
+implementations extend the app restrictions that are implemented in AOSP, MUST
+follow the implementation described in [this document](
+https://souce.android.com/devices/tech/power/app_mgmt.html).
\ No newline at end of file
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 9b26cfe..76c32c2 100644
--- a/3_software/3_8_user-interface-compatibility.md
+++ b/3_software/3_8_user-interface-compatibility.md
@@ -276,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
 
@@ -450,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
 
diff --git a/3_software/3_9_device-administration.md b/3_software/3_9_device-administration.md
index 98f4030..f0d4a7b 100644
--- a/3_software/3_9_device-administration.md
+++ b/3_software/3_9_device-administration.md
@@ -83,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:
 
@@ -139,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 208b098..be0b3d7 100644
--- a/4_application-packaging/4_0_intro.md
+++ b/4_application-packaging/4_0_intro.md
@@ -50,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 21d917a..ea34d0c 100644
--- a/5_multimedia/5_1_media-codecs.md
+++ b/5_multimedia/5_1_media-codecs.md
@@ -186,7 +186,7 @@
 
 See more details in [5.1.6. Image Codecs Details](#5_1_6_image_codecs_details).
 
-Device impelementations MUST support encoding the following image decoding:
+Device impelementations MUST support decoding the following image encoding:
 
 *    [C-0-1] JPEG
 *    [C-0-2] GIF
@@ -194,6 +194,7 @@
 *    [C-0-4] BMP
 *    [C-0-5] WebP
 *    [C-0-6] Raw
+*    [C-0-7] HEIF (HEIC)
 
 ### 5.1.6\. Image Codecs Details
 
@@ -234,6 +235,11 @@
     <td>ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf),
         PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)</td>
  </tr>
+ <tr>
+    <td>HEIF</td>
+    <td>Image, Image collection, Image sequence</td>
+    <td>HEIF (.heif), HEIC (.heic)</td>
+ </tr>
 </table>
 
 
diff --git a/5_multimedia/5_6_audio-latency.md b/5_multimedia/5_6_audio-latency.md
index cefc797..5e0699d 100644
--- a/5_multimedia/5_6_audio-latency.md
+++ b/5_multimedia/5_6_audio-latency.md
@@ -46,35 +46,41 @@
 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
-*   [SR] The output timestamp returned by
+*   [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
-   *   [SR] Limit the error in input timestamps, as returned by
+   *   [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/6_dev-tools-and-options/6_1_developer_tools.md b/6_dev-tools-and-options/6_1_developer_tools.md
index 2e1477e..9b028e8 100644
--- a/6_dev-tools-and-options/6_1_developer_tools.md
+++ b/6_dev-tools-and-options/6_1_developer_tools.md
@@ -5,11 +5,41 @@
 *   [C-0-1] MUST support the Android Developer Tools provided in the Android
 SDK.
 *   [**Android Debug Bridge (adb)**](http://developer.android.com/tools/help/adb.html)
-    *   [C-0-2] MUST support all adb functions as documented in the Android
-    SDK including [dumpsys](https://source.android.com/devices/input/diagnostics.html).
+    *   [C-0-2] MUST support adb as documented in the Android SDK and the shell
+        commands provided in the AOSP, which can be used by app developers,
+        including [`dumpsys`](https://source.android.com/devices/input/diagnostics.html)
+        and `cmd stats`.
     *   [C-0-3] MUST NOT alter the format or the contents of device system
-    events (batterystats , diskstats, fingerprint, graphicsstats, netstats,
-    notification, procstats) logged via dumpsys.
+        events (batterystats , diskstats, fingerprint, graphicsstats, netstats,
+        notification, procstats) logged via the dumpsys command.
+    *   [C-0-10] MUST record, without ommmission, and make the following events
+        accessible and available to the `cmd stats` shell command and the
+        `StatsManager` System API class.
+        *   ActivityForegroundStateChanged
+        *   AnomalyDetected
+        *   AppBreadcrumbReported
+        *   AppCrashOccurred
+        *   AppStartOccurred
+        *   BatteryLevelChanged
+        *   BatterySaverModeStateChanged
+        *   BleScanResultReceived
+        *   BleScanStateChanged
+        *   ChargingStateChanged
+        *   DeviceIdleModeStateChanged
+        *   ForegroundServiceStateChanged
+        *   GpsScanStateChanged
+        *   JobStateChanged
+        *   PluggedStateChanged
+        *   ScheduledJobStateChanged
+        *   ScreenStateChanged
+        *   SyncStateChanged
+        *   SystemElapsedRealtime
+        *   UidProcessStateChanged
+        *   WakelockStateChanged
+        *   WakeupAlarmOccurred
+        *   WifiLockStateChanged
+        *   WifiMulticastLockStateChanged
+        *   WifiScanStateChanged
     *   [C-0-4] MUST have the device-side adb daemon be inactive by default and
     there MUST be a user-accessible mechanism to turn on the Android Debug
     Bridge.
@@ -32,6 +62,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 e90ee0c..3ab68d0 100644
--- a/7_hardware-compatibility/7_1_display-and-graphics.md
+++ b/7_hardware-compatibility/7_1_display-and-graphics.md
@@ -21,14 +21,16 @@
 
 ### 7.1.1\. Screen Configuration
 
-#### 7.1.1.1\. Screen Size
+#### 7.1.1.1\. Screen Size and Shape
 
 The Android UI framework supports a variety of different logical screen layout
 sizes, and allows applications to query the current configuration's screen
 layout size via `Configuration.screenLayout` with the `SCREENLAYOUT_SIZE_MASK`
 and `Configuration.smallestScreenWidthDp`.
 
-*    [C-0-1] Device implementations MUST report the correct layout size for the
+Device implementations:
+
+*    [C-0-1] MUST report the correct layout size for the
  `Configuration.screenLayout` as defined in the Android SDK documentation.
  Specifically, device implementations MUST report the correct logical
  density-independent pixel (dp) screen dimensions as below:
@@ -43,12 +45,22 @@
      *   Devices reporting a `xlarge` size for the `Configuration.screenLayout`,
      MUST have at least 960 dp x 720 dp.
 
-*   [C-0-2] Device implementations MUST correctly honor applications' stated
+*   [C-0-2] MUST correctly honor applications' stated
  support for screen sizes through the [&lt;`supports-screens`&gt;](
  https://developer.android.com/guide/topics/manifest/supports-screens-element.html)
  attribute in the AndroidManifest.xml, as described
  in the Android SDK documentation.
 
+*    MAY have a display with rounded corners.
+
+If device implementations support `UI_MODE_TYPE_NORMAL` and include a display
+with rounded corners, they:
+
+*    [C-1-1] MUST ensure that the radius of the rounded corners is less than or
+equal to 32 dp.
+*    SHOULD include user affordance to switch to the display mode with the
+rectangular corners.
+
 #### 7.1.1.2\. Screen Aspect Ratio
 
 While there is no restriction to the screen aspect ratio value of the physical
@@ -328,14 +340,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 4fe22cc..b452eff 100644
--- a/7_hardware-compatibility/7_3_sensors.md
+++ b/7_hardware-compatibility/7_3_sensors.md
@@ -26,10 +26,10 @@
 http://developer.android.com/reference/android/hardware/SensorEvent.html)
 using the relevant International System of Units (metric) values for each
 sensor type as defined in the Android SDK documentation.
-*   [C-1-2] MUST report sensor data with a maximum latency of 100 milliseconds
-+ 2 * sample_time for the case of a sensor streamed with a minimum required
-latency of 5 ms + 2 * sample_time when the application processor is active.
-This delay does not include any filtering delays.
+*   [C-1-2] MUST report sensor data with a maximum latency of 100
+milliseconds + 2 * sample_time for the case of a sensor streamed with a minimum
+required latency of 5 ms + 2 * sample_time when the application processor is
+active. This delay does not include any filtering delays.
 *   [C-1-3] MUST report the first sensor sample within 400 milliseconds + 2 *
 sample_time of the sensor being activated. It is acceptable for this sample to
 have an accuracy of 0.
@@ -203,12 +203,11 @@
     form of Assisted or Predicted GPS/GNSS technique
     to minimize GPS/GNSS lock-on time (Assistance data includes Reference Time,
     Reference Location and Satellite Ephemeris/Clock).
-       * [SR] After making such a location calculation, it is
-         STRONGLY RECOMMENDED for the device to
-         be able to determine its location, in open sky, within 10 seconds,
-         when location requests are restarted, up to an hour after the initial
-         location calculation, even when the subsequent request is made without
-         a data connection, and/or after a power cycle.
+       * [C-1-6] After making such a location calculation, device
+         implementations MUST determine its location, in open sky, within
+         5 seconds, when location requests are restarted, up to an hour after
+         the initial location calculation, even when the subsequent request is
+         made without a data connection, and/or after a power cycle.
 *   In open sky conditions after determining the location, while stationary or
     moving with less than 1 meter per second squared of acceleration:
 
@@ -229,7 +228,7 @@
 in GnssStatus messages), with the exception of SBAS.
 *    [SR] Report AGC, and Frequency of GNSS measurement.
 *    [SR] Report all accuracy estimates (including Bearing, Speed, and Vertical)
-as part of each GPS Location.
+as part of each GPS/GNSS location.
 *    [SR] are STRONGLY RECOMMENDED to meet as many as possible from the
 additional mandatory requirements for devices reporting the year "2016" or
 "2017" through the Test API `LocationManager.getGnssYearOfHardware()`.
@@ -239,9 +238,9 @@
 `LocationManager.getGnssYearOfHardware()` Test API reports the year "2016" or
 newer, they:
 
-*    [C-2-1] MUST report GPS measurements, as soon as they are found, even if a
+*    [C-2-1] MUST report GNSS measurements, as soon as they are found, even if a
 location calculated from GPS/GNSS is not yet reported.
-*    [C-2-2] MUST report GPS pseudoranges and pseudorange rates, that, in
+*    [C-2-2] MUST report GNSS pseudoranges and pseudorange rates, that, in
 open-sky conditions after determining the location, while stationary or moving
 with less than 0.2 meter per second squared of acceleration, are sufficient to
 calculate position within 20 meters, and speed within 0.2 meters per second,
@@ -259,8 +258,19 @@
      GnssStatus messages), with the exception of SBAS.
 *    [C-3-3] MUST report AGC, and Frequency of GNSS measurement.
 *    [C-3-4] MUST report all accuracy estimates (including Bearing, Speed, and
-Vertical) as part of each GPS Location.
+Vertical) as part of each GPS/GNSS location.
 
+If device implementations include a GPS/GNSS receiver and report the capability
+to applications through the `android.hardware.location.gps` feature flag and the
+`LocationManager.getGnssYearOfHardware()` Test API reports the year "2018" or
+newer, they:
+
+*    [C-4-1] MUST continue to deliver normal GPS/GNSS outputs to applications
+during a Mobile Station Based (MS-Based) Network Initiated emergency session
+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
 
@@ -371,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`.
@@ -394,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.
@@ -418,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.
@@ -449,14 +473,16 @@
     *   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
 the time when the data is available on any of the above physical sensors
 to the application.
-*   [C-2-16] MUST not have a power consumption higher than 0.5 mW
+*   [C-2-16] MUST NOT have a power consumption higher than 0.5 mW
 when device is static and 2.0 mW when device is moving
 when any combination of the following sensors are enabled:
     *   `SENSOR_TYPE_SIGNIFICANT_MOTION`
@@ -492,7 +518,9 @@
   *   `TYPE_MAGNETIC_FIELD`
   *   `TYPE_MAGNETIC_FIELD_UNCALIBRATED`
 
-### 7.3.10\. Fingerprint Sensor
+### 7.3.10\. Biometric Sensors
+
+#### 7.3.10.1\. Fingerprint Sensors
 
 If device implementations include a secure lock screen, they:
 
@@ -519,8 +547,8 @@
 a secure channel to the TEE.
 *   [C-1-7] MUST have all identifiable fingerprint data encrypted and
 cryptographically authenticated such that they cannot be acquired, read or
-altered outside of the Trusted Execution Environment (TEE) as documented in the
-[implementation guidelines](
+altered outside of the Trusted Execution Environment (TEE), or a chip with a
+secure channel to the TEE as documented in the [implementation guidelines](
 https://source.android.com/devices/tech/security/authentication/fingerprint-hal.html)
 on the Android Open Source Project site.
 *   [C-1-8] MUST prevent adding a fingerprint without first establishing a chain
@@ -534,6 +562,10 @@
 *   [C-1-11] MUST, when upgraded from a version earlier than Android 6.0, have
 the fingerprint data securely migrated to meet the above requirements or
 removed.
+*   [C-1-12] MUST completely remove all identifiable fingerprint data for a
+user when the user's account is removed (including via a factory reset).
+*   [C-1-13] MUST not allow unencrypted access to identifiable fingerprint data
+or any data derived from it (such as embeddings) to the Application Processor.
 *   [SR] Are STRONGLY RECOMMENDED to have a false rejection rate of less than 10%,
 as measured on the device.
 *   [SR] Are STRONGLY RECOMMENDED to have a latency below 1 second, measured from
@@ -542,6 +574,52 @@
 *   SHOULD use the Android Fingerprint icon provided in the Android Open Source
 Project.
 
+#### 7.3.10.2\. Other Biometric Sensors
+
+If device implementations include one or more non-fingerprint-based-biometric
+sensors and make them available to third-party apps they:
+
+*   [C-1-1] MUST have a false acceptance rate not higher than 0.002%.
+*   [C-SR] Are STRONGLY RECOMMENDED to have a spoof and imposter acceptance rate
+not higher than 7%.
+*   [C-1-2] MUST disclose that this mode may be less secure than a strong PIN,
+pattern, or password and clearly enumerate the risks of enabling it, if the
+spoof and imposter acceptance rates are higher than 7%.
+*   [C-1-3] MUST rate limit attempts for at least 30 seconds after five false
+trials for biometric verification - where a false trial is one with an adequate
+capture quality
+(ACQUIRED_GOOD) that does not match an enrolled biometric
+*   [C-1-4] MUST have a hardware-backed keystore implementation, and perform the
+biometric matching in a Trusted Execution Environment (TEE) or on a chip with
+a secure channel to the TEE.
+* [C-1-5] MUST have all identifiable data encrypted and cryptographically
+authenticated such that they cannot be acquired, read or altered outside of the
+Trusted Execution Environment (TEE), or a chip with a secure channel to the TEE
+as documented in the [implementation guidelines](
+https://source.android.com/devices/tech/security/authentication/fingerprint-hal.html)
+on the Android Open Source Project site.
+* [C-1-6] MUST prevent adding new biometrics without first establishing a chain
+of trust by having the user confirm existing or add a new device credential
+(PIN/pattern/password) that's secured by TEE; the Android Open Source Project
+implementation provides the mechanism in the framework to do so.
+*   [C-1-7] MUST NOT enable third-party applications to distinguish between
+biometric enrollments.
+*   [C-1-8] MUST honor the individual flag for that biometric (ie:
+`DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT`,
+`DevicePolicymanager.KEYGUARD_DISABLE_FACE`, or
+`DevicePolicymanager.KEYGUARD_DISABLE_IRIS`).
+*   [C-1-9] MUST completely remove all identifiable biometric data for a user when
+the user's account is removed (including via a factory reset).
+*   [C-1-10] MUST not allow unencrypted access to identifiable biometric data or any
+data derived from it (such as embeddings) to the Application Processor outside
+the context of the TEE.
+*   [C-SR] Are STRONGLY RECOMMENDED to have a false rejection rate of less than 10%,
+as measured on the device.
+*   [C-SR] Are STRONGLY RECOMMENDED to have a latency below 1 second, measured from
+when the biometric is detected, until the screen is unlocked, for each
+enrolled biometric.
+
+
 ### 7.3.11\. Android Automotive-only sensors
 
 Automotive-specific sensors are defined in the
diff --git a/7_hardware-compatibility/7_4_data-connectivity.md b/7_hardware-compatibility/7_4_data-connectivity.md
index a6ef4d1..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,16 +101,31 @@
 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.
+*   [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.
@@ -104,6 +141,13 @@
     * 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:
@@ -117,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
 
@@ -263,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:
@@ -485,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_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/8_performance-and-power/8_3_power-saving-modes.md b/8_performance-and-power/8_3_power-saving-modes.md
index 6268303..f5d90ba 100644
--- a/8_performance-and-power/8_3_power-saving-modes.md
+++ b/8_performance-and-power/8_3_power-saving-modes.md
@@ -1,19 +1,39 @@
 ## 8.3\. Power-Saving Modes
 
-Android includes App Standby and Doze power-saving modes to optimize battery
-usage.
-*   [SR] All Apps exempted from these modes are STRONGLY RECOMMENDED to be made
-visible to the end user.
-*   [SR] The triggering, maintenance, wakeup algorithms and the use of
-global system settings of these power-saving modes are STRONGLY RECOMMENDED NOT
-to deviate from the Android Open Source Project.
+If device implementations include features to improve device power management
+that are included in AOSP or extend the features that are included in AOSP,
+they:
+
+*   [C-1-1] MUST NOT deviate from the AOSP implementation for the triggering,
+    maintenance, wakeup algorithms and the use of global system settings of App
+    Standby and Doze power-saving modes.
+*   [C-1-2] MUST NOT deviate from the AOSP implementation for the use of global
+    settings to manage the throttling of jobs, alarm and network for apps in
+    each bucket for App standby.
+*   [C-1-3] MUST NOT deviate from the AOSP implementation for the number of the
+    [App Standby Buckets](
+    https://developer.android.com/topic/performance/appstandby) used for App
+    Standby.
+*   [C-1-4] MUST implement [App Standby Buckets](
+    https://developer.android.com/topic/performance/appstandby) and Doze as
+    described in [Power Management](
+    https://source.android.com/devices/tech/power/mgmt).
+*   [C-1-5] MUST return `true` for [`PowerManager.isPowerSaveMode()`](
+    https://developer.android.com/reference/android/os/PowerManager#isPowerSaveMode%28%29)
+    when the device is on power save mode.
+*   [C-SR] Are STRONGLY RECOMMENDED to provide user affordance to enable and
+    disable the battery saver feature.
+*   [C-SR] Are STRONGLY RECOMMENDED to provide user affordance to display all
+    Apps that are exempted from App Standby and Doze power-saving modes.
 
 In addition to the power-saving modes, Android device implementations MAY
 implement any or all of the 4 sleeping power states as defined by the Advanced
 Configuration and Power Interface (ACPI).
 
-If device implementations implements S3 and S4 power states as defined by the
+If device implementations implement S3 and S4 power states as defined by the
 ACPI, they:
 
-*   [C-1-1] MUST only enter these states when closing a lid that is physically
-    part of the device.
+*   [C-1-1] MUST enter these states only after the user has taken an explicit action
+    to put the device in an inactive state (e.g. by closing a lid that is physically
+    part of the device or turning off a vehicle or television) and before the user re-activates the
+    device (e.g. by opening the lid or turning the vehicle or television back on).
\ No newline at end of file
diff --git a/9_security-model/9_10_device-integrity.md b/9_security-model/9_10_device-integrity.md
index 1d7698b..366b7bd 100644
--- a/9_security-model/9_10_device-integrity.md
+++ b/9_security-model/9_10_device-integrity.md
@@ -9,6 +9,13 @@
 reserved for device implementations upgrading from an earlier version of Android
 where this new system API method did not exist.
 
+*    [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:
 
@@ -31,15 +38,14 @@
 *    [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.
-*    [C-SR] Are STRONGLY RECOMMENDED to use tamper-evident storage: for when the
+*    [C-1-8] MUST use tamper-evident storage: for storing whether 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).
-*    [C-SR] Are STRONGLY RECOMMENDED to prompt the user, while using the device, and
+detect if the storage has been tampered with from inside Android.
+*    [C-1-9] MUST 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.
-*    [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
+*    [C-1-10] MUST implement rollback protection for partitions used by Android
+(e.g. boot, system partitions) and use tamper-evident storage for storing the
 metadata used for determining the minimum allowable OS version.
 *    [C-SR] Are STRONGLY RECOMMENDED to verify all privileged app APK files with
 a chain of trust rooted in `/system`, which is protected by Verified Boot.
@@ -51,18 +57,42 @@
 firmware (e.g. modem, camera) and SHOULD use tamper-evident storage for
 storing the metadata used for determining the minimum allowable version.
 
+If device implementations are already launched without supporting C-1-8 through
+C-1-10 on an earlier version of Android and can not add support for
+these requirements with a system software update, they MAY be exempted from the
+requirements.
+
 The upstream Android Open Source Project provides a preferred implementation of
-this feature in the [`external/avb/`](http://android.googlesource.com/platform/external/avb/)
+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`](
+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.
+*    [C-2-1] MUST support verified boot for device integrity.
 
-If a device implementation is already launched without supporting Verified Boot
+If a device implementation is already launched without supporting verified boot
 on an earlier version of Android, such a device can not add support for this
 feature with a system software update and thus are exempted from the
 requirement.
+
+Device implementations:
+
+*    [C-R] Are RECOMMENDED to support the [Android Protected Confirmation API](
+https://developer.android.com/preview/features/security.html#user-confirmation).
+
+If device implementations support the Android Protected Confirmation
+API they:
+
+*    [C-3-1] MUST report `true` for the [`ConfirmationPrompt.isSupported()`](
+https://developer.android.com/reference/android/security/ConfirmationPrompt.html#isSupported%28android.content.Context%29)
+API.
+*    [C-3-2] MUST ensure that secure hardware takes full control of display in
+such a way that Android OS cannot block it without detection by the
+secure hardware.
+*    [C-3-3] MUST ensure that secure hardware takes full control of the touch
+screen.
diff --git a/9_security-model/9_11_keys-and-credentials.md b/9_security-model/9_11_keys-and-credentials.md
index d409563..7b314dc 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
@@ -39,128 +40,278 @@
 requirement is to share the same attestation key unless at least 100,000 units
 of a given SKU are produced. If more than 100,000 units of an SKU are produced,
 a different key MAY be used for each 100,000 units.
+*    [C-1-5] MUST allow the user to choose the Sleep timeout for transition from
+     the unlocked to the locked state, with a minimum allowable timout up to
+     15 seconds.
 
 Note that if a device implementation is already launched on an earlier Android
-version, such a device is exempted from the requirement to have a
-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
 
-If device implementations have a secure lock screen and include one or more
-trust agent, which implements the `TrustAgentService` System API, then they:
+The AOSP implementation follows a tiered authentication model where a
+knowledge-factory based primary authentication can be backed by either a
+secondary strong biometric, or by weaker tertiary modalities.
 
-*    [C-1-1] MUST indicate the user in the Settings and Lock screen user
-interface of situations where either the screen auto-lock is deferred or the
-screen lock can be unlocked by the trust agent. The AOSP meets the requirement
-by showing a text description for the "Automatically lock setting" and
-"Power button instantly locks setting" menus and a distinguishable icon on
-the lock screen.
-*    [C-1-2] MUST respect and fully implement all trust agent APIs in the
-`DevicePolicyManager` class, such as the [`KEYGUARD_DISABLE_TRUST_AGENTS`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#KEYGUARD&lowbarDISABLE&lowbarTRUST&lowbarAGENTS)
-constant.
-*    [C-1-3] MUST NOT fully implement the `TrustAgentService.addEscrowToken()`
-function on a device that is used as the primary personal device
-(e.g. handheld) but MAY fully implement the function on device implementations
-typically shared.
-*    [C-1-4] MUST encrypt the tokens added by `TrustAgentService.addEscrowToken()`
-before storing them on the device.
-*    [C-1-5] MUST NOT store the encryption key on the device.
-*    [C-1-6] MUST inform the user about the security implications before
-enabling the escrow token to decrypt the data storage.
+Device implementations:
 
-If device implementations add or modify the authentication methods to unlock
-the lock screen, then for such an authentication method to be treated as a
-secure way to lock the screen, they:
+*    [C-SR] Are STRONGLY RECOMMENDED to set only one of the following as the primary authentication
+method:
+     *     A numerical PIN,
+     *     An alphanumerical password, or
+     *     A swipe pattern on a grid of exactly 3x3 dots.
+
+Note that the above authentication methods are referred as the recommended
+primary authentication methods in this document.
+
+If device implementations add or modify the recommended primary authentication
+methods and use a new authentication method as a secure way to lock the screen,
+the new authentication method:
 
 *    [C-2-1] MUST be the user authentication method as described in
-[Requiring User Authentication For Key Use](https://developer.android.com/training/articles/keystore.html#UserAuthentication).
+     [Requiring User Authentication For Key Use](
+     https://developer.android.com/training/articles/keystore.html#UserAuthentication).
 *    [C-2-2] MUST unlock all keys for a third-party developer app to use when
-the user unlocks the secure lock screen. For example, all keys MUST be available
-for a third-party developer app through relevant APIs, such as
-[`createConfirmDeviceCredentialIntent`](https://developer.android.com/reference/android/app/KeyguardManager.html#createConfirmDeviceCredentialIntent%28java.lang.CharSequence, java.lang.CharSequence%29)
-and [`setUserAuthenticationRequired`](https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired%28boolean%29).
+     the user unlocks the secure lock screen. For example, all keys MUST be
+     available for a third-party developer app through relevant APIs, such as
+     [`createConfirmDeviceCredentialIntent`](
+     https://developer.android.com/reference/android/app/KeyguardManager.html#createConfirmDeviceCredentialIntent%28java.lang.CharSequence, java.lang.CharSequence%29)
+     and [`setUserAuthenticationRequired`](
+     https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired%28boolean%29).
 
 If device implementations add or modify the authentication methods to unlock
-the lock screen if based on a known secret then for such an authentication
-method to be treated as a secure way to lock the screen, they:
+the lock screen if based on a known secret and use a new authentication
+method to be treated as a secure way to lock the screen:
 
 *    [C-3-1] The entropy of the shortest allowed length of inputs MUST be
-greater than 10 bits.
+     greater than 10 bits.
 *    [C-3-2] The maximum entropy of all possible inputs MUST be greater than
-18 bits.
-*    [C-3-3] MUST not replace any of the existing authentication methods
-(PIN,pattern, password) implemented and provided in AOSP.
-*    [C-3-4] MUST be disabled when the Device Policy Controller (DPC)
-application has set the password quality policy via the
-[`DevicePolicyManager.setPasswordQuality()`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordQuality%28android.content.ComponentName,%20int%29)
-method with a more restrictive quality constant than
-`PASSWORD_QUALITY_SOMETHING`.
+     18 bits.
+*    [C-3-3] The new authentication method MUST NOT replace any of the
+     recommended primary authentication methods (i.e. PIN, pattern, password)
+     implemented and provided in AOSP.
+*    [C-3-4] The new authentication method MUST be disabled when the Device
+     Policy Controller (DPC) application has set the password quality policy
+     via the
+     [`DevicePolicyManager.setPasswordQuality()`](
+     https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordQuality%28android.content.ComponentName,%20int%29)
+     method with a more restrictive quality constant than
+    `PASSWORD_QUALITY_SOMETHING`.
+
+If device implementations add or modify the recommended primary authentication
+methods to unlock the lock screen and use a new authentication method that is
+based on biometrics to be treated as a secure way to lock the screen, the new
+method:
+
+*    [C-4-1] MUST meet all requirements described in
+     [section 7.3.10.2](#7_3_10_2_other_biometric_sensors).
+*    [C-4-2] MUST have a fall-back mechanism to use one of the recommended
+     primary authentication methods which is based on a known secret.
+*    [C-4-3] MUST be disabled and only allow the recommended primary
+     authentication to unlock the screen when the Device Policy Controller (DPC)
+     application has set the keguard feature policy by calling the method
+     [`DevicePolicyManager.setKeyguardDisabledFeatures()`](
+     http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setKeyguardDisabledFeatures%28android.content.ComponentName,%20int%29)
+     , with any of the associated biometric flags (i.e.
+     `KEYGUARD_DISABLE_BIOMETRICS`, `KEYGUARD_DISABLE_FINGERPRINT`,
+     `KEYGUARD_DISABLE_FACE`, or `KEYGUARD_DISABLE_IRIS`).
+*    [C-4-4] MUST challenge the user for the recommended primary authentication
+     (e.g. PIN, pattern, password) at least once very 72 hours or less.
+*    [C-4-5] MUST have a false acceptance rate that is equal or stronger than
+     what is required for a fingerprint sensor as described in section
+     [section 7.3.10](#7_3_10_biometric_sensors),
+     or otherwise
+     MUST be disabled and only allow the recommended primary authentication
+     to unlock the screen when the Device Policy Controller (DPC) application
+     has set the password quality policy via the
+    [`DevicePolicyManager.setPasswordQuality()`](
+    https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html\#setPasswordQuality%28android.content.ComponentName,%20int%29)
+    method with a more restrictive quality constant than
+   `PASSWORD_QUALITY_BIOMETRIC_WEAK`.
+*    [C-SR] Are STRONGLY RECOMMENDED to have spoof and imposter acceptance rates
+     that are equal to or stronger than what is required for a fingerprint
+     sensor as described in [section 7.3.10](#7_3_10_biometric_sensors).
+*    [C-4-6] MUST have a secure processing pipeline such that an operating
+     system or kernel compromise cannot allow data to be directly injected to
+     falsely authenticate as the user.
+*    [C-4-7] MUST be paired with an explicit confirm action (eg: a button press)
+     to allow access to keystore keys if the application sets `true` for
+     [`KeyGenParameterSpec.Built.setUserAuthenticationRequired()`](
+     https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired%28boolean%29)
+     and the biometric is passive (e.g. face or iris where no explicit
+     signal of intent exists).
+*    [C-SR] The confirm action for passive biometrics is STRONGLY RECOMMENDED to
+     be secured such that an operating system or kernel compromise cannot spoof
+     it. For example, this means that the confirm action based on a physical
+     button is routed through an input-only general-purpose input/output (GPIO)
+     pin of a secure element (SE) that cannot be driven by any other means
+     than a physical button press.
+
+If the biometric authentication methods do not meet the spoof and imposter
+acceptance rates as described in [section 7.3.10](#7_3_10_biometric_sensors):
+
+*    [C-5-1] The methods MUST be disabled if the Device Policy Controller (DPC)
+     application has set the password quality policy via the [`DevicePolicyManager.setPasswordQuality()`](
+     https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html\#setPasswordQuality%28android.content.ComponentName,%20int%29)
+     method with a more restrictive quality constant than
+     `PASSWORD_QUALITY_BIOMETRIC_WEAK`.
+*    [C-5-2] The user MUST be challenged for the recommended primary
+     authentication (eg: PIN, pattern, password) after any 4-hour idle timeout
+     period. The idle timeout period is reset after any successful confirmation
+     of the device credentials.
+*    [C-5-3] The methods MUST NOT be treated as a secure lock screen, and MUST
+     meet the requirements that start with C-8 in this section below.
 
 If device implementations add or modify the authentication methods to unlock
-the lock screen if based on a physical token or the location, then for such an
-authentication method to be treated as a secure way to lock the screen, they:
+the lock screen and a new authentication method is based on a physical token
+or the location:
 
-*    [C-4-1] MUST have a fall-back mechanism to use one of the primary
-authentication methods which is based on a known secret and meets the
-requirements to be treated as a secure lock screen.
-*    [C-4-2] MUST be disabled and only allow the primary authentication to
-unlock the screen when the Device Policy Controller (DPC) application has set
-the policy with either the [`DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)`](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setKeyguardDisabledFeatures%28android.content.ComponentName,%20int%29)
-method or 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_UNSPECIFIED`.
-*    [C-4-3] The user MUST be challenged for the primary authentication
-(e.g.PIN, pattern, password) at least once every 72 hours or less.
+*    [C-6-1] They MUST have a fall-back mechanism to use one of the recommended
+     primary authentication methods which is based on a known secret and meet
+     the requirements to be treated as a secure lock screen.
+*    [C-6-2] The new method MUST be disabled and only allow one of the
+     recommended primary authentication methods to unlock the screen when the
+     Device Policy Controller (DPC) application has set the policy with either
+     the
+     [`DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)`](
+     http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setKeyguardDisabledFeatures%28android.content.ComponentName,%20int%29)
+     method or 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_UNSPECIFIED`.
+*    [C-6-3] The user MUST be challenged for one of the recommended primary
+     authentication methods (e.g.PIN, pattern, password) at least once every 72
+     hours or less.
+*    [C-6-4] The new method MUST NOT be treated as a secure lock screen and MUST
+     follow the constraints listed in C-8 below.
+
+If device implementations have a secure lock screen and include one or more
+trust agent, which implements the `TrustAgentService` System API, they:
+
+*    [C-7-1] MUST have clear indication in the settings menu and on the lock
+     screen when device lock is deferred or can be unlocked by trust agent(s).
+     For example, AOSP meets this requirement by showing a text description for
+     the "Automatically lock setting" and "Power button instantly locks" in the
+     settings menu and a distinguishable icon on the lock screen.
+*    [C-7-2] MUST respect and fully implement all trust agent APIs in the
+     `DevicePolicyManager` class, such as the
+     [`KEYGUARD_DISABLE_TRUST_AGENTS`](
+     https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#KEYGUARD&lowbarDISABLE&lowbarTRUST&lowbarAGENTS)
+     constant.
+*    [C-7-3] MUST NOT fully implement the `TrustAgentService.addEscrowToken()`
+     function on a device that is used as a primary personal device
+     (e.g. handheld) but MAY fully implement the function on device
+     implementations that are typically shared (e.g. Android Television or
+     Automotive device).
+*    [C-7-4] MUST encrypt all stored tokens added by
+     `TrustAgentService.addEscrowToken()`.
+*    [C-7-5] MUST NOT store the encryption key on the same device where the key
+     is used. For example, it is allowed for a key stored on a phone to unlock a
+     user account on a TV.
+*    [C-7-6] MUST inform the user about the security implications before
+     enabling the escrow token to decrypt the data storage.
+*    [C-7-7] MUST have a fall-back mechanism to use one of the recommended
+     primary authentication methods.
+*    [C-7-8] The user MUST be challenged for one of the recommended primary
+     authentication (eg: PIN, pattern, password) methods at least once every 72
+     hours or less.
+*    [C-7-9] The user MUST be challenged for one of the recommended primary
+     authentication (eg: PIN, pattern, password) methods after any 4-hour idle
+     timeout period. The idle timeout period is reset after any successful
+     confirmation of the device credentials.
+*    [C-7-10] MUST NOT be treated as a secure lock screen and MUST follow the
+     constraints listed in C-8 below.
 
 If device implementations add or modify the authentication methods to unlock
-the lock screen based on biometrics, then for such an authentication method to
-be treated as a secure way to lock the screen, they:
+the lock screen that is not a secure lock screen as described above, and use
+a new authentication method to unlock the keyguard:
 
-*    [C-5-1] MUST have a fall-back mechanism to use one of the primary
-authentication methods which is based on a known secret and meets the
-requirements to be treated as a secure lock screen.
-*    [C-5-2] MUST be disabled and only allow the primary authentication to
-unlock the screen when the Device Policy Controller (DPC) application has set
-the keguard feature policy by calling the method
-[`DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT)`](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setKeyguardDisabledFeatures%28android.content.ComponentName,%20int%29).
-*    [C-5-3] MUST have a false acceptance rate that is equal or stronger than
-what is required for a fingerprint sensor as described in section 7.3.10, or
-otherwise MUST be disabled and only allow the primary authentication to unlock
-the screen when the Device Policy Controller (DPC) application has set the
-password quality policy via the [`DevicePolicyManager.setPasswordQuality()`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html\#setPasswordQuality%28android.content.ComponentName,%20int%29)
-method with a more restrictive quality constant than
-`PASSWORD_QUALITY_BIOMETRIC_WEAK`.
-*    [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.
+*    [C-8-1] The new method MUST be disabled when the Device Policy Controller
+     (DPC) application has set the password quality policy via the
+     [`DevicePolicyManager.setPasswordQuality()`](
+     https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordQuality%28android.content.ComponentName,%20int%29)
+     method with a more restrictive quality constant than
+     `PASSWORD_QUALITY_UNSPECIFIED`.
+*    [C-8-2] They MUST NOT reset the password expiration timers set by
+     [`DevicePolicyManager.setPasswordExpirationTimeout()`](
+     http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordExpirationTimeout%28android.content.ComponentName,%20long%29).
+*    [C-8-3] They MUST NOT authenticate access to keystores when the application
+     sets `true` for
+     [`KeyGenParameterSpec.Builder.setUserAuthenticationRequired()`](
+     https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired%28boolean%29)).
 
-If the spoof and imposter acceptance rates are not equal to or stronger than
-what is required for a fingerprint sensor as described in
-[section 7.3.10](#7_3_10_fingerprint_sensor) and the Device Policy
-Controller (DPC) application has set the password quality policy via the
-[`DevicePolicyManager.setPasswordQuality()`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html\#setPasswordQuality%28android.content.ComponentName,%20int%29)
-method with a more restrictive quality constant than
-`PASSWORD_QUALITY_BIOMETRIC_WEAK`, then:
+### 9.11.2\. StrongBox
 
-*    [C-6-1] MUST disable these biometric methods and allow only the primary
-authentication to unlock the screen.
-*    [C-6-2] MUST challenge the user for the primary authentication
-(e.g.PIN, pattern, password) at least once every 72 hours or less.
+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.
 
-If device implementations add or modify the authentication methods to unlock
-the lock screen and if such an authentication method will be used to unlock
-the keyguard, but will not be treated as a secure lock screen, then they:
+Device implementations:
 
-*    [C-7-1] MUST return `false` for both the [`KeyguardManager.isKeyguardSecure()`](http://developer.android.com/reference/android/app/KeyguardManager.html#isKeyguardSecure%28%29)
-and the [`KeyguardManager.isDeviceSecure()`](https://developer.android.com/reference/android/app/KeyguardManager.html#isDeviceSecure%28%29)
-methods.
-*    [C-7-2] MUST be disabled when the Device Policy Controller (DPC)
-application has set the password quality policy via the [`DevicePolicyManager.setPasswordQuality()`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordQuality%28android.content.ComponentName,%20int%29)
-method with a more restrictive quality constant than
-`PASSWORD_QUALITY_UNSPECIFIED`.
-*    [C-7-3] MUST NOT reset the password expiration timers set by
-[`DevicePolicyManager.setPasswordExpirationTimeout()`](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordExpirationTimeout%28android.content.ComponentName,%20long%29).
-*    [C-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)).
+*    [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_1_permissions.md b/9_security-model/9_1_permissions.md
index 525e9d5..7e6610c 100644
--- a/9_security-model/9_1_permissions.md
+++ b/9_security-model/9_1_permissions.md
@@ -37,7 +37,15 @@
        uses it
    *   the runtime permissions are associated with an intent pattern
        for which the preinstalled application is set as the default handler
-
+*   [C-0-6] MUST grant the `android.permission.RECOVER_KEYSTORE` permission
+     only to system apps that register a properly secured Recovery Agent. A
+     properly secured Recovery Agent is defined as an on-device software agent
+     that synchronizes with an off-device remote storage, that is equipped with
+     secure hardware with protection equivalent or stronger than what is
+     described in
+     [Google Cloud Key Vault Service](
+     https://developer.android.com/preview/features/security/ckv-whitepaper.html)
+     to prevent brute-force attacks on the lockscreen knowledge factor.
 
 If device implementations include a pre-installed app or wish to allow
 third-party apps to access the usage statistics, they:
diff --git a/9_security-model/9_7_kernel-security-features.md b/9_security-model/9_7_security-features.md
similarity index 86%
rename from 9_security-model/9_7_kernel-security-features.md
rename to 9_security-model/9_7_security-features.md
index 1c44acf..84db962 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
@@ -48,9 +50,8 @@
 kernel outside of normal usercopy access APIs (e.g. hardware PAN, or
 emulated via `CONFIG_CPU_SW_DOMAIN_PAN` or `CONFIG_ARM64_SW_TTBR0_PAN`)
 on devices originally shipping with API level 28 or higher.
-*   [C-0-12] MUST implement kernel page table isolation on all devices with CPUs
-vulnerable to CVE-2017-5754 (Meltdown), and on all devices with kernel versions
-4.4 or higher on devices originally shipping with API level 28 or higher
+*   [C-0-12] MUST implement kernel page table isolation on all devices
+originally shipping with API level 28 or higher
 (e.g. `CONFIG_PAGE_TABLE_ISOLATION` or `CONFIG_UNMAP_KERNEL_AT_EL0).
 *   [SR] STRONGLY RECOMMENDED to keep kernel data
 which is written only during initialization marked read-only after
@@ -84,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 8990a82..61a9b5f 100644
--- a/9_security-model/9_8_privacy.md
+++ b/9_security-model/9_8_privacy.md
@@ -8,11 +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.
 
+Android stores the system events using the [`StatsLog`](https://developer.android.com/reference/android/util/StatsLog.html)
+identifiers, and manages such history via the `StatsManager` and the
+`IncidentManager` System API.
+
+Device implementations:
+
+*   [C-0-2] MUST only include the fields marked with `DEST_AUTOMATIC` in the
+    incident report created by the System API class `IncidentManager`.
+*   [C-0-3] MUST not use the system event identifiers to log any other event
+    than what is described in the [`StatsLog`](https://developer.android.com/reference/android/util/StatsLog.html)
+    SDK documents. If additional system events are logged, they MAY use a
+    different atom identifier in the range between 100,000 and 200,000.
 
 ### 9.8.2\. Recording
 
diff --git a/9_security-model/9_9_full-disk-encryption.md b/9_security-model/9_9_full-disk-encryption.md
index 8a14713..60e39ba 100644
--- a/9_security-model/9_9_full-disk-encryption.md
+++ b/9_security-model/9_9_full-disk-encryption.md
@@ -1,22 +1,23 @@
 ## 9.9\. Data Storage Encryption
 
-If device implementations support a secure lock screen as described in
-[section 9.11.1](#9_11_1_secure_lock_screen), they:
+If Advanced Encryption Standard (AES) crypto performance, measured with the most
+performant AES technology available on the device (e.g. the ARM Cryptography
+Extensions), is above 50 MiB/sec, device implementations:
 
 *   [C-1-1] MUST support data storage encryption of the application private
-data (`/data partition`), as well as the application shared storage partition
-(`/sdcard partition`) if it is a permanent, non-removable part of the device.
+data (`/data` partition), as well as the application shared storage partition
+(`/sdcard` partition) if it is a permanent, non-removable part of the device,
+except for device implementations that are typically shared (e.g.
+Television).
+*   [C-1-2] MUST enable the data storage encryption by default at the time
+the user has completed the out-of-box setup experience, except for device
+implementations that are typically shared (e.g. Television).
 
-If device implementations support a secure lock screen as described in
-[section 9.11.1](#9_11_1_secure_lock_screen) and support data storage
-encryption with Advanced Encryption Standard (AES) crypto performance
-above 50MiB/sec, they:
+If device implementations are already launched on an earlier Android version
+and cannot meet the requirement through a system software update, they MAY be
+exempted from the above requirements.
 
-*    [C-2-1] MUST enable the data storage encryption by default at the time
-the user has completed the out-of-box setup experience. If device
-implementations are already launched on an earlier Android version with
-encryption disabled by default, such a device cannot meet the requirement
-through a system software update and thus MAY be exempted.
+Device implementations:
 
 *    SHOULD meet the above data storage encryption
 requirement via implementing [File Based Encryption](
@@ -49,13 +50,14 @@
 (eg. passcode, pin, pattern or fingerprint) and the `ACTION_USER_UNLOCKED`
 message is broadcasted.
 *    [C-1-3] MUST NOT offer any method to unlock the CE protected storage
-without the user-supplied credentials.
+without either the user-supplied credentials or a registered escrow key.
 *    [C-1-4] MUST support Verified Boot and ensure that DE keys are
 cryptographically bound to the device's hardware root of trust.
-*    [C-1-5] MUST support encrypting file contents using AES with a key length
-of 256-bits in XTS mode.
-*    [C-1-6] MUST support encrypting file name using AES with a key length of
-256-bits in CBC-CTS mode.
+*    [C-1-5] MUST support encrypting file contents using AES-256-XTS.
+AES-256-XTS refers to the Advanced Encryption Standard with
+a 256-bit key length, operated in XTS mode.  The full length of the XTS key
+is 512 bits.
+*    [C-1-6] MUST support encrypting file names using AES-256 in CBC-CTS mode.
 
 *   The keys protecting CE and DE storage areas:
 
@@ -68,6 +70,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.
@@ -83,12 +88,12 @@
 http://source.android.com/devices/tech/security/encryption/index.html)
 (FDE), they:
 
-*   [C-1-1] MUST use AES with a key of 128-bits (or greater) and a mode
-designed for storage (for example, AES-XTS, AES-CBC-ESSIV).
+*   [C-1-1] MUST use AES in a mode designed for storage (for example, XTS
+or CBC-ESSIV), and with a cipher key length of 128 bits or greater.
 *   [C-1-2] MUST use a default passcode to wrap the encryption key and
 MUST NOT write the encryption key to storage at any time
 without being encrypted.
-   *   [C-1-3] MUST AES encrypt the encryption key by default unless the user
+*   [C-1-3] MUST AES encrypt the encryption key by default unless the user
    explicitly opts out, except when it is in active use, with the lock screen
    credentials stretched using a slow stretching algorithm
    (e.g. PBKDF2 or scrypt).