Merge "CDD: O errata changes" into oreo-dev
diff --git a/10_software-compatibility-testing/10_0_intro.md b/10_software-compatibility-testing/10_0_intro.md
index d3340aa..26ddf19 100644
--- a/10_software-compatibility-testing/10_0_intro.md
+++ b/10_software-compatibility-testing/10_0_intro.md
@@ -1,10 +1,10 @@
# 10\. Software Compatibility Testing
-Device implementations MUST pass all tests described in this section.
-
-However, note that no software test package is fully comprehensive. For this
-reason, device implementers are **STRONGLY RECOMMENDED** to make the minimum
-number of changes as possible to the reference and preferred implementation of
-Android available from the Android Open Source Project. This will minimize the
-risk of introducing bugs that create incompatibilities requiring rework and
-potential device updates.
+Device implementations MUST pass all tests described in this
+section.
+However, note that no software test package is fully comprehensive.
+For this reason, device implementers are **STRONGLY RECOMMENDED** to make the
+minimum number of changes as possible to the reference and preferred
+implementation of Android available from the Android Open Source Project.
+This will minimize the risk of introducing bugs that create incompatibilities
+requiring rework and potential device updates.
diff --git a/10_software-compatibility-testing/10_1_compatibility_test_suite.md b/10_software-compatibility-testing/10_1_compatibility_test_suite.md
index 5dba74d..1e4307c 100644
--- a/10_software-compatibility-testing/10_1_compatibility_test_suite.md
+++ b/10_software-compatibility-testing/10_1_compatibility_test_suite.md
@@ -1,15 +1,23 @@
## 10.1\. Compatibility Test Suite
-Device implementations MUST pass the
-[Android Compatibility Test Suite (CTS)](http://source.android.com/compatibility/index.html)
+Device implementations:
+
+* [C-0-1] MUST pass the [Android Compatibility Test Suite (CTS)](http://source.android.com/compatibility/index.html)
available from the Android Open Source Project, using the final shipping
-software on the device. Additionally, device implementers SHOULD use the
-reference implementation in the Android Open Source tree as much as possible,
-and MUST ensure compatibility in cases of ambiguity in CTS and for any
+software on the device.
+
+* [C-0-2] MUST ensure compatibility in cases of ambiguity in CTS and for any
reimplementations of parts of the reference source code.
The CTS is designed to be run on an actual device. Like any software, the CTS
may itself contain bugs. The CTS will be versioned independently of this
Compatibility Definition, and multiple revisions of the CTS may be released for
-Android ANDROID_VERSION. Device implementations MUST pass the latest CTS
-version available at the time the device software is completed.
+Android ANDROID_VERSION.
+
+Device implementations:
+
+* [C-0-3] MUST pass the latest CTS version available at the time the device
+software is completed.
+
+* SHOULD use the reference implementation in the Android Open Source tree
+as much as possible.
\ No newline at end of file
diff --git a/10_software-compatibility-testing/10_2_cts-verifier.md b/10_software-compatibility-testing/10_2_cts-verifier.md
index 103e1ed..a52f133 100644
--- a/10_software-compatibility-testing/10_2_cts-verifier.md
+++ b/10_software-compatibility-testing/10_2_cts-verifier.md
@@ -1,22 +1,29 @@
## 10.2\. CTS Verifier
-Device implementations MUST correctly execute all applicable cases in the CTS
-Verifier. The CTS Verifier is included with the Compatibility Test Suite, and
+The CTS Verifier is included with the Compatibility Test Suite, and
is intended to be run by a human operator to test functionality that cannot be
tested by an automated system, such as correct functioning of a camera and
sensors.
+Device implementations:
+
+* [C-0-1] MUST correctly execute all applicable cases in the CTS verifier.
+
The CTS Verifier has tests for many kinds of hardware, including some hardware
-that is optional. Device implementations MUST pass all tests for hardware that
-they possess; for instance, if a device possesses an accelerometer, it MUST
-correctly execute the Accelerometer test case in the CTS Verifier. Test cases
-for features noted as optional by this Compatibility Definition Document MAY be
-skipped or omitted.
+that is optional.
-Every device and every build MUST correctly run the CTS Verifier, as noted
-above. However, since many builds are very similar, device implementers are not
-expected to explicitly run the CTS Verifier on builds that differ only in
-trivial ways. Specifically, device implementations that differ from an
-implementation that has passed the CTS Verifier only by the set of included
-locales, branding, etc. MAY omit the CTS Verifier test.
+Device implementations:
+* [C-0-2] MUST pass all tests for hardware that they possess; for instance,
+if a device possesses an accelerometer, it MUST correctly execute the
+Accelerometer test case in the CTS Verifier.
+
+Test cases for features noted as optional by this Compatibility Definition
+Document MAY be skipped or omitted.
+
+* [C-0-2] Every device and every build MUST correctly run the CTS Verifier,
+as noted above. However, since many builds are very similar, device
+implementers are not expected to explicitly run the CTS Verifier on builds
+that differ only in trivial ways. Specifically, device implementations that
+differ from an implementation that has passed the CTS Verifier only by the
+set of included locales, branding, etc. MAY omit the CTS Verifier test.
diff --git a/11_updatable-software/11_0_intro.md b/11_updatable-software/11_0_intro.md
index 229c3cb..3e7a3a0 100644
--- a/11_updatable-software/11_0_intro.md
+++ b/11_updatable-software/11_0_intro.md
@@ -1,8 +1,8 @@
# 11\. Updatable Software
-Device implementations MUST include a mechanism to replace the entirety of the
-system software. The mechanism need not perform “live” upgrades—that is, a
-device restart MAY be required.
+* [C-0-1] Device implementations MUST include a mechanism to replace the
+entirety of the system software. The mechanism need not perform “live”
+upgrades—that is, a device restart MAY be required.
Any method can be used, provided that it can replace the entirety of the
software preinstalled on the device. For instance, any of the following
@@ -12,14 +12,16 @@
* “Tethered” updates over USB from a host PC.
* “Offline” updates via a reboot and update from a file on removable storage.
-However, if the device implementation includes support for an unmetered data
-connection such as 802.11 or Bluetooth PAN (Personal Area Network) profile, it
-MUST support OTA downloads with offline update via reboot.
+* [C-0-2] The update mechanism used MUST support updates without wiping user
+data. That is, the update mechanism MUST preserve application private data and
+application shared data. Note that the upstream Android software includes an
+update mechanism that satisfies this requirement.
-The update mechanism used MUST support updates without wiping user data. That
-is, the update mechanism MUST preserve application private data and application
-shared data. Note that the upstream Android software includes an update
-mechanism that satisfies this requirement.
+If the device implementations includes support for an unmetered data
+connection such as 802.11 or Bluetooth PAN (Personal Area Network) profile,
+then, they:
+
+* [C-1-1] MUST support OTA downloads with offline update via reboot.
For device implementations that are launching with Android 6.0 and
later, the update mechanism SHOULD support verifying that the system image is
@@ -33,12 +35,14 @@
If an error is found in a device implementation after it has been released but
within its reasonable product lifetime that is determined in consultation with
the Android Compatibility Team to affect the compatibility of third-party
-applications, the device implementer MUST correct the error via a software
+applications, then:
+
+* [C-2-1] The device implementer MUST correct the error via a software
update available that can be applied per the mechanism just described.
Android includes features that allow the Device Owner app (if present) to
-control the installation of system updates. To facilitate this, the system
-update subsystem for devices that report android.software.device_admin MUST
-implement the behavior described in the
-[SystemUpdatePolicy](http://developer.android.com/reference/android/app/admin/SystemUpdatePolicy.html)
-class.
+control the installation of system updates. If the system update subsystem
+for devices report android.software.device_admin then, they:
+
+* [C-3-1] MUST implement the behavior described in the [SystemUpdatePolicy](http://developer.android.com/reference/android/app/admin/SystemUpdatePolicy.html)
+ class.
diff --git a/7_hardware-compatibility/7_9_virtual-reality.md b/7_hardware-compatibility/7_9_virtual-reality.md
index 393058c..2c6d92b 100644
--- a/7_hardware-compatibility/7_9_virtual-reality.md
+++ b/7_hardware-compatibility/7_9_virtual-reality.md
@@ -76,7 +76,10 @@
* MAY provide an exclusive core to the foreground
application and MAY support the `Process.getExclusiveCores` API to return
the numbers of the cpu cores that are exclusive to the top foreground
- application. If exclusive core is supported then the core MUST not allow
- any other userspace processes to run on it (except device drivers used
- by the application), but MAY allow some kernel processes to run as
- necessary.
+ application.
+
+If exclusive core is supported, then the core:
+
+* [C-2-1] MUST not allow any other userspace processes to run on it
+(except device drivers used by the application), but MAY allow some kernel
+processes to run as necessary.
\ No newline at end of file
diff --git a/9_security-model/9_10_device-integrity.md b/9_security-model/9_10_device-integrity.md
index 594bbf2..1b4557d 100644
--- a/9_security-model/9_10_device-integrity.md
+++ b/9_security-model/9_10_device-integrity.md
@@ -14,19 +14,19 @@
* [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
+* [C-1-2] MUST perform verification on every boot sequence.
+* [C-1-3] 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
+* [C-1-4] 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
+* [C-1-5] 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,
+* [C-1-6] 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
+* [C-1-7] MUST NOT allow verified partitions on the device to be modified
unless the user has explicitly unlocked the boot loader.
* [SR] If there are multiple discrete chips in the device (e.g. radio,
specialized image processor), the boot process of each of those chips is
@@ -53,9 +53,9 @@
Device implementations with Advanced Encryption Standard (AES) crypto
performance above 50 MiB/seconds:
-* [C-8-1] MUST support verified boot for device integrity.
+* [C-2-1] MUST support verified boot for device integrity.
If a device implementation is already launched without supporting verified boot
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.
\ No newline at end of file
+requirement.
diff --git a/9_security-model/9_1_permissions.md b/9_security-model/9_1_permissions.md
index 0e8e5bb..525e9d5 100644
--- a/9_security-model/9_1_permissions.md
+++ b/9_security-model/9_1_permissions.md
@@ -42,7 +42,7 @@
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
+* [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_USAGE_ACCESS_SETTINGS)
@@ -52,7 +52,7 @@
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
+* [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_USAGE_ACCESS_SETTINGS)
intent pattern but MUST implement it as a no-op, that is to have an
diff --git a/9_security-model/9_8_privacy.md b/9_security-model/9_8_privacy.md
index ee51b24..8c5c22e 100644
--- a/9_security-model/9_8_privacy.md
+++ b/9_security-model/9_8_privacy.md
@@ -7,7 +7,7 @@
Device implementations:
-* [C-1-1] MUST keep a reasonable retention period of such user history.
+* [C-0-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.
diff --git a/9_security-model/9_9_full-disk-encryption.md b/9_security-model/9_9_full-disk-encryption.md
index 65ee9d6..38ca201 100644
--- a/9_security-model/9_9_full-disk-encryption.md
+++ b/9_security-model/9_9_full-disk-encryption.md
@@ -66,11 +66,13 @@
* [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.
+ * [C-1-11] MUST use the mandatorily supported ciphers, key lengths and
+ modes by default.
+
* 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.
+and file name encryption.
The upstream Android Open Source project provides a preferred implementation of
this feature based on the Linux kernel ext4 encryption feature.
