Merge "Docs: Add new cover art and cover text for 8.0 CDD." into oc-dev
diff --git a/2_device-types/2_1_device-configurations.md b/2_device-types/2_1_device-configurations.md
index 883d049..6b04ddd 100644
--- a/2_device-types/2_1_device-configurations.md
+++ b/2_device-types/2_1_device-configurations.md
@@ -1,132 +1,4 @@
## 2.1 Device Configurations
-This is a summary of major differences in hardware configuration by device
-type. (Empty cells denote a “MAY”). Not all configurations are covered in this
-table; see relevant hardware sections for more detail.
-
-<table>
- <tr>
- <th>Category</th>
- <th>Feature</th>
- <th>Section</th>
- <th>Handheld</th>
- <th>Television</th>
- <th>Watch</th>
- <th>Automotive</th>
- <th>Other</th>
- </tr>
- <tr>
- <td rowspan="3">Input</td>
- <td>D-pad</td>
- <td><a href="#7_2_2_non-touch-navigation">7.2.2. Non-touch Navigation</a></td>
- <td></td>
- <td>MUST</td>
- <td></td>
- <td></td>
- <td></td>
- </tr>
- <tr>
- <td>Touchscreen </td>
- <td><a href="#7_2_4_touchscreen_input">7.2.4. Touchscreen input</a></td>
- <td>MUST</td>
- <td></td>
- <td>MUST</td>
- <td></td>
- <td>SHOULD</td>
- </tr>
- <tr>
- <td>Microphone </td>
- <td><a href="#7_8_1_microphone">7.8.1. Microphone</a></td>
- <td>MUST</td>
- <td>SHOULD </td>
- <td>MUST</td>
- <td>MUST</td>
- <td>SHOULD</td>
- </tr>
- <tr>
- <td rowspan="2">Sensors</td>
- <td>Accelerometer </td>
- <td><a href="#7_3_1_accelerometer">7.3.1 Accelerometer</a></td>
- <td>SHOULD</td>
- <td></td>
- <td>SHOULD</td>
- <td></td>
- <td>SHOULD</td>
- </tr>
- <tr>
- <td>GPS</td>
- <td><a href="#7_3_3_gps">7.3.3. GPS</a></td>
- <td>SHOULD</td>
- <td></td>
- <td></td>
- <td>SHOULD</td>
- <td></td>
- </tr>
- <tr>
- <td rowspan="5">Connectivity</td>
- <td>Wi-Fi</td>
- <td><a href="#7_4_2_ieee_802.11">7.4.2. IEEE 802.11</a></td>
- <td>SHOULD</td>
- <td>SHOULD</td>
- <td></td>
- <td>SHOULD</td>
- <td>SHOULD</td>
- </tr>
- <tr>
- <td>Wi-Fi Direct</td>
- <td><a href="#7_4_2_1_wi-fi-direct">7.4.2.1. Wi-Fi Direct</a></td>
- <td>SHOULD</td>
- <td>SHOULD</td>
- <td></td>
- <td></td>
- <td>SHOULD</td>
- </tr>
- <tr>
- <td>Bluetooth</td>
- <td><a href="#7_4_3_bluetooth">7.4.3. Bluetooth</a></td>
- <td>SHOULD</td>
- <td>MUST</td>
- <td>MUST</td>
- <td>MUST</td>
- <td>SHOULD</td>
- </tr>
- <tr>
- <td>Bluetooth Low Energy</td>
- <td><a href="#7_4_3_bluetooth">7.4.3. Bluetooth</a></td>
- <td>SHOULD</td>
- <td>MUST</td>
- <td>SHOULD</td>
- <td>SHOULD</td>
- <td>SHOULD</td>
- </tr>
- <tr>
- <td>Cellular radio</td>
- <td><a href="#7_4_5_minimum_network_capability">
- 7.4.5. Minimum Network Capability</a></td>
- <td></td>
- <td></td>
- <td></td>
- <td>SHOULD</td>
- <td></td>
- </tr>
- <tr>
- <td>USB</td>
- <td>USB peripheral/host mode</td>
- <td><a href="#7_7_usb">7.7. USB</a></td>
- <td>SHOULD</td>
- <td></td>
- <td></td>
- <td>SHOULD</td>
- <td>SHOULD</td>
- </tr>
- <tr>
- <td>Output</td>
- <td>Speaker and/or Audio output ports</td>
- <td><a href="#7_8_2_audio_output">7.8.2. Audio Output</a></td>
- <td>MUST</td>
- <td>MUST</td>
- <td></td>
- <td>MUST</td>
- <td>MUST</td>
- </tr>
-</table>
+For the major differences in hardware configuration by device
+type, see the device-specific requirements that follow in this section.
diff --git a/2_device-types/2_2_handheld-reqs.md b/2_device-types/2_2_handheld-reqs.md
index 871375f..104fb97 100644
--- a/2_device-types/2_2_handheld-reqs.md
+++ b/2_device-types/2_2_handheld-reqs.md
@@ -13,51 +13,301 @@
The additional requirements in the rest of this section are specific to Android
Handheld device implementations.
+
+<div class="note">
+<b>Note:</b> Requirements that do not apply to Android Tablet devices are marked with an *.
+</div>
+
### 2.2.1\. Hardware
+**Screen Size (Section 7.1.1.1)**
+
+Handheld device implementations:
+
+* [H-0-1] MUST have a screen at least 2.5 inches in physical diagonal size.<sup>*</sup>
+
+**Screen Density (Section 7.1.1.3)**
+
+Handheld device implementations:
+
+* [H-SR] Are STRONGLY RECOMMENDED to provide users an affordance to change
+ the display size.
+
+**Legacy Application Compatibility Mode (Section 7.1.5)**
+
+Handheld device implementations:
+
+* [H-0-1] MUST include support for legacy application compatibility mode as
+ implemented by the upstream Android open source code. That is, device
+ implementations MUST NOT alter the triggers or thresholds at which
+ compatibility mode is activated, and MUST NOT alter the behavior of the
+ compatibility mode itself.
+
+**Keyboard (Section 7.2.1)**
+
+Handheld device implementations:
+
+* [H-0-1] MUST include support for third-party Input Method Editor (IME)
+ applications.
+
+**Navigation Keys (Section 7.2.3)**
+
+Handheld device implementations:
+
+* [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
+ function ([`KEYCODE_BACK`](http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK))
+ to the foreground application.
+
**Touchscreen Input (Section 7.2.4)**
-* [H-0-1] Handheld devices MUST have a touchscreen embedded in the device.
+Handheld device implementations:
-More to be added.
+* [H-0-1] MUST support touchscreen input.
+
+**Accelerometer (Section 7.3.1)**
+
+Handheld device implementations:
+
+* [H-SR] Are STRONGLY RECOMMENDED to include a 3-axis accelerometer.
+
+If Handheld device implementations include a 3-axis accelerometer, they:
+
+* [H-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
+
+**Gyroscope (Section 7.3.4)**
+
+If Handheld device implementations include a gyroscope, they:
+
+* [H-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
+
+**Proximity Sensor (Section 7.3.8 )**
+
+Handheld device implementations that can make a voice call and indicate
+any value other than `PHONE_TYPE_NONE` in `getPhoneType`:
+
+* SHOULD include a proximity sensor.
+
+**Pose Sensor (Section 7.3.12)**
+
+Handheld device implementations:
+
+* Are RECOMMENDED to support pose sensor with 6 degrees of freedom.
+
+**Bluetooth (Section 7.4.3)**
+
+Handheld device implementations:
+
+ * SHOULD include support for Bluetooth and Bluetooth LE.
+
+**Data Saver (Section 7.4.7)**
+
+If Handheld device implementations include a metered connection, they:
+
+* [H-1-1] MUST provide the data saver mode.
+
+**Minimum Memory and Storage (Section 7.6.1)**
+
+Handheld device implementations:
+
+* [H-0-1] MUST have at least 4GB of non-volatile storage available for
+ application private data (a.k.a. "/data" partition)
+* [H-0-2] MUST return “true” for `ActivityManager.isLowRamDevice()` when there
+ is less than 1GB of memory available to the kernel and userspace.
+
+
+If Handheld device implementations are 32-bit:
+
+* [H-1-1] The memory available to the kernel and userspace MUST
+be at least 512MB if any of the following densities are used:
+ * 280dpi or lower on small/normal screens<sup>*</sup>
+ * ldpi or lower on extra large screens
+ * mdpi or lower on large screens
+
+* [H-2-1] The memory available to the kernel and userspace MUST
+be at least 608MB if any of the following densities are used:
+ * xhdpi or higher on small/normal screens<sup>*</sup>
+ * hdpi or higher on large screens
+ * mdpi or higher on extra large screens
+
+* [H-3-1] The memory available to the kernel and userspace MUST
+be at least 896MB if any of the following densities are used:
+ * 400dpi or higher on small/normal screens<sup>*</sup>
+ * xhdpi or higher on large screens
+ * tvdpi or higher on extra large screens
+
+* [H-4-1] The memory available to the kernel and userspace MUST
+be at least 1344MB if any of the following densities are used:
+ * 560dpi or higher on small/normal screens<sup>*</sup>
+ * 400dpi or higher on large screens
+ * xhdpi or higher on extra large screens
+
+If Handheld device implementations are 64-bit:
+
+* [H-5-1] The memory available to the kernel and userspace MUST
+be at least 816MB if any of the following densities are used:
+ * 280dpi or lower on small/normal screens<sup>*</sup>
+ * ldpi or lower on extra large screens
+ * mdpi or lower on large screens
+
+* [H-6-1] The memory available to the kernel and userspace MUST
+be at least 944MB if any of the following densities are used:
+ * xhdpi or higher on small/normal screens<sup>*</sup>
+ * hdpi or higher on large screens
+ * mdpi or higher on extra large screens
+
+* [H-7-1] The memory available to the kernel and userspace MUST
+be at least 1280MB if any of the following densities are used:
+ * 400dpi or higher on small/normal screens<sup>*</sup>
+ * xhdpi or higher on large screens
+ * tvdpi or higher on extra large screens
+
+* [H-8-1] The memory available to the kernel and userspace MUST
+be at least 1824MB if any of the following densities are used:
+ * 560dpi or higher on small/normal screens<sup>*</sup>
+ * 400dpi or higher on large screens
+ * xhdpi or higher on extra large screens
+
+Note that the "memory available to the kernel and userspace" above refers to the
+memory space provided in addition to any memory already dedicated to hardware
+components such as radio, video, and so on that are not under the kernel’s
+control on device implementations.
+
+**Application Shared Storage (Section 7.6.2)**
+
+Handheld device implementations:
+
+* [H-0-1] MUST NOT provide an application shared storage smaller than 1 GiB.
+
+**USB peripheral mode (Section 7.7.1)**
+
+Handheld device implementations:
+
+* SHOULD include a USB port supporting peripheral mode.
+
+If handheld device implementations include a USB port supporting peripheral
+mode, they:
+
+* [H-1-1] MUST implement the Android Open Accessory (AOA) API.<sup>*</sup>
+
+**Microphone (Section 7.8.1)**
+
+Handheld device implementations:
+
+* [H-0-1] MUST include a microphone.
+
+**Audio Output (Section 7.8.2)**
+
+Handheld device implementations:
+
+* [H-0-1] MUST have an audio output and declare
+ `android.hardware.audio.output`.
+
+**Virtual Reality Mode (Section 7.9.1)**
+
+If Handheld device implementations include support for the VR mode, they:
+
+* [H-1-1] MUST declare the `android.software.vr.mode` feature.<sup>*</sup>
+
+
+If device implementations declare `android.software.vr.mode` feature, they:
+
+* [H-2-1] MUST include an application implementing
+`android.service.vr.VrListenerService`
+that can be enabled by VR applications via
+`android.app.Activity#setVrModeEnabled`.<sup>*</sup>
+
+
+**Virtual Reality High Performance (Section 7.9.2)**
+
+If Handheld device implementations are capable of meeting all the requirements
+to declare the `android.hardware.vr.high_performance` feature flag, they:
+
+* [H-1-1] MUST declare the `android.hardware.vr.high_performance`
+feature flag.<sup>*</sup>
+
### 2.2.2\. Multimedia
-To be added.
+**Audio Encoding (Section 5.1.1)**
+
+Handheld device implementations MUST support the following audio encoding:
+
+* [H-0-1] AMR-NB
+* [H-0-2] AMR-WB
+* [H-0-3] MPEG-4 AAC Profile (AAC LC)
+* [H-0-4] MPEG-4 HE AAC Profile (AAC+)
+* [H-0-5] AAC ELD (enhanced low delay AAC)
+
+
+**Audio Decoding (Section 5.1.2)**
+
+Handheld device implementations MUST support the following audio decoding:
+
+* [H-0-1] AMR-NB
+* [H-0-2] AMR-WB
+
+**Video Encoding (Section 5.2)**
+
+Handheld device implementations MUST support the following video encoding and
+make it available to third-party applications:
+
+* [H-0-1] H.264 AVC
+* [H-0-2] VP8
+
+**Video Decoding (Section 5.3)**
+
+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.
### 2.2.3\. Software
**WebView Compatibility (Section 3.4.1)**
-* [H-0-1] Handheld devices MUST provide a complete implementation of the android.webkit.Webview API.
+Handheld device implementations:
+
+* [H-0-1] MUST provide a complete implementation of the
+ `android.webkit.Webview` API.
**Browser Compatibility (Section 3.4.2)**
-* [H-0-1] Handheled device implementations MUST include a standalone Browser application for general
+Handheld device implementations:
+
+* [H-0-1] MUST include a standalone Browser application for general
user web browsing.
**Launcher (Section 3.8.1)**
-* [H-SR] Handheld device implementations are STRONGLY RECOMMENDED to implement a default launcher
+Handheld device implementations:
+
+* [H-SR] Are STRONGLY RECOMMENDED to implement a default launcher
that supports in-app pinning of shortcuts and widgets.
-* [H-SR] Device implementations are STRONGLY RECOMMENDED to implement a default launcher that
+* [H-SR] Are STRONGLY RECOMMENDED to implement a default launcher that
provides quick access to the additional shortcuts provided by third-party apps through the
[ShortcutManager](
https://developer.android.com/reference/android/content/pm/ShortcutManager.html) API.
-* [H-SR] Handheld devices are STRONGLY RECOMMENDED to include a default
+* [H-SR] Are STRONGLY RECOMMENDED to include a default
launcher app that shows badges for the app icons.
**Widgets (Section 3.8.2)**
-* [H-SR] Handheld Device implementations are STRONGLY RECOMMENDED to support
+Handheld device implementations:
+
+* [H-SR] Are STRONGLY RECOMMENDED to support
third-party app widgets.
**Notifications (Section 3.8.3)**
-Android Handheld device implementations:
+Handheld device implementations:
* [H-0-1] MUST allow third-party apps to notify users
of notable events through the [`Notification`](
@@ -74,8 +324,10 @@
**Search (Section 3.8.4)**
-* [H-SR] Handheld device implementations are STRONGLY RECOMMENDED to implement
- an assistant on the device to handle the [Assist action](
+Handheld device implementations:
+
+* [H-SR] Are STRONGLY RECOMMENDED to implement an assistant on the device to
+ handle the [Assist action](
http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST).
**Lock Screen Media Control (Section 3.8.10)**
@@ -94,32 +346,110 @@
**Accessibility (Section 3.10)**
-* [H-SR] Android Handheld device implementations MUST support third-party
- accessibility services.
+Handheld device implementations:
-* [H-SR] Android Handheld device implementations 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
- the [talkback open source project](https://github.com/google/talkback).
+* [H-SR] 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
+ TalkBack (for languages supported by the preloaded Text-to-speech engine)
+ accessibility services as provided in the [talkback open source
+ project](https://github.com/google/talkback).
**Text-to-Speech (Section 3.11)**
-Android handheld device implementations:
-
-* [H-SR] STRONGLY RECOMMENDED to include a TTS engine supporting the
- languages available on the device.
+Handheld device implementations:
* [H-0-1] MUST support installation of third-party TTS engines.
+* [H-SR] Are STRONGLY RECOMMENDED to include a TTS engine supporting the
+ languages available on the device.
+
**Quick Settings (Section 3.13)**
-* [H-SR] Android Handheld devices are STRONGLY RECOMMENDED to include a
- Quick Settings UI component.
+Handheld device implementations:
+
+* [H-SR] Are STRONGLY RECOMMENDED to include a Quick Settings UI component.
**Companion Device Pairing (Section 3.15)**
If Android handheld device implementations declare `FEATURE_BLUETOOTH` or `FEATURE_WIFI` support, they:
* [H-1-1] MUST support the companion device pairing feature.
+
+### 2.2.4\. Performance and Power
+
+**User Experience Consistency (Section 8.1)**
+
+For handheld device implementations:
+
+ * [H-0-1] **Consistent frame latency**. Inconsistent frame latency or a
+delay to render frames MUST NOT happen more often than 5 frames in a second,
+and SHOULD be below 1 frames in a second.
+ * [H-0-2] **User interface latency**. Device implementations MUST ensure
+low latency user experience by scrolling a list of 10K list entries as defined
+by the Android Compatibility Test Suite (CTS) in less than 36 secs.
+ * [H-0-3] **Task switching**. When multiple applications have been
+launched, re-launching an already-running application after it has been
+launched MUST take less than 1 second.
+
+**File I/O Access Performance (Section 8.2)**
+
+Handheld device implementations:
+
+ * [H-0-1] MUST ensure a sequential write performance of at least 5 MB/s.
+ * [H-0-2] MUST ensure a random write performance of at least 0.5 MB/s.
+ * [H-0-3] MUST ensure a sequential read performance of at least 15 MB/s.
+ * [H-0-4] MUST ensure a random read performance of at least 3.5 MB/s.
+
+**Power-Saving Modes (Section 8.3)**
+
+For handheld device implementations:
+
+* [H-0-1] All Apps exempted from App Standby and Doze power-saving modes
+MUST be made visible to the end user.
+* [H-0-2] The triggering, maintenance, wakeup algorithms and the use of
+global system settings of App Standby and Doze power-saving modes MUST not
+deviate from the Android Open Source Project.
+
+**Power Consumption Accounting (Sections 8.4)**
+
+Handheld device implementations:
+
+* [H-0-1] MUST provide a per-component power profile that defines the
+[current consumption value](
+http://source.android.com/devices/tech/power/values.html)
+for each hardware component and the approximate battery drain caused by the
+components over time as documented in the Android Open Source Project site.
+* [H-0-2] MUST report all power consumption values in milliampere
+hours (mAh).
+* [H-0-3] MUST report CPU power consumption per each process's UID.
+The Android Open Source Project meets the requirement through the
+`uid_cputime` kernel module implementation.
+* [H-0-4] MUST make this power usage available via the
+[`adb shell dumpsys batterystats`](
+http://source.android.com/devices/tech/power/batterystats.html)
+shell command to the app developer.
+* SHOULD be attributed to the hardware component itself if unable to
+attribute hardware component power usage to an application.
+
+If Handheld device implementations include a screen or video output, they:
+
+* [H-1-1] MUST honor the [`android.intent.action.POWER_USAGE_SUMMARY`](
+http://developer.android.com/reference/android/content/Intent.html#ACTION_POWER_USAGE_SUMMARY)
+intent and display a settings menu that shows this power usage.
+
+### 2.2.5\. Security Model
+
+**Permissions (Sections 9.1)**
+
+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.
+
diff --git a/2_device-types/2_3_television-reqs.md b/2_device-types/2_3_television-reqs.md
index 39ff09e..7eeabd4 100644
--- a/2_device-types/2_3_television-reqs.md
+++ b/2_device-types/2_3_television-reqs.md
@@ -19,15 +19,189 @@
### 2.3.1\. Hardware
-To be added.
+**Non-touch Navigation (Section 7.2.2)**
+
+Television device implementations:
+
+* [T-0-1] MUST support [D-pad](https://developer.android.com/reference/android/content/res/Configuration.html#NAVIGATION_DPAD).
+
+**Navigation Keys (Section 7.2.3)**
+
+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
+ function
+ ([`KEYCODE_BACK`](http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK))
+ to the foreground application.
+
+**Button Mappings (Section 7.2.6.1)**
+
+Television device implementations:
+
+* [T-0-1] MUST include support for game controllers and declare the
+`android.hardware.gamepad` feature flag.
+
+**Remote Control (Section 7.2.7)**
+
+Television device implementations:
+
+* SHOULD provide a remote control from which users can access
+[non-touch navigation](#7_2_2_non-touch_navigation) and
+[core navigation keys](#7_2_3_navigation_keys) inputs.
+
+**Gyroscope (Section 7.3.4)**
+
+If Television device implementations include a gyroscope, they:
+
+* [T-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
+
+**Bluetooth (Section 7.4.3)**
+
+Television device implementations:
+
+* [T-0-1] MUST support Bluetooth and Bluetooth LE.
+
+**Minimum Memory and Storage (Section 7.6.1)**
+
+Television device implementations:
+
+* [T-0-1] MUST have at least 4GB of non-volatile storage available for
+ application private data (a.k.a. "/data" partition)
+
+**Microphone (Section 7.8.1)**
+
+Television device implementations:
+
+* SHOULD include a microphone.
+
+**Audio Output (Section 7.8.2)**
+
+Television device implementations:
+
+* [T-0-1] MUST have an audio output and declare
+ `android.hardware.audio.output`.
### 2.3.2\. Multimedia
-To be added.
+**Audio Encoding (Section 5.1)**
+
+Television device implementations MUST support the following audio encoding:
+
+* [T-0-1] MPEG-4 AAC Profile (AAC LC)
+* [T-0-2] MPEG-4 HE AAC Profile (AAC+)
+* [T-0-3] AAC ELD (enhanced low delay AAC)
+
+
+**Video Encoding (Section 5.2)**
+
+Television device implementations MUST support the following video encoding:
+
+* [T-0-1] H.264 AVC
+* [T-0-2] VP8
+
+**H-264 (Section 5.2.2)**
+
+Television device implementations are:
+
+* [T-SR] STRONGLY RECOMMENDED to support H.264 encoding of 720p and 1080p
+resolution videos.
+* [T-SR] STRONGLY RECOMMENDED to support H.264 encoding of 1080p resolution
+video at 30 frame-per-second (fps).
+
+**Video Decoding (Section 5.3)**
+
+Television device implementations MUST support the following video decoding:
+
+* [T-0-1] H.264 AVC
+* [T-0-2] H.265 HEVC
+* [T-0-3] MPEG-4 SP
+* [T-0-4] VP8
+* [T-0-5] VP9
+
+Television device implementations are STRONGLY RECOMMENDED to support the
+following video decoding:
+
+* [T-SR] MPEG-2
+
+**H.264 (Section 5.3.4)**
+
+If Television device implementations support H.264 decoders, they:
+
+* [T-1-1] MUST support High Profile Level 4.2 and the HD 1080p (at 60 fps)
+decoding profile.
+* [T-1-2] MUST be capable of decoding videos with both HD profiles as
+indicated in the following table and encoded with either the Baseline Profile,
+Main Profile, or the High Profile Level 4.2
+
+**H.265 (HEVC) (Section 5.3.5)**
+
+If Television device implementations support H.265 codec and the HD 1080p
+decoding profile, they:
+
+* [T-1-1] MUST support the Main Profile Level 4.1 Main tier.
+* [T-SR] Are STRONGLY RECOMMENDED to support 60 fps video frame rate
+for HD 1080p.
+
+If Television device implementations support H.265 codec and the UHD decoding
+profile, then:
+
+* [T-2-1] The codec MUST support Main10 Level 5 Main Tier profile.
+
+**VP8 (Section 5.3.6)**
+
+If Television device implementations support VP8 codec, they:
+
+* [T-1-1] MUST support the HD 1080p60 decoding profile.
+
+If Television device implementations support VP8 codec and support 720p, they:
+
+* [T-2-1] MUST support the HD 720p60 decoding profile.
+
+
+**VP9 (Section 5.3.7)**
+
+If Television device implementations support VP9 codec and the UHD video
+decoding, they:
+
+* [T-1-1] MUST support 8-bit color depth and SHOULD support VP9 Profile 2
+(10-bit).
+
+If Television device implementations support VP9 codec, the 1080p profile and
+VP9 hardware decoding, they:
+
+* [T-2-1] MUST support 60 fps for 1080p.
+
+**Secure Media (Section 5.8)**
+
+If device implementations are Android Television devices and support 4K
+resolution, they:
+
+* [T-1-1] MUST support HDCP 2.2 for all wired external displays.
+
+If Television device implementations don't support 4K resolution, they:
+
+* [T-2-1] MUST support HDCP 1.4 for all wired external displays.
+
+Television device implementations:
+
+* [T-SR] Are STRONGLY RECOMMENDED to support simulataneous decoding of secure
+ streams. At minimum, simultaneous decoding of two steams is STRONGLY
+ RECOMMENDED.
+
+**Audio Output Volume (Section 5.5.3)**
+
+Television device implementations:
+
+* [T-0-1] MUST include support for system Master Volume and digital audio
+output volume attenuation on supported outputs,
+except for compressed audio passthrough output (where no audio decoding is done
+on the device).
+
### 2.3.3\. Software
-Android Television device implementations:
+Television device implementations:
* [T-0-1] MUST declare the features
[`android.software.leanback`](http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK)
@@ -35,7 +209,9 @@
**WebView compatibility (Section 3.4.1)**
-* [T-0-1] Television devices MUST provide a complete implementation of the android.webkit.Webview API.
+Television device implementations:
+
+* [T-0-1] MUST provide a complete implementation of the `android.webkit.Webview` API.
**Lock Screen Media Control (Section 3.8.10)**
@@ -46,13 +222,16 @@
**Multi-windows (Section 3.8.14)**
-* [T-SR] Android Television device implementations are STRONGLY RECOMMENDED to
- support picture-in-picture (PIP) mode multi-window.
+Television device implementations:
+
+* [T-SR] Are STRONGLY RECOMMENDED to support picture-in-picture (PIP) mode
+ multi-window.
**Accessibility (Section 3.10)**
-* [T-SR] Android Television device implementations MUST support third-party
- accessibility services.
+Television device implementations:
+
+* [T-SR] MUST support third-party accessibility services.
* [T-SR] Android Television device implementations are STRONGLY RECOMMENDED to
preload accessibility services on the device comparable with or exceeding
@@ -73,6 +252,58 @@
**TV Input Framework (Section 3.12)**
-To be added.
+Television device implementations:
+
+* [T-0-1] MUST support TV Input Framework.
+### 2.2.4\. Performance and Power
+
+
+**User Experience Consistency (Section 8.1)**
+
+For Television device implementations:
+
+ * [T-0-1] **Consistent frame latency**. Inconsistent frame latency or a
+delay to render frames MUST NOT happen more often than 5 frames in a second,
+and SHOULD be below 1 frames in a second.
+
+**File I/O Access Performance (Section 8.2)**
+
+Television device implementations:
+
+ * [T-0-1] MUST ensure a sequential write performance of at least 5MB/s.
+ * [T-0-2] MUST ensure a random write performance of at least 0.5MB/s.
+ * [T-0-3] MUST ensure a sequential read performance of at least 15MB/s.
+ * [T-0-4] MUST ensure a random read performance of at least 3.5MB/s.
+
+**Power-Saving Modes (Section 8.3)**
+
+For Television device implementations:
+
+* [T-0-1] All Apps exempted from App Standby and Doze power-saving modes
+MUST be made visible to the end user.
+* [T-0-2] The triggering, maintenance, wakeup algorithms and the use of
+global system settings of App Standby and Doze power-saving modes MUST not
+deviate from the Android Open Source Project.
+
+**Power Consumption Accounting (Sections 8.4)**
+
+Television device implementations:
+
+* [T-0-1] MUST provide a per-component power profile that defines the
+[current consumption value](
+http://source.android.com/devices/tech/power/values.html)
+for each hardware component and the approximate battery drain caused by the
+components over time as documented in the Android Open Source Project site.
+* [T-0-2] MUST report all power consumption values in milliampere
+hours (mAh).
+* [T-0-3] MUST report CPU power consumption per each process's UID.
+The Android Open Source Project meets the requirement through the
+`uid_cputime` kernel module implementation.
+* SHOULD be attributed to the hardware component itself if unable to
+attribute hardware component power usage to an application.
+* [T-0-4] MUST make this power usage available via the
+[`adb shell dumpsys batterystats`](
+http://source.android.com/devices/tech/power/batterystats.html)
+shell command to the app developer.
diff --git a/2_device-types/2_4_watch-reqs.md b/2_device-types/2_4_watch-reqs.md
index 500aab8..2523460 100644
--- a/2_device-types/2_4_watch-reqs.md
+++ b/2_device-types/2_4_watch-reqs.md
@@ -15,15 +15,67 @@
### 2.4.1\. Hardware
-To be added.
+**Screen Size (Section 7.1.1.1)**
+
+Watch device implementations:
+
+* [W-0-1] MUST have a screen with the physical diagonal size in the range from
+ 1.1 to 2.5 inches.
+
+**Navigation Keys (Section 7.2.3)**
+
+Watch device implementations:
+
+* [W-0-1] MUST have the Home function available to the user, and the Back
+ function except for when it is in `UI_MODE_TYPE_WATCH`.
+
+**Touchscreen Input (Section 7.2.4)**
+
+Watch device implementations:
+
+* [W-0-2] MUST support touchscreen input.
+
+**Accelerometer (Section 7.3.1)**
+
+Watch device implementations:
+
+* [W-SR] Are STRONGLY RECOMMENDED to include a 3-axis accelerometer.
+
+**Bluetooth (Section 7.4.3)**
+
+Watch device implementations:
+
+* [W-0-1] MUST support Bluetooth.
+
+
+**Minimum Memory and Storage (Section 7.6.1)**
+
+Watch device implementations:
+
+* [W-0-1] MUST have at least 1GB of non-volatile storage available for
+ application private data (a.k.a. "/data" partition)
+* [W-0-2] MUST have at least 416MB memory available to the kernel and
+ userspace.
+
+**Microphone (Section 7.8.1)**
+
+Watch device implementations:
+
+* [W-0-1] MUST include a microphone.
+
+**Audio Output (Section 7.8.1)**
+
+Watch device implementations:
+
+* MAY but SHOULD NOT have audio output.
### 2.4.2\. Multimedia
-To be added.
+No additional requirements.
### 2.4.3\. Software
-Android Watch device implementations:
+Watch device implementations:
* [W-0-1] MUST declare the feature android.hardware.type.watch.
* [W-0-2] MUST support uiMode =
@@ -32,19 +84,20 @@
**Search (Section 3.8.4)**
-* [W-SR] Watch device implementations are STRONGLY RECOMMENDED to implement
- an assistant on the device to handle the [Assist action](
+Watch device implementations:
+
+* [W-SR] Are STRONGLY RECOMMENDED to implement an assistant on the device to
+ handle the [Assist action](
http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST).
**Accessibility (Section 3.10)**
-* [W-1-1] Android Watch device implementations that declare the
- `android.hardware.audio.output` feature flag MUST support third-party
- accessibility services.
+Watch device implementations that declare the `android.hardware.audio.output` feature flag:
-* [W-SR] Android Watch device implementations that declare `android.hardware.
- audio.output` are STRONGLY RECOMMENDED to preload accessibility services on
+* [W-1-1] MUST support third-party accessibility services.
+
+* [W-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 the [talkback open source
@@ -52,10 +105,10 @@
**Text-to-Speech (Section 3.11)**
-If device implementations report the feature android.hardware.audio.output,
+If Watch device implementations report the feature android.hardware.audio.output,
they:
-* [W-SR] STRONGLY RECOMMENDED to include a TTS engine supporting the
+* [W-SR] Are STRONGLY RECOMMENDED to include a TTS engine supporting the
languages available on the device.
* [W-0-1] MUST support installation of third-party TTS engines.
diff --git a/2_device-types/2_5_automotive-reqs.md b/2_device-types/2_5_automotive-reqs.md
index d6f4271..65e09b8 100644
--- a/2_device-types/2_5_automotive-reqs.md
+++ b/2_device-types/2_5_automotive-reqs.md
@@ -2,33 +2,181 @@
**Android Automotive implementation** refers to a vehicle head unit running
Android as an operating system for part or all of the system and/or
-infotainment functionality. Android Automotive implementations:
+infotainment functionality.
Android device implementations are classified as an Automotive if they declare
the feature `android.hardware.type.automotive` or meet all the following
criteria.
-* are embedded as part of, or pluggable to, an automotive vehicle.
-* are using a screen in the driver's seat row as the primary display.
+* Are embedded as part of, or pluggable to, an automotive vehicle.
+* Are using a screen in the driver's seat row as the primary display.
The additional requirements in the rest of this section are specific to Android
Automotive device implementations.
### 2.5.1\. Hardware
-Android Automotive device implementations:
+**Screen Size (Section 7.1.1.1)**
-* [A-0-1] MUST have a screen with the physical diagonal length equal to or greater
- than 6 inches.
+Automotive device implementations:
-More to be added.
+* [A-0-1] MUST have a screen at least 6 inches in physical diagonal size.
+* [A-0-2] MUST have a screen size layout of at least 750 dp x 480 dp.
+
+**Navigation Keys (Section 7.2.3)**
+
+Automotive device implementations:
+
+* [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
+ function
+ ([`KEYCODE_BACK`](http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK))
+ to the foreground application.
+
+**Accelerometer (Section 7.3.1)**
+
+Automotive device implementations:
+
+* [A-SR] Are STRONGLY RECOMMENDED to include a 3-axis accelerometer.
+
+If Automotive device implementations include a 3-axis accelerometer, they:
+
+* [A-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
+* [A-1-2] MUST comply with the Android
+ [car sensor coordinate system](
+ http://source.android.com/devices/sensors/sensor-types.html#auto_axes).
+
+**GPS (Section 7.3.3)**
+
+If Automotive device implementations include a GPS/GNSS receiver and report
+the capability to applications through the `android.hardware.location.gps`
+feature flag:
+
+* [A-1-1] GNSS technology generation MUST be the year "2017" or newer.
+
+**Gyroscope (Section 7.3.4)**
+
+If Automotive device implementations include a gyroscope, they:
+
+* [A-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
+
+**Android Automotive-only sensors (Section 7.3.11)**
+**Current Gear (Section 7.3.11.1)**
+
+Automotive device implementations:
+
+* SHOULD provide current gear as `SENSOR_TYPE_GEAR`.
+
+**Day Night Mode (Section 7.3.11.2)**
+
+Automotive device implementations:
+
+* [A-0-1] MUST support day/night mode defined as `SENSOR_TYPE_NIGHT`.
+* [A-0-2] The value of the `SENSOR_TYPE_NIGHT` flag MUST be consistent with
+ dashboard day/night mode and SHOULD be based on ambient light sensor input.
+* The underlying ambient light sensor MAY be the same as
+[Photometer](#7_3_7_photometer).
+
+**Driving Status (Section 7.3.11.3)**
+
+Automotive device implementations:
+
+* [A-0-1] MUST support driving status defined as
+ `SENSOR_TYPE_DRIVING_STATUS`, with a default value of
+ `DRIVE_STATUS_UNRESTRICTED` when the vehicle is fully stopped and parked.
+ It is the responsibility of device manufacturers to configure
+ `SENSOR_TYPE_DRIVING_STATUS` in compliance with all laws and regulations
+ that apply to markets where the product is shipping.
+
+**Wheel Speed (Section 7.3.11.4)**
+
+Automotive device implementations:
+
+* [A-0-1] MUST provide vehicle speed defined as `SENSOR_TYPE_CAR_SPEED`.
+
+**Bluetooth (Section 7.4.3)**
+
+Automotive device implementations:
+
+* [A-0-1] MUST support Bluetooth and SHOULD support Bluetooth LE.
+
+* [A-0-2] Android Automotive implementations MUST support the following
+ Bluetooth profiles:
+ * Phone calling over Hands-Free Profile (HFP).
+ * Media playback over Audio Distribution Profile (A2DP).
+ * Media playback control over Remote Control Profile (AVRCP).
+ * Contact sharing using the Phone Book Access Profile (PBAP).
+* SHOULD support Message Access Profile (MAP).
+
+**Minimum Network Capability (Section 7.4.5)**
+
+Automotive device implementations:
+
+* SHOULD include support for cellular network based data connectivity.
+
+**Minimum Memory and Storage (Section 7.6.1)**
+
+Automotive device implementations:
+
+* [A-0-1] MUST have at least 4GB of non-volatile storage available for
+ application private data (a.k.a. "/data" partition)
+
+**USB peripheral mode (Section 7.7.1)**
+
+Automotive device implementations:
+
+* SHOULD include a USB port supporting peripheral mode.
+
+**Microphone (Section 7.8.1)**
+
+Automotive device implementations:
+
+* [A-0-1] MUST include a microphone.
+
+**Audio Output (Section 7.8.2)**
+
+Automotive device implementations:
+
+* [A-0-1] MUST have an audio output and declare
+ `android.hardware.audio.output`.
### 2.5.2\. Multimedia
-To be added.
+**Audio Encoding (Section 5.1)**
+
+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)
+
+**Video Encoding (Section 5.2)**
+
+Automotive device implementations MUST support the following video encoding:
+
+* [A-0-1] H.264 AVC
+* [A-0-2] VP8
+
+**Video Decoding (Section 5.3)**
+
+Automotive device implementations MUST support the following video decoding:
+
+* [A-0-1] H.264 AVC
+* [A-0-2] MPEG-4 SP
+* [A-0-3] VP8
+* [A-0-4] VP9
+
+Automotive device implementations are STRONGLY RECOMMENDED to support the
+following video decoding:
+
+* [A-SR] H.265 HEVC
+
### 2.5.3\. Software
+Automotive device implementations:
+
* [A-0-1] MUST declare the feature android.hardware.type.automotive.
* [A-0-2] MUST support uiMode =
[UI_MODE_TYPE_CAR](http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR).
@@ -37,7 +185,9 @@
**WebView Compatibility (Section 3.4.1)**
-* [A-0-1] Automobile devices MUST provide a complete implementation of the android.webkit.Webview API.
+Automotive device implementations:
+
+* [A-0-1] MUST provide a complete implementation of the `android.webkit.Webview API`.
**Notifications (Section 3.8.3)**
@@ -49,12 +199,69 @@
**Search (Section 3.8.4)**
-* [A-0-1] Android Automotive implementations MUST implement an assistant on
- the device to handle the [Assist action](
+Automotive device implementations:
+
+* [A-0-1] MUST implement an assistant on the device to handle the
+ [Assist action](
http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST).
**Media UI (Section 3.14)**
-* [A-0-1] Automotive implementations MUST include a UI framework to support
- third-party apps using the media APIs as described in section 3.14.
+Automotive device implementations:
+
+* [A-0-1] MUST include a UI framework to support third-party apps using the
+ media APIs as described in section 3.14.
+
+### 2.2.4\. Performance and Power
+
+**Power-Saving Modes (Section 8.3)**
+
+For Automotive device implementations:
+
+* [A-0-1] All Apps exempted from App Standby and Doze power-saving modes
+MUST be made visible to the end user.
+* [A-0-2] The triggering, maintenance, wakeup algorithms and the use of
+global system settings of App Standby and Doze power-saving modes MUST not
+deviate from the Android Open Source Project.
+
+**Power Consumption Accounting (Sections 8.4)**
+
+Automotive device implementations:
+
+* [A-0-1] MUST provide a per-component power profile that defines the
+[current consumption value](
+http://source.android.com/devices/tech/power/values.html)
+for each hardware component and the approximate battery drain caused by the
+components over time as documented in the Android Open Source Project site.
+* [A-0-2] MUST report all power consumption values in milliampere
+hours (mAh).
+* [A-0-3] MUST report CPU power consumption per each process's UID.
+The Android Open Source Project meets the requirement through the
+`uid_cputime` kernel module implementation.
+* SHOULD be attributed to the hardware component itself if unable to
+attribute hardware component power usage to an application.
+* [A-0-4] MUST make this power usage available via the
+[`adb shell dumpsys batterystats`](
+http://source.android.com/devices/tech/power/batterystats.html)
+shell command to the app developer.
+
+### 2.2.5\. Security Model
+
+**Multi-User Support (Section 9.5)**
+
+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.
+
+**Automotive Vehicle System Isolation (Section 9.14)**
+
+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.
diff --git a/2_device-types/2_6_tablet-reqs.md b/2_device-types/2_6_tablet-reqs.md
new file mode 100644
index 0000000..387d53b
--- /dev/null
+++ b/2_device-types/2_6_tablet-reqs.md
@@ -0,0 +1,45 @@
+## 2.6\. Tablet Requirements
+
+An **Android Tablet device** refers to an Android device implementation that is
+typically used by holding in both hands and not in a clamshell form-factor.
+
+Android device implementations are classified as a Tablet if they meet all the
+following criteria:
+
+* Have a power source that provides mobility, such as a battery.
+* Have a physical diagonal screen size in the range of 7 to 18 inches.
+
+Tablet device implementations have similar requirements to handheld device
+implementations. The exceptions are in indicated by and \* in that section
+and noted for reference in this section.
+
+### 2.4.1\. Hardware
+
+**Screen Size (Section 7.1.1.1)**
+
+Tablet device implementations:
+
+* [Ta-0-1] MUST have a screen in the range of 7 to 18 inches.
+
+**Minimum Memory and Storage (Section 7.6.1)**
+
+The screen densities listed for small/normal screens in the handheld
+requirements are not applicable to tablets.
+
+**USB peripheral mode (Section 7.7.1)**
+
+If handheld device implementations include a USB port supporting peripheral
+mode, they:
+
+* MAY implement the Android Open Accessory (AOA) API.
+
+**Virtual Reality Mode (Section 7.9.1)**
+
+**Virtual Reality High Performance (Section 7.9.2)**
+
+Virtual reality requirements are not applicable to tablets.
+
+
+
+
+
diff --git a/3_software/3_12_tv-input-framework.md b/3_software/3_12_tv-input-framework.md
index 9676250..0bca402 100644
--- a/3_software/3_12_tv-input-framework.md
+++ b/3_software/3_12_tv-input-framework.md
@@ -5,9 +5,6 @@
content to Android Television devices. TIF provides a standard API to create
input modules that control Android Television devices.
-* [T-0-1] Android Television device implementations MUST support TV Input
-Framework.
-
If device implementations support TIF, they:
* [C-1-1] MUST declare the platform feature `android.software.live_tv`.
diff --git a/3_software/3_2_soft-api-compatibility.md b/3_software/3_2_soft-api-compatibility.md
index 3837b1c..b86a590 100644
--- a/3_software/3_2_soft-api-compatibility.md
+++ b/3_software/3_2_soft-api-compatibility.md
@@ -252,15 +252,15 @@
components, or at least a handler, for all the public intent filter patterns
defined by the 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
@@ -433,4 +433,4 @@
* [C-3-1] Only the owner of that display, system, and activities that are
already on that display MUST be able to launch to it. Everyone can launch to
a display that has [android.view.Display.FLAG_PUBLIC](https://developer.android.com/reference/android/view/Display.html#FLAG_PUBLIC)
- flag.
\ No newline at end of file
+ flag.
diff --git a/5_multimedia/5_1_media-codecs.md b/5_multimedia/5_1_media-codecs.md
index 781376e..c8d569c 100644
--- a/5_multimedia/5_1_media-codecs.md
+++ b/5_multimedia/5_1_media-codecs.md
@@ -4,27 +4,6 @@
See more details in [5.1.3. Audio Codecs Details](#5_1_3_audio_codecs_details).
-Handheld device implementations MUST support the following audio encoding:
-
-* [H-0-1] AMR-NB
-* [H-0-2] AMR-WB
-* [H-0-3] MPEG-4 AAC Profile (AAC LC)
-* [H-0-4] MPEG-4 HE AAC Profile (AAC+)
-* [H-0-5] AAC ELD (enhanced low delay AAC)
-
-
-Television device implementations MUST support the following audio encoding:
-
-* [T-0-1] MPEG-4 AAC Profile (AAC LC)
-* [T-0-2] MPEG-4 HE AAC Profile (AAC+)
-* [T-0-3] AAC ELD (enhanced low delay AAC)
-
-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)
-
If device implementations declare `android.hardware.microphone`,
they MUST support the following audio encoding:
@@ -35,10 +14,6 @@
See more details in [5.1.3. Audio Codecs Details](#5_1_3_audio_codecs_details).
-Handheld device implementations MUST support the following decoding.
-
-* [H-0-1] AMR-NB
-* [H-0-2] AMR-WB
If device implementations declare support for the
`android.hardware.audio.output` feature, they:
diff --git a/5_multimedia/5_2_video-encoding.md b/5_multimedia/5_2_video-encoding.md
index 4f97c1e..3bc9d79 100644
--- a/5_multimedia/5_2_video-encoding.md
+++ b/5_multimedia/5_2_video-encoding.md
@@ -1,22 +1,5 @@
## 5.2\. Video Encoding
-Handheld device implementations MUST support the following encoding and make it
-available to third-party applications.
-
-* [H-0-1] H.264 AVC
-* [H-0-2] VP8
-
-Television device implementations MUST support the following encoding.
-
-* [T-0-1] H.264 AVC
-* [T-0-2] VP8
-
-Automotive device implementations MUST support the following encoding:
-
-* [A-0-1] H.264 AVC
-* [A-0-2] VP8
-
-
If device implementations support any video encoder and make it available
to third-party apps, they:
@@ -60,14 +43,6 @@
### 5.2.2\. H-264
-Television device implementations are:
-
-* [T-SR] STRONGLY RECOMMENDED to support H.264 encoding of 720p and 1080p
-resolution videos.
-* [T-SR] STRONGLY RECOMMENDED to support H.264 encoding of 1080p resolution
-video at 30 frame-per-second (fps).
-
-
If device implementations support H.264 codec, they:
* [C-1-1] MUST support Baseline Profile Level 3.
diff --git a/5_multimedia/5_3_video-decoding.md b/5_multimedia/5_3_video-decoding.md
index 255d503..0d09bab 100644
--- a/5_multimedia/5_3_video-decoding.md
+++ b/5_multimedia/5_3_video-decoding.md
@@ -1,32 +1,5 @@
## 5.3\. Video Decoding
-Handheld device implementations:
-
-* [H-0-1] MUST support decoding of H.264 AVC.
-* [H-0-2] MUST support decoding of H.265 HEVC.
-* [H-0-3] MUST support decoding of MPEG-4 SP.
-* [H-0-4] MUST support decoding of VP8.
-* [H-0-5] MUST support decoding of VP9.
-
-Television device implementations:
-
-* [T-0-1] MUST support decoding of H.264 AVC.
-* [T-0-2] MUST support decoding of H.265 HEVC.
-* [T-0-3] MUST support decoding of MPEG-4 SP.
-* [T-0-4] MUST support decoding of VP8.
-* [T-0-5] MUST support decoding of VP9.
-* [T-SR] Are Strongly Recommended to support MPEG-2 decoding.
-
-
-Automotive device implementations:
-
-* [A-0-1] MUST support decoding of H.264 AVC.
-* [A-0-2] MUST support decoding of MPEG-4 SP.
-* [A-0-3] MUST support decoding of VP8.
-* [A-0-4] MUST support decoding of VP9.
-* [A-SR] Are Strongly Recommended to support H.265 HEVC decoding.
-
-
If device implementations support VP8, VP9, H.264, or H.265 codecs, they:
* [C-1-1] MUST support dynamic video resolution and frame rate switching
@@ -83,13 +56,6 @@
* [C-2-2] MUST support the HD 1080p video encoding profiles in the following
table.
-If Television device implementations support H.264 decoders, they:
-
-* [T-1-1] MUST support High Profile Level 4.2 and the HD 1080p (at 60 fps)
-decoding profile.
-* [T-1-2] MUST be capable of decoding videos with both HD profiles as
-indicated in the following table and encoded with either the Baseline Profile,
-Main Profile, or the High Profile Level 4.2
<table>
<tr>
@@ -124,6 +90,7 @@
### 5.3.5\. H.265 (HEVC)
+
If device implementations support H.265 codec, they:
* [C-1-1] MUST support the Main Profile Level 3 Main tier and the SD video
@@ -138,18 +105,6 @@
* [C-2-1] Device implementations MUST support at least one of H.265 or VP9
decoding of 720, 1080 and UHD profiles.
-If Television device implementations support H.265 codec and the HD 1080p
-decoding profile, they:
-
-* [T-1-1] MUST support the Main Profile Level 4.1 Main tier.
-* [T-SR] STRONGLY RECOMMENDED to support 60 fps video frame rate
-for HD 1080p.
-
-If Television device implementations support H.265 codec and the UHD decoding
-profile, then:
-
-* [T-2-1] The codec MUST support Main10 Level 5 Main Tier profile.
-
<table>
<tr>
<th></th>
@@ -204,15 +159,6 @@
* [C-2-2] Device implementations MUST support 1080p profiles in the
following table.
-If Television device implementations support VP8 codec, they:
-
-* [T-1-1] MUST support the HD 1080p60 decoding profile.
-
-If Television device implementations support VP8 codec and support 720p, they:
-
-* [T-2-1] MUST support the HD 720p60 decoding profile.
-
-
<table>
<tr>
@@ -265,17 +211,6 @@
* [C-3-1] Device implementations MUST support at least one of VP9 or H.265
decoding of the 720, 1080 and UHD profiles.
-If Television device implementations support VP9 codec and the UHD video
-decoding, they:
-
-* [T-1-1] MUST support 8-bit color depth and SHOULD support VP9 Profile 2
-(10-bit).
-
-If Television device implementations support VP9 codec, the 1080p profile and
-VP9 hardware decoding, they:
-
-* [T-2-1] MUST support 60 fps for 1080p.
-
<table>
<tr>
<th></th>
@@ -309,4 +244,4 @@
<td>5 Mbps</td>
<td>20 Mbps</td>
</tr>
-</table>
\ No newline at end of file
+</table>
diff --git a/5_multimedia/5_5_audio-playback.md b/5_multimedia/5_5_audio-playback.md
index 363197e..b0e6d45 100644
--- a/5_multimedia/5_5_audio-playback.md
+++ b/5_multimedia/5_5_audio-playback.md
@@ -10,14 +10,14 @@
* [C-1-1] MUST allow playback of raw audio content with the following
characteristics:
- * **Format**: Linear PCM, 16-bit
- * **Sampling rates**: 8000, 11025, 16000, 22050, 32000, 44100
- * **Channels**: Mono, Stereo
+ * **Format**: Linear PCM, 16-bit
+ * **Sampling rates**: 8000, 11025, 16000, 22050, 32000, 44100
+ * **Channels**: Mono, Stereo
* SHOULD allow playback of raw audio content with the following
characteristics:
- * **Sampling rates**: 24000, 48000
+ * **Sampling rates**: 24000, 48000
### 5.5.2\. Audio Effects
@@ -40,13 +40,6 @@
### 5.5.3\. Audio Output Volume
-Television device implementations:
-
-* [T-0-1] MUST include support for system Master Volume and digital audio
-output volume attenuation on supported outputs,
-except for compressed audio passthrough output (where no audio decoding is done
-on the device).
-
Automotive device implementations:
* SHOULD allow adjusting audio volume
diff --git a/5_multimedia/5_8_secure-media.md b/5_multimedia/5_8_secure-media.md
index 5df157e..e75a775 100644
--- a/5_multimedia/5_8_secure-media.md
+++ b/5_multimedia/5_8_secure-media.md
@@ -17,15 +17,3 @@
* [C-3-1] MUST support HDCP 1.2 or higher for all wired external displays.
-If device implementations are Android Television devices and support 4K
-resolution, they:
-
-* [T-1-1] MUST support HDCP 2.2 for all wired external displays.
-
-If Television device implementations don't support 4K resolution, they:
-
-* [T-2-1] MUST support HDCP 1.4 for all wired external displays.
-
-* [T-SR] Television device implementations are STRONGLY RECOMMENDED to
-support simulataneous decoding of secure streams. At minimum, simultaneous
-decoding of two steams is STRONGLY RECOMMENDED.
\ No newline at end of file
diff --git a/7_hardware-compatibility/7_1_display-and-graphics.md b/7_hardware-compatibility/7_1_display-and-graphics.md
index b9b8d0f..ece4f9f 100644
--- a/7_hardware-compatibility/7_1_display-and-graphics.md
+++ b/7_hardware-compatibility/7_1_display-and-graphics.md
@@ -23,18 +23,6 @@
#### 7.1.1.1\. Screen Size
-* [H-0-1] Handheld device implementations MUST have a screen at least 2.5
- inches in physical diagonal size.
-
-* [A-0-1] Android Automotive devices MUST have a screen at least 6 inches
- in physical diagonal size.
-
-* [A-0-2] Android Automotive devices MUST have a screen size layout of
-at least 750 dp x 480 dp.
-
-* [W-0-1] Android Watch device implementations MUST have a screen with the
- physical diagonal size in the range from 1.1 to 2.5 inches.
-
The Android UI framework supports a variety of different logical screen layout
sizes, and allows applications to query the current configuration's screen
layout size via `Configuration.screenLayout` with the `SCREENLAYOUT_SIZE_MASK`
@@ -130,8 +118,6 @@
supported compatible screen size (320 dp width), device implementations SHOULD
report the next lowest standard Android framework density.
-* [H-SR] Device implementations are STRONGLY RECOMMENDED to provide users an
- affordance to change the display size.
If there is an affordance to change the display size of the device:
@@ -355,12 +341,6 @@
applications not developed for old versions of Android that pre-date
screen-size independence.
-* [H-0-1] Handheld device implementations MUST include support
- for legacy application compatibility mode as implemented by the upstream
- Android open source code. That is, device implementations MUST NOT alter the
- triggers or thresholds at which compatibility mode is activated, and MUST
- NOT alter the behavior of the compatibility mode itself.
-
### 7.1.6\. Screen Technology
The Android platform includes APIs that allow applications to render rich
@@ -386,4 +366,4 @@
* [C-1-1] MUST implement the [`DisplayManager`](
https://developer.android.com/reference/android/hardware/display/DisplayManager.html)
- system service and API as described in the Android SDK documentation.
\ No newline at end of file
+ system service and API as described in the Android SDK documentation.
diff --git a/7_hardware-compatibility/7_2_input-devices.md b/7_hardware-compatibility/7_2_input-devices.md
index 66fda1d..993db39 100644
--- a/7_hardware-compatibility/7_2_input-devices.md
+++ b/7_hardware-compatibility/7_2_input-devices.md
@@ -8,11 +8,6 @@
### 7.2.1\. Keyboard
-* [H-0-1] Handheld device implementations MUST include support for
-third-party Input Method Editor (IME) applications.
-* [T-0-1] Television device implementations MUST include support for
-third-party Input Method Editor (IME) applications.
-
If device implementations include support for third-party
Input Method Editor (IME) applications, they:
@@ -34,10 +29,6 @@
Android includes support for d-pad, trackball, and wheel as mechanisms for
non-touch navigation.
-Television device implementations:
-
-* [T-0-1] MUST support [D-pad](https://developer.android.com/reference/android/content/res/Configuration.html#NAVIGATION_DPAD).
-
Device implementations:
* [C-0-1] MUST report the correct value for
@@ -61,25 +52,6 @@
or a distinct portion of the touch screen, are essential to the Android
navigation paradigm and therefore:
-* [H-0-1] Android Handheld device implementations MUST provide the Home,
- Recents, and Back functions.
-* [H-0-2] Android Handheld device implementations MUST send both the normal
- and long press event of the the Back function ([`KEYCODE_BACK`](http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK))
- to the foreground application.
-* [T-0-1] Android Television device implementations MUST provide the Home
- and Back functions.
-* [T-0-2] Android Television device implementations MUST send both the normal
- and long press event of the the Back function ([`KEYCODE_BACK`](http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK))
- to the foreground application.
-* [W-0-1] Android Watch device implementations MUST have the Home function
- available to the user, and the Back function except for when it is in
- `UI_MODE_TYPE_WATCH`.
-* [A-0-1] Automotive device implementations MUST provide the Home function
- and MAY provide Back and Recent functions.
-* [A-0-2] Automotive device implementations MUST send both the normal
- and long press event of the the Back function ([`KEYCODE_BACK`](http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK))
- to the foreground application.
-
* [C-0-1] MUST provide the Home function.
* SHOULD provide buttons for the Recents and Back function.
@@ -145,9 +117,6 @@
the system does not require any additional affordances to indicate the objects
being manipulated.
-* [H-0-1] Handheld device implementations MUST support touchscreen input.
-* [W-0-2] Watch device implementations MUST support touchscreen input.
-
Device implementations:
* SHOULD have a pointer input system of some kind
@@ -236,10 +205,6 @@
#### 7.2.6.1\. Button Mappings
-Television device implementations:
-* [T-0-1] MUST include support for game controllers and declare the
-`android.hardware.gamepad` feature flag.
-
If device implementations declare the `android.hardware.gamepad` feature flag,
they:
* [C-1-1] MUST have embed a controller or ship with a separate controller
@@ -381,8 +346,5 @@
### 7.2.7\. Remote Control
-Television device implementations:
+See [Section 2.3.1](#2_3_1_hardware) for device-specific requirements.
-* SHOULD provide a remote control from which users can access
-[non-touch navigation](#7_2_2_non-touch_navigation) and
-[core navigation keys](#7_2_3_navigation_keys) inputs.
\ No newline at end of file
diff --git a/7_hardware-compatibility/7_3_sensors.md b/7_hardware-compatibility/7_3_sensors.md
index 2090341..7e43ea1 100644
--- a/7_hardware-compatibility/7_3_sensors.md
+++ b/7_hardware-compatibility/7_3_sensors.md
@@ -82,25 +82,6 @@
### 7.3.1\. Accelerometer
* Device implementations SHOULD include a 3-axis accelerometer.
-* [H-SR] Handheld device implementations are STRONGLY RECOMMENDED to
- include a 3-axis accelerometer.
-* [A-SR] Automotive device implementations are STRONGLY RECOMMENDED to
- include a 3-axis accelerometer.
-* [W-SR] Watch device implementations are STRONGLY RECOMMENDED to
- include a 3-axis accelerometer.
-
-
-
-If Handheld device implementations include a 3-axis accelerometer, they:
-
-* [H-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
-
-If Automotive device implementations include a 3-axis accelerometer, they:
-
-* [A-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
-* [A-1-2] MUST comply with the Android
- [car sensor coordinate system](
- http://source.android.com/devices/sensors/sensor-types.html#auto_axes).
If device implementations include a 3-axis accelerometer, they:
@@ -253,12 +234,6 @@
additional mandatory requirements for devices reporting the year "2016" or
"2017" through the Test API `LocationManager.getGnssYearOfHardware()`.
-If Automotive device implementations include a GPS/GNSS receiver and report
-the capability to applications through the `android.hardware.location.gps`
-feature flag:
-
-* [A-1-1] GNSS technology generation MUST be the year "2017" or newer.
-
If device implementations include a GPS/GNSS receiver and report the capability
to applications through the `android.hardware.location.gps` feature flag and the
`LocationManager.getGnssYearOfHardware()` Test API reports the year "2016" or
@@ -318,19 +293,6 @@
when device is stationary at room temperature.
* SHOULD report events up to at least 200 Hz.
-If Handheld device implementations include a gyroscope, they:
-
-* [H-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
-
-If Automotive device implementations include a gyroscope, they:
-
-* [A-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
-
-If Television device implementations include a gyroscope, they:
-
-* [T-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
-
-
If device implementations include a gyroscope, an accelerometer sensor and a
magnetometer sensor, they:
@@ -385,9 +347,6 @@
### 7.3.8\. Proximity Sensor
* Device implementations MAY include a proximity sensor.
-* Handheld device implementations that can make a voice call and indicate
-any value other than `PHONE_TYPE_NONE` in `getPhoneType`
-SHOULD include a proximity sensor.
If device implementations include a proximity sensor, they:
@@ -583,40 +542,22 @@
Automotive-specific sensors are defined in the
`android.car.CarSensorManager API`.
-
#### 7.3.11.1\. Current Gear
-* Android Automotive implementations SHOULD provide current gear as
-`SENSOR_TYPE_GEAR`.
+See [Section 2.5.1](#2_5_1_hardware) for device-specific requirements.
#### 7.3.11.2\. Day Night Mode
-Automotive device implementations:
-
-* [A-0-1] MUST support day/night mode
-defined as `SENSOR_TYPE_NIGHT`.
-* [A-0-2] The value of the `SENSOR_TYPE_NIGHT` flag MUST be consistent with
-dashboard day/night mode and SHOULD be based on ambient light sensor input.
-
-* The underlying ambient light sensor MAY be the same as
-[Photometer](#7_3_7_photometer).
+See [Section 2.5.1](#2_5_1_hardware) for device-specific requirements.
#### 7.3.11.3\. Driving Status
-Automotive device implementations:
-
-* [A-0-1] MUST support driving status
-defined as `SENSOR_TYPE_DRIVING_STATUS`, with a default value of
-`DRIVE_STATUS_UNRESTRICTED` when the vehicle is fully stopped and parked. It is
-the responsibility of device manufacturers to configure
-`SENSOR_TYPE_DRIVING_STATUS` in compliance with all
-laws and regulations that apply to markets where the product is shipping.
+See [Section 2.5.1](#2_5_1_hardware) for device-specific requirements.
#### 7.3.11.4\. Wheel Speed
-Automotive device implementations:
+See [Section 2.5.1](#2_5_1_hardware) for device-specific requirements.
-* [A-0-1] MUST provide vehicle speed defined as `SENSOR_TYPE_CAR_SPEED`.
## 7.3.12\. Pose Sensor
@@ -624,10 +565,6 @@
* MAY support pose sensor with 6 degrees of freedom.
-Handheld device implementations are:
-
-* RECOMMENDED to support this sensor.
-
If device implementations support pose sensor with 6 degrees of freedom, they:
* [C-1-1] MUST implement and report [`TYPE_POSE_6DOF`](
diff --git a/7_hardware-compatibility/7_4_data-connectivity.md b/7_hardware-compatibility/7_4_data-connectivity.md
index b8869d0..9cd6ae4 100644
--- a/7_hardware-compatibility/7_4_data-connectivity.md
+++ b/7_hardware-compatibility/7_4_data-connectivity.md
@@ -162,10 +162,6 @@
### 7.4.3\. Bluetooth
-* [W-0-1] Watch device implementations MUST support Bluetooth.
-* [T-0-1] Television device implementations MUST support Bluetooth and
-Bluetooth LE.
-
If device implementations support Bluetooth Audio profile, they:
* SHOULD support Advanced Audio Codecs and Bluetooth Audio Codecs
@@ -188,17 +184,6 @@
* SHOULD implement relevant Bluetooth profiles such as
A2DP, AVCP, OBEX, etc. as appropriate for the device.
-Automotive device implementations:
-* [A-0-1] Automotive device implementations MUST support Bluetooth and
-SHOULD support Bluetooth LE.
-* [A-0-2] Android Automotive implementations MUST support the following
-Bluetooth profiles:
-
- * Phone calling over Hands-Free Profile (HFP).
- * Media playback over Audio Distribution Profile (A2DP).
- * Media playback control over Remote Control Profile (AVRCP).
- * Contact sharing using the Phone Book Access Profile (PBAP).
-* SHOULD support Message Access Profile (MAP).
If device implementations include support for Bluetooth Low Energy, they:
@@ -413,10 +398,6 @@
* [SR] STRONGLY RECOMMENDED to provide the data saver mode.
-If Handheld device implementations include a metered connection, they:
-
-* [H-1-1] MUST provide the data saver mode.
-
If device implementations provide the data saver mode, they:
* [C-1-1] MUST support all the APIs in the `ConnectivityManager`
diff --git a/7_hardware-compatibility/7_6_memory-and-storage.md b/7_hardware-compatibility/7_6_memory-and-storage.md
index 674da7f..c4f8fab 100644
--- a/7_hardware-compatibility/7_6_memory-and-storage.md
+++ b/7_hardware-compatibility/7_6_memory-and-storage.md
@@ -10,97 +10,6 @@
downloading individual files of at least 100MB in size to the default
“cache” location.
-Television device implementations:
-
-* [T-0-1] MUST have at least 4GB of non-volatile storage available for
- application private data (a.k.a. "/data" partition)
-
-Automotive device implementations:
-
-* [A-0-1] MUST have at least 4GB of non-volatile storage available for
- application private data (a.k.a. "/data" partition)
-
-Watch device implementations:
-
-* [W-0-1] MUST have at least 1GB of non-volatile storage available for
- application private data (a.k.a. "/data" partition)
-* [W-0-2] MUST have at least 416MB memory available to the kernel and
- userspace.
-
-Handheld device implementations:
-
-* [H-0-1] MUST have at least 4GB of non-volatile storage available for
- application private data (a.k.a. "/data" partition)
-* [H-0-2] MUST return “true” for `ActivityManager.isLowRamDevice()` when there
- is less than 1GB of memory available to the kernel and userspace.
-
-
-If Handheld device implementations are 32-bit:
-
-* [H-1-1] The memory available to the kernel and userspace MUST
-be at least: 512MB if any of the following densities are used:
-
- * 280dpi or lower on small/normal screens
- * ldpi or lower on extra large screens
- * mdpi or lower on large screens
-
-* [H-2-1] The memory available to the kernel and userspace MUST
-be at least: 608MB if any of the following densities are used:
-
- * xhdpi or higher on small/normal screens
- * hdpi or higher on large screens
- * mdpi or higher on extra large screens
-
-* [H-3-1] The memory available to the kernel and userspace MUST
-be at least: 896MB if any of the following densities are used:
-
- * 400dpi or higher on small/normal screens
- * xhdpi or higher on large screens
- * tvdpi or higher on extra large screens
-
-* [H-4-1] The memory available to the kernel and userspace MUST
-be at least: 1344MB if any of the following densities are used:
-
- * 560dpi or higher on small/normal screens
- * 400dpi or higher on large screens
- * xhdpi or higher on extra large screens
-
-If Handheld device implementations are 64-bit:
-
-* [H-5-1] The memory available to the kernel and userspace MUST
-be at least: 816MB if any of the following densities are used:
-
- * 280dpi or lower on small/normal screens
- * ldpi or lower on extra large screens
- * mdpi or lower on large screens
-
-
-* [H-6-1] The memory available to the kernel and userspace MUST
-be at least: 944MB if any of the following densities are used:
-
- * xhdpi or higher on small/normal screens
- * hdpi or higher on large screens
- * mdpi or higher on extra large screens
-
-* [H-7-1] The memory available to the kernel and userspace MUST
-be at least: 1280MB if any of the following densities are used:
-
- * 400dpi or higher on small/normal screens
- * xhdpi or higher on large screens
- * tvdpi or higher on extra large screens
-
-* [H-8-1] The memory available to the kernel and userspace MUST
-be at least: 1824MB if any of the following densities are used:
-
- * 560dpi or higher on small/normal screens
- * 400dpi or higher on large screens
- * xhdpi or higher on extra large screens
-
-Note that the "memory available to the kernel and userspace" above refers to the
-memory space provided in addition to any memory already dedicated to hardware
-components such as radio, video, and so on that are not under the kernel’s
-control on device implementations.
-
### 7.6.2\. Application Shared Storage
Device implementations:
@@ -119,10 +28,6 @@
permission on this shared storage as documented in the SDK. Shared storage
MUST otherwise be writable by any application that obtains that permission.
-Android handheld device implementations:
-
-* [H-0-1] MUST NOT provide an application shared storage smaller than 1GiB.
-
Device implementations MAY meet the above requirements using either:
* a user-accessible removable storage, such as a Secure Digital (SD) card slot.
diff --git a/7_hardware-compatibility/7_7_usb.md b/7_hardware-compatibility/7_7_usb.md
index 0d4965c..77f3b82 100644
--- a/7_hardware-compatibility/7_7_usb.md
+++ b/7_hardware-compatibility/7_7_usb.md
@@ -6,11 +6,6 @@
### 7.7.1\. USB peripheral mode
-If handheld device implementations include a USB port supporting peripheral
-mode, they:
-
-* [H-1-1] MUST implement the Android Open Accessory (AOA) API.
-
If device implementations include a USB port supporting peripheral mode:
* [C-1-1] The port MUST be connectable to a USB host that has a standard
@@ -68,12 +63,12 @@
[`android.hardware.usb.host`](http://developer.android.com/guide/topics/connectivity/usb/host.html).
* [C-1-2] MUST implement support to connect standard USB peripherals,
in other words, they MUST either:
- * Have an on-device type C port or ship with cable(s) adapting an on-device
- proprietary port to a standard USB type-C port (USB Type-C device).
- * Have an on-device type A or ship with cable(s) adapting an on-device
- proprietary port to a standard USB type-A port.
- * Have an on-device micro-AB port, which SHOULD ship with a cable adapting
- to a standard type-A port.
+ * Have an on-device type C port or ship with cable(s) adapting an on-device
+ proprietary port to a standard USB type-C port (USB Type-C device).
+ * Have an on-device type A or ship with cable(s) adapting an on-device
+ proprietary port to a standard USB type-A port.
+ * Have an on-device micro-AB port, which SHOULD ship with a cable adapting
+ to a standard type-A port.
* [C-1-3] MUST NOT ship with an adapter converting from USB type A or
micro-AB ports to a type-C port (receptacle).
* [SR] STRONGLY RECOMMENDED to implement the [USB audio class](
@@ -99,10 +94,10 @@
and the [Voice Command Usage Request](http://www.usb.org/developers/hidpage/Voice_Command_Usage.pdf)
to the [`KeyEvent`](https://developer.android.com/reference/android/view/KeyEvent.html)
constants as below:
- * Usage Page (0xC) Usage ID (0x0CD): `KEYCODE_MEDIA_PLAY_PAUSE`
- * Usage Page (0xC) Usage ID (0x0E9): `KEYCODE_VOLUME_UP`
- * Usage Page (0xC) Usage ID (0x0EA): `KEYCODE_VOLUME_DOWN`
- * Usage Page (0xC) Usage ID (0x0CF): `KEYCODE_VOICE_ASSIST`
+ * Usage Page (0xC) Usage ID (0x0CD): `KEYCODE_MEDIA_PLAY_PAUSE`
+ * Usage Page (0xC) Usage ID (0x0E9): `KEYCODE_VOLUME_UP`
+ * Usage Page (0xC) Usage ID (0x0EA): `KEYCODE_VOLUME_DOWN`
+ * Usage Page (0xC) Usage ID (0x0CF): `KEYCODE_VOICE_ASSIST`
If device implementations include a USB port supporting host mode and
@@ -126,4 +121,4 @@
http://www.usb.org/developers/docs/).
* SHOULD implement the Try.\* model that is most appropriate for the
device form factor. For example a handheld device SHOULD implement the
-Try.SNK model.
\ No newline at end of file
+Try.SNK model.
diff --git a/7_hardware-compatibility/7_8_audio.md b/7_hardware-compatibility/7_8_audio.md
index 0279da4..32288e3 100644
--- a/7_hardware-compatibility/7_8_audio.md
+++ b/7_hardware-compatibility/7_8_audio.md
@@ -2,11 +2,6 @@
### 7.8.1\. Microphone
-
-* [H-0-1] Handheld device implementations MUST include a microphone.
-* [W-0-1] Watch device implementations MUST include a microphone.
-* [A-0-1] Automotive device implementations MUST include a microphone.
-
If device implementations include a microphone, they:
* [C-1-1] MUST report the `android.hardware.microphone` feature constant.
@@ -44,13 +39,6 @@
* [C-2-1] MUST NOT report the `android.hardware.audio output` feature.
* [C-2-2] MUST implement the Audio Output related APIs as no-ops at least.
-* [H-0-1] Handheld device implementations MUST have an audio output and
-declare `android.hardware.audio.output`.
-* [T-0-1] Television device implementations MUST have an audio output and
-declare `android.hardware.audio.output`.
-* [A-0-1] Automotive device implementations MUST have an audio output and
-declare `android.hardware.audio.output`.
-* Watch device implementations MAY but SHOULD NOT have audio output.
For the purposes of this section, an "output port" is a
[physical interface](https://en.wikipedia.org/wiki/Computer_port_%28hardware%29)
diff --git a/7_hardware-compatibility/7_9_virtual-reality.md b/7_hardware-compatibility/7_9_virtual-reality.md
index e9f9257..393058c 100644
--- a/7_hardware-compatibility/7_9_virtual-reality.md
+++ b/7_hardware-compatibility/7_9_virtual-reality.md
@@ -12,26 +12,8 @@
a feature which handles stereoscopic rendering of notifications and disables
monocular system UI components while a VR application has user focus.
-If Handheld device implementations include support for the VR mode, they:
-
-* [H-1-1] MUST declare the `android.software.vr.mode` feature.
-
-If device implementations declare `android.software.vr.mode` feature, they:
-
-* [H-2-1] MUST include an application implementing
-`android.service.vr.VrListenerService`
-that can be enabled by VR applications via
-`android.app.Activity#setVrModeEnabled`.
-
### 7.9.2\. Virtual Reality High Performance
-
-If Handheld device implementations are capable of meeting all the requirements
-to declare the `android.hardware.vr.high_performance` feature flag, they:
-
-* [H-1-1] MUST declare the `android.hardware.vr.high_performance`
-feature flag.
-
If device implementations identify the support of high performance VR
for longer user periods through the `android.hardware.vr.high_performance`
feature flag, they:
diff --git a/8_performance-and-power/8_1_user-experience-consistency.md b/8_performance-and-power/8_1_user-experience-consistency.md
index 9728f44..85f8a14 100644
--- a/8_performance-and-power/8_1_user-experience-consistency.md
+++ b/8_performance-and-power/8_1_user-experience-consistency.md
@@ -6,15 +6,3 @@
MAY have measurable requirements for the user interface latency and task
switching as described in [section 2](#2_device-types).
- * [H-0-1] **Consistent frame latency**. Inconsistent frame latency or a
-delay to render frames MUST NOT happen more often than 5 frames in a second,
-and SHOULD be below 1 frames in a second.
- * [H-0-2] **User interface latency**. Device implementations MUST ensure
-low latency user experience by scrolling a list of 10K list entries as defined
-by the Android Compatibility Test Suite (CTS) in less than 36 secs.
- * [H-0-3] **Task switching**. When multiple applications have been
-launched, re-launching an already-running application after it has been
-launched MUST take less than 1 second.
- * [T-0-1] **Consistent frame latency**. Inconsistent frame latency or a
-delay to render frames MUST NOT happen more often than 5 frames in a second,
-and SHOULD be below 1 frames in a second.
diff --git a/8_performance-and-power/8_2_file-io-access-performance.md b/8_performance-and-power/8_2_file-io-access-performance.md
index 7508aff..c667ec5 100644
--- a/8_performance-and-power/8_2_file-io-access-performance.md
+++ b/8_performance-and-power/8_2_file-io-access-performance.md
@@ -7,7 +7,6 @@
described in [section 2](#2_device-type) for the following read
and write operations:
-
* **Sequential write performance**. Measured by writing a 256MB file using
10MB write buffer.
* **Random write performance**. Measured by writing a 256MB file using 4KB
@@ -17,16 +16,3 @@
* **Random read performance**. Measured by reading a 256MB file using 4KB
write buffer.
-Handheld device implementations:
-
- * [H-0-1] MUST ensure a sequential write performance of at least 5MB/s.
- * [H-0-2] MUST ensure a random write performance of at least 0.5MB/s.
- * [H-0-3] MUST ensure a sequential read performance of at least 15MB/s.
- * [H-0-4] MUST ensure a random read performance of at least 3.5MB/s.
-
-Television device implementations:
-
- * [T-0-1] MUST ensure a sequential write performance of at least 5MB/s.
- * [T-0-2] MUST ensure a random write performance of at least 0.5MB/s.
- * [T-0-3] MUST ensure a sequential read performance of at least 15MB/s.
- * [T-0-4] MUST ensure a random read performance of at least 3.5MB/s.
\ No newline at end of file
diff --git a/8_performance-and-power/8_3_power-saving-modes.md b/8_performance-and-power/8_3_power-saving-modes.md
index a6a5bf3..6268303 100644
--- a/8_performance-and-power/8_3_power-saving-modes.md
+++ b/8_performance-and-power/8_3_power-saving-modes.md
@@ -2,25 +2,6 @@
Android includes App Standby and Doze power-saving modes to optimize battery
usage.
-
-* [H-0-1] All Apps exempted from App Standby and Doze power-saving modes
-MUST be made visible to the end user.
-* [H-0-2] The triggering, maintenance, wakeup algorithms and the use of
-global system settings of App Standby and Doze power-saving modes MUST not
-deviate from the Android Open Source Project.
-
-* [T-0-1] All Apps exempted from App Standby and Doze power-saving modes
-MUST be made visible to the end user.
-* [T-0-2] The triggering, maintenance, wakeup algorithms and the use of
-global system settings of App Standby and Doze power-saving modes MUST not
-deviate from the Android Open Source Project.
-
-* [A-0-1] All Apps exempted from App Standby and Doze power-saving modes
-MUST be made visible to the end user.
-* [A-0-2] The triggering, maintenance, wakeup algorithms and the use of
-global system settings of App Standby and Doze power-saving modes MUST not
-deviate from the Android Open Source Project.
-
* [SR] All Apps exempted from these modes are STRONGLY RECOMMENDED to be made
visible to the end user.
* [SR] The triggering, maintenance, wakeup algorithms and the use of
diff --git a/8_performance-and-power/8_4_power-consumption-accounting.md b/8_performance-and-power/8_4_power-consumption-accounting.md
index 0628b10..0e688fe 100644
--- a/8_performance-and-power/8_4_power-consumption-accounting.md
+++ b/8_performance-and-power/8_4_power-consumption-accounting.md
@@ -4,62 +4,6 @@
app developer both the incentives and the tools to optimize the power usage
pattern of the application.
-Handheld device implementations:
-
-* [H-0-1] MUST provide a per-component power profile that defines the
-[current consumption value](
-http://source.android.com/devices/tech/power/values.html)
-for each hardware component and the approximate battery drain caused by the
-components over time as documented in the Android Open Source Project site.
-* [H-0-2] MUST report all power consumption values in milliampere
-hours (mAh).
-* [H-0-3] MUST report CPU power consumption per each process's UID.
-The Android Open Source Project meets the requirement through the
-`uid_cputime` kernel module implementation.
-* SHOULD be attributed to the hardware component itself if unable to
-attribute hardware component power usage to an application.
-* [H-0-4] MUST make this power usage available via the
-[`adb shell dumpsys batterystats`](
-http://source.android.com/devices/tech/power/batterystats.html)
-shell command to the app developer.
-
-Television device implementations:
-
-* [T-0-1] MUST provide a per-component power profile that defines the
-[current consumption value](
-http://source.android.com/devices/tech/power/values.html)
-for each hardware component and the approximate battery drain caused by the
-components over time as documented in the Android Open Source Project site.
-* [T-0-2] MUST report all power consumption values in milliampere
-hours (mAh).
-* [T-0-3] MUST report CPU power consumption per each process's UID.
-The Android Open Source Project meets the requirement through the
-`uid_cputime` kernel module implementation.
-* SHOULD be attributed to the hardware component itself if unable to
-attribute hardware component power usage to an application.
-* [T-0-4] MUST make this power usage available via the
-[`adb shell dumpsys batterystats`](
-http://source.android.com/devices/tech/power/batterystats.html)
-shell command to the app developer.
-
-Automotive device implementations:
-
-* [A-0-1] MUST provide a per-component power profile that defines the
-[current consumption value](
-http://source.android.com/devices/tech/power/values.html)
-for each hardware component and the approximate battery drain caused by the
-components over time as documented in the Android Open Source Project site.
-* [A-0-2] MUST report all power consumption values in milliampere
-hours (mAh).
-* [A-0-3] MUST report CPU power consumption per each process's UID.
-The Android Open Source Project meets the requirement through the
-`uid_cputime` kernel module implementation.
-* SHOULD be attributed to the hardware component itself if unable to
-attribute hardware component power usage to an application.
-* [A-0-4] MUST make this power usage available via the
-[`adb shell dumpsys batterystats`](
-http://source.android.com/devices/tech/power/batterystats.html)
-shell command to the app developer.
Device implementations:
@@ -81,9 +25,4 @@
attribute hardware component power usage to an application.
-If Handheld device implementations include a screen or video output, they:
-
-* [H-1-1] MUST honor the [`android.intent.action.POWER_USAGE_SUMMARY`](
-http://developer.android.com/reference/android/content/Intent.html#ACTION_POWER_USAGE_SUMMARY)
-intent and display a settings menu that shows this power usage.
diff --git a/9_security-model/9_14_automotive-system-isolation.md b/9_security-model/9_14_automotive-system-isolation.md
index a1d5276..046ebd4 100644
--- a/9_security-model/9_14_automotive-system-isolation.md
+++ b/9_security-model/9_14_automotive-system-isolation.md
@@ -6,11 +6,5 @@
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:
+these subsystems.
-* [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.
\ No newline at end of file
diff --git a/9_security-model/9_1_permissions.md b/9_security-model/9_1_permissions.md
index 5fed443..0e8e5bb 100644
--- a/9_security-model/9_1_permissions.md
+++ b/9_security-model/9_1_permissions.md
@@ -38,14 +38,6 @@
* 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:
@@ -64,4 +56,4 @@
[`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.
\ No newline at end of file
+ equivalent behavior as when the user is declined for access.
diff --git a/9_security-model/9_5_multi-user-support.md b/9_security-model/9_5_multi-user-support.md
index 4f201e5..d266b0c 100644
--- a/9_security-model/9_5_multi-user-support.md
+++ b/9_security-model/9_5_multi-user-support.md
@@ -9,11 +9,6 @@
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
