upload android base code part4

android/compatibility/cdd/9_security-model/9_0_intro.md

@@ -0,0 +1,12 @@
+# 9\. Security Model Compatibility
+
+Device implementations:
+
+*    [C-0-1] MUST implement a security model consistent
+with the Android platform security model as defined in [Security and Permissions reference document](http://developer.android.com/guide/topics/security/permissions.html)
+in the APIs in the Android developer documentation.
+
+*    [C-0-2] MUST support installation of self-signed
+applications without requiring any additional permissions/certificates from any
+third parties/authorities. Specifically, compatible devices MUST support the
+security mechanisms described in the follow subsections.

android/compatibility/cdd/9_security-model/9_10_device-integrity.md

@@ -0,0 +1,61 @@
+## 9.10\. Device Integrity
+
+The following requirements ensures there is transparancy to the status of the
+device integrity. Device implementations:
+
+*    [C-0-1] MUST correctly report through the System API method
+`PersistentDataBlockManager.getFlashLockState()` whether their bootloader
+state permits flashing of the system image. The `FLASH_LOCK_UNKNOWN` state is
+reserved for device implementations upgrading from an earlier version of Android
+where this new system API method did not exist.
+
+Verified boot is a feature that guarantees the integrity of the device
+software. If a device implementation supports the feature, it:
+
+*    [C-1-1] MUST declare the platform feature flag
+`android.software.verified_boot`.
+*    [C-2-1] MUST perform verification on every boot sequence.
+*    [C-3-1] MUST start verification from an immutable hardware key that is the
+root of trust and go all the way up to the system partition.
+*    [C-4-1] MUST implement each stage of verification to check the integrity
+and authenticity of all the bytes in the next stage before executing the code in
+the next stage.
+*    [C-5-1] MUST use verification algorithms as strong as current
+recommendations from NIST for hashing algorithms (SHA-256) and public key
+sizes (RSA-2048).
+*    [C-6-1] MUST NOT allow boot to complete when system verification fails,
+unless the user consents to attempt booting anyway, in which case the data from
+any non-verified storage blocks MUST not be used.
+*    [C-7-1] MUST NOT allow verified partitions on the device to be modified
+unless the user has explicitly unlocked the boot loader.
+*    [SR] If there are multiple discrete chips in the device (e.g. radio,
+specialized image processor), the boot process of each of those chips is
+STRONGLY RECOMMENDED to verify every stage upon booting.
+*    [SR] STRONGLY RECOMMENDED to use tamper-evident storage: for when the
+bootloader is unlocked. Tamper-evident storage means that the boot loader can
+detect if the storage has been tampered with from inside the
+HLOS (High Level Operating System).
+*    [SR] STRONGLY RECOMMENDED to prompt the user, while using the device, and
+require physical confirmation before allowing a transition from boot loader
+locked mode to boot loader unlocked mode.
+*    [SR] STRONGLY RECOMMENDED to implement rollback protection for the HLOS
+(e.g. boot, system partitions) and to use tamper-evident storage for storing the
+metadata used for determining the minimum allowable OS version.
+*    SHOULD implement rollback protection for any component with persistent
+firmware (e.g. modem, camera) and SHOULD use tamper-evident storage for
+storing the metadata used for determining the minimum allowable version.
+
+The upstream Android Open Source Project provides a preferred implementation of
+this feature in the [`external/avb/`](http://android.googlesource.com/platform/external/avb/)
+repository, which can be integrated into the boot loader used for loading
+Android.
+
+Device implementations with Advanced Encryption Standard (AES) crypto
+performance above 50 MiB/seconds:
+
+*    [C-8-1] MUST support verified boot for device integrity.
+
+If a device implementation is already launched without supporting verified boot
+on an earlier version of Android, such a device can not add support for this
+feature with a system software update and thus are exempted from the
+requirement.

android/compatibility/cdd/9_security-model/9_11_keys-and-credentials.md

@@ -0,0 +1,149 @@
+## 9.11\. Keys and Credentials
+
+The [Android Keystore System](https://developer.android.com/training/articles/keystore.html)
+allows app developers to store cryptographic keys in a container and use them in
+cryptographic operations through the [KeyChain API](https://developer.android.com/reference/android/security/KeyChain.html)
+or the [Keystore API](https://developer.android.com/reference/java/security/KeyStore.html).
+Device implementations:
+
+*    [C-0-1] MUST at least allow more than 8,192 keys to be imported.
+*    [C-0-2] The lock screen authentication MUST rate-limit attempts and MUST
+have an exponential backoff algorithm. Beyond 150 failed attempts, the delay
+MUST be at least 24 hours per attempt.
+*    SHOULD not limit the number of keys that can be generated
+
+When the device implementation supports a secure lock screen, it:
+
+*    [C-1-1] MUST back up the keystore implementation with secure hardware.
+*    [C-1-2] MUST have implementations of RSA, AES, ECDSA and HMAC cryptographic
+algorithms and MD5, SHA1, and SHA-2 family hash functions to properly support
+the Android Keystore system's supported algorithms in an area that is securely
+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. The upstream
+Android Open Source Project (AOSP) meets this requirement by using the
+[Trusty](https://source.android.com/security/trusty/) implementation, but
+another ARM TrustZone-based solution or a third-party reviewed secure
+implementation of a proper hypervisor-based isolation are alternative options.
+*    [C-1-3] MUST perform the lock screen authentication in the isolated
+execution environment and only when successful, allow the authentication-bound
+keys to be used. The upstream Android Open Source Project provides the
+[Gatekeeper Hardware Abstraction Layer (HAL)](http://source.android.com/devices/tech/security/authentication/gatekeeper.html)
+and Trusty, which can be used to satisfy this requirement.
+*    [C-1-4] MUST support key attestation where the attestation signing key is
+protected by secure hardware and signing is performed in secure hardware. The
+attestation signing keys MUST be shared across large enough number of devices to
+prevent the keys from being used as device identifiers. One way of meeting this
+requirement is to share the same attestation key unless at least 100,000 units
+of a given SKU are produced. If more than 100,000 units of an SKU are produced,
+a different key MAY be used for each 100,000 units.
+
+Note that if a device implementation is already launched on an earlier Android
+version, such a device is exempted from the requirement to have a
+hardware-backed keystore, unless it declares the `android.hardware.fingerprint`
+feature which requires a hardware-backed keystore.
+
+### 9.11.1\. Secure Lock Screen
+
+If device implementations have a secure lock screen and include one or more
+trust agent, which implements the `TrustAgentService` System API, then they:
+
+*    [C-1-1] MUST indicate the user in the Settings and Lock screen user
+interface of situations where either the screen auto-lock is deferred or the
+screen lock can be unlocked by the trust agent. The AOSP meets the requirement
+by showing a text description for the "Automatically lock setting" and
+"Power button instantly locks setting" menus and a distinguishable icon on
+the lock screen.
+*    [C-1-2] MUST respect and fully implement all trust agent APIs in the
+`DevicePolicyManager` class, such as the [`KEYGUARD_DISABLE_TRUST_AGENTS`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#KEYGUARD&lowbarDISABLE&lowbarTRUST&lowbarAGENTS)
+constant.
+*    [C-1-3] MUST NOT fully implement the `TrustAgentService.addEscrowToken()`
+function on a device that is used as the primary personal device
+(e.g. handheld) but MAY fully implement the function on device implementations
+typically shared.
+*    [C-1-4] MUST encrypt the tokens added by `TrustAgentService.addEscrowToken()`
+before storing them on the device.
+*    [C-1-5] MUST NOT store the encryption key on the device.
+*    [C-1-6] MUST inform the user about the security implications before
+enabling the escrow token to decrypt the data storage.
+
+If device implementations add or modify the authentication methods to unlock
+the lock screen, then for such an authentication method to be treated as a
+secure way to lock the screen, they:
+
+*    [C-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 then for such an authentication
+method to be treated as a secure way to lock the screen, they:
+
+*    [C-3-1] The entropy of the shortest allowed length of inputs MUST be
+greater than 10 bits.
+*    [C-3-2] The maximum entropy of all possible inputs MUST be greater than
+18 bits.
+*    [C-3-3] MUST not replace any of the existing authentication methods
+(PIN,pattern, password) implemented and provided in AOSP.
+*    [C-3-4] MUST be disabled when the Device Policy Controller (DPC)
+application has set the password quality policy via the
+[`DevicePolicyManager.setPasswordQuality()`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordQuality%28android.content.ComponentName,%20int%29)
+method with a more restrictive quality constant than
+`PASSWORD_QUALITY_SOMETHING`.
+
+If device implementations add or modify the authentication methods to unlock
+the lock screen if based on a physical token or the location, then for such an
+authentication method to be treated as a secure way to lock the screen, they:
+
+*    [C-4-1] MUST have a fall-back mechanism to use one of the primary
+authentication methods which is based on a known secret and meets the
+requirements to be treated as a secure lock screen.
+*    [C-4-2] MUST be disabled and only allow the primary authentication to
+unlock the screen when the Device Policy Controller (DPC) application has set
+the policy with either the [`DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS)`](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setKeyguardDisabledFeatures%28android.content.ComponentName,%20int%29)
+method or the [`DevicePolicyManager.setPasswordQuality()`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordQuality%28android.content.ComponentName,%20int%29)
+method with a more restrictive quality constant than
+`PASSWORD_QUALITY_UNSPECIFIED`.
+*    [C-4-3] The user MUST be challenged for the primary authentication
+(e.g.PIN, pattern, password) at least once every 72 hours or less.
+
+If device implementations add or modify the authentication methods to unlock
+the lock screen based on biometrics, then for such an authentication method to
+be treated as a secure way to lock the screen, they:
+
+*    [C-5-1] MUST have a fall-back mechanism to use one of the primary
+authentication methods which is based on a known secret and meets the
+requirements to be treated as a secure lock screen.
+*    [C-5-2] MUST be disabled and only allow the primary authentication to
+unlock the screen when the Device Policy Controller (DPC) application has set
+the keguard feature policy by calling the method
+[`DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT)`](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setKeyguardDisabledFeatures%28android.content.ComponentName,%20int%29).
+*    [C-5-3] MUST have a false acceptance rate that is equal or stronger than
+what is required for a fingerprint sensor as described in section 7.3.10, or
+otherwise MUST be disabled and only allow the primary authentication to unlock
+the screen when the Device Policy Controller (DPC) application has set the
+password quality policy via the [`DevicePolicyManager.setPasswordQuality()`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html\#setPasswordQuality%28android.content.ComponentName,%20int%29)
+method with a more restrictive quality constant than
+`PASSWORD_QUALITY_BIOMETRIC_WEAK`.
+*    [C-5-4] The user MUST be challenged for the primary authentication
+(e.g.PIN, pattern, password) at least once every 72 hours or less.
+
+If device implementations add or modify the authentication methods to unlock
+the lock screen and if such an authentication method will be used to unlock
+the keyguard, but will not be treated as a secure lock screen, then they:
+
+*    [C-6-1] MUST return `false` for both the [`KeyguardManager.isKeyguardSecure()`](http://developer.android.com/reference/android/app/KeyguardManager.html#isKeyguardSecure%28%29)
+and the [`KeyguardManager.isDeviceSecure()`](https://developer.android.com/reference/android/app/KeyguardManager.html#isDeviceSecure%28%29)
+methods.
+*    [C-6-2] MUST be disabled when the Device Policy Controller (DPC)
+application has set the password quality policy via the [`DevicePolicyManager.setPasswordQuality()`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordQuality%28android.content.ComponentName,%20int%29)
+method with a more restrictive quality constant than
+`PASSWORD_QUALITY_UNSPECIFIED`.
+*    [C-6-3] MUST NOT reset the password expiration timers set by
+[`DevicePolicyManager.setPasswordExpirationTimeout()`](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordExpirationTimeout%28android.content.ComponentName,%20long%29).
+*    [C-6-4] MUST NOT authenticate access to keystores if the application has
+called [`KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true)`](https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired%28boolean%29)).

android/compatibility/cdd/9_security-model/9_12_data-deletion.md

@@ -0,0 +1,16 @@
+## 9.12\. Data Deletion
+
+All device implementations:
+
+*   [C-0-1] MUST provide users a mechanism to perform a "Factory Data Reset".
+*   [C-0-2] MUST delete all user-generated data. That is, all data except for
+    the following:
+     *    The system image
+     *    Any operating system files required by the system image
+*   [C-0-3] MUST delete the data in such a way that will satisfy relevant
+    industry standards such as NIST SP800-88\.
+*   [C-0-4] MUST trigger the above "Factory Data Reset" process when the
+    [`DevicePolicyManager.wipeData()`](
+    https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#wipeData%28int%29)
+    API is called by the primary user's Device Policy Controller app.
+*   MAY provide a fast data wipe option that conducts only a logical data erase.

android/compatibility/cdd/9_security-model/9_13_safe-mode.md

@@ -0,0 +1,25 @@
+## 9.13\. Safe Boot Mode
+
+Android provides Safe Boot Mode, which allows users to boot up into a mode
+where only preinstalled system apps are allowed to run and all third-party
+apps are disabled. This mode, known as "Safe Boot Mode", provides the user the
+capability to uninstall potentially harmful third-party apps.
+
+Device implementations are:
+
+*   [SR] STRONGLY RECOMMENDED to implement Safe Boot Mode.
+
+If device implementations implement Safe Boot Mode, they:
+
+*   [C-1-1] MUST provide the user an option to
+    enter Safe Boot Mode in such a way that is uninterruptible from third-party
+    apps installed on the device, except when the third-party app is a
+    Device Policy Controller and has set the [`UserManager.DISALLOW_SAFE_BOOT`](
+    https://developer.android.com/reference/android/os/UserManager.html#DISALLOW_SAFE_BOOT)
+    flag as true.
+
+*   [C-1-2] MUST provide the user the capability to
+    uninstall any third-party apps within Safe Mode.
+
+*   SHOULD provide the user an option to enter Safe Boot Mode from the
+boot menu using a workflow that is different from that of a normal boot.

android/compatibility/cdd/9_security-model/9_14_automotive-system-isolation.md

@@ -0,0 +1,16 @@
+## 9.14\. Automotive Vehicle System Isolation
+
+Android Automotive devices are expected to exchange data with critical vehicle
+subsystems by using the [vehicle HAL](http://source.android.com/devices/automotive.html)
+to send and receive messages over vehicle networks such as CAN bus.
+
+The data exchange can be secured by implementing security features below the
+Android framework layers to prevent malicious or unintentional interaction with
+these subsystems. Automotive device implementations:
+
+*    [A-0-1] MUST gatekeep messages from Android framework vehicle subsystems,
+e.g., whitelisting permitted message types and message sources.
+*    [A-0-2] MUST watchdog against denial of service attacks from the Android
+framework or third-party apps. This guards against malicious software flooding
+the vehicle network with traffic, which may lead to malfunctioning vehicle
+subsystems.

android/compatibility/cdd/9_security-model/9_1_permissions.md

@@ -0,0 +1,67 @@
+## 9.1\. Permissions
+
+Device implementations:
+
+*   [C-0-1] MUST support the [Android permissions model](
+http://developer.android.com/guide/topics/security/permissions.html)
+as defined in the Android developer documentation. Specifically, they
+MUST enforce each permission defined as described in the SDK documentation; no
+permissions may be omitted, altered, or ignored.
+
+*   MAY add additional permissions, provided the new permission ID strings
+are not in the `android.\*` namespace.
+
+*   [C-0-2] Permissions with a `protectionLevel` of
+[`PROTECTION_FLAG_PRIVILEGED`](
+https://developer.android.com/reference/android/content/pm/PermissionInfo.html#PROTECTION_FLAG_PRIVILEGED)
+MUST only be granted to apps preloaded in the privileged path(s) of the system
+image and within the subset of the explicitly whitelisted permissions for each
+app. The AOSP implementation meets this requirement by reading and honoring
+the whitelisted permissions for each app from the files in the
+`etc/permissions/` path and using the `system/priv-app` path as the
+privileged path.
+
+Permissions with a protection level of dangerous are runtime permissions.
+Applications with `targetSdkVersion` > 22 request them at runtime.
+
+Device implementations:
+
+*   [C-0-3] MUST show a dedicated interface for the user to decide
+     whether to grant the requested runtime permissions and also provide
+     an interface for the user to manage runtime permissions.
+*   [C-0-4] MUST have one and only one implementation of both user
+     interfaces.
+*   [C-0-5] MUST NOT grant any runtime permissions to preinstalled
+     apps unless:
+   *   the user's consent can be obtained before the application
+       uses it
+   *   the runtime permissions are associated with an intent pattern
+       for which the preinstalled application is set as the default handler
+
+Handheld device implementations:
+
+*   [H-0-1] MUST allow third-party apps to access the usage statistics via the
+    `android.permission.PACKAGE_USAGE_STATS` permission and provide a
+    user-accessible mechanism to grant or revoke access to such apps in response
+    to the [`android.settings.ACTION_USAGE_ACCESS_SETTINGS`](
+    https://developer.android.com/reference/android/provider/Settings.html#ACTION_USAGE_ACCESS_SETTINGS)
+    intent.
+
+If device implementations include a pre-installed app or wish to allow
+third-party apps to access the usage statistics, they:
+
+*   [C-1-1] 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_USAGE_ACCESS_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-2-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_USAGE_ACCESS_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.

android/compatibility/cdd/9_security-model/9_2_uid-and-process-isolation.md

@@ -0,0 +1,10 @@
+## 9.2\. UID and Process Isolation
+
+Device implementations:
+
+*    [C-0-1] MUST support the Android application
+sandbox model, in which each application runs as a unique Unixstyle UID
+and in a separate process.
+*    [C-0-2] MUST support running multiple applications
+as the same Linux user ID, provided that the applications are properly signed
+and constructed, as defined in the [Security and Permissions reference](http://developer.android.com/guide/topics/security/permissions.html).

android/compatibility/cdd/9_security-model/9_3_filesystem-permissions.md

@@ -0,0 +1,7 @@
+## 9.3\. Filesystem Permissions
+
+Device implementations:
+
+*    [C-0-1] MUST support the Android file access
+permissions model as defined in the [Security and Permissions reference](
+http://developer.android.com/guide/topics/security/permissions.html).

android/compatibility/cdd/9_security-model/9_4_alternate-execution-environments.md

@@ -0,0 +1,52 @@
+## 9.4\. Alternate Execution Environments
+
+Device implementations MUST keep consistency of the Android security and
+permission model, even if they include runtime environments that execute
+applications using some other software or technology than the Dalvik Executable
+Format or native code. In other words:
+
+*    [C-0-1] Alternate runtimes MUST themselves be Android applications,
+and abide by the standard Android security model, as described elsewhere
+in [section 9](#9_security_model_compatibility).
+
+*    [C-0-2] Alternate runtimes MUST NOT be granted access to resources
+protected by permissions not requested in the runtime’s `AndroidManifest.xml`
+file via the <`uses-permission`> mechanism.
+
+*    [C-0-3] Alternate runtimes MUST NOT permit applications to make use of
+features protected by Android permissions restricted to system applications.
+
+*    [C-0-4] Alternate runtimes MUST abide by the Android sandbox model
+and installed applications using an alternate runtime MUST NOT
+reuse the sandbox of any other app installed on the device, except through
+the standard Android mechanisms of shared user ID and signing certificate.
+
+*    [C-0-5] Alternate runtimes MUST NOT launch with, grant, or be granted
+access to the sandboxes corresponding to other Android applications.
+
+*    [C-0-6] Alternate runtimes MUST NOT be launched with, be granted, or grant
+to other applications any privileges of the superuser (root), or of any other
+user ID.
+
+*    [C-0-7] When the `.apk` files of alternate runtimes are included in the
+system image of device implementations, it MUST be signed with a key distinct
+from the key used to sign other applications included with the device
+implementations.
+
+*    [C-0-8] When installing applications, alternate runtimes MUST obtain
+user consent for the Android permissions used by the application.
+
+*    [C-0-9] When an application needs to make use of a device resource for
+which there is a corresponding Android permission (such as Camera, GPS, etc.),
+the alternate runtime MUST inform the user that the application will be able to
+access that resource.
+
+*    [C-0-10] When the runtime environment does not record application
+capabilities in this manner, the runtime environment MUST list all permissions
+held by the runtime itself when installing any application using that runtime.
+
+*    Alternate runtimes SHOULD install apps via the `PackageManager` into
+separate Android sandboxes (Linux user IDs, etc.).
+
+*    Alternate runtimes MAY provide a single Android sandbox shared by all
+applications using the alternate runtime.

android/compatibility/cdd/9_security-model/9_5_multi-user-support.md

@@ -0,0 +1,55 @@
+## 9.5\. Multi-User Support
+
+Android includes [support for multiple users](
+http://developer.android.com/reference/android/os/UserManager.html)
+and provides support for full user isolation.
+
+*    Device implementations MAY but SHOULD NOT enable multi-user if they use
+[removable media](
+http://developer.android.com/reference/android/os/Environment.html)
+for primary external storage.
+
+If Automotive device implementations include multiple users, they:
+
+*   [A-1-1] MUST include a guest account that allows all functions provided
+by the vehicle system without requiring a user to log in.
+
+If device implementations include multiple users, they:
+
+*   [C-1-1] MUST meet the following requirements related to
+[multi-user support](
+http://source.android.com/devices/storage/traditional.html).
+*   [C-1-2] MUST, for each user, implement a security
+model consistent with the Android platform security model as defined in
+[Security and Permissions reference document](
+http://developer.android.com/guide/topics/security/permissions.html)
+in the APIs.
+*   [C-1-3] MUST have separate and isolated shared application storage
+(a.k.a. `/sdcard`) directories for each user instance.
+*   [C-1-4] MUST ensure that applications owned by and running on behalf a
+given user cannot list, read, or write to the files owned by any other user,
+even if the data of both users are stored on the same volume or filesystem.
+*   [C-1-5] MUST encrypt the contents of the SD card when multiuser is enabled
+using a key stored only on non-removable media accessible only to the system if
+device implementations use removable media for the external storage APIs.
+As this will make the media unreadable by a host PC, device implementations
+will be required to switch to MTP or a similar system to provide host PCs with
+access to the current user’s data.
+
+If device implementations include multiple users and
+do not declare the `android.hardware.telephony` feature flag, they:
+
+*   [C-2-1] MUST support restricted profiles,
+a feature that allows device owners to manage additional users and their
+capabilities on the device. With restricted profiles, device owners can quickly
+set up separate environments for additional users to work in, with the ability
+to manage finer-grained restrictions in the apps that are available in those
+environments.
+
+If device implementations include multiple users and
+declare the `android.hardware.telephony` feature flag, they:
+
+*   [C-3-1] MUST NOT support restricted profiles but MUST align with the AOSP
+implementation of controls to enable /disable other users from accessing the
+voice calls and SMS.
+

android/compatibility/cdd/9_security-model/9_6_premium-sms-warning.md

@@ -0,0 +1,14 @@
+## 9.6\. Premium SMS Warning
+
+Android includes support for warning users of any outgoing
+[premium SMS message](http://en.wikipedia.org/wiki/Short_code). Premium SMS
+messages are text messages sent to a service registered with a carrier that may
+incur a charge to the user.
+
+If device implementations declare support for `android.hardware.telephony`,
+they:
+
+*    [C-1-1]  MUST warn users before sending a SMS message to numbers
+identified by regular expressions defined in `/data/misc/sms/codes.xml`
+file in the device. The upstream Android Open Source Project provides
+an implementation that satisfies this requirement.

android/compatibility/cdd/9_security-model/9_7_kernel-security-features.md

@@ -0,0 +1,75 @@
+## 9.7\. Kernel Security Features
+
+The Android Sandbox includes features that use the Security-Enhanced Linux
+(SELinux) mandatory access control (MAC) system, seccomp sandboxing, and other
+security features in the Linux kernel. Device implementations:
+
+*   [C-0-1] MUST maintain compatibility with existing applications, even when
+SELinux or any other security features are implemented below the Android
+framework.
+*   [C-0-2] MUST NOT have a visible user interface when a security
+violation is detected and successfully blocked by the security feature
+implemented below the Android framework, but MAY have a visible user interface
+when an unblocked security violation occurs resulting in a successful exploit.
+*   [C-0-3] MUST NOT make SELinux or any other security features implemented
+below the Android framework configurable to the user or app developer.
+*   [C-0-4]  MUST NOT allow an application that can affect another application
+through an API (such as a Device Administration API) to configure a policy
+that breaks compatibility.
+*   [C-0-5] MUST split the media framework into multiple processes so that it
+is possible to more narrowly grant access for each process as
+[described](https://source.android.com/devices/media/framework-hardening.html#arch_changes)
+in the Android Open Source Project site.
+*   [C-0-6] MUST implement a kernel application sandboxing mechanism
+which allows filtering of system calls using a configurable policy from
+multithreaded programs. The upstream Android Open Source Project meets this
+requirement through enabling the seccomp-BPF with threadgroup
+synchronization (TSYNC) as described
+[in the Kernel Configuration section of source.android.com](http://source.android.com/devices/tech/config/kernel.html#Seccomp-BPF-TSYNC).
+
+Kernel integrity and self-protection features are integral to Android
+security. Device implementations:
+
+*   [C-0-7] MUST implement kernel stack buffer overflow protections
+(e.g. `CONFIG_CC_STACKPROTECTOR_STRONG`).
+*   [C-0-8] MUST implement strict kernel memory protections where executable
+code is read-only, read-only data is non-executable and non-writable, and
+writable data is non-executable (e.g. `CONFIG_DEBUG_RODATA` or `CONFIG_STRICT_KERNEL_RWX`).
+*   [SR] STRONGLY RECOMMENDED to keep kernel data
+which is written only during initialization marked read-only after
+initialization (e.g. `__ro_after_init`).
+*   [SR} STRONGLY RECOMMENDED to implement static and dynamic object size
+bounds checking of copies between user-space and kernel-space
+(e.g. `CONFIG_HARDENED_USERCOPY`).
+*   [SR] STRONGLY RECOMMENDED to never execute user-space memory when running
+in the kernel (e.g. hardware PXN, or emulated via
+`CONFIG_CPU_SW_DOMAIN_PAN` or `CONFIG_ARM64_SW_TTBR0_PAN`).
+*   [SR] STRONGLY RECOMMENDED to never read or write user-space memory in the
+kernel outside of normal usercopy access APIs (e.g. hardware PAN, or
+emulated via `CONFIG_CPU_SW_DOMAIN_PAN` or `CONFIG_ARM64_SW_TTBR0_PAN`).
+*   [SR] STRONGLY RECOMMENDED to randomize the layout of the kernel code and
+memory, and to avoid exposures that would compromise the randomization
+(e.g. `CONFIG_RANDOMIZE_BASE` with bootloader entropy via the
+[`/chosen/kaslr-seed Device Tree node`](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/chosen.txt)
+or [`EFI_RNG_PROTOCOL`](https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/efi-rng-protocol)).
+
+
+If device implementations use a Linux kernel, they:
+
+*   [C-1-1] MUST implement SELinux.
+*   [C-1-2] MUST set SELinux to global enforcing mode.
+*   [C-1-3] MUST configure all domains in enforcing mode. No permissive mode
+domains are allowed, including domains specific to a device/vendor.
+*   [C-1-4] MUST NOT modify, omit, or replace the neverallow rules present
+within the system/sepolicy folder provided in the upstream Android Open Source
+Project (AOSP) and the policy MUST compile with all neverallow rules present,
+for both AOSP SELinux domains as well as device/vendor specific domains.
+*   SHOULD retain the default SELinux policy provided in the system/sepolicy
+folder of the upstream Android Open Source Project and only further add to this
+policy for their own device-specific configuration.
+
+
+If device implementations use kernel other than Linux, they:
+
+*   [C-2-1] MUST use an mandatory access control system that is
+equivalent to SELinux.

android/compatibility/cdd/9_security-model/9_8_privacy.md

@@ -0,0 +1,68 @@
+## 9.8\. Privacy
+
+### 9.8.1\. Usage History
+
+Android stores the history of the user's choices and manages such history by
+[UsageStatsManager](https://developer.android.com/reference/android/app/usage/UsageStatsManager.html).
+
+Device implementations:
+
+*   [C-1-1] MUST keep a reasonable retention period of such user history.
+*   [SR] Are STRONGLY RECOMMENDED to keep the 14 days retention period as
+    configured by default in the AOSP implementation.
+
+
+### 9.8.2\. Recording
+
+If device implementations include functionality in the system that captures
+the contents displayed on the screen and/or records the audio stream played
+on the device, they:
+
+*   [C-1-1] MUST have an ongoing notification to the user whenever this
+    functionality is enabled and actively capturing/recording.
+
+If device implementations include a component enabled out-of-box, capable of
+recording ambient audio to infer useful information about user’s context, they:
+
+*   [C-2-1] MUST NOT store in persistent on-device storage or transmit off the
+    device the recorded raw audio or any format that can be converted back into
+    the original audio or a near facsimile, except with explicit user consent.
+
+### 9.8.3\. Connectivity
+
+If device implementations have a USB port with USB peripheral mode support,
+they:
+
+*   [C-1-1] MUST present a user interface asking for the user's consent before
+allowing access to the contents of the shared storage over the USB port.
+
+
+### 9.8.4\. Network Traffic
+
+Device implementations:
+
+*   [C-0-1] MUST preinstall the same root certificates for the system-trusted
+    Certificate Authority (CA) store as [provided](
+    https://source.android.com/security/overview/app-security.html#certificate-authorities)
+    in the upstream Android Open Source Project.
+*   [C-0-2] MUST ship with an empty user root CA store.
+*   [C-0-3] MUST display a warning to the user indicating the network traffic
+    may be monitored, when a user root CA is added.
+
+If device traffic is routed through a VPN, device implementations:
+
+*   [C-1-1] MUST display a warning to the user indicating either:
+    *   That network traffic may be monitored.
+    *   That network traffic is being routed through the specific VPN
+        application providing the VPN.
+
+If device implementations have a mechanism, enabled out-of-box by default, that
+routes network data traffic through a proxy server or VPN gateway (for example,
+preloading a VPN service with `android.permission.CONTROL_VPN` granted), they:
+
+*    [C-2-1] MUST ask for the user's consent before enabling that mechanism,
+     unless that VPN is enabled by the Device Policy Controller via the
+     [`DevicePolicyManager.setAlwaysOnVpnPackage()`](
+     https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setAlwaysOnVpnPackage%28android.content.ComponentName, java.lang.String, boolean%29)
+     , in which case the user does not need to provide a separate consent, but
+     MUST only be notified.

android/compatibility/cdd/9_security-model/9_9_full-disk-encryption.md

@@ -0,0 +1,101 @@
+## 9.9\. Data Storage Encryption
+
+If device implementations support a secure lock screen as described in
+[section 9.11.1](#9_11_1_secure_lock_screen), they:
+
+*   [C-1-1] MUST support data storage encryption of the application private
+data (`/data partition`), as well as the application shared storage partition
+(`/sdcard partition`) if it is a permanent, non-removable part of the device.
+
+If device implementations support a secure lock screen as described in
+[section 9.11.1](#9_11_1_secure_lock_screen) and support data storage
+encryption with Advanced Encryption Standard (AES) crypto performance
+above 50MiB/sec, they:
+
+*    [C-2-1] MUST enable the data storage encryption by default at the time
+the user has completed the out-of-box setup experience. If device
+implementations are already launched on an earlier Android version with
+encryption disabled by default, such a device cannot meet the requirement
+through a system software update and thus MAY be exempted.
+
+*    SHOULD meet the above data storage encryption
+requirement via implementing [File Based Encryption](
+https://source.android.com/security/encryption/file-based.html) (FBE).
+
+### 9.9.1\. Direct Boot
+
+Device implementations:
+
+*    [C-0-1] MUST implement the [Direct Boot mode](
+http://developer.android.com/preview/features/direct-boot.html) APIs even if
+they do not support Storage Encryption.
+
+*     [C-0-2] The [`ACTION_LOCKED_BOOT_COMPLETED`](
+https://developer.android.com/reference/android/content/Intent.html#ACTION_LOCKED_BOOT_COMPLETED)
+and [`ACTION_USER_UNLOCKED`](https://developer.android.com/reference/android/content/Intent.html#ACTION_USER_UNLOCKED)
+Intents MUST still be broadcast to signal Direct Boot aware applications that
+Device Encrypted (DE) and Credential Encrypted (CE) storage locations are
+available for user.
+
+### 9.9.2\. File Based Encryption
+
+If device implementations support FBE, 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
+after the `ACTION_LOCKED_BOOT_COMPLETED` message is broadcasted.
+*    [C-1-2] MUST only allow access to Credential Encrypted (CE) storage after
+the user has unlocked the device by supplying their credentials
+(eg. passcode, pin, pattern or fingerprint) and the `ACTION_USER_UNLOCKED`
+message is broadcasted.
+*    [C-1-3] MUST NOT offer any method to unlock the CE protected storage
+without the user-supplied credentials.
+*    [C-1-4] MUST support Verified Boot and ensure that DE keys are
+cryptographically bound to the device's hardware root of trust.
+*    [C-1-5] MUST support encrypting file contents using AES with a key length
+of 256-bits in XTS mode.
+*    [C-1-6] MUST support encrypting file name using AES with a key length of
+256-bits in CBC-CTS mode.
+
+*   The keys protecting CE and DE storage areas:
+
+   *   [C-1-7] MUST be cryptographically bound to a hardware-backed Keystore.
+   *   [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.
+   *   [C-1-10] MUST be unique and distinct, in other words no user's CE or DE
+   key matches any other user's CE or DE keys.
+
+*    SHOULD make preloaded essential apps (e.g. Alarm, Phone, Messenger)
+Direct Boot aware.
+*    MAY support alternative ciphers, key lengths and modes for file content
+and file name encryption, but MUST use the mandatorily supported ciphers, key
+lengths and modes by default.
+
+The upstream Android Open Source project provides a preferred implementation of
+this feature based on the Linux kernel ext4 encryption feature.
+
+### 9.9.3\. Full Disk Encryption
+
+If device implementations support [full disk encryption](
+http://source.android.com/devices/tech/security/encryption/index.html)
+(FDE), they:
+
+*   [C-1-1] MUST use AES with a key of 128-bits (or greater) and a mode
+designed for storage (for example, AES-XTS, AES-CBC-ESSIV).
+*   [C-1-2] MUST use a default passcode to wrap the encryption key and
+MUST NOT write the encryption key to storage at any time
+without being encrypted.
+   *   [C-1-3] MUST provide the user the possibility to AES encrypt the
+   encryption key, except when it is in active use, with the lock screen
+   credentials stretched using a slow stretching algorithm
+   (e.g. PBKDF2 or scrypt).
+*   [C-1-4] The above default password stretching algorithm MUST be
+cryptographically bound to that keystore when the user has not specified a lock
+screen credentials or has disabled use of the passcode for encryption and
+the device provides a hardware-backed keystore.
+*   [C-1-5] MUST NOT send encryption key off the the device
+(even when wrapped with the user passcode and/or hardware bound key).
+
+The upstream Android Open Source project provides a preferred implementation
+of this feature, based on the Linux kernel feature dm-crypt.