diff options
| author | Gina Dimino <gdimino@google.com> | 2017-08-30 16:22:07 -0700 |
|---|---|---|
| committer | Gina Dimino <gdimino@google.com> | 2017-08-31 19:14:44 -0700 |
| commit | 0ece682cb7f915f4289ba6d7b5c86957e6d5d276 (patch) | |
| tree | 4abfad6e00a727cea659a1d7e06fa13889fa890a | |
| parent | 3aef255161f9b566a0c276e40a343daf2d2ffa51 (diff) | |
| download | platform_compatibility_cdd-0ece682cb7f915f4289ba6d7b5c86957e6d5d276.tar.gz platform_compatibility_cdd-0ece682cb7f915f4289ba6d7b5c86957e6d5d276.tar.bz2 platform_compatibility_cdd-0ece682cb7f915f4289ba6d7b5c86957e6d5d276.zip | |
Docs: Move dev-specific reqs to Ch 2.
Test: python make_cdd.py --version <version-number> --branch <mybranch>
Bug: 64164626
Change-Id: Ie091c0be79ad4a797f26a60e95ee2594f053f804
28 files changed, 962 insertions, 756 deletions
diff --git a/2_device-types/2_1_device-configurations.md b/2_device-types/2_1_device-configurations.md index 883d0490..6b04ddda 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 871375fe..104fb976 100644 --- a/2_device-types/2_2_handheld-reqs.md +++ b/2_device-types/2_2_handheld-reqs.md @@ -13,51 +13,301 @@ following criteria: 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: + +* [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> -More to be added. ### 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 @@ Android Handheld device implementations: **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 @@ policies defined in the Android SDK documentation. **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. -**Text-to-Speech (Section 3.11)** +* [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). -Android handheld device implementations: +**Text-to-Speech (Section 3.11)** -* [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 39ff09eb..7eeabd48 100644 --- a/2_device-types/2_3_television-reqs.md +++ b/2_device-types/2_3_television-reqs.md @@ -19,15 +19,189 @@ Television device implementations. ### 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 @@ Android Television device implementations: **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 @@ If Android Television device implementations support a lock screen,they: **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 @@ they: **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 500aab8b..25234601 100644 --- a/2_device-types/2_4_watch-reqs.md +++ b/2_device-types/2_4_watch-reqs.md @@ -15,15 +15,67 @@ Watch device implementations. ### 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 @@ Android Watch device implementations: **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-1-1] MUST support third-party accessibility services. -* [W-SR] Android Watch device implementations that declare `android.hardware. - audio.output` are STRONGLY RECOMMENDED to preload accessibility services on +* [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 @@ Android Watch device implementations: **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 d6f42710..65e09b85 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)** + +Automotive device implementations: + +* [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 a screen with the physical diagonal length equal to or greater - than 6 inches. +* [A-0-1] MUST have at least 4GB of non-volatile storage available for + application private data (a.k.a. "/data" partition) -More to be added. +**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 @@ To be added. **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 @@ Android Automotive device implementations: **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 00000000..387d53b9 --- /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 9676250a..0bca4021 100644 --- a/3_software/3_12_tv-input-framework.md +++ b/3_software/3_12_tv-input-framework.md @@ -5,9 +5,6 @@ http://source.android.com/devices/tv/index.html) simplifies the delivery of live 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 3837b1c3..b86a5909 100644 --- a/3_software/3_2_soft-api-compatibility.md +++ b/3_software/3_2_soft-api-compatibility.md @@ -252,15 +252,15 @@ intent patterns to perform common actions. 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 @@ flag: * [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 781376ec..c8d569ce 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 @@ they MUST support the following audio encoding: 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 4f97c1ec..3bc9d798 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 @@ to third-party apps, they: ### 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 255d5038..0d09babb 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 @@ table. * [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 @@ Main Profile, or the High Profile Level 4.2 ### 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 @@ equal to or greater than the video resolution, then: * [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 @@ following table. * [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 @@ equal to or greater than the video resolution, then: * [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 @@ VP9 hardware decoding, they: <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 363197e3..b0e6d45d 100644 --- a/5_multimedia/5_5_audio-playback.md +++ b/5_multimedia/5_5_audio-playback.md @@ -10,14 +10,14 @@ If device implementations declare `android.hardware.audio.output`, they: * [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 @@ controllable through the `AudioEffect` sub-classes `BassBoost`, ### 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 5df157e1..e75a7750 100644 --- a/5_multimedia/5_8_secure-media.md +++ b/5_multimedia/5_8_secure-media.md @@ -17,15 +17,3 @@ support wired external display, they: * [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 b9b8d0fd..ece4f9ff 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 @@ be 854/480 = 1.779, or roughly “16:9”. #### 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 @@ made by the user (for example, display size) set after initial boot. 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 @@ Android specifies a “compatibility mode” in which the framework operates in 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 @@ wireless, or an embedded additional display connection, they: * [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 66fda1d9..993db396 100644 --- a/7_hardware-compatibility/7_2_input-devices.md +++ b/7_hardware-compatibility/7_2_input-devices.md @@ -8,11 +8,6 @@ to navigate between the UI elements. ### 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 @@ Device implementations: 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 @@ functions typically provided via an interaction with a dedicated physical button 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 @@ manipulating items on screen. Since the user is directly touching the screen, 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 @@ or more pointer inputs fully independently. #### 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 @@ href="http://developer.android.com/reference/android/view/MotionEvent.html">Moti ### 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 20903411..7e43ea13 100644 --- a/7_hardware-compatibility/7_3_sensors.md +++ b/7_hardware-compatibility/7_3_sensors.md @@ -82,25 +82,6 @@ https://source.android.com/devices/sensors/sensor-types.html#composite_sensor_ty ### 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 @@ as part of each GPS Location. 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 @@ implement the `SENSOR_TYPE_GYROSCOPE_UNCALIBRATED` sensor. 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 @@ Note the `SENSOR_TYPE_TEMPERATURE` sensor type was deprecated in Android 4.0. ### 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 @@ Project. 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 @@ Device implementations: * 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 b8869d0b..9cd6ae45 100644 --- a/7_hardware-compatibility/7_4_data-connectivity.md +++ b/7_hardware-compatibility/7_4_data-connectivity.md @@ -162,10 +162,6 @@ APIs MUST throw an `UnsupportedOperationException`. ### 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 @@ respectively) and implement the platform APIs. * 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 @@ If device implementations include a metered connection, they are: * [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 674da7fc..c4f8fab4 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 @@ Device implementations: 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 @@ Device implementations: 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 0d4965ca..77f3b82f 100644 --- a/7_hardware-compatibility/7_7_usb.md +++ b/7_hardware-compatibility/7_7_usb.md @@ -6,11 +6,6 @@ If device implementations have a USB port, they: ### 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 SDK and MUST declare support for the hardware feature [`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 @@ fields specified in the [USB HID Usage Tables](http://www.usb.org/developers/hid 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 @@ described in the Appendix A of the 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 0279da41..32288e3a 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 @@ If device implementations do not include a speaker or audio output port, they: * [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 e9f92570..393058c6 100644 --- a/7_hardware-compatibility/7_9_virtual-reality.md +++ b/7_hardware-compatibility/7_9_virtual-reality.md @@ -12,26 +12,8 @@ https://developer.android.com/reference/android/app/Activity.html#setVrModeEnabl 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 9728f44e..85f8a140 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 @@ applications and games. Device implementations, depending on the device type, 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 7508aff6..c667ec51 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 @@ implementations, depending on the device type, MAY have certain requirements 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 @@ write buffer. * **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 a6a5bf34..6268303d 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 0628b101..0e688fe4 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 @@ A more accurate accounting and reporting of the power consumption provides the 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 @@ shell command to the app developer. 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 a1d5276a..046ebd40 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 @@ to send and receive messages over vehicle networks such as CAN bus. The data exchange can be secured by implementing security features below the Android framework layers to prevent malicious or unintentional interaction with -these subsystems. Automotive device implementations: +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 5fed4437..0e8e5bb6 100644 --- a/9_security-model/9_1_permissions.md +++ b/9_security-model/9_1_permissions.md @@ -38,14 +38,6 @@ Device implementations: * 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 @@ apps, from accessing the usage statistics, they: [`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 4f201e5e..d266b0ce 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 @@ and provides support for full user isolation. 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 |