[automerger] Merge "CDD: Relax CDD section 7.2.3 visibility requirement for nav functions" into nougat-dev am: 472ba43619 am: e069b9dbd6 am: 3840033f08 am: c53268693c am: 93e1223544 -s ours am: 9abaf8b016 am: 6f0749b91f
am: 23df259fed
Change-Id: Ib64226ac79b2871bc58b4600c2d997b4faa9375c
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/2_device-types/2_2_handheld-reqs.md b/2_device-types/2_2_handheld-reqs.md
index abdc318..66c8209 100644
--- a/2_device-types/2_2_handheld-reqs.md
+++ b/2_device-types/2_2_handheld-reqs.md
@@ -56,7 +56,7 @@
* [H-0-1] MUST provide the Home, Recents, and Back functions.
-* [H-0-2] MUST send both the normal and long press event of the the Back
+* [H-0-2] MUST send both the normal and long press event of the Back
function ([`KEYCODE_BACK`](http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK))
to the foreground application.
@@ -252,11 +252,11 @@
Handheld device implementations MUST support the following video decoding:
-* [H-0-1] H.264 AVC.
-* [H-0-2] H.265 HEVC.
-* [H-0-3] MPEG-4 SP.
-* [H-0-4] VP8.
-* [H-0-5] VP9.
+* [H-0-1] H.264 AVC
+* [H-0-2] H.265 HEVC
+* [H-0-3] MPEG-4 SP
+* [H-0-4] VP8
+* [H-0-5] VP9
### 2.2.3\. Software
@@ -324,7 +324,7 @@
**Lock Screen Media Control (Section 3.8.10)**
-If Android Handheld device implementations support a lock screen,they:
+If Android Handheld device implementations support a lock screen, they:
* [H-1-1] MUST display the Lock screen Notifications including the Media Notification Template.
@@ -340,7 +340,7 @@
Handheld device implementations:
-* [H-SR] MUST support third-party accessibility services.
+* [H-0-1] MUST support third-party accessibility services.
* [H-SR] Are STRONGLY RECOMMENDED to preload accessibility services on the
device comparable with or exceeding functionality of the Switch Access and
diff --git a/2_device-types/2_3_television-reqs.md b/2_device-types/2_3_television-reqs.md
index 2f5ef14..d0e9e19 100644
--- a/2_device-types/2_3_television-reqs.md
+++ b/2_device-types/2_3_television-reqs.md
@@ -30,7 +30,7 @@
Television device implementations:
* [T-0-1] MUST provide the Home and Back functions.
-* [T-0-2] MUST send both the normal and long press event of the the Back
+* [T-0-2] MUST send both the normal and long press event of the Back
function
([`KEYCODE_BACK`](http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK))
to the foreground application.
@@ -233,9 +233,10 @@
Television device implementations:
-* [T-SR] MUST support third-party accessibility services.
-* [T-SR] Android Television device implementations are STRONGLY RECOMMENDED to
+* [T-0-1] MUST support third-party accessibility services.
+
+* [T-SR] Are STRONGLY RECOMMENDED to
preload accessibility services on the device comparable with or exceeding
functionality of the Switch Access and TalkBack (for languages supported by
the preloaded Text-to-speech engine) accessibility services as provided in
@@ -246,7 +247,7 @@
If device implementations report the feature android.hardware.audio.output,
they:
-* [T-SR] STRONGLY RECOMMENDED to include a TTS engine supporting the
+* [T-SR] Are STRONGLY RECOMMENDED to include a TTS engine supporting the
languages available on the device.
* [T-0-1] MUST support installation of third-party TTS engines.
diff --git a/2_device-types/2_4_watch-reqs.md b/2_device-types/2_4_watch-reqs.md
index 2523460..2200f03 100644
--- a/2_device-types/2_4_watch-reqs.md
+++ b/2_device-types/2_4_watch-reqs.md
@@ -33,7 +33,7 @@
Watch device implementations:
-* [W-0-2] MUST support touchscreen input.
+* [W-0-1] MUST support touchscreen input.
**Accelerometer (Section 7.3.1)**
diff --git a/2_device-types/2_5_automotive-reqs.md b/2_device-types/2_5_automotive-reqs.md
index 65e09b8..8ef5348 100644
--- a/2_device-types/2_5_automotive-reqs.md
+++ b/2_device-types/2_5_automotive-reqs.md
@@ -29,7 +29,7 @@
* [A-0-1] MUST provide the Home function and MAY provide Back and Recent
functions.
-* [A-0-2] MUST send both the normal and long press event of the the Back
+* [A-0-2] MUST send both the normal and long press event of the Back
function
([`KEYCODE_BACK`](http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK))
to the foreground application.
@@ -147,9 +147,9 @@
Automotive device implementations MUST support the following audio encoding:
-* [A-1-1] MPEG-4 AAC Profile (AAC LC)
-* [A-1-2] MPEG-4 HE AAC Profile (AAC+)
-* [A-1-3] AAC ELD (enhanced low delay AAC)
+* [A-0-1] MPEG-4 AAC Profile (AAC LC)
+* [A-0-2] MPEG-4 HE AAC Profile (AAC+)
+* [A-0-3] AAC ELD (enhanced low delay AAC)
**Video Encoding (Section 5.2)**
@@ -172,7 +172,6 @@
* [A-SR] H.265 HEVC
-
### 2.5.3\. Software
Automotive device implementations:
diff --git a/3_software/3_12_tv-input-framework.md b/3_software/3_12_tv-input-framework.md
index 0cddf65..2e055f5 100644
--- a/3_software/3_12_tv-input-framework.md
+++ b/3_software/3_12_tv-input-framework.md
@@ -17,7 +17,7 @@
* [C-1-1] The TV App MUST provide facilities to install and use [TV Channels](
http://developer.android.com/reference/android/media/tv/TvContract.Channels.html)
-and meet the following requirements:
+and meet the following requirements.
The TV app that is required for Android device implementations declaring the
`android.software.live_tv` feature flag, MUST meet the following requirements:
@@ -74,8 +74,11 @@
#### 3.12.1.3\. TV input app linking
-Android Television device implementations SHOULD support
-[TV input app linking](http://developer.android.com/reference/android/media/tv/TvContract.Channels.html#COLUMN_APP_LINK_INTENT_URI),
+If device implementations support TIF:
+
+* [C-1-1] Android Television device implementations MUST support
+[TV input app linking](
+http://developer.android.com/reference/android/media/tv/TvContract.Channels.html#COLUMN_APP_LINK_INTENT_URI),
which allows all inputs to provide activity links from the current activity to
another activity (i.e. a link from live programming to related content). The TV
App SHOULD show TV input app linking when it is provided.
@@ -95,6 +98,8 @@
If device implementations support TIF, they:
* [SR] STRONGLY RECOMMENDED to support TV recording.
+* SHOULD provide a user interface to play recorded
+programs.
* If the TV input supports recording and the recording of a program is not
[prohibited](
https://developer.android.com/reference/android/media/tv/TvContract.Programs.html#COLUMN_RECORDING_PROHIBITED),
diff --git a/3_software/3_2_soft-api-compatibility.md b/3_software/3_2_soft-api-compatibility.md
index d0ed019..0d4a3ce 100644
--- a/3_software/3_2_soft-api-compatibility.md
+++ b/3_software/3_2_soft-api-compatibility.md
@@ -252,15 +252,15 @@
service components with an intent handler, for all the public intent filter
patterns defined by the following core android applications in AOSP:
- * Desk Clock
- * Browser
- * Calendar
- * Contacts
- * Gallery
- * GlobalSearch
- * Launcher
- * Music
- * Settings
+ * Desk Clock
+ * Browser
+ * Calendar
+ * Contacts
+ * Gallery
+ * GlobalSearch
+ * Launcher
+ * Music
+ * Settings
#### 3.2.3.2\. Intent Resolution
@@ -294,8 +294,8 @@
as implemented by the Package Manager in the upstream Android Open Source
Project.
* [C-0-5] MUST attempt validation of the intent filters during the installation of
-the application and set all successfully validated UIR intent filters as
-default app handlers for their UIRs.
+the application and set all successfully validated URI intent filters as
+default app handlers for their URIs.
* MAY set specific URI intent filters as default app handlers for their URIs,
if they are successfully verified but other candidate URI filters fail
verification. If a device implementation does this, it MUST provide the
diff --git a/3_software/3_3_native-api-compatibility.md b/3_software/3_3_native-api-compatibility.md
index cf88710..b6b7e43 100644
--- a/3_software/3_3_native-api-compatibility.md
+++ b/3_software/3_3_native-api-compatibility.md
@@ -1,7 +1,5 @@
## 3.3\. Native API Compatibility
-Device implementers are:
-
Native code compatibility is challenging. For this reason,
device implementers are:
@@ -117,4 +115,4 @@
highest supported ARM architecture (e.g., "8" for ARMv8 devices).
* SHOULD not alter `/proc/cpuinfo` when read by 64-bit ARM or non-ARM
- applications.
\ No newline at end of file
+ applications.
diff --git a/3_software/3_8_user-interface-compatibility.md b/3_software/3_8_user-interface-compatibility.md
index 23ee0b4..b2a15aa 100644
--- a/3_software/3_8_user-interface-compatibility.md
+++ b/3_software/3_8_user-interface-compatibility.md
@@ -260,7 +260,7 @@
in [section 7.2.3](#7_2_3_navigation_keys) MUST launch the user-selected
assist app, in other words the app that implements `VoiceInteractionService`,
or an activity handling the `ACTION_ASSIST` intent.
-* [SR] STRONGLY RECOMMENDED to use long press on `HOME` key as this designated
+* [C-SR] STRONGLY RECOMMENDED to use long press on `HOME` key as this designated
interaction.
### 3.8.5\. Alerts and Toasts
@@ -381,7 +381,6 @@
* SHOULD trigger the split-screen multiwindow-mode, if supported, when the
recents functions key is long pressed.
* MAY display affiliated recents as a group that moves together.
-
* [SR] Are STRONGLY RECOMMENDED to use the upstream Android user
interface (or a similar thumbnail-based interface) for the overview screen.
@@ -450,10 +449,10 @@
* [C-1-1] MUST be capable of rendering these emoji characters in color glyph.
* [C-1-2] MUST include support for:
- * Roboto 2 font with different weights—sans-serif-thin, sans-serif-light,
+ * Roboto 2 font with different weights—sans-serif-thin, sans-serif-light,
sans-serif-medium, sans-serif-black, sans-serif-condensed,
sans-serif-condensed-light for the languages available on the device.
- * Full Unicode 7.0 coverage of Latin, Greek, and Cyrillic, including the
+ * Full Unicode 7.0 coverage of Latin, Greek, and Cyrillic, including the
Latin Extended A, B, C, and D ranges, and all glyphs in the currency
symbols block of Unicode 7.0.
* SHOULD support the skin tone and diverse family emojis as specified in the
@@ -485,7 +484,7 @@
multi-window mode, but the system MUST provide warning that the app may not
work as expected in multi-window mode.
* [C-1-3] MUST NOT offer split-screen or freeform mode if
- the screen height < 440 dp and the the screen width < 440 dp.
+ the screen height < 440 dp and the screen width < 440 dp.
* Device implementations with screen size `xlarge` SHOULD support freeform
mode.
diff --git a/3_software/3_9_device-administration.md b/3_software/3_9_device-administration.md
index 6310bdf..eb50d95 100644
--- a/3_software/3_9_device-administration.md
+++ b/3_software/3_9_device-administration.md
@@ -29,8 +29,8 @@
* [C-1-1] MUST support enrolling a Device Policy Client (DPC) as a
[Device Owner app](
http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp%28java.lang.String%29)
- as described below:.
- * when the device implementation has no user data is configured yet, it:
+ as described below:
+ * When the device implementation has no user data is configured yet, it:
* [C-1-3] MUST report `true` for [`DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE)`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html\#isProvisioningAllowed\(java.lang.String\)).
* [C-1-4] MUST enroll the DPC application as the Device Owner app in
response to the intent action [`android.app.action.PROVISION_MANAGED_DEVICE`](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_DEVICE).
diff --git a/4_application-packaging/4_0_intro.md b/4_application-packaging/4_0_intro.md
index 4285e9c..1a25035 100644
--- a/4_application-packaging/4_0_intro.md
+++ b/4_application-packaging/4_0_intro.md
@@ -31,20 +31,25 @@
https://developer.android.com/reference/android/os/storage/StorageManager.html#ACTION_MANAGE_STORAGE)
intent.
-Device implementations MUST NOT install application packages from unknown
+* [C-0-5] MUST have an activity that handles the
+[`android.settings.MANAGE_UNKNOWN_APP_SOURCES`](http://developer.android.com/reference/android/provider/Settings.html#ACTION_MANAGE_UNKNOWN_APP_SOURCES)
+intent.
+
+* [C-0-6] MUST NOT install application packages from unknown
sources, unless the app that [requests the installation](https://developer.android.com/reference/android/content/Intent.html#ACTION_INSTALL_PACKAGE)
meets all the following requirements:
-* It MUST declare the [`REQUEST_INSTALL_PACKAGES`](http://developer.android.com/reference/android/Manifest.permission.html#REQUEST_INSTALL_PACKAGES)
+ * It MUST declare the [`REQUEST_INSTALL_PACKAGES`](http://developer.android.com/reference/android/Manifest.permission.html#REQUEST_INSTALL_PACKAGES)
permission or have the `android:targetSdkVersion` set at 24 or lower.
-* It MUST have been granted permission by the user to install apps from
+ * It MUST have been granted permission by the user to install apps from
unknown sources.
-Device implementations MUST have an activity that handles the
-[`android.settings.MANAGE_UNKNOWN_APP_SOURCES`](http://developer.android.com/reference/android/provider/Settings.html#ACTION_MANAGE_UNKNOWN_APP_SOURCES)
-intent. They SHOULD provide a user affordance to grant/revoke the permission to
+* SHOULD provide a user affordance to grant/revoke the permission to
install apps from unknown sources per application, but MAY choose to implement
-this as a no-op and return `RESULT_CANCELED` for [`startActivityForResult()`](http://developer.android.com/reference/android/app/Activity.html#startActivityForResult%28android.content.Intent, int%29),
+this as a no-op and return `RESULT_CANCELED` for
+[`startActivityForResult()`](http://developer.android.com/reference/android/app/Activity.html#startActivityForResult%28android.content.Intent,
+int%29),
if the device implementation does not want to allow users to have this choice.
-However even in such cases, they SHOULD indicate to the user why there is no such
+However, even in such cases, they SHOULD indicate to the user why there is no
+such
choice presented.
diff --git a/5_multimedia/5_1_media-codecs.md b/5_multimedia/5_1_media-codecs.md
index c8d569c..3b61db4 100644
--- a/5_multimedia/5_1_media-codecs.md
+++ b/5_multimedia/5_1_media-codecs.md
@@ -16,7 +16,8 @@
If device implementations declare support for the
-`android.hardware.audio.output` feature, they:
+`android.hardware.audio.output` feature, they must support the following audio
+decoders:
* [C-1-1] MPEG-4 AAC Profile (AAC LC)
* [C-1-2] MPEG-4 HE AAC Profile (AAC+)
diff --git a/5_multimedia/5_3_video-decoding.md b/5_multimedia/5_3_video-decoding.md
index 0d09bab..30adfe2 100644
--- a/5_multimedia/5_3_video-decoding.md
+++ b/5_multimedia/5_3_video-decoding.md
@@ -51,9 +51,9 @@
If the height that is reported by the `Display.getSupportedModes()` method is
equal or greater than the video resolution, device implementations:
-* [C-2-1] MUST support the HD 720p video encoding profiles in the following
+* [C-2-1] MUST support the HD 720p video decoding profiles in the following
table.
-* [C-2-2] MUST support the HD 1080p video encoding profiles in the following
+* [C-2-2] MUST support the HD 1080p video decoding profiles in the following
table.
@@ -202,7 +202,7 @@
If device implementations support VP9 codec and a hardware decoder:
-* [C-2-2] MUST support the HD decoding profiles as indicated in the following
+* [C-2-1] MUST support the HD decoding profiles as indicated in the following
table.
If the height that is reported by the `Display.getSupportedModes()` method is
diff --git a/5_multimedia/5_4_audio-recording.md b/5_multimedia/5_4_audio-recording.md
index c208ff6..6c09e6a 100644
--- a/5_multimedia/5_4_audio-recording.md
+++ b/5_multimedia/5_4_audio-recording.md
@@ -14,9 +14,9 @@
* [C-1-1] MUST allow capture of raw audio content with the following
characteristics:
- * **Format**: Linear PCM, 16-bit
- * **Sampling rates**: 8000, 11025, 16000, 44100 Hz
- * **Channels**: Mono
+ * **Format**: Linear PCM, 16-bit
+ * **Sampling rates**: 8000, 11025, 16000, 44100 Hz
+ * **Channels**: Mono
* [C-1-2] MUST capture at above sample rates without up-sampling.
* [C-1-3] MUST include an appropriate anti-aliasing filter when the
@@ -24,9 +24,9 @@
* SHOULD allow AM radio and DVD quality capture of raw audio content, which
means the following characteristics:
- * **Format**: Linear PCM, 16-bit
- * **Sampling rates**: 22050, 48000 Hz
- * **Channels**: Stereo
+ * **Format**: Linear PCM, 16-bit
+ * **Sampling rates**: 22050, 48000 Hz
+ * **Channels**: Stereo
If device implementations allow AM radio and DVD quality capture of raw audio
content, they:
diff --git a/5_multimedia/5_7_network-protocols.md b/5_multimedia/5_7_network-protocols.md
index bc1260e..191c286 100644
--- a/5_multimedia/5_7_network-protocols.md
+++ b/5_multimedia/5_7_network-protocols.md
@@ -18,7 +18,7 @@
codecs in the RTSP table below. For exceptions please see the table footnotes
in [section 5.1](#5_1_media_codecs).
-Media Segment Formats
+**Media Segment Formats**
<table>
@@ -63,7 +63,7 @@
</table>
-RTSP (RTP, SDP)
+**RTSP (RTP, SDP)**
<table>
<tr>
diff --git a/7_hardware-compatibility/7_1_display-and-graphics.md b/7_hardware-compatibility/7_1_display-and-graphics.md
index ece4f9f..853ba1b 100644
--- a/7_hardware-compatibility/7_1_display-and-graphics.md
+++ b/7_hardware-compatibility/7_1_display-and-graphics.md
@@ -72,7 +72,7 @@
* The app declares it is resizeable via the [android:resizeableActivity](
https://developer.android.com/guide/topics/ui/multi-window.html#configuring)
attribute.
- * The app is targeting API level 26 or higher and does not declare a
+ * The app is targeting API level 24 or higher and does not declare a
[`android:MaxAspectRatio`](
https://developer.android.com/reference/android/R.attr.html#maxAspectRatio)
that would restrict the allowed aspect ratio.
@@ -307,14 +307,16 @@
Android includes a TextureView object that lets developers directly integrate
hardware-accelerated OpenGL ES textures as rendering targets in a UI hierarchy.
+Device implementations:
+
* [C-0-3] MUST support the TextureView API, and MUST exhibit
consistent behavior with the upstream Android implementation.
#### 7.1.4.5 Wide-gamut Displays
If device implementations claim support for wide-gamut displays through
-[`Display.isWideColorGamut()`
-](https://developer.android.com/reference/android/view/Display.html#isWideColorGamut%28%29)
+[`Configuration.isScreenWideColorGamut()`
+](https://developer.android.com/reference/android/content/res/Configuration.html#isScreenWideColorGamut%28%29)
, they:
* [C-1-1] MUST have a color-calibrated display.
diff --git a/7_hardware-compatibility/7_3_sensors.md b/7_hardware-compatibility/7_3_sensors.md
index bf22f3e..8da2e19 100644
--- a/7_hardware-compatibility/7_3_sensors.md
+++ b/7_hardware-compatibility/7_3_sensors.md
@@ -42,7 +42,7 @@
upgrade to the future platform releases where this might become a REQUIRED
component. The synchronization error SHOULD be below 100 milliseconds.
-* [C-1-7] For any API indicated by the Android SDK documentation to be a
+* [C-1-4] For any API indicated by the Android SDK documentation to be a
[continuous sensor](
https://source.android.com/devices/sensors/report-modes.html#continuous),
device implementations MUST continuously provide
@@ -50,7 +50,7 @@
where jitter is defined as the standard deviation of the difference of the
reported timestamp values between consecutive events.
-* [C-1-8] MUST ensure that the sensor event stream
+* [C-1-5] MUST ensure that the sensor event stream
MUST NOT prevent the device CPU from entering a suspend state or waking up
from a suspend state.
* When several sensors are activated, the power consumption SHOULD NOT exceed
diff --git a/7_hardware-compatibility/7_4_data-connectivity.md b/7_hardware-compatibility/7_4_data-connectivity.md
index 403e2c4..080170d 100644
--- a/7_hardware-compatibility/7_4_data-connectivity.md
+++ b/7_hardware-compatibility/7_4_data-connectivity.md
@@ -77,9 +77,9 @@
* SHOULD include support for one or more forms of 802.11\.
If device implementations include support for 802.11 and expose the
-functionality to a third-party application, they
+functionality to a third-party application, they:
-* [C-1-1] MUST implement the corresponding Android API.
+* [C-1-1] MUST implement the corresponding Andr:oid API.
* [C-1-2] MUST report the hardware feature flag `android.hardware.wifi`.
* [C-1-3] MUST implement the [multicast API](
http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html)
@@ -250,11 +250,11 @@
* [C-1-2] MUST be capable of acting as an NFC Forum reader/writer
(as defined by the NFC Forum technical specification
NFCForum-TS-DigitalProtocol-1.0) via the following NFC standards:
- * NfcA (ISO14443-3A)
- * NfcB (ISO14443-3B)
- * NfcF (JIS X 6319-4)
- * IsoDep (ISO 14443-4)
- * NFC Forum Tag Types 1, 2, 3, 4, 5 (defined by the NFC Forum)
+ * NfcA (ISO14443-3A)
+ * NfcB (ISO14443-3B)
+ * NfcF (JIS X 6319-4)
+ * IsoDep (ISO 14443-4)
+ * NFC Forum Tag Types 1, 2, 3, 4, 5 (defined by the NFC Forum)
* [SR] STRONGLY RECOMMENDED to be capable of reading and writing NDEF
messages as well as raw data via the following NFC standards. Note that
while the NFC standards are stated as STRONGLY RECOMMENDED, the
@@ -266,12 +266,12 @@
* [C-1-3] MUST be capable of transmitting and receiving data via the
following peer-to-peer standards and protocols:
- * ISO 18092
- * LLCP 1.2 (defined by the NFC Forum)
- * SDP 1.0 (defined by the NFC Forum)
- * [NDEF Push Protocol](
- http://static.googleusercontent.com/media/source.android.com/en/us/compatibility/ndef-push-protocol.pdf)
- * SNEP 1.0 (defined by the NFC Forum)
+ * ISO 18092
+ * LLCP 1.2 (defined by the NFC Forum)
+ * SDP 1.0 (defined by the NFC Forum)
+ * [NDEF Push Protocol](
+ http://static.googleusercontent.com/media/source.android.com/en/us/compatibility/ndef-push-protocol.pdf)
+ * SNEP 1.0 (defined by the NFC Forum)
* [C-1-4] MUST include support for [Android Beam](
http://developer.android.com/guide/topics/connectivity/nfc/nfc.html) and
SHOULD enable Android Beam by default.
@@ -338,8 +338,8 @@
for NfcF, and implement the feature for third-party applications, they:
* [C-3-1] MUST report the `android.hardware.nfc.hcef` feature constant.
-* [C-3-2] MUST implement the [NfcF Card Emulation APIs]
-(https://developer.android.com/reference/android/nfc/cardemulation/NfcFCardEmulation.html)
+* [C-3-2] MUST implement the [NfcF Card Emulation APIs](
+https://developer.android.com/reference/android/nfc/cardemulation/NfcFCardEmulation.html)
as defined in the Android SDK.
diff --git a/7_hardware-compatibility/7_5_cameras.md b/7_hardware-compatibility/7_5_cameras.md
index 49913aa..570a8ae 100644
--- a/7_hardware-compatibility/7_5_cameras.md
+++ b/7_hardware-compatibility/7_5_cameras.md
@@ -28,7 +28,7 @@
* MAY have fixed-focus or EDOF (extended depth of field) hardware.
* MAY include a flash.
-If the Camera includes a flash:
+If the camera includes a flash:
* [C-2-1] the flash lamp MUST NOT be lit while an
`android.hardware.Camera.PreviewCallback` instance has been registered
@@ -46,7 +46,7 @@
Device implementations:
-* MAY include a front-facing camera
+* MAY include a front-facing camera.
If device implementations include at least one front-facing camera, they:
@@ -56,21 +56,21 @@
* [C-1-3] MUST NOT use a front-facing camera as the default for the
Camera API and MUST NOT configure the API to treat a front-facing camera as
the default rear-facing camera, even if it is the only camera on the device.
-* [C-1-5] The camera preview MUST be mirrored horizontally relative to the
+* [C-1-4] The camera preview MUST be mirrored horizontally relative to the
orientation specified by the application when the current application has
explicitly requested that the Camera
display be rotated via a call to the
[`android.hardware.Camera.setDisplayOrientation()`](
http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int))
method. Conversely, the preview MUST be mirrored along the device’s default
-horizontal axis when the the current application does not explicitly request
+horizontal axis when the current application does not explicitly request
that the Camera display be rotated via a call to the
[`android.hardware.Camera.setDisplayOrientation()`](
http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int))
method.
-* [C-1-6] MUST NOT mirror the final captured still image or video streams
+* [C-1-5] MUST NOT mirror the final captured still image or video streams
returned to application callbacks or committed to media storage.
-* [C-1-7] MUST mirror the image displayed by the postview in the same manner
+* [C-1-6] MUST mirror the image displayed by the postview in the same manner
as the camera preview image stream.
* MAY include features (such as auto-focus, flash, etc.) available to
rear-facing cameras as described in [section 7.5.1](#7_5_1_rear-facing_camera).
@@ -99,7 +99,11 @@
high-quality unencoded streams (i.e. raw or independently compressed picture
streams).
* MAY support multiple cameras.
-* MAY support camera-based video encoding. If supported, a simultaneous
+* MAY support camera-based video encoding.
+
+If camera-based video encoding is supported:
+
+* [C-2-1] A simultaneous
unencoded / MJPEG stream (QVGA or greater resolution) MUST be accessible to
the device implementation.
diff --git a/7_hardware-compatibility/7_6_memory-and-storage.md b/7_hardware-compatibility/7_6_memory-and-storage.md
index c4f8fab..fa5998d 100644
--- a/7_hardware-compatibility/7_6_memory-and-storage.md
+++ b/7_hardware-compatibility/7_6_memory-and-storage.md
@@ -28,10 +28,11 @@
permission on this shared storage as documented in the SDK. Shared storage
MUST otherwise be writable by any application that obtains that permission.
-Device implementations MAY meet the above requirements using either:
+Device implementations MAY meet the above requirements using either of the
+following:
-* a user-accessible removable storage, such as a Secure Digital (SD) card slot.
-* a portion of the internal (non-removable) storage as implemented in the
+* User-accessible removable storage, such as a Secure Digital (SD) card slot.
+* A portion of the internal (non-removable) storage as implemented in the
Android Open Source Project (AOSP).
If device implementations use removable storage to satisfy the above
@@ -53,7 +54,7 @@
If device implementations include multiple shared storage paths (such
as both an SD card slot and shared internal storage), they:
-* [C-3-1] MUST allow only pre-installed and privileged Android
+* [C-2-1] MUST allow only pre-installed and privileged Android
applications with the `WRITE_EXTERNAL_STORAGE` permission to
write to the secondary external storage, except when writing to their
package-specific directories or within the `URI` returned by firing the
diff --git a/7_hardware-compatibility/7_7_usb.md b/7_hardware-compatibility/7_7_usb.md
index 77f3b82..20c1be6 100644
--- a/7_hardware-compatibility/7_7_usb.md
+++ b/7_hardware-compatibility/7_7_usb.md
@@ -88,7 +88,7 @@
If device implementations include a USB port supporting host mode and the USB
audio class, they:
-* [C-2-1] MUST support the [USB HID class](https://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_HID)
+* [C-2-1] MUST support the [USB HID class](https://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_HID).
* [C-2-2] MUST support the detection and mapping of the following HID data
fields specified in the [USB HID Usage Tables](http://www.usb.org/developers/hidpage/Hut1_12v2.pdf)
and the [Voice Command Usage Request](http://www.usb.org/developers/hidpage/Voice_Command_Usage.pdf)
diff --git a/7_hardware-compatibility/7_8_audio.md b/7_hardware-compatibility/7_8_audio.md
index 80c9860..84c08b7 100644
--- a/7_hardware-compatibility/7_8_audio.md
+++ b/7_hardware-compatibility/7_8_audio.md
@@ -9,7 +9,7 @@
[section 5.4](#5_4_audio_recording).
* [C-1-3] MUST meet the audio latency requirements in
[section 5.6](#5_6_audio_latency).
-* [SR] STRONGLY RECOMMENDED to support near-ultrasound recording as described
+* [SR] Are STRONGLY RECOMMENDED to support near-ultrasound recording as described
in [section 7.8.3](#7_8_3_near_ultrasound).
If device implementations omit a microphone, they:
diff --git a/7_hardware-compatibility/7_9_virtual-reality.md b/7_hardware-compatibility/7_9_virtual-reality.md
index c33c8af..1a8b632 100644
--- a/7_hardware-compatibility/7_9_virtual-reality.md
+++ b/7_hardware-compatibility/7_9_virtual-reality.md
@@ -89,7 +89,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.
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 6f0d676..a1799a4 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 94763d8..8a14713 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.
@@ -94,7 +96,7 @@
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
+* [C-1-5] MUST NOT send encryption key off the device
(even when wrapped with the user passcode and/or hardware bound key).
The upstream Android Open Source project provides a preferred implementation
diff --git a/source/android-cdd-cover.html b/source/android-cdd-cover.html
index fbc7256..946cda0 100644
--- a/source/android-cdd-cover.html
+++ b/source/android-cdd-cover.html
@@ -1,6 +1,6 @@
<!DOCTYPE html>
<head>
-<title>Android 7.0 Compatibility Definition</title>
+<title>Android 8.0 Compatibility Definition</title>
<link rel="stylesheet" type="text/css" href="android-cdd-cover.css"/>
</head>
@@ -27,7 +27,6 @@
<p class="subtitle">Android 8.0</p>
<p class="cover-text">Last updated: September 1, 2017</p>
<p class="cover-text">Copyright © 2017, Google Inc. All rights reserved.</p>
-<p class="cover-text"><a href="mailto:compatibility@android.com">compatibility@android.com</a></p>
</td>
</tr>