Merge "CDD: Relaxing the Media UI requirement to present MediaBrowser hierarchy." into pi-dev
diff --git a/2_device-types/2_3_television-reqs.md b/2_device-types/2_3_television-reqs.md
index 1ce2d6b..0cf24ed 100644
--- a/2_device-types/2_3_television-reqs.md
+++ b/2_device-types/2_3_television-reqs.md
@@ -82,83 +82,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.
+* [[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:
diff --git a/5_multimedia/5_5_audio-playback.md b/5_multimedia/5_5_audio-playback.md
index b0e6d45..5cca863 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_4_data-connectivity.md b/7_hardware-compatibility/7_4_data-connectivity.md
index 080170d..6f823fa 100644
--- a/7_hardware-compatibility/7_4_data-connectivity.md
+++ b/7_hardware-compatibility/7_4_data-connectivity.md
@@ -364,40 +364,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.