resolve merge conflicts of 45bcfaf7a1b208ad21c8ba0c9cc8a75c6feeb6f6 to master
Test: I solemnly swear I tested this conflict resolution.
Change-Id: Ic969c832c2c6aa86e36ea9dcd155aa7f42a7e34d
diff --git a/2_device-types/2_2_handheld-reqs.md b/2_device-types/2_2_handheld-reqs.md
index af30054..1aad3f2 100644
--- a/2_device-types/2_2_handheld-reqs.md
+++ b/2_device-types/2_2_handheld-reqs.md
@@ -13,6 +13,11 @@
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)**
@@ -57,9 +62,171 @@
**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
+ * ldpi or lower on extra large screens
+ * mdpi or lower on large screens
+
+* [H-1-2] 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-1-3] 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-1-4] 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-2-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-2-2] 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-2-3] 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-2-4] 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.
+
+**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
@@ -103,35 +270,44 @@
**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`](
@@ -148,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)**
@@ -168,6 +346,8 @@
**Accessibility (Section 3.10)**
+Handheld device implementations:
+
* [H-0-1] MUST support third-party accessibility services.
* [H-SR] Are STRONGLY RECOMMENDED to preload accessibility services on the
@@ -178,21 +358,97 @@
**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 0a355cb..9cc44cd 100644
--- a/2_device-types/2_3_television-reqs.md
+++ b/2_device-types/2_3_television-reqs.md
@@ -69,6 +69,27 @@
* [T-0-1] MUST have at least 4GB of non-volatile storage available for
application private data (a.k.a. "/data" partition)
+If TV device implementations are 32-bit:
+
+* [T-1-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
+
+If TV device implementations are 64-bit:
+
+* [T-2-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
+
+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.
+
**Microphone (Section 7.8.1)**
Television device implementations:
@@ -84,11 +105,124 @@
### 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)
@@ -96,7 +230,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)**
@@ -107,8 +243,10 @@
**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)**
@@ -135,6 +273,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.
\ No newline at end of file
diff --git a/2_device-types/2_5_automotive-reqs.md b/2_device-types/2_5_automotive-reqs.md
index 2d9652e..2c2de18 100644
--- a/2_device-types/2_5_automotive-reqs.md
+++ b/2_device-types/2_5_automotive-reqs.md
@@ -2,14 +2,14 @@
**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.
@@ -122,6 +122,63 @@
* [A-0-1] MUST have at least 4GB of non-volatile storage available for
application private data (a.k.a. "/data" partition)
+If Automotive device implementations are 32-bit:
+
+* [A-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
+
+* [A-1-2] 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
+
+* [A-1-3] 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
+
+* [A-1-4] 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-2-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-2-2] 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-2-3] 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-2-4] 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.
+
**USB peripheral mode (Section 7.7.1)**
Automotive device implementations:
@@ -172,8 +229,11 @@
* [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).
@@ -182,7 +242,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)**
@@ -194,12 +256,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.
\ No newline at end of file