diff --git a/2_device-types/2_2_handheld-reqs.md b/2_device-types/2_2_handheld-reqs.md
index 1d257c0..00930b0 100644
--- a/2_device-types/2_2_handheld-reqs.md
+++ b/2_device-types/2_2_handheld-reqs.md
@@ -59,6 +59,27 @@
 
 Handheld device implementations:
 
+*   [[7.1](#7_1_display_and_graphics).4.6/H-0-1] MUST report whether the device
+    supports the GPU profiling capability via a system property
+    `graphics.gpu.profiler.support`.
+
+If Handheld device implementations declare support via a system property
+`graphics.gpu.profiler.support`, they:
+
+*    [[7.1](#7_1_display_and_graphics).4.6/H-1-1] MUST report as output a
+     protobuf trace that complies with the schema for GPU counters and GPU
+     renderstages defined in the [Perfetto documentation](https://developer.android.com/studio/command-line/perfetto).
+*    [[7.1](#7_1_display_and_graphics).4.6/H-1-2] MUST report conformant values
+     for the device’s GPU counters following the
+     [gpu counter trace packet proto](https://android.googlesource.com/platform/external/perfetto/+/refs/heads/master/protos/perfetto/trace/gpu/gpu_counter_event.proto).
+*    [[7.1](#7_1_display_and_graphics).4.6/H-1-3] MUST report conformant values
+     for the device’s GPU RenderStages following the
+     [render stage trace packet proto](https://android.googlesource.com/platform/external/perfetto/+/refs/heads/master/protos/perfetto/trace/gpu/gpu_render_stage_event.proto).
+*    [[7.1](#7_1_display_and_graphics).4.6/H-1-4] MUST report a GPU Frequency
+     tracepoint as specified by the format: [power/gpu_frequency](https://android.googlesource.com/platform/external/perfetto/+/refs/heads/master/protos/perfetto/trace/ftrace/power.proto).
+
+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
@@ -374,6 +395,58 @@
 terminal types and broadcast Intent ACTION_HEADSET_PLUG in less than
 1000 milliseconds.
 
+If Handheld device implementations include at least one haptic actuator, they:
+
+*   [[7.10](#7_10_haptics)/H-SR]* Are STRONGLY RECOMMENDED NOT to use an
+    eccentric rotating mass (ERM) haptic actuator(vibrator).
+*   [[7.10](#7_10_haptics)/H]* SHOULD position the placement of the actuator
+    near the location where the device is typically held or touched by hands.
+*   [[7.10](#7_10_haptics)/H-SR]* Are STRONGLY RECOMMENDED to implement all
+    public constants for [clear haptics](https://source.android.com/devices/haptics)
+    in [android.view.HapticFeedbackConstants](https://developer.android.com/reference/android/view/HapticFeedbackConstants#constants)
+    namely (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE,
+    KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY,
+    VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START and GESTURE_END).
+*   [[7.10](#7_10_haptics)/H-SR]* Are STRONGLY RECOMMENDED to implement all
+    public constants for [clear haptics](https://source.android.com/devices/haptics)
+    in [android.os.VibrationEffect](https://developer.android.com/reference/android/os/VibrationEffect)
+    namely (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK and
+    EFFECT_DOUBLE_CLICK) and all public constants for [rich haptics](https://source.android.com/devices/haptics)
+    in [android.os.VibrationEffect.Composition](https://developer.android.com/reference/android/os/VibrationEffect.Composition)
+    namely (PRIMITIVE_CLICK and PRIMITIVE_TICK).
+*   [[7.10](#7_10_haptics)/H-SR]* Are STRONGLY RECOMMENDED to use these linked
+    haptic constants [mappings](https://source.android.com/devices/haptics).
+*   [[7.10](#7_10_haptics)/H-SR]* Are STRONGLY RECOMMENDED to follow
+    [quality assessment](https://source.android.com/devices/haptics)
+    for [createOneShot()](https://developer.android.com/reference/android/os/VibrationEffect#createOneShot%28long,%20int%29)
+    and [createWaveform()](https://developer.android.com/reference/android/os/VibrationEffect#createOneShot%28long,%20int%29)
+    API's.
+*   [[7.10](#7_10_haptics)/H-SR]* Are STRONGLY RECOMMENDED to verify the
+    capabilities for amplitude scalability by running
+    [android.os.Vibrator.hasAmplitudeControl()](https://developer.android.com/reference/android/os/Vibrator#hasAmplitudeControl%28%29).
+
+Linear resonant actuator (LRA) is a single mass spring system which has a
+dominant resonant frequency where the mass translates in the direction of
+desired motion.
+
+If Handheld device implementations include at least one linear resonant
+actuator, they:
+
+*  [[7.10](#7_10_haptics)/H]* SHOULD move the haptic actuator in the X-axis of
+   portrait orientation.
+
+If Handheld device implementations have a haptic actuator which is X-axis
+Linear resonant actuator (LRA), they:
+
+*   [[7.10](#7_10_haptics)/H-SR]* Are STRONGLY RECOMMENDED to have the resonant
+    frequency of the X-axis LRA be under 200 Hz.
+
+If handheld device implementations follow haptic constants mapping, they:
+
+*   [[7.10](#7_10_haptics)/H-SR]* Are STRONGLY RECOMMENDED to perform a
+    [quality assessment](https://source.android.com/devices/haptics)
+    for haptic constants.
+
 ### 2.2.2\. Multimedia
 
 Handheld device implementations MUST support the following audio encoding and
@@ -404,7 +477,7 @@
 
 Handheld device implementations:
 
-*   [[3.2.3.1](#3_2_3_1_core_application_intents)/H-0-1] MUST have an
+*   [[3.2.3.1](#3_2_3_1_common_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`](
@@ -416,6 +489,15 @@
 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.2.3.1](#3_2_3_1_common_application_intents)/H-0-2]*  MUST preload one
+or more applications or service components with an intent handler, for
+all the public intent filter patterns defined by the following application
+intents listed [here](https://developer.android.com/about/versions/11/reference/common-intents-30).
+*   [[3.2.3.1](#3_2_3_1_common_application_intents)/H-SR] Are STRONGLY
+RECOMMENDED to preload an email application which can handle [ACTION_SENDTO](https://developer.android.com/reference/android/content/Intent#ACTION_SENDTO)
+or [ACTION_SEND](https://developer.android.com/reference/android/content/Intent#ACTION_SEND)
+or [ACTION_SEND_MULTIPLE](https://developer.android.com/reference/android/content/Intent#ACTION_SEND_MULTIPLE)
+intents to send an email.
 *   [[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
@@ -478,6 +560,16 @@
 https://developer.android.com/reference/android/service/voice/VoiceInteractionService)
 , or an activity handling the `ACTION_ASSIST` intent.
 
+If Handheld device implementations support [`conversation notifications`](https://developer.android.com/preview/features/conversations#api-notifications)
+and group them into a separate section from alerting and silent non-conversation
+notifications, they:
+
+*   [[3.8](#3_8_user_interface_compatibility).4/H-1-1]* MUST display
+    conversation notifications ahead of non conversation notifications with
+    the exception of ongoing foreground service notifications and
+    [importance:high](https://developer.android.com/reference/android/app/NotificationManager#IMPORTANCE_HIGH)
+    notifications.
+
 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
diff --git a/2_device-types/2_3_television-reqs.md b/2_device-types/2_3_television-reqs.md
index 97e4064..a0db0f8 100644
--- a/2_device-types/2_3_television-reqs.md
+++ b/2_device-types/2_3_television-reqs.md
@@ -213,6 +213,10 @@
 [`android.software.leanback`](
 http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK)
 and `android.hardware.type.television`.
+*   [[3.2.3.1](#3_2_3_1_common_application_intents)/T-0-1]  MUST preload one or
+more applications or service components with an intent handler, for all the
+public intent filter patterns defined by the following application intents
+listed [here](https://developer.android.com/about/versions/11/reference/common-intents-30).
 *   [[3.4](#3_4_web_compatibility).1/T-0-1] MUST provide a complete
 implementation of the `android.webkit.Webview` API.
 
diff --git a/2_device-types/2_4_watch-reqs.md b/2_device-types/2_4_watch-reqs.md
index 0f60070..0d67308 100644
--- a/2_device-types/2_4_watch-reqs.md
+++ b/2_device-types/2_4_watch-reqs.md
@@ -71,6 +71,10 @@
 *   [[3](#3_0_intro)/W-0-2] MUST support uiMode =
     [UI_MODE_TYPE_WATCH](
     http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH).
+*   [[3.2.3.1](#3_2_3_1_common_application_intents)/W-0-1]  MUST preload one
+or more applications or service components with an intent handler, for
+all the public intent filter patterns defined by the following application
+intents listed [here](https://developer.android.com/about/versions/11/reference/common-intents-30).
 
 Watch device implementations:
 
diff --git a/2_device-types/2_5_automotive-reqs.md b/2_device-types/2_5_automotive-reqs.md
index 889a822..86b5e7b 100644
--- a/2_device-types/2_5_automotive-reqs.md
+++ b/2_device-types/2_5_automotive-reqs.md
@@ -264,10 +264,28 @@
 [`android.car.*`](https://developer.android.com/reference/android/car/package-summary)
 namespace.
 
+If Automotive device implementations provide a proprietary API using
+[`android.car.CarPropertyManager`](https://developer.android.com/reference/android/car/hardware/property/CarPropertyManager) with
+[`android.car.VehiclePropertyIds`](https://developer.android.com/reference/android/car/VehiclePropertyIds),
+they:
+
+*   [[3](#3_0_intro)/A-1-1] MUST NOT attach special privileges to system
+    application's use of these properties, or prevent third-party applications
+    from using these properties.
+*   [[3](#3_0_intro)/A-1-2] MUST NOT replicate a vehicle property that already
+    exists in the [SDK](https://developer.android.com/reference/android/car/VehiclePropertyIds).
+
+Automotive device implementations:
+
 *   [[3.2](#3_2_soft_api_compatibility).1/A-0-1] MUST support and enforce all
 permissions constants as documented by the [Automotive Permission reference page](
 https://developer.android.com/reference/android/car/Car).
 
+*   [[3.2.3.1](#3_2_3_1_common_application_intents)/A-0-1]  MUST preload one or
+more applications or service components with an intent handler, for all the
+public intent filter patterns defined by the following application intents
+listed [here](https://developer.android.com/about/versions/11/reference/common-intents-30).
+
 *   [[3.4](#3_4_web_compatibility).1/A-0-1] MUST provide a complete
 implementation of the `android.webkit.Webview` API.
 
diff --git a/2_device-types/2_6_tablet-reqs.md b/2_device-types/2_6_tablet-reqs.md
index bbbb5f9..7babded 100644
--- a/2_device-types/2_6_tablet-reqs.md
+++ b/2_device-types/2_6_tablet-reqs.md
@@ -48,3 +48,10 @@
 **Keys and Credentials (Section 9.11)**
 
 Refer to Section [[9.11](#9_11_permissions)].
+
+### 2.6.2\. Software
+
+*   [[3.2.3.1](#3_2_3_1_common_application_intents)/Tab-0-1]  MUST preload one
+or more applications or service components with an intent handler, for all the
+public intent filter patterns defined by the following application intents
+listed [here](https://developer.android.com/about/versions/11/reference/common-intents-30).
\ No newline at end of file
diff --git a/3_software/3_10_accessibility.md b/3_software/3_10_accessibility.md
index 1f52271..1b934fb 100644
--- a/3_software/3_10_accessibility.md
+++ b/3_software/3_10_accessibility.md
@@ -16,9 +16,6 @@
     `AccessibilityEvent` to all registered [`AccessibilityService`](
     http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html)
     implementations as documented in the SDK.
-*   [C-1-3] MUST honor the `android.settings.ACCESSIBILITY_SETTINGS` intent to
-    provide a user-accessible mechanism to enable and disable the third-party
-    accessibility services alongside the preinstalled accessibility services.
 *   [C-1-4] MUST add a button in the system's navigation bar allowing the user
     to control the accessibility service when the enabled accessibility services
     declare the [`AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON`](
diff --git a/3_software/3_2_soft-api-compatibility.md b/3_software/3_2_soft-api-compatibility.md
index 38c0358..39a7937 100644
--- a/3_software/3_2_soft-api-compatibility.md
+++ b/3_software/3_2_soft-api-compatibility.md
@@ -243,35 +243,31 @@
 
 ### 3.2.3\. Intent Compatibility
 
-#### 3.2.3.1\. Core Application Intents
+#### 3.2.3.1\. Common Application Intents
 
 Android intents allow application components to request functionality from
 other Android components. The Android upstream project includes a list of
-applications considered core Android applications, which implements several
-intent patterns to perform common actions.
+applications which implement several intent patterns to perform common actions.
 
-*   [C-0-1] Device implementations MUST preload one or more applications or
+Device implementations:
+
+*   [C-SR] Are STRONGLY RECOMMENDED to 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:
+patterns defined by the following application intents listed [here](https://developer.android.com/about/versions/11/reference/common-intents-30)
+and provide fulfillment i.e meet with the developer expectation for these common
+application intents as described in the SDK.
 
-     *   Desk Clock
-     *   Browser
-     *   Calendar
-     *   Contacts
-     *   Gallery
-     *   GlobalSearch
-     *   Launcher
-     *   Music
-     *   Settings
+Please refer to [Section 2](#2_device_types) for mandatory application intents
+for each device type.
 
 #### 3.2.3.2\. Intent Resolution
 
 *   [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)
+allow each intent pattern referenced in [section 3.2.3.1](#3_2_3_1_common_application_intents)
 , 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
+*   [C-0-2] Device 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
 specifically includes but is not limited to disabling the “Chooser” user
@@ -327,7 +323,7 @@
 honor any new intent or broadcast intent patterns using an ACTION, CATEGORY, or
 other key string in a package space belonging to another organization.
 *   [C-0-3] Device implementers MUST NOT alter or extend any of the intent
-patterns used by the core apps listed in [section 3.2.3.1](#3_2_3_1_core_application_intents).
+patterns listed in [section 3.2.3.1](#3_2_3_1_common_application_intents).
 *   Device implementations MAY include intent patterns using namespaces clearly
 and obviously associated with their own organization. This prohibition is
 analogous to that specified for Java language classes in [section 3.6](#3_6_api_namespaces).
@@ -339,12 +335,15 @@
 
 Device implementations:
 
-*   [C-0-1] MUST broadcast the public broadcast intents in response to
-    appropriate system events as described in the SDK documentation. Note that
-    this requirement is not conflicting with section 3.5 as the limitation for
-    background applications are also described in the SDK documentation.
+*   [C-0-1] MUST broadcast the public broadcast intents listed [here](https://developer.android.com/about/versions/11/reference/broadcast-intents-30)
+in response to appropriate system events as described in the SDK documentation.
+Note that this requirement is not conflicting with section 3.5 as the
+limitation for background applications are also described in the SDK
+documentation. Also certain broadcast intents are conditional upon hardware
+support, if the device supports the necessary hardware they MUST broadcast the
+intents and provide the behavior inline with SDK documentation.
 
-#### 3.2.3.5\. Default App Settings
+#### 3.2.3.5\. Conditional Application Intents
 
 Android includes settings that provide users an easy way to select their
 default applications, for example for Home screen or SMS.
@@ -384,28 +383,168 @@
 use to place outgoing calls. The AOSP implementation meets this requirement by
 including a "Calling Accounts option" menu within the "Calls" settings menu.
 
-*   [C-2-4] MUST allow [`android.telecom.CallRedirectionService`](
-    https://developer.android.com/reference/android/telecom/CallRedirectionService) for an app
-    that holds the [`android.app.role.CALL_REDIRECTION`](
-    https://developer.android.com/reference/android/app/role/RoleManager#ROLE_CALL_REDIRECTION)
-    role.
-*   [C-2-5] MUST provide the user affordance to choose an app
-    that holds the [`android.app.role.CALL_REDIRECTION`](
-    https://developer.android.com/reference/android/app/role/RoleManager#ROLE_CALL_REDIRECTION)
-    role.
+*   [C-2-4] MUST allow [`android.telecom.CallRedirectionService`](https://developer.android.com/reference/android/telecom/CallRedirectionService)
+for an app that holds the [`android.app.role.CALL_REDIRECTION`](https://developer.android.com/reference/android/app/role/RoleManager#ROLE_CALL_REDIRECTION)
+role.
+*   [C-2-5] MUST provide the user affordance to choose an app that holds the
+[`android.app.role.CALL_REDIRECTION`](https://developer.android.com/reference/android/app/role/RoleManager#ROLE_CALL_REDIRECTION)
+role.
+*   [C-2-6] MUST honor the [android.intent.action.SENDTO](https://developer.android.com/reference/android/content/Intent#ACTION_SENDTO)
+and [android.intent.action.VIEW](https://developer.android.com/reference/android/content/Intent#ACTION_VIEW)
+intents and provide an activity to send/display SMS messages.
+*   [C-SR] Are Strongly Recommended to honor [android.intent.action.ANSWER](https://developer.android.com/reference/android/content/Intent#ACTION_ANSWER),
+[android.intent.action.CALL](https://developer.android.com/reference/android/content/Intent#ACTION_CALL),
+[android.intent.action.CALL_BUTTON](https://developer.android.com/reference/android/content/Intent#ACTION_CALL_BUTTON),
+[android.intent.action.VIEW](https://developer.android.com/reference/android/content/Intent#ACTION_VIEW)
+& [android.intent.action.DIAL](https://developer.android.com/reference/android/content/Intent#ACTION_DIAL)
+intents with a preloaded dialer application which can handle these intents and
+provide fulfillment as described in the SDK.
 
 If device implementations report `android.hardware.nfc.hce`, they:
 
 *   [C-3-1] MUST honor the [android.settings.NFC_PAYMENT_SETTINGS](
 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.
+*   [C-3-2] MUST honor [android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT](https://developer.android.com/reference/android/nfc/cardemulation/CardEmulation#ACTION_CHANGE_DEFAULT)
+intent to show an activity which opens a dialog to ask the user to change the
+default card emulation service for a certain category as described in the SDK.
+
+If device implementations report `android.hardware.nfc`, they:
+
+*   [C-4-1] MUST honor these intents [android.nfc.action.NDEF_DISCOVERED](https://developer.android.com/reference/android/nfc/NfcAdapter#ACTION_NDEF_DISCOVERED),
+[android.nfc.action.TAG_DISCOVERED](https://developer.android.com/reference/android/nfc/NfcAdapter#ACTION_TAG_DISCOVERED)
+& [android.nfc.action.TECH_DISCOVERED](https://developer.android.com/reference/android/nfc/NfcAdapter#ACTION_TECH_DISCOVERED),
+to show an activity which fulfils developer expectations for these intents as
+described in the SDK.
 
 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.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.
+*   [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.
+
+If device implementations report `android.hardware.bluetooth`, they:
+
+*   [C-5-1] MUST honor the [‘android.bluetooth.adapter.action.REQUEST_ENABLE’](https://developer.android.com/reference/kotlin/android/bluetooth/BluetoothAdapter#action_request_enable)
+intent and show a system activity to allow the user to turn on Bluetooth. 
+*   [C-5-2] MUST honor the
+[‘android.bluetooth.adapter.action.REQUEST_DISCOVERABLE’](https://developer.android.com/reference/android/bluetooth/BluetoothAdapter#ACTION_REQUEST_DISCOVERABLE)
+intent and show a system activity that requests discoverable mode.
+
+If device implementations support the DND feature, they:
+
+*   [C-6-1] MUST implement an activity that would respond to the intent
+[`ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS`](https://developer.android.com/reference/android/provider/Settings#ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS),
+which for implementations with UI_MODE_TYPE_NORMAL it MUST be an activity where
+the user can grant or deny the app access to DND policy configurations.
+
+If device implementations allow users to use third-party input methods on the
+device, they:
+
+*   [C-7-1] MUST provide a user-accessible mechanism to add and configure
+third-party input methods in response to the
+[`android.settings.INPUT_METHOD_SETTINGS`](https://developer.android.com/reference/android/provider/Settings#ACTION_INPUT_METHOD_SETTINGS)
+intent.
+
+If device implementations support third-party accessibility services, they:
+
+*   [C-8-1] MUST honor the [`android.settings.ACCESSIBILITY_SETTINGS`](https://developer.android.com/reference/android/provider/Settings#ACTION_ACCESSIBILITY_SETTINGS)
+intent to provide a user-accessible mechanism to enable and disable the
+third-party accessibility services alongside the preloaded accessibility
+services.
+
+If device implementations include support for Wi-Fi Easy Connect and expose the
+functionality to third-party apps, they:
+
+*   [C-9-1] MUST implement the [Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI](https://developer.android.com/reference/android/provider/Settings.html#ACTION_PROCESS_WIFI_EASY_CONNECT_URI)
+Intent APIs as described in the SDK documentation.
+
+If device implementations provide the data saver mode, they:
+*   [C-10-1] MUST provide a user interface in the settings, that handles the
+[`Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS`](https://developer.android.com/reference/android/provider/Settings.html#ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS)
+intent, allowing users to add applications to or remove applications from
+the allow list.
+
+If device implementations do not provide the data saver mode, they:
+
+*   [C-11-1] MUST have an activity that handles the
+[`Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS`](https://developer.android.com/reference/android/provider/Settings#ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS)
+intent but MAY implement it as a no-op.
+
+If device implementations declare the support for camera via
+`android.hardware.camera.any` they:
+
+*   [C-12-1] MUST honor the [`android.media.action.STILL_IMAGE_CAMERA`](https://developer.android.com/reference/android/provider/MediaStore#INTENT_ACTION_STILL_IMAGE_CAMERA)
+and [`android.media.action.STILL_IMAGE_CAMERA_SECURE`](https://developer.android.com/reference/android/provider/MediaStore#INTENT_ACTION_STILL_IMAGE_CAMERA_SECURE)
+intent and launch the camera in still image mode as described in the SDK.
+*   [C-12-2] MUST honor the [`android.media.action.VIDEO_CAMERA`](https://developer.android.com/reference/android/provider/MediaStore#INTENT_ACTION_VIDEO_CAMERA)
+intent to launch the camera in video mode as described in the SDK.
+*   [C-12-3] MUST honor only allow preinstalled Android applications to handle
+the following intents [`MediaStore.ACTION_IMAGE_CAPTURE`](https://developer.android.com/reference/android/provider/MediaStore.html#ACTION_IMAGE_CAPTURE),
+[`MediaStore.ACTION_IMAGE_CAPTURE_SECURE`](https://developer.android.com/reference/android/provider/MediaStore.html#ACTION_IMAGE_CAPTURE_SECURE),
+and [`MediaStore.ACTION_VIDEO_CAPTURE`](https://developer.android.com/reference/android/provider/MediaStore.html#ACTION_VIDEO_CAPTURE)
+as described in the [SDK document](https://developer.android.com/preview/behavior-changes-11?hl=zh-tw#media-capture).
+
+If device implementations report `android.software.device_admin`, they:
+
+*   [C-13-1] MUST honor the intent [`android.app.action.ADD_DEVICE_ADMIN`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager#ACTION_ADD_DEVICE_ADMIN)
+to invoke a UI to bring the user through adding the device administrator to
+the system (or allowing them to reject it).
+
+*   [C-13-2] MUST honor the  intents
+[android.app.action.ADMIN_POLICY_COMPLIANCE](https://developer.android.com/reference/android/app/admin/DevicePolicyManager#ACTION_ADMIN_POLICY_COMPLIANCE),
+[android.app.action.GET_PROVISIONING_MODE](https://developer.android.com/reference/android/app/admin/DevicePolicyManager#ACTION_GET_PROVISIONING_MODE),
+[android.app.action.PROVISIONING_SUCCESSFUL](https://developer.android.com/reference/android/app/admin/DevicePolicyManager#ACTION_PROVISIONING_SUCCESSFUL),
+[android.app.action.PROVISION_MANAGED_DEVICE](https://developer.android.com/reference/android/app/admin/DevicePolicyManager#ACTION_PROVISION_MANAGED_DEVICE),
+[android.app.action.PROVISION_MANAGED_PROFILE](https://developer.android.com/reference/android/app/admin/DevicePolicyManager#ACTION_PROVISION_MANAGED_PROFILE),
+[android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD](https://developer.android.com/reference/android/app/admin/DevicePolicyManager#ACTION_SET_NEW_PARENT_PROFILE_PASSWORD),
+[android.app.action.SET_NEW_PASSWORD](https://developer.android.com/reference/android/app/admin/DevicePolicyManager#ACTION_SET_NEW_PASSWORD)
+& [android.app.action.START_ENCRYPTION](https://developer.android.com/reference/android/app/admin/DevicePolicyManager#ACTION_START_ENCRYPTION)
+and have an activity to provide fulfillment for these intents as described
+in SDK [here](https://developer.android.com/reference/android/app/admin/DevicePolicyManager).
+
+If device implementations declare the [`android.software.autofill`](https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_AUTOFILL)
+feature flag, they:
+
+*   [C-14-1] MUST fully implement the [`AutofillService`](https://developer.android.com/reference/android/service/autofill/AutofillService.html)
+and [`AutofillManager`](https://developer.android.com/reference/android/view/autofill/AutofillManager.html)
+APIs and honor the [android.settings.REQUEST_SET_AUTOFILL_SERVICE](https://developer.android.com/reference/android/provider/Settings.html#ACTION_REQUEST_SET_AUTOFILL_SERVICE)
+intent to show a default app settings menu to enable and disable autofill and
+change the default autofill service for the user.
+
+If device implementations include a pre-installed app or wish to allow
+third-party apps to access the usage statistics, they:
+
+*   [C-SR] are STRONGLY RECOMMENDED provide user-accessible mechanism to grant
+or revoke access to the usage stats 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 for apps that declare the `android.permission.PACKAGE_USAGE_STATS`
+permission.
+
+If device implementations intend to disallow any apps, including pre-installed
+apps, from accessing the usage statistics, they:
+
+*   [C-15-1] MUST still have an activity that handles the
+[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.
+
+If device implementations report the feature `android.hardware.audio.output`,
+they:
+
+*   [C-SR] Are Strongly Recommended to honor android.intent.action.TTS_SERVICE,
+android.speech.tts.engine.INSTALL_TTS_DATA &
+android.speech.tts.engine.GET_SAMPLE_TEXT intents have an activity to provide
+fulfillment for these intents as described in SDK [here](https://developer.android.com/reference/android/speech/tts/TextToSpeech.Engine).
+
+Android includes support for interactive screensavers, previously referred to
+as Dreams. Screen Savers allow users to interact with applications when a device
+connected to a power source is idle or docked in a desk dock.
+Device Implementations:
+
+*   SHOULD include support for screen savers and provide a settings option for
+users to configure screen savers in response to the
+`android.settings.DREAM_SETTINGS` intent. 
 
 ### 3.2.4\. Activities on secondary/multiple displays
 
diff --git a/3_software/3_8_user-interface-compatibility.md b/3_software/3_8_user-interface-compatibility.md
index de304a6..7265e3b 100644
--- a/3_software/3_8_user-interface-compatibility.md
+++ b/3_software/3_8_user-interface-compatibility.md
@@ -157,6 +157,26 @@
 *   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.
 
+Android 11 introduces support for conversation notifications, which are
+notifications that use [MessagingStyle](https://developer.android.com/reference/android/app/Notification.MessagingStyle.html)
+and provides a published [People](https://developer.android.com/reference/android/app/Person) Shortcut ID.
+
+Device implementations:
+
+*   [C-SR] Are STRONGLY RECOMMENDED to group and display
+    [`conversation notifications`](https://developer.android.com/preview/features/conversations#api-notifications)
+    ahead of non conversation notifications with the exception of
+    ongoing foreground service notifications and [`importance:high`](https://developer.android.com/reference/android/app/NotificationManager#IMPORTANCE_HIGH)
+    notifications.
+
+If device implementations support [`conversation notifications`](https://developer.android.com/preview/features/conversations#api-notifications)
+and the app provides the required data for
+[`bubbles`](https://developer.android.com/guide/topics/ui/bubbles), they:
+
+*   [C-SR] Are STRONGLY RECOMMENDED to display this conversation as a bubble.
+    The AOSP implementation meets these requirements with the default System UI,
+    Settings, and Launcher.
+
 If device implementations support rich notifications, they:
 
 *   [C-2-1] MUST use the exact resources as
@@ -212,13 +232,7 @@
 
 If device implementations support the DND feature, they:
 
-*   [C-1-1] MUST implement an activity that would respond to the intent
-    [ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS](
-    https://developer.android.com/reference/android/provider/Settings.html#ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS),
-    which for implementations with UI_MODE_TYPE_NORMAL it MUST be an activity
-    where the user can grant or deny the app access to DND policy
-    configurations.
-*   [C-1-2] MUST, for when the device implementation has provided a means for the user
+*   [C-1-1] MUST, for when the device implementation has provided a means for the user
     to grant or deny third-party apps to access the DND policy configuration,
     display [Automatic DND rules](
     https://developer.android.com/reference/android/app/NotificationManager.html#addAutomaticZenRule%28android.app.AutomaticZenRule%29)
@@ -411,22 +425,6 @@
 
 *   [C-1-1] MUST declare the platform feature android.software.input_methods and
     support IME APIs as defined in the Android SDK documentation.
-*   [C-1-2] MUST provide a user-accessible mechanism to add and configure
-    third-party input methods in response to the
-    android.settings.INPUT_METHOD_SETTINGS intent.
-
-If device implementations declare the [`android.software.autofill`](
-https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_AUTOFILL)
-feature flag, they:
-
-*   [C-2-1] MUST fully implement the [`AutofillService`](
-https://developer.android.com/reference/android/service/autofill/AutofillService.html)
-and [`AutofillManager`](
-https://developer.android.com/reference/android/view/autofill/AutofillManager.html)
-APIs and honor the [`android.settings.REQUEST_SET_AUTOFILL_SERVICE`](
-https://developer.android.com/reference/android/provider/Settings.html#ACTION_REQUEST_SET_AUTOFILL_SERVICE)
-intent to show a default app settings menu to enable and disable autofill and
-change the default autofill service for the user.
 
 
 ### 3.8.10\. Lock Screen Media Control
@@ -439,13 +437,8 @@
 
 ### 3.8.11\. Screen savers (previously Dreams)
 
-Android includes support for [interactive screen savers](http://developer.android.com/reference/android/service/dreams/DreamService.html),
-previously referred to as Dreams. Screen savers allow users to interact with
-applications when a device connected to a power source is idle or docked in a
-desk dock.  Android Watch devices MAY implement screen savers, but other types
-of device implementations SHOULD include support for screen savers and provide
-a settings option for users to configure screen savers in response to the
-`android.settings.DREAM_SETTINGS` intent.
+See [section 3.2.3.5](#3_2_3_5_conditional_application_intents) for settings
+intent to congfigure screen savers.
 
 ### 3.8.12\. Location
 
diff --git a/7_hardware-compatibility/7_10_haptics.md b/7_hardware-compatibility/7_10_haptics.md
new file mode 100644
index 0000000..e5ba689
--- /dev/null
+++ b/7_hardware-compatibility/7_10_haptics.md
@@ -0,0 +1,3 @@
+## 7.10\. Haptics
+
+See Section [2.2.1](#2_2_1_hardware) for device-specific requirements.
diff --git a/7_hardware-compatibility/7_1_display-and-graphics.md b/7_hardware-compatibility/7_1_display-and-graphics.md
index 60df722..ad9e3c6 100644
--- a/7_hardware-compatibility/7_1_display-and-graphics.md
+++ b/7_hardware-compatibility/7_1_display-and-graphics.md
@@ -67,6 +67,29 @@
 *    SHOULD include user affordance to switch to the display mode with the
 rectangular corners.
 
+If device implementations include an Android-compatible display(s) that is
+foldable, or includes a folding hinge between multiple display panels and makes
+such display(s) available to render third-party apps, they:
+
+*    [C-2-1] MUST implement the latest available stable version of the
+[extensions API](
+https://developer.android.com/jetpack/androidx/releases/window-extensions)
+or the stable version of [sidecar API](
+https://android.googlesource.com/platform/frameworks/support/+/androidx-master-dev/window/window-sidecar/api/0.1.0-alpha01.txt)
+to be used by [Window Manager Jetpack](
+https://developer.android.com/jetpack/androidx/releases/window) library.
+
+If device implementations include an Android-compatible display(s) that is
+foldable, or includes a folding hinge between multiple display panels and if
+the hinge or fold crosses a fullscreen application window, they:
+
+*    [C-3-1] MUST report the position, bounds and state of hinge or fold through
+     extensions or sidecar APIs to the application.
+
+For details on correctly implementing the sidecar or extension APIs refer
+to the public documentation of [Window Manager Jetpack](
+https://developer.android.com/jetpack/androidx/releases/window).
+
 #### 7.1.1.2\. Screen Aspect Ratio
 
 While there is no restriction to the aspect ratio of the physical display for
diff --git a/7_hardware-compatibility/7_3_sensors.md b/7_hardware-compatibility/7_3_sensors.md
index 2b1afba..3c145c3 100644
--- a/7_hardware-compatibility/7_3_sensors.md
+++ b/7_hardware-compatibility/7_3_sensors.md
@@ -523,48 +523,81 @@
 
 *   SHOULD include a biometric sensor
 
-Biometric sensors can be classified as **Strong**, **Weak**, or **Convenience**
+Biometric sensors can be classified as **Class 3** (formerly **Strong**),
+**Class 2** (formerly **Weak**), or **Class 1** (formerly **Convenience**)
 based on their spoof and imposter acceptance rates, and on the security of the
 biometric pipeline. This classification determines the capabilities the
 biometric sensor has to interface with the platform and with third-party
-applications. Sensors are classified as **Convenience** by default, and need
+applications. Sensors are classified as **Class 1** by default, and need
 to meet additional requirements as detailed below if they wish to be classified
-as either **Weak** or **Strong**. Both **Weak** and **Strong** biometrics get
-additional capabilities as detailed below.
+as either **Class 2** or **Class 3**. Both **Class 2** and **Class 3**
+biometrics get additional capabilities as detailed below.
 
-
-To make a biometric sensor available to third-party applications, device
-implementations:
-
-*   [C-0-1] MUST meet the requirements for **Strong** or **Weak** biometric as
-    defined in this document.
-
-
-To allow access to keystore keys to third-party applications,
-device implementations:
-
-*   [C-0-2] MUST meet the requirements for **Strong** as defined in this
-    document.
-
-Additionally:
-
-*   [C-0-3] MUST be paired with an explicit confirm action (e.g. a button press)
-    if that **Strong** biometric is passive (e.g. face or iris where no
-    explicit signal of the user's intent exists).
-     *   [C-SR] The confirm action for passive biometrics is STRONGLY
-     RECOMMENDED to be secured such that an operating system or kernel
-     compromise cannot spoof it. For example, this means that the confirm action
-     based on a physical button is routed through an input-only general-purpose
-     input/output (GPIO) pin of a secure element (SE) that cannot be driven
-     by any other means than a physical button press.
-
-If device implementations wish to treat a biometric sensor as **Convenience**,
+If device implementations make a biometric sensor available to third-party
+applications via [android.hardware.biometrics.BiometricManager](https://developer.android.com/reference/android/hardware/biometrics/BiometricManager),
+[android.hardware.biometrics.BiometricPrompt](https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt),
+and [android.provider.Settings.ACTION_BIOMETRIC_ENROLL](https://developer.android.com/reference/android/provider/Settings#ACTION_BIOMETRIC_ENROLL),
 they:
 
+*   [C-4-1] MUST meet the requirements for **Class 3** or **Class 2** biometric
+    as defined in this document.
+*   [C-4-2] MUST recognize and honor each parameter name defined as a constant
+    in the [Authenticators](https://developer.android.com/reference/android/hardware/biometrics/BiometricManager.Authenticators)
+    class and any combinations thereof.
+    Conversely, MUST NOT honor or recognize integer constants passed to the
+    [canAuthenticate(int)](https://developer.android.com/reference/android/hardware/biometrics/BiometricManager#canAuthenticate%28int%29)
+    and [setAllowedAuthenticators(int)](https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt.Builder#setAllowedAuthenticators%28int%29)
+    methods other than those documented as public constants in
+    [Authenticators](https://developer.android.com/reference/android/hardware/biometrics/BiometricManager.Authenticators)
+    and any combinations thereof.
+*   [C-4-3] MUST implement the [ACTION_BIOMETRIC_ENROLL](https://developer.android.com/reference/android/provider/Settings#ACTION_BIOMETRIC_ENROLL)
+    action on devices that have either **Class 3** or **Class 2** biometrics.
+    This action MUST only present the enrollment entry points for **Class 3**
+    or **Class 2** biometrics.
+
+If device implementations support passive biometrics, they:
+
+*   [C-5-1] MUST by default require an additional confirmation step
+    (e.g. a button press).
+*   [C-SR] Are STRONGLY RECOMMENDED to have a setting to allow users to
+    override application preference and always require accompanying
+    confirmation step.
+*   [C-SR] Are STRONGLY RECOMMENDED to have the confirm action 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.
+*   [C-5-2] MUST additionally implement an implicit authentication flow
+    (without confirmation step) corresponding to
+    [setConfirmationRequired(boolean)](https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt.Builder#setConfirmationRequired%28boolean%29),
+    which applications can set to utilize for sign-in flows.
+
+If device implementations have multiple biometric sensors, they:
+
+*   [C-SR] Are STRONGLY RECOMMENDED to require only one biometric be confirmed
+    per authentication (e.g. if both fingerprint and face sensors are available
+    on the device, [onAuthenticationSucceeded](https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt.AuthenticationCallback.html#onAuthenticationSucceeded%28android.hardware.biometrics.BiometricPrompt.AuthenticationResult%29)
+    should be sent after any one of them is confirmed).
+
+In order for device implementations to allow access to keystore keys to
+third-party applications, they:
+
+*   [C-6-1] MUST meet the requirements for **Class 3** as defined in this
+    section below.
+*   [C-6-2] MUST present only **Class 3** biometrics when the authentication
+    requires [BIOMETRIC_STRONG](https://developer.android.com/reference/android/hardware/biometrics/BiometricManager.Authenticators#BIOMETRIC_STRONG),
+    or the authentication is invoked with a
+    [CryptoObject](https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt.CryptoObject).
+
+If device implementations wish to treat a biometric sensor as **Class 1**
+(formerly **Convenience**), they:
+
 *   [C-1-1] MUST have a false acceptance rate less than 0.002%.
 *   [C-1-2] MUST disclose that this mode may be less secure than a strong PIN,
     pattern, or password and clearly enumerate the risks of enabling it, if the
-    spoof and imposter acceptance rates are higher than 7%.
+    spoof and imposter acceptance rates are higher than 7% as measured by the
+    [Android Biometrics Test Protocols](https://source.android.com/security/biometric/measure).
 *   [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 ([`BIOMETRIC_ACQUIRED_GOOD`](
@@ -597,29 +630,33 @@
      *    3 failed biometric authentication attempts.
      *    The idle timeout period and the failed authentication count is reset
           after any successful confirmation of the device credentials.
+*   [C-SR] Are STRONGLY RECOMMENDED to use the logic in the framework provided
+    by the Android Open Source Project to enforce constraints specified in
+    [C-1-7] and [C-1-8] for new devices.
 *   [C-SR] Are STRONGLY RECOMMENDED to have a false rejection rate of less than
     10%, as measured on the device.
 *   [C-SR] Are STRONGLY RECOMMENDED to have a latency below 1 second, measured
     from when the biometric is detected, until the screen is unlocked, for each
     enrolled biometric.
 
-If device implementations wish to treat a biometric sensor as **Weak**, they:
+If device implementations wish to treat a biometric sensor as **Class 2**
+(formerly **Weak**), they:
 
-*   [C-2-1] MUST meet all requirements for **Convenience** above, except
-    for [C-1-2].
-*   [C-2-2] MUST have a spoof and imposter acceptance rate not higher than 20%.
-*   [C-2-3] MUST have a hardware-backed keystore implementation, and perform the
-    biometric matching in an isolated execution environment outside Android user
-    or kernel space, such as the Trusted Execution Environment (TEE), or on a
-    chip with a secure channel to the isolated execution environment.
+*   [C-2-1] MUST meet all requirements for **Class 1** above.
+*   [C-2-2] MUST have a spoof and imposter acceptance rate not higher than 20%
+    as measured by the [Android Biometrics Test Protocols](https://source.android.com/security/biometric/measure).
+*   [C-2-3] MUST perform the
+    biometric matching in an isolated execution environment outside Android
+    user or kernel space, such as the Trusted Execution Environment (TEE), or
+    on a chip with a secure channel to the isolated execution environment.
 *   [C-2-4] MUST have all identifiable data encrypted and cryptographically
     authenticated such that they cannot be acquired, read or altered outside of
     the isolated execution environment or a chip with a secure channel to the
     isolated execution environment as documented in the [implementation
     guidelines](https://source.android.com/security/biometric#hal-implementation)
     on the Android Open Source Project site.
-*   [C-2-5] For camera based biometrics, while biometric based authentication or
-    enrollment is happening:
+*   [C-2-5] For camera based biometrics, while biometric based authentication
+    or enrollment is happening:
     *    MUST operate the camera in a mode that prevents camera frames from
     being read or altered outside the isolated execution environment or a chip
     with a secure channel to the isolated execution environment.
@@ -635,16 +672,23 @@
     system or kernel compromise cannot allow data to be directly injected to
     falsely authenticate as the user.
 
-    If device implementations are already launched on an earlier Android version
-    and cannot meet the requirement C-2-8 through a system software update, they
-    MAY be exempted from the requirement.
+    If device implementations are already launched on an earlier Android
+    version and cannot meet the requirement C-2-8 through a system software
+    update, they MAY be exempted from the requirement.
 
-If device implementations wish to treat a biometric sensor as **Strong**, they:
+*   [C-SR] Are STRONGLY RECOMMENDED to include liveness detection for all
+    biometric modalities and attention detection for Face biometrics.
 
-*   [C-3-1] MUST meet all the requirements of **Weak** above. Upgrading
-    devices from an earlier Android version is not exempted from C-2-7.
-*   [C-3-2] MUST have a spoof and imposter acceptance rate not higher than 7%.
-*   [C-3-3] MUST challenge the user for the recommended primary
+If device implementations wish to treat a biometric sensor as **Class 3**
+(formerly **Strong**), they:
+
+*   [C-3-1] MUST meet all the requirements of **Class 2** above, except for
+    [C-1-7] and [C-1-8]. Upgrading devices from an earlier Android version
+    are not exempted from C-2-7.
+*   [C-3-2] MUST have a hardware-backed keystore implementation.
+*   [C-3-3] MUST have a spoof and imposter acceptance rate not higher than 7%
+    as measured by the [Android Biometrics Test Protocols](https://source.android.com/security/biometric/measure).
+*   [C-3-4] MUST challenge the user for the recommended primary
     authentication (e.g. PIN, pattern, password) once every 72 hours
     or less.
 
diff --git a/7_hardware-compatibility/7_4_data-connectivity.md b/7_hardware-compatibility/7_4_data-connectivity.md
index 94a80b8..f1aa803 100644
--- a/7_hardware-compatibility/7_4_data-connectivity.md
+++ b/7_hardware-compatibility/7_4_data-connectivity.md
@@ -312,10 +312,7 @@
 If device implementations include support for Wi-Fi Easy Connect and expose the
 functionality to third-party apps, they:
 
-*   [C-1-1] MUST implement the [`Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI`](
-    https://developer.android.com/reference/android/provider/Settings.html#ACTION_PROCESS_WIFI_EASY_CONNECT_URI)
-    Intent APIs as described in the SDK documentation.
-*   [C-1-2] MUST have the [WifiManager#isEasyConnectSupported\(\)](
+*   [C-1-1] MUST have the [WifiManager#isEasyConnectSupported\(\)](
     https://developer.android.com/reference/android/net/wifi/WifiManager.html#isEasyConnectSupported\(\))
     method return `true`.
 
@@ -467,8 +464,9 @@
 method. Note that this is not a standard Android feature and as such does not
 appear as a constant in the `android.content.pm.PackageManager` class.
 
-### 7.4.5\. Minimum Network Capability
+### 7.4.5\. Networking protocols and APIs
 
+#### 7.4.5.1\. Minimum Network Capability
 Device implementations:
 
 *   [C-0-1] MUST include support for one or more forms of
@@ -480,6 +478,11 @@
 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.
+
+#### 7.4.5.2\. IPv6
+
+Device implementations:
+
 *   [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`
@@ -499,7 +502,7 @@
 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.
+network and is visible as the source ip and port to internet (web) servers.
 
 
 The required level of IPv6 support depends on the network type, as shown in
@@ -511,19 +514,53 @@
 
 If device implementations support Ethernet, they:
 
-*   [C-2-1] MUST support dual-stack operation on Ethernet.
+*   [C-2-1] MUST support dual-stack and IPv6-only operation on
+    Ethernet.
 
 If device implementations support Cellular data, they:
 
-*   SHOULD support IPv6 operation (IPv6-only and possibly dual-stack) on
-cellular.
+*   [C-3-1] MUST support IPv6 operation (IPv6-only and possibly dual-stack) on
+    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.
+*   [C-4-1] MUST simultaneously meet the above requirements on each network
+    when the device is simultaneously connected to more than one network type.
 
+#### 7.4.5.3\. Captive Portals
+
+A captive portal refers to a network that requires sign-in in order to
+obtain internet access.
+
+
+If device implementations provide a complete implementation of the
+[`android.webkit.Webview API`](https://developer.android.com/reference/android/webkit/WebView.html),
+they:
+
+*   [C-1-1] MUST provide a captive portal application to handle the intent
+    [`ACTION_CAPTIVE_PORTAL_SIGN_IN`](https://developer.android.com/reference/android/net/ConnectivityManager#ACTION_CAPTIVE_PORTAL_SIGN_IN)
+    and display the captive portal login page, by sending that intent, on
+    call to the System API
+    `ConnectivityManager#startCaptivePortalApp(Network, Bundle)`.
+*   [C-1-2] MUST perform detection of captive portals and support login
+    through the captive portal application when the device is connected
+    to any network type, including cellular/mobile network, WiFi, Ethernet
+    or Bluetooth.
+*   [C-1-3] MUST support logging in to captive portals using cleartext DNS
+    when the device is configured to use private DNS strict mode.
+*   [C-1-4] MUST use encrypted DNS as per the SDK documentation for
+    [`android.net.LinkProperties.getPrivateDnsServerName`](https://developer.android.com/reference/android/net/LinkProperties.html#getPrivateDnsServerName%28%29)
+    and [`android.net.LinkProperties.isPrivateDnsActive`](https://developer.android.com/reference/android/net/LinkProperties#isPrivateDnsActive%28%29)
+    for all network traffic that is not explicitly communicating with the
+    captive portal.
+*   [C-1-5] MUST ensure that, while the user is logging in to a captive
+    portal, the default network used by applications (as returned by
+    [`ConnectivityManager.getActiveNetwork`](https://developer.android.com/reference/android/net/ConnectivityManager#getActiveNetwork%28%29),
+    [`ConnectivityManager.registerDefaultNetworkCallback`](https://developer.android.com/reference/android/net/ConnectivityManager#registerDefaultNetworkCallback%28android.net.ConnectivityManager.NetworkCallback%29),
+    and used by default by Java networking APIs such as java.net.Socket,
+    and native APIs such as connect()) is any other available network
+    that provides internet access, if available.
 
 ### 7.4.6\. Sync Settings
 
@@ -545,11 +582,6 @@
 *   [C-1-1] MUST support all the APIs in the `ConnectivityManager`
 class as described in the [SDK documentation](
 https://developer.android.com/training/basics/network-ops/data-saver.html)
-*   [C-1-2] MUST provide a user interface in the settings, that handles the
-    [`Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS`](
-    https://developer.android.com/reference/android/provider/Settings.html#ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS)
-    intent, allowing users to add applications to or remove applications
-    from the whitelist.
 
 If device implementations do not provide the data saver mode, they:
 
@@ -558,9 +590,6 @@
     https://developer.android.com/reference/android/net/ConnectivityManager.html#getRestrictBackgroundStatus%28%29)
 *   [C-2-2] MUST NOT broadcast
 `ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED`.
-*   [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
 
diff --git a/7_hardware-compatibility/7_5_cameras.md b/7_hardware-compatibility/7_5_cameras.md
index 7dc0f67..2f7bad0 100644
--- a/7_hardware-compatibility/7_5_cameras.md
+++ b/7_hardware-compatibility/7_5_cameras.md
@@ -15,12 +15,6 @@
 is responsible for removing the user location in the image metadata before
 sending it to the receiving application when the receiving application does not
 have [`ACCESS_FINE_LOCATION`](https://developer.android.com/reference/android/Manifest.permission.html#ACCESS_FINE_LOCATION).
-*   [C-1-4] MUST only allow preinstalled Android applications to handle the
-following intents [`MediaStore.ACTION_IMAGE_CAPTURE`](https://developer.android.com/reference/android/provider/MediaStore.html#ACTION_IMAGE_CAPTURE),
-[`MediaStore.ACTION_IMAGE_CAPTURE_SECURE`](https://developer.android.com/reference/android/provider/MediaStore.html#ACTION_IMAGE_CAPTURE_SECURE),
-and
-[`MediaStore.ACTION_VIDEO_CAPTURE`](https://developer.android.com/reference/android/provider/MediaStore.html#ACTION_VIDEO_CAPTURE)
-as described in the [SDK document](https://developer.android.com/preview/behavior-changes-11?hl=zh-tw#media-capture).
 
 ### 7.5.1\. Rear-Facing Camera
 
diff --git a/9_security-model/9_11_keys-and-credentials.md b/9_security-model/9_11_keys-and-credentials.md
index c4baaec..34cf539 100644
--- a/9_security-model/9_11_keys-and-credentials.md
+++ b/9_security-model/9_11_keys-and-credentials.md
@@ -77,13 +77,6 @@
 *    [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).
-*    [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).
 
 If device implementations add or modify the authentication methods to unlock
 the lock screen if based on a known secret and use a new authentication
@@ -115,7 +108,8 @@
 method:
 
 *    [C-4-1] MUST meet all requirements described in [section
-     7.3.10](#7_3_10_biometric_sensors) for **Convenience**.
+     7.3.10](#7_3_10_biometric_sensors) for **Class 1** (formerly
+     **Convenience**).
 *    [C-4-2] MUST have a fall-back mechanism to use one of the recommended
      primary authentication methods which is based on a known secret.
 *    [C-4-3] MUST be disabled and only allow the recommended primary
@@ -128,7 +122,8 @@
      `KEYGUARD_DISABLE_FACE`, or `KEYGUARD_DISABLE_IRIS`).
 
 If the biometric authentication methods do not meet the requirements
-for **Strong** as described in [section 7.3.10](#7_3_10_biometric_sensors):
+for **Class 3** (formerly **Strong**) as described in
+[section 7.3.10](#7_3_10_biometric_sensors):
 
 *    [C-5-1] The methods MUST be disabled if the Device Policy Controller (DPC)
      application has set the password quality policy via the [`DevicePolicyManager.setPasswordQuality()`](
@@ -136,9 +131,8 @@
      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.
+     authentication (eg: PIN, pattern, password) as described in [C-1-7] and
+     [C-1-8] in [section 7.3.10](#7_3_10_biometric_sensors).
 *    [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.
 
@@ -199,9 +193,8 @@
      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.
+     authentication (eg: PIN, pattern, password) methods as described in
+     [C-1-7] and [C-1-8] in [section 7.3.10](#7_3_10_biometric_sensors).
 *    [C-7-10] MUST NOT be treated as a secure lock screen and MUST follow the
      constraints listed in C-8 below.
 *    [C-7-11] MUST NOT allow TrustAgents on primary personal devices
diff --git a/9_security-model/9_1_permissions.md b/9_security-model/9_1_permissions.md
index 40ee9c1..b36e8ba 100644
--- a/9_security-model/9_1_permissions.md
+++ b/9_security-model/9_1_permissions.md
@@ -86,25 +86,6 @@
     permission (for example, [`READ_EXTERNAL_STORAGE`](
     https://developer.android.com/reference/android/Manifest.permission#READ_EXTERNAL_STORAGE)).
 
-If device implementations include a pre-installed app or wish to allow
-third-party apps to access the usage statistics, they:
-
-*   [SR] are STRONGLY RECOMMENDED provide user-accessible mechanism to grant
-    or revoke access to the usage stats 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 for apps that declare the `android.permission.PACKAGE_USAGE_STATS`
-    permission.
-
-If device implementations intend to disallow any apps, including pre-installed
-apps, from accessing the usage statistics, they:
-
-*   [C-1-1] MUST still have an activity that handles the
-    [`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.
-
 If device implementations provide a user affordance to choose which apps can
 draw on top of other apps with an activity that handles the
 [`ACTION_MANAGE_OVERLAY_PERMISSION`](https://developer.android.com/reference/android/provider/Settings.html#ACTION_MANAGE_OVERLAY_PERMISSION)
diff --git a/9_security-model/9_7_security-features.md b/9_security-model/9_7_security-features.md
index 6b5a175..49fa244 100644
--- a/9_security-model/9_7_security-features.md
+++ b/9_security-model/9_7_security-features.md
@@ -81,6 +81,10 @@
 `CONFIG_INIT_STACK_ALL_ZERO`).
 Also, device implementations SHOULD NOT assume the value used by the compiler to
 initialize the locals.
+*   [C-SR] Are STRONGLY RECOMMENDED to enable heap initialization in the kernel
+to prevent uses of uninitialized heap allocations
+(`CONFIG_INIT_ON_ALLOC_DEFAULT_ON`) and they SHOULD NOT assume the value used by
+the kernel to initialize those allocations.
 
 If device implementations use a Linux kernel, they:
 
diff --git a/9_security-model/9_8_privacy.md b/9_security-model/9_8_privacy.md
index 98627f5..7049c8e 100644
--- a/9_security-model/9_8_privacy.md
+++ b/9_security-model/9_8_privacy.md
@@ -260,4 +260,29 @@
 *   [C-SR] Are STRONGLY RECOMMENDED to have a developer setting defaulted to
     disabled. The AOSP meets this by providing the
     `Enable verbose vendor logging` option in developer settings to include
-    additional device-specific vendor logs in the bug reports.
\ No newline at end of file
+    additional device-specific vendor logs in the bug reports.
+
+### 9.8.11\. Data blobs sharing
+
+Android, through [BlobStoreManager](
+https://developer.android.com/reference/android/app/blob/BlobStoreManager)
+allows apps to contribute data blobs to the System to be shared with a selected
+set of apps.
+
+If device implementations support shared data blobs as described in the
+[SDK documentation](https://developer.android.com/reference/android/app/blob/BlobStoreManager),
+they:
+
+  * [C-1-1] MUST NOT share data blobs belonging to apps beyond what they
+    intended to allow (i.e. the scope of default access and the other access
+    modes that can be specified using
+    [BlobStoreManager.session#allowPackageAccess()](
+    https://developer.android.com/reference/android/app/blob/BlobStoreManager.Session#allowPackageAccess%28java.lang.String%2C%2520byte%5B%5D%29),
+    [BlobStoreManager.session#allowSameSignatureAccess()](
+    https://developer.android.com/reference/android/app/blob/BlobStoreManager.Session#allowSameSignatureAccess%28%29),
+    or [BlobStoreManager.session#allowPublicAccess()](
+    https://developer.android.com/reference/android/app/blob/BlobStoreManager.Session#allowPublicAccess%28%29)
+    MUST NOT be modified). The AOSP reference implementation meets these
+    requirements.
+  * [C-1-2] MUST NOT send off device or share with other apps the secure hashes
+    of data blobs (which are used to control access).
\ No newline at end of file
diff --git a/9_security-model/9_9_full-disk-encryption.md b/9_security-model/9_9_full-disk-encryption.md
index 119d781..cbf4de5 100644
--- a/9_security-model/9_9_full-disk-encryption.md
+++ b/9_security-model/9_9_full-disk-encryption.md
@@ -32,9 +32,10 @@
 the user has completed the out-of-box setup experience.
 *   [C-0-3] MUST meet the above data storage encryption
 requirement via implementing [File Based Encryption](
-https://source.android.com/security/encryption/file-based.html) (FBE).
+https://source.android.com/security/encryption/file-based.html) (FBE) and
+[Metadata Encryption](https://source.android.com/security/encryption/metadata).
 
-### 9.9.3\. File Based Encryption
+### 9.9.3\. Encryption Methods
 
 If device implementations are encrypted, they:
 
@@ -49,20 +50,19 @@
 without either the user-supplied credentials, a registered escrow key or a
 resume on reboot implementation meeting the requirements in
 [section 9.9.4](#9_9_4_resume_on_reboot).
-*    [C-1-4] MUST use Verified Boot and ensure that DE keys are
-cryptographically bound to the device's hardware root of trust.
-*    [C-1-5] MUST encrypt file contents using AES-256-XTS or
-Adiantum.  AES-256-XTS refers to the Advanced Encryption Standard with a
-256-bit cipher key length, operated in XTS mode; the full length of the key
-is 512 bits.  Adiantum refers to Adiantum-XChaCha12-AES, as specified at
-https://github.com/google/adiantum.
+*    [C-1-4] MUST use Verified Boot.
+*    [C-1-5] MUST encrypt file contents and filesystem metadata using
+AES-256-XTS or Adiantum.  AES-256-XTS refers to the Advanced Encryption Standard
+with a 256-bit cipher key length, operated in XTS mode; the full length of the
+key is 512 bits.  Adiantum refers to Adiantum-XChaCha12-AES, as specified at
+https://github.com/google/adiantum. Filesystem metadata is data such as file
+sizes, ownership, modes, and extended attributes (xattrs).
 *    [C-1-6] MUST encrypt file names using AES-256-CBC-CTS
 or Adiantum.
-*    [C-1-12] MUST use AES-256-XTS for file contents and AES-256-CBC-CTS for
-file names (instead of Adiantum) if the device has Advanced Encryption Standard
-(AES) instructions.  AES instructions are ARMv8 Cryptography Extensions on
-ARM-based devices, or AES-NI on x86-based devices.  If the device does not
-have AES instructions, the device MAY use Adiantum.
+*    [C-1-12] If the device has Advanced Encryption Standard (AES)
+instructions (such as ARMv8 Cryptography Extensions on ARM-based devices, or
+AES-NI on x86-based devices) then the AES-based options above for file name,
+file contents, and filesystem metadata encryption MUST be used, not Adiantum.
 *    [C-1-13] MUST use a cryptographically strong and non-reversible key
 derivation function (e.g. HKDF-SHA512) to derive any needed subkeys (e.g.
 per-file keys) from the CE and DE keys.  "Cryptographically strong and
@@ -74,9 +74,11 @@
 for different cryptographic purposes (e.g. for both encryption and key
 derivation, or for two different encryption algorithms).
 
-*   The keys protecting CE and DE storage areas:
+*   The keys protecting CE and DE storage areas and filesystem metadata:
 
    *   [C-1-7] MUST be cryptographically bound to a hardware-backed Keystore.
+   This keystore MUST be bound to Verified Boot and the device's hardware
+   root of trust.
    *   [C-1-8] CE keys MUST be bound to a user's lock screen credentials.
    *   [C-1-9] CE keys MUST be bound to a default passcode when the user has
 not specified lock screen credentials.
@@ -84,15 +86,13 @@
    key matches any other user's CE or DE keys.
    *    [C-1-11] MUST use the mandatorily supported ciphers, key lengths and
    modes.
-*    [C-SR] Are STRONGLY RECOMMENDED to encrypt file system metadata, such as
-file sizes, ownership, modes, and Extended attributes (xattrs), with a key
-cryptographically bound to the device's hardware root of trust.
 
 *    SHOULD make preinstalled essential apps (e.g. Alarm, Phone, Messenger)
 Direct Boot aware.
 
 The upstream Android Open Source project provides a preferred implementation of
-this feature based on the Linux kernel "fscrypt" encryption feature.
+File Based Encryption based on the Linux kernel "fscrypt" encryption feature,
+and of Metadata Encryption based on the Linux kernel "dm-default-key" feature.
 
 ### 9.9.4\. Resume on Reboot
 
@@ -126,4 +126,4 @@
 
 By way of example, a device implementation that implements and complies with all
 of the descriptions found [here](https://source.android.com/devices/tech/ota/resume-on-reboot)
-will be compliant with [C-0-1].
\ No newline at end of file
+will be compliant with [C-0-1].