Merge "CDD: Tightening kernel security requirements from SR to MUST" 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/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/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 0b5da6c..33151fb 100644
--- a/9_security-model/9_7_kernel-security-features.md
+++ b/9_security-model/9_7_kernel-security-features.md
@@ -71,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.
