Merge "CDD: Clarify Device Owner consent requirements" into rvc-dev
diff --git a/2_device-types/2_2_handheld-reqs.md b/2_device-types/2_2_handheld-reqs.md
index 971300a..07a17f5 100644
--- a/2_device-types/2_2_handheld-reqs.md
+++ b/2_device-types/2_2_handheld-reqs.md
@@ -659,3 +659,5 @@
     *   [[6.1](#6_1_developer_tools)/H-0-5]\* MUST provide, through the perfetto
         binary, at least the data sources described  in [the perfetto documentation](
         https://developer.android.com/studio/command-line/perfetto).
+    *   [[6.1](#6_1_developer_tools)/H-0-6]\* The perfetto traced daemon MUST be
+        enabled by default (system property `persist.traced.enable`).
diff --git a/2_device-types/2_4_watch-reqs.md b/2_device-types/2_4_watch-reqs.md
index 64c35a6..0f60070 100644
--- a/2_device-types/2_4_watch-reqs.md
+++ b/2_device-types/2_4_watch-reqs.md
@@ -56,7 +56,7 @@
 
 *   [[7.8](#7_8_audio).1/W-0-1] MUST include a microphone.
 
-*   [[7.8](#7_8_audio).2/W] MAY but SHOULD NOT have audio output.
+*   [[7.8](#7_8_audio).2/W] MAY have audio output.
 
 ### 2.4.2\. Multimedia
 
diff --git a/2_device-types/2_5_automotive-reqs.md b/2_device-types/2_5_automotive-reqs.md
index 84077a4..a0a11f2 100644
--- a/2_device-types/2_5_automotive-reqs.md
+++ b/2_device-types/2_5_automotive-reqs.md
@@ -331,18 +331,13 @@
 Automotive device implementations:
 
 *    [[3.8](#3_8_user-interface-compatibility)/A] MAY restrict the application
-     requests to limit the ability to enter a full screen mode as described in
-     [`immersive documentation`](
+     requests to enter a full screen mode as described in [`immersive documentation`](
      https://developer.android.com/training/system-ui/immersive).
 *   [[3.8](#3_8_user-interface-compatibility)/A] MAY keep the status bar and
     the navigation bar visible at all times.
 *   [[3.8](#3_8_user-interface-compatibility)/A] MAY restrict the application
-    requests to limit the ability to change the colors behind the system UI
-    elements, to ensure those elements are clearly visible at all times,
-    as described in the [`WindowManager.LayoutParams#FLAG_TRANSLUCENT_STATUS`](
-    https://developer.android.com/reference/android/view/WindowManager.LayoutParams#FLAG_TRANSLUCENT_STATUS)
-    and [`WindowManager.LayoutParams#FLAG_TRANSLUCENT_NAVIGATION`](
-    https://developer.android.com/reference/android/view/WindowManager.LayoutParams#FLAG_TRANSLUCENT_NAVIGATION).
+    requests to change the colors behind the system UI elements, to ensure
+    those elements are clearly visible at all times.
 
 ### 2.5.4\. Performance and Power
 
@@ -353,10 +348,10 @@
 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.3](#8_3_power_saving_modes)/A-1-3] MUST enter [Garage Mode](https://source.android.com/devices/automotive/garage_mode)
-at least once before the car is powered down.
-*   [[8.3](#8_3_power_saving_modes)/A-1-4] MUST be in [Garage Mode](https://source.android.com/devices/automotive/garage_mode)
-for at least 15 minutes unless:
+*   [[8.3](#8_3_power_saving_modes)/A-1-3] MUST support [Garage Mode](
+    https://source.android.com/devices/automotive/garage_mode).
+*   [[8.3](#8_3_power_saving_modes)/A] SHOULD be in Garage Mode for at least
+    15 minutes after every drive unless:
     *    The battery is drained.
     *    No idle jobs are scheduled.
     *    The driver exits Garage Mode.
diff --git a/3_software/3_5_api-behavioral-compatibility.md b/3_software/3_5_api-behavioral-compatibility.md
index 70004ed..fac707e 100644
--- a/3_software/3_5_api-behavioral-compatibility.md
+++ b/3_software/3_5_api-behavioral-compatibility.md
@@ -77,10 +77,11 @@
 SHOULD use the source code available via the Android Open Source Project where
 possible, rather than re-implement significant parts of the system.
 
-## 3.5.1\. Background Restriction
+## 3.5.1\. Application Restriction
 
-If device implementations implement the app restrictions that are included in
-AOSP or extend the app restrictions, they:
+If device implementations implement a proprietary mechanism to restrict apps and
+that mechanism is more restrictive than [the Rare App Standby Bucket](
+https://developer.android.com/topic/performance/power/power-details), they:
 
 *    [C-1-1] MUST provide user affordance where the user can see the list of
 restricted apps.
@@ -97,7 +98,8 @@
 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.
+automatically. Such information MUST be provided within 24 hours of when
+the restrictions are applied.
 *    [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.
diff --git a/3_software/3_8_user-interface-compatibility.md b/3_software/3_8_user-interface-compatibility.md
index fafb1b8..f8f1e68 100644
--- a/3_software/3_8_user-interface-compatibility.md
+++ b/3_software/3_8_user-interface-compatibility.md
@@ -314,6 +314,9 @@
     the [Material theme attributes](
     http://developer.android.com/reference/android/R.style.html#Theme_Material)
     or their assets exposed to applications.
+*   [C-1-3] MUST use the [Roboto version 2.x](https://github.com/google/roboto)
+    fonts as the out-of-box Sans-serif font family for languages that Roboto
+    supports.
 
 Android also includes a “Device Default” theme family as a set of defined styles
 for application developers to use if they want to match the look and feel of the
@@ -584,14 +587,12 @@
 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.
+an area on the edge of the display that may not be functional for an application
+due to a display cutout or curved display on the edge(s).
 
 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-5] MUST NOT have cutout(s) if the device's aspect ratio is 1.0(1:1).
 *   [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`](
diff --git a/4_application-packaging/4_0_intro.md b/4_application-packaging/4_0_intro.md
index 27ae4f2..9e0b08f 100644
--- a/4_application-packaging/4_0_intro.md
+++ b/4_application-packaging/4_0_intro.md
@@ -63,3 +63,13 @@
 harmful.
 *    SHOULD provide a user affordance to choose to uninstall or launch an
 application on the warning dialog.
+
+*    [C-0-8] MUST implement support for Incremental File System as documented
+     [here](https://source.android.com/devices/architecture/kernel/incfs).
+
+*    [C-0-9] MUST support verifying .apk files using the
+     [APK Signature Scheme v4](https://source.android.com/security/apksigning/v4.html).
+
+*    If device implementations are already launched on an earlier Android
+     version and cannot meet the requirements [C-0-8] and [C-0-9] through a
+     system software update, they MAY be exempted from these requirements.
diff --git a/5_multimedia/5_9_midi.md b/5_multimedia/5_9_midi.md
index ec13b0a..9a950a8 100644
--- a/5_multimedia/5_9_midi.md
+++ b/5_multimedia/5_9_midi.md
@@ -9,10 +9,12 @@
 which they provide generic non-MIDI connectivity, where such 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)
 
 *    [C-1-2] MUST support the inter-app MIDI software transport
 (virtual MIDI devices)
 
 *    [C-1-3] MUST include libamidi.so (native MIDI support)
+
+*    SHOULD support MIDI over USB peripheral mode, [section 7.7](#7_7_USB)
+
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 802b984..9548790 100644
--- a/6_dev-tools-and-options/6_1_developer_tools.md
+++ b/6_dev-tools-and-options/6_1_developer_tools.md
@@ -48,12 +48,26 @@
     *   [C-0-5] MUST support secure adb. Android includes support for secure
     adb. Secure adb enables adb on known authenticated hosts.
     *   [C-0-6] MUST provide a mechanism allowing adb to be connected from a
-    host machine. For example:
+    host machine. Specifically:
 
-        *   Device implementations without a USB port supporting peripheral mode
-        MUST implement adb via local-area network (such as Ethernet or Wi-Fi).
-        *   MUST provide drivers for Windows 7, 9 and 10, allowing developers to
-        connect to the device using the adb protocol.
+    If device implementations without a USB port support peripheral mode, they:
+
+    *   [C-3-1] MUST implement adb via local-area network (such as Ethernet
+    or Wi-Fi).
+    *   [C-3-2] MUST provide drivers for Windows 7, 8 and 10, allowing
+    developers to connect to the device using the adb protocol.
+
+    If device implementations support adb connections to a host machine via
+    Wi-Fi, they:
+
+    *   [C-4-1] MUST have the `AdbManager#isAdbWifiSupported()` method
+    return `true`.
+
+    If device implementations support adb connections to a host machine via
+    Wi-Fi and includes at least one camera, they:
+
+    *   [C-5-1] MUST have the `AdbManager#isAdbWifiQrSupported()` method
+     return `true`.
 
 *    [**Dalvik Debug Monitor Service (ddms)**](http://developer.android.com/tools/debugging/ddms.html)
     *   [C-0-7] MUST support all ddms features as documented in the Android SDK.
diff --git a/7_hardware-compatibility/7_1_display-and-graphics.md b/7_hardware-compatibility/7_1_display-and-graphics.md
index c470f95..60df722 100644
--- a/7_hardware-compatibility/7_1_display-and-graphics.md
+++ b/7_hardware-compatibility/7_1_display-and-graphics.md
@@ -55,11 +55,15 @@
 
 *    MAY have the Android-compatible display(s) with rounded corners.
 
-If device implementations support `UI_MODE_TYPE_NORMAL` and include the
+If device implementations support `UI_MODE_TYPE_NORMAL` and include
 Android-compatible display(s) with rounded corners, they:
 
-*    [C-1-1] MUST ensure that the radius of the rounded corners is less than or
-equal to 38 dp.
+*    [C-1-1] MUST ensure that at least one of the following requirements
+ is met:
+  *  The radius of the rounded corners is less than or equal to 38 dp.
+  *  When a 15 dp by 15 dp box is anchored at each corner of the logical
+     display, at least one pixel of each box is visible on the screen.
+
 *    SHOULD include user affordance to switch to the display mode with the
 rectangular corners.
 
@@ -279,7 +283,13 @@
 
 *    SHOULD include support for Vulkan 1.1.
 
-If device implementations include support for Vulkan 1.0, they:
+The Vulkan dEQP tests are partitioned into a number of test lists, each with an
+associated date/version.  These are in the Android source tree at
+`external/deqp/android/cts/master/vk-master-YYYY-MM-DD.txt`.  A device that
+supports Vulkan at a self-reported level indicates that it can pass the dEQP
+tests in all test lists from this level and earlier.
+
+If device implementations include support for Vulkan 1.0 or higher, they:
 
 *   [C-1-1] MUST report the correct integer value with the
     `android.hardware.vulkan.level` and `android.hardware.vulkan.version`
@@ -306,6 +316,13 @@
     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.
+*   [C-1-8] MUST report the maximum version of the Vulkan dEQP Tests
+    supported via the `android.software.vulkan.deqp.level` feature flag.
+*   [C-1-9] MUST at least support version `132317953` (from Mar 1st, 2019) as
+    reported in the `android.software.vulkan.deqp.level` feature flag.
+*   [C-1-10] MUST pass all Vulkan dEQP Tests in the test lists between
+    version `132317953` and the version specified in the
+    `android.software.vulkan.deqp.level` feature flag.
 *   [C-SR] Are STRONGLY RECOMMENDED to support the VK_KHR_driver_properties and
     VK_GOOGLE_display_timing extensions.
 
diff --git a/7_hardware-compatibility/7_4_data-connectivity.md b/7_hardware-compatibility/7_4_data-connectivity.md
index af33139..94a80b8 100644
--- a/7_hardware-compatibility/7_4_data-connectivity.md
+++ b/7_hardware-compatibility/7_4_data-connectivity.md
@@ -363,17 +363,16 @@
 *   [C-3-4] MUST report the correct value for
 `BluetoothAdapter.isMultipleAdvertisementSupported()` to indicate
 whether Low Energy Advertising is supported.
+*   [C-3-5] MUST implement a Resolvable Private Address (RPA) timeout no longer
+    than 15 minutes and rotate the address at timeout to protect user privacy.
+    To prevent timing attacks, timeout intervals MUST also be randomized
+    between 5 and 15 minutes.
 *   SHOULD support offloading of the filtering logic to the bluetooth chipset
 when implementing the [ScanFilter API](
 https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html).
 *   SHOULD support offloading of the batched scanning to the bluetooth chipset.
 *   SHOULD support multi advertisement with at least 4 slots.
 
-
-*   [SR] STRONGLY RECOMMENDED to implement a Resolvable Private Address (RPA)
-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:
 
@@ -565,9 +564,19 @@
 
 ### 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:
+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 third-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.
+*   [C-1-1] MUST enumerate the available secure elements readers via
+    [`android.se.omapi.SEService.getReaders()`](https://developer.android.com/reference/android/se/omapi/SEService#getReaders%28%29) API.
+
+*   [C-1-2] MUST declare the correct feature flags via
+    [`android.hardware.se.omapi.uicc`](
+    https://developer.android.com/reference/android/content/pm/PackageManager#FEATURE_SE_OMAPI_UICC)
+    for the device with UICC-based secure elements,
+    [`android.hardware.se.omapi.ese`](
+    https://developer.android.com/reference/android/content/pm/PackageManager#FEATURE_SE_OMAPI_ESE)
+    for the device with eSE-based secure elements and
+    [`android.hardware.se.omapi.sd`](
+    https://developer.android.com/reference/android/content/pm/PackageManager#FEATURE_SE_OMAPI_SD)
+    for the device with SD-based secure elements.
\ 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 3b1339f..2f7bad0 100644
--- a/7_hardware-compatibility/7_5_cameras.md
+++ b/7_hardware-compatibility/7_5_cameras.md
@@ -207,6 +207,11 @@
 [`android.hardware.Camera`](https://developer.android.com/reference/android/hardware/Camera)
 API also accessible via the [`android.hardware.camera2`](https://developer.android.com/reference/android/hardware/camera2/package-summary)
 API.
+*   [C-0-12] MUST ensure that the facial appearance is NOT altered, including
+    but not limited to altering facial geometry, facial skin tone, or facial
+    skin smoothening for any [`android.hardware.camera2`](https://developer.android.com/reference/android/hardware/camera2/package-summary)
+    or [`android.hardware.Camera`](https://developer.android.com/reference/android/hardware/Camera)
+    API.
 *   [C-SR] For devices with multiple RGB cameras facing in the same direction,
 are STRONGLY RECOMMENDED to support a logical camera device that lists
 capability
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 488d301..84eced9 100644
--- a/8_performance-and-power/8_3_power-saving-modes.md
+++ b/8_performance-and-power/8_3_power-saving-modes.md
@@ -1,8 +1,9 @@
 ## 8.3\. Power-Saving Modes
 
 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:
+that are included in AOSP (e.g. App Standby Bucket, Doze) or extend the features
+that do not apply harder restrictions than [the Rare App Standby Bucket](
+https://developer.android.com/topic/performance/power/power-details), they:
 
 *   [C-1-1] MUST NOT deviate from the AOSP implementation for the triggering,
     maintenance, wakeup algorithms and the use of global system settings of App
@@ -26,6 +27,12 @@
 *   [C-SR] Are STRONGLY RECOMMENDED to provide user affordance to display all
     Apps that are exempted from App Standby and Doze power-saving modes.
 
+If device implementations extend power management features that are included
+in AOSP and that extension applies more stringent restrictions than
+[the Rare App Standby Bucket](
+https://developer.android.com/topic/performance/power/power-details), refer to
+[section 3.5.1](#3_5_api-behavioral-compatibility).
+
 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).
diff --git a/9_security-model/9_11_keys-and-credentials.md b/9_security-model/9_11_keys-and-credentials.md
index fe42b8f..496f463 100644
--- a/9_security-model/9_11_keys-and-credentials.md
+++ b/9_security-model/9_11_keys-and-credentials.md
@@ -301,3 +301,40 @@
 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.
+
+### 9.11.3\. Identity Credential
+
+The Identity Credential System is defined and achieved by implementing all
+APIs in the
+[`android.security.identity.*`](https://developer.android.com/reference/android/security/identity/package-summary)
+package. These APIs allows app developers to store and retrieve user identity
+documents. Device implementations:
+
+*    [C-SR] are STRONGLY RECOMMENDED to implement the Identity Credential
+System.
+
+If device implementations implement the Identity Credential System, they:
+
+*    [C-0-1] MUST return non-null for the [IdentityCredentialStore#getInstance()](
+     https://developer.android.com/reference/android/security/identity/IdentityCredentialStore#getInstance%28android.content.Context%29)
+     method.
+
+*    [C-0-2] MUST implement the Identity Credential System (e.g. the
+     `android.security.identity.*` APIs) with code communicating with a trusted
+     application in an area that is securely isolated from the code running on
+     the kernel and above. Secure isolation MUST block all potential mechanisms
+     by which kernel or userspace code might access the internal state of the
+     isolated environment, including DMA.
+
+*    [C-0-3] The cryptographic operations needed to implement the Identity
+     Credential System (e.g. the `android.security.identity.*` APIs) MUST be
+     performed entirely in the trusted application and private key material MUST
+     never leave the isolated execution environment unless specifically required
+     by higher-level APIs (e.g. the
+     [createEphemeralKeyPair()](https://developer.android.com/reference/android/security/identity/IdentityCredential#createEphemeralKeyPair%28%29)
+     method).
+
+*    [C-0-4] The trusted application MUST be implemented in a way such that its
+     security properties  are not affected (e.g. credential data is not released unless access
+     control conditions are satisfied, MACs can't be produced for arbitrary
+     data) even if Android is misbehaving or compromised.
diff --git a/9_security-model/9_7_security-features.md b/9_security-model/9_7_security-features.md
index 83b03ed..6b5a175 100644
--- a/9_security-model/9_7_security-features.md
+++ b/9_security-model/9_7_security-features.md
@@ -76,6 +76,11 @@
 additional security-sensitive userspace components as explained in
 [CFI](https://source.android.com/devices/tech/debug/cfi) and
 [IntSan](https://source.android.com/devices/tech/debug/intsan).
+*   [C-SR] Are STRONGLY RECOMMENDED to enable stack initialization in the kernel
+to prevent uses of uninitialized local variables (`CONFIG_INIT_STACK_ALL` or
+`CONFIG_INIT_STACK_ALL_ZERO`).
+Also, device implementations SHOULD NOT assume the value used by the compiler to
+initialize the locals.
 
 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 425290f..caa7f00 100644
--- a/9_security-model/9_8_privacy.md
+++ b/9_security-model/9_8_privacy.md
@@ -202,9 +202,26 @@
 of Wi-Fi/Bluetooth scanning for determining location.
 *   [C-0-3] MUST ensure that the application using Emergency Location Bypass API
 [LocationRequest.setLocationSettingsIgnored()] is a user initiated emergency
-session (e.g. dial 911 or text to 911).
+session (e.g. dial 911 or text to 911). For Automotive however, a vehicle MAY
+initiate an emergency session without active user interaction in the case
+a crash/accident is detected (e.g. to satisfy eCall requirements).
 *   [C-0-4] MUST preserve the Emergency Location Bypass API's ability to
 bypass device location settings without changing the settings.
 *   [C-0-5] MUST schedule a notification that reminds the user after an app in
 the background has accessed their location using the
 [`ACCESS_BACKGROUND_LOCATION`] permission.
+
+### 9.8.9\. Installed apps
+
+Android apps targeting API level 30 or above cannot see details about other
+installed apps by default (see [Package visibility](
+https://developer.android.com/preview/privacy/package-visibility) in the Android
+SDK documentation).
+
+Device implementations:
+
+*   [C-0-1] MUST NOT expose to any app targeting API level 30 or above details
+    about any other installed app, unless the app is already able to see details
+    about the other installed app through the managed APIs. This includes but is
+    not limited to details exposed by any custom APIs added by the device
+    implementer, or accessible via the filesystem.
diff --git a/9_security-model/9_9_full-disk-encryption.md b/9_security-model/9_9_full-disk-encryption.md
index 55d6f19..365cf37 100644
--- a/9_security-model/9_9_full-disk-encryption.md
+++ b/9_security-model/9_9_full-disk-encryption.md
@@ -36,7 +36,7 @@
 
 ### 9.9.3\. File Based Encryption
 
-Encrypted devices:
+If device implementations are encrypted, they:
 
 *    [C-1-1] MUST boot up without challenging the user for credentials and
 allow Direct Boot aware apps to access to the Device Encrypted (DE) storage
@@ -61,6 +61,16 @@
 (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-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
+non-reversible" means that the key derivation function has a security strength
+of at least 256 bits and behaves as a [pseudorandom function
+family](https://en.wikipedia.org/w/index.php?title=Pseudorandom_function_family&oldid=928163524)
+over its inputs.
+*    [C-1-14] MUST NOT use the same File Based Encryption (FBE) keys or subkeys
+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: