Merge Android Pie into master

Bug: 112104996
Change-Id: I60cfa304a7ee4baeb2d0c47f91350af8410612ef
diff --git a/2_device-types/2_1_device-configurations.md b/2_device-types/2_1_device-configurations.md
index 883d049..6b04ddd 100644
--- a/2_device-types/2_1_device-configurations.md
+++ b/2_device-types/2_1_device-configurations.md
@@ -1,132 +1,4 @@
 ## 2.1 Device Configurations
 
-This is a summary of major differences in hardware configuration by device
-type. (Empty cells denote a “MAY”). Not all configurations are covered in this
-table; see relevant hardware sections for more detail.
-
-<table>
- <tr>
-    <th>Category</th>
-    <th>Feature</th>
-    <th>Section</th>
-    <th>Handheld</th>
-    <th>Television</th>
-    <th>Watch</th>
-    <th>Automotive</th>
-    <th>Other</th>
- </tr>
- <tr>
-    <td rowspan="3">Input</td>
-    <td>D-pad</td>
-    <td><a href="#7_2_2_non-touch-navigation">7.2.2. Non-touch Navigation</a></td>
-    <td></td>
-    <td>MUST</td>
-    <td></td>
-    <td></td>
-    <td></td>
- </tr>
- <tr>
-    <td>Touchscreen </td>
-    <td><a href="#7_2_4_touchscreen_input">7.2.4. Touchscreen input</a></td>
-    <td>MUST</td>
-    <td></td>
-    <td>MUST</td>
-    <td></td>
-    <td>SHOULD</td>
- </tr>
- <tr>
-    <td>Microphone </td>
-    <td><a href="#7_8_1_microphone">7.8.1. Microphone</a></td>
-    <td>MUST</td>
-    <td>SHOULD </td>
-    <td>MUST</td>
-    <td>MUST</td>
-    <td>SHOULD</td>
- </tr>
- <tr>
-    <td rowspan="2">Sensors</td>
-    <td>Accelerometer </td>
-    <td><a href="#7_3_1_accelerometer">7.3.1 Accelerometer</a></td>
-    <td>SHOULD</td>
-    <td></td>
-    <td>SHOULD</td>
-    <td></td>
-    <td>SHOULD</td>
- </tr>
- <tr>
-    <td>GPS</td>
-    <td><a href="#7_3_3_gps">7.3.3. GPS</a></td>
-    <td>SHOULD</td>
-    <td></td>
-    <td></td>
-    <td>SHOULD</td>
-    <td></td>
- </tr>
- <tr>
-    <td rowspan="5">Connectivity</td>
-    <td>Wi-Fi</td>
-    <td><a href="#7_4_2_ieee_802.11">7.4.2. IEEE 802.11</a></td>
-    <td>SHOULD</td>
-    <td>SHOULD</td>
-    <td></td>
-    <td>SHOULD</td>
-    <td>SHOULD</td>
- </tr>
- <tr>
-    <td>Wi-Fi Direct</td>
-    <td><a href="#7_4_2_1_wi-fi-direct">7.4.2.1. Wi-Fi Direct</a></td>
-    <td>SHOULD</td>
-    <td>SHOULD</td>
-    <td></td>
-    <td></td>
-    <td>SHOULD</td>
- </tr>
- <tr>
-    <td>Bluetooth</td>
-    <td><a href="#7_4_3_bluetooth">7.4.3. Bluetooth</a></td>
-    <td>SHOULD</td>
-    <td>MUST</td>
-    <td>MUST</td>
-    <td>MUST</td>
-    <td>SHOULD</td>
- </tr>
- <tr>
-    <td>Bluetooth Low Energy</td>
-    <td><a href="#7_4_3_bluetooth">7.4.3. Bluetooth</a></td>
-    <td>SHOULD</td>
-    <td>MUST</td>
-    <td>SHOULD</td>
-    <td>SHOULD</td>
-    <td>SHOULD</td>
- </tr>
- <tr>
-    <td>Cellular radio</td>
-    <td><a href="#7_4_5_minimum_network_capability">
-      7.4.5. Minimum Network Capability</a></td>
-    <td></td>
-    <td></td>
-    <td></td>
-    <td>SHOULD</td>
-    <td></td>
- </tr>
- <tr>
-    <td>USB</td>
-    <td>USB peripheral/host mode</td>
-    <td><a href="#7_7_usb">7.7. USB</a></td>
-    <td>SHOULD</td>
-    <td></td>
-    <td></td>
-    <td>SHOULD</td>
-    <td>SHOULD</td>
- </tr>
- <tr>
-    <td>Output</td>
-    <td>Speaker and/or Audio output ports</td>
-    <td><a href="#7_8_2_audio_output">7.8.2. Audio Output</a></td>
-    <td>MUST</td>
-    <td>MUST</td>
-    <td></td>
-    <td>MUST</td>
-    <td>MUST</td>
- </tr>
-</table>
+For the major differences in hardware configuration by device
+type, see the device-specific requirements that follow in this section.
diff --git a/2_device-types/2_2_handheld-reqs.md b/2_device-types/2_2_handheld-reqs.md
index e61222c..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,13 +219,26 @@
 
 Handheld device implementations:
 
+*   [[3.2.3.1](#3_2_3_1_core-application-intents)/H-0-1] MUST have an
+application that handles the [`ACTION_GET_CONTENT`](
+https://developer.android.com/reference/android/content/Intent.html#ACTION_GET_CONTENT),
+[`ACTION_OPEN_DOCUMENT`](
+https://developer.android.com/reference/android/content/Intent#ACTION_OPEN_DOCUMENT),
+[`ACTION_OPEN_DOCUMENT_TREE`](
+https://developer.android.com/reference/android/content/Intent.html#ACTION_OPEN_DOCUMENT_TREE),
+and [`ACTION_CREATE_DOCUMENT`](
+https://developer.android.com/reference/android/content/Intent.html#ACTION_CREATE_DOCUMENT)
+intents as described in the SDK documents, and provide the user affordance
+to access the document provider data by using [`DocumentsProvider`](
+https://developer.android.com/reference/android/provider/DocumentsProvider) API.
 *   [[3.4](#3_4_web-compatibility).1/H-0-1] MUST provide a complete
 implementation of the `android.webkit.Webview` API.
 *   [[3.4](#3_4_web-compatibility).2/H-0-1] MUST include a standalone Browser
 application for general user web browsing.
 *   [[3.8](#3_8_user-interface-compatibility).1/H-SR] Are STRONGLY RECOMMENDED
-to implement a default launcher that supports in-app pinning of shortcuts and
-widgets.
+to implement a default launcher that supports in-app pinning of shortcuts,
+widgets and [widgetFeatures](
+https://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html#widgetFeatures).
 *   [[3.8](#3_8_user-interface-compatibility).1/H-SR] Are STRONGLY RECOMMENDED
 to implement a default launcher that provides quick access to the additional
 shortcuts provided by third-party apps through the [ShortcutManager](
@@ -237,10 +262,33 @@
 notification shade, providing the user the ability to directly control (e.g.
 reply, snooze, dismiss, block) the notifications through user affordance such as
 action buttons or the control panel as implemented in the AOSP.
+*   [[3.8](#3_8_user-interface-compatibility).3/H-0-5] MUST display the choices
+provided through [`RemoteInput.Builder setChoices()`](
+https://developer.android.com/reference/android/app/RemoteInput.Builder.html#setChoices%28java.lang.CharSequence[]%29)
+in the notification shade.
+*   [[3.8](#3_8_user-interface-compatibility).3/H-SR] Are STRONGLY RECOMMENDED
+to display the first choice provided through [`RemoteInput.Builder setChoices()`](
+https://developer.android.com/reference/android/app/RemoteInput.Builder.html#setChoices%28java.lang.CharSequence[]%29)
+in the notification shade without additional user interaction.
+*   [[3.8](#3_8_user-interface-compatibility).3/H-SR] Are STRONGLY RECOMMENDED
+to display all the choices provided through [`RemoteInput.Builder setChoices()`](
+https://developer.android.com/reference/android/app/RemoteInput.Builder.html#setChoices%28java.lang.CharSequence[]%29)
+in the notification shade when the user expands all notifications in the
+notification shade.
 *   [[3.8](#3_8_user-interface-compatibility).4/H-SR] Are STRONGLY RECOMMENDED
 to implement an assistant on the device to handle the [Assist action](
 http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST).
 
+If Handheld device implementations support Assist action, they:
+
+*   [[3.8](#3_8_user-interface-compatibility).4/H-SR] Are STRONGLY RECOMMENDED
+to use long press on `HOME` key as the designated interaction to launch the
+assist app as described in [section 7.2.3](#7_2_3_navigation_keys) MUST launch
+the user-selected assist app, in other words the app that implements
+[`VoiceInteractionService`](
+https://developer.android.com/reference/android/service/voice/VoiceInteractionService)
+, or an activity handling the `ACTION_ASSIST` intent.
+
 If Android Handheld device implementations support a lock screen, they:
 
 *   [[3.8](#3_8_user-interface-compatibility).10/H-1-1] MUST display the Lock
@@ -252,6 +300,11 @@
 [device administration](
 http://developer.android.com/guide/topics/admin/device-admin.html)
 policies defined in the Android SDK documentation.
+*   [[3.9](#3_9_device-administration)/H-1-2]  MUST declare the support of
+managed profiles via the `android.software.managed_users` feature flag, except when the device is configured so that it would [report](
+http://developer.android.com/reference/android/app/ActivityManager.html#isLowRamDevice%28%29)
+itself as a low RAM device or so that it allocates internal (non-removable)
+storage as shared storage.
 
 Handheld device implementations:
 
@@ -298,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:
 
@@ -342,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 ddb7a9e..0856947 100644
--- a/2_device-types/2_3_television-reqs.md
+++ b/2_device-types/2_3_television-reqs.md
@@ -1,4 +1,3 @@
-## 2.3\. Television Requirements
 
 An **Android Television device** refers to an Android device implementation that
 is an entertainment interface for consuming digital media, movies, games, apps,
@@ -50,6 +49,12 @@
 non-volatile storage available for application private data
 (a.k.a. "/data" partition).
 
+If Television device implementations include a USB port that supports host mode,
+they:
+
+*   [[7.5](#7_5_camera).3/T-1-1] MUST include support for an external camera
+that connects through this USB port but is not necessarily always connected.
+
 If TV device implementations are 32-bit:
 
 *   [[7.6](#7_6_memory-and-storage).1/T-1-1] The memory available to the kernel
@@ -82,100 +87,69 @@
 
 ### 2.3.2\. Multimedia
 
-Television device implementations MUST support the following audio encoding:
+Television device implementations MUST support the following audio encoding formats:
 
 *    [[5.1](#5_1_media-codecs)/T-0-1] MPEG-4 AAC Profile (AAC LC)
 *    [[5.1](#5_1_media-codecs)/T-0-2] MPEG-4 HE AAC Profile (AAC+)
 *    [[5.1](#5_1_media-codecs)/T-0-3] AAC ELD (enhanced low delay AAC)
 
 
-Television device implementations MUST support the following video encoding:
+Television device implementations MUST support the following video encoding formats:
 
-*    [[5.2](#5_2_video-encoding)/T-0-1] H.264 AVC
+*    [[5.2](#5_2_video-encoding)/T-0-1] H.264 
 *    [[5.2](#5_2_video-encoding)/T-0-2] VP8
 
 Television device implementations:
 
 *   [[5.2](#5_2_video-encoding).2/T-SR] Are STRONGLY RECOMMENDED to support
-H.264 encoding of 720p and 1080p resolution videos.
-*   [[5.2](#5_2_video-encoding)2/T-SR] Are STRONGLY RECOMMENDED to support H.264
-encoding of 1080p resolution video at 30 frame-per-second (fps).
+H.264 encoding of 720p and 1080p resolution videos at 30 frames per second.
 
-Television device implementations MUST support the following video decoding:
+Television device implementations MUST support the following video decoding formats:
 
-*    [[5.3](#5_3_video-decoding)/T-0-1] H.264 AVC
-*    [[5.3](#5_3_video-decoding)/T-0-2] H.265 HEVC
-*    [[5.3](#5_3_video-decoding)/T-0-3] MPEG-4 SP
-*    [[5.3](#5_3_video-decoding)/T-0-4] VP8
-*    [[5.3](#5_3_video-decoding)/T-0-5] VP9
+*    [[5.3.3](#5_3_video-decoding)/T-0-1] MPEG-4 SP
+*    [[5.3.4](#5_3_video-decoding)/T-0-2] H.264 AVC
+*    [[5.3.5](#5_3_video-decoding)/T-0-3] H.265 HEVC
+*    [[5.3.6](#5_3_video-decoding)/T-0-4] VP8
+*    [[5.3.7](#5_3_video-decoding)/T-0-5] VP9
 
 Television device implementations are STRONGLY RECOMMENDED to support the
-following video decoding:
+following video decoding formats:
 
-*    [[5.3](#5_3_video-decoding)/T-SR] MPEG-2
+*    [[5.3.1](#5_3_video-decoding)/T-SR] MPEG-2
 
+Television device implementations MUST support H.264 decoding, as detailed in Section 5.3.4, 
+at standard video frame rates and resolutions up to and including:
 
-If Television device implementations support H.264 decoders, they:
+*   [[5.3.4](#5_3_video-decoding).4/T-1-1] HD 1080p at 60 frames per second with Basline Profile
+*   [[5.3.4](#5_3_video-decoding).4/T-1-2] HD 1080p at 60 frames per second with Main Profile 
+*   [[5.3.4](#5_3_video-decoding).4/T-1-3] HD 1080p at 60 frames per second with High Profile Level 4.2
 
-*   [[5.3](#5_3_video-decoding).4/T-1-1] MUST support High Profile Level 4.2 and
-the HD 1080p (at 60 fps) decoding profile.
-*   [[5.3](#5_3_video-decoding).4/T-1-2] MUST be capable of decoding videos with
-both HD profiles as indicated in the following table and encoded with either the
-Baseline Profile, Main Profile, or the High Profile Level 4.2
+Television device implementations  with H.265 hardware decoders MUST support H.265 decoding, 
+as detailed in Section 5.3.5, at standard video frame rates and resolutions up to and including:
 
-If Television device implementations support H.265 codec and the HD 1080p
-decoding profile, they:
+*   [[5.3.5](#5_3_video-decoding).4/T-1-1] HD 1080p at 60 frames per second with Main Profile Level 4.1
 
-*   [[5.3](#5_3_video-decoding).5/T-1-1] MUST support the Main Profile Level 4.1
-Main tier.
-*   [[5.3](#5_3_video-decoding).5/T-SR] Are STRONGLY RECOMMENDED to support 60
-fps video frame rate for HD 1080p.
+If Television device implementations with H.265 hardware decoders support 
+H.265 decoding and the UHD decoding profile, they:
 
-If Television device implementations support H.265 codec and the UHD decoding
-profile, then:
-
-*   [[5.3](#5_3_video-decoding).5/T-2-1] The codec MUST support Main10 Level 5
+*   [[5.3.5](#5_3_video-decoding).5/T-2-1] MUST support UHD 3480p at 60 frames per second with Main10 Level 5
 Main Tier profile.
 
-If Television device implementations support VP8 codec, they:
+Television device implementations MUST support VP8 decoding, as detailed in Section 5.3.6, 
+at standard video frame rates and resolutions up to and including:
 
-*   [[5.3](#5_3_video-decoding).6/T-1-1] MUST support the HD 1080p60 decoding
-profile.
+*   [[5.3.6](#5_3_video-decoding).4/T-1-1] HD 1080p at 60 frames per second decoding profile
 
-If Television device implementations support VP8 codec and support 720p, they:
+Television device implementations  with VP9 hardware decoders MUST support VP9 decoding, as detailed in Section 5.3.7, 
+at standard video frame rates and resolutions up to and including:
 
-*   [[5.3](#5_3_video-decoding).6/T-2-1] MUST support the HD 720p60 decoding
-profile.
+*   [[5.3.7](#5_3_video-decoding).4/T-1-1] HD 1080p at 60 frames per second with profile 0 (8 bit colour depth) 
 
+If Television device implementations with VP9 hardware decoders support VP9 decoding and the UHD decoding
+profile, they:
 
-If Television device implementations support VP9 codec and the UHD video
-decoding, they:
-
-*   [[5.3](#5_3_video-decoding).7/T-1-1] MUST support 8-bit color depth and
-SHOULD support VP9 Profile 2
-(10-bit).
-
-If Television device implementations support VP9 codec, the 1080p profile and
-VP9 hardware decoding, they:
-
-*   [[5.3](#5_3_video-decoding).7/T-2-1] MUST support 60 fps for 1080p.
-
-Television device implementations:
-
-*    [[5.8](#5_8_secure-media)/T-SR] Are STRONGLY RECOMMENDED to support
-simultaneous decoding of secure streams. At minimum, simultaneous decoding of
-two steams is STRONGLY RECOMMENDED.
-
-If device implementations are Android Television devices and support 4K
-resolution, they:
-
-*    [[5.8](#5_8_secure-media)/T-1-1] MUST support HDCP 2.2 for all wired
-external displays.
-
-If Television device implementations don't support 4K resolution, they:
-
-*    [[5.8](#5_8_secure-media)/T-2-1] MUST support HDCP 1.4 for all wired
-external displays.
+*   [[5.3.7](#5_3_video-decoding).5/T-2-1] MUST support UHD 3480p at 60 frames per second with profile 0 (8 bit colour depth).
+*   [[5.3.7](#5_3_video-decoding).5/T-2-1] Are STRONGLY RECOMMENDED to support UHD 3480p at 60 frames per second with profile 2 (10 bit colour depth).
 
 Television device implementations:
 
@@ -183,6 +157,28 @@
 Volume and digital audio output volume attenuation on supported outputs,
 except for compressed audio passthrough output (where no audio decoding is done
 on the device).
+*    [[5.8](#5_8_secure-media)/T-0-1] MUST set the HDMI output mode to
+select the maximum resolution that can be supported with either 50Hz or 60Hz
+refresh rate for all wired displays.
+*    [[5.8](#5_8_secure-media)/T-SR] Are STRONGLY RECOMMENDED to provide a user
+configurable HDMI refresh rate selector for all wired displays.
+*    [[5.8](#5_8_secure-media)/T-SR] Are STRONGLY RECOMMENDED to support
+simultaneous decoding of secure streams. At minimum, simultaneous decoding of
+two steams is STRONGLY RECOMMENDED.
+*    [[5.8](#5_8_secure-media)] SHOULD set the HDMI output mode refresh rate
+to either 50Hz or 60Hz, depending on the video refresh rate for the region the
+device is sold in for all wired displays.
+
+If Television device implementations support UHD decoding and have support
+for external displays, they:
+
+*    [[5.8](#5_8_secure-media)/T-1-1] MUST support HDCP 2.2.
+
+If Television device implementations do not support UHD decoding but have
+support for external displays, they:
+
+*    [[5.8](#5_8_secure-media)/T-2-1] MUST support HDCP 1.4
+
 
 
 ### 2.3.3\. Software
@@ -228,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
@@ -242,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:
 
@@ -267,4 +265,4 @@
 *   [[8.4](#8_4_power-consumption-accounting)/T-0-4] MUST make this power usage
 available via the [`adb shell dumpsys batterystats`](
 http://source.android.com/devices/tech/power/batterystats.html)
-shell command to the app developer.
\ No newline at end of file
+shell command to the app developer.
diff --git a/2_device-types/2_4_watch-reqs.md b/2_device-types/2_4_watch-reqs.md
index 8c9b588..aa5912a 100644
--- a/2_device-types/2_4_watch-reqs.md
+++ b/2_device-types/2_4_watch-reqs.md
@@ -41,11 +41,11 @@
 
 ### 2.4.2\. Multimedia
 
-To be added.
+No additional requirements.
 
 ### 2.4.3\. Software
 
-Android Watch device implementations:
+Watch device implementations:
 
 *   [[3](#3_0_intro)/W-0-1] MUST declare the feature
 `android.hardware.type.watch`.
@@ -70,7 +70,7 @@
 Text-to-speech engine) accessibility services as provided in the
 [talkback open source project]( https://github.com/google/talkback).
 
-If device implementations report the feature android.hardware.audio.output,
+If Watch device implementations report the feature android.hardware.audio.output,
 they:
 
 *   [[3.11](#3_11_text-to-speech)/W-SR] Are STRONGLY RECOMMENDED to include a
@@ -78,3 +78,35 @@
 
 *   [[3.11](#3_11_text-to-speech)/W-0-1] MUST support installation of
 third-party TTS engines.
+
+### 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).
+for each hardware component and the approximate battery drain caused by the
+components over time as documented in the Android Open Source Project site.
+*    [[8.4](#8_4_power-consumption-accounting)/W-0-2] MUST report all power
+consumption values in milliampere hours (mAh).
+*    [[8.4](#8_4_power-consumption-accounting)/W-0-3] MUST report CPU power
+consumption per each process's UID. The Android Open Source Project meets the
+requirement through the `uid_cputime` kernel module implementation.
+*   [[8.4](#8_4_power-consumption-accounting)/W-0-4] MUST make this power usage
+available via the [`adb shell dumpsys batterystats`](
+http://source.android.com/devices/tech/power/batterystats.html)
+shell command to the app developer.
+*   [[8.4](#8_4_power-consumption-accounting)/W] SHOULD be attributed to the
+hardware component itself if unable to attribute hardware component power usage
+to an application.
diff --git a/2_device-types/2_5_automotive-reqs.md b/2_device-types/2_5_automotive-reqs.md
index d529946..9246a37 100644
--- a/2_device-types/2_5_automotive-reqs.md
+++ b/2_device-types/2_5_automotive-reqs.md
@@ -55,7 +55,7 @@
 
 Automotive device implementations:
 
-*    [[7.3](#7_3_sensors).11/A] SHOULD provide current gear as
+*    [[7.3](#7_3_sensors).11/A-0-1] MUST provide current gear as
 `SENSOR_TYPE_GEAR`.
 
 Automotive device implementations:
@@ -68,16 +68,12 @@
 *    The underlying ambient light sensor MAY be the same as
 [Photometer](#7_3_7_photometer).
 
-*    [[7.3](#7_3_sensors).11.3/A-0-1] MUST support driving status defined as
-     `SENSOR_TYPE_DRIVING_STATUS`, with a default value of
-     `DRIVE_STATUS_UNRESTRICTED` when the vehicle is fully stopped and parked.
-     It is the responsibility of device manufacturers to configure
-     `SENSOR_TYPE_DRIVING_STATUS` in compliance with all laws and regulations
-     that apply to markets where the product is shipping.
-
-*    [[7.3](#7_3_sensors).11.4/A-0-1] MUST provide vehicle speed defined as
+*    [[7.3](#7_3_sensors).11.4/A-0-1] MUST provide vehicle speed as defined by
 `SENSOR_TYPE_CAR_SPEED`.
 
+*    [[7.3](#7_3_sensors).11.5/A-0-1] MUST provide parking brake status as
+defined by `SENSOR_TYPE_PARKING_BRAKE`.
+
 *    [[7.4](#7_4_data-connectivity).3/A-0-1] MUST support Bluetooth and SHOULD
 support Bluetooth LE.
 *    [[7.4](#7_4_data-connectivity).3/A-0-2] Android Automotive implementations
@@ -86,16 +82,32 @@
      * Media playback over Audio Distribution Profile (A2DP).
      * Media playback control over Remote Control Profile (AVRCP).
      * Contact sharing using the Phone Book Access Profile (PBAP).
-*    [[7.4](#7_4_data-connectivity).3/A] SHOULD support Message Access Profile
-(MAP).
+*    [[7.4](#7_4_data-connectivity).3/A-SR] Are STRONGLY RECOMMENDED to support
+Message Access Profile (MAP).
 
 *   [[7.4](#7_4_data-connectivity).5/A] SHOULD include support for cellular
-network based data connectivity.
+network-based data connectivity.
+*   [[7.4](#7_4_data-connectivity).5/A] MAY use the System API
+`NetworkCapabilities#NET_CAPABILITY_OEM_PAID` constant for
+networks that should be available to system apps.
 
 *   [[7.6](#7_6_memory-and-storage).1/A-0-1] MUST have at least 4GB of
 non-volatile storage available for application private data
 (a.k.a. "/data" partition).
 
+Automotive device implementations:
+
+*   [[7.6](#7_6_memory-and-storage).1/A] SHOULD format the data partition
+to offer improved performance and longevity on flash storage, for example
+using `f2fs` file-system.
+
+If Automotive device implementations provide shared external storage via a
+portion of the internal non-removable storage, they:
+
+*   [[7.6](#7_6_memory-and-storage).1/A-SR] Are STRONGLY RECOMMENDED to reduce
+I/O overhead on operations performed on the external storage, for example by
+using `SDCardFS`.
+
 If Automotive device implementations are 32-bit:
 
 *   [[7.6](#7_6_memory-and-storage).1/A-1-1] The memory available to the kernel
@@ -199,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.
@@ -213,23 +228,45 @@
 API when requested by third-party applications.
 
 *   [[3.8](#3_8_user-interface-compatibility).4/A-0-1] MUST implement an
-assistant on the device to handle the [Assist action](
-http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST).
+assistant on the device that provides a default implementation of the
+[`VoiceInteractionSession`](https://developer.android.com/reference/android/service/voice/VoiceInteractionSession)
+service.
 
-*   [[3.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.13](#3_13_quick_settings)/A-SR] Are STRONGLY RECOMMENDED to include a
+Quick Settings UI component.
 
-### 2.2.4\. Performance and Power
+If Automotive device implementations include a push-to-talk button, they:
+
+*   [[3.8](#3_8_user-interface-compatibility).4/A-1-1] MUST use a short press of
+the push-to-talk button as the designated interaction to launch the
+user-selected assist app, in other words the app that implements
+[`VoiceInteractionService`](
+https://developer.android.com/reference/android/service/voice/VoiceInteractionService).
 
 Automotive device implementations:
 
-*   [[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)
@@ -248,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
@@ -265,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/2_device-types/2_6_tablet-reqs.md b/2_device-types/2_6_tablet-reqs.md
index b132ced..ce910d1 100644
--- a/2_device-types/2_6_tablet-reqs.md
+++ b/2_device-types/2_6_tablet-reqs.md
@@ -39,12 +39,3 @@
 Virtual reality requirements are not applicable to tablets.
 
 
-
-
-
-
-
-
-
-
-
diff --git a/3_software/3_12_tv-input-framework.md b/3_software/3_12_tv-input-framework.md
index 7fc167d..8051028 100644
--- a/3_software/3_12_tv-input-framework.md
+++ b/3_software/3_12_tv-input-framework.md
@@ -5,106 +5,9 @@
 content to Android Television devices. TIF provides a standard API to create
 input modules that control Android Television devices.
 
-*    [T-0-1] Android Television device implementations MUST support TV Input
-Framework.
-
 If device implementations support TIF, they:
 
 *    [C-1-1] MUST declare the platform feature `android.software.live_tv`.
-*    [C-1-2] MUST preload a TV application (TV App) and meet all requirements
-     described in [section 3.12.1](#3_12_tv-input-framework).
-
-### 3.12.1\. TV App
-
-If device implementations support TIF:
-
-*    [C-1-1] The TV App MUST provide facilities to install and use [TV Channels](
-http://developer.android.com/reference/android/media/tv/TvContract.Channels.html)
-and meet the following requirements.
-
-The TV app that is required for Android device implementations declaring the
-`android.software.live_tv` feature flag, MUST meet the following requirements:
-
-*   Device implementations SHOULD allow third-party TIF-based inputs
-    ([third-party inputs](
-    https://source.android.com/devices/tv/index.html#third-party_input_example))
-    to be installed and managed.
-*   Device implementations MAY provide visual separation between pre-installed
-    [TIF-based inputs](
-    https://source.android.com/devices/tv/index.html#tv_inputs)
-    (installed inputs) and third-party inputs.
-*   Device implementations SHOULD NOT display the third-party inputs more than a
-    single navigation action away from the TV App (i.e. expanding a list of
-    third-party inputs from the TV App).
-
-The Android Open Source Project provides an implementation of the TV App that
-meets the above requirements.
-
-#### 3.12.1.1\. Electronic Program Guide
-
-If device implementations support TIF, they:
-
-*    [C-1-1] MUST show an informational and
-interactive overlay, which MUST include an electronic program guide (EPG)
-generated from the values in the [TvContract.Programs](
-https://developer.android.com/reference/android/media/tv/TvContract.Programs.html)
-fields.
-*   [C-1-2] On channel change, device implementations MUST display EPG data for
-    the currently playing program.
-*   [SR] The EPG is STRONGLY RECOMMENDED to display installed inputs and
-    third-party inputs with equal prominence. The EPG SHOULD NOT display the
-    third-party inputs more than a single navigation action away from the
-    installed inputs on the EPG.
-*   The EPG SHOULD display information from all installed inputs and third-party
-    inputs.
-*   The EPG MAY provide visual separation between the installed inputs and
-    third-party inputs.
-
-#### 3.12.1.2\. Navigation
-
-If device implementations support TIF, they:
-
-*    [C-1-1] MUST allow navigation for the following functions via
-the D-pad, Back, and Home keys on the Android Television device’s input
-device(s) (i.e. remote control, remote control application, or game controller):
-
-    *   Changing TV channels
-    *   Opening EPG
-    *   Configuring and tuning to third-party TIF-based inputs (if those inputs are supported)
-    *   Opening Settings menu
-
-*    SHOULD pass key events to HDMI inputs through CEC.
-
-#### 3.12.1.3\. TV input app linking
-
-If device implementations support TIF:
-
-*    [C-1-1] Android Television device implementations MUST support
-[TV input app linking](
-http://developer.android.com/reference/android/media/tv/TvContract.Channels.html#COLUMN_APP_LINK_INTENT_URI),
-which allows all inputs to provide activity links from the current activity to
-another activity (i.e. a link from live programming to related content). The TV
-App SHOULD show TV input app linking when it is provided.
-
-#### 3.12.1.4\. Time shifting
-
-If device implementations support TIF, they:
-
-*    [SR] STRONGLY RECOMMENDED to support time shifting, which allows the user
-to pause and resume live content.
-*    SHOULD provide the user a way to pause and resume the currently playing
-program, if time shifting for that program [is available](
-https://developer.android.com/reference/android/media/tv/TvInputManager.html#TIME_SHIFT_STATUS_AVAILABLE).
-
-#### 3.12.1.5\. TV recording
-
-If device implementations support TIF, they:
-
-*    [SR] STRONGLY RECOMMENDED to support TV recording.
-*    SHOULD provide a user interface to play recorded
-programs.
-*    If the TV input supports recording and the recording of a program is not
-[prohibited](
-https://developer.android.com/reference/android/media/tv/TvContract.Programs.html#COLUMN_RECORDING_PROHIBITED),
-the EPG MAY provide a way to [record a program](
-https://developer.android.com/reference/android/media/tv/TvInputInfo.html#canRecord%28%29).
+*    [C-1-2] MUST support all TIF APIs such that an application which uses
+these APIs and the [third-party TIF-based inputs](https://source.android.com/devices/tv/index.html#third-party_input_example)
+service can be installed and used on the device.
\ No newline at end of file
diff --git a/3_software/3_14_media-ui.md b/3_software/3_14_media-ui.md
new file mode 100644
index 0000000..fb6d358
--- /dev/null
+++ b/3_software/3_14_media-ui.md
@@ -0,0 +1,29 @@
+## 3.14\. Media UI
+
+
+If device implementations include the UI framework that supports third-party
+apps that depend on [`MediaBrowser`](
+http://developer.android.com/reference/android/media/browse/MediaBrowser.html)
+and [`MediaSession`](
+http://developer.android.com/reference/android/media/session/MediaSession.html)
+, they:
+
+*    [C-1-1] MUST display [MediaItem](
+     http://developer.android.com/reference/android/media/browse/MediaBrowser.MediaItem.html)
+     icons and notification icons unaltered.
+*    [C-1-2] MUST display those items as described by MediaSession, e.g.,
+     metadata, icons, imagery.
+*    [C-1-3] MUST show app title.
+*    [C-1-4] MUST have a drawer or other mechanism to present [MediaBrowser](
+     http://developer.android.com/reference/android/media/browse/MediaBrowser.html)
+     hierarchy and provide user affordance for the [MediaBrowser](
+     http://developer.android.com/reference/android/media/browse/MediaBrowser.html)
+     hierarchy.
+*    [C-1-5] MUST consider double tap of [`KEYCODE_HEADSETHOOK`](
+     https://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_HEADSETHOOK)
+     or [`KEYCODE_MEDIA_PLAY_PAUSE`](
+     https://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_MEDIA_PLAY_PAUSE)
+     as [`KEYCODE_MEDIA_NEXT`](
+     https://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_MEDIA_NEXT)
+     for [`MediaSession.Callback#onMediaButtonEvent`](
+     https://developer.android.com/reference/android/media/session/MediaSession.Callback.html#onMediaButtonEvent%28android.content.Intent%29).
\ No newline at end of file
diff --git a/3_software/3_14_vehicle-ui-apis.md b/3_software/3_14_vehicle-ui-apis.md
deleted file mode 100644
index b576593..0000000
--- a/3_software/3_14_vehicle-ui-apis.md
+++ /dev/null
@@ -1,19 +0,0 @@
-## 3.14\. Media UI
-
-
-If device implementations include the UI framework that supports third-party
-apps that depend on [`MediaBrowser`](
-http://developer.android.com/reference/android/media/browse/MediaBrowser.html)
-and [`MediaSession`](
-http://developer.android.com/reference/android/media/session/MediaSession.html)
-, they:
-
-*    [C-1-1] MUST display [MediaItem](
-     http://developer.android.com/reference/android/media/browse/MediaBrowser.MediaItem.html)
-     icons and notification icons unaltered.
-*    [C-1-2] MUST display those items as described by MediaSession, e.g.,
-     metadata, icons, imagery.
-*    [C-1-3] MUST show app title.
-*    [C-1-4] MUST have drawer to present [MediaBrowser](
-     http://developer.android.com/reference/android/media/browse/MediaBrowser.html)
-     hierarchy.
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 fd0f1a2..169347b 100644
--- a/3_software/3_2_soft-api-compatibility.md
+++ b/3_software/3_2_soft-api-compatibility.md
@@ -175,10 +175,7 @@
  </tr>
  <tr>
     <td>SERIAL</td>
-    <td>A hardware serial number, which MUST be available and unique across
-    devices with the same MODEL and MANUFACTURER. The value of this field MUST
-    be encodable as 7-bit ASCII and match the regular expression
-    &ldquo;^([a-zA-Z0-9]{6,20})$&rdquo;.</td>
+    <td>MUST return "UNKNOWN".</td>
  </tr>
  <tr>
     <td>TAGS</td>
@@ -237,6 +234,13 @@
     encodable as 7-bit ASCII and match the regular expression
     &ldquo;^[a-zA-Z0-9._-,]+$&rdquo;.</td>
  </tr>
+ <tr>
+    <td><a href="https://developer.android.com/reference/android/os/Build.html#getSerial()">getSerial()</a></td>
+    <td> MUST (be or return) a hardware serial number, which MUST be available
+    and unique across devices with the same MODEL and MANUFACTURER. The value of
+    this field MUST be encodable as 7-bit ASCII and match the regular expression
+    &ldquo;^[a-zA-Z0-9._-,]+$&rdquo;.</td>
+ </tr>
 </table>
 
 ### 3.2.3\. Intent Compatibility
@@ -248,9 +252,9 @@
 applications considered core Android applications, which implements several
 intent patterns to perform common actions.
 
-*   [C-0-1] Device implementations MUST include these application, service
-components, or at least a handler, for all the public intent filter patterns
-defined by the following core Android applications in AOSP:
+*   [C-0-1] Device implementations MUST preload one or more applications or
+service components with an intent handler, for all the public intent filter
+patterns defined by the following core android applications in AOSP:
 
    *   Desk Clock
    *   Browser
@@ -266,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
@@ -352,17 +357,34 @@
 
 If device implementations report `android.software.home_screen`, they:
 
-*   [C-1-1] MUST honor the [android.settings.HOME_SETTINGS](
+*   [C-1-1] MUST honor the [`android.settings.HOME_SETTINGS`](
 http://developer.android.com/reference/android/provider/Settings.html#ACTION_HOME_SETTINGS)
 intent to show a default app settings menu for Home Screen.
 
 If device implementations report `android.hardware.telephony`, they:
 
 *   [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)
+[`android.provider.Telephony.ACTION_CHANGE_DEFAULT`](
+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)
+intent to provide user affordance to configure the [`ConnectionServices`](
+https://developer.android.com/reference/android/telecom/ConnectionService.html)
+associated with the [`PhoneAccounts`](
+https://developer.android.com/reference/android/telecom/PhoneAccount.html), as
+well as a default PhoneAccount that the telecommunications service provider will
+use to place outgoing calls. The AOSP implementation meets this requirement by
+including a "Calling Accounts option" menu within the "Calls" settings menu.
 
 If device implementations report `android.hardware.nfc.hce`, they:
 
@@ -370,16 +392,10 @@
 http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFC_PAYMENT_SETTINGS)
 intent to show a default app settings menu for Tap and Pay.
 
-If device implementations report `android.hardware.telephony`, they:
+If device implementations support the `VoiceInteractionService` and have more
+than one application using this API installed at a time, they:
 
-*   [C-4-1] 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.
-
-If device implementations support the VoiceInteractionService, they:
-
-*   [C-5-1] MUST honor the [android.settings.ACTION_VOICE_INPUT_SETTINGS](
+*   [C-4-1] MUST honor the [`android.settings.ACTION_VOICE_INPUT_SETTINGS`](
     https://developer.android.com/reference/android/provider/Settings.html#ACTION_VOICE_INPUT_SETTINGS)
     intent to show a default app settings menu for voice input and assist.
 
@@ -433,4 +449,4 @@
 *   [C-3-1] Only the owner of that display, system, and activities that are
     already on that display MUST be able to launch to it. Everyone can launch to
     a display that has [android.view.Display.FLAG_PUBLIC](https://developer.android.com/reference/android/view/Display.html#FLAG_PUBLIC)
-    flag.
\ No newline at end of file
+    flag.
diff --git a/3_software/3_3_native-api-compatibility.md b/3_software/3_3_native-api-compatibility.md
index b6b7e43..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:
 
@@ -56,6 +55,7 @@
     *   liblog (Android logging)
     *   libmediandk.so (native media APIs support)
     *   libm (math library)
+    *   libneuralnetworks.so (Neural Networks API)
     *   libOpenMAXAL.so (OpenMAX AL 1.0.1 support)
     *   libOpenSLES.so (OpenSL ES 1.0.1 audio support)
     *   libRS.so
@@ -78,7 +78,7 @@
     in more detail the requirements for when the full implementation of each
     corresponding functions are expected.
 *   [C-0-12] MUST export function symbols for the core Vulkan 1.0 function
-    symobls, as well as the `VK_KHR_surface`, `VK_KHR_android_surface`,
+    symbols, as well as the `VK_KHR_surface`, `VK_KHR_android_surface`,
     `VK_KHR_swapchain`, `VK_KHR_maintenance1`, and
     `VK_KHR_get_physical_device_properties2` extensions through the
     `libvulkan.so` library.  Note that while all the symbols MUST be present,
@@ -87,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 4dee802..76c32c2 100644
--- a/3_software/3_8_user-interface-compatibility.md
+++ b/3_software/3_8_user-interface-compatibility.md
@@ -5,7 +5,8 @@
 Android includes a launcher application (home screen) and support for
 third-party applications to replace the device launcher (home screen).
 
-If device implementations allow third-party applications to replace the device home screen, they:
+If device implementations allow third-party applications to replace the device
+home screen, they:
 
 *   [C-1-1] MUST declare the platform feature `android.software.home_screen`.
 *   [C-1-2] MUST return the [`AdaptiveIconDrawable`](
@@ -25,18 +26,22 @@
     by apps via the [`ShortcutManager.requestPinShortcut()`](
     https://developer.android.com/reference/android/content/pm/ShortcutManager.html#requestPinShortcut%28android.content.pm.ShortcutInfo, android.content.IntentSender%29)
     API method.
+*   [C-2-3] MUST support pinned shortcuts and dynamic and static
+    shortcuts as documented on the [App Shortcuts page](
+    https://developer.android.com/guide/topics/ui/shortcuts.html).
 
-Conversely, if device implementations do not support in-app pinning, they:
+Conversely, if device implementations do not support in-app pinning of
+shortcuts, they:
 
 *   [C-3-1] MUST report `false` for
     [`ShortcutManager.isRequestPinShortcutSupported()`](
-    https://developer.android.com/reference/android/content/pm/ShortcutManager.html#isRequestPinShortcutSupported%28%29)
-    and [`AppWidgetManager.html#isRequestPinAppWidgetSupported()`](
-    https://developer.android.com/reference/android/appwidget/AppWidgetManager.html#isRequestPinAppWidgetSupported%28%29).
+    https://developer.android.com/reference/android/content/pm/ShortcutManager.html#isRequestPinShortcutSupported%28%29).
 
-If device implementations implement a default launcher that provides quick access to the additional
-shortcuts provided by third-party apps through the [ShortcutManager](
-https://developer.android.com/reference/android/content/pm/ShortcutManager.html) API, they:
+If device implementations implement a default launcher that provides quick
+access to the additional shortcuts provided by third-party apps through the
+[ShortcutManager](
+https://developer.android.com/reference/android/content/pm/ShortcutManager.html)
+API, they:
 
 *   [C-4-1] MUST support all documented shortcut features (e.g. static and
     dynamic shortcuts, pinning shortcuts) and fully implement the APIs of the
@@ -71,16 +76,16 @@
 [“AppWidget”](http://developer.android.com/guide/practices/ui_guidelines/widget_design.html)
 to the end user.
 
-
 If device implementations support third-party app widgets, they:
 
-*   [C-1-1] MUST declare support for platform feature android.software.app_widgets.
+*   [C-1-1] MUST declare support for platform feature
+    `android.software.app_widgets`.
 *   [C-1-2] MUST include built-in support for AppWidgets and expose
     user interface affordances to add, configure, view, and remove AppWidgets
     directly within the Launcher.
 *   [C-1-3] MUST be capable of rendering widgets that are 4 x 4
-    in the standard grid size. See the [App Widget Design
-    Guidelines](http://developer.android.com/guide/practices/ui_guidelines/widget_design.html)
+    in the standard grid size. See the [App Widget DesignGuidelines](
+    http://developer.android.com/guide/practices/ui_guidelines/widget_design.html)
     in the Android SDK documentation for details.
 *   MAY support application widgets on the lock screen.
 
@@ -119,7 +124,7 @@
     further detailed in [section 7](#7_hardware_compatibility).
 *   [C-1-2]  MUST correctly render all [resources](
     https://developer.android.com/guide/topics/resources/available-resources.html)
-    (icons, animation files etc.) provided for in the APIs, or in the
+    (icons, animation files, etc.) provided for in the APIs, or in the
     Status/System Bar [icon style guide](
     http://developer.android.com/design/style/iconography.html), although they
     MAY provide an alternative user experience for notifications than that
@@ -135,9 +140,20 @@
     third-party app's notification per each channel and app package level.
 *   [C-1-6] MUST also provide a user affordance to display deleted notification
     channels.
+*   [C-1-7] MUST correctly render all resources (images, stickers, icons, etc.)
+    provided through [Notification.MessagingStyle](
+    https://developer.android.com/reference/android/app/Notification.MessagingStyle)
+    alongside the notification text without additional user interaction. For
+    example, MUST show all resources including icons provided through
+    [android.app.Person](https://developer.android.com/reference/android/app/Person)
+    in a group conversation that is set through [setGroupConversation](
+    https://developer.android.com/reference/android/app/Notification.MessagingStyle.html?hl=es-AR#setGroupConversation%28boolean%29).
+*   [C-SR] Are STRONGLY RECOMMENDED to automatically surface a user affordance
+    to block a certain third-party app's notification per each channel and app
+    package level after the user dismisses that notification multiple times.
 *   SHOULD support rich notifications.
 *   SHOULD present some higher priority notifications as heads-up notifications.
-*   SHOULD have user affordance to snooze notifications.
+*   SHOULD have a user affordance to snooze notifications.
 *   MAY only manage the visibility and timing of when third-party apps can notify
     users of notable events to mitigate safety issues such as driver distraction.
 
@@ -158,6 +174,12 @@
     as described in the [`Notification.Builder`](
     https://developer.android.com/reference/android/app/Notification.Builder.html)
     API class when heads-up notifications are presented.
+*   [C-3-2] MUST display the actions provided through
+    [`Notification.Builder.addAction()`](
+    https://developer.android.com/reference/android/app/Notification.Builder#addAction%28android.app.Notification.Action%29)
+    together with the notification content without additional user interaction
+    as described in [the SDK](
+    https://developer.android.com/guide/topics/ui/notifiers/notifications.html#Heads-up).
 
 #### 3.8.3.2\. Notification Listener Service
 
@@ -166,23 +188,24 @@
 APIs that allow apps (once explicitly enabled by the user) to receive a copy of
 all notifications as they are posted or updated.
 
-Device implementations:
+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-0-1] MUST correctly and promptly update notifications in their entirety to all
+*   [C-1-1] MUST correctly and promptly update notifications in their entirety to all
     such installed and user-enabled listener services, including any and all
     metadata attached to the Notification object.
-*   [C-0-2] MUST respect the [`snoozeNotification()`](
+*   [C-1-2] MUST respect the [`snoozeNotification()`](
     https://developer.android.com/reference/android/service/notification/NotificationListenerService.html#snoozeNotification%28java.lang.String, long%29)
     API call, and dismiss the notification and make a callback after the snooze
     duration that is set in the API call.
 
 If device implementations have a user affordance to snooze notifications, they:
 
-*   [C-1-1] MUST reflect the snoozed notification status properly
+*   [C-2-1] MUST reflect the snoozed notification status properly
     through the standard APIs such as
     [`NotificationListenerService.getSnoozedNotifications()`](
     https://developer.android.com/reference/android/service/notification/NotificationListenerService.html#getSnoozedNotifications%28%29).
-*   [C-1-2] MUST make this user affordance available to snooze notifications
+*   [C-2-2] MUST make this user affordance available to snooze notifications
     from each installed third-party app's, unless they are from
     persistent/foreground services.
 
@@ -253,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
 
@@ -362,7 +383,7 @@
 If device implementations including the recents function navigation key as detailed in
 [section 7.2.3](#7_2_3_navigation_keys) alter the interface, they:
 
-*   [C-1-1] MUST support at least up to 20 displayed activities.
+*   [C-1-1] MUST support at least up to 7 displayed activities.
 *   SHOULD at least display the title of 4 activities at a time.
 *   [C-1-2] MUST implement the [screen pinning behavior](http://developer.android.com/about/versions/android-5.0.html#ScreenPinning)
     and provide the user with a settings menu to toggle the feature.
@@ -374,8 +395,7 @@
 *   SHOULD trigger the split-screen multiwindow-mode, if supported, when the
     recents functions key is long pressed.
 *   MAY display affiliated recents as a group that moves together.
-
-*   [C-SR] Device implementations are STRONGLY RECOMMENDED to use the upstream Android user
+*   [SR] Are STRONGLY RECOMMENDED to use the upstream Android user
 interface (or a similar thumbnail-based interface) for the overview screen.
 
 ### 3.8.9\. Input Management
@@ -428,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
 
@@ -527,3 +550,26 @@
     and minimum width of 240 dp and height of 135 dp for the PIP window when the
     `Configuration.uiMode` is configured as [`UI_MODE_TYPE_TELEVISION`](
     https://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_TELEVISION)
+
+
+### 3.8.15\. Display Cutout
+
+Android supports a Display Cutout as described
+in the SDK document. The [`DisplayCutout`](
+https://developer.android.com/reference/android/view/DisplayCutout) API defines
+an area on the edge of the display that is not functional for displaying
+content.
+
+If device implementations include display cutout(s), they:
+
+*   [C-1-1] MUST only have cutout(s) on the short edge(s) of the device.
+Conversely, if the device's aspect ratio is 1.0(1:1), they MUST NOT have
+cutout(s).
+*   [C-1-2] MUST NOT have more than one cutout per edge.
+*   [C-1-3] MUST honor the display cutout flags set by the app through the
+[`WindowManager.LayoutParams`](
+https://developer.android.com/reference/android/view/WindowManager.LayoutParams)
+API as described in the SDK.
+*   [C-1-4] MUST report correct values for all cutout metrics defined in the
+[`DisplayCutout`](
+https://developer.android.com/reference/android/view/DisplayCutout) API.
\ No newline at end of file
diff --git a/3_software/3_9_device-administration.md b/3_software/3_9_device-administration.md
index eb50d95..f0d4a7b 100644
--- a/3_software/3_9_device-administration.md
+++ b/3_software/3_9_device-administration.md
@@ -13,12 +13,6 @@
 *   [C-1-2] MUST support device owner provisioning as described in
     [section 3.9.1](#3_9_1_device_provisioning) and
     [section 3.9.1.1](#3_9_1_1_device_owner_provisioning).
-*   [C-1-3] MUST declare the support of manged profiles via the
-    `android.software.managed_users` feature flag, except for when the device is
-    configured so that it would [report](
-    http://developer.android.com/reference/android/app/ActivityManager.html#isLowRamDevice%28%29)
-    itself as a low RAM device or so that it allocate internal (non-removable)
-    storage as shared storage.
 
 ### 3.9.1 Device Provisioning
 
@@ -42,9 +36,10 @@
         *    [C-1-6] MUST report `false` for the [`DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE)`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html\#isProvisioningAllowed\(java.lang.String\)).
         *    [C-1-7] MUST not enroll any DPC application as the Device Owner App
              any more.
-*   [C-1-2] MUST NOT set an application (including pre-installed app) as the
-    Device Owner app without explicit consent or action from the user or the
-    administrator of the device.
+*   [C-1-2] MUST require some affirmative action during the provisioning process
+to consent to the app being set as Device Owner. Consent can be via user action
+or by some programmatic means during provisioning but it MUST NOT be hard coded
+or prevent the use of other Device Owner apps.
 
 If device implementations declare `android.software.device_admin`, but also
 include a proprietary Device Owner management solution and provide a mechanism
@@ -88,7 +83,7 @@
         https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setShortSupportMessage%28android.content.ComponentName, java.lang.CharSequence%29).
     *   The DPC application’s icon.
 
-## 3.9.2 Managed Profile Support
+### 3.9.2 Managed Profile Support
 
 If device implementations declare `android.software.managed_users`, they:
 
@@ -144,3 +139,14 @@
     in the preinstalled call log, in-call UI, in-progress and missed-call
     notifications, contacts and messaging apps they SHOULD be badged with the
     same badge used to indicate managed profile applications.
+
+## 3.9.3 Managed User Support
+
+If device implementations declare `android.software.managed_users`, they:
+
+*   [C-1-1] MUST provide a user affordance to logout from the current user and
+    switch back to the primary user in multiple-user session when
+    [`isLogoutEnabled`](
+    https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isLogoutEnabled%28%29)
+    returns `true`. The user affordance MUST be accessible from the lockscreen
+    without unlocking the device.
\ No newline at end of file
diff --git a/4_application-packaging/4_0_intro.md b/4_application-packaging/4_0_intro.md
index 1a25035..be0b3d7 100644
--- a/4_application-packaging/4_0_intro.md
+++ b/4_application-packaging/4_0_intro.md
@@ -8,9 +8,13 @@
 http://developer.android.com/tools/help/index.html).
    *   As the above requirement may be challenging, device implementations are
    RECOMMENDED to use the AOSP reference implementation's package management
-   systemDevice implementations.
+   system.
+
+Device implementations:
+
 *    [C-0-2] MUST support verifying “.apk” files using the
-[APK Signature Scheme v2](https://source.android.com/security/apksigning/v2.html)
+[APK Signature Scheme v3](https://source.android.com/security/apksigning/v3.html)
+, [APK Signature Scheme v2](https://source.android.com/security/apksigning/v2.html)
 and [JAR signing](
 https://source.android.com/security/apksigning/v2.html#v1-verification).
 *    [C-0-3] MUST NOT extend either the
@@ -22,7 +26,7 @@
 installing and running correctly on other compatible devices.
 *    [C-0-4] MUST NOT allow apps other than the current
 "installer of record" for the package to silently uninstall the app without any
-prompt, as documented in the SDK for the [`DELETE_PACKAGE`](
+user confirmation, as documented in the SDK for the [`DELETE_PACKAGE`](
 https://developer.android.com/reference/android/Manifest.permission.html#DELETE_PACKAGES)
 permission. The only exceptions are the system package verifier app handling
 [PACKAGE_NEEDS_VERIFICATION](
@@ -46,10 +50,16 @@
 
 *    SHOULD provide a user affordance to grant/revoke the permission to
 install apps from unknown sources per application, but MAY choose to implement
-this as a no-op and return `RESULT_CANCELED` for
-[`startActivityForResult()`](http://developer.android.com/reference/android/app/Activity.html#startActivityForResult%28android.content.Intent,
-int%29),
+this as a no-op and return `RESULT_CANCELED` for [`startActivityForResult()`](
+http://developer.android.com/reference/android/app/Activity.html#startActivityForResult%28android.content.Intent,int%29),
 if the device implementation does not want to allow users to have this choice.
 However, even in such cases, they SHOULD indicate to the user why there is no
-such
-choice presented.
+such choice presented.
+
+*    [C-0-7] MUST display a warning dialog with the warning string that is
+provided through the system API `PackageManager.setHarmfulAppWarning`
+to the user before launching an activity in an application that has been marked
+by the same system API `PackageManager.setHarmfulAppWarning` as potentially
+harmful.
+*    SHOULD provide a user affordance to choose to uninstall or launch an
+application on the warning dialog.
\ No newline at end of file
diff --git a/5_multimedia/5_10_professional-audio.md b/5_multimedia/5_10_professional-audio.md
index e90d000..4af9364 100644
--- a/5_multimedia/5_10_professional-audio.md
+++ b/5_multimedia/5_10_professional-audio.md
@@ -14,13 +14,25 @@
 *    [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.
-*    SHOULD provide a sustainable level of CPU performance while audio is active.
+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)
+commit [1bd6391](https://github.com/googlesamples/android-audio-high-performance/commit/1bd6391f8ba9512f9f8798e979bc55b899f856d1).
+The SimpleSynth app needs to be run with below parameters and achieve zero
+underruns after 10 minutes:
+    * Work cycles: 200,000
+    * Variable load: ON (this will switch between 100% and 10% of the work
+      cycles value every 2 seconds and is designed to test CPU governor
+      behavior)
+    * Stabilized load: OFF
 *    SHOULD minimize audio clock inaccuracy and drift relative to standard time.
-*    SHOULD minimize audio clock drift relative to the CPU `CLOCK_MONOTONIC` when both
-are active.
+*    SHOULD minimize audio clock drift relative to the CPU `CLOCK_MONOTONIC`
+when both are active.
 *    SHOULD minimize audio latency over on-device transducers.
 *    SHOULD minimize audio latency over USB digital audio.
 *    SHOULD document audio latency measurements over all paths.
@@ -48,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:
 
@@ -56,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
@@ -74,20 +82,17 @@
 *   The continuous round-trip audio latency SHOULD be 10 milliseconds
 or less over the audio jack path.
 
-If device implementations omit a 4 conductor 3.5mm audio jack, they:
+If device implementations omit a 4 conductor 3.5mm audio jack and
+include a USB port(s) supporting USB host mode, they:
 
-*   [C-3-1] MUST have a continuous round-trip audio latency of 20
-milliseconds or less.
+*   [C-3-1] MUST implement the USB audio class.
+*   [C-3-2] MUST have a continuous round-trip audio latency of 20
+milliseconds or less over the USB host mode port using USB audio class.
 *   The continuous round-trip audio latency SHOULD be 10 milliseconds
 or less over the USB host mode port using USB audio class.
 
-
-If device implementations include a USB port(s) supporting USB host mode, they:
-
-*   [C-4-1] MUST implement the USB audio class.
-
-
 If device implementations include an HDMI port, they:
 
-*   [C-5-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.
+*   [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,
+in at least one configuration.
diff --git a/5_multimedia/5_1_media-codecs.md b/5_multimedia/5_1_media-codecs.md
index 1ad3158..ea34d0c 100644
--- a/5_multimedia/5_1_media-codecs.md
+++ b/5_multimedia/5_1_media-codecs.md
@@ -4,27 +4,6 @@
 
 See more details in [5.1.3. Audio Codecs Details](#5_1_3_audio_codecs_details).
 
-Handheld device implementations MUST support the following audio encoding:
-
-*    [H-0-1] AMR-NB
-*    [H-0-2] AMR-WB
-*    [H-0-3] MPEG-4 AAC Profile (AAC LC)
-*    [H-0-4] MPEG-4 HE AAC Profile (AAC+)
-*    [H-0-5] AAC ELD (enhanced low delay AAC)
-
-
-Television device implementations MUST support the following audio encoding:
-
-*    [T-0-1] MPEG-4 AAC Profile (AAC LC)
-*    [T-0-2] MPEG-4 HE AAC Profile (AAC+)
-*    [T-0-3] AAC ELD (enhanced low delay AAC)
-
-Automotive device implementations MUST support the following audio encoding:
-
-*    [A-1-1] MPEG-4 AAC Profile (AAC LC)
-*    [A-1-2] MPEG-4 HE AAC Profile (AAC+)
-*    [A-1-3] AAC ELD (enhanced low delay AAC)
-
 If device implementations declare `android.hardware.microphone`,
 they MUST support the following audio encoding:
 
@@ -35,19 +14,18 @@
 
 See more details in [5.1.3. Audio Codecs Details](#5_1_3_audio_codecs_details).
 
-Handheld device implementations MUST support the following decoding.
-
-*    [H-0-1] AMR-NB
-*    [H-0-2] AMR-WB
 
 If device implementations declare support for the
-`android.hardware.audio.output` feature, they must support the following audio
-decoders:
+`android.hardware.audio.output` feature, they must support decoding the
+following audio formats:
 
 *    [C-1-1] MPEG-4 AAC Profile (AAC LC)
 *    [C-1-2] MPEG-4 HE AAC Profile (AAC+)
 *    [C-1-3] MPEG-4 HE AACv2 Profile (enhanced AAC+)
 *    [C-1-4] AAC ELD (enhanced low delay AAC)
+*    [C-1-11] xHE-AAC (ISO/IEC 23003-3 Extended HE AAC Profile, which includes
+             the USAC Baseline Profile, and ISO/IEC 23003-4 Dynamic Range Control
+             Profile)
 *    [C-1-5] FLAC
 *    [C-1-6] MP3
 *    [C-1-7] MIDI
@@ -67,10 +45,27 @@
 (DRC)" in ISO/IEC 14496-3, and the `android.media.MediaFormat` DRC keys to
 configure the dynamic range-related behaviors of the audio decoder. The
 AAC DRC keys were introduced in API 21,and are:
-KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR,
-KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL and
-KEY_AAC_ENCODED_TARGET_LEVEL
+`KEY_AAC_DRC_ATTENUATION_FACTOR`, `KEY_AAC_DRC_BOOST_FACTOR`,
+`KEY_AAC_DRC_HEAVY_COMPRESSION`, `KEY_AAC_DRC_TARGET_REFERENCE_LEVEL` and
+`KEY_AAC_ENCODED_TARGET_LEVEL`
 
+When decoding USAC audio, MPEG-D (ISO/IEC 23003-4):
+
+*    [C-3-1] Loudness and DRC metadata MUST be interpreted and applied
+according to MPEG-D DRC Dynamic Range Control Profile Level 1.
+*    [C-3-2] The decoder MUST behave according to the configuration
+set with the following `android.media.MediaFormat` keys:
+`KEY_AAC_DRC_TARGET_REFERENCE_LEVEL` and `KEY_AAC_DRC_EFFECT_TYPE`.
+
+MPEG-4 AAC, HE AAC, and HE AACv2 profile decoders:
+
+*    MAY support loudness and dynamic range control using ISO/IEC 23003-4
+Dynamic Range Control Profile.
+
+If ISO/IEC 23003-4 is supported and if both ISO/IEC 23003-4 and
+ISO/IEC 14496-3 metadata are present in a decoded bitstream, then:
+
+*    ISO/IEC 23003-4 metadata SHALL take precedence.
 
 ### 5.1.3\. Audio Codecs Details
 
@@ -113,6 +108,17 @@
     <td></td>
  </tr>
  <tr>
+    <td>USAC</td>
+    <td>Support for mono/stereo content with standard sampling rates from 7.35
+    to 48 kHz.</td>
+    <td>
+    <ul>
+    <li>MPEG-4 (.mp4, .m4a)</li>
+    <li>LATM/LOAS (.loas, .xhe)</li>
+    </ul>
+    </td>
+ </tr>
+ <tr>
     <td>AMR-NB</td>
     <td>4.75 to 12.2 kbps sampled @ 8 kHz</td>
     <td>3GPP (.3gp)</td>
@@ -180,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
@@ -188,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
 
@@ -228,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_2_video-encoding.md b/5_multimedia/5_2_video-encoding.md
index 4f97c1e..3bc9d79 100644
--- a/5_multimedia/5_2_video-encoding.md
+++ b/5_multimedia/5_2_video-encoding.md
@@ -1,22 +1,5 @@
 ## 5.2\. Video Encoding
 
-Handheld device implementations MUST support the following encoding and make it
-available to third-party applications.
-
-*    [H-0-1] H.264 AVC
-*    [H-0-2] VP8
-
-Television device implementations MUST support the following encoding.
-
-*    [T-0-1] H.264 AVC
-*    [T-0-2] VP8
-
-Automotive device implementations MUST support the following encoding:
-
-*    [A-0-1] H.264 AVC
-*    [A-0-2] VP8
-
-
 If device implementations support any video encoder and make it available
 to third-party apps, they:
 
@@ -60,14 +43,6 @@
 
 ### 5.2.2\. H-264
 
-Television device implementations are:
-
-*   [T-SR] STRONGLY RECOMMENDED to support H.264 encoding of 720p and 1080p
-resolution videos.
-*   [T-SR] STRONGLY RECOMMENDED to support H.264 encoding of 1080p resolution
-video at 30 frame-per-second (fps).
-
-
 If device implementations support H.264 codec, they:
 
 *   [C-1-1] MUST support Baseline Profile Level 3.
diff --git a/5_multimedia/5_3_video-decoding.md b/5_multimedia/5_3_video-decoding.md
index b376275..30adfe2 100644
--- a/5_multimedia/5_3_video-decoding.md
+++ b/5_multimedia/5_3_video-decoding.md
@@ -1,32 +1,5 @@
 ## 5.3\. Video Decoding
 
-Handheld device implementations:
-
-*    [H-0-1] MUST support decoding of H.264 AVC.
-*    [H-0-2] MUST support decoding of H.265 HEVC.
-*    [H-0-3] MUST support decoding of MPEG-4 SP.
-*    [H-0-4] MUST support decoding of VP8.
-*    [H-0-5] MUST support decoding of VP9.
-
-Television device implementations:
-
-*    [T-0-1] MUST support decoding of H.264 AVC.
-*    [T-0-2] MUST support decoding of H.265 HEVC.
-*    [T-0-3] MUST support decoding of MPEG-4 SP.
-*    [T-0-4] MUST support decoding of VP8.
-*    [T-0-5] MUST support decoding of VP9.
-*    [T-SR] Are Strongly Recommended to support MPEG-2 decoding.
-
-
-Automotive device implementations:
-
-*    [A-0-1] MUST support decoding of H.264 AVC.
-*    [A-0-2] MUST support decoding of MPEG-4 SP.
-*    [A-0-3] MUST support decoding of VP8.
-*    [A-0-4] MUST support decoding of VP9.
-*    [A-SR] Are Strongly Recommended to support H.265 HEVC decoding.
-
-
 If device implementations support VP8, VP9, H.264, or H.265 codecs, they:
 
 *   [C-1-1] MUST support dynamic video resolution and frame rate switching
@@ -83,13 +56,6 @@
 *   [C-2-2] MUST support the HD 1080p video decoding profiles in the following
 table.
 
-If Television device implementations support H.264 decoders, they:
-
-*   [T-1-1] MUST support High Profile Level 4.2 and the HD 1080p (at 60 fps)
-decoding profile.
-*   [T-1-2] MUST be capable of decoding videos with both HD profiles as
-indicated in the following table and encoded with either the Baseline Profile,
-Main Profile, or the High Profile Level 4.2
 
 <table>
  <tr>
@@ -124,6 +90,7 @@
 
 ### 5.3.5\. H.265 (HEVC)
 
+
 If device implementations support H.265 codec, they:
 
 *   [C-1-1] MUST support the Main Profile Level 3 Main tier and the SD video
@@ -138,18 +105,6 @@
 *   [C-2-1] Device implementations MUST support at least one of H.265 or VP9
 decoding of 720, 1080 and UHD profiles.
 
-If Television device implementations support H.265 codec and the HD 1080p
-decoding profile, they:
-
-*   [T-1-1] MUST support the Main Profile Level 4.1 Main tier.
-*   [T-SR] STRONGLY RECOMMENDED to support 60 fps video frame rate
-for HD 1080p.
-
-If Television device implementations support H.265 codec and the UHD decoding
-profile, then:
-
-*   [T-2-1] The codec MUST support Main10 Level 5 Main Tier profile.
-
 <table>
  <tr>
     <th></th>
@@ -204,15 +159,6 @@
 *   [C-2-2] Device implementations MUST support 1080p profiles in the
 following table.
 
-If Television device implementations support VP8 codec, they:
-
-*   [T-1-1] MUST support the HD 1080p60 decoding profile.
-
-If Television device implementations support VP8 codec and support 720p, they:
-
-*   [T-2-1] MUST support the HD 720p60 decoding profile.
-
-
 
 <table>
  <tr>
@@ -265,17 +211,6 @@
 *   [C-3-1] Device implementations MUST support at least one of VP9 or H.265
 decoding of the 720, 1080 and UHD profiles.
 
-If Television device implementations support VP9 codec and the UHD video
-decoding, they:
-
-*   [T-1-1] MUST support 8-bit color depth and SHOULD support VP9 Profile 2
-(10-bit).
-
-If Television device implementations support VP9 codec, the 1080p profile and
-VP9 hardware decoding, they:
-
-*   [T-2-1] MUST support 60 fps for 1080p.
-
 <table>
  <tr>
     <th></th>
@@ -309,4 +244,4 @@
     <td>5 Mbps</td>
     <td>20 Mbps</td>
  </tr>
-</table>
\ No newline at end of file
+</table>
diff --git a/5_multimedia/5_5_audio-playback.md b/5_multimedia/5_5_audio-playback.md
index 363197e..f510887 100644
--- a/5_multimedia/5_5_audio-playback.md
+++ b/5_multimedia/5_5_audio-playback.md
@@ -10,14 +10,18 @@
 *   [C-1-1] MUST allow playback of raw audio content with the following
 characteristics:
 
-   *   **Format**: Linear PCM, 16-bit
-   *   **Sampling rates**: 8000, 11025, 16000, 22050, 32000, 44100
-   *   **Channels**: Mono, Stereo
+     *   **Format**: Linear PCM, 16-bit, 8-bit, float
+     *   **Channels**: Mono, Stereo, valid multichannel configurations
+            with up to 8 channels
+     *   **Sampling rates (in Hz)**:
+          * 8000, 11025, 16000, 22050, 32000, 44100, 48000 at the channel
+              configurations listed above
+          * 96000 in mono and stereo
 
 *   SHOULD allow playback of raw audio content with the following
 characteristics:
 
-   *   **Sampling rates**: 24000, 48000
+     *   **Sampling rates**: 24000, 48000
 
 ### 5.5.2\. Audio Effects
 
@@ -33,6 +37,8 @@
 AudioEffect subclasses `Equalizer`, `LoudnessEnhancer`.
 *   [C-1-2] MUST support the visualizer API implementation, controllable through
 the `Visualizer` class.
+*   [C-1-3] MUST support the `EFFECT_TYPE_DYNAMICS_PROCESSING` implementation
+controllable through the AudioEffect subclass [`DynamicsProcessing`](https://developer.android.com/reference/android/media/audiofx/DynamicsProcessing).
 *   SHOULD support the `EFFECT_TYPE_BASS_BOOST`, `EFFECT_TYPE_ENV_REVERB`,
 `EFFECT_TYPE_PRESET_REVERB`, and `EFFECT_TYPE_VIRTUALIZER` implementations
 controllable through the `AudioEffect` sub-classes `BassBoost`,
@@ -40,13 +46,6 @@
 
 ### 5.5.3\. Audio Output Volume
 
-Television device implementations:
-
-*   [T-0-1] MUST include support for system Master Volume and digital audio
-output volume attenuation on supported outputs,
-except for compressed audio passthrough output (where no audio decoding is done
-on the device).
-
 Automotive device implementations:
 
 *   SHOULD allow adjusting audio volume
diff --git a/5_multimedia/5_6_audio-latency.md b/5_multimedia/5_6_audio-latency.md
index 7edea1e..5e0699d 100644
--- a/5_multimedia/5_6_audio-latency.md
+++ b/5_multimedia/5_6_audio-latency.md
@@ -38,33 +38,49 @@
 *   **AAudio native audio API**. The set of
 [AAudio](https://developer.android.com/ndk/guides/audio/aaudio/aaudio.html) APIs
 within [Android NDK](https://developer.android.com/ndk/index.html).
+*   **Timestamp**. A pair consisting of a relative frame position within a
+stream and the estimated time when that frame enters or leaves the
+audio processing pipeline on the associated endpoint.  See also
+[AudioTimestamp](https://developer.android.com/reference/android/media/AudioTimestamp).
 
 If device implementations declare `android.hardware.audio.output` they are
 STRONGLY RECOMMENDED to meet or exceed the following requirements:
 
-*   [SR] Cold output latency of 100 milliseconds or less
-*   [SR] Continuous output latency of 45 milliseconds or less
-*   [SR] Minimize the cold output jitter
+*   [C-SR] Cold output latency of 100 milliseconds or less
+*   [C-SR] Continuous output latency of 45 milliseconds or less
+*   [C-SR] Minimize the cold output jitter
+*   [C-SR] The output timestamp returned by
+[AudioTrack.getTimestamp](https://developer.android.com/reference/android/media/AudioTrack.html#getTimestamp(android.media.AudioTimestamp))
+and `AAudioStream_getTimestamp` is accurate to +/- 1 ms.
 
-If device implementations meet the above requirements after any initial
-calibration when using the OpenSL ES PCM buffer queue API, for continuous output
-latency and cold output latency over at least one supported audio output device,
-they are:
+If device implementations meet the above requirements, after any initial
+calibration, when using both the OpenSL ES PCM buffer queue and AAudio native audio APIs,
+for continuous output latency and cold output latency over at least one supported audio
+output device, they are:
 
-*   [SR] STRONGLY RECOMMENDED to report low latency audio by declaring 
-`android.hardware.audio.low_latency` feature flag.
-*   [SR] STRONGLY RECOMMENDED to also meet the requirements for low-latency
+*   [C-SR] STRONGLY RECOMMENDED to report low-latency audio by declaring
+    `android.hardware.audio.low_latency` feature flag.
+*   [C-SR] STRONGLY RECOMMENDED to meet the requirements for low-latency
     audio via the AAudio API.
+*   [C-SR] STRONGLY RECOMMENDED to ensure that for streams that return
+    [`AAUDIO_PERFORMANCE_MODE_LOW_LATENCY`](https://developer.android.com/ndk/guides/audio/aaudio/aaudio#performance-mode)
+    from [`AAudioStream_getPerformanceMode()`](https://developer.android.com/ndk/reference/group/audio#aaudiostream_getperformancemode),
+    the value returned by [`AAudioStream_getFramesPerBurst()`](https://developer.android.com/ndk/reference/group/audio#aaudiostream_getframesperburst)
+    is less than or equal to the value returned by [`android.media.AudioManager.getProperty(String)`](https://developer.android.com/reference/android/media/AudioManager.html#getProperty%28java.lang.String%29)
+    for property key [`AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER`](https://developer.android.com/reference/android/media/AudioManager.html#PROPERTY_OUTPUT_FRAMES_PER_BUFFER).
 
 If device implementations do not meet the requirements for low-latency audio
-via the OpenSL ES PCM buffer queue API, they:
+via both the OpenSL ES PCM buffer queue and AAudio native audio APIs, they:
 
 *   [C-1-1] MUST NOT report support for low-latency audio.
 
 If device implementations include `android.hardware.microphone`, they are
 STRONGLY RECOMMENDED to meet these input audio requirements:
 
-   *   [SR] Cold input latency of 100 milliseconds or less
-   *   [SR] Continuous input latency of 30 milliseconds or less
-   *   [SR] Continuous round-trip latency of 50 milliseconds or less
-   *   [SR] Minimize the cold input jitter
\ No newline at end of file
+   *   [C-SR] Cold input latency of 100 milliseconds or less
+   *   [C-SR] Continuous input latency of 30 milliseconds or less
+   *   [C-SR] Continuous round-trip latency of 50 milliseconds or less
+   *   [C-SR] Minimize the cold input jitter
+   *   [C-SR] Limit the error in input timestamps, as returned by
+[AudioRecord.getTimestamp](https://developer.android.com/reference/android/media/AudioRecord.html#getTimestamp(android.media.AudioTimestamp,%20int))
+or `AAudioStream_getTimestamp`, to +/- 1 ms.
diff --git a/5_multimedia/5_8_secure-media.md b/5_multimedia/5_8_secure-media.md
index 5df157e..7722d80 100644
--- a/5_multimedia/5_8_secure-media.md
+++ b/5_multimedia/5_8_secure-media.md
@@ -15,17 +15,6 @@
 If device implementations declare support for `Display.FLAG_SECURE` and
 support wired external display, they:
 
-*    [C-3-1] MUST support HDCP 1.2 or higher for all wired external displays.
+*    [C-3-1] MUST support HDCP 1.2 or higher for all external displays connected
+via a user-accessible wired port.
 
-If device implementations are Android Television devices and support 4K
-resolution, they:
-
-*    [T-1-1] MUST support HDCP 2.2 for all wired external displays.
-
-If Television device implementations don't support 4K resolution, they:
-
-*    [T-2-1] MUST support HDCP 1.4 for all wired external displays.
-
-*    [T-SR] Television device implementations are STRONGLY RECOMMENDED to
-support simulataneous decoding of secure streams. At minimum, simultaneous
-decoding of two steams is STRONGLY RECOMMENDED.
\ No newline at end of file
diff --git a/5_multimedia/5_9_midi.md b/5_multimedia/5_9_midi.md
index 6dacb59..205d074 100644
--- a/5_multimedia/5_9_midi.md
+++ b/5_multimedia/5_9_midi.md
@@ -1,22 +1,16 @@
 ## 5.9\. Musical Instrument Digital Interface (MIDI)
 
-If a device implementation supports the inter-app MIDI software transport
-(virtual MIDI devices), and it supports MIDI over _all_ of the following
-MIDI-capable hardware transports for which it provides generic non-MIDI
-connectivity, it is: 
+If device implementations report support for feature `android.software.midi`
+via the [`android.content.pm.PackageManager`](
+http://developer.android.com/reference/android/content/pm/PackageManager.html)
+class, they:
 
-*    [SR] STRONGLY RECOMMENDED to report support for feature
-android.software.midi via the [android.content.pm.PackageManager](http://developer.android.com/reference/android/content/pm/PackageManager.html)
-class.
+*    [C-1-1] MUST support MIDI over _all_ MIDI-capable hardware transports for
+which they provide generic non-MIDI connectivity, where such transports are:
 
-The MIDI-capable hardware transports are:
+    *   USB host mode, [section 7.7](#7_7_USB)
+    *   USB peripheral mode, [section 7.7](#7_7_USB)
+    *   MIDI over Bluetooth LE acting in central role, [section 7.4.3](#7_4_3_bluetooth)
 
-*   USB host mode (section 7.7 USB)
-*   USB peripheral mode (section 7.7 USB)
-*   MIDI over Bluetooth LE acting in central role (section 7.4.3 Bluetooth)
-
-If the device implementation provides generic non-MIDI connectivity over a
-particular MIDI-capable hardware transport listed above, but does not support
-MIDI over that hardware transport, it:
-
-*    [C-1-1] MUST NOT report support for feature android.software.midi.
+*    [C-1-2] MUST support the inter-app MIDI software transport
+(virtual MIDI devices)
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 13da399..3ab68d0 100644
--- a/7_hardware-compatibility/7_1_display-and-graphics.md
+++ b/7_hardware-compatibility/7_1_display-and-graphics.md
@@ -21,26 +21,16 @@
 
 ### 7.1.1\. Screen Configuration
 
-#### 7.1.1.1\. Screen Size
-
-*   [H-0-1] Handheld device implementations MUST have a screen at least 2.5
-    inches in physical diagonal size.
-
-*   [A-0-1] Android Automotive devices MUST have a screen at least 6 inches
-    in physical diagonal size.
-
-*   [A-0-2] Android Automotive devices MUST have a screen size layout of
-at least 750 dp x 480 dp.
-
-*   [W-0-1] Android Watch device implementations MUST have a screen with the
-    physical diagonal size in the range from 1.1 to 2.5 inches.
+#### 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:
@@ -55,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
@@ -130,8 +130,6 @@
      supported compatible screen size (320 dp width), device implementations SHOULD
      report the next lowest standard Android framework density.
 
-*    [H-SR] Device implementations are STRONGLY RECOMMENDED to provide users an
-     affordance to change the display size.
 
 If there is an affordance to change the display size of the device:
 
@@ -204,11 +202,11 @@
 
 If device implementations include a screen or video output, they:
 
-*   [C-1-1] MUST support both OpenGL ES 1.0 and 2.0, as embodied and detailed
+*   [C-1-1] MUST support both OpenGL ES 1.1 and 2.0, as embodied and detailed
     in the [Android SDK documentation](
     https://developer.android.com/guide/topics/graphics/opengl.html).
-*   [SR] are STRONGLY RECOMMENDED to support OpenGL ES 3.0.
-*   SHOULD support OpenGL ES 3.1 or 3.2.
+*   [SR] are STRONGLY RECOMMENDED to support OpenGL ES 3.1.
+*   SHOULD support OpenGL ES 3.2.
 
 If device implementations support any of the OpenGL ES versions, they:
 
@@ -252,15 +250,15 @@
 https://www.khronos.org/registry/vulkan/specs/1.0-wsi&lowbarextensions/xhtml/vkspec.html)
 , a low-overhead, cross-platform API for high-performance 3D graphics.
 
-If device implementations support OpenGL ES 3.0 or 3.1, they:
+If device implementations support OpenGL ES 3.1, they:
 
-*    [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.0 .
+*    [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.1.
 
 If device implementations include a screen or video output, they:
 
-*    SHOULD include support for Vulkan 1.0.
+*    SHOULD include support for Vulkan 1.1.
 
-Device implementations, if including support for Vulkan 1.0:
+If device implementations include support for Vulkan 1.0, they:
 
 *   [C-1-1] MUST report the correct integer value with the
     `android.hardware.vulkan.level` and `android.hardware.vulkan.version`
@@ -285,14 +283,22 @@
 *   [C-1-6] MUST report all extension strings that they do support via the
     Vulkan native APIs , and conversely MUST NOT report extension strings
     that they do not correctly support.
+*   [C-1-7] MUST support the VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain,
+    and VK_KHR_incremental_present extensions
 
-Device implementations, if not including support for Vulkan 1.0:
+If device implementations do not include support for Vulkan 1.0, they:
 
 *   [C-2-1] MUST NOT declare any of the Vulkan feature flags (e.g.
     `android.hardware.vulkan.level`, `android.hardware.vulkan.version`).
 *   [C-2-2] MUST NOT enumarate any `VkPhysicalDevice` for the Vulkan native API
     `vkEnumeratePhysicalDevices()`.
 
+If device implementations include support for Vulkan 1.1, they:
+
+*   [C-3-1] MUST expose support for the `SYNC_FD` external semaphore and handle types.
+*   [SR] Are STRONGLY RECOMMENDED to support the
+    `VK_ANDROID_external_memory_android_hardware_buffer` extension.
+
 #### 7.1.4.3 RenderScript
 
 *    [C-0-1] Device implementations MUST support [Android RenderScript](
@@ -334,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`.
 
@@ -357,12 +364,6 @@
 applications not developed for old versions of Android that pre-date
 screen-size independence.
 
-*   [H-0-1] Handheld device implementations 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 thresholds at which compatibility mode is activated, and MUST
-    NOT alter the behavior of the compatibility mode itself.
-
 ### 7.1.6\. Screen Technology
 
 The Android platform includes APIs that allow applications to render rich
@@ -388,4 +389,4 @@
 
 *   [C-1-1] MUST implement the [`DisplayManager`](
     https://developer.android.com/reference/android/hardware/display/DisplayManager.html)
-    system service and API as described in the Android SDK documentation.
\ No newline at end of file
+    system service and API as described in the Android SDK documentation.
diff --git a/7_hardware-compatibility/7_2_input-devices.md b/7_hardware-compatibility/7_2_input-devices.md
index 66fda1d..664d7c5 100644
--- a/7_hardware-compatibility/7_2_input-devices.md
+++ b/7_hardware-compatibility/7_2_input-devices.md
@@ -8,11 +8,6 @@
 
 ### 7.2.1\. Keyboard
 
-*    [H-0-1]  Handheld device implementations MUST include support for
-third-party Input Method Editor (IME) applications.
-*    [T-0-1] Television device implementations  MUST include support for
-third-party Input Method Editor (IME) applications.
-
 If device implementations include support for third-party
 Input Method Editor (IME) applications, they:
 
@@ -34,10 +29,6 @@
 Android includes support for d-pad, trackball, and wheel as mechanisms for
 non-touch navigation.
 
-Television device implementations:
-
-*    [T-0-1] MUST support [D-pad](https://developer.android.com/reference/android/content/res/Configuration.html#NAVIGATION_DPAD).
-
 Device implementations:
 
 *   [C-0-1] MUST report the correct value for
@@ -59,28 +50,13 @@
 and [Back](http://developer.android.com/reference/android/view/KeyEvent.html#`KEYCODE_BACK`)
 functions typically provided via an interaction with a dedicated physical button
 or a distinct portion of the touch screen, are essential to the Android
-navigation paradigm and therefore:
+navigation paradigm and therefore, device implementations:
 
-*   [H-0-1] Android Handheld device implementations MUST provide the Home,
-    Recents, and Back functions.
-*   [H-0-2] Android Handheld device implementations MUST send both the normal
-    and long press event of the the Back function ([`KEYCODE_BACK`](http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK))
-    to the foreground application.
-*   [T-0-1] Android Television device implementations MUST provide the Home
-    and Back functions.
-*   [T-0-2] Android Television device implementations MUST send both the normal
-    and long press event of the the Back function ([`KEYCODE_BACK`](http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK))
-    to the foreground application.
-*   [W-0-1] Android Watch device implementations MUST have the Home function
-    available to the user, and the Back function except for when it is in
-    `UI_MODE_TYPE_WATCH`.
-*   [A-0-1] Automotive device implementations MUST provide the Home function
-    and MAY provide Back and Recent functions.
-*   [A-0-2] Automotive device implementations MUST send both the normal
-    and long press event of the the Back function ([`KEYCODE_BACK`](http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK))
-    to the foreground application.
-
-*   [C-0-1] MUST provide the Home function.
+*   [C-0-1] MUST provide a user affordance to launch installed applications
+    that have an activity with the `<intent-filter>` set with `ACTION=MAIN` and
+    `CATEGORY=LAUNCHER` or `CATEGORY=LEANBACK_LAUNCHER` for Television device
+    implementations.
+    The Home function SHOULD be the mechanism for this user affordance.
 *   SHOULD provide buttons for the Recents and Back function.
 
 If the Home, Recents, or Back functions are provided, they:
@@ -139,15 +115,12 @@
 
 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
 being manipulated.
 
-*    [H-0-1] Handheld device implementations MUST support touchscreen input.
-*    [W-0-2] Watch device implementations MUST support touchscreen input.
-
 Device implementations:
 
 *    SHOULD have a pointer input system of some kind
@@ -236,10 +209,6 @@
 
 #### 7.2.6.1\. Button Mappings
 
-Television device implementations:
-*    [T-0-1] MUST include support for game controllers and declare the
-`android.hardware.gamepad` feature flag.
-
 If device implementations declare the `android.hardware.gamepad` feature flag,
 they:
 *    [C-1-1] MUST have embed a controller or ship with a separate controller
@@ -381,8 +350,5 @@
 
 ### 7.2.7\. Remote Control
 
-Television device implementations:
+See [Section 2.3.1](#2_3_1_hardware) for device-specific requirements.
 
-*    SHOULD provide a remote control from which users can access
-[non-touch navigation](#7_2_2_non-touch_navigation) and
-[core navigation keys](#7_2_3_navigation_keys) inputs.
\ No newline at end of file
diff --git a/7_hardware-compatibility/7_3_sensors.md b/7_hardware-compatibility/7_3_sensors.md
index 0553ac6..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.
@@ -82,25 +82,6 @@
 ### 7.3.1\. Accelerometer
 
 *   Device implementations SHOULD include a 3-axis accelerometer.
-*   [H-SR] Handheld device implementations are STRONGLY RECOMMENDED to
-    include a 3-axis accelerometer.
-*   [A-SR] Automotive device implementations are STRONGLY RECOMMENDED to
-    include a 3-axis accelerometer.
-*   [W-SR] Watch device implementations are STRONGLY RECOMMENDED to
-    include a 3-axis accelerometer.
-
-
-
-If Handheld device implementations include a 3-axis accelerometer, they:
-
-*   [H-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
-
-If Automotive device implementations include a 3-axis accelerometer, they:
-
-*   [A-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
-*   [A-1-2] MUST comply with the Android
-    [car sensor coordinate system](
-    http://source.android.com/devices/sensors/sensor-types.html#auto_axes).
 
 If device implementations include a 3-axis accelerometer, they:
 
@@ -222,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:
 
@@ -248,25 +228,19 @@
 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()`.
 
-If Automotive device implementations include a GPS/GNSS receiver and report
-the capability to applications through the `android.hardware.location.gps`
-feature flag:
-
-*   [A-1-1] GNSS technology generation MUST be the year "2017" or newer.
-
 If device implementations include a GPS/GNSS receiver and report the capability
 to applications through the `android.hardware.location.gps` feature flag and the
 `LocationManager.getGnssYearOfHardware()` Test API reports the year "2016" or
 newer, they:
 
-*    [C-2-1] MUST report 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,
@@ -284,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
 
@@ -318,19 +303,6 @@
 when device is stationary at room temperature.
 *   SHOULD report events up to at least 200 Hz.
 
-If Handheld device implementations include a gyroscope, they:
-
-*   [H-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
-
-If Automotive device implementations include a gyroscope, they:
-
-*   [A-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
-
-If Television device implementations include a gyroscope, they:
-
-*   [T-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
-
-
 If device implementations include a gyroscope, an accelerometer sensor and a
 magnetometer sensor, they:
 
@@ -385,9 +357,6 @@
 ### 7.3.8\. Proximity Sensor
 
 *   Device implementations MAY include a proximity sensor.
-*   Handheld device implementations that can make a voice call and indicate
-any value other than `PHONE_TYPE_NONE` in `getPhoneType`
-SHOULD include a proximity sensor.
 
 If device implementations include a proximity sensor, they:
 
@@ -412,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`.
@@ -435,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.
@@ -459,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.
@@ -490,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`
@@ -533,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:
 
@@ -548,75 +535,116 @@
 https://developer.android.com/reference/android/hardware/fingerprint/package-summary.html)
 as described in the Android SDK documentation.
 *   [C-1-3] MUST have a false acceptance rate not higher than 0.002%.
-*   [C-1-4] MUST rate limit attempts for at least 30 seconds after five false
+*   [SR] Are STRONGLY RECOMMENDED to have a spoof and imposter acceptance rate
+not higher than 7%.
+*   [C-1-4] MUST disclose that this mode may be less secure than a strong PIN,
+pattern, or password and clearly enumerate the risks of enabling it, if the
+spoof and imposter acceptance rates are higher than 7%.
+*   [C-1-5] MUST rate limit attempts for at least 30 seconds after five false
 trials for fingerprint verification.
-*   [C-1-5] MUST have a hardware-backed keystore implementation, and perform the
+*   [C-1-6] MUST have a hardware-backed keystore implementation, and perform the
 fingerprint matching in a Trusted Execution Environment (TEE) or on a chip with
 a secure channel to the TEE.
-*   [C-1-6] MUST have all identifiable fingerprint data encrypted and
+*   [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-7] MUST prevent adding a fingerprint without first establishing a chain
+*   [C-1-8] MUST prevent adding a fingerprint without first establishing a chain
 of trust by having the user confirm existing or add a new device credential
 (PIN/pattern/password) that's secured by TEE; the Android Open Source Project
     implementation provides the mechanism in the framework to do so.
-*   [C-1-8] MUST NOT enable 3rd-party applications to distinguish between
+*   [C-1-9] MUST NOT enable 3rd-party applications to distinguish between
 individual fingerprints.
-*   [C-1-9] MUST honor the DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT
+*   [C-1-10] MUST honor the DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT
 flag.
-*   [C-1-10] MUST, when upgraded from a version earlier than Android 6.0, have
+*   [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.
-*   [SR] STRONGLY RECOMMENDED to have a false rejection rate of less than 10%,
+*   [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] STRONGLY RECOMMENDED to have a latency below 1 second, measured from
+*   [SR] Are STRONGLY RECOMMENDED to have a latency below 1 second, measured from
 when the fingerprint sensor is touched until the screen is unlocked, for one
 enrolled finger.
 *   SHOULD use the Android Fingerprint icon provided in the Android Open Source
 Project.
 
+#### 7.3.10.2\. Other Biometric Sensors
+
+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
 `android.car.CarSensorManager API`.
 
-
 #### 7.3.11.1\. Current Gear
 
-*    Android Automotive implementations SHOULD provide current gear as
-`SENSOR_TYPE_GEAR`.
+See [Section 2.5.1](#2_5_1_hardware) for device-specific requirements.
 
 #### 7.3.11.2\. Day Night Mode
 
-Automotive device implementations:
-
-*    [A-0-1] MUST support day/night mode
-defined as `SENSOR_TYPE_NIGHT`.
-*    [A-0-2] The value of the `SENSOR_TYPE_NIGHT` flag MUST be consistent with
-dashboard day/night mode and SHOULD be based on ambient light sensor input.
-
-*    The underlying ambient light sensor MAY be the same as
-[Photometer](#7_3_7_photometer).
+See [Section 2.5.1](#2_5_1_hardware) for device-specific requirements.
 
 #### 7.3.11.3\. Driving Status
 
-Automotive device implementations:
-
-*    [A-0-1] MUST support driving status
-defined as `SENSOR_TYPE_DRIVING_STATUS`, with a default value of
-`DRIVE_STATUS_UNRESTRICTED` when the vehicle is fully stopped and parked. It is
-the responsibility of device manufacturers to configure
-`SENSOR_TYPE_DRIVING_STATUS` in compliance with all
-laws and regulations that apply to markets where the product is shipping.
+This requirement is deprecated.
 
 #### 7.3.11.4\. Wheel Speed
 
-Automotive device implementations:
+See [Section 2.5.1](#2_5_1_hardware) for device-specific requirements.
 
-*    [A-0-1] MUST provide vehicle speed defined as `SENSOR_TYPE_CAR_SPEED`.
+#### 7.3.11.5\. Parking Brake
+
+See [Section 2.5.1](#2_5_1_hardware) for device-specific requirements.
+
 
 ## 7.3.12\. Pose Sensor
 
@@ -624,10 +652,6 @@
 
 *   MAY support pose sensor with 6 degrees of freedom.
 
-Handheld device implementations are:
-
-*   RECOMMENDED to support this sensor.
-
 If device implementations support pose sensor with 6 degrees of freedom, they:
 
 *   [C-1-1] MUST implement and report [`TYPE_POSE_6DOF`](
diff --git a/7_hardware-compatibility/7_4_data-connectivity.md b/7_hardware-compatibility/7_4_data-connectivity.md
index d85d0de..a3e168f 100644
--- a/7_hardware-compatibility/7_4_data-connectivity.md
+++ b/7_hardware-compatibility/7_4_data-connectivity.md
@@ -54,6 +54,44 @@
 *   SHOULD migrate the blocked numbers into the provider when a device updates
 to Android 7.0.
 
+#### 7.4.1.2\. Telecom API
+
+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)
+    APIs as below:
+    *   Call [`Connection.onDisconnect()`](https://developer.android.com/reference/android/telecom/Connection.html#onDisconnect%28%29)
+        when a short press of the key event is detected during an ongoing call.
+    *   Call [`Connection.onAnswer()`](https://developer.android.com/reference/android/telecom/Connection.html#onAnswer%28%29)
+        when a short press of the key event is detected during an incoming call.
+    *   Call [`Connection.onReject()`](https://developer.android.com/reference/android/telecom/Connection.html#onReject%28%29)
+        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:
@@ -63,30 +101,53 @@
 If device implementations include support for 802.11 and expose the
 functionality to a third-party application, they:
 
-*   [C-1-1] MUST implement the corresponding Andr:oid API.
+*   [C-1-1] MUST implement the corresponding Android API.
 *   [C-1-2] MUST report the hardware feature flag `android.hardware.wifi`.
-*   [C-1-3] MUST implement the [multicast API](
-http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html)
-as described in the SDK documentation.
+*   [C-1-3] MUST implement the [multicast API](http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html)
+    as described in the SDK documentation.
 *   [C-1-4] MUST support multicast DNS (mDNS) and MUST NOT filter mDNS packets
-(224.0.0.251) at any time of operation including:
+    (224.0.0.251) at any time of operation including:
     *   Even when the screen is not in an active state.
     *   For Android Television device implementations, even when in standby
 power states.
-*   SHOULD randomize the source MAC address and sequence number of probe
-request frames, once at the beginning of each scan, while STA is disconnected.
+*   [C-1-5] MUST NOT treat the [`WifiManager.enableNetwork()`](
+    https://developer.android.com/reference/android/net/wifi/WifiManager.html#enableNetwork%28int%2C%20boolean%29)
+    API method call as a sufficient indication to switch the currently active
+    `Network` that is used by default for application traffic and is returned
+    by [`ConnectivityManager`](https://developer.android.com/reference/android/net/ConnectivityManager)
+    API methods such as [`getActiveNetwork`](https://developer.android.com/reference/android/net/ConnectivityManager#getActiveNetwork%28%29)
+    and [`registerDefaultNetworkCallback`](https://developer.android.com/reference/android/net/ConnectivityManager#registerDefaultNetworkCallback%28android.net.ConnectivityManager.NetworkCallback,%20android.os.Handler%29).
+    In other words, they MAY only disable the Internet access provided by any
+    other network provider (e.g. mobile data) if they successfully validate
+    that the Wi-Fi network is providing Internet access.
+*   [C-1-6] MUST, when the [`ConnectivityManager.reportNetworkConnectivity()`](
+    https://developer.android.com/reference/android/net/ConnectivityManager.html#reportNetworkConnectivity%28android.net.Network%2C%20boolean%29)
+    API method is called, re-evaluate the Internet access on the `Network` and,
+    once the evaluation determines that the current `Network` no longer provides
+    Internet access, switch to any other available network (e.g. mobile
+    data) that provides Internet access.
+*   [C-SR] Are STRONGLY RECOMMENDED to randomize the source MAC address and
+sequence number of probe request frames, once at the beginning of each scan,
+while STA is disconnected.
     * Each group of probe request frames comprising one scan should use one
     consistent MAC address (SHOULD NOT randomize MAC address halfway through a
     scan).
     * Probe request sequence number should iterate as normal (sequentially)
-    between the probe requests in a scan
+    between the probe requests in a scan.
     * Probe request sequence number should randomize between the last probe
-    request of a scan and the first probe request of the next scan
-*   SHOULD only allow the following information elements in probe request
-frames, while STA is disconnected:
+    request of a scan and the first probe request of the next scan.
+*   [C-SR] Are STRONGLY RECOMMENDED, while STA is disconnected, to allow only
+the following elements in probe request frames:
     * SSID Parameter Set (0)
     * DS Parameter Set (3)
 
+If device implementations support Wi-Fi and use Wi-Fi for location scanning,
+they:
+
+*    [C-2-1] MUST provide a user affordance to enable/disable the value read
+     through the [`WifiManager.isScanAlwaysAvailable`](https://developer.android.com/reference/android/net/wifi/WifiManager.html#isScanAlwaysAvailable%28%29)
+     API method.
+
 #### 7.4.2.1\. Wi-Fi Direct
 
 Device implementations:
@@ -100,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
 
@@ -138,6 +199,20 @@
 *   [C-1-4] MUST randomize the Wi-Fi Aware management interface address at intervals
     no longer then 30 minutes and whenever Wi-Fi Aware is enabled.
 
+If device implementations include support for Wi-Fi Aware and
+Wi-Fi Location as described in [Section 7.4.2.5](#7_4_2_5_Wi-Fi_Location) and
+exposes these functionalities to third-party apps, then they:
+
+*   [C-2-1] MUST implement the location-aware discovery APIs: [setRangingEnabled](
+https://developer.android.com/reference/android/net/wifi/aware/PublishConfig.Builder.html#setRangingEnabled%28boolean%29),
+ [setMinDistanceMm](
+https://developer.android.com/reference/android/net/wifi/aware/SubscribeConfig.Builder#setMinDistanceMm%28int%29),
+ [setMaxDistanceMm](
+https://developer.android.com/reference/android/net/wifi/aware/SubscribeConfig.Builder#setMaxDistanceMm%28int%29)
+, and
+ [onServiceDiscoveredWithinRange](
+https://developer.android.com/reference/android/net/wifi/aware/DiscoverySessionCallback#onServiceDiscoveredWithinRange%28android.net.wifi.aware.PeerHandle,%20byte[],%20java.util.List%3Cbyte[]%3E,%20int%29).
+
 #### 7.4.2.4\. Wi-Fi Passpoint
 
 Device implementations:
@@ -160,17 +235,35 @@
 *    [C-2-1] The implementation of the Passpoint related `WifiManager`
 APIs MUST throw an `UnsupportedOperationException`.
 
-### 7.4.3\. Bluetooth
+#### 7.4.2.5\. Wi-Fi Location (Wi-Fi Round Trip Time - RTT)
 
-*    [W-0-1] Watch device implementations MUST support Bluetooth.
-*    [T-0-1] Television device implementations MUST support Bluetooth and
-Bluetooth LE.
+Device implementations:
+
+*    SHOULD include support for [Wi-Fi Location](
+     https://www.wi-fi.org/discover-wi-fi/wi-fi-location).
+
+If device implementations include support for Wi-Fi Location and expose the
+functionality to third-party apps, then they:
+
+*   [C-1-1] MUST implement the `WifiRttManager` APIs as described in the
+[SDK documentation](
+http://developer.android.com/reference/android/net/wifi/rtt/WifiRttManager.html).
+*   [C-1-2] MUST declare the `android.hardware.wifi.rtt` feature flag.
+*   [C-1-3] MUST randomize the source MAC address for each RTT burst
+    which is executed while the Wi-Fi interface on which the RTT is
+    being executed is not associated to an Access Point.
+
+### 7.4.3\. Bluetooth
 
 If device implementations support Bluetooth Audio profile, they:
 
 *    SHOULD support Advanced Audio Codecs and Bluetooth Audio Codecs
 (e.g. LDAC).
 
+If device implementations support HFP, A2DP and AVRCP, they:
+
+*    SHOULD support at least 5 total connected devices.
+
 If device implementations declare `android.hardware.vr.high_performance`
 feature, they:
 
@@ -186,19 +279,7 @@
 (`android.hardware.bluetooth` and `android.hardware.bluetooth_le`
 respectively) and implement the platform APIs.
 *    SHOULD implement relevant Bluetooth profiles such as
-     A2DP, AVCP, OBEX, etc. as appropriate for the device.
-
-Automotive device implementations:
-*    [A-0-1] Automotive device implementations MUST support Bluetooth and
-SHOULD support Bluetooth LE.
-*    [A-0-2] Android Automotive implementations MUST support the following
-Bluetooth profiles:
-
-     * Phone calling over Hands-Free Profile (HFP).
-     * Media playback over Audio Distribution Profile (A2DP).
-     * Media playback control over Remote Control Profile (AVRCP).
-     * Contact sharing using the Phone Book Access Profile (PBAP).
-*    SHOULD support Message Access Profile (MAP).
+     A2DP, AVRCP, OBEX, HFP, etc. as appropriate for the device.
 
 If device implementations include support for Bluetooth Low Energy, they:
 
@@ -226,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:
@@ -360,42 +447,56 @@
 
 *   [C-0-1] MUST include support for one or more forms of
 data networking. Specifically, device implementations MUST include support for
-at least one data standard capable of 200Kbit/sec or greater. Examples of
+at least one data standard capable of 200 Kbit/sec or greater. Examples of
     technologies that satisfy this requirement include EDGE, HSPA, EV-DO,
-    802.11g, Ethernet, Bluetooth PAN, etc.
+    802.11g, Ethernet and Bluetooth PAN.
+*   SHOULD also include support for at least one common wireless data
+standard, such as 802.11 (Wi-Fi), when a physical networking standard (such as
+Ethernet) is the primary data connection.
+*   MAY implement more than one form of data connectivity.
 *   [C-0-2] MUST include an IPv6 networking stack and support IPv6
 communication using the managed APIs, such as `java.net.Socket` and
 `java.net.URLConnection`, as well as the native APIs, such as `AF_INET6`
 sockets.
 *   [C-0-3] MUST enable IPv6 by default.
-   *   MUST ensure that IPv6 communication is as reliable as IPv4, for example.
-   *   [C-0-4] MUST maintain IPv6 connectivity in doze mode.
-   *   [C-0-5] Rate-limiting MUST NOT cause the device to lose IPv6
-   connectivity on any IPv6-compliant network that uses RA lifetimes of
-   at least 180 seconds.
-*   SHOULD also include support for at least one common wireless data
-standard, such as 802.11 (Wi-Fi) when a physical networking standard (such as
-Ethernet) is the primary data connection
-*   MAY implement more than one form of data connectivity.
+   *   MUST ensure that IPv6 communication is as reliable as IPv4, for example:
+      *   [C-0-4] MUST maintain IPv6 connectivity in doze mode.
+      *   [C-0-5] Rate-limiting MUST NOT cause the device to lose IPv6
+      connectivity on any IPv6-compliant network that uses RA lifetimes of
+      at least 180 seconds.
+*   [C-0-6] MUST provide third-party applications with direct IPv6 connectivity
+to the network when connected to an IPv6 network, without any form of address or
+port translation happening locally on the device. Both managed APIs such as
+[`Socket#getLocalAddress`](
+https://developer.android.com/reference/java/net/Socket.html#getLocalAddress%28%29)
+or [`Socket#getLocalPort`](
+https://developer.android.com/reference/java/net/Socket.html#getLocalPort%28%29))
+and NDK APIs such as `getsockname()` or `IPV6_PKTINFO` MUST return the IP
+address and port that is actually used to send and receive packets on the
+network.
 
 
-The required level of IPv6 support depends on the network type, as follows:
+The required level of IPv6 support depends on the network type, as shown in
+the following requirements.
 
-If devices implementations support Wi-Fi networks, they:
+If device implementations support Wi-Fi, they:
 
 *   [C-1-1] MUST support dual-stack and IPv6-only operation on Wi-Fi.
 
-If device impelementations support Ethernet networks, they:
+If device implementations support Ethernet, they:
 
 *   [C-2-1] MUST support dual-stack operation on Ethernet.
 
-If device implementations support cellular data, they:
+If device implementations support Cellular data, they:
 
-*   [C-3-1] MUST simultaneously meet these requirements on each network to which
-it is connected when a device is simultaneously connected to more than one
-network (e.g., Wi-Fi and cellular data), .
 *   SHOULD support IPv6 operation (IPv6-only and possibly dual-stack) on
-cellular data.
+cellular.
+
+If device implementations support more than one network type (e.g., Wi-Fi
+and cellular data), they:
+
+*   [C-3-1] MUST simultaneously meet the above requirements on each network
+when the device is simultaneously connected to more than one network type.
 
 
 ### 7.4.6\. Sync Settings
@@ -413,10 +514,6 @@
 
 *   [SR] STRONGLY RECOMMENDED to provide the data saver mode.
 
-If Handheld device implementations include a metered connection, they:
-
-*   [H-1-1] MUST provide the data saver mode.
-
 If device implementations provide the data saver mode, they:
 
 *   [C-1-1] MUST support all the APIs in the `ConnectivityManager`
@@ -438,3 +535,12 @@
 *   [C-2-3] MUST have an activity that handles the
 `Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS`
     intent but MAY implement it as a no-op.
+
+### 7.4.8\. Secure Elements
+
+If device implementations support [Open Mobile API](https://developer.android.com/reference/android/se/omapi/package-summary)
+capable secure elements and make them available to 3rd-party apps, they:
+
+*   [C-1-1] MUST enumerate the available Secure Elements readers when
+[`android.se.omapi.SEService.getReaders()`](https://developer.android.com/reference/android/se/omapi/SEService#getReaders%28%29)
+method is called.
\ No newline at end of file
diff --git a/7_hardware-compatibility/7_5_cameras.md b/7_hardware-compatibility/7_5_cameras.md
index 570a8ae..dda1f9c 100644
--- a/7_hardware-compatibility/7_5_cameras.md
+++ b/7_hardware-compatibility/7_5_cameras.md
@@ -81,7 +81,6 @@
 *    [C-2-1] The camera preview MUST be mirrored horizontally relative to
 the device’s current orientation.
 
-
 ### 7.5.3\. External Camera
 
 Device implementations:
@@ -89,12 +88,15 @@
 *    MAY include support for an external camera that is not necessarily
 always connected.
 
-If device impelmentations include support for an external camera, they:
+If device implementations include support for an external camera, they:
 
 *   [C-1-1] MUST declare the platform feature flag
 `android.hardware.camera.external` and `android.hardware camera.any`.
 *   [C-1-2] MUST support USB Video Class (UVC 1.0 or higher) if the external
-camera connects through the USB port.
+camera connects through the USB host port.
+*   [C-1-3] MUST pass camera CTS tests with a physical external camera device
+connected. Details of camera CTS testing are available at [source.android.com](
+https://source.android.com/compatibility/cts/camera-hal).
 *   SHOULD support video compressions such as MJPEG to enable transfer of
     high-quality unencoded streams (i.e. raw or independently compressed picture
     streams).
@@ -115,11 +117,19 @@
 exposure, gain, white balance gains, color conversion, denoising, sharpening,
 and more.
 
-The older API package, `android.hardware.Camera`, is marked as deprecated in
+The older API package,`android.hardware.Camera`, is marked as deprecated in
 Android 5.0 but as it should still be available for apps to use. Android device
 implementations MUST ensure the continued support of the API as described in
 this section and in the Android SDK.
 
+All features that are common between the deprecated android.hardware.Camera class
+and the newer android.hardware.camera2 package MUST have equivalent performance
+and quality in both APIs. For example, with equivalent settings,
+autofocus speed and accuracy must be identical, and the quality of captured images
+must be the same. Features that depend on the different semantics of the two APIs
+are not required to have matching speed or quality, but SHOULD match as closely
+as possible.
+
 Device implementations MUST implement the following behaviors for the
 camera-related APIs, for all available cameras. Device implementations:
 
@@ -184,6 +194,16 @@
 *   [C-0-10] MUST broadcast the `Camera.ACTION_NEW_VIDEO`
 intent whenever a new video is recorded by the camera and the entry of the
 picture has been added to the media store.
+*   [C-SR] Are STRONGLY RECOMMENDED to support a logical camera device that lists
+capability
+[`CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA`](
+https://developer.android.com/reference/android/hardware/camera2/CameraMetadata#REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA),
+for devices with multiple cameras facing the same direction, consisting of each
+physical camera facing that direction, as long as the physical camera type is
+supported by the framework and
+[`CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL`](
+https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics#INFO_SUPPORTED_HARDWARE_LEVEL)
+for the physical cameras is either `LIMITED`, `FULL`, or `LEVEL_3`.
 
 ### 7.5.5\. Camera Orientation
 
diff --git a/7_hardware-compatibility/7_6_memory-and-storage.md b/7_hardware-compatibility/7_6_memory-and-storage.md
index 8af504f..fa5998d 100644
--- a/7_hardware-compatibility/7_6_memory-and-storage.md
+++ b/7_hardware-compatibility/7_6_memory-and-storage.md
@@ -10,97 +10,6 @@
     downloading individual files of at least 100MB in size to the default
     “cache” location.
 
-Television device implementations:
-
-*   [T-0-1] MUST have at least 4GB of non-volatile storage available for
-    application private data (a.k.a. "/data" partition)
-
-Automotive device implementations:
-
-*   [A-0-1] MUST have at least 4GB of non-volatile storage available for
-    application private data (a.k.a. "/data" partition)
-
-Watch device implementations:
-
-*   [W-0-1] MUST have at least 1GB of non-volatile storage available for
-    application private data (a.k.a. "/data" partition)
-*   [W-0-2] MUST have at least 416MB memory available to the kernel and
-    userspace.
-
-Handheld device implementations:
-
-*   [H-0-1] MUST have at least 4GB of non-volatile storage available for
-    application private data (a.k.a. "/data" partition)
-*   [H-0-2] MUST return “true” for `ActivityManager.isLowRamDevice()` when there
-    is less than 1GB of memory available to the kernel and userspace.
-
-
-If Handheld device implementations are 32-bit:
-
-*   [H-1-1] The memory available to the kernel and userspace MUST
-be at least: 512MB if any of the following densities are used:
-
-   *   280dpi or lower on small/normal screens
-   *   ldpi or lower on extra large screens
-   *   mdpi or lower on large screens
-
-*   [H-2-1] The memory available to the kernel and userspace MUST
-be at least: 608MB if any of the following densities are used:
-
-   *   xhdpi or higher on small/normal screens
-   *   hdpi or higher on large screens
-   *   mdpi or higher on extra large screens
-
-*   [H-3-1] The memory available to the kernel and userspace MUST
-be at least: 896MB if any of the following densities are used:
-
-   *   400dpi or higher on small/normal screens
-   *   xhdpi or higher on large screens
-   *   tvdpi or higher on extra large screens
-
-*    [H-4-1] The memory available to the kernel and userspace MUST
-be at least: 1344MB if any of the following densities are used:
-
-   *   560dpi or higher on small/normal screens
-   *   400dpi or higher on large screens
-   *   xhdpi or higher on extra large screens
-
-If Handheld device implementations are 64-bit:
-
-*   [H-5-1] The memory available to the kernel and userspace MUST
-be at least: 816MB if any of the following densities are used:
-
-   *   280dpi or lower on small/normal screens
-   *   ldpi or lower on extra large screens
-   *   mdpi or lower on large screens
-
-
-*   [H-6-1] The memory available to the kernel and userspace MUST
-be at least: 944MB if any of the following densities are used:
-
-   *   xhdpi or higher on small/normal screens
-   *   hdpi or higher on large screens
-   *   mdpi or higher on extra large screens
-
-*   [H-7-1] The memory available to the kernel and userspace MUST
-be at least: 1280MB if any of the following densities are used:
-
-   *  400dpi or higher on small/normal screens
-   *  xhdpi or higher on large screens
-   *  tvdpi or higher on extra large screens
-
-*    [H-8-1] The memory available to the kernel and userspace MUST
-be at least: 1824MB if any of the following densities are used:
-
-   *   560dpi or higher on small/normal screens
-   *   400dpi or higher on large screens
-   *   xhdpi or higher on extra large screens
-
-Note that the "memory available to the kernel and userspace" above refers to the
-memory space provided in addition to any memory already dedicated to hardware
-components such as radio, video, and so on that are not under the kernel’s
-control on device implementations.
-
 ### 7.6.2\. Application Shared Storage
 
 Device implementations:
diff --git a/7_hardware-compatibility/7_7_usb.md b/7_hardware-compatibility/7_7_usb.md
index 27d10ef..90db766 100644
--- a/7_hardware-compatibility/7_7_usb.md
+++ b/7_hardware-compatibility/7_7_usb.md
@@ -6,11 +6,6 @@
 
 ### 7.7.1\. USB peripheral mode
 
-If handheld device implementations include a USB port supporting peripheral
-mode, they:
-
-*    [H-1-1] MUST implement the Android Open Accessory (AOA) API.
-
 If device implementations include a USB port supporting peripheral mode:
 
 *    [C-1-1] The port MUST be connectable to a USB host that has a standard
@@ -47,8 +42,8 @@
 *    SHOULD implement the Android Open Accessory (AOA) API and specification as
 documented in the Android SDK documentation.
 
-If device implementations including a USB port, implement the AOA specification,
-they:
+If device implementations include a USB port and implement the AOA
+specification, they:
 
 *    [C-2-1] MUST declare support for the hardware feature
 [`android.hardware.usb.accessory`](http://developer.android.com/guide/topics/connectivity/usb/accessory.html).
@@ -68,12 +63,12 @@
 [`android.hardware.usb.host`](http://developer.android.com/guide/topics/connectivity/usb/host.html).
 *   [C-1-2] MUST implement support to connect standard USB peripherals,
 in other words, they MUST either:
-   *   Have an on-device type C port or ship with cable(s) adapting an on-device
-   proprietary port to a standard USB type-C port (USB Type-C device).
-   *   Have an on-device type A or ship with cable(s) adapting an on-device
-   proprietary port to a standard USB type-A port.
-   *   Have an on-device micro-AB port, which SHOULD ship with a cable adapting
-   to a standard type-A port.
+     *   Have an on-device type C port or ship with cable(s) adapting an on-device
+     proprietary port to a standard USB type-C port (USB Type-C device).
+     *   Have an on-device type A or ship with cable(s) adapting an on-device
+     proprietary port to a standard USB type-A port.
+     *   Have an on-device micro-AB port, which SHOULD ship with a cable adapting
+     to a standard type-A port.
 *   [C-1-3] MUST NOT ship with an adapter converting from USB type A or
 micro-AB ports to a type-C port (receptacle).
 *   [SR] STRONGLY RECOMMENDED to implement the [USB audio class](
@@ -99,10 +94,10 @@
 and the [Voice Command Usage Request](http://www.usb.org/developers/hidpage/Voice_Command_Usage.pdf)
 to the [`KeyEvent`](https://developer.android.com/reference/android/view/KeyEvent.html)
 constants as below:
-        *   Usage Page (0xC) Usage ID (0x0CD): `KEYCODE_MEDIA_PLAY_PAUSE`
-        *   Usage Page (0xC) Usage ID (0x0E9): `KEYCODE_VOLUME_UP`
-        *   Usage Page (0xC) Usage ID (0x0EA): `KEYCODE_VOLUME_DOWN`
-        *   Usage Page (0xC) Usage ID (0x0CF): `KEYCODE_VOICE_ASSIST`
+       *   Usage Page (0xC) Usage ID (0x0CD): `KEYCODE_MEDIA_PLAY_PAUSE`
+       *   Usage Page (0xC) Usage ID (0x0E9): `KEYCODE_VOLUME_UP`
+       *   Usage Page (0xC) Usage ID (0x0EA): `KEYCODE_VOLUME_DOWN`
+       *   Usage Page (0xC) Usage ID (0x0CF): `KEYCODE_VOICE_ASSIST`
 
 
 If device implementations include a USB port supporting host mode and
@@ -126,4 +121,4 @@
 http://www.usb.org/developers/docs/).
 *   SHOULD implement the Try.\* model that is most appropriate for the
 device form factor. For example a handheld device SHOULD implement the
-Try.SNK model.
\ No newline at end of file
+Try.SNK model.
diff --git a/7_hardware-compatibility/7_8_audio.md b/7_hardware-compatibility/7_8_audio.md
index c9944f7..b1ec118 100644
--- a/7_hardware-compatibility/7_8_audio.md
+++ b/7_hardware-compatibility/7_8_audio.md
@@ -2,11 +2,6 @@
 
 ### 7.8.1\. Microphone
 
-
-*    [H-0-1] Handheld device implementations MUST include a microphone.
-*    [W-0-1] Watch device implementations MUST include a microphone.
-*    [A-0-1] Automotive device implementations MUST include a microphone.
-
 If device implementations include a microphone, they:
 
 *   [C-1-1] MUST report the `android.hardware.microphone` feature constant.
@@ -41,16 +36,9 @@
 
 If device implementations do not include a speaker or audio output port, they:
 
-*   [C-2-1] MUST NOT report the `android.hardware.audio output` feature.
+*   [C-2-1] MUST NOT report the `android.hardware.audio.output` feature.
 *   [C-2-2] MUST implement the Audio Output related APIs as no-ops at least.
 
-*   [H-0-1] Handheld device implementations MUST have an audio output and
-declare `android.hardware.audio.output`.
-*   [T-0-1] Television device implementations MUST have an audio output and
-declare `android.hardware.audio.output`.
-*   [A-0-1] Automotive device implementations MUST have an audio output and
-declare `android.hardware.audio.output`.
-*   Watch device implementations MAY but SHOULD NOT have audio output.
 
 For the purposes of this section, an "output port" is a
 [physical interface](https://en.wikipedia.org/wiki/Computer_port_%28hardware%29)
@@ -61,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:
 
@@ -83,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 44df56a..ff9deb2 100644
--- a/7_hardware-compatibility/7_9_virtual-reality.md
+++ b/7_hardware-compatibility/7_9_virtual-reality.md
@@ -12,36 +12,16 @@
 a feature which handles stereoscopic rendering of notifications and disables
 monocular system UI components while a VR application has user focus.
 
-If Handheld device implementations include support for the VR mode, they:
+### 7.9.2\. Virtual Reality Mode - High Performance
 
-*   [H-1-1] MUST declare the `android.software.vr.mode` feature.
-
-If device implementations declare `android.software.vr.mode` feature, they:
-
-*   [H-2-1] MUST include an application implementing
-`android.service.vr.VrListenerService`
-that can be enabled by VR applications via
-`android.app.Activity#setVrModeEnabled`.
-
-### 7.9.2\. Virtual Reality High Performance
-
-
-If Handheld device implementations are capable of meeting all the requirements
-to declare the `android.hardware.vr.high_performance` feature flag, they:
-
-*   [H-1-1] MUST declare the `android.hardware.vr.high_performance`
-feature flag.
-
-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),
@@ -50,46 +30,90 @@
     [`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),
     [`GL_EXT_protected_textures`](https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_protected_textures.txt),
+    [`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 on Gray-to-Gray, White-to-Black, and
-Black-to-White switching time MUST be ≤ 3 ms.
-*   [C-1-17] The display MUST support a low-persistence mode with ≤5 ms
-persistence, persistence being defined as the amount of time for
-which a pixel is emitting light.
+*   [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.
 *   [C-1-18] MUST support Bluetooth 4.2 and Bluetooth LE Data Length Extension
     [section 7.4.3](#7_4_3_bluetooth).
-*   [SR] 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-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`
+      * `TYPE_GYROSCOPE`
+      * `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)
+    direct channel type for all Direct Channel Types listed above.
+*   [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_1_user-experience-consistency.md b/8_performance-and-power/8_1_user-experience-consistency.md
index 9728f44..85f8a14 100644
--- a/8_performance-and-power/8_1_user-experience-consistency.md
+++ b/8_performance-and-power/8_1_user-experience-consistency.md
@@ -6,15 +6,3 @@
 MAY have measurable requirements for the user interface latency and task
 switching as described in [section 2](#2_device-types).
 
-   *   [H-0-1] **Consistent frame latency**. Inconsistent frame latency or a
-delay to render frames MUST NOT happen more often than 5 frames in a second,
-and SHOULD be below 1 frames in a second.
-   *   [H-0-2] **User interface latency**. Device implementations MUST ensure
-low latency user experience by scrolling a list of 10K list entries as defined
-by the Android Compatibility Test Suite (CTS) in less than 36 secs.
-   *   [H-0-3] **Task switching**. When multiple applications have been
-launched, re-launching an already-running application after it has been
-launched MUST take less than 1 second.
-   *   [T-0-1] **Consistent frame latency**. Inconsistent frame latency or a
-delay to render frames MUST NOT happen more often than 5 frames in a second,
-and SHOULD be below 1 frames in a second.
diff --git a/8_performance-and-power/8_2_file-io-access-performance.md b/8_performance-and-power/8_2_file-io-access-performance.md
index 7508aff..c667ec5 100644
--- a/8_performance-and-power/8_2_file-io-access-performance.md
+++ b/8_performance-and-power/8_2_file-io-access-performance.md
@@ -7,7 +7,6 @@
 described in [section 2](#2_device-type) for the following read
 and write operations:
 
-
 *    **Sequential write performance**. Measured by writing a 256MB file using
 10MB write buffer.
 *    **Random write performance**. Measured by writing a 256MB file using 4KB
@@ -17,16 +16,3 @@
 *    **Random read performance**. Measured by reading a 256MB file using 4KB
 write buffer.
 
-Handheld device implementations:
-
-   *   [H-0-1] MUST ensure a sequential write performance of at least 5MB/s.
-   *   [H-0-2] MUST ensure a random write performance of at least 0.5MB/s.
-   *   [H-0-3] MUST ensure a sequential read performance of at least 15MB/s.
-   *   [H-0-4] MUST ensure a random read performance of at least 3.5MB/s.
-
-Television device implementations:
-
-   *   [T-0-1] MUST ensure a sequential write performance of at least 5MB/s.
-   *   [T-0-2] MUST ensure a random write performance of at least 0.5MB/s.
-   *   [T-0-3] MUST ensure a sequential read performance of at least 15MB/s.
-   *   [T-0-4] MUST ensure a random read performance of at least 3.5MB/s.
\ No newline at end of file
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 a6a5bf3..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,38 +1,39 @@
 ## 8.3\. Power-Saving Modes
 
-Android includes App Standby and Doze power-saving modes to optimize battery
-usage.
+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:
 
-*   [H-0-1] All Apps exempted from App Standby and Doze power-saving modes
-MUST be made visible to the end user.
-*   [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.
-
-*   [T-0-1] All Apps exempted from App Standby and Doze power-saving modes
-MUST be made visible to the end user.
-*   [T-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.
-
-*   [A-0-1] All Apps exempted from App Standby and Doze power-saving modes
-MUST be made visible to the end user.
-*   [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.
-
-*   [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.
+*   [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/8_performance-and-power/8_4_power-consumption-accounting.md b/8_performance-and-power/8_4_power-consumption-accounting.md
index 0628b10..0e688fe 100644
--- a/8_performance-and-power/8_4_power-consumption-accounting.md
+++ b/8_performance-and-power/8_4_power-consumption-accounting.md
@@ -4,62 +4,6 @@
 app developer both the incentives and the tools to optimize the power usage
 pattern of the application.
 
-Handheld device implementations:
-
-*    [H-0-1] MUST provide a per-component power profile that defines the
-[current consumption value](
-http://source.android.com/devices/tech/power/values.html)
-for each hardware component and the approximate battery drain caused by the
-components over time as documented in the Android Open Source Project site.
-*    [H-0-2] MUST report all power consumption values in milliampere
-hours (mAh).
-*    [H-0-3] MUST report CPU power consumption per each process's UID.
-The Android Open Source Project meets the requirement through the
-`uid_cputime` kernel module implementation.
-*    SHOULD be attributed to the hardware component itself if unable to
-attribute hardware component power usage to an application.
-*   [H-0-4] MUST make this power usage available via the
-[`adb shell dumpsys batterystats`](
-http://source.android.com/devices/tech/power/batterystats.html)
-shell command to the app developer.
-
-Television device implementations:
-
-*    [T-0-1] MUST provide a per-component power profile that defines the
-[current consumption value](
-http://source.android.com/devices/tech/power/values.html)
-for each hardware component and the approximate battery drain caused by the
-components over time as documented in the Android Open Source Project site.
-*    [T-0-2] MUST report all power consumption values in milliampere
-hours (mAh).
-*    [T-0-3] MUST report CPU power consumption per each process's UID.
-The Android Open Source Project meets the requirement through the
-`uid_cputime` kernel module implementation.
-*    SHOULD be attributed to the hardware component itself if unable to
-attribute hardware component power usage to an application.
-*   [T-0-4] MUST make this power usage available via the
-[`adb shell dumpsys batterystats`](
-http://source.android.com/devices/tech/power/batterystats.html)
-shell command to the app developer.
-
-Automotive device implementations:
-
-*    [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)
-for each hardware component and the approximate battery drain caused by the
-components over time as documented in the Android Open Source Project site.
-*    [A-0-2] MUST report all power consumption values in milliampere
-hours (mAh).
-*    [A-0-3] MUST report CPU power consumption per each process's UID.
-The Android Open Source Project meets the requirement through the
-`uid_cputime` kernel module implementation.
-*    SHOULD be attributed to the hardware component itself if unable to
-attribute hardware component power usage to an application.
-*   [A-0-4] MUST make this power usage available via the
-[`adb shell dumpsys batterystats`](
-http://source.android.com/devices/tech/power/batterystats.html)
-shell command to the app developer.
 
 Device implementations:
 
@@ -81,9 +25,4 @@
 attribute hardware component power usage to an application.
 
 
-If Handheld device implementations include a screen or video output, they:
-
-*   [H-1-1] MUST honor the [`android.intent.action.POWER_USAGE_SUMMARY`](
-http://developer.android.com/reference/android/content/Intent.html#ACTION_POWER_USAGE_SUMMARY)
-intent and display a settings menu that shows this power usage.
 
diff --git a/9_security-model/9_10_device-integrity.md b/9_security-model/9_10_device-integrity.md
index 1b4557d..366b7bd 100644
--- a/9_security-model/9_10_device-integrity.md
+++ b/9_security-model/9_10_device-integrity.md
@@ -9,8 +9,15 @@
 reserved for device implementations upgrading from an earlier version of Android
 where this new system API method did not exist.
 
-Verified boot is a feature that guarantees the integrity of the device
-software. If a device implementation supports the feature, it:
+*    [C-0-2] MUST support Verified Boot for device integrity.
+
+If device implementations are already launched without supporting Verified Boot
+on an earlier version of Android and can not add support for this
+feature with a system software update, they MAY be exempted from the
+requirement.
+
+Verified Boot is a feature that guarantees the integrity of the device
+software. If device implementations support the feature, they:
 
 *    [C-1-1] MUST declare the platform feature flag
 `android.software.verified_boot`.
@@ -28,30 +35,43 @@
 any non-verified storage blocks MUST not be used.
 *    [C-1-7] MUST NOT allow verified partitions on the device to be modified
 unless the user has explicitly unlocked the boot loader.
-*    [SR] If there are multiple discrete chips in the device (e.g. radio,
+*    [C-SR] If there are multiple discrete chips in the device (e.g. radio,
 specialized image processor), the boot process of each of those chips is
 STRONGLY RECOMMENDED to verify every stage upon booting.
-*    [SR] STRONGLY RECOMMENDED to use tamper-evident storage: for when the
+*    [C-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).
-*    [SR] 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.
-*    [SR] STRONGLY RECOMMENDED to implement rollback protection for the HLOS
-(e.g. boot, system partitions) and to use tamper-evident storage for storing the
+*    [C-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.
+*    [C-SR] Are STRONGLY RECOMMENDED to verify any executable artifacts loaded by
+a privileged app from outside its APK file (such as dynamically loaded code or
+compiled code) before executing them or STRONGLY RECOMMENDED not to execute them
+at all.
 *    SHOULD implement rollback protection for any component with persistent
 firmware (e.g. modem, camera) and SHOULD use tamper-evident storage for
 storing the metadata used for determining the minimum allowable version.
 
+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.
 
-Device implementations with Advanced Encryption Standard (AES) crypto
-performance above 50 MiB/seconds:
+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.
 
@@ -59,3 +79,20 @@
 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 503ed90..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
@@ -27,7 +28,9 @@
 implementation of a proper hypervisor-based isolation are alternative options.
 *    [C-1-3] MUST perform the lock screen authentication in the isolated
 execution environment and only when successful, allow the authentication-bound
-keys to be used. The upstream Android Open Source Project provides the
+keys to be used. Lock screen credentials MUST be stored in a
+way that allows only the isolated execution environment to perform lock screen
+authentication. The upstream Android Open Source Project provides the
 [Gatekeeper Hardware Abstraction Layer (HAL)](http://source.android.com/devices/tech/security/authentication/gatekeeper.html)
 and Trusty, which can be used to satisfy this requirement.
 *    [C-1-4] MUST support key attestation where the attestation signing key is
@@ -37,114 +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`.
-*    [C-5-4] The user MUST be challenged for the primary authentication
-(e.g.PIN, pattern, password) at least once every 72 hours or less.
+*    [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 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:
+### 9.11.2\. StrongBox
 
-*    [C-6-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-6-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-6-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-6-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)).
+The [Android Keystore System](
+https://developer.android.com/training/articles/keystore.html) allows
+app developers to store cryptographic keys in a dedicated secure processor as
+well as the isolated execution environment described above.
+
+Device implementations:
+
+*    [C-SR] Are STRONGLY RECOMMENDED to support StrongBox.
+
+If device implementations support StrongBox, they:
+
+*    [C-1-1] MUST declare [FEATURE_STRONGBOX_KEYSTORE](
+https://developer.android.com/reference/kotlin/android/content/pm/PackageManager#FEATURE_STRONGBOX_KEYSTORE%3Akotlin.String).
+
+*    [C-1-2] MUST provide dedicated secure hardware that is used to back
+keystore and secure user authentication.
+
+*    [C-1-3] MUST have a discrete CPU that shares no cache, DRAM, coprocessors
+or other core resources with the application processor (AP).
+
+*    [C-1-4] MUST ensure that any peripherals shared with the AP cannot alter
+StrongBox processing in any way, or obtain any information from the StrongBox.
+The AP MAY disable or block access to StrongBox.
+
+*    [C-1-5] MUST have an internal clock with reasonable accuracy (+-10%)
+that is immune to manipulation by the AP.
+
+*    [C-1-6] MUST have a true random number generator that produces
+uniformly-distributed and unpredictable output.
+
+*    [C-1-7] MUST have tamper resistance, including resistance against
+physical penetration, and glitching.
+
+*    [C-1-8] MUST have side-channel resistance, including resistance against
+leaking information via power, timing, electromagnetic radiation, and thermal
+radiation side channels.
+
+*    [C-1-9] MUST have secure storage which ensures confidentiality,
+integrity, authenticity, consistency, and freshness of the
+contents. The storage MUST NOT be able to be read or altered, except
+as permitted by the StrongBox APIs.
+
+*    To validate compliance with [C-1-3] through [C-1-9], device
+     implementations:
+
+    *    [C-1-10] MUST include the hardware that is certified against the
+         Secure IC Protection Profile [BSI-CC-PP-0084-2014](
+         https://www.commoncriteriaportal.org/files/ppfiles/pp0084b_pdf.pdf) or
+         evaluated by a nationally accredited testing laboratory incorporating
+         High attack potential vulnerability assessment according to the
+         [Common Criteria Application of Attack Potential to Smartcards](
+       https://www.commoncriteriaportal.org/files/supdocs/CCDB-2013-05-002.pdf).
+    *    [C-1-11] MUST include the firmware that is evaluated by a
+         nationally accredited testing laboratory incorporating High attack
+         potential vulnerability assessment according to the
+         [Common Criteria Application of Attack Potential to Smartcards](
+         https://www.commoncriteriaportal.org/files/supdocs/CCDB-2013-05-002.pdf).
+    *    [C-SR] Are STRONGLY RECOMMENDED to include the hardware that is
+         evaluated using a Security Target, Evaluation Assurance Level
+         (EAL) 5, augmented by AVA_VAN.5.  EAL 5 certification will likely
+         become a requirement in a future release.
+
+*    [C-SR] are STRONGLY RECOMMENDED to provide insider attack resistance (IAR),
+which means that an insider with access to firmware signing keys cannot produce
+firmware that causes the StrongBox to leak secrets, to bypass functional
+security requirements or otherwise enable access to sensitive user data. The
+recommended way to implement IAR is to allow firmware updates only when the
+primary user password is provided via the IAuthSecret HAL. IAR will likely
+become a requirement in a future release.
\ No newline at end of file
diff --git a/9_security-model/9_14_automotive-system-isolation.md b/9_security-model/9_14_automotive-system-isolation.md
index a1d5276..046ebd4 100644
--- a/9_security-model/9_14_automotive-system-isolation.md
+++ b/9_security-model/9_14_automotive-system-isolation.md
@@ -6,11 +6,5 @@
 
 The data exchange can be secured by implementing security features below the
 Android framework layers to prevent malicious or unintentional interaction with
-these subsystems. Automotive device implementations:
+these subsystems.
 
-*    [A-0-1] MUST gatekeep messages from Android framework vehicle subsystems,
-e.g., whitelisting permitted message types and message sources.
-*    [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.
\ No newline at end of file
diff --git a/9_security-model/9_15_subscription-plans.md b/9_security-model/9_15_subscription-plans.md
new file mode 100644
index 0000000..bd3e46b
--- /dev/null
+++ b/9_security-model/9_15_subscription-plans.md
@@ -0,0 +1,12 @@
+## 9.15\. Subscription Plans
+
+"Subscription plans" refer to the billing relationship plan details provided
+by a mobile carrier through [`SubscriptionManager.setSubscriptionPlans()`](https://developer.android.com/reference/android/telephony/SubscriptionManager.html#setSubscriptionPlans%28int, java.util.List<android.telephony.SubscriptionPlan>%29).
+
+All device implementations:
+
+* [C-0-1] MUST return subscription plans only to the mobile carrier app that
+has originally provided them.
+* [C-0-2] MUST NOT remotely back up or upload subscription plans.
+* [C-0-3] MUST only allow overrides, such as [`SubscriptionManager.setSubscriptionOverrideCongested()`](https://developer.android.com/reference/android/telephony/SubscriptionManager.html#setSubscriptionOverrideCongested%28int, boolean, long%29),
+from the mobile carrier app currently providing valid subscription plans.
diff --git a/9_security-model/9_1_permissions.md b/9_security-model/9_1_permissions.md
index c46365b..7e6610c 100644
--- a/9_security-model/9_1_permissions.md
+++ b/9_security-model/9_1_permissions.md
@@ -37,15 +37,15 @@
        uses it
    *   the runtime permissions are associated with an intent pattern
        for which the preinstalled application is set as the default handler
-
-Handheld device implementations:
-
-*   [H-0-1] MUST allow third-party apps to access the usage statistics via the
-    `android.permission.PACKAGE_USAGE_STATS` permission and provide a
-    user-accessible mechanism to grant or revoke access to such apps in response
-    to the [`android.settings.ACTION_USAGE_ACCESS_SETTINGS`](
-    https://developer.android.com/reference/android/provider/Settings.html#ACTION&lowbar;USAGE&lowbar;ACCESS&lowbar;SETTINGS)
-    intent.
+*   [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:
@@ -64,4 +64,4 @@
     [`android.settings.ACTION_USAGE_ACCESS_SETTINGS`](
     https://developer.android.com/reference/android/provider/Settings.html#ACTION&lowbar;USAGE&lowbar;ACCESS&lowbar;SETTINGS)
     intent pattern but MUST implement it as a no-op, that is to have an
-    equivalent behavior as when the user is declined for access.
\ No newline at end of file
+    equivalent behavior as when the user is declined for access.
diff --git a/9_security-model/9_5_multi-user-support.md b/9_security-model/9_5_multi-user-support.md
index 4f201e5..d266b0c 100644
--- a/9_security-model/9_5_multi-user-support.md
+++ b/9_security-model/9_5_multi-user-support.md
@@ -9,11 +9,6 @@
 http://developer.android.com/reference/android/os/Environment.html)
 for primary external storage.
 
-If Automotive device implementations include multiple users, they:
-
-*   [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 device implementations include multiple users, they:
 
 *   [C-1-1] MUST meet the following requirements related to
diff --git a/9_security-model/9_7_kernel-security-features.md b/9_security-model/9_7_security-features.md
similarity index 71%
rename from 9_security-model/9_7_kernel-security-features.md
rename to 9_security-model/9_7_security-features.md
index e4aebaa..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
@@ -36,18 +38,24 @@
 *   [C-0-8] MUST implement strict kernel memory protections where executable
 code is read-only, read-only data is non-executable and non-writable, and
 writable data is non-executable (e.g. `CONFIG_DEBUG_RODATA` or `CONFIG_STRICT_KERNEL_RWX`).
+*   [C-0-9] MUST implement static and dynamic object size
+bounds checking of copies between user-space and kernel-space
+(e.g. `CONFIG_HARDENED_USERCOPY`) on devices originally shipping with API level
+28 or higher.
+*   [C-0-10] MUST NOT execute user-space memory when executing
+in the kernel mode (e.g. hardware PXN, or emulated via
+`CONFIG_CPU_SW_DOMAIN_PAN` or `CONFIG_ARM64_SW_TTBR0_PAN`) on devices
+originally shipping with API level 28 or higher.
+*   [C-0-11] MUST NOT read or write user-space memory in the
+kernel outside of normal usercopy access APIs (e.g. hardware PAN, or
+emulated via `CONFIG_CPU_SW_DOMAIN_PAN` or `CONFIG_ARM64_SW_TTBR0_PAN`)
+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
 initialization (e.g. `__ro_after_init`).
-*   [SR} STRONGLY RECOMMENDED to implement static and dynamic object size
-bounds checking of copies between user-space and kernel-space
-(e.g. `CONFIG_HARDENED_USERCOPY`).
-*   [SR] STRONGLY RECOMMENDED to never execute user-space memory when running
-in the kernel (e.g. hardware PXN, or emulated via
-`CONFIG_CPU_SW_DOMAIN_PAN` or `CONFIG_ARM64_SW_TTBR0_PAN`).
-*   [SR] STRONGLY RECOMMENDED to never read or write user-space memory in the
-kernel outside of normal usercopy access APIs (e.g. hardware PAN, or
-emulated via `CONFIG_CPU_SW_DOMAIN_PAN` or `CONFIG_ARM64_SW_TTBR0_PAN`).
 *   [SR] STRONGLY RECOMMENDED to randomize the layout of the kernel code and
 memory, and to avoid exposures that would compromise the randomization
 (e.g. `CONFIG_RANDOMIZE_BASE` with bootloader entropy via the
@@ -65,6 +73,9 @@
 within the system/sepolicy folder provided in the upstream Android Open Source
 Project (AOSP) and the policy MUST compile with all neverallow rules present,
 for both AOSP SELinux domains as well as device/vendor specific domains.
+*   [C-1-5] MUST run third-party applications targeting API level 28 or higher
+in per-application SELinux sandboxes with per-app SELinux restrictions on each
+application's private data directory.
 *   SHOULD retain the default SELinux policy provided in the system/sepolicy
 folder of the upstream Android Open Source Project and only further add to this
 policy for their own device-specific configuration.
@@ -74,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 8c5c22e..61a9b5f 100644
--- a/9_security-model/9_8_privacy.md
+++ b/9_security-model/9_8_privacy.md
@@ -11,9 +11,28 @@
 *   [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
 
+Device implementations:
+
+*   [C-0-1] MUST NOT preload or distribute software components out-of-box that
+    send the user's private information (e.g. keystrokes, text displayed on the
+    screen) off the device without the user's consent or clear ongoing
+    notifications.
+
 If device implementations include functionality in the system that captures
 the contents displayed on the screen and/or records the audio stream played
 on the device, they:
@@ -66,3 +85,12 @@
      https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setAlwaysOnVpnPackage%28android.content.ComponentName, java.lang.String, boolean%29)
      , in which case the user does not need to provide a separate consent, but
      MUST only be notified.
+
+If device implementations implement a user affordance to toggle on the
+"always-on VPN" function of a 3rd-party VPN app, they:
+
+*    [C-3-1] MUST disable this user affordance for apps that do not support
+     always-on VPN service in the `AndroidManifest.xml` file via setting the
+     [`SERVICE_META_DATA_SUPPORTS_ALWAYS_ON`](
+     https://developer.android.com/reference/android/net/VpnService.html#SERVICE_META_DATA_SUPPORTS_ALWAYS_ON)
+     attribute to `false`.
diff --git a/9_security-model/9_9_full-disk-encryption.md b/9_security-model/9_9_full-disk-encryption.md
index 3506679..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,13 +88,13 @@
 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 provide the user the possibility to AES encrypt the
-   encryption key, except when it is in active use, with the lock screen
+*   [C-1-3] MUST AES encrypt the encryption key by default unless the user
+   explicitly opts out, except when it is in active use, with the lock screen
    credentials stretched using a slow stretching algorithm
    (e.g. PBKDF2 or scrypt).
 *   [C-1-4] The above default password stretching algorithm MUST be