diff --git a/2_device-types/2_1_device-configurations.md b/2_device-types/2_1_device-configurations.md
index 883d049..6b04ddd 100644
--- a/2_device-types/2_1_device-configurations.md
+++ b/2_device-types/2_1_device-configurations.md
@@ -1,132 +1,4 @@
 ## 2.1 Device Configurations
 
-This is a summary of major differences in hardware configuration by device
-type. (Empty cells denote a “MAY”). Not all configurations are covered in this
-table; see relevant hardware sections for more detail.
-
-<table>
- <tr>
-    <th>Category</th>
-    <th>Feature</th>
-    <th>Section</th>
-    <th>Handheld</th>
-    <th>Television</th>
-    <th>Watch</th>
-    <th>Automotive</th>
-    <th>Other</th>
- </tr>
- <tr>
-    <td rowspan="3">Input</td>
-    <td>D-pad</td>
-    <td><a href="#7_2_2_non-touch-navigation">7.2.2. Non-touch Navigation</a></td>
-    <td></td>
-    <td>MUST</td>
-    <td></td>
-    <td></td>
-    <td></td>
- </tr>
- <tr>
-    <td>Touchscreen </td>
-    <td><a href="#7_2_4_touchscreen_input">7.2.4. Touchscreen input</a></td>
-    <td>MUST</td>
-    <td></td>
-    <td>MUST</td>
-    <td></td>
-    <td>SHOULD</td>
- </tr>
- <tr>
-    <td>Microphone </td>
-    <td><a href="#7_8_1_microphone">7.8.1. Microphone</a></td>
-    <td>MUST</td>
-    <td>SHOULD </td>
-    <td>MUST</td>
-    <td>MUST</td>
-    <td>SHOULD</td>
- </tr>
- <tr>
-    <td rowspan="2">Sensors</td>
-    <td>Accelerometer </td>
-    <td><a href="#7_3_1_accelerometer">7.3.1 Accelerometer</a></td>
-    <td>SHOULD</td>
-    <td></td>
-    <td>SHOULD</td>
-    <td></td>
-    <td>SHOULD</td>
- </tr>
- <tr>
-    <td>GPS</td>
-    <td><a href="#7_3_3_gps">7.3.3. GPS</a></td>
-    <td>SHOULD</td>
-    <td></td>
-    <td></td>
-    <td>SHOULD</td>
-    <td></td>
- </tr>
- <tr>
-    <td rowspan="5">Connectivity</td>
-    <td>Wi-Fi</td>
-    <td><a href="#7_4_2_ieee_802.11">7.4.2. IEEE 802.11</a></td>
-    <td>SHOULD</td>
-    <td>SHOULD</td>
-    <td></td>
-    <td>SHOULD</td>
-    <td>SHOULD</td>
- </tr>
- <tr>
-    <td>Wi-Fi Direct</td>
-    <td><a href="#7_4_2_1_wi-fi-direct">7.4.2.1. Wi-Fi Direct</a></td>
-    <td>SHOULD</td>
-    <td>SHOULD</td>
-    <td></td>
-    <td></td>
-    <td>SHOULD</td>
- </tr>
- <tr>
-    <td>Bluetooth</td>
-    <td><a href="#7_4_3_bluetooth">7.4.3. Bluetooth</a></td>
-    <td>SHOULD</td>
-    <td>MUST</td>
-    <td>MUST</td>
-    <td>MUST</td>
-    <td>SHOULD</td>
- </tr>
- <tr>
-    <td>Bluetooth Low Energy</td>
-    <td><a href="#7_4_3_bluetooth">7.4.3. Bluetooth</a></td>
-    <td>SHOULD</td>
-    <td>MUST</td>
-    <td>SHOULD</td>
-    <td>SHOULD</td>
-    <td>SHOULD</td>
- </tr>
- <tr>
-    <td>Cellular radio</td>
-    <td><a href="#7_4_5_minimum_network_capability">
-      7.4.5. Minimum Network Capability</a></td>
-    <td></td>
-    <td></td>
-    <td></td>
-    <td>SHOULD</td>
-    <td></td>
- </tr>
- <tr>
-    <td>USB</td>
-    <td>USB peripheral/host mode</td>
-    <td><a href="#7_7_usb">7.7. USB</a></td>
-    <td>SHOULD</td>
-    <td></td>
-    <td></td>
-    <td>SHOULD</td>
-    <td>SHOULD</td>
- </tr>
- <tr>
-    <td>Output</td>
-    <td>Speaker and/or Audio output ports</td>
-    <td><a href="#7_8_2_audio_output">7.8.2. Audio Output</a></td>
-    <td>MUST</td>
-    <td>MUST</td>
-    <td></td>
-    <td>MUST</td>
-    <td>MUST</td>
- </tr>
-</table>
+For the major differences in hardware configuration by device
+type, see the device-specific requirements that follow in this section.
diff --git a/2_device-types/2_2_handheld-reqs.md b/2_device-types/2_2_handheld-reqs.md
index 871375f..104fb97 100644
--- a/2_device-types/2_2_handheld-reqs.md
+++ b/2_device-types/2_2_handheld-reqs.md
@@ -13,51 +13,301 @@
 The additional requirements in the rest of this section are specific to Android
 Handheld device implementations.
 
+
+<div class="note">
+<b>Note:</b> Requirements that do not apply to Android Tablet devices are marked with an *.
+</div>
+
 ### 2.2.1\. Hardware
 
+**Screen Size (Section 7.1.1.1)**
+
+Handheld device implementations:
+
+*   [H-0-1] MUST have a screen at least 2.5 inches in physical diagonal size.<sup>*</sup>
+
+**Screen Density (Section 7.1.1.3)**
+
+Handheld device implementations:
+
+*    [H-SR] Are STRONGLY RECOMMENDED to provide users an affordance to change
+     the display size.
+
+**Legacy Application Compatibility Mode (Section 7.1.5)**
+
+Handheld device implementations:
+
+*   [H-0-1] MUST include support for legacy application compatibility mode as
+    implemented by the upstream Android open source code. That is, device
+    implementations MUST NOT alter the triggers or thresholds at which
+    compatibility mode is activated, and MUST NOT alter the behavior of the
+    compatibility mode itself.
+
+**Keyboard (Section 7.2.1)**
+
+Handheld device implementations:
+
+*    [H-0-1] MUST include support for third-party Input Method Editor (IME)
+     applications.
+
+**Navigation Keys (Section 7.2.3)**
+
+Handheld device implementations:
+
+*   [H-0-1] MUST provide the Home, Recents, and Back functions.
+
+*   [H-0-2] MUST send both the normal and long press event of the the Back
+    function ([`KEYCODE_BACK`](http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK))
+    to the foreground application.
+
 **Touchscreen Input (Section 7.2.4)**
 
-*   [H-0-1]  Handheld devices MUST have a touchscreen embedded in the device.
+Handheld device implementations:
 
-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<sup>*</sup>
+     *    ldpi or lower on extra large screens
+     *    mdpi or lower on large screens
+
+*    [H-2-1] The memory available to the kernel and userspace MUST
+be at least 608MB if any of the following densities are used:
+     *   xhdpi or higher on small/normal screens<sup>*</sup>
+     *   hdpi or higher on large screens
+     *   mdpi or higher on extra large screens
+
+*    [H-3-1] The memory available to the kernel and userspace MUST
+be at least 896MB if any of the following densities are used:
+     *   400dpi or higher on small/normal screens<sup>*</sup>
+     *   xhdpi or higher on large screens
+     *   tvdpi or higher on extra large screens
+
+*     [H-4-1] The memory available to the kernel and userspace MUST
+be at least 1344MB if any of the following densities are used:
+     *   560dpi or higher on small/normal screens<sup>*</sup>
+     *   400dpi or higher on large screens
+     *   xhdpi or higher on extra large screens
+
+If Handheld device implementations are 64-bit:
+
+*    [H-5-1] The memory available to the kernel and userspace MUST
+be at least 816MB if any of the following densities are used:
+     *   280dpi or lower on small/normal screens<sup>*</sup>
+     *   ldpi or lower on extra large screens
+     *   mdpi or lower on large screens
+
+*    [H-6-1] The memory available to the kernel and userspace MUST
+be at least 944MB if any of the following densities are used:
+     *   xhdpi or higher on small/normal screens<sup>*</sup>
+     *   hdpi or higher on large screens
+     *   mdpi or higher on extra large screens
+
+*    [H-7-1] The memory available to the kernel and userspace MUST
+be at least 1280MB if any of the following densities are used:
+     *  400dpi or higher on small/normal screens<sup>*</sup>
+     *  xhdpi or higher on large screens
+     *  tvdpi or higher on extra large screens
+
+*    [H-8-1] The memory available to the kernel and userspace MUST
+be at least 1824MB if any of the following densities are used:
+     *   560dpi or higher on small/normal screens<sup>*</sup>
+     *   400dpi or higher on large screens
+     *   xhdpi or higher on extra large screens
+
+Note that the "memory available to the kernel and userspace" above refers to the
+memory space provided in addition to any memory already dedicated to hardware
+components such as radio, video, and so on that are not under the kernel’s
+control on device implementations.
+
+**Application Shared Storage (Section 7.6.2)**
+
+Handheld device implementations:
+
+*   [H-0-1] MUST NOT provide an application shared storage smaller than 1 GiB.
+
+**USB peripheral mode (Section 7.7.1)**
+
+Handheld device implementations:
+
+*   SHOULD include a USB port supporting peripheral mode.
+
+If handheld device implementations include a USB port supporting peripheral
+mode, they:
+
+*    [H-1-1] MUST implement the Android Open Accessory (AOA) API.<sup>*</sup>
+
+**Microphone (Section 7.8.1)**
+
+Handheld device implementations:
+
+*    [H-0-1] MUST include a microphone.
+
+**Audio Output (Section 7.8.2)**
+
+Handheld device implementations:
+
+*   [H-0-1] MUST have an audio output and declare
+    `android.hardware.audio.output`.
+
+**Virtual Reality Mode (Section 7.9.1)**
+
+If Handheld device implementations include support for the VR mode, they:
+
+*   [H-1-1] MUST declare the `android.software.vr.mode` feature.<sup>*</sup>
+
+
+If device implementations declare `android.software.vr.mode` feature, they:
+
+*   [H-2-1] MUST include an application implementing
+`android.service.vr.VrListenerService`
+that can be enabled by VR applications via
+`android.app.Activity#setVrModeEnabled`.<sup>*</sup>
+
+
+**Virtual Reality High Performance (Section 7.9.2)**
+
+If Handheld device implementations are capable of meeting all the requirements
+to declare the `android.hardware.vr.high_performance` feature flag, they:
+
+*   [H-1-1] MUST declare the `android.hardware.vr.high_performance`
+feature flag.<sup>*</sup>
+
 
 ### 2.2.2\. Multimedia
 
-To be added.
+**Audio Encoding (Section 5.1.1)**
+
+Handheld device implementations MUST support the following audio encoding:
+
+*    [H-0-1] AMR-NB
+*    [H-0-2] AMR-WB
+*    [H-0-3] MPEG-4 AAC Profile (AAC LC)
+*    [H-0-4] MPEG-4 HE AAC Profile (AAC+)
+*    [H-0-5] AAC ELD (enhanced low delay AAC)
+
+
+**Audio Decoding (Section 5.1.2)**
+
+Handheld device implementations MUST support the following audio decoding:
+
+*    [H-0-1] AMR-NB
+*    [H-0-2] AMR-WB
+
+**Video Encoding (Section 5.2)**
+
+Handheld device implementations MUST support the following video encoding and
+make it available to third-party applications:
+
+*    [H-0-1] H.264 AVC
+*    [H-0-2] VP8
+
+**Video Decoding (Section 5.3)**
+
+Handheld device implementations MUST support the following video decoding:
+
+*    [H-0-1] H.264 AVC.
+*    [H-0-2] H.265 HEVC.
+*    [H-0-3] MPEG-4 SP.
+*    [H-0-4] VP8.
+*    [H-0-5] VP9.
 
 ### 2.2.3\. Software
 
 **WebView Compatibility (Section 3.4.1)**
 
-*   [H-0-1] Handheld devices MUST provide a complete implementation of the android.webkit.Webview API.
+Handheld device implementations:
+
+*   [H-0-1] MUST provide a complete implementation of the
+    `android.webkit.Webview` API.
 
 **Browser Compatibility (Section 3.4.2)**
 
-*   [H-0-1] Handheled device implementations MUST include a standalone Browser application for general
+Handheld device implementations:
+
+*   [H-0-1] MUST include a standalone Browser application for general
 user web browsing.
 
 **Launcher (Section 3.8.1)**
 
-*   [H-SR] Handheld device implementations are STRONGLY RECOMMENDED to implement a default launcher
+Handheld device implementations:
+
+*   [H-SR] Are STRONGLY RECOMMENDED to implement a default launcher
     that supports in-app pinning of shortcuts and widgets.
 
-*   [H-SR] Device implementations are STRONGLY RECOMMENDED to implement a default launcher that
+*   [H-SR] Are STRONGLY RECOMMENDED to implement a default launcher that
     provides quick access to the additional shortcuts provided by third-party apps through the
     [ShortcutManager](
     https://developer.android.com/reference/android/content/pm/ShortcutManager.html) API.
 
-*   [H-SR] Handheld devices are STRONGLY RECOMMENDED to include a default
+*   [H-SR] Are STRONGLY RECOMMENDED to include a default
     launcher app that shows badges for the app icons.
 
 **Widgets (Section 3.8.2)**
 
-*   [H-SR] Handheld Device implementations are STRONGLY RECOMMENDED to support
+Handheld device implementations:
+
+*   [H-SR] Are STRONGLY RECOMMENDED to support
     third-party app widgets.
 
 
 **Notifications (Section 3.8.3)**
 
-Android Handheld device implementations:
+Handheld device implementations:
 
 *   [H-0-1] MUST allow third-party apps to notify users
     of notable events through the [`Notification`](
@@ -74,8 +324,10 @@
 
 **Search (Section 3.8.4)**
 
-*   [H-SR] Handheld device implementations are STRONGLY RECOMMENDED to implement
-    an assistant on the device to handle the [Assist action](
+Handheld device implementations:
+
+*   [H-SR] Are STRONGLY RECOMMENDED to implement an assistant on the device to
+    handle the [Assist action](
     http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST).
 
 **Lock Screen Media Control (Section 3.8.10)**
@@ -94,32 +346,110 @@
 
 **Accessibility (Section 3.10)**
 
-*  [H-SR] Android Handheld device implementations MUST support third-party
-   accessibility services.
+Handheld device implementations:
 
-*  [H-SR] Android Handheld device implementations are STRONGLY RECOMMENDED to
-   preload accessibility services on the device comparable with or exceeding
-   functionality of the Switch Access and TalkBack (for languages supported by
-   the preloaded Text-to-speech engine) accessibility services as provided in
-   the [talkback open source project](https://github.com/google/talkback).
+*  [H-SR] MUST support third-party accessibility services.
+
+*  [H-SR] Are STRONGLY RECOMMENDED to preload accessibility services on the
+   device comparable with or exceeding functionality of the Switch Access and
+   TalkBack (for languages supported by the preloaded Text-to-speech engine)
+   accessibility services as provided in the [talkback open source
+   project](https://github.com/google/talkback).
 
 **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&lowbar;USAGE&lowbar;ACCESS&lowbar;SETTINGS)
+    intent.
+
diff --git a/2_device-types/2_3_television-reqs.md b/2_device-types/2_3_television-reqs.md
index 39ff09e..7eeabd4 100644
--- a/2_device-types/2_3_television-reqs.md
+++ b/2_device-types/2_3_television-reqs.md
@@ -19,15 +19,189 @@
 
 ### 2.3.1\. Hardware
 
-To be added.
+**Non-touch Navigation (Section 7.2.2)**
+
+Television device implementations:
+
+*    [T-0-1] MUST support [D-pad](https://developer.android.com/reference/android/content/res/Configuration.html#NAVIGATION_DPAD).
+
+**Navigation Keys (Section 7.2.3)**
+
+Television device implementations:
+
+*   [T-0-1] MUST provide the Home and Back functions.
+*   [T-0-2] MUST send both the normal and long press event of the the Back
+    function
+    ([`KEYCODE_BACK`](http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK))
+    to the foreground application.
+
+**Button Mappings (Section 7.2.6.1)**
+
+Television device implementations:
+
+*    [T-0-1] MUST include support for game controllers and declare the
+`android.hardware.gamepad` feature flag.
+
+**Remote Control (Section 7.2.7)**
+
+Television device implementations:
+
+*    SHOULD provide a remote control from which users can access
+[non-touch navigation](#7_2_2_non-touch_navigation) and
+[core navigation keys](#7_2_3_navigation_keys) inputs.
+
+**Gyroscope (Section 7.3.4)**
+
+If Television device implementations include a gyroscope, they:
+
+*   [T-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
+
+**Bluetooth (Section 7.4.3)**
+
+Television device implementations:
+
+*    [T-0-1] MUST support Bluetooth and Bluetooth LE.
+
+**Minimum Memory and Storage (Section 7.6.1)**
+
+Television device implementations:
+
+*   [T-0-1] MUST have at least 4GB of non-volatile storage available for
+    application private data (a.k.a. "/data" partition)
+
+**Microphone (Section 7.8.1)**
+
+Television device implementations:
+
+*   SHOULD include a microphone.
+
+**Audio Output (Section 7.8.2)**
+
+Television device implementations:
+
+*   [T-0-1] MUST have an audio output and declare
+    `android.hardware.audio.output`.
 
 ### 2.3.2\. Multimedia
 
-To be added.
+**Audio Encoding (Section 5.1)**
+
+Television device implementations MUST support the following audio encoding:
+
+*    [T-0-1] MPEG-4 AAC Profile (AAC LC)
+*    [T-0-2] MPEG-4 HE AAC Profile (AAC+)
+*    [T-0-3] AAC ELD (enhanced low delay AAC)
+
+
+**Video Encoding (Section 5.2)**
+
+Television device implementations MUST support the following video encoding:
+
+*    [T-0-1] H.264 AVC
+*    [T-0-2] VP8
+
+**H-264 (Section 5.2.2)**
+
+Television device implementations are:
+
+*   [T-SR] STRONGLY RECOMMENDED to support H.264 encoding of 720p and 1080p
+resolution videos.
+*   [T-SR] STRONGLY RECOMMENDED to support H.264 encoding of 1080p resolution
+video at 30 frame-per-second (fps).
+
+**Video Decoding (Section 5.3)**
+
+Television device implementations MUST support the following video decoding:
+
+*    [T-0-1] H.264 AVC
+*    [T-0-2] H.265 HEVC
+*    [T-0-3] MPEG-4 SP
+*    [T-0-4] VP8
+*    [T-0-5] VP9
+
+Television device implementations are STRONGLY RECOMMENDED to support the
+following video decoding:
+
+*    [T-SR] MPEG-2
+
+**H.264 (Section 5.3.4)**
+
+If Television device implementations support H.264 decoders, they:
+
+*   [T-1-1] MUST support High Profile Level 4.2 and the HD 1080p (at 60 fps)
+decoding profile.
+*   [T-1-2] MUST be capable of decoding videos with both HD profiles as
+indicated in the following table and encoded with either the Baseline Profile,
+Main Profile, or the High Profile Level 4.2
+
+**H.265 (HEVC) (Section 5.3.5)**
+
+If Television device implementations support H.265 codec and the HD 1080p
+decoding profile, they:
+
+*   [T-1-1] MUST support the Main Profile Level 4.1 Main tier.
+*   [T-SR]  Are STRONGLY RECOMMENDED to support 60 fps video frame rate
+for HD 1080p.
+
+If Television device implementations support H.265 codec and the UHD decoding
+profile, then:
+
+*   [T-2-1] The codec MUST support Main10 Level 5 Main Tier profile.
+
+**VP8 (Section 5.3.6)**
+
+If Television device implementations support VP8 codec, they:
+
+*   [T-1-1] MUST support the HD 1080p60 decoding profile.
+
+If Television device implementations support VP8 codec and support 720p, they:
+
+*   [T-2-1] MUST support the HD 720p60 decoding profile.
+
+
+**VP9 (Section 5.3.7)**
+
+If Television device implementations support VP9 codec and the UHD video
+decoding, they:
+
+*   [T-1-1] MUST support 8-bit color depth and SHOULD support VP9 Profile 2
+(10-bit).
+
+If Television device implementations support VP9 codec, the 1080p profile and
+VP9 hardware decoding, they:
+
+*   [T-2-1] MUST support 60 fps for 1080p.
+
+**Secure Media (Section 5.8)**
+
+If device implementations are Android Television devices and support 4K
+resolution, they:
+
+*    [T-1-1] MUST support HDCP 2.2 for all wired external displays.
+
+If Television device implementations don't support 4K resolution, they:
+
+*    [T-2-1] MUST support HDCP 1.4 for all wired external displays.
+
+Television device implementations:
+
+*    [T-SR] Are STRONGLY RECOMMENDED to support simulataneous decoding of secure
+     streams. At minimum, simultaneous decoding of two steams is STRONGLY
+     RECOMMENDED.
+
+**Audio Output Volume (Section 5.5.3)**
+
+Television device implementations:
+
+*   [T-0-1] MUST include support for system Master Volume and digital audio
+output volume attenuation on supported outputs,
+except for compressed audio passthrough output (where no audio decoding is done
+on the device).
+
 
 ### 2.3.3\. Software
 
-Android Television device implementations:
+Television device implementations:
 
 *    [T-0-1] MUST declare the features
      [`android.software.leanback`](http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK)
@@ -35,7 +209,9 @@
 
 **WebView compatibility (Section 3.4.1)**
 
-*    [T-0-1] Television devices MUST provide a complete implementation of the android.webkit.Webview API.
+Television device implementations:
+
+*    [T-0-1] MUST provide a complete implementation of the `android.webkit.Webview` API.
 
 
 **Lock Screen Media Control (Section 3.8.10)**
@@ -46,13 +222,16 @@
 
 **Multi-windows (Section 3.8.14)**
 
-*   [T-SR] Android Television device implementations are STRONGLY RECOMMENDED to
-    support picture-in-picture (PIP) mode multi-window.
+Television device implementations:
+
+*   [T-SR] Are STRONGLY RECOMMENDED to support picture-in-picture (PIP) mode
+    multi-window.
 
 **Accessibility (Section 3.10)**
 
-*   [T-SR] Android Television device implementations MUST support third-party
-    accessibility services.
+Television device implementations:
+
+*   [T-SR] MUST support third-party accessibility services.
 
 *   [T-SR] Android Television device implementations are STRONGLY RECOMMENDED to
     preload accessibility services on the device comparable with or exceeding
@@ -73,6 +252,58 @@
 
 **TV Input Framework (Section 3.12)**
 
-To be added.
+Television device implementations:
+
+*    [T-0-1] MUST support TV Input Framework.
 
 
+### 2.2.4\. Performance and Power
+
+
+**User Experience Consistency (Section 8.1)**
+
+For Television device implementations:
+
+   *   [T-0-1] **Consistent frame latency**. Inconsistent frame latency or a
+delay to render frames MUST NOT happen more often than 5 frames in a second,
+and SHOULD be below 1 frames in a second.
+
+**File I/O Access Performance (Section 8.2)**
+
+Television device implementations:
+
+   *   [T-0-1] MUST ensure a sequential write performance of at least 5MB/s.
+   *   [T-0-2] MUST ensure a random write performance of at least 0.5MB/s.
+   *   [T-0-3] MUST ensure a sequential read performance of at least 15MB/s.
+   *   [T-0-4] MUST ensure a random read performance of at least 3.5MB/s.
+
+**Power-Saving Modes (Section 8.3)**
+
+For Television device implementations:
+
+*   [T-0-1] All Apps exempted from App Standby and Doze power-saving modes
+MUST be made visible to the end user.
+*   [T-0-2] The triggering, maintenance, wakeup algorithms and the use of
+global system settings of App Standby and Doze power-saving modes MUST not
+deviate from the Android Open Source Project.
+
+**Power Consumption Accounting (Sections 8.4)**
+
+Television device implementations:
+
+*    [T-0-1] MUST provide a per-component power profile that defines the
+[current consumption value](
+http://source.android.com/devices/tech/power/values.html)
+for each hardware component and the approximate battery drain caused by the
+components over time as documented in the Android Open Source Project site.
+*    [T-0-2] MUST report all power consumption values in milliampere
+hours (mAh).
+*    [T-0-3] MUST report CPU power consumption per each process's UID.
+The Android Open Source Project meets the requirement through the
+`uid_cputime` kernel module implementation.
+*    SHOULD be attributed to the hardware component itself if unable to
+attribute hardware component power usage to an application.
+*   [T-0-4] MUST make this power usage available via the
+[`adb shell dumpsys batterystats`](
+http://source.android.com/devices/tech/power/batterystats.html)
+shell command to the app developer.
diff --git a/2_device-types/2_4_watch-reqs.md b/2_device-types/2_4_watch-reqs.md
index 500aab8..2523460 100644
--- a/2_device-types/2_4_watch-reqs.md
+++ b/2_device-types/2_4_watch-reqs.md
@@ -15,15 +15,67 @@
 
 ### 2.4.1\. Hardware
 
-To be added.
+**Screen Size (Section 7.1.1.1)**
+
+Watch device implementations:
+
+*   [W-0-1] MUST have a screen with the physical diagonal size in the range from
+    1.1 to 2.5 inches.
+
+**Navigation Keys (Section 7.2.3)**
+
+Watch device implementations:
+
+*   [W-0-1] MUST have the Home function available to the user, and the Back
+    function except for when it is in `UI_MODE_TYPE_WATCH`.
+
+**Touchscreen Input (Section 7.2.4)**
+
+Watch device implementations:
+
+*    [W-0-2] MUST support touchscreen input.
+
+**Accelerometer (Section 7.3.1)**
+
+Watch device implementations:
+
+*   [W-SR] Are STRONGLY RECOMMENDED to include a 3-axis accelerometer.
+
+**Bluetooth (Section 7.4.3)**
+
+Watch device implementations:
+
+*    [W-0-1] MUST support Bluetooth.
+
+
+**Minimum Memory and Storage (Section 7.6.1)**
+
+Watch device implementations:
+
+*   [W-0-1] MUST have at least 1GB of non-volatile storage available for
+    application private data (a.k.a. "/data" partition)
+*   [W-0-2] MUST have at least 416MB memory available to the kernel and
+    userspace.
+
+**Microphone (Section 7.8.1)**
+
+Watch device implementations:
+
+*    [W-0-1] MUST include a microphone.
+
+**Audio Output (Section 7.8.1)**
+
+Watch device implementations:
+
+*   MAY but SHOULD NOT have audio output.
 
 ### 2.4.2\. Multimedia
 
-To be added.
+No additional requirements.
 
 ### 2.4.3\. Software
 
-Android Watch device implementations:
+Watch device implementations:
 
 *   [W-0-1] MUST declare the feature android.hardware.type.watch.
 *   [W-0-2] MUST support uiMode =
@@ -32,19 +84,20 @@
 
 **Search (Section 3.8.4)**
 
-*   [W-SR] Watch device implementations are STRONGLY RECOMMENDED to implement
-    an assistant on the device to handle the [Assist action](
+Watch device implementations:
+
+*   [W-SR] Are STRONGLY RECOMMENDED to implement an assistant on the device to
+    handle the [Assist action](
     http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST).
 
 
 **Accessibility (Section 3.10)**
 
-*   [W-1-1] Android Watch device implementations that declare the
-    `android.hardware.audio.output` feature flag MUST support third-party
-    accessibility services.
+Watch device implementations that declare the `android.hardware.audio.output` feature flag:
 
-*   [W-SR] Android Watch device implementations that declare `android.hardware.
-    audio.output` are STRONGLY RECOMMENDED to preload accessibility services on
+*   [W-1-1]  MUST support third-party accessibility services.
+
+*   [W-SR] Are STRONGLY RECOMMENDED to preload accessibility services on
     the device comparable with or exceeding functionality of the Switch Access
     and TalkBack (for languages supported by the preloaded Text-to-speech
     engine) accessibility services as provided in the [talkback open source
@@ -52,10 +105,10 @@
 
 **Text-to-Speech (Section 3.11)**
 
-If device implementations report the feature android.hardware.audio.output,
+If Watch device implementations report the feature android.hardware.audio.output,
 they:
 
-*   [W-SR] STRONGLY RECOMMENDED to include a TTS engine supporting the
+*   [W-SR] Are STRONGLY RECOMMENDED to include a TTS engine supporting the
     languages available on the device.
 
 *   [W-0-1] MUST support installation of third-party TTS engines.
diff --git a/2_device-types/2_5_automotive-reqs.md b/2_device-types/2_5_automotive-reqs.md
index d6f4271..65e09b8 100644
--- a/2_device-types/2_5_automotive-reqs.md
+++ b/2_device-types/2_5_automotive-reqs.md
@@ -2,33 +2,181 @@
 
 **Android Automotive implementation** refers to a vehicle head unit running
 Android as an operating system for part or all of the system and/or
-infotainment functionality. Android Automotive implementations:
+infotainment functionality.
 
 Android device implementations are classified as an Automotive if they declare
 the feature `android.hardware.type.automotive` or meet all the following
 criteria.
 
-*   are embedded as part of, or pluggable to, an automotive vehicle.
-*   are using a screen in the driver's seat row as the primary display.
+*   Are embedded as part of, or pluggable to, an automotive vehicle.
+*   Are using a screen in the driver's seat row as the primary display.
 
 The additional requirements in the rest of this section are specific to Android
 Automotive device implementations.
 
 ### 2.5.1\. Hardware
 
-Android Automotive device implementations:
+**Screen Size (Section 7.1.1.1)**
 
-*   [A-0-1] MUST have a screen with the physical diagonal length equal to or greater
-    than 6 inches.
+Automotive device implementations:
 
-More to be added.
+*   [A-0-1] MUST have a screen at least 6 inches in physical diagonal size.
+*   [A-0-2] MUST have a screen size layout of at least 750 dp x 480 dp.
+
+**Navigation Keys (Section 7.2.3)**
+
+Automotive device implementations:
+
+*   [A-0-1] MUST provide the Home function and MAY provide Back and Recent
+    functions.
+*   [A-0-2] MUST send both the normal and long press event of the the Back
+    function
+    ([`KEYCODE_BACK`](http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK))
+    to the foreground application.
+
+**Accelerometer (Section 7.3.1)**
+
+Automotive device implementations:
+
+*   [A-SR] Are STRONGLY RECOMMENDED to include a 3-axis accelerometer.
+
+If Automotive device implementations include a 3-axis accelerometer, they:
+
+*   [A-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
+*   [A-1-2] MUST comply with the Android
+    [car sensor coordinate system](
+    http://source.android.com/devices/sensors/sensor-types.html#auto_axes).
+
+**GPS (Section 7.3.3)**
+
+If Automotive device implementations include a GPS/GNSS receiver and report
+the capability to applications through the `android.hardware.location.gps`
+feature flag:
+
+*   [A-1-1] GNSS technology generation MUST be the year "2017" or newer.
+
+**Gyroscope (Section 7.3.4)**
+
+If Automotive device implementations include a gyroscope, they:
+
+*   [A-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
+
+**Android Automotive-only sensors (Section 7.3.11)**
+**Current Gear (Section 7.3.11.1)**
+
+Automotive device implementations:
+
+*    SHOULD provide current gear as `SENSOR_TYPE_GEAR`.
+
+**Day Night Mode (Section 7.3.11.2)**
+
+Automotive device implementations:
+
+*    [A-0-1] MUST support day/night mode defined as `SENSOR_TYPE_NIGHT`.
+*    [A-0-2] The value of the `SENSOR_TYPE_NIGHT` flag MUST be consistent with
+     dashboard day/night mode and SHOULD be based on ambient light sensor input.
+*    The underlying ambient light sensor MAY be the same as
+[Photometer](#7_3_7_photometer).
+
+**Driving Status (Section 7.3.11.3)**
+
+Automotive device implementations:
+
+*    [A-0-1] MUST support driving status defined as
+     `SENSOR_TYPE_DRIVING_STATUS`, with a default value of
+     `DRIVE_STATUS_UNRESTRICTED` when the vehicle is fully stopped and parked.
+     It is the responsibility of device manufacturers to configure
+     `SENSOR_TYPE_DRIVING_STATUS` in compliance with all laws and regulations
+     that apply to markets where the product is shipping.
+
+**Wheel Speed (Section 7.3.11.4)**
+
+Automotive device implementations:
+
+*    [A-0-1] MUST provide vehicle speed defined as `SENSOR_TYPE_CAR_SPEED`.
+
+**Bluetooth (Section 7.4.3)**
+
+Automotive device implementations:
+
+*    [A-0-1] MUST support Bluetooth and SHOULD support Bluetooth LE.
+
+*    [A-0-2] Android Automotive implementations MUST support the following
+     Bluetooth profiles:
+     * Phone calling over Hands-Free Profile (HFP).
+     * Media playback over Audio Distribution Profile (A2DP).
+     * Media playback control over Remote Control Profile (AVRCP).
+     * Contact sharing using the Phone Book Access Profile (PBAP).
+*    SHOULD support Message Access Profile (MAP).
+
+**Minimum Network Capability (Section 7.4.5)**
+
+Automotive device implementations:
+
+*   SHOULD include support for cellular network based data connectivity.
+
+**Minimum Memory and Storage (Section 7.6.1)**
+
+Automotive device implementations:
+
+*   [A-0-1] MUST have at least 4GB of non-volatile storage available for
+    application private data (a.k.a. "/data" partition)
+
+**USB peripheral mode (Section 7.7.1)**
+
+Automotive device implementations:
+
+*   SHOULD include a USB port supporting peripheral mode.
+
+**Microphone (Section 7.8.1)**
+
+Automotive device implementations:
+
+*    [A-0-1] MUST include a microphone.
+
+**Audio Output (Section 7.8.2)**
+
+Automotive device implementations:
+
+*   [A-0-1] MUST have an audio output and declare
+    `android.hardware.audio.output`.
 
 ### 2.5.2\. Multimedia
 
-To be added.
+**Audio Encoding (Section 5.1)**
+
+Automotive device implementations MUST support the following audio encoding:
+
+*    [A-1-1] MPEG-4 AAC Profile (AAC LC)
+*    [A-1-2] MPEG-4 HE AAC Profile (AAC+)
+*    [A-1-3] AAC ELD (enhanced low delay AAC)
+
+**Video Encoding (Section 5.2)**
+
+Automotive device implementations MUST support the following video encoding:
+
+*    [A-0-1] H.264 AVC
+*    [A-0-2] VP8
+
+**Video Decoding (Section 5.3)**
+
+Automotive device implementations MUST support the following video decoding:
+
+*    [A-0-1] H.264 AVC
+*    [A-0-2] MPEG-4 SP
+*    [A-0-3] VP8
+*    [A-0-4] VP9
+
+Automotive device implementations are STRONGLY RECOMMENDED to support the
+following video decoding:
+
+*    [A-SR] H.265 HEVC
+
 
 ### 2.5.3\. Software
 
+Automotive device implementations:
+
 *   [A-0-1] MUST declare the feature android.hardware.type.automotive.
 *   [A-0-2] MUST support uiMode =
     [UI_MODE_TYPE_CAR](http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR).
@@ -37,7 +185,9 @@
 
 **WebView Compatibility (Section 3.4.1)**
 
-*   [A-0-1] Automobile devices MUST provide a complete implementation of the android.webkit.Webview API.
+Automotive device implementations:
+
+*   [A-0-1] MUST provide a complete implementation of the `android.webkit.Webview API`.
 
 **Notifications (Section 3.8.3)**
 
@@ -49,12 +199,69 @@
 
 **Search (Section 3.8.4)**
 
-*   [A-0-1] Android Automotive implementations MUST implement an assistant on
-    the device to handle the [Assist action](
+Automotive device implementations:
+
+*   [A-0-1] MUST implement an assistant on the device to handle the 
+    [Assist action](
     http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST).
 
 
 **Media UI (Section 3.14)**
 
-*   [A-0-1] Automotive implementations MUST include a UI framework to support
-    third-party apps using the media APIs as described in section 3.14.
+Automotive device implementations:
+
+*   [A-0-1] MUST include a UI framework to support third-party apps using the
+    media APIs as described in section 3.14.
+
+### 2.2.4\. Performance and Power
+
+**Power-Saving Modes (Section 8.3)**
+
+For Automotive device implementations:
+
+*   [A-0-1] All Apps exempted from App Standby and Doze power-saving modes
+MUST be made visible to the end user.
+*   [A-0-2] The triggering, maintenance, wakeup algorithms and the use of
+global system settings of App Standby and Doze power-saving modes MUST not
+deviate from the Android Open Source Project.
+
+**Power Consumption Accounting (Sections 8.4)**
+
+Automotive device implementations:
+
+*    [A-0-1] MUST provide a per-component power profile that defines the
+[current consumption value](
+http://source.android.com/devices/tech/power/values.html)
+for each hardware component and the approximate battery drain caused by the
+components over time as documented in the Android Open Source Project site.
+*    [A-0-2] MUST report all power consumption values in milliampere
+hours (mAh).
+*    [A-0-3] MUST report CPU power consumption per each process's UID.
+The Android Open Source Project meets the requirement through the
+`uid_cputime` kernel module implementation.
+*    SHOULD be attributed to the hardware component itself if unable to
+attribute hardware component power usage to an application.
+*   [A-0-4] MUST make this power usage available via the
+[`adb shell dumpsys batterystats`](
+http://source.android.com/devices/tech/power/batterystats.html)
+shell command to the app developer.
+
+### 2.2.5\. Security Model
+
+**Multi-User Support (Section 9.5)**
+
+If Automotive device implementations include multiple users, they:
+
+*   [A-1-1] MUST include a guest account that allows all functions provided
+by the vehicle system without requiring a user to log in.
+
+**Automotive Vehicle System Isolation (Section 9.14)**
+
+Automotive device implementations:
+
+*    [A-0-1] MUST gatekeep messages from Android framework vehicle subsystems,
+e.g., whitelisting permitted message types and message sources.
+*    [A-0-2] MUST watchdog against denial of service attacks from the Android
+framework or third-party apps. This guards against malicious software flooding
+the vehicle network with traffic, which may lead to malfunctioning vehicle
+subsystems.
diff --git a/2_device-types/2_6_tablet-reqs.md b/2_device-types/2_6_tablet-reqs.md
new file mode 100644
index 0000000..387d53b
--- /dev/null
+++ b/2_device-types/2_6_tablet-reqs.md
@@ -0,0 +1,45 @@
+## 2.6\. Tablet Requirements
+
+An **Android Tablet device** refers to an Android device implementation that is
+typically used by holding in both hands and not in a clamshell form-factor.
+
+Android device implementations are classified as a Tablet if they meet all the
+following criteria:
+
+*   Have a power source that provides mobility, such as a battery.
+*   Have a physical diagonal screen size in the range of 7 to 18 inches.
+
+Tablet device implementations have similar requirements to handheld device
+implementations. The exceptions are in indicated by and \* in that section
+and noted for reference in this section.
+
+### 2.4.1\. Hardware
+
+**Screen Size (Section 7.1.1.1)**
+
+Tablet device implementations:
+
+*   [Ta-0-1] MUST have a screen in the range of 7 to 18 inches.
+
+**Minimum Memory and Storage (Section 7.6.1)**
+
+The screen densities listed for small/normal screens in the handheld
+requirements are not applicable to tablets.
+
+**USB peripheral mode (Section 7.7.1)**
+
+If handheld device implementations include a USB port supporting peripheral
+mode, they:
+
+*   MAY implement the Android Open Accessory (AOA) API.
+
+**Virtual Reality Mode (Section 7.9.1)**
+
+**Virtual Reality High Performance (Section 7.9.2)**
+
+Virtual reality requirements are not applicable to tablets.
+
+
+
+
+
diff --git a/3_software/3_12_tv-input-framework.md b/3_software/3_12_tv-input-framework.md
index 9676250..0bca402 100644
--- a/3_software/3_12_tv-input-framework.md
+++ b/3_software/3_12_tv-input-framework.md
@@ -5,9 +5,6 @@
 content to Android Television devices. TIF provides a standard API to create
 input modules that control Android Television devices.
 
-*    [T-0-1] Android Television device implementations MUST support TV Input
-Framework.
-
 If device implementations support TIF, they:
 
 *    [C-1-1] MUST declare the platform feature `android.software.live_tv`.
diff --git a/3_software/3_2_soft-api-compatibility.md b/3_software/3_2_soft-api-compatibility.md
index 3837b1c..b86a590 100644
--- a/3_software/3_2_soft-api-compatibility.md
+++ b/3_software/3_2_soft-api-compatibility.md
@@ -252,15 +252,15 @@
 components, or at least a handler, for all the public intent filter patterns
 defined by the the following core Android applications in AOSP:
 
-   *   Desk Clock
-   *   Browser
-   *   Calendar
-   *   Contacts
-   *   Gallery
-   *   GlobalSearch
-   *   Launcher
-   *   Music
-   *   Settings
+     *   Desk Clock
+     *   Browser
+     *   Calendar
+     *   Contacts
+     *   Gallery
+     *   GlobalSearch
+     *   Launcher
+     *   Music
+     *   Settings
 
 #### 3.2.3.2\. Intent Resolution
 
@@ -433,4 +433,4 @@
 *   [C-3-1] Only the owner of that display, system, and activities that are
     already on that display MUST be able to launch to it. Everyone can launch to
     a display that has [android.view.Display.FLAG_PUBLIC](https://developer.android.com/reference/android/view/Display.html#FLAG_PUBLIC)
-    flag.
\ No newline at end of file
+    flag.
diff --git a/5_multimedia/5_1_media-codecs.md b/5_multimedia/5_1_media-codecs.md
index 781376e..c8d569c 100644
--- a/5_multimedia/5_1_media-codecs.md
+++ b/5_multimedia/5_1_media-codecs.md
@@ -4,27 +4,6 @@
 
 See more details in [5.1.3. Audio Codecs Details](#5_1_3_audio_codecs_details).
 
-Handheld device implementations MUST support the following audio encoding:
-
-*    [H-0-1] AMR-NB
-*    [H-0-2] AMR-WB
-*    [H-0-3] MPEG-4 AAC Profile (AAC LC)
-*    [H-0-4] MPEG-4 HE AAC Profile (AAC+)
-*    [H-0-5] AAC ELD (enhanced low delay AAC)
-
-
-Television device implementations MUST support the following audio encoding:
-
-*    [T-0-1] MPEG-4 AAC Profile (AAC LC)
-*    [T-0-2] MPEG-4 HE AAC Profile (AAC+)
-*    [T-0-3] AAC ELD (enhanced low delay AAC)
-
-Automotive device implementations MUST support the following audio encoding:
-
-*    [A-1-1] MPEG-4 AAC Profile (AAC LC)
-*    [A-1-2] MPEG-4 HE AAC Profile (AAC+)
-*    [A-1-3] AAC ELD (enhanced low delay AAC)
-
 If device implementations declare `android.hardware.microphone`,
 they MUST support the following audio encoding:
 
@@ -35,10 +14,6 @@
 
 See more details in [5.1.3. Audio Codecs Details](#5_1_3_audio_codecs_details).
 
-Handheld device implementations MUST support the following decoding.
-
-*    [H-0-1] AMR-NB
-*    [H-0-2] AMR-WB
 
 If device implementations declare support for the
 `android.hardware.audio.output` feature, they:
diff --git a/5_multimedia/5_2_video-encoding.md b/5_multimedia/5_2_video-encoding.md
index 4f97c1e..3bc9d79 100644
--- a/5_multimedia/5_2_video-encoding.md
+++ b/5_multimedia/5_2_video-encoding.md
@@ -1,22 +1,5 @@
 ## 5.2\. Video Encoding
 
-Handheld device implementations MUST support the following encoding and make it
-available to third-party applications.
-
-*    [H-0-1] H.264 AVC
-*    [H-0-2] VP8
-
-Television device implementations MUST support the following encoding.
-
-*    [T-0-1] H.264 AVC
-*    [T-0-2] VP8
-
-Automotive device implementations MUST support the following encoding:
-
-*    [A-0-1] H.264 AVC
-*    [A-0-2] VP8
-
-
 If device implementations support any video encoder and make it available
 to third-party apps, they:
 
@@ -60,14 +43,6 @@
 
 ### 5.2.2\. H-264
 
-Television device implementations are:
-
-*   [T-SR] STRONGLY RECOMMENDED to support H.264 encoding of 720p and 1080p
-resolution videos.
-*   [T-SR] STRONGLY RECOMMENDED to support H.264 encoding of 1080p resolution
-video at 30 frame-per-second (fps).
-
-
 If device implementations support H.264 codec, they:
 
 *   [C-1-1] MUST support Baseline Profile Level 3.
diff --git a/5_multimedia/5_3_video-decoding.md b/5_multimedia/5_3_video-decoding.md
index 255d503..0d09bab 100644
--- a/5_multimedia/5_3_video-decoding.md
+++ b/5_multimedia/5_3_video-decoding.md
@@ -1,32 +1,5 @@
 ## 5.3\. Video Decoding
 
-Handheld device implementations:
-
-*    [H-0-1] MUST support decoding of H.264 AVC.
-*    [H-0-2] MUST support decoding of H.265 HEVC.
-*    [H-0-3] MUST support decoding of MPEG-4 SP.
-*    [H-0-4] MUST support decoding of VP8.
-*    [H-0-5] MUST support decoding of VP9.
-
-Television device implementations:
-
-*    [T-0-1] MUST support decoding of H.264 AVC.
-*    [T-0-2] MUST support decoding of H.265 HEVC.
-*    [T-0-3] MUST support decoding of MPEG-4 SP.
-*    [T-0-4] MUST support decoding of VP8.
-*    [T-0-5] MUST support decoding of VP9.
-*    [T-SR] Are Strongly Recommended to support MPEG-2 decoding.
-
-
-Automotive device implementations:
-
-*    [A-0-1] MUST support decoding of H.264 AVC.
-*    [A-0-2] MUST support decoding of MPEG-4 SP.
-*    [A-0-3] MUST support decoding of VP8.
-*    [A-0-4] MUST support decoding of VP9.
-*    [A-SR] Are Strongly Recommended to support H.265 HEVC decoding.
-
-
 If device implementations support VP8, VP9, H.264, or H.265 codecs, they:
 
 *   [C-1-1] MUST support dynamic video resolution and frame rate switching
@@ -83,13 +56,6 @@
 *   [C-2-2] MUST support the HD 1080p video encoding profiles in the following
 table.
 
-If Television device implementations support H.264 decoders, they:
-
-*   [T-1-1] MUST support High Profile Level 4.2 and the HD 1080p (at 60 fps)
-decoding profile.
-*   [T-1-2] MUST be capable of decoding videos with both HD profiles as
-indicated in the following table and encoded with either the Baseline Profile,
-Main Profile, or the High Profile Level 4.2
 
 <table>
  <tr>
@@ -124,6 +90,7 @@
 
 ### 5.3.5\. H.265 (HEVC)
 
+
 If device implementations support H.265 codec, they:
 
 *   [C-1-1] MUST support the Main Profile Level 3 Main tier and the SD video
@@ -138,18 +105,6 @@
 *   [C-2-1] Device implementations MUST support at least one of H.265 or VP9
 decoding of 720, 1080 and UHD profiles.
 
-If Television device implementations support H.265 codec and the HD 1080p
-decoding profile, they:
-
-*   [T-1-1] MUST support the Main Profile Level 4.1 Main tier.
-*   [T-SR] STRONGLY RECOMMENDED to support 60 fps video frame rate
-for HD 1080p.
-
-If Television device implementations support H.265 codec and the UHD decoding
-profile, then:
-
-*   [T-2-1] The codec MUST support Main10 Level 5 Main Tier profile.
-
 <table>
  <tr>
     <th></th>
@@ -204,15 +159,6 @@
 *   [C-2-2] Device implementations MUST support 1080p profiles in the
 following table.
 
-If Television device implementations support VP8 codec, they:
-
-*   [T-1-1] MUST support the HD 1080p60 decoding profile.
-
-If Television device implementations support VP8 codec and support 720p, they:
-
-*   [T-2-1] MUST support the HD 720p60 decoding profile.
-
-
 
 <table>
  <tr>
@@ -265,17 +211,6 @@
 *   [C-3-1] Device implementations MUST support at least one of VP9 or H.265
 decoding of the 720, 1080 and UHD profiles.
 
-If Television device implementations support VP9 codec and the UHD video
-decoding, they:
-
-*   [T-1-1] MUST support 8-bit color depth and SHOULD support VP9 Profile 2
-(10-bit).
-
-If Television device implementations support VP9 codec, the 1080p profile and
-VP9 hardware decoding, they:
-
-*   [T-2-1] MUST support 60 fps for 1080p.
-
 <table>
  <tr>
     <th></th>
@@ -309,4 +244,4 @@
     <td>5 Mbps</td>
     <td>20 Mbps</td>
  </tr>
-</table>
\ No newline at end of file
+</table>
diff --git a/5_multimedia/5_5_audio-playback.md b/5_multimedia/5_5_audio-playback.md
index 363197e..b0e6d45 100644
--- a/5_multimedia/5_5_audio-playback.md
+++ b/5_multimedia/5_5_audio-playback.md
@@ -10,14 +10,14 @@
 *   [C-1-1] MUST allow playback of raw audio content with the following
 characteristics:
 
-   *   **Format**: Linear PCM, 16-bit
-   *   **Sampling rates**: 8000, 11025, 16000, 22050, 32000, 44100
-   *   **Channels**: Mono, Stereo
+     *   **Format**: Linear PCM, 16-bit
+     *   **Sampling rates**: 8000, 11025, 16000, 22050, 32000, 44100
+     *   **Channels**: Mono, Stereo
 
 *   SHOULD allow playback of raw audio content with the following
 characteristics:
 
-   *   **Sampling rates**: 24000, 48000
+     *   **Sampling rates**: 24000, 48000
 
 ### 5.5.2\. Audio Effects
 
@@ -40,13 +40,6 @@
 
 ### 5.5.3\. Audio Output Volume
 
-Television device implementations:
-
-*   [T-0-1] MUST include support for system Master Volume and digital audio
-output volume attenuation on supported outputs,
-except for compressed audio passthrough output (where no audio decoding is done
-on the device).
-
 Automotive device implementations:
 
 *   SHOULD allow adjusting audio volume
diff --git a/5_multimedia/5_8_secure-media.md b/5_multimedia/5_8_secure-media.md
index 5df157e..e75a775 100644
--- a/5_multimedia/5_8_secure-media.md
+++ b/5_multimedia/5_8_secure-media.md
@@ -17,15 +17,3 @@
 
 *    [C-3-1] MUST support HDCP 1.2 or higher for all wired external displays.
 
-If device implementations are Android Television devices and support 4K
-resolution, they:
-
-*    [T-1-1] MUST support HDCP 2.2 for all wired external displays.
-
-If Television device implementations don't support 4K resolution, they:
-
-*    [T-2-1] MUST support HDCP 1.4 for all wired external displays.
-
-*    [T-SR] Television device implementations are STRONGLY RECOMMENDED to
-support simulataneous decoding of secure streams. At minimum, simultaneous
-decoding of two steams is STRONGLY RECOMMENDED.
\ No newline at end of file
diff --git a/7_hardware-compatibility/7_1_display-and-graphics.md b/7_hardware-compatibility/7_1_display-and-graphics.md
index b9b8d0f..ece4f9f 100644
--- a/7_hardware-compatibility/7_1_display-and-graphics.md
+++ b/7_hardware-compatibility/7_1_display-and-graphics.md
@@ -23,18 +23,6 @@
 
 #### 7.1.1.1\. Screen Size
 
-*   [H-0-1] Handheld device implementations MUST have a screen at least 2.5
-    inches in physical diagonal size.
-
-*   [A-0-1] Android Automotive devices MUST have a screen at least 6 inches
-    in physical diagonal size.
-
-*   [A-0-2] Android Automotive devices MUST have a screen size layout of
-at least 750 dp x 480 dp.
-
-*   [W-0-1] Android Watch device implementations MUST have a screen with the
-    physical diagonal size in the range from 1.1 to 2.5 inches.
-
 The Android UI framework supports a variety of different logical screen layout
 sizes, and allows applications to query the current configuration's screen
 layout size via `Configuration.screenLayout` with the `SCREENLAYOUT_SIZE_MASK`
@@ -130,8 +118,6 @@
      supported compatible screen size (320 dp width), device implementations SHOULD
      report the next lowest standard Android framework density.
 
-*    [H-SR] Device implementations are STRONGLY RECOMMENDED to provide users an
-     affordance to change the display size.
 
 If there is an affordance to change the display size of the device:
 
@@ -355,12 +341,6 @@
 applications not developed for old versions of Android that pre-date
 screen-size independence.
 
-*   [H-0-1] Handheld device implementations MUST include support
-    for legacy application compatibility mode as implemented by the upstream
-    Android open source code. That is, device implementations MUST NOT alter the
-    triggers or thresholds at which compatibility mode is activated, and MUST
-    NOT alter the behavior of the compatibility mode itself.
-
 ### 7.1.6\. Screen Technology
 
 The Android platform includes APIs that allow applications to render rich
@@ -386,4 +366,4 @@
 
 *   [C-1-1] MUST implement the [`DisplayManager`](
     https://developer.android.com/reference/android/hardware/display/DisplayManager.html)
-    system service and API as described in the Android SDK documentation.
\ No newline at end of file
+    system service and API as described in the Android SDK documentation.
diff --git a/7_hardware-compatibility/7_2_input-devices.md b/7_hardware-compatibility/7_2_input-devices.md
index 66fda1d..993db39 100644
--- a/7_hardware-compatibility/7_2_input-devices.md
+++ b/7_hardware-compatibility/7_2_input-devices.md
@@ -8,11 +8,6 @@
 
 ### 7.2.1\. Keyboard
 
-*    [H-0-1]  Handheld device implementations MUST include support for
-third-party Input Method Editor (IME) applications.
-*    [T-0-1] Television device implementations  MUST include support for
-third-party Input Method Editor (IME) applications.
-
 If device implementations include support for third-party
 Input Method Editor (IME) applications, they:
 
@@ -34,10 +29,6 @@
 Android includes support for d-pad, trackball, and wheel as mechanisms for
 non-touch navigation.
 
-Television device implementations:
-
-*    [T-0-1] MUST support [D-pad](https://developer.android.com/reference/android/content/res/Configuration.html#NAVIGATION_DPAD).
-
 Device implementations:
 
 *   [C-0-1] MUST report the correct value for
@@ -61,25 +52,6 @@
 or a distinct portion of the touch screen, are essential to the Android
 navigation paradigm and therefore:
 
-*   [H-0-1] Android Handheld device implementations MUST provide the Home,
-    Recents, and Back functions.
-*   [H-0-2] Android Handheld device implementations MUST send both the normal
-    and long press event of the the Back function ([`KEYCODE_BACK`](http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK))
-    to the foreground application.
-*   [T-0-1] Android Television device implementations MUST provide the Home
-    and Back functions.
-*   [T-0-2] Android Television device implementations MUST send both the normal
-    and long press event of the the Back function ([`KEYCODE_BACK`](http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK))
-    to the foreground application.
-*   [W-0-1] Android Watch device implementations MUST have the Home function
-    available to the user, and the Back function except for when it is in
-    `UI_MODE_TYPE_WATCH`.
-*   [A-0-1] Automotive device implementations MUST provide the Home function
-    and MAY provide Back and Recent functions.
-*   [A-0-2] Automotive device implementations MUST send both the normal
-    and long press event of the the Back function ([`KEYCODE_BACK`](http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK))
-    to the foreground application.
-
 *   [C-0-1] MUST provide the Home function.
 *   SHOULD provide buttons for the Recents and Back function.
 
@@ -145,9 +117,6 @@
 the system does not require any additional affordances to indicate the objects
 being manipulated.
 
-*    [H-0-1] Handheld device implementations MUST support touchscreen input.
-*    [W-0-2] Watch device implementations MUST support touchscreen input.
-
 Device implementations:
 
 *    SHOULD have a pointer input system of some kind
@@ -236,10 +205,6 @@
 
 #### 7.2.6.1\. Button Mappings
 
-Television device implementations:
-*    [T-0-1] MUST include support for game controllers and declare the
-`android.hardware.gamepad` feature flag.
-
 If device implementations declare the `android.hardware.gamepad` feature flag,
 they:
 *    [C-1-1] MUST have embed a controller or ship with a separate controller
@@ -381,8 +346,5 @@
 
 ### 7.2.7\. Remote Control
 
-Television device implementations:
+See [Section 2.3.1](#2_3_1_hardware) for device-specific requirements.
 
-*    SHOULD provide a remote control from which users can access
-[non-touch navigation](#7_2_2_non-touch_navigation) and
-[core navigation keys](#7_2_3_navigation_keys) inputs.
\ No newline at end of file
diff --git a/7_hardware-compatibility/7_3_sensors.md b/7_hardware-compatibility/7_3_sensors.md
index 2090341..7e43ea1 100644
--- a/7_hardware-compatibility/7_3_sensors.md
+++ b/7_hardware-compatibility/7_3_sensors.md
@@ -82,25 +82,6 @@
 ### 7.3.1\. Accelerometer
 
 *   Device implementations SHOULD include a 3-axis accelerometer.
-*   [H-SR] Handheld device implementations are STRONGLY RECOMMENDED to
-    include a 3-axis accelerometer.
-*   [A-SR] Automotive device implementations are STRONGLY RECOMMENDED to
-    include a 3-axis accelerometer.
-*   [W-SR] Watch device implementations are STRONGLY RECOMMENDED to
-    include a 3-axis accelerometer.
-
-
-
-If Handheld device implementations include a 3-axis accelerometer, they:
-
-*   [H-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
-
-If Automotive device implementations include a 3-axis accelerometer, they:
-
-*   [A-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
-*   [A-1-2] MUST comply with the Android
-    [car sensor coordinate system](
-    http://source.android.com/devices/sensors/sensor-types.html#auto_axes).
 
 If device implementations include a 3-axis accelerometer, they:
 
@@ -253,12 +234,6 @@
 additional mandatory requirements for devices reporting the year "2016" or
 "2017" through the Test API `LocationManager.getGnssYearOfHardware()`.
 
-If Automotive device implementations include a GPS/GNSS receiver and report
-the capability to applications through the `android.hardware.location.gps`
-feature flag:
-
-*   [A-1-1] GNSS technology generation MUST be the year "2017" or newer.
-
 If device implementations include a GPS/GNSS receiver and report the capability
 to applications through the `android.hardware.location.gps` feature flag and the
 `LocationManager.getGnssYearOfHardware()` Test API reports the year "2016" or
@@ -318,19 +293,6 @@
 when device is stationary at room temperature.
 *   SHOULD report events up to at least 200 Hz.
 
-If Handheld device implementations include a gyroscope, they:
-
-*   [H-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
-
-If Automotive device implementations include a gyroscope, they:
-
-*   [A-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
-
-If Television device implementations include a gyroscope, they:
-
-*   [T-1-1] MUST be able to report events up to a frequency of at least 100 Hz.
-
-
 If device implementations include a gyroscope, an accelerometer sensor and a
 magnetometer sensor, they:
 
@@ -385,9 +347,6 @@
 ### 7.3.8\. Proximity Sensor
 
 *   Device implementations MAY include a proximity sensor.
-*   Handheld device implementations that can make a voice call and indicate
-any value other than `PHONE_TYPE_NONE` in `getPhoneType`
-SHOULD include a proximity sensor.
 
 If device implementations include a proximity sensor, they:
 
@@ -583,40 +542,22 @@
 Automotive-specific sensors are defined in the
 `android.car.CarSensorManager API`.
 
-
 #### 7.3.11.1\. Current Gear
 
-*    Android Automotive implementations SHOULD provide current gear as
-`SENSOR_TYPE_GEAR`.
+See [Section 2.5.1](#2_5_1_hardware) for device-specific requirements.
 
 #### 7.3.11.2\. Day Night Mode
 
-Automotive device implementations:
-
-*    [A-0-1] MUST support day/night mode
-defined as `SENSOR_TYPE_NIGHT`.
-*    [A-0-2] The value of the `SENSOR_TYPE_NIGHT` flag MUST be consistent with
-dashboard day/night mode and SHOULD be based on ambient light sensor input.
-
-*    The underlying ambient light sensor MAY be the same as
-[Photometer](#7_3_7_photometer).
+See [Section 2.5.1](#2_5_1_hardware) for device-specific requirements.
 
 #### 7.3.11.3\. Driving Status
 
-Automotive device implementations:
-
-*    [A-0-1] MUST support driving status
-defined as `SENSOR_TYPE_DRIVING_STATUS`, with a default value of
-`DRIVE_STATUS_UNRESTRICTED` when the vehicle is fully stopped and parked. It is
-the responsibility of device manufacturers to configure
-`SENSOR_TYPE_DRIVING_STATUS` in compliance with all
-laws and regulations that apply to markets where the product is shipping.
+See [Section 2.5.1](#2_5_1_hardware) for device-specific requirements.
 
 #### 7.3.11.4\. Wheel Speed
 
-Automotive device implementations:
+See [Section 2.5.1](#2_5_1_hardware) for device-specific requirements.
 
-*    [A-0-1] MUST provide vehicle speed defined as `SENSOR_TYPE_CAR_SPEED`.
 
 ## 7.3.12\. Pose Sensor
 
@@ -624,10 +565,6 @@
 
 *   MAY support pose sensor with 6 degrees of freedom.
 
-Handheld device implementations are:
-
-*   RECOMMENDED to support this sensor.
-
 If device implementations support pose sensor with 6 degrees of freedom, they:
 
 *   [C-1-1] MUST implement and report [`TYPE_POSE_6DOF`](
diff --git a/7_hardware-compatibility/7_4_data-connectivity.md b/7_hardware-compatibility/7_4_data-connectivity.md
index b8869d0..9cd6ae4 100644
--- a/7_hardware-compatibility/7_4_data-connectivity.md
+++ b/7_hardware-compatibility/7_4_data-connectivity.md
@@ -162,10 +162,6 @@
 
 ### 7.4.3\. Bluetooth
 
-*    [W-0-1] Watch device implementations MUST support Bluetooth.
-*    [T-0-1] Television device implementations MUST support Bluetooth and
-Bluetooth LE.
-
 If device implementations support Bluetooth Audio profile, they:
 
 *    SHOULD support Advanced Audio Codecs and Bluetooth Audio Codecs
@@ -188,17 +184,6 @@
 *    SHOULD implement relevant Bluetooth profiles such as
      A2DP, AVCP, OBEX, etc. as appropriate for the device.
 
-Automotive device implementations:
-*    [A-0-1] Automotive device implementations MUST support Bluetooth and
-SHOULD support Bluetooth LE.
-*    [A-0-2] Android Automotive implementations MUST support the following
-Bluetooth profiles:
-
-     * Phone calling over Hands-Free Profile (HFP).
-     * Media playback over Audio Distribution Profile (A2DP).
-     * Media playback control over Remote Control Profile (AVRCP).
-     * Contact sharing using the Phone Book Access Profile (PBAP).
-*    SHOULD support Message Access Profile (MAP).
 
 If device implementations include support for Bluetooth Low Energy, they:
 
@@ -413,10 +398,6 @@
 
 *   [SR] STRONGLY RECOMMENDED to provide the data saver mode.
 
-If Handheld device implementations include a metered connection, they:
-
-*   [H-1-1] MUST provide the data saver mode.
-
 If device implementations provide the data saver mode, they:
 
 *   [C-1-1] MUST support all the APIs in the `ConnectivityManager`
diff --git a/7_hardware-compatibility/7_6_memory-and-storage.md b/7_hardware-compatibility/7_6_memory-and-storage.md
index 674da7f..c4f8fab 100644
--- a/7_hardware-compatibility/7_6_memory-and-storage.md
+++ b/7_hardware-compatibility/7_6_memory-and-storage.md
@@ -10,97 +10,6 @@
     downloading individual files of at least 100MB in size to the default
     “cache” location.
 
-Television device implementations:
-
-*   [T-0-1] MUST have at least 4GB of non-volatile storage available for
-    application private data (a.k.a. "/data" partition)
-
-Automotive device implementations:
-
-*   [A-0-1] MUST have at least 4GB of non-volatile storage available for
-    application private data (a.k.a. "/data" partition)
-
-Watch device implementations:
-
-*   [W-0-1] MUST have at least 1GB of non-volatile storage available for
-    application private data (a.k.a. "/data" partition)
-*   [W-0-2] MUST have at least 416MB memory available to the kernel and
-    userspace.
-
-Handheld device implementations:
-
-*   [H-0-1] MUST have at least 4GB of non-volatile storage available for
-    application private data (a.k.a. "/data" partition)
-*   [H-0-2] MUST return “true” for `ActivityManager.isLowRamDevice()` when there
-    is less than 1GB of memory available to the kernel and userspace.
-
-
-If Handheld device implementations are 32-bit:
-
-*   [H-1-1] The memory available to the kernel and userspace MUST
-be at least: 512MB if any of the following densities are used:
-
-   *   280dpi or lower on small/normal screens
-   *   ldpi or lower on extra large screens
-   *   mdpi or lower on large screens
-
-*   [H-2-1] The memory available to the kernel and userspace MUST
-be at least: 608MB if any of the following densities are used:
-
-   *   xhdpi or higher on small/normal screens
-   *   hdpi or higher on large screens
-   *   mdpi or higher on extra large screens
-
-*   [H-3-1] The memory available to the kernel and userspace MUST
-be at least: 896MB if any of the following densities are used:
-
-   *   400dpi or higher on small/normal screens
-   *   xhdpi or higher on large screens
-   *   tvdpi or higher on extra large screens
-
-*    [H-4-1] The memory available to the kernel and userspace MUST
-be at least: 1344MB if any of the following densities are used:
-
-   *   560dpi or higher on small/normal screens
-   *   400dpi or higher on large screens
-   *   xhdpi or higher on extra large screens
-
-If Handheld device implementations are 64-bit:
-
-*   [H-5-1] The memory available to the kernel and userspace MUST
-be at least: 816MB if any of the following densities are used:
-
-   *   280dpi or lower on small/normal screens
-   *   ldpi or lower on extra large screens
-   *   mdpi or lower on large screens
-
-
-*   [H-6-1] The memory available to the kernel and userspace MUST
-be at least: 944MB if any of the following densities are used:
-
-   *   xhdpi or higher on small/normal screens
-   *   hdpi or higher on large screens
-   *   mdpi or higher on extra large screens
-
-*   [H-7-1] The memory available to the kernel and userspace MUST
-be at least: 1280MB if any of the following densities are used:
-
-   *  400dpi or higher on small/normal screens
-   *  xhdpi or higher on large screens
-   *  tvdpi or higher on extra large screens
-
-*    [H-8-1] The memory available to the kernel and userspace MUST
-be at least: 1824MB if any of the following densities are used:
-
-   *   560dpi or higher on small/normal screens
-   *   400dpi or higher on large screens
-   *   xhdpi or higher on extra large screens
-
-Note that the "memory available to the kernel and userspace" above refers to the
-memory space provided in addition to any memory already dedicated to hardware
-components such as radio, video, and so on that are not under the kernel’s
-control on device implementations.
-
 ### 7.6.2\. Application Shared Storage
 
 Device implementations:
@@ -119,10 +28,6 @@
     permission on this shared storage as documented in the SDK. Shared storage
     MUST otherwise be writable by any application that obtains that permission.
 
-Android handheld device implementations:
-
-*   [H-0-1] MUST NOT provide an application shared storage smaller than 1GiB.
-
 Device implementations MAY meet the above requirements using either:
 
 * a user-accessible removable storage, such as a Secure Digital (SD) card slot.
diff --git a/7_hardware-compatibility/7_7_usb.md b/7_hardware-compatibility/7_7_usb.md
index 0d4965c..77f3b82 100644
--- a/7_hardware-compatibility/7_7_usb.md
+++ b/7_hardware-compatibility/7_7_usb.md
@@ -6,11 +6,6 @@
 
 ### 7.7.1\. USB peripheral mode
 
-If handheld device implementations include a USB port supporting peripheral
-mode, they:
-
-*    [H-1-1] MUST implement the Android Open Accessory (AOA) API.
-
 If device implementations include a USB port supporting peripheral mode:
 
 *    [C-1-1] The port MUST be connectable to a USB host that has a standard
@@ -68,12 +63,12 @@
 [`android.hardware.usb.host`](http://developer.android.com/guide/topics/connectivity/usb/host.html).
 *   [C-1-2] MUST implement support to connect standard USB peripherals,
 in other words, they MUST either:
-   *   Have an on-device type C port or ship with cable(s) adapting an on-device
-   proprietary port to a standard USB type-C port (USB Type-C device).
-   *   Have an on-device type A or ship with cable(s) adapting an on-device
-   proprietary port to a standard USB type-A port.
-   *   Have an on-device micro-AB port, which SHOULD ship with a cable adapting
-   to a standard type-A port.
+     *   Have an on-device type C port or ship with cable(s) adapting an on-device
+     proprietary port to a standard USB type-C port (USB Type-C device).
+     *   Have an on-device type A or ship with cable(s) adapting an on-device
+     proprietary port to a standard USB type-A port.
+     *   Have an on-device micro-AB port, which SHOULD ship with a cable adapting
+     to a standard type-A port.
 *   [C-1-3] MUST NOT ship with an adapter converting from USB type A or
 micro-AB ports to a type-C port (receptacle).
 *   [SR] STRONGLY RECOMMENDED to implement the [USB audio class](
@@ -99,10 +94,10 @@
 and the [Voice Command Usage Request](http://www.usb.org/developers/hidpage/Voice_Command_Usage.pdf)
 to the [`KeyEvent`](https://developer.android.com/reference/android/view/KeyEvent.html)
 constants as below:
-        *   Usage Page (0xC) Usage ID (0x0CD): `KEYCODE_MEDIA_PLAY_PAUSE`
-        *   Usage Page (0xC) Usage ID (0x0E9): `KEYCODE_VOLUME_UP`
-        *   Usage Page (0xC) Usage ID (0x0EA): `KEYCODE_VOLUME_DOWN`
-        *   Usage Page (0xC) Usage ID (0x0CF): `KEYCODE_VOICE_ASSIST`
+       *   Usage Page (0xC) Usage ID (0x0CD): `KEYCODE_MEDIA_PLAY_PAUSE`
+       *   Usage Page (0xC) Usage ID (0x0E9): `KEYCODE_VOLUME_UP`
+       *   Usage Page (0xC) Usage ID (0x0EA): `KEYCODE_VOLUME_DOWN`
+       *   Usage Page (0xC) Usage ID (0x0CF): `KEYCODE_VOICE_ASSIST`
 
 
 If device implementations include a USB port supporting host mode and
@@ -126,4 +121,4 @@
 http://www.usb.org/developers/docs/).
 *   SHOULD implement the Try.\* model that is most appropriate for the
 device form factor. For example a handheld device SHOULD implement the
-Try.SNK model.
\ No newline at end of file
+Try.SNK model.
diff --git a/7_hardware-compatibility/7_8_audio.md b/7_hardware-compatibility/7_8_audio.md
index 0279da4..32288e3 100644
--- a/7_hardware-compatibility/7_8_audio.md
+++ b/7_hardware-compatibility/7_8_audio.md
@@ -2,11 +2,6 @@
 
 ### 7.8.1\. Microphone
 
-
-*    [H-0-1] Handheld device implementations MUST include a microphone.
-*    [W-0-1] Watch device implementations MUST include a microphone.
-*    [A-0-1] Automotive device implementations MUST include a microphone.
-
 If device implementations include a microphone, they:
 
 *   [C-1-1] MUST report the `android.hardware.microphone` feature constant.
@@ -44,13 +39,6 @@
 *   [C-2-1] MUST NOT report the `android.hardware.audio output` feature.
 *   [C-2-2] MUST implement the Audio Output related APIs as no-ops at least.
 
-*   [H-0-1] Handheld device implementations MUST have an audio output and
-declare `android.hardware.audio.output`.
-*   [T-0-1] Television device implementations MUST have an audio output and
-declare `android.hardware.audio.output`.
-*   [A-0-1] Automotive device implementations MUST have an audio output and
-declare `android.hardware.audio.output`.
-*   Watch device implementations MAY but SHOULD NOT have audio output.
 
 For the purposes of this section, an "output port" is a
 [physical interface](https://en.wikipedia.org/wiki/Computer_port_%28hardware%29)
diff --git a/7_hardware-compatibility/7_9_virtual-reality.md b/7_hardware-compatibility/7_9_virtual-reality.md
index e9f9257..393058c 100644
--- a/7_hardware-compatibility/7_9_virtual-reality.md
+++ b/7_hardware-compatibility/7_9_virtual-reality.md
@@ -12,26 +12,8 @@
 a feature which handles stereoscopic rendering of notifications and disables
 monocular system UI components while a VR application has user focus.
 
-If Handheld device implementations include support for the VR mode, they:
-
-*   [H-1-1] MUST declare the `android.software.vr.mode` feature.
-
-If device implementations declare `android.software.vr.mode` feature, they:
-
-*   [H-2-1] MUST include an application implementing
-`android.service.vr.VrListenerService`
-that can be enabled by VR applications via
-`android.app.Activity#setVrModeEnabled`.
-
 ### 7.9.2\. Virtual Reality High Performance
 
-
-If Handheld device implementations are capable of meeting all the requirements
-to declare the `android.hardware.vr.high_performance` feature flag, they:
-
-*   [H-1-1] MUST declare the `android.hardware.vr.high_performance`
-feature flag.
-
 If device implementations identify the support of high performance VR
 for longer user periods through the `android.hardware.vr.high_performance`
 feature flag, they:
diff --git a/8_performance-and-power/8_1_user-experience-consistency.md b/8_performance-and-power/8_1_user-experience-consistency.md
index 9728f44..85f8a14 100644
--- a/8_performance-and-power/8_1_user-experience-consistency.md
+++ b/8_performance-and-power/8_1_user-experience-consistency.md
@@ -6,15 +6,3 @@
 MAY have measurable requirements for the user interface latency and task
 switching as described in [section 2](#2_device-types).
 
-   *   [H-0-1] **Consistent frame latency**. Inconsistent frame latency or a
-delay to render frames MUST NOT happen more often than 5 frames in a second,
-and SHOULD be below 1 frames in a second.
-   *   [H-0-2] **User interface latency**. Device implementations MUST ensure
-low latency user experience by scrolling a list of 10K list entries as defined
-by the Android Compatibility Test Suite (CTS) in less than 36 secs.
-   *   [H-0-3] **Task switching**. When multiple applications have been
-launched, re-launching an already-running application after it has been
-launched MUST take less than 1 second.
-   *   [T-0-1] **Consistent frame latency**. Inconsistent frame latency or a
-delay to render frames MUST NOT happen more often than 5 frames in a second,
-and SHOULD be below 1 frames in a second.
diff --git a/8_performance-and-power/8_2_file-io-access-performance.md b/8_performance-and-power/8_2_file-io-access-performance.md
index 7508aff..c667ec5 100644
--- a/8_performance-and-power/8_2_file-io-access-performance.md
+++ b/8_performance-and-power/8_2_file-io-access-performance.md
@@ -7,7 +7,6 @@
 described in [section 2](#2_device-type) for the following read
 and write operations:
 
-
 *    **Sequential write performance**. Measured by writing a 256MB file using
 10MB write buffer.
 *    **Random write performance**. Measured by writing a 256MB file using 4KB
@@ -17,16 +16,3 @@
 *    **Random read performance**. Measured by reading a 256MB file using 4KB
 write buffer.
 
-Handheld device implementations:
-
-   *   [H-0-1] MUST ensure a sequential write performance of at least 5MB/s.
-   *   [H-0-2] MUST ensure a random write performance of at least 0.5MB/s.
-   *   [H-0-3] MUST ensure a sequential read performance of at least 15MB/s.
-   *   [H-0-4] MUST ensure a random read performance of at least 3.5MB/s.
-
-Television device implementations:
-
-   *   [T-0-1] MUST ensure a sequential write performance of at least 5MB/s.
-   *   [T-0-2] MUST ensure a random write performance of at least 0.5MB/s.
-   *   [T-0-3] MUST ensure a sequential read performance of at least 15MB/s.
-   *   [T-0-4] MUST ensure a random read performance of at least 3.5MB/s.
\ No newline at end of file
diff --git a/8_performance-and-power/8_3_power-saving-modes.md b/8_performance-and-power/8_3_power-saving-modes.md
index a6a5bf3..6268303 100644
--- a/8_performance-and-power/8_3_power-saving-modes.md
+++ b/8_performance-and-power/8_3_power-saving-modes.md
@@ -2,25 +2,6 @@
 
 Android includes App Standby and Doze power-saving modes to optimize battery
 usage.
-
-*   [H-0-1] All Apps exempted from App Standby and Doze power-saving modes
-MUST be made visible to the end user.
-*   [H-0-2] The triggering, maintenance, wakeup algorithms and the use of
-global system settings of App Standby and Doze power-saving modes MUST not
-deviate from the Android Open Source Project.
-
-*   [T-0-1] All Apps exempted from App Standby and Doze power-saving modes
-MUST be made visible to the end user.
-*   [T-0-2] The triggering, maintenance, wakeup algorithms and the use of
-global system settings of App Standby and Doze power-saving modes MUST not
-deviate from the Android Open Source Project.
-
-*   [A-0-1] All Apps exempted from App Standby and Doze power-saving modes
-MUST be made visible to the end user.
-*   [A-0-2] The triggering, maintenance, wakeup algorithms and the use of
-global system settings of App Standby and Doze power-saving modes MUST not
-deviate from the Android Open Source Project.
-
 *   [SR] All Apps exempted from these modes are STRONGLY RECOMMENDED to be made
 visible to the end user.
 *   [SR] The triggering, maintenance, wakeup algorithms and the use of
diff --git a/8_performance-and-power/8_4_power-consumption-accounting.md b/8_performance-and-power/8_4_power-consumption-accounting.md
index 0628b10..0e688fe 100644
--- a/8_performance-and-power/8_4_power-consumption-accounting.md
+++ b/8_performance-and-power/8_4_power-consumption-accounting.md
@@ -4,62 +4,6 @@
 app developer both the incentives and the tools to optimize the power usage
 pattern of the application.
 
-Handheld device implementations:
-
-*    [H-0-1] MUST provide a per-component power profile that defines the
-[current consumption value](
-http://source.android.com/devices/tech/power/values.html)
-for each hardware component and the approximate battery drain caused by the
-components over time as documented in the Android Open Source Project site.
-*    [H-0-2] MUST report all power consumption values in milliampere
-hours (mAh).
-*    [H-0-3] MUST report CPU power consumption per each process's UID.
-The Android Open Source Project meets the requirement through the
-`uid_cputime` kernel module implementation.
-*    SHOULD be attributed to the hardware component itself if unable to
-attribute hardware component power usage to an application.
-*   [H-0-4] MUST make this power usage available via the
-[`adb shell dumpsys batterystats`](
-http://source.android.com/devices/tech/power/batterystats.html)
-shell command to the app developer.
-
-Television device implementations:
-
-*    [T-0-1] MUST provide a per-component power profile that defines the
-[current consumption value](
-http://source.android.com/devices/tech/power/values.html)
-for each hardware component and the approximate battery drain caused by the
-components over time as documented in the Android Open Source Project site.
-*    [T-0-2] MUST report all power consumption values in milliampere
-hours (mAh).
-*    [T-0-3] MUST report CPU power consumption per each process's UID.
-The Android Open Source Project meets the requirement through the
-`uid_cputime` kernel module implementation.
-*    SHOULD be attributed to the hardware component itself if unable to
-attribute hardware component power usage to an application.
-*   [T-0-4] MUST make this power usage available via the
-[`adb shell dumpsys batterystats`](
-http://source.android.com/devices/tech/power/batterystats.html)
-shell command to the app developer.
-
-Automotive device implementations:
-
-*    [A-0-1] MUST provide a per-component power profile that defines the
-[current consumption value](
-http://source.android.com/devices/tech/power/values.html)
-for each hardware component and the approximate battery drain caused by the
-components over time as documented in the Android Open Source Project site.
-*    [A-0-2] MUST report all power consumption values in milliampere
-hours (mAh).
-*    [A-0-3] MUST report CPU power consumption per each process's UID.
-The Android Open Source Project meets the requirement through the
-`uid_cputime` kernel module implementation.
-*    SHOULD be attributed to the hardware component itself if unable to
-attribute hardware component power usage to an application.
-*   [A-0-4] MUST make this power usage available via the
-[`adb shell dumpsys batterystats`](
-http://source.android.com/devices/tech/power/batterystats.html)
-shell command to the app developer.
 
 Device implementations:
 
@@ -81,9 +25,4 @@
 attribute hardware component power usage to an application.
 
 
-If Handheld device implementations include a screen or video output, they:
-
-*   [H-1-1] MUST honor the [`android.intent.action.POWER_USAGE_SUMMARY`](
-http://developer.android.com/reference/android/content/Intent.html#ACTION_POWER_USAGE_SUMMARY)
-intent and display a settings menu that shows this power usage.
 
diff --git a/9_security-model/9_14_automotive-system-isolation.md b/9_security-model/9_14_automotive-system-isolation.md
index a1d5276..046ebd4 100644
--- a/9_security-model/9_14_automotive-system-isolation.md
+++ b/9_security-model/9_14_automotive-system-isolation.md
@@ -6,11 +6,5 @@
 
 The data exchange can be secured by implementing security features below the
 Android framework layers to prevent malicious or unintentional interaction with
-these subsystems. Automotive device implementations:
+these subsystems.
 
-*    [A-0-1] MUST gatekeep messages from Android framework vehicle subsystems,
-e.g., whitelisting permitted message types and message sources.
-*    [A-0-2] MUST watchdog against denial of service attacks from the Android
-framework or third-party apps. This guards against malicious software flooding
-the vehicle network with traffic, which may lead to malfunctioning vehicle
-subsystems.
\ No newline at end of file
diff --git a/9_security-model/9_1_permissions.md b/9_security-model/9_1_permissions.md
index 5fed443..0e8e5bb 100644
--- a/9_security-model/9_1_permissions.md
+++ b/9_security-model/9_1_permissions.md
@@ -38,14 +38,6 @@
    *   the runtime permissions are associated with an intent pattern
        for which the preinstalled application is set as the default handler
 
-Handheld device implementations:
-
-*   [H-0-1] MUST allow third-party apps to access the usage statistics via the
-    `android.permission.PACKAGE_USAGE_STATS` permission and provide a
-    user-accessible mechanism to grant or revoke access to such apps in response
-    to the [`android.settings.ACTION_USAGE_ACCESS_SETTINGS`](
-    https://developer.android.com/reference/android/provider/Settings.html#ACTION&lowbar;USAGE&lowbar;ACCESS&lowbar;SETTINGS)
-    intent.
 
 If device implementations include a pre-installed app or wish to allow
 third-party apps to access the usage statistics, they:
@@ -64,4 +56,4 @@
     [`android.settings.ACTION_USAGE_ACCESS_SETTINGS`](
     https://developer.android.com/reference/android/provider/Settings.html#ACTION&lowbar;USAGE&lowbar;ACCESS&lowbar;SETTINGS)
     intent pattern but MUST implement it as a no-op, that is to have an
-    equivalent behavior as when the user is declined for access.
\ No newline at end of file
+    equivalent behavior as when the user is declined for access.
diff --git a/9_security-model/9_5_multi-user-support.md b/9_security-model/9_5_multi-user-support.md
index 4f201e5..d266b0c 100644
--- a/9_security-model/9_5_multi-user-support.md
+++ b/9_security-model/9_5_multi-user-support.md
@@ -9,11 +9,6 @@
 http://developer.android.com/reference/android/os/Environment.html)
 for primary external storage.
 
-If Automotive device implementations include multiple users, they:
-
-*   [A-1-1] MUST include a guest account that allows all functions provided
-by the vehicle system without requiring a user to log in.
-
 If device implementations include multiple users, they:
 
 *   [C-1-1] MUST meet the following requirements related to