Merge "CDD: Requirement for Dynamics Processing Effect." into pi-dev
diff --git a/2_device-types/2_2_handheld-reqs.md b/2_device-types/2_2_handheld-reqs.md
index e61222c..f7b0671 100644
--- a/2_device-types/2_2_handheld-reqs.md
+++ b/2_device-types/2_2_handheld-reqs.md
@@ -252,6 +252,11 @@
[device administration](
http://developer.android.com/guide/topics/admin/device-admin.html)
policies defined in the Android SDK documentation.
+* [[3.9](#3_9_device-administration)/H-1-2] MUST declare the support of
+managed profiles via the `android.software.managed_users` feature flag, except when the device is configured so that it would [report](
+http://developer.android.com/reference/android/app/ActivityManager.html#isLowRamDevice%28%29)
+itself as a low RAM device or so that it allocates internal (non-removable)
+storage as shared storage.
Handheld device implementations:
diff --git a/2_device-types/2_3_television-reqs.md b/2_device-types/2_3_television-reqs.md
index 1ce2d6b..1161b6e 100644
--- a/2_device-types/2_3_television-reqs.md
+++ b/2_device-types/2_3_television-reqs.md
@@ -1,4 +1,3 @@
-## 2.3\. Television Requirements
An **Android Television device** refers to an Android device implementation that
is an entertainment interface for consuming digital media, movies, games, apps,
@@ -82,100 +81,69 @@
### 2.3.2\. Multimedia
-Television device implementations MUST support the following audio encoding:
+Television device implementations MUST support the following audio encoding formats:
* [[5.1](#5_1_media-codecs)/T-0-1] MPEG-4 AAC Profile (AAC LC)
* [[5.1](#5_1_media-codecs)/T-0-2] MPEG-4 HE AAC Profile (AAC+)
* [[5.1](#5_1_media-codecs)/T-0-3] AAC ELD (enhanced low delay AAC)
-Television device implementations MUST support the following video encoding:
+Television device implementations MUST support the following video encoding formats:
-* [[5.2](#5_2_video-encoding)/T-0-1] H.264 AVC
+* [[5.2](#5_2_video-encoding)/T-0-1] H.264
* [[5.2](#5_2_video-encoding)/T-0-2] VP8
Television device implementations:
* [[5.2](#5_2_video-encoding).2/T-SR] Are STRONGLY RECOMMENDED to support
-H.264 encoding of 720p and 1080p resolution videos.
-* [[5.2](#5_2_video-encoding)2/T-SR] Are STRONGLY RECOMMENDED to support H.264
-encoding of 1080p resolution video at 30 frame-per-second (fps).
+H.264 encoding of 720p and 1080p resolution videos at 30 frames per second.
-Television device implementations MUST support the following video decoding:
+Television device implementations MUST support the following video decoding formats:
-* [[5.3](#5_3_video-decoding)/T-0-1] H.264 AVC
-* [[5.3](#5_3_video-decoding)/T-0-2] H.265 HEVC
-* [[5.3](#5_3_video-decoding)/T-0-3] MPEG-4 SP
-* [[5.3](#5_3_video-decoding)/T-0-4] VP8
-* [[5.3](#5_3_video-decoding)/T-0-5] VP9
+* [[5.3.3](#5_3_video-decoding)/T-0-1] MPEG-4 SP
+* [[5.3.4](#5_3_video-decoding)/T-0-2] H.264 AVC
+* [[5.3.5](#5_3_video-decoding)/T-0-3] H.265 HEVC
+* [[5.3.6](#5_3_video-decoding)/T-0-4] VP8
+* [[5.3.7](#5_3_video-decoding)/T-0-5] VP9
Television device implementations are STRONGLY RECOMMENDED to support the
-following video decoding:
+following video decoding formats:
-* [[5.3](#5_3_video-decoding)/T-SR] MPEG-2
+* [[5.3.1](#5_3_video-decoding)/T-SR] MPEG-2
+Television device implementations MUST support H.264 decoding, as detailed in Section 5.3.4,
+at standard video frame rates and resolutions up to and including:
-If Television device implementations support H.264 decoders, they:
+* [[5.3.4](#5_3_video-decoding).4/T-1-1] HD 1080p at 60 frames per second with Basline Profile
+* [[5.3.4](#5_3_video-decoding).4/T-1-2] HD 1080p at 60 frames per second with Main Profile
+* [[5.3.4](#5_3_video-decoding).4/T-1-3] HD 1080p at 60 frames per second with High Profile Level 4.2
-* [[5.3](#5_3_video-decoding).4/T-1-1] MUST support High Profile Level 4.2 and
-the HD 1080p (at 60 fps) decoding profile.
-* [[5.3](#5_3_video-decoding).4/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
+Television device implementations with H.265 hardware decoders MUST support H.265 decoding,
+as detailed in Section 5.3.5, at standard video frame rates and resolutions up to and including:
-If Television device implementations support H.265 codec and the HD 1080p
-decoding profile, they:
+* [[5.3.5](#5_3_video-decoding).4/T-1-1] HD 1080p at 60 frames per second with Main Profile Level 4.1
-* [[5.3](#5_3_video-decoding).5/T-1-1] MUST support the Main Profile Level 4.1
-Main tier.
-* [[5.3](#5_3_video-decoding).5/T-SR] Are STRONGLY RECOMMENDED to support 60
-fps video frame rate for HD 1080p.
+If Television device implementations with H.265 hardware decoders support
+H.265 decoding and the UHD decoding profile, they:
-If Television device implementations support H.265 codec and the UHD decoding
-profile, then:
-
-* [[5.3](#5_3_video-decoding).5/T-2-1] The codec MUST support Main10 Level 5
+* [[5.3.5](#5_3_video-decoding).5/T-2-1] MUST support UHD 3480p at 60 frames per second with Main10 Level 5
Main Tier profile.
-If Television device implementations support VP8 codec, they:
+Television device implementations MUST support VP8 decoding, as detailed in Section 5.3.6,
+at standard video frame rates and resolutions up to and including:
-* [[5.3](#5_3_video-decoding).6/T-1-1] MUST support the HD 1080p60 decoding
-profile.
+* [[5.3.6](#5_3_video-decoding).4/T-1-1] HD 1080p at 60 frames per second decoding profile
-If Television device implementations support VP8 codec and support 720p, they:
+Television device implementations with VP9 hardware decoders MUST support VP9 decoding, as detailed in Section 5.3.7,
+at standard video frame rates and resolutions up to and including:
-* [[5.3](#5_3_video-decoding).6/T-2-1] MUST support the HD 720p60 decoding
-profile.
+* [[5.3.7](#5_3_video-decoding).4/T-1-1] HD 1080p at 60 frames per second with profile 0 (8 bit colour depth)
+If Television device implementations with VP9 hardware decoders support VP9 decoding and the UHD decoding
+profile, they:
-If Television device implementations support VP9 codec and the UHD video
-decoding, they:
-
-* [[5.3](#5_3_video-decoding).7/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:
-
-* [[5.3](#5_3_video-decoding).7/T-2-1] MUST support 60 fps for 1080p.
-
-Television device implementations:
-
-* [[5.8](#5_8_secure-media)/T-SR] Are STRONGLY RECOMMENDED to support
-simultaneous decoding of secure streams. At minimum, simultaneous decoding of
-two steams is STRONGLY RECOMMENDED.
-
-If device implementations are Android Television devices and support 4K
-resolution, they:
-
-* [[5.8](#5_8_secure-media)/T-1-1] MUST support HDCP 2.2 for all wired
-external displays.
-
-If Television device implementations don't support 4K resolution, they:
-
-* [[5.8](#5_8_secure-media)/T-2-1] MUST support HDCP 1.4 for all wired
-external displays.
+* [[5.3.7](#5_3_video-decoding).5/T-2-1] MUST support UHD 3480p at 60 frames per second with profile 0 (8 bit colour depth).
+* [[5.3.7](#5_3_video-decoding).5/T-2-1] Are STRONGLY RECOMMENDED to support UHD 3480p at 60 frames per second with profile 2 (10 bit colour depth).
Television device implementations:
@@ -183,6 +151,28 @@
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).
+* [[5.8](#5_8_secure-media)/T-0-1] MUST set the HDMI output mode to
+select the maximum resolution that can be supported with either 50Hz or 60Hz
+refresh rate for all wired displays.
+* [[5.8](#5_8_secure-media)/T-SR] Are STRONGLY RECOMMENDED to provide a user
+configurable HDMI refresh rate selector for all wired displays.
+* [[5.8](#5_8_secure-media)/T-SR] Are STRONGLY RECOMMENDED to support
+simultaneous decoding of secure streams. At minimum, simultaneous decoding of
+two steams is STRONGLY RECOMMENDED.
+* [[5.8](#5_8_secure-media)] SHOULD set the HDMI output mode refresh rate
+to either 50Hz or 60Hz, depending on the video refresh rate for the region the
+device is sold in for all wired displays.
+
+If Television device implementations support UHD decoding and have support
+for external displays, they:
+
+* [[5.8](#5_8_secure-media)/T-1-1] MUST support HDCP 2.2.
+
+If Television device implementations do not support UHD decoding but have
+support for external displays, they:
+
+* [[5.8](#5_8_secure-media)/T-2-1] MUST support HDCP 1.4
+
### 2.3.3\. Software
diff --git a/2_device-types/2_4_watch-reqs.md b/2_device-types/2_4_watch-reqs.md
index 6bfacc8..99468a9 100644
--- a/2_device-types/2_4_watch-reqs.md
+++ b/2_device-types/2_4_watch-reqs.md
@@ -78,3 +78,25 @@
* [[3.11](#3_11_text-to-speech)/W-0-1] MUST support installation of
third-party TTS engines.
+
+### 2.4.4\. Performance and Power
+
+Watch device implementations:
+
+* [[8.4](#8_4_power-consumption-accounting)/W-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.
+* [[8.4](#8_4_power-consumption-accounting)/W-0-2] MUST report all power
+consumption values in milliampere hours (mAh).
+* [[8.4](#8_4_power-consumption-accounting)/W-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.
+* [[8.4](#8_4_power-consumption-accounting)/W-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.
+* [[8.4](#8_4_power-consumption-accounting)/W] SHOULD be attributed to the
+hardware component itself if unable to attribute hardware component power usage
+to an application.
diff --git a/2_device-types/2_5_automotive-reqs.md b/2_device-types/2_5_automotive-reqs.md
index d529946..18030d9 100644
--- a/2_device-types/2_5_automotive-reqs.md
+++ b/2_device-types/2_5_automotive-reqs.md
@@ -75,9 +75,12 @@
`SENSOR_TYPE_DRIVING_STATUS` in compliance with all laws and regulations
that apply to markets where the product is shipping.
-* [[7.3](#7_3_sensors).11.4/A-0-1] MUST provide vehicle speed defined as
+* [[7.3](#7_3_sensors).11.4/A-0-1] MUST provide vehicle speed as defined by
`SENSOR_TYPE_CAR_SPEED`.
+* [[7.3](#7_3_sensors).11.5/A-0-1] MUST provide parking brake status as
+defined by `SENSOR_TYPE_PARKING_BRAKE`.
+
* [[7.4](#7_4_data-connectivity).3/A-0-1] MUST support Bluetooth and SHOULD
support Bluetooth LE.
* [[7.4](#7_4_data-connectivity).3/A-0-2] Android Automotive implementations
@@ -86,8 +89,8 @@
* Media playback over Audio Distribution Profile (A2DP).
* Media playback control over Remote Control Profile (AVRCP).
* Contact sharing using the Phone Book Access Profile (PBAP).
-* [[7.4](#7_4_data-connectivity).3/A] SHOULD support Message Access Profile
-(MAP).
+* [[7.4](#7_4_data-connectivity).3/A-SR] Are STRONGLY RECOMMENDED to support
+Message Access Profile (MAP).
* [[7.4](#7_4_data-connectivity).5/A] SHOULD include support for cellular
network based data connectivity.
@@ -96,6 +99,19 @@
non-volatile storage available for application private data
(a.k.a. "/data" partition).
+Automotive device implementations:
+
+* [[7.6](#7_6_memory-and-storage).1/A] SHOULD format the data partition
+to offer improved performance and longevity on flash storage, for example
+using `f2fs` file-system.
+
+If Automotive device implementations provide shared external storage via a
+portion of the internal non-removable storage, they:
+
+* [[7.6](#7_6_memory-and-storage).1/A-SR] Are STRONGLY RECOMMENDED to reduce
+I/O overhead on operations performed on the external storage, for example by
+using `SDCardFS`.
+
If Automotive device implementations are 32-bit:
* [[7.6](#7_6_memory-and-storage).1/A-1-1] The memory available to the kernel
@@ -213,8 +229,12 @@
API when requested by third-party applications.
* [[3.8](#3_8_user-interface-compatibility).4/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).
+assistant on the device that provides a default implementation of the
+[`VoiceInteractionSession`](https://developer.android.com/reference/android/service/voice/VoiceInteractionSession)
+service.
+
+* [[3.13](#3_13_quick_settings)/A-SR] Are STRONGLY RECOMMENDED to include a
+Quick Settings UI component.
* [[3.14](#3_14_media_ui)/A-0-1] MUST include a UI framework to support
third-party apps using the media APIs as described in section 3.14.
diff --git a/3_software/3_14_media-ui.md b/3_software/3_14_media-ui.md
index 18d0f14..fb6d358 100644
--- a/3_software/3_14_media-ui.md
+++ b/3_software/3_14_media-ui.md
@@ -14,7 +14,9 @@
* [C-1-2] MUST display those items as described by MediaSession, e.g.,
metadata, icons, imagery.
* [C-1-3] MUST show app title.
-* [C-1-4] MUST have drawer to present [MediaBrowser](
+* [C-1-4] MUST have a drawer or other mechanism to present [MediaBrowser](
+ http://developer.android.com/reference/android/media/browse/MediaBrowser.html)
+ hierarchy and provide user affordance for the [MediaBrowser](
http://developer.android.com/reference/android/media/browse/MediaBrowser.html)
hierarchy.
* [C-1-5] MUST consider double tap of [`KEYCODE_HEADSETHOOK`](
diff --git a/3_software/3_3_native-api-compatibility.md b/3_software/3_3_native-api-compatibility.md
index b6b7e43..1fe7f37 100644
--- a/3_software/3_3_native-api-compatibility.md
+++ b/3_software/3_3_native-api-compatibility.md
@@ -56,6 +56,7 @@
* liblog (Android logging)
* libmediandk.so (native media APIs support)
* libm (math library)
+ * libneuralnetworks.so (Neural Networks API)
* libOpenMAXAL.so (OpenMAX AL 1.0.1 support)
* libOpenSLES.so (OpenSL ES 1.0.1 audio support)
* libRS.so
@@ -77,8 +78,8 @@
Note that while all the symbols MUST be present, section 7.1.4.1 describes
in more detail the requirements for when the full implementation of each
corresponding functions are expected.
-* [C-0-12] MUST export function symbols for the core Vulkan 1.0 function
- symobls, as well as the `VK_KHR_surface`, `VK_KHR_android_surface`,
+* [C-0-12] MUST export function symbols for the core Vulkan 1.1 function
+ symbols, as well as the `VK_KHR_surface`, `VK_KHR_android_surface`,
`VK_KHR_swapchain`, `VK_KHR_maintenance1`, and
`VK_KHR_get_physical_device_properties2` extensions through the
`libvulkan.so` library. Note that while all the symbols MUST be present,
diff --git a/3_software/3_8_user-interface-compatibility.md b/3_software/3_8_user-interface-compatibility.md
index 9d0a5a1..f464e6b 100644
--- a/3_software/3_8_user-interface-compatibility.md
+++ b/3_software/3_8_user-interface-compatibility.md
@@ -140,6 +140,9 @@
third-party app's notification per each channel and app package level.
* [C-1-6] MUST also provide a user affordance to display deleted notification
channels.
+* [C-SR] Are STRONGLY RECOMMENDED to automatically surface a user affordance
+ to block a certain third-party app's notification per each channel and app
+ package level after the user dismisses that notification multiple times.
* SHOULD support rich notifications.
* SHOULD present some higher priority notifications as heads-up notifications.
* SHOULD have a user affordance to snooze notifications.
diff --git a/3_software/3_9_device-administration.md b/3_software/3_9_device-administration.md
index eb50d95..f33b5be 100644
--- a/3_software/3_9_device-administration.md
+++ b/3_software/3_9_device-administration.md
@@ -13,12 +13,6 @@
* [C-1-2] MUST support device owner provisioning as described in
[section 3.9.1](#3_9_1_device_provisioning) and
[section 3.9.1.1](#3_9_1_1_device_owner_provisioning).
-* [C-1-3] MUST declare the support of manged profiles via the
- `android.software.managed_users` feature flag, except for when the device is
- configured so that it would [report](
- http://developer.android.com/reference/android/app/ActivityManager.html#isLowRamDevice%28%29)
- itself as a low RAM device or so that it allocate internal (non-removable)
- storage as shared storage.
### 3.9.1 Device Provisioning
diff --git a/5_multimedia/5_5_audio-playback.md b/5_multimedia/5_5_audio-playback.md
index ef43045..f510887 100644
--- a/5_multimedia/5_5_audio-playback.md
+++ b/5_multimedia/5_5_audio-playback.md
@@ -10,9 +10,13 @@
* [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, 8-bit, float
+ * **Channels**: Mono, Stereo, valid multichannel configurations
+ with up to 8 channels
+ * **Sampling rates (in Hz)**:
+ * 8000, 11025, 16000, 22050, 32000, 44100, 48000 at the channel
+ configurations listed above
+ * 96000 in mono and stereo
* SHOULD allow playback of raw audio content with the following
characteristics:
diff --git a/5_multimedia/5_6_audio-latency.md b/5_multimedia/5_6_audio-latency.md
index 7edea1e..cefc797 100644
--- a/5_multimedia/5_6_audio-latency.md
+++ b/5_multimedia/5_6_audio-latency.md
@@ -38,6 +38,10 @@
* **AAudio native audio API**. The set of
[AAudio](https://developer.android.com/ndk/guides/audio/aaudio/aaudio.html) APIs
within [Android NDK](https://developer.android.com/ndk/index.html).
+* **Timestamp**. A pair consisting of a relative frame position within a
+stream and the estimated time when that frame enters or leaves the
+audio processing pipeline on the associated endpoint. See also
+[AudioTimestamp](https://developer.android.com/reference/android/media/AudioTimestamp).
If device implementations declare `android.hardware.audio.output` they are
STRONGLY RECOMMENDED to meet or exceed the following requirements:
@@ -45,6 +49,9 @@
* [SR] Cold output latency of 100 milliseconds or less
* [SR] Continuous output latency of 45 milliseconds or less
* [SR] Minimize the cold output jitter
+* [SR] The output timestamp returned by
+[AudioTrack.getTimestamp](https://developer.android.com/reference/android/media/AudioTrack.html#getTimestamp(android.media.AudioTimestamp))
+and `AAudioStream_getTimestamp` is accurate to +/- 1 ms.
If device implementations meet the above requirements after any initial
calibration when using the OpenSL ES PCM buffer queue API, for continuous output
@@ -67,4 +74,7 @@
* [SR] Cold input latency of 100 milliseconds or less
* [SR] Continuous input latency of 30 milliseconds or less
* [SR] Continuous round-trip latency of 50 milliseconds or less
- * [SR] Minimize the cold input jitter
\ No newline at end of file
+ * [SR] Minimize the cold input jitter
+ * [SR] Limit the error in input timestamps, as returned by
+[AudioRecord.getTimestamp](https://developer.android.com/reference/android/media/AudioRecord.html#getTimestamp(android.media.AudioTimestamp,%20int))
+or `AAudioStream_getTimestamp`, to +/- 1 ms.
diff --git a/7_hardware-compatibility/7_1_display-and-graphics.md b/7_hardware-compatibility/7_1_display-and-graphics.md
index 853ba1b..e90ee0c 100644
--- a/7_hardware-compatibility/7_1_display-and-graphics.md
+++ b/7_hardware-compatibility/7_1_display-and-graphics.md
@@ -190,11 +190,11 @@
If device implementations include a screen or video output, they:
-* [C-1-1] MUST support both OpenGL ES 1.0 and 2.0, as embodied and detailed
+* [C-1-1] MUST support both OpenGL ES 1.1 and 2.0, as embodied and detailed
in the [Android SDK documentation](
https://developer.android.com/guide/topics/graphics/opengl.html).
-* [SR] are STRONGLY RECOMMENDED to support OpenGL ES 3.0.
-* SHOULD support OpenGL ES 3.1 or 3.2.
+* [SR] are STRONGLY RECOMMENDED to support OpenGL ES 3.1.
+* SHOULD support OpenGL ES 3.2.
If device implementations support any of the OpenGL ES versions, they:
@@ -238,15 +238,15 @@
https://www.khronos.org/registry/vulkan/specs/1.0-wsi&lowbarextensions/xhtml/vkspec.html)
, a low-overhead, cross-platform API for high-performance 3D graphics.
-If device implementations support OpenGL ES 3.0 or 3.1, they:
+If device implementations support OpenGL ES 3.1, they:
-* [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.0 .
+* [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.1.
If device implementations include a screen or video output, they:
-* SHOULD include support for Vulkan 1.0.
+* SHOULD include support for Vulkan 1.1.
-Device implementations, if including support for Vulkan 1.0:
+If device implementations include support for Vulkan 1.0, they:
* [C-1-1] MUST report the correct integer value with the
`android.hardware.vulkan.level` and `android.hardware.vulkan.version`
@@ -271,14 +271,22 @@
* [C-1-6] MUST report all extension strings that they do support via the
Vulkan native APIs , and conversely MUST NOT report extension strings
that they do not correctly support.
+* [C-1-7] MUST support the VK_KHR_surface, VK_KHR_android_surface, VK_KHR_swapchain,
+ and VK_KHR_incremental_present extensions
-Device implementations, if not including support for Vulkan 1.0:
+If device implementations do not include support for Vulkan 1.0, they:
* [C-2-1] MUST NOT declare any of the Vulkan feature flags (e.g.
`android.hardware.vulkan.level`, `android.hardware.vulkan.version`).
* [C-2-2] MUST NOT enumarate any `VkPhysicalDevice` for the Vulkan native API
`vkEnumeratePhysicalDevices()`.
+If device implementations include support for Vulkan 1.1, they:
+
+* [C-3-1] MUST expose support for the `SYNC_FD` external semaphore and handle types.
+* [SR] Are STRONGLY RECOMMENDED to support the
+ `VK_ANDROID_external_memory_android_hardware_buffer` extension.
+
#### 7.1.4.3 RenderScript
* [C-0-1] Device implementations MUST support [Android RenderScript](
diff --git a/7_hardware-compatibility/7_3_sensors.md b/7_hardware-compatibility/7_3_sensors.md
index 8da2e19..870f67b 100644
--- a/7_hardware-compatibility/7_3_sensors.md
+++ b/7_hardware-compatibility/7_3_sensors.md
@@ -563,6 +563,10 @@
See [Section 2.5.1](#2_5_1_hardware) for device-specific requirements.
+#### 7.3.11.5\. Parking Brake
+
+See [Section 2.5.1](#2_5_1_hardware) for device-specific requirements.
+
## 7.3.12\. Pose Sensor
diff --git a/7_hardware-compatibility/7_4_data-connectivity.md b/7_hardware-compatibility/7_4_data-connectivity.md
index 080170d..4c3da94 100644
--- a/7_hardware-compatibility/7_4_data-connectivity.md
+++ b/7_hardware-compatibility/7_4_data-connectivity.md
@@ -89,17 +89,18 @@
* Even when the screen is not in an active state.
* For Android Television device implementations, even when in standby
power states.
-* SHOULD randomize the source MAC address and sequence number of probe
-request frames, once at the beginning of each scan, while STA is disconnected.
+* [C-SR] Are STRONGLY RECOMMENDED to randomize the source MAC address and
+sequence number of probe request frames, once at the beginning of each scan,
+while STA is disconnected.
* Each group of probe request frames comprising one scan should use one
consistent MAC address (SHOULD NOT randomize MAC address halfway through a
scan).
* Probe request sequence number should iterate as normal (sequentially)
- between the probe requests in a scan
+ between the probe requests in a scan.
* Probe request sequence number should randomize between the last probe
- request of a scan and the first probe request of the next scan
-* SHOULD only allow the following information elements in probe request
-frames, while STA is disconnected:
+ request of a scan and the first probe request of the next scan.
+* [C-SR] Are STRONGLY RECOMMENDED, while STA is disconnected, to allow only
+the following elements in probe request frames:
* SSID Parameter Set (0)
* DS Parameter Set (3)
@@ -154,6 +155,20 @@
* [C-1-4] MUST randomize the Wi-Fi Aware management interface address at intervals
no longer then 30 minutes and whenever Wi-Fi Aware is enabled.
+If device implementations include support for Wi-Fi Aware and
+Wi-Fi Location as described in [Section 7.4.2.5](#7_4_2_5_Wi-Fi_Location) and
+exposes these functionalities to third-party apps, then they:
+
+* [C-2-1] MUST implement the location-aware discovery APIs: [setRangingEnabled](
+https://developer.android.com/reference/android/net/wifi/aware/PublishConfig.Builder.html#setRangingEnabled%28boolean%29),
+ [setMinDistanceMm](
+https://developer.android.com/reference/android/net/wifi/aware/SubscribeConfig.Builder#setMinDistanceMm%28int%29),
+ [setMaxDistanceMm](
+https://developer.android.com/reference/android/net/wifi/aware/SubscribeConfig.Builder#setMaxDistanceMm%28int%29)
+, and
+ [onServiceDiscoveredWithinRange](
+https://developer.android.com/reference/android/net/wifi/aware/DiscoverySessionCallback#onServiceDiscoveredWithinRange%28android.net.wifi.aware.PeerHandle,%20byte[],%20java.util.List%3Cbyte[]%3E,%20int%29).
+
#### 7.4.2.4\. Wi-Fi Passpoint
Device implementations:
@@ -176,6 +191,24 @@
* [C-2-1] The implementation of the Passpoint related `WifiManager`
APIs MUST throw an `UnsupportedOperationException`.
+#### 7.4.2.5\. Wi-Fi Location (Wi-Fi Round Trip Time - RTT)
+
+Device implementations:
+
+* SHOULD include support for [Wi-Fi Location](
+ https://www.wi-fi.org/discover-wi-fi/wi-fi-location).
+
+If device implementations include support for Wi-Fi Location and expose the
+functionality to third-party apps, then they:
+
+* [C-1-1] MUST implement the `WifiRttManager` APIs as described in the
+[SDK documentation](
+http://developer.android.com/reference/android/net/wifi/rtt/WifiRttManager.html).
+* [C-1-2] MUST declare the `android.hardware.wifi.rtt` feature flag.
+* [C-1-3] MUST randomize the source MAC address for each RTT burst
+ which is executed while the Wi-Fi interface on which the RTT is
+ being executed is not associated to an Access Point.
+
### 7.4.3\. Bluetooth
If device implementations support Bluetooth Audio profile, they:
@@ -364,40 +397,55 @@
at least one data standard capable of 200Kbit/sec or greater. Examples of
technologies that satisfy this requirement include EDGE, HSPA, EV-DO,
802.11g, Ethernet, Bluetooth PAN, etc.
+* SHOULD also include support for at least one common wireless data
+standard, such as 802.11 (Wi-Fi) when a physical networking standard (such as
+Ethernet) is the primary data connection
+* MAY implement more than one form of data connectivity.
* [C-0-2] MUST include an IPv6 networking stack and support IPv6
communication using the managed APIs, such as `java.net.Socket` and
`java.net.URLConnection`, as well as the native APIs, such as `AF_INET6`
sockets.
* [C-0-3] MUST enable IPv6 by default.
* MUST ensure that IPv6 communication is as reliable as IPv4, for example.
- * [C-0-4] MUST maintain IPv6 connectivity in doze mode.
- * [C-0-5] Rate-limiting MUST NOT cause the device to lose IPv6
- connectivity on any IPv6-compliant network that uses RA lifetimes of
- at least 180 seconds.
-* SHOULD also include support for at least one common wireless data
-standard, such as 802.11 (Wi-Fi) when a physical networking standard (such as
-Ethernet) is the primary data connection
-* MAY implement more than one form of data connectivity.
+ * [C-0-4] MUST maintain IPv6 connectivity in doze mode.
+ * [C-0-5] Rate-limiting MUST NOT cause the device to lose IPv6
+ connectivity on any IPv6-compliant network that uses RA lifetimes of
+ at least 180 seconds.
+
+When connected to an IPv6-capable network:
+
+* [C-1-1] devices MUST provide applications with direct IPv6 connectivity to
+the network, without any form
+of address or port translation happening locally on the device. Both managed
+APIs such as
+[`Socket#getLocalAddress`](https://developer.android.com/reference/java/net/Socket.html#getLocalAddress%28%29)
+or
+[`Socket#getLocalPort`](https://developer.android.com/reference/java/net/Socket.html#getLocalPort%28%29))
+and NDK APIs such as `getsockname()` or `IPV6_PKTINFO` MUST return the IP
+address and port that is actually used to send and receive packets on the
+network.
The required level of IPv6 support depends on the network type, as follows:
If devices implementations support Wi-Fi networks, they:
-* [C-1-1] MUST support dual-stack and IPv6-only operation on Wi-Fi.
+* [C-2-1] MUST support dual-stack and IPv6-only operation on Wi-Fi.
-If device impelementations support Ethernet networks, they:
+If device implementations support Ethernet networks, they:
-* [C-2-1] MUST support dual-stack operation on Ethernet.
+* [C-3-1] MUST support dual-stack operation on Ethernet.
If device implementations support cellular data, they:
-* [C-3-1] MUST simultaneously meet these requirements on each network to which
-it is connected when a device is simultaneously connected to more than one
-network (e.g., Wi-Fi and cellular data), .
-* SHOULD support IPv6 operation (IPv6-only and possibly dual-stack) on
+* [C-4-1] SHOULD support IPv6 operation (IPv6-only and possibly dual-stack) on
cellular data.
+When devices are simultaneously connected to more than one network, (e.g., Wi-Fi
+and cellular data), they:
+* [C-5-1] MUST simultaneously meet these requirements on each network to which
+they are connected.
+
### 7.4.6\. Sync Settings
diff --git a/7_hardware-compatibility/7_5_cameras.md b/7_hardware-compatibility/7_5_cameras.md
index b5da828..2d63f88 100644
--- a/7_hardware-compatibility/7_5_cameras.md
+++ b/7_hardware-compatibility/7_5_cameras.md
@@ -191,6 +191,16 @@
* [C-0-10] MUST broadcast the `Camera.ACTION_NEW_VIDEO`
intent whenever a new video is recorded by the camera and the entry of the
picture has been added to the media store.
+* [C-SR] Are STRONGLY RECOMMENDED to support a logical camera device that lists
+capability
+[`CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA`](
+https://developer.android.com/reference/android/hardware/camera2/CameraMetadata#REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA),
+for devices with multiple cameras facing the same direction, consisting of each
+physical camera facing that direction, as long as the physical camera type is
+supported by the framework and
+[`CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL`](
+https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics#INFO_SUPPORTED_HARDWARE_LEVEL)
+for the physical cameras is either `LIMITED`, `FULL`, or `LEVEL_3`.
### 7.5.5\. Camera Orientation
diff --git a/7_hardware-compatibility/7_7_usb.md b/7_hardware-compatibility/7_7_usb.md
index 20c1be6..90db766 100644
--- a/7_hardware-compatibility/7_7_usb.md
+++ b/7_hardware-compatibility/7_7_usb.md
@@ -42,8 +42,8 @@
* SHOULD implement the Android Open Accessory (AOA) API and specification as
documented in the Android SDK documentation.
-If device implementations including a USB port, implement the AOA specification,
-they:
+If device implementations include a USB port and implement the AOA
+specification, they:
* [C-2-1] MUST declare support for the hardware feature
[`android.hardware.usb.accessory`](http://developer.android.com/guide/topics/connectivity/usb/accessory.html).
diff --git a/9_security-model/9_15_subscription-plans.md b/9_security-model/9_15_subscription-plans.md
new file mode 100644
index 0000000..bd3e46b
--- /dev/null
+++ b/9_security-model/9_15_subscription-plans.md
@@ -0,0 +1,12 @@
+## 9.15\. Subscription Plans
+
+"Subscription plans" refer to the billing relationship plan details provided
+by a mobile carrier through [`SubscriptionManager.setSubscriptionPlans()`](https://developer.android.com/reference/android/telephony/SubscriptionManager.html#setSubscriptionPlans%28int, java.util.List<android.telephony.SubscriptionPlan>%29).
+
+All device implementations:
+
+* [C-0-1] MUST return subscription plans only to the mobile carrier app that
+has originally provided them.
+* [C-0-2] MUST NOT remotely back up or upload subscription plans.
+* [C-0-3] MUST only allow overrides, such as [`SubscriptionManager.setSubscriptionOverrideCongested()`](https://developer.android.com/reference/android/telephony/SubscriptionManager.html#setSubscriptionOverrideCongested%28int, boolean, long%29),
+from the mobile carrier app currently providing valid subscription plans.
diff --git a/9_security-model/9_7_kernel-security-features.md b/9_security-model/9_7_kernel-security-features.md
index a6a5d8d..33151fb 100644
--- a/9_security-model/9_7_kernel-security-features.md
+++ b/9_security-model/9_7_kernel-security-features.md
@@ -35,18 +35,25 @@
* [C-0-8] MUST implement strict kernel memory protections where executable
code is read-only, read-only data is non-executable and non-writable, and
writable data is non-executable (e.g. `CONFIG_DEBUG_RODATA` or `CONFIG_STRICT_KERNEL_RWX`).
+* [C-0-9] MUST implement static and dynamic object size
+bounds checking of copies between user-space and kernel-space
+(e.g. `CONFIG_HARDENED_USERCOPY`) on devices originally shipping with API level
+28 or higher.
+* [C-0-10] MUST NOT execute user-space memory when executing
+in the kernel mode (e.g. hardware PXN, or emulated via
+`CONFIG_CPU_SW_DOMAIN_PAN` or `CONFIG_ARM64_SW_TTBR0_PAN`) on devices
+originally shipping with API level 28 or higher.
+* [C-0-11] MUST NOT read or write user-space memory in the
+kernel outside of normal usercopy access APIs (e.g. hardware PAN, or
+emulated via `CONFIG_CPU_SW_DOMAIN_PAN` or `CONFIG_ARM64_SW_TTBR0_PAN`)
+on devices originally shipping with API level 28 or higher.
+* [C-0-12] MUST implement kernel page table isolation on all devices with CPUs
+vulnerable to CVE-2017-5754 (Meltdown), and on all devices with kernel versions
+4.4 or higher on devices originally shipping with API level 28 or higher
+(e.g. `CONFIG_PAGE_TABLE_ISOLATION` or `CONFIG_UNMAP_KERNEL_AT_EL0).
* [SR] STRONGLY RECOMMENDED to keep kernel data
which is written only during initialization marked read-only after
initialization (e.g. `__ro_after_init`).
-* [SR} STRONGLY RECOMMENDED to implement static and dynamic object size
-bounds checking of copies between user-space and kernel-space
-(e.g. `CONFIG_HARDENED_USERCOPY`).
-* [SR] STRONGLY RECOMMENDED to never execute user-space memory when running
-in the kernel (e.g. hardware PXN, or emulated via
-`CONFIG_CPU_SW_DOMAIN_PAN` or `CONFIG_ARM64_SW_TTBR0_PAN`).
-* [SR] STRONGLY RECOMMENDED to never read or write user-space memory in the
-kernel outside of normal usercopy access APIs (e.g. hardware PAN, or
-emulated via `CONFIG_CPU_SW_DOMAIN_PAN` or `CONFIG_ARM64_SW_TTBR0_PAN`).
* [SR] STRONGLY RECOMMENDED to randomize the layout of the kernel code and
memory, and to avoid exposures that would compromise the randomization
(e.g. `CONFIG_RANDOMIZE_BASE` with bootloader entropy via the
@@ -64,6 +71,9 @@
within the system/sepolicy folder provided in the upstream Android Open Source
Project (AOSP) and the policy MUST compile with all neverallow rules present,
for both AOSP SELinux domains as well as device/vendor specific domains.
+* [C-1-5] MUST run third-party applications targeting API level 28 or higher
+in per-application SELinux sandboxes with per-app SELinux restrictions on each
+application's private data directory.
* SHOULD retain the default SELinux policy provided in the system/sepolicy
folder of the upstream Android Open Source Project and only further add to this
policy for their own device-specific configuration.
@@ -72,4 +82,4 @@
If device implementations use kernel other than Linux, they:
* [C-2-1] MUST use an mandatory access control system that is
-equivalent to SELinux.
\ No newline at end of file
+equivalent to SELinux.
diff --git a/9_security-model/9_8_privacy.md b/9_security-model/9_8_privacy.md
index a1799a4..8990a82 100644
--- a/9_security-model/9_8_privacy.md
+++ b/9_security-model/9_8_privacy.md
@@ -8,12 +8,21 @@
Device implementations:
* [C-0-1] MUST keep a reasonable retention period of such user history.
+* [C-0-2] MUST only include the fields marked with `DEST_AUTOMATIC` in the
+ incident report created by the System API class `IncidentManager`.
* [SR] Are STRONGLY RECOMMENDED to keep the 14 days retention period as
configured by default in the AOSP implementation.
### 9.8.2\. Recording
+Device implementations:
+
+* [C-0-1] MUST NOT preload or distribute software components out-of-box that
+ send the user's private information (e.g. keystrokes, text displayed on the
+ screen) off the device without the user's consent or clear ongoing
+ notifications.
+
If device implementations include functionality in the system that captures
the contents displayed on the screen and/or records the audio stream played
on the device, they:
@@ -74,4 +83,4 @@
always-on VPN service in the `AndroidManifest.xml` file via setting the
[`SERVICE_META_DATA_SUPPORTS_ALWAYS_ON`](
https://developer.android.com/reference/android/net/VpnService.html#SERVICE_META_DATA_SUPPORTS_ALWAYS_ON)
- attribute to `false`.
\ No newline at end of file
+ attribute to `false`.