Merge "CDD: Vehicle UI APIs" into nyc-dev
diff --git a/2_device-types/2_0_intro.md b/2_device-types/2_0_intro.md
index 38d93da..d50e4eb 100644
--- a/2_device-types/2_0_intro.md
+++ b/2_device-types/2_0_intro.md
@@ -37,12 +37,15 @@
Android as an operating system for part or all of the system and/or
infotainment functionality. Android Automotive implementations:
+* MUST have a screen with the physical diagonal length equal to or greater
+ than 6 inches.
* MUST declare the feature android.hardware.type.automotive.
* MUST support uiMode =
[UI_MODE_TYPE_CAR](http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR).
+* Android Automotive implementations MUST support all public APIs in the
+`android.car.*` namespace.
All Android device implementations that do not fit into any of the above device
types still MUST meet all requirements in this document to be Android
ANDROID_VERSION compatible, unless the requirement is explicitly described to
be only applicable to a specific Android device type from above.
-
diff --git a/3_software/3_13_quick-settings.md b/3_software/3_13_quick-settings.md
new file mode 100644
index 0000000..6bdc769
--- /dev/null
+++ b/3_software/3_13_quick-settings.md
@@ -0,0 +1,16 @@
+## 3.13\. Quick Settings
+
+Android device implementations SHOULD include a Quick Settings UI component that
+allow quick access to frequently used or urgently needed actions.
+
+Android includes the [`quicksettings`](https://developer.android.com/reference/android/service/quicksettings/package-summary.html)
+API allowing third party apps to implement tiles that can be added by the user
+alongside the system-provided tiles in the Quick Settings UI component. If a
+device implementation has a Quick Settings UI component, it:
+
+* MUST allow the user to add or remove tiles from a third-party app to Quick
+ Settings.
+* MUST NOT automatically add a tile from a third-party app directly to Quick
+ Settings.
+* MUST display all the user-added tiles from third-party apps alongside the
+ system-provided quick setting tiles.
diff --git a/3_software/3_1_managed-api-compatibility.md b/3_software/3_1_managed-api-compatibility.md
index de3cb05..09ef63e 100644
--- a/3_software/3_1_managed-api-compatibility.md
+++ b/3_software/3_1_managed-api-compatibility.md
@@ -9,6 +9,9 @@
SDK](http://developer.android.com/reference/packages.html) or any API decorated
with the “@SystemApi” marker in the upstream Android source code.
+Device implementations MUST support/preserve all classes, methods, and
+associated elements marked by the TestApi annotation (@TestApi).
+
Device implementations MUST NOT omit any managed APIs, alter API interfaces or
signatures, deviate from the documented behavior, or include no-ops, except
where specifically allowed by this Compatibility Definition.
diff --git a/3_software/3_2_soft-api-compatibility.md b/3_software/3_2_soft-api-compatibility.md
index 64aabf8..f89b351 100644
--- a/3_software/3_2_soft-api-compatibility.md
+++ b/3_software/3_2_soft-api-compatibility.md
@@ -109,7 +109,8 @@
or code name identifying the configuration of the hardware features and
industrial design of the device. The value of this field MUST be encodable
as 7-bit ASCII and match the regular expression
- “^[a-zA-Z0-9_-]+$”.</td>
+ “^[a-zA-Z0-9_-]+$”. This device name MUST NOT change during the
+ lifetime of the product.</td>
</tr>
<tr>
<td>FINGERPRINT</td>
@@ -168,7 +169,8 @@
or code name of the specific product (SKU) that MUST be unique within the
same brand. MUST be human-readable, but is not necessarily intended for view
by end users. The value of this field MUST be encodable as 7-bit ASCII and
- match the regular expression “^[a-zA-Z0-9_-]+$”.</td>
+ match the regular expression “^[a-zA-Z0-9_-]+$”. This product
+ name MUST NOT change during the lifetime of the product.</td>
</tr>
<tr>
<td>SERIAL</td>
diff --git a/3_software/3_3_native-api-compatibility.md b/3_software/3_3_native-api-compatibility.md
index 7d06cc2..95decff 100644
--- a/3_software/3_3_native-api-compatibility.md
+++ b/3_software/3_3_native-api-compatibility.md
@@ -1,5 +1,9 @@
## 3.3\. Native API Compatibility
+Native code compatibility is challenging. For this reason, device implementers
+are **STRONGLY RECOMMENDED** to use the implementations of the libraries listed
+below from the upstream Android Open Source Project.
+
### 3.3.1\. Application Binary Interfaces
Managed Dalvik bytecode can call into native code provided in the application
@@ -40,12 +44,14 @@
* libGLESv1_CM.so (OpenGL ES 1.x)
* libGLESv2.so (OpenGL ES 2.0)
* libGLESv3.so (OpenGL ES 3.x)
+* libvukan.so (Vulkan)
* libEGL.so (native OpenGL surface management)
* libjnigraphics.so
* libOpenSLES.so (OpenSL ES 1.0.1 audio support)
* libOpenMAXAL.so (OpenMAX AL 1.0.1 support)
* libandroid.so (native Android activity support)
* libmediandk.so (native media APIs support)
+* libcamera2ndk.so
* Support for OpenGL, as described below
Note that future releases of the Android NDK may introduce support for
@@ -59,15 +65,42 @@
symbols must be present, only the corresponding functions for OpenGL ES versions
and extensions actually supported by the device must be fully implemented.
-Device implementations, if including a native library with the name
-libvulkan.so, MUST export function symbols and provide an implementation of the
-Vulkan 1.0 API and the VK_KHR_surface, VK_KHR_swapchain, and
-VK_KHR_android_surface extensions as defined by the Khronos Group and passing
-the Khronos conformance tests.
+#### 3.3.1.1\. Graphic Libraries
-Native code compatibility is challenging. For this reason, device implementers
-are **STRONGLY RECOMMENDED** to use the implementations of the libraries listed
-above from the upstream Android Open Source Project.
+[Vulkan](https://www.khronos.org/registry/vulkan/specs/1.0-wsi_extensions/xhtml/vkspec.html)
+is a low-overhead, cross-platform API for high-performance 3D graphics. Device
+implementations, even if not including support of the Vulkan APIs, MUST satisfy
+the following requirements:
+
+* It MUST always provide a native library named `libvulkan.so` which exports
+ function symbols for the core Vulkan 1.0 API as well as the `VK_KHR_surface`,
+ `VK_KHR_android_surface`, and `VK_KHR_swapchain` extensions.
+
+Device implementations, if including support of the Vulkan APIs:
+
+* MUST report, one or more `VkPhysicalDevices` through the
+ `vkEnumeratePhysicalDevices` call.
+* Each enumarated `VkPhysicalDevices` MUST fully implement the Vulkan 1.0 API.
+* MUST report the correct
+ [`PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL`](https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_VULKAN_HARDWARE_LEVEL)
+ and [`PackageManager#FEATURE_VULKAN_HARDWARE_VERSION`](https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_VULKAN_HARDWARE_VERSION)
+ feature flags.
+* MUST enumerate layers, contained in native libraries named `libVkLayer*.so`
+ in the application package’s native library directory, through the
+ `vkEnumerateInstanceLayerProperties` and `vkEnumerateDeviceLayerProperties`
+ functions in `libvulkan.so`
+* MUST NOT enumerate layers provided by libraries outside of the application
+ package, or provide other ways of tracing or intercepting the Vulkan API,
+ unless the application has the `android:debuggable=”true”` attribute.
+
+Device implementations, if not including support of the Vulkan APIs:
+
+* MUST report 0 `VkPhysicalDevices` through the `vkEnumeratePhysicalDevices`
+ call.
+* MUST NOT delare any of the Vulkan feature flags
+ [`PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL`](https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_VULKAN_HARDWARE_LEVEL)
+ and [`PackageManager#FEATURE_VULKAN_HARDWARE_VERSION`](https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_VULKAN_HARDWARE_VERSION).
+
### 3.3.2. 32-bit ARM Native Code Compatibility
diff --git a/3_software/3_8_user-interface-compatibility.md b/3_software/3_8_user-interface-compatibility.md
index e1c9a7f..ed9bd96 100644
--- a/3_software/3_8_user-interface-compatibility.md
+++ b/3_software/3_8_user-interface-compatibility.md
@@ -104,13 +104,14 @@
applications are installed that make use of this functionality, the default
behavior SHOULD be to display web search engine results and suggestions.
-Android device implementations SHOULD implement an assistant on the device to
+Android device implementations SHOULD, and Android Automotive implementations
+MUST, implement an assistant on the device to
handle the [Assist action](http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST).
Android also includes the [Assist APIs](https://developer.android.com/reference/android/app/assist/package-summary.html)
to allow applications to elect how much information of the current context is
shared with the assistant on the device. Device implementations supporting the
-Assist action MUST indicate clearly to the end user when the the context is
+Assist action MUST indicate clearly to the end user when the context is
shared by displaying a white light around the edges of the screen. To ensure
clear visibility to the end user, the indication MUST meet or exceed the
duration and brightness of the Android Open Source Project implementation.
@@ -187,9 +188,10 @@
<div class="note">
-As the Recent function navigation key is OPTIONAL, the requirements to implement
-the overview screen is OPTIONAL for Android Watch devices and RECOMMENDED for
-Android Television devices.
+As the Recent function navigation key is OPTIONAL, the requirement to implement
+the overview screen is OPTIONAL for Android Watch and Android Automotive implementations,
+and RECOMMENDED for Android Television devices. There SHOULD still be a
+method to switch between activities on Android Automotive implementations.
</div>
@@ -202,13 +204,14 @@
[section 7.2.3](#7_2_3_navigation_keys) MAY alter the interface but MUST meet the
following requirements:
-* MUST display affiliated recents as a group that moves together.
* MUST support at least up to 20 displayed activities.
* MUST at least display the title of 4 activities at a time.
-* SHOULD display highlight color, icon, screen title in recents.
-* MUST implement the [screen pinning behavior](http://developer.android.com/about/versions/android-5.0.html#ScreenPinning)]
+* MUST implement the [screen pinning behavior](http://developer.android.com/about/versions/android-5.0.html#ScreenPinning)
and provide the user with a settings menu to toggle the feature.
+* SHOULD display highlight color, icon, screen title in recents.
* SHOULD display a closing affordance ("x") but MAY delay this until user interacts with screens.
+* SHOULD implement a shortcut to switch easily to the previous activity
+* MAY display affiliated recents as a group that moves together.
Device implementations are STRONGLY RECOMMENDED to use the upstream Android user
interface (or a similar thumbnail-based interface) for the overview screen.
@@ -236,15 +239,15 @@
unless an Android Automotive or Watch implementation, MUST display the
Lockscreen Notifications including the Media Notification Template.
-### 3.8.11\. Dreams
+### 3.8.11\. Screen savers (previously Dreams)
-Android includes support for interactive screensavers called
-[Dreams](http://developer.android.com/reference/android/service/dreams/DreamService.html).
-Dreams allows users to interact with applications when a device connected to a
-power source is idle or docked in a desk dock. Android Watch devices MAY
-implement Dreams, but other types of device implementations SHOULD include
-support for Dreams and provide a settings option for users to configure Dreams
-in response to the android.settings.DREAM_SETTINGS intent.
+Android includes support for [interactivescreensavers](http://developer.android.com/reference/android/service/dreams/DreamService.html),
+previously referred to as Dreams. Screen savers allow users to interact with
+applications when a device connected to a power source is idle or docked in a
+desk dock. Android Watch devices MAY implement screen savers, but other types
+of device implementations SHOULD include support for screen savers and provide
+a settings option for users toconfigure screen savers in response to the
+`android.settings.DREAM_SETTINGS` intent.
### 3.8.12\. Location
@@ -254,10 +257,14 @@
### 3.8.13\. Unicode and Font
-Android includes support for color emoji characters. When Android device
-implementations include an IME, devices SHOULD provide an input method to the
-user for the Emoji characters defined in [Unicode 6.1](http://www.unicode.org/versions/Unicode6.1.0/). All devices MUST be capable
-of rendering these emoji characters in color glyph.
+Android includes support for the emoji characters defined in
+[Unicode 9.0](http://www.unicode.org/versions/Unicode9.0.0/). All device
+implementations MUST be capable of rendering these emoji characters
+in color glyph and when Android device implementations include an IME,
+it SHOULD provide an input method to the user for these emoji characters.
+
+Android handheld devices SHOULD support the skin tone and diverse family emojis
+as specificed in the [Unicode Technical Report #51](http://unicode.org/reports/tr51).
Android includes support for Roboto 2 font with different
weights—sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black,
@@ -265,4 +272,3 @@
the languages available on the device and full Unicode 7.0 coverage of Latin,
Greek, and Cyrillic, including the Latin Extended A, B, C, and D ranges, and all
glyphs in the currency symbols block of Unicode 7.0.
-
diff --git a/3_software/3_9_device-administration.md b/3_software/3_9_device-administration.md
index 9b98caf..31093de 100644
--- a/3_software/3_9_device-administration.md
+++ b/3_software/3_9_device-administration.md
@@ -43,6 +43,16 @@
[android.app.action.PROVISION_MANAGED_PROFILE](http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_PROFILE))
user experience MUST align with the AOSP implementation.
+Device implementations MUST provide the following user affordances within the
+Settings user interface to indicate to the user when a particular system function
+has been disabled by the Device Policy Controller (DPC):
+* A consistent icon or other user affordance (for example the upstream AOSP
+ info icon) to represent when a particular setting is restricted by a
+ Device Admin
+* A short explanation message, as provided by the Device Admin via the
+ [`setShortSupportMessage`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setShortSupportMessage(android.content.ComponentName, java.lang.CharSequence))
+* The DPC application’s icon
+
## 3.9.2 Managed Profile Support
Managed profile capable devices are those devices that:
@@ -78,14 +88,15 @@
or managed profile.
* Independent management of accounts within the primary user or managed
profile.
-* Ensure the default dialer can look up caller information from the managed
- profile (if one exists) alongside those from the primary profile, if the
- Device Policy Controller permits it. When contacts from the managed
- profile are displayed in the preinstalled call log, in-call UI, in progress
- and missed call notifications, contacts and messaging apps they SHOULD be
- badged with the same badge used to indicate managed profile applications
+* Ensure the preinstalled dialer, contacts and messaging applications can
+ search for and look up caller information from the managed profile (if one
+ exists) alongside those from the primary profile, if the Device Policy
+ Controller permits it. When contacts from the managed profile are displayed
+ in the preinstalled call log, in-call UI, in-progress and missed-call
+ notifications, contacts and messaging apps they SHOULD be badged with the
+ same badge used to indicate managed profile applications.
* MUST ensure that it satisfies all the security requirements applicable for a
- device with multiple users enabled (see
- [section 9.5](#9_5_multi-user_support)), even though the managed profile is not
- counted as another user in addition to the primary user.
+ device with multiple users enabled (see[section 9.5](#9_5_multi-user_support)),
+ even though the managed profile is not counted as another user in addition
+ to the primary user.
diff --git a/5_multimedia/5_10_professional-audio.md b/5_multimedia/5_10_professional-audio.md
index 1fe11ca..2097436 100644
--- a/5_multimedia/5_10_professional-audio.md
+++ b/5_multimedia/5_10_professional-audio.md
@@ -26,3 +26,35 @@
implementation is STRONGLY RECOMMENDED to comply with section [Mobile device
(jack) specifications](https://source.android.com/accessories/headset/specification.html#mobile_device_jack_specifications)
of the [Wired Audio Headset Specification (v1.1)](https://source.android.com/accessories/headset/specification.html).
+
+Latencies and USB audio requirements MUST be met using the
+[OpenSL ES](https://developer.android.com/ndk/guides/audio/opensl-for-android.html)
+PCM buffer queue API.
+
+In addition, a device implementation that reports support for this feature SHOULD:
+
+* Provide a sustainable level of CPU performance while audio is active.
+* Minimize audio clock inaccuracy and drift relative to standard time.
+* Minimize audio clock drift relative to the CPU `CLOCK_MONOTONIC` when both are active.
+* Minimize audio latency over on-device transducers.
+* Minimize audio latency over USB digital audio.
+* Document audio latency measurements over all paths.
+* Minimize jitter in audio buffer completion callback entry times, as this affects usable percentage of full CPU bandwidth by the callback.
+* Provide zero audio underruns (output) or overruns (input) under normal use at reported latency.
+* Provide zero inter-channel latency difference.
+* Minimize MIDI mean latency over all transports.
+* Minimize MIDI latency variability under load (jitter) over all transports.
+* Provide accurate MIDI timestamps over all transports.
+* Minimize audio signal noise over on-device transducers, including the period immediately after cold start.
+* Provide zero audio clock difference between the input and output sides of corresponding
+ end-points, when both are active. Examples of corresponding end-points include
+ the on-device microphone and speaker, or the audio jack input and output.
+* Handle audio buffer completion callbacks for the input and output sides of corresponding
+ end-points on the same thread when both are active, and enter the output callback immediately
+ after the return from the input callback. Or if it is not feasible to handle the callbacks
+ on the same thread, then enter the output callback shortly after entering the input callback
+ to permit the application to have a consistent timing of the input and output sides.
+* Minimize the phase difference between HAL audio buffering for the input and output
+ sides of corresponding end-points.
+* Minimize touch latency.
+* Minimize touch latency variability under load (jitter).
diff --git a/5_multimedia/5_11_unprocessed-audio.md b/5_multimedia/5_11_unprocessed-audio.md
new file mode 100644
index 0000000..d60cbd4
--- /dev/null
+++ b/5_multimedia/5_11_unprocessed-audio.md
@@ -0,0 +1,51 @@
+## 5.11\. Capture for Unprocessed
+
+Starting from Android 7.0,
+a new recording source has been added. It can be accessed using
+the `android.media.MediaRecorder.AudioSource.UNPROCESSED` audio
+source. In OpenSL ES, it can be accessed with the record preset
+`SL_ANDROID_RECORDING_PRESET_UNPROCESSED`.
+
+A device MUST satisfy all of the following requirements to report support
+of the unprocessed audio source via the `android.media.AudioManager` property
+[PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED](http://developer.android.com/reference/android/media/AudioManager.html#PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED):
+
+* The device MUST exhibit approximately flat amplitude-versus-frequency
+characteristics in the mid-frequency range: specifically ±10dB from
+100 Hz to 7000 Hz.
+
+* The device MUST exhibit amplitude levels in the low frequency range:
+specifically from ±20 dB from 5 Hz to 100 Hz compared to the mid-frequency range.
+
+* The device MUST exhibit amplitude levels in the high frequency range:
+specifically from ±30 dB from 4000 Hz to 22 KHz compared to the mid-frequency range.
+
+* Audio input sensitivity MUST be set such that a 1000 Hz sinusoidal tone
+source played at 94 dB Sound Pressure Level (SPL)
+yields a response with RMS of 520 for 16
+bit-samples (or -36 dB Full Scale for floating point/double precision
+samples).
+
+* SNR > 60 dB (difference between 94 dB SPL and equivalent SPL of self
+noise, A-weighted).
+
+* Total harmonic distortion MUST be less than 1% for 1 kHZ at 90 dB SPL
+input level at the microphone.
+
+* The only signal processing allowed in the path is a level multiplier
+to bring the level to desired range. This level multiplier MUST NOT
+introduce delay or latency to the signal path.
+
+* No other signal processing is allowed in the path, such as Automatic Gain
+Control, High Pass Filter, or Echo Cancellation. If any signal processing
+is present in the architecture for any reason, it MUST be disabled and
+effectively introduce zero delay or extra latency to the signal path.
+
+All SPL measurements are made directly next to the microphone under test.
+
+For multiple microphone configurations, these requirements apply to each
+microphone.
+
+It is STRONGLY RECOMMENDED that a device satisfy as many of the requirements for the signal
+path for the unprocessed recording source; however, a device must satisfy _all_ of these
+requirements, listed above, if it claims to support the unprocessed audio source.
diff --git a/5_multimedia/5_1_media-codecs.md b/5_multimedia/5_1_media-codecs.md
index b297e49..d9c25ff 100644
--- a/5_multimedia/5_1_media-codecs.md
+++ b/5_multimedia/5_1_media-codecs.md
@@ -1,17 +1,34 @@
## 5.1\. Media Codecs
-Device implementations MUST support the [core media
+Device implementations—
+
+* MUST support the [core media
formats](http://developer.android.com/guide/appendix/media-formats.html)
-specified in the Android SDK documentation except where explicitly permitted in
-this document. Specifically, device implementations MUST support the media
-formats, encoders, decoders, file types, and container formats defined in the
-tables below and reported via
+specified in the Android SDK documentation, except where explicitly permitted
+in this document.
+
+* MUST support the media formats, encoders, decoders, file types, and
+container formats defined in the tables below and reported via
[MediaCodecList](http://developer.android.com/reference/android/media/MediaCodecList.html).
-Device implementations MUST also be able to decode all profiles reported in its
+
+* MUST also be able to decode all profiles reported in its
[CamcorderProfile](http://developer.android.com/reference/android/media/CamcorderProfile.html)
-and MUST be able to decode all formats it can encode. All of these codecs are
-provided as software implementations in the preferred Android implementation
-from the Android Open Source Project.
+
+* MUST be able to decode all formats it can encode. This includes all
+ bitstreams that its encoders generate.
+
+Codecs SHOULD aim for minimum codec latency, in other words, codecs—
+
+* SHOULD NOT consume and store input buffers and return input buffers only
+once processed
+* SHOULD NOT hold onto decoded buffers for longer than as specified by the
+standard (e.g. SPS).
+* SHOULD NOT hold onto encoded buffers longer than required by the GOP
+structure.
+
+All of the codecs listed in the table below are provided as software
+implementations in the preferred Android implementation from the Android Open
+Source Project.
Please note that neither Google nor the Open Handset Alliance make any
representation that these codecs are free from third-party patents. Those
@@ -19,6 +36,8 @@
that implementations of this code, including in open source software or
shareware, may require patent licenses from the relevant patent holders.
+
+
### 5.1.1\. Audio Codecs
<table>
@@ -142,7 +161,7 @@
<td></td>
<td>REQUIRED<br> (Android 5.0+)</td>
<td></td>
- <td>Matroska (.mkv)</td>
+ <td>Matroska (.mkv), Ogg(.ogg)</td>
</tr>
</table>
@@ -151,8 +170,22 @@
android.hardware.microphone but optional for Android Watch device
implementations.</p>
-<p class="table_footnote">2 Only downmix of 5.0/5.1 content is required;
-recording or rendering more than 2 channels is optional.</p>
+<p class="table_footnote">2 Recording or playback MAY be performed in mono
+or stereo, but the decoding of AAC input buffers of multichannel streams
+(i.e. more than two channels) to PCM through the default AAC audio decoder
+in the android.media.MediaCodec API, the following MUST be supported:
+<ul>
+<li>decoding is performed without downmixing (e.g. a 5.0 AAC stream must be
+decoded to five channels of PCM, a 5.1 AAC stream must be decoded to six
+channels of PCM),</li>
+<li>dynamic range metadata, as defined in "Dynamic Range Control (DRC)"
+in ISO/IEC 14496-3, and the android.media.MediaFormat DRC keys to
+configure the dynamic range-related behaviors of the audio decoder. The
+AAC DRC keys were introduced in API 21,and are:
+KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR,
+KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL and
+KEY_AAC_ENCODED_TARGET_LEVEL</li>
+</ul></p>
<p class="table_footnote">3 Required for Android Handheld device
implementations.</p>
@@ -205,11 +238,36 @@
<td></td>
<td>WebP (.webp)</td>
</tr>
+ <tr>
+ <td>Raw</td>
+ <td></td>
+ <td>REQUIRED</td>
+ <td>Uses the embedded JPEG if available. Renders DNG images if no preview
+ available.</td>
+ <td>ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf),
+ PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)</td>
+ </tr>
</table>
<h3 id="5_1_3_video_codecs">5.1.3. Video Codecs</h3>
+
+* Codecs advertising HDR profile support MUST support HDR static metadata
+parsing and handling.
+
+* If a media codec advertises intra refresh support, then it MUST support the
+refresh periods in the range of 10 - 60 frames and accurately operate within
+20% of configured refresh period.
+
+* Video codecs MUST support output and input bytebuffer sizes that
+accommodate the largest feasible compressed and uncompressed frame as dictated
+by the standard and configuration but also not overallocate.
+
+* Video encoders and decoders MUST support YUV420 flexible color format
+(COLOR_FormatYUV420Flexible).
+
+
<table>
<tr>
<th>Format/Codec</th>
@@ -220,8 +278,8 @@
</tr>
<tr>
<td>H.263</td>
- <td>REQUIRED<sup>1</sup></td>
- <td>REQUIRED<sup>2</sup></td>
+ <td>MAY</td>
+ <td>MAY</td>
<td></td>
<td><ul>
<li class="table_list">3GPP (.3gp)</li>
diff --git a/5_multimedia/5_2_video-encoding.md b/5_multimedia/5_2_video-encoding.md
index f202c00..c19a23a 100644
--- a/5_multimedia/5_2_video-encoding.md
+++ b/5_multimedia/5_2_video-encoding.md
@@ -1,19 +1,44 @@
## 5.2\. Video Encoding
<div class="note">
-
Video codecs are optional for Android Watch device implementations.
-
</div>
-Android device implementations with H.263 encoders MUST support Baseline
-Profile Level 45.
+H.264, VP8, VP9 and HEVC video encoders—
-Android device implementations with H.264 codec support MUST support Baseline
-Profile Level 3 and the following SD (Standard Definition) video encoding
-profiles and SHOULD support Main Profile Level 4 and the following HD (High
-Definition) video encoding profiles. Android Television devices are STRONGLY
-RECOMMENDED to encode HD 1080p video at 30 fps.
+* MUST support dynamically configurable bitrates.
+* SHOULD support variable frame rates, where video encoder SHOULD determine
+instantaneous frame duration based on the timestamps of input buffers, and
+allocate its bit bucket based on that frame duration.
+
+H.263 and MPEG-4 video encoder SHOULD support dynamically configurable
+bitrates.
+
+All video encoders SHOULD meet the following bitrate targets over two sliding
+windows:
+
+* It SHOULD be not more than ~15% over the bitrate between intraframe
+(I-frame) intervals.
+* It SHOULD be not more than ~100% over the bitrate over a sliding window of
+1 second.
+
+### 5.2.1\. H.263
+
+Android device implementations with H.263 encoders MUST support Baseline Profile Level 45.
+
+### 5.2.2\. H-264
+
+Android device implementations with H.264 codec support&emdash;
+
+* MUST support Baseline Profile Level 3.<br>
+ However, support for ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock
+ Ordering) and RS (Redundant Slices) is OPTIONAL. Moreover, to maintain
+ compatibility with other Android devices, it is RECOMMENDED that ASO, FMO
+ and RS are not used for Baseline Profile by encoders.
+* MUST support the SD (Standard Definition) video encoding profiles in the following table.
+* SHOULD support Main Profile Level 4.
+* SHOULD support the HD (High Definition) video encoding profiles as indicated in the following table.
+* In addition, Android Television devices are STRONGLY RECOMMENDED to encode HD 1080p video at 30 fps.
<table>
<tr>
@@ -50,8 +75,10 @@
<p class="table_footnote">1 When supported by hardware, but STRONGLY RECOMMENDED
for Android Television devices.</p>
+### 5.2.3\. VP8
-Android device implementations with VP8 codec support MUST support the SD video encoding profiles and SHOULD support the following HD (High Definition) video encoding profiles.
+Android device implementations with VP8 codec support MUST support the SD video
+encoding profiles and SHOULD support the following HD (High Definition) video encoding profiles.
<table>
<tr>
diff --git a/5_multimedia/5_3_video-decoding.md b/5_multimedia/5_3_video-decoding.md
index da4bb2e..58d06b2 100644
--- a/5_multimedia/5_3_video-decoding.md
+++ b/5_multimedia/5_3_video-decoding.md
@@ -1,26 +1,56 @@
## 5.3\. Video Decoding
<div class="note">
-
Video codecs are optional for Android Watch device implementations.
-
</div>
-Device implementations MUST support dynamic video resolution and frame rate
-switching through the standard Android APIs within the same stream for all VP8,
-VP9, H.264, and H.265 codecs in real time and up to the maximum resolution
-supported by each codec on the device.
+Device implementations&emdash;
-Android device implementations with H.263 decoders MUST support Baseline Profile Level 30.
+* MUST support dynamic video resolution and frame rate switching through the
+ standard Android APIs within the same stream for all VP8, VP9, H.264, and
+ H.265 codecs in real time and up to the maximum resolution supported by each
+ codec on the device.
-Android device implementations with MPEG-4 decoders MUST support Simple Profile Level 3.
+* Implementations that support the Dolby Vision decoder&emdash;
+ * MUST provide a Dolby Vision-capable extractor.
+ * MUST properly display Dolby Vision content on the device screen or on a
+ standard video output port (e.g., HDMI).
-### 5.3.1\. H.264
+* Implementations that provide a Dolby Vision-capable extractor MUST set the
+ track index of backward-compatible base-layer(s) (if present) to be the same
+ as the combined Dolby Vision layer's track index.
-Android device implementations with H.264 decoders MUST support Main Profile
-Level 3.1 and the following SD video decoding profiles and SHOULD support the
-HD decoding profiles. Android Television devices MUST support High Profile
-Level 4.2 and the HD 1080p decoding profile.
+### 5.3.1\. MPEG-2
+
+Android device implementations with MPEG-2 decoders must support the Main
+Profile High Level.
+
+### 5.3.2\. H.263
+
+Android device implementations with H.263 decoders MUST support Baseline Profile
+Level 30 and Level 45.
+
+### 5.3.3\. MPEG-4
+Android device implementations with MPEG-4 decoders MUST support Simple Profile
+Level 3.
+
+### 5.3.4\. H.264
+
+Android device implementations with H.264 decoders:
+
+* MUST support Main Profile Level 3.1 and Baseline Profile.<br>
+ Support for ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering)
+ and RS (Redundant Slices) is OPTIONAL.
+* MUST be capable of decoding videos with the SD (Standard Definition)
+ profiles listed in the following table and encoded with the Baseline Profile and
+ Main Profile Level 3.1 (including 720p30).
+* SHOULD be capable of decoding videos with the HD (High Definition) profiles
+ as indicated in the following table.
+* In addition, Android Television devices&emdash;
+ * MUST support High Profile Level 4.2 and the HD 1080p60 decoding profile.
+ * 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>
@@ -60,13 +90,13 @@
<p class="table_footnote">2 REQUIRED for Android Television device
implementations.</p>
-### 5.3.2\. H.265
+### 5.3.5\. H.265 (HEVC)
Android device implementations, when supporting H.265 codec as described in
[section 5.1.3](#5_1_3_video_codecs), MUST support the Main Profile Level 3
Main tier and the following SD video decoding profiles and SHOULD support the
HD decoding profiles. Android Television devices MUST support the Main Profile
-Level 4.1 Main tier and the HD 1080p decoding profile and SHOULD support Main10
+Level 4.1 Main tier and the HD 1080p60 decoding profile and SHOULD support Main10
Level 5 Main Tier profile and the UHD decoding profile.
<table>
@@ -81,7 +111,7 @@
<tr>
<th>Video resolution</th>
<td>352 x 288 px</td>
- <td>640 x 360 px</td>
+ <td>720 x 480 px</td>
<td>1280 x 720 px</td>
<td>1920 x 1080 px</td>
<td>3840 x 2160 px</td>
@@ -113,12 +143,13 @@
device implementations when supported by hardware.</p>
-### 5.3.3\. VP8
-
+### 5.3.6\. VP8
Android device implementations, when supporting VP8 codec as described in
-[section 5.1.3](#5_1_3_video_codecs), MUST support the following SD decoding
-profiles and SHOULD support the HD decoding profiles. Android Television
-devices MUST support the HD 1080p decoding profile.
+[section 5.1.3](https://source.android.com/compatibility/android-cdd.html#5_1_3_video_codecs):
+
+* MUST support the SD decoding profiles in the following table.
+* SHOULD support the HD decoding profiles in the following table.
+* Android Television devices MUST support the HD 1080p60 decoding profile.
<table>
<tr>
@@ -157,14 +188,20 @@
<p class="table_footnote">2 REQUIRED for Android Television device
implementations.</p>
-### 5.3.4\. VP9
+### 5.3.7\. VP9
Android device implementations, when supporting VP9 codec as described in
-[section 5.1.3](#5_1_3_video_codecs), MUST support the following SD video
-decoding profiles and SHOULD support the HD decoding profiles. Android Television
-devices are STRONGLY RECOMMENDED to support the HD 1080p decoding profile and
-SHOULD support the UHD decoding profile. When the UHD video decoding profile is
-supported, it MUST support 8-bit color depth and SHOULD support VP9 Profile 2 (10-bit).
+[section 5.1.3](https://source.android.com/compatibility/android-cdd.html#5_1_3_video_codecs),:
+
+* MUST support the SD video decoding profiles as indicated in the following table.
+* SHOULD support the HD decoding profiles as indicated in the following table.
+* MUST be able to decode the video resolution up to the width and height as
+ reported by the `Display.getSupportedModes()`.
+* In addition, Android Television devices are—
+ * STRONGLY RECOMMENDED to support the HD 1080p60 decoding profile.
+ * SHOULD support the UHD decoding profile.
+ * When the UHD video decoding profile is supported, it MUST support
+ 8-bit color depth and SHOULD support VP9 Profile 2 (10-bit).
<table>
<tr>
diff --git a/5_multimedia/5_4_audio-recording.md b/5_multimedia/5_4_audio-recording.md
index 5c99a76..4d5afed 100644
--- a/5_multimedia/5_4_audio-recording.md
+++ b/5_multimedia/5_4_audio-recording.md
@@ -33,18 +33,21 @@
### 5.4.2\. Capture for Voice Recognition
+The android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION audio source MUST
+support capture at one of the sampling rates, 44100 and 48000.
+
In addition to the above recording specifications, when an application has
started recording an audio stream using the
android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION audio source:
* The device SHOULD exhibit approximately flat amplitude versus frequency
-characteristics: specifically, ±3 dB, from 100 Hz to 4000 Hz.
+ characteristics: specifically, ±3 dB, from 100 Hz to 4000 Hz.
* Audio input sensitivity SHOULD be set such that a 90 dB sound power level
-(SPL) source at 1000 Hz yields RMS of 2500 for 16-bit samples.
-* PCM amplitude levels SHOULD linearly track input SPL changes over at least
-a 30 dB range from -18 dB to +12 dB re 90 dB SPL at the microphone.
+ (SPL) source at 1000 Hz yields RMS of 2500 for 16-bit samples.
+* PCM amplitude levels SHOULD linearly track input SPL changes over at least a
+ 30 dB range from -18 dB to +12 dB re 90 dB SPL at the microphone.
* Total harmonic distortion SHOULD be less than 1% for 1 kHz at 90 dB SPL
-input level at the microphone.
+ input level at the microphone.
* Noise reduction processing, if present, MUST be disabled.
* Automatic gain control, if present, MUST be disabled.
diff --git a/5_multimedia/5_5_audio-playback.md b/5_multimedia/5_5_audio-playback.md
index d482a38..9a5bec5 100644
--- a/5_multimedia/5_5_audio-playback.md
+++ b/5_multimedia/5_5_audio-playback.md
@@ -40,3 +40,8 @@
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).
+
+Android Automotive device implementations SHOULD allow adjusting audio volume
+separately per each audio stream using the content type or usage as defined
+by [AudioAttributes]("http://developer.android.com/reference/android/media/AudioAttributes.html")
+and car audio usage as publicly defined in `android.car.CarAudioManager`.
diff --git a/5_multimedia/5_6_audio-latency.md b/5_multimedia/5_6_audio-latency.md
index 4ed03f1..edc2642 100644
--- a/5_multimedia/5_6_audio-latency.md
+++ b/5_multimedia/5_6_audio-latency.md
@@ -7,27 +7,29 @@
For the purposes of this section, use the following definitions:
* **output latency**. The interval between when an application writes a frame
-of PCM-coded data and when the corresponding sound can be heard by an external
-listener or observed by a transducer.
+of PCM-coded data and when the corresponding sound is presented to environment at an on-device transducer
+or signal leaves the device via a port and can be observed externally.
* **cold output latency**. The output latency for the first frame, when the
audio output system has been idle and powered down prior to the request.
* **continuous output latency**. The output latency for subsequent frames,
after the device is playing audio.
-* **input latency**. The interval between when an external sound is presented
-to the device and when an application reads the corresponding frame of
+* **input latency**. The interval between when a sound is presented by environment to device
+at an on-device transducer or signal enters the device via a port
+and when an application reads the corresponding frame of
PCM-coded data.
+* **lost input**. The initial portion of an input signal that is unusable or unavailable.
* **cold input latency**. The sum of lost input time and the input latency
for the first frame, when the audio input system has been idle and powered down
prior to the request.
* **continuous input latency**. The input latency for subsequent frames,
while the device is capturing audio.
-* **cold output jitter**. The variance among separate measurements of cold
+* **cold output jitter**. The variability among separate measurements of cold
output latency values.
-* **cold input jitter**. The variance among separate measurements of cold
+* **cold input jitter**. The variability among separate measurements of cold
input latency values.
* **continuous round-trip latency**. The sum of continuous input latency plus
-continuous output latency plus one buffer period. The buffer period term allows
-processing time for the app and for the app to mitigate phase difference
+continuous output latency plus one buffer period. The buffer period allows
+time for the app to process the signal and time for the app to mitigate phase difference
between input and output streams.
* **OpenSL ES PCM buffer queue API**. The set of PCM-related OpenSL ES APIs
within [Android NDK](https://developer.android.com/ndk/index.html).
diff --git a/5_multimedia/5_7_network-protocols.md b/5_multimedia/5_7_network-protocols.md
index 28a3516..70b9b49 100644
--- a/5_multimedia/5_7_network-protocols.md
+++ b/5_multimedia/5_7_network-protocols.md
@@ -5,7 +5,146 @@
audio and video playback as specified in the Android SDK documentation.
Specifically, devices MUST support the following media network protocols:
+* HTTP(S) progressive streaming <br>
+ All required codecs and container formats in [section 5.1](#5_1_media_codecs) MUST
+ be supported over HTTP(S)
+
+* [HTTP Live Streaming draft protocol, Version 7
+ ](http://tools.ietf.org/html/draft-pantos-http-live-streaming-07)<br>
+ The following media segment formats MUST be supported:
+
+<table>
+
+ <tr>
+ <th>Segment formats</th>
+ <th>Reference(s)</th>
+ <th>Required codec support</th>
+ </tr>
+
+ <tr id="mp2t">
+ <td>MPEG-2 Transport Stream</td>
+ <td><a href="http://www.iso.org/iso/catalogue_detail?csnumber=44169">ISO 13818</a></td>
+ <td>
+ Video codecs:
+ <ul>
+ <li class="table_list">H264 AVC</li>
+ <li class="table_list">MPEG-4 SP</li>
+ <li class="table_list">MPEG-2</li>
+ </ul>
+ See <a href="#5_1_3_video_codecs">section 5.1.3</a> for details on H264 AVC, MPEG2-4 SP,<br/>
+ and MPEG-2.
+ <p>Audio codecs:
+ <ul>
+ <li class="table_list">AAC</li>
+ </ul>
+ See <a href="#5_1_1_audio_codecs">section 5.1.1 </a> for details on AAC and its variants.
+ </td>
+ </tr>
+
+ <tr>
+ <td>AAC with ADTS framing and ID3 tags</td>
+ <td><a href="http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=43345">ISO 13818-7</a></td>
+ <td>See <a href="#5_1_1_audio_codecs">section 5.1.1 </a>
+ for details on AAC and its variants</td>
+ </tr>
+
+ <tr>
+ <td>WebVTT</td>
+ <td><a href="http://dev.w3.org/html5/webvtt/">WebVTT</a></td>
+ <td></td>
+ </tr>
+
+</table>
+
* RTSP (RTP, SDP)
-* HTTP(S) progressive streaming
-* HTTP(S) [Live Streaming draft protocol, Version
- 3](http://tools.ietf.org/html/draft-pantos-http-live-streaming-03)
+
+ The following RTP audio video profile and related codecs MUST be supported.
+ For exceptions please see the table footnotes in [section 5.1](#5_1_media_codecs).
+
+<table>
+ <tr>
+ <th>Profile name</th>
+ <th>Reference(s)</th>
+ <th>Required codec support</th>
+ </tr>
+
+ <tr>
+ <td>H264 AVC</td>
+ <td><a href="https://tools.ietf.org/html/rfc6184">RFC 6184</a></td>
+ <td>See <a href="#5_1_3_video_codecs">section 5.1.3 </a>
+ for details on H264 AVC</td>
+ </tr>
+
+ <tr>
+ <td>MP4A-LATM</td>
+ <td><a href="https://tools.ietf.org/html/rfc6416">RFC 6416</a></td>
+ <td>See <a href="#5_1_1_audio_codecs">section 5.1.1 </a>
+ for details on AAC and its variants</td>
+ </tr>
+
+ <tr>
+ <td>H263-1998</td>
+ <td>
+ <a href="https://tools.ietf.org/html/rfc3551">RFC 3551</a><br/>
+ <a href="https://tools.ietf.org/html/rfc4629">RFC 4629</a><br/>
+ <a href="https://tools.ietf.org/html/rfc2190">RFC 2190</a>
+ </td>
+ <td>See <a href="#5_1_3_video_codecs">section 5.1.3 </a>
+ for details on H263
+ </td>
+ </tr>
+
+ <tr>
+ <td>H263-2000</td>
+ <td>
+ <a href="https://tools.ietf.org/html/rfc4629">RFC 4629</a>
+ </td>
+ <td>See <a href="#5_1_3_video_codecs">section 5.1.3 </a>
+ for details on H263
+ </td>
+ </tr>
+
+ <tr>
+ <td>AMR</td>
+ <td>
+ <a href="https://tools.ietf.org/html/rfc4867">RFC 4867</a>
+ </td>
+ <td>See <a href="#5_1_1_audio_codecs">section 5.1.1 </a>
+ for details on AMR-NB
+ </td>
+ </tr>
+
+ <tr>
+ <td>AMR-WB</td>
+ <td>
+ <a href="https://tools.ietf.org/html/rfc4867">RFC 4867</a>
+ </td>
+ <td>See <a href="#5_1_1_audio_codecs">section 5.1.1 </a>
+ for details on AMR-WB
+ </td>
+ </tr>
+
+ <tr>
+ <td>MP4V-ES</td>
+ <td>
+ <a href="https://tools.ietf.org/html/rfc6416">RFC 6416</a>
+ </td>
+ <td>See <a href="#5_1_3_video_codecs">section 5.1.3 </a>
+ for details on MPEG-4 SP
+ </td>
+ </tr>
+
+ <tr>
+ <td>mpeg4-generic</td>
+ <td><a href="https://tools.ietf.org/html/rfc3640">RFC 3640</a></td>
+ <td>See <a href="#5_1_1_audio_codecs">section 5.1.1 </a>
+ for details on AAC and its variants</td>
+ </tr>
+
+ <tr>
+ <td>MP2T</td>
+ <td><a href="https://tools.ietf.org/html/rfc2250">RFC 2250</a></td>
+ <td>See <a href="#mp2t">MPEG-2 Transport Stream</a> underneath HTTP Live Streaming for details</td>
+ </tr>
+
+</table>
diff --git a/5_multimedia/5_9_midi.md b/5_multimedia/5_9_midi.md
index 42a1cea..886252b 100644
--- a/5_multimedia/5_9_midi.md
+++ b/5_multimedia/5_9_midi.md
@@ -12,14 +12,10 @@
* USB host mode (section 7.7 USB)
* USB peripheral mode (section 7.7 USB)
+* MIDI over Bluetooth LE acting in central role (section 7.4.3 Bluetooth)
Conversely, if the device implementation provides generic non-MIDI connectivity
over a particular MIDI-capable hardware transport listed above, but does not
support MIDI over that hardware transport, it MUST NOT report support for
feature android.software.midi.
-MIDI over Bluetooth LE acting in central role (section 7.4.3 Bluetooth) is in
-trial use status. A device implementation that reports feature
-android.software.midi, and which provides generic non-MIDI connectivity over
-Bluetooth LE, SHOULD support MIDI over Bluetooth LE.
-
diff --git a/7_hardware-compatibility/7_1_display-and-graphics.md b/7_hardware-compatibility/7_1_display-and-graphics.md
index 2ed2586..228f606 100644
--- a/7_hardware-compatibility/7_1_display-and-graphics.md
+++ b/7_hardware-compatibility/7_1_display-and-graphics.md
@@ -54,6 +54,10 @@
* Android Watch devices MUST have a screen with the physical diagonal size in
the range from 1.1 to 2.5 inches.
+* Android Automotive devices MUST have a screen with the physical diagonal
+size greater than or equal to 6 inches.
+* Android Automotive devices MUST have a screen size of at least 750 dp x
+450 dp.
* Other types of Android device implementations, with a physically integrated
screen, MUST have a screen at least 2.5 inches in physical diagonal size.
@@ -241,4 +245,3 @@
[display manager
API](http://developer.android.com/reference/android/hardware/display/DisplayManager.html)
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 dd954e6..3fd7de2 100644
--- a/7_hardware-compatibility/7_2_input-devices.md
+++ b/7_hardware-compatibility/7_2_input-devices.md
@@ -60,15 +60,18 @@
navigation paradigm and therefore:
* Android Handheld device implementations MUST provide the Home, Recents, and
-Back functions.
+ Back functions.
* Android Television device implementations MUST provide the Home and Back
-functions.
+ functions.
* 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.
+ to the user, and the Back function except for when it is in `UI_MODE_TYPE_WATCH`.
+* Android Watch device implementations, and no other Android deivce types,
+ MAY consume the long press event on the key event [`KEYCODE_BACK`](http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK)
+ and omit it from being sent to the foreground application.
* Android Automotive implementations MUST provide the Home function and MAY
-provide Back and Recent functions.
+ provide Back and Recent functions.
* All other types of device implementations MUST provide the Home and Back
-functions.
+ functions.
These functions MAY be implemented via dedicated physical buttons (such as
mechanical or capacitive touch buttons), or MAY be implemented using dedicated
diff --git a/7_hardware-compatibility/7_3_sensors.md b/7_hardware-compatibility/7_3_sensors.md
index a096606..f77e9f1 100644
--- a/7_hardware-compatibility/7_3_sensors.md
+++ b/7_hardware-compatibility/7_3_sensors.md
@@ -71,8 +71,9 @@
### 7.3.1\. Accelerometer
Device implementations SHOULD include a 3-axis accelerometer. Android Handheld
-devices and Android Watch devices are STRONGLY RECOMMENDED to include this
-sensor. If a device implementation does include a 3-axis accelerometer, it:
+devices, Android Automotive implementations, and Android Watch devices are STRONGLY
+RECOMMENDED to include this sensor. If a device implementation does include a
+3-axis accelerometer, it:
* MUST implement and report [TYPE_ACCELEROMETER
sensor](http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER).
@@ -82,7 +83,8 @@
* SHOULD report events up to at least 200 Hz.
* MUST comply with the [Android sensor coordinate
system](http://developer.android.com/reference/android/hardware/SensorEvent.html)
-as detailed in the Android APIs.
+as detailed in the Android APIs. Android Automotive implementations MUST comply
+with the Android [car sensor coordinate system](http://source.android.com/devices/sensors/sensor-types.html#auto_axes).
* MUST be capable of measuring from freefall up to four times the gravity
(4g) or more on any axis.
* MUST have a resolution of at least 12-bits and SHOULD have a resolution of
@@ -145,9 +147,46 @@
### 7.3.3\. GPS
-Device implementations SHOULD include a GPS receiver. If a device
-implementation does include a GPS receiver, it SHOULD include some form
-of“assisted GPS” technique to minimize GPS lock-on time.
+Device implementations SHOULD include a GPS/GNSS receiver. If a device implementation
+does include a GPS/GNSS receiver and reports the capability to applications through the
+`android.hardware.location.gps` feature flag:
+
+* It is STRONGLY RECOMMENDED that the device continue to deliver normal GPS/GNSS
+ outputs to applications during an emergency phone call and that location output
+ not be blocked during an emergency phone call.
+* It MUST support location outputs at a rate of at least 1Hz when requested via
+ LocationManager#requestLocationUpdate.
+* It MUST be able to determine the location in open-sky conditions (strong signals,
+ negligible multipath, HDOP < 2) within 10 seconds (fast time to first fix), when
+ connected to a 0.5 Mbps or faster data speed internet connection. This requirement
+ is typically met by the use of some form of Assisted or Predicted GPS/GNSS technique
+ to minimize GPS/GNSS lock-on time (Assistance data includes Reference Time, Reference
+ Location and Satellite Ephemeris/Clock).
+ * After making such a location calculation, it is STRONGLY RECOMMENDED for the device to
+ be able to determine its location, in open sky, within 10 seconds, when location
+ requests are restarted, up to an hour after the initial location calculation,
+ even when the subsequent request is made without a data connection, and/or after a power
+ cycle.
+* In open sky conditions after determining the location, while stationary or moving with less
+ than 1 meter per second squared of acceleration:
+ * It MUST be able to determine location within 20 meters, and speed within 0.5 meters
+ per second, at least 95% of the time.
+ * It MUST simultaneously track and report via [GnssStatus.Callback](https://developer.android.com/reference/android/location/GnssStatus.Callback.html#GnssStatus.Callback()')
+ at least 8 satellites from one constellation.
+ * It SHOULD be able to simultaneously track at least 24 satellites, from multiple
+ constellations (e.g. GPS + at least one of Glonass, Beidou, Galileo).
+* It MUST report the GNSS technology generation through the test API ‘getGnssYearOfHardware’.
+* It is STRONGLY RECOMMENDED to meet and MUST meet all requirements below if the GNSS technology
+ generation is reported as the year "2016" or newer.
+ * It MUST report GPS measurements, as soon as they are found, even if a location calculated
+ from GPS/GNSS is not yet reported.
+ * It MUST report GPS pseudoranges and pseudorange rates, that, in open-sky conditions
+ after determining the location, while stationary or moving with less than 0.2 meter
+ per second squared of acceleration, are sufficient to calculate position within
+ 20 meters, and speed within 0.2 meters per second, at least 95% of the time.
+
+Note that while some of the GPS requirements above are stated as STRONGLY RECOMMENDED, the
+Compatibility Definition for the next major version is expected to change these to a MUST.
### 7.3.4\. Gyroscope
@@ -202,6 +241,13 @@
temperature of the device CPU, and it MUST NOT measure any other temperature.
Note the SENSOR_TYPE_TEMPERATURE sensor type was deprecated in Android 4.0.
+<div class="note">
+
+For Android Automotive implementations, SENSOR_TYPE_AMBIENT_TEMPERATURE MUST
+measure the temperature inside the vehicle cabin.
+
+</div>
+
### 7.3.7\. Photometer
Device implementations MAY include a photometer (ambient light sensor).
@@ -233,19 +279,30 @@
* MUST have a measurement range between at least -8g and +8g.
* MUST have a measurement resolution of at least 1024 LSB/G.
* MUST have a minimum measurement frequency of 12.5 Hz or lower.
- * MUST have a maxmium measurement frequency of 200 Hz or higher.
+ * MUST have a maxmium measurement frequency of 400 Hz or higher.
* MUST have a measurement noise not above 400uG/√Hz.
* MUST implement a non-wake-up form of this sensor with a buffering
-capability of at least 3000 sensor events.
+ capability of at least 3000 sensor events.
* MUST have a batching power consumption not worse than 3 mW.
+ * SHOULD have a stationary noise bias stability of \<15 μg √Hz from 24hr static
+ dataset.
+ * SHOULD have a bias change vs. temperature of ≤ +/- 1mg / °C.
+ * SHOULD have a best-fit line non-linearity of ≤ 0.5%, and sensitivity change vs. temperature of ≤
+ 0.03%/C°.
* SENSOR_TYPE_GYROSCOPE
* MUST have a measurement range between at least -1000 and +1000 dps.
* MUST have a measurement resolution of at least 16 LSB/dps.
* MUST have a minimum measurement frequency of 12.5 Hz or lower.
* MUST have a maxmium measurement frequency of 200 Hz or higher.
* MUST have a measurement noise not above 0.014°/s/√Hz.
+ * SHOULD have a stationary bias stability of < 0.0002 °/s √Hz from 24-hour static dataset.
+ * SHOULD have a bias change vs. temperature of ≤ +/- 0.05 °/ s / °C.
+ * SHOULD have a sensitivity change vs. temperature of ≤ 0.02% / °C.
+ * SHOULD have a best-fit line non-linearity of ≤ 0.2%.
+ * SHOULD have a noise density of ≤ 0.07 °/s/√Hz.
+
* SENSOR_TYPE_GYROSCOPE_UNCALIBRATED with the same quality requirements as
-SENSOR_TYPE_GYROSCOPE.
+ SENSOR_TYPE_GYROSCOPE.
* SENSOR_TYPE_GEOMAGNETIC_FIELD
* MUST have a measurement range between at least -900 and +900 uT.
* MUST have a measurement resolution of at least 5 LSB/uT.
@@ -253,9 +310,9 @@
* MUST have a maxmium measurement frequency of 50 Hz or higher.
* MUST have a measurement noise not above 0.5 uT.
* SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED with the same quality requirements
-as SENSOR_TYPE_GEOMAGNETIC_FIELD and in addition:
+ as SENSOR_TYPE_GEOMAGNETIC_FIELD and in addition:
* MUST implement a non-wake-up form of this sensor with a buffering
-capability of at least 600 sensor events.
+ capability of at least 600 sensor events.
* SENSOR_TYPE_PRESSURE
* MUST have a measurement range between at least 300 and 1100 hPa.
* MUST have a measurement resolution of at least 80 LSB/hPa.
@@ -263,27 +320,27 @@
* MUST have a maximum measurement frequency of 10 Hz or higher.
* MUST have a measurement noise not above 2 Pa/√Hz.
* MUST implement a non-wake-up form of this sensor with a buffering
-capability of at least 300 sensor events.
+ capability of at least 300 sensor events.
* MUST have a batching power consumption not worse than 2 mW.
* SENSOR_TYPE_ROTATION_VECTOR
* MUST have a batching power consumption not worse than 4 mW.
* SENSOR_TYPE_GAME_ROTATION_VECTOR MUST implement a non-wake-up form of this
-sensor with a buffering capability of at least 300 sensor events.
+ sensor with a buffering capability of at least 300 sensor events.
* SENSOR_TYPE_SIGNIFICANT_MOTION
* MUST have a power consumption not worse than 0.5 mW when device is
-static and 1.5 mW when device is moving.
+ static and 1.5 mW when device is moving.
* SENSOR_TYPE_STEP_DETECTOR
* MUST implement a non-wake-up form of this sensor with a buffering
-capability of at least 100 sensor events.
+ capability of at least 100 sensor events.
* MUST have a power consumption not worse than 0.5 mW when device is
-static and 1.5 mW when device is moving.
+ static and 1.5 mW when device is moving.
* MUST have a batching power consumption not worse than 4 mW.
* SENSOR_TYPE_STEP_COUNTER
* MUST have a power consumption not worse than 0.5 mW when device is
-static and 1.5 mW when device is moving.
+ static and 1.5 mW when device is moving.
* SENSOR_TILT_DETECTOR
* MUST have a power consumption not worse than 0.5 mW when device is
-static and 1.5 mW when device is moving.
+ static and 1.5 mW when device is moving.
Also such a device MUST meet the following sensor subsystem requirements:
@@ -292,9 +349,9 @@
milliseconds of each other.
* The Gyroscope sensor event timestamps MUST be on the same time base as the
camera subsystem and within 1 millisconds of error.
-* The latency of delivery of samples to the HAL SHOULD be below 5
-milliseconds from the instant the data is available on the physical sensor
-hardware.
+* High Fidelity sensors MUST deliver samples to applications within 5
+milliseconds from the time when the data is available on the physical sensor
+to the application.
* The power consumption MUST not be higher than 0.5 mW when device is static
and 2.0 mW when device is moving when any combination of the following sensors
are enabled:
@@ -352,3 +409,31 @@
* SHOULD use the Android Fingerprint icon provided in the Android Open Source
Project.
+### 7.3.11\. Android Automotive-only sensors
+
+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.
+
+#### 7.3.11.2\. Day Night Mode
+
+Android Automotive implementations MUST support day/night mode defined as
+SENSOR_TYPE_NIGHT. The value of this 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).
+
+#### 7.3.11.3\. Driving Status
+
+Android Automotive implementations 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 OEM
+to configure SENSOR_TYPE_DRIVING_STATUS in compliance with all laws and
+regulations that apply to markets where the product is shipping.
+
+#### 7.3.11.4\. Wheel Speed
+
+Android Automotive implementations MUST provide vehicle speed defined as
+SENSOR_TYPE_CAR_SPEED.
diff --git a/7_hardware-compatibility/7_4_data-connectivity.md b/7_hardware-compatibility/7_4_data-connectivity.md
index c25fe10..c71552c 100644
--- a/7_hardware-compatibility/7_4_data-connectivity.md
+++ b/7_hardware-compatibility/7_4_data-connectivity.md
@@ -82,8 +82,9 @@
<div class="note">
-Android Watch and Automotive implementations MUST support Bluetooth. Android
-Television implementations MUST support Bluetooth and Bluetooth LE.
+Android Watch implementations MUST support Bluetooth. Android Television
+implementations MUST support Bluetooth and Bluetooth LE. Android Automotive
+implementations MUST support Bluetooth and SHOULD support Bluetooth LE.
</div>
@@ -93,8 +94,16 @@
Energy MUST declare the relevant platform features (android.hardware.bluetooth
and android.hardware.bluetooth_le respectively) and implement the platform
APIs. Device implementations SHOULD implement relevant Bluetooth profiles such
-as A2DP, AVCP, OBEX, etc. as appropriate for the device. Android Television
-device implementations MUST support Bluetooth and Bluetooth LE.
+as A2DP, AVCP, OBEX, etc. as appropriate for the device.
+
+Android Automotive implementations SHOULD support Message Access Profile (MAP).
+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).
Device implementations including support for Bluetooth Low Energy:
@@ -204,14 +213,22 @@
Forum specifications cited above.)
Android includes support for NFC Host Card Emulation (HCE) mode. If a device
-implementation does include an NFC controller chipset capable of HCE and
-Application ID (AID) routing, then it:
+implementation does include an NFC controller chipset capable of HCE (for NfcA
+and/or NfcB) and it supports Application ID (AID) routing, then it:
* MUST report the android.hardware.nfc.hce feature constant.
* MUST support [NFC HCE
APIs](http://developer.android.com/guide/topics/connectivity/nfc/hce.html) as
defined in the Android SDK.
+If a device implementation does include an NFC controller chipset capable of HCE
+for NfcF, and it implements the feature for third-party applications, then it:
+
+* MUST report the android.hardware.nfc.hcef feature constant.
+* MUST implement the [NfcF Card Emulation APIs]
+(https://developer.android.com/reference/android/nfc/cardemulation/NfcFCardEmulation.html)
+as defined in the Android SDK.
+
Additionally, device implementations MAY include reader/writer support for the
following MIFARE technologies.
@@ -288,4 +305,3 @@
that the method
[getMasterSyncAutomatically()](http://developer.android.com/reference/android/content/ContentResolver.html)
returns “true”.
-
diff --git a/7_hardware-compatibility/7_5_cameras.md b/7_hardware-compatibility/7_5_cameras.md
index 8efb581..fe963bf 100644
--- a/7_hardware-compatibility/7_5_cameras.md
+++ b/7_hardware-compatibility/7_5_cameras.md
@@ -8,9 +8,10 @@
typically used to image the user, such as for video conferencing and similar
applications.
-If a device implementation includes at least one camera, it SHOULD be possible
-for an application to simultaneously allocate 3 bitmaps equal to the size of
-the images produced by the largest-resolution camera sensor on the device.
+If a device implementation includes at least one camera, it MUST be possible for
+an application to simultaneously allocate 3 RGBA_8888 bitmaps equal to the size
+of the images produced by the largest-resolution camera sensor on the device,
+while camera is open for the purpose of basic preview and still capture.
### 7.5.1\. Rear-Facing Camera
@@ -66,20 +67,22 @@
### 7.5.3\. External Camera
-Device implementations with USB host mode MAY include support for an external
-camera that connects to the USB port. If a device includes support for an
-external camera, it:
+Device implementations MAY include support for an external camera that is not
+necessarily always connected. If a device includes support for an external camera,
+it:
-* MUST declare the platform feature android.hardware.camera.external and
-android.hardware camera.any.
-* MUST support USB Video Class (UVC 1.0 or higher).
+
+* MUST declare the platform feature flag `android.hardware.camera.external` and
+ `android.hardware camera.any`.
* MAY support multiple cameras.
-
-Video compression (such as MJPEG) support is RECOMMENDED to enable transfer of
-high-quality unencoded streams (i.e. raw or independently compressed picture
-streams). Camera-based video encoding MAY be supported. If so, a simultaneous
-unencoded/ MJPEG stream (QVGA or greater resolution) MUST be accessible to the
-device implementation.
+* MUST support USB Video Class (UVC 1.0 or higher) if the external camera
+ connects through the USB port.
+* SHOULD support video compressions such as MJPEG to enable transfer of
+ high-quality unencoded streams (i.e. raw or independently compressed picture
+ streams).
+* MAY support camera-based video encoding. If supported, a simultaneous
+ unencoded / MJPEG stream (QVGA or greater resolution) MUST be accessible to
+ the device implementation.
### 7.5.4\. Camera API Behavior
diff --git a/7_hardware-compatibility/7_6_memory-and-storage.md b/7_hardware-compatibility/7_6_memory-and-storage.md
index 5038310..c30015c 100644
--- a/7_hardware-compatibility/7_6_memory-and-storage.md
+++ b/7_hardware-compatibility/7_6_memory-and-storage.md
@@ -151,58 +151,4 @@
ports as the device is expected to be static and not mobile. But for other
device implementations that are mobile in nature, it is STRONGLY RECOMMENDED to
implement the adoptable storage in a long-term stable location, since
-accidentally disconnecting them can cause data loss/corruption.
-
-## 7.7\. USB
-
-Device implementations SHOULD support USB peripheral mode and SHOULD support
-USB host mode.
-
-If a device implementation includes a USB port supporting peripheral mode:
-
-* The port MUST be connectable to a USB host that has a standard type-A or type-C USB port.
-* The port SHOULD use micro-B, micro-AB or Type-C USB form factor. Existing and new Android devices are **STRONGLY RECOMMENDED to meet these requirements** so they will be able to upgrade to the future platform releases.
-* The port SHOULD either locate the port on the bottom of the device
-(according to natural orientation) or enable software screen rotation for all
-apps (including home screen), so that the display draws correctly when the
-device is oriented with the port at bottom. Existing and new Android devices
-are **STRONGLY RECOMMENDED to meet these requirements** so they will be able to
-upgrade to future platform releases.
-* It MUST allow a USB host connected with the Android device to access the
-contents of the shared storage volume using either USB mass storage or Media
-Transfer Protocol.
-* It SHOULD implement the Android Open Accessory (AOA) API and specification
-as documented in the Android SDK documentation, and if it is an Android
-Handheld device it MUST implement the AOA API. Device implementations
-implementing the AOA specification:
- * MUST declare support for the hardware feature
-[android.hardware.usb.accessory](http://developer.android.com/guide/topics/connectivity/usb/accessory.html).
- * MUST implement the [USB audio
-class](http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO)as
-documented in the Android SDK documentation.
- * The USB mass storage class MUST include the string "android" at the end
-of the interface description `iInterface` string of the USB mass storage
-* It SHOULD implement support to draw 1.5 A current during HS chirp and
-traffic as specified in the [USB Battery Charging specification, revision
-1.2](http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip).
-Existing and new Android devices are **STRONGLY RECOMMENDED to meet these
-requirements** so they will be able to upgrade to the future platform releases.
-* The value of iSerialNumber in USB standard device descriptor MUST be equal
-to the value of android.os.Build.SERIAL.
-
-If a device implementation includes a USB port supporting host mode, it:
-
-* SHOULD use a type-C USB port, if the device implementation supports USB 3.1.
-* MAY use a non-standard port form factor, but if so MUST ship with a cable
-or cables adapting the port to a standard type-A or type-C USB port.
-* MAY use a micro-AB USB port, but if so SHOULD ship with a cable or cables
-adapting the port to a standard type-A or type-C USB port.
-* is **STRONGLY RECOMMENDED** to implement the [USB audio
-class](http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO)
-as documented in the Android SDK documentation.
-* MUST implement the Android USB host API as documented in the Android SDK,
-and MUST declare support for the hardware feature
-[android.hardware.usb.host](http://developer.android.com/guide/topics/connectivity/usb/host.html).
-* SHOULD support the Charging Downstream Port output current range of 1.5 A ~
-5 A as specified in the [USB Battery Charging specifications, revision
-1.2](http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip).
+accidentally disconnecting them can cause data loss/corruption.
\ No newline at end of file
diff --git a/7_hardware-compatibility/7_7_usb.md b/7_hardware-compatibility/7_7_usb.md
new file mode 100644
index 0000000..a74109d
--- /dev/null
+++ b/7_hardware-compatibility/7_7_usb.md
@@ -0,0 +1,74 @@
+## 7.7\. USB
+
+Device implementations SHOULD support USB peripheral mode and SHOULD support
+USB host mode.
+
+If a device implementation includes a USB port supporting peripheral mode:
+
+* The port MUST be connectable to a USB host that has a standard type-A or
+type-C USB port.
+
+* The port SHOULD use micro-B, micro-AB or Type-C USB form factor. Existing
+and new Android devices are **STRONGLY RECOMMENDED to meet these requirements**
+so they will be able to upgrade to the future platform releases.
+
+* The port SHOULD either locate the port on the bottom of the device
+(according to natural orientation) or enable software screen rotation for all
+apps (including home screen), so that the display draws correctly when the
+device is oriented with the port at bottom. Existing and new Android devices
+are **STRONGLY RECOMMENDED to meet these requirements** so they will be able to
+upgrade to future platform releases.
+
+* It MUST allow a USB host connected with the Android device to access the
+contents of the shared storage volume using either USB mass storage or Media
+Transfer Protocol.
+
+* It SHOULD implement the Android Open Accessory (AOA) API and specification
+as documented in the Android SDK documentation, and if it is an Android
+Handheld device it MUST implement the AOA API. Device implementations
+implementing the AOA specification:
+
+ * MUST declare support for the hardware feature
+[android.hardware.usb.accessory](http://developer.android.com/guide/topics/connectivity/usb/accessory.html).
+
+ * MUST support establishing an [AOA protocol based
+communication](http://source.android.com/devices/accessories/aoa.html) on first
+time connection with a USB host machine that acts as an accessory, without the
+need for the user to change the default USB mode.
+
+ * MUST implement the [USB audio
+class](http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO)as
+documented in the Android SDK documentation.
+
+ * The USB mass storage class MUST include the string "android" at the end
+of the interface description `iInterface` string of the USB mass storage
+
+* It SHOULD implement support to draw 1.5 A current during HS chirp and
+traffic as specified in the [USB Battery Charging specification, revision
+1.2](http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip).
+Existing and new Android devices are **STRONGLY RECOMMENDED to meet these
+requirements** so they will be able to upgrade to the future platform releases.
+
+* The value of iSerialNumber in USB standard device descriptor MUST be equal
+to the value of android.os.Build.SERIAL.
+
+If a device implementation includes a USB port supporting host mode, it:
+
+* SHOULD use a type-C USB port, if the device implementation supports USB
+3.1.
+
+* MAY use a non-standard port form factor, but if so MUST ship with a cable
+or cables adapting the port to a standard type-A or type-C USB port.
+
+* MAY use a micro-AB USB port, but if so SHOULD ship with a cable or cables
+adapting the port to a standard type-A or type-C USB port.
+
+* is **STRONGLY RECOMMENDED** to implement the [USB audio
+class](http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO)
+as documented in the Android SDK documentation.
+
+* MUST implement the Android USB host API as documented in the Android SDK,
+and MUST declare support for the hardware feature
+[android.hardware.usb.host](http://developer.android.com/guide/topics/connectivity/usb/host.html).
+
+* SHOULD support the Charging Downstream Port output current range of 1.5 A ~ 5 A as specified in the [USB Battery Charging specifications, revision 1.2](http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip).
diff --git a/7_hardware-compatibility/7_8_audio.md b/7_hardware-compatibility/7_8_audio.md
index 2a87a6a..137d5eb 100644
--- a/7_hardware-compatibility/7_8_audio.md
+++ b/7_hardware-compatibility/7_8_audio.md
@@ -63,15 +63,15 @@
* MUST support the detection of microphone on the plugged in audio accessory,
if the device implementation supports a microphone, and broadcast the
android.intent.action.HEADSET_PLUG with the extra value microphone set as 1.
-* SHOULD support the detection and mapping to the keycodes for the following
+* MUST support the detection and mapping to the keycodes for the following
3 ranges of equivalent impedance between the microphone and ground conductors
on the audio plug:
* **70 ohm or less**: KEYCODE_HEADSETHOOK
* **210-290 Ohm**: KEYCODE_VOLUME_UP
* **360-680 Ohm**: KEYCODE_VOLUME_DOWN
-* SHOULD support the detection and mapping to the keycode for the following
-range of equivalent impedance between the microphone and ground conductors on
-the audio plug:
+* STRONGLY RECOMMENDED to detect and map to the keycode for the following
+range of equivalent impedance between the microphone and ground conductors
+on the audio plug:
* **110-180 Ohm:** KEYCODE_VOICE_ASSIST
* MUST trigger ACTION_HEADSET_PLUG upon a plug insert, but only after all
contacts on plug are touching their relevant segments on the jack.
@@ -88,10 +88,12 @@
* If
[PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND](http://developer.android.com/reference/android/media/AudioManager.html#PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND)
-is "true", then
+is "true", then the following requirements must be met by the
+VOICE_RECOGNITION and UNPROCESSED audio sources:
* The microphone's mean power response in the 18.5 kHz to 20 kHz band
MUST be no more than 15 dB below the response at 2 kHz.
- * The signal to noise ratio of the microphone MUST be no lower than 80 dB.
+ * The microphone's unweighted signal to noise ratio over 18.5 kHz to 20 kHz
+for a 19 kHz tone at -26 dBFS MUST be no lower than 50 dB.
* If
[PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND](http://developer.android.com/reference/android/media/AudioManager.html#PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND)
is "true", then the speaker's mean response in 18.5 kHz - 20 kHz MUST be no
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 370985e..33e6639 100644
--- a/8_performance-and-power/8_3_power-saving-modes.md
+++ b/8_performance-and-power/8_3_power-saving-modes.md
@@ -1,6 +1,13 @@
## 8.3\. Power-Saving Modes
-All apps exempted from App Standby and/or Doze mode MUST be made visible to the
-end user. Further, the triggering, maintenance, wakeup algorithms and the use
-of Global system settings of these power-saving modes MUST not deviate from the
+Android 6.0 introduced App Standby and Doze power-saving modes to optimize
+battery usage. All Apps exempted from these modes MUST be made visible to the
+end user. Further, the triggering, maintenance, wakeup algorithms and the use of
+global system settings of these power-saving modes MUST not deviate from the
Android Open Source Project.
+
+In addition to the power-saving modes, Android device implementations MAY
+implement any or all of the 4 sleeping power states as defined by the Advanced
+Configuration and Power Interface (ACPI), but if it implements S3 and S4
+power states, it can only enter these states when closing a lid that is
+physically part of the device.
diff --git a/9_security-model/9_10_device-integrity.md b/9_security-model/9_10_device-integrity.md
new file mode 100644
index 0000000..6c7e4ea
--- /dev/null
+++ b/9_security-model/9_10_device-integrity.md
@@ -0,0 +1,40 @@
+## 9.10\. Device Integrity
+
+The following requirements ensures there is transparancy to the status of the
+device integrity.
+
+Device implementations MUST correctly report through the System API method
+PersistentDataBlockManager.getFlashLockState() whether their bootloader state
+permits flashing of the system image. The `FLASH_LOCK_UNKNOWN` state is reserved
+for device implementations upgrading from an earlier version of Android where this
+new system API method did not exist.
+
+Verified boot is a feature that guarantees the integrity of the device
+software. If a device implementation supports the feature, it MUST:
+
+* Declare the platform feature flag android.software.verified_boot.
+* Perform verification on every boot sequence.
+* Start verification from an immutable hardware key that is the root of trust
+and go all the way up to the system partition.
+* Implement each stage of verification to check the integrity and
+authenticity of all the bytes in the next stage before executing the code in
+the next stage.
+* Use verification algorithms as strong as current recommendations from NIST
+for hashing algorithms (SHA-256) and public key sizes (RSA-2048).
+* MUST NOT allow boot to complete when system verification fails, unless the
+user consents to attempt booting anyway, in which case the data from any
+non-verified storage blocks MUST not be used.
+* MUST NOT allow verified partitions on the device to be modified unless the
+user has explicitly unlocked the boot loader.
+
+The upstream Android Open Source Project provides a preferred implementation of
+this feature based on the Linux kernel feature dm-verity.
+
+Starting from Android 6.0, device implementations with Advanced Encryption
+Standard (AES) crypto perfomance above 50MiB/seconds MUST support verified boot
+for device integrity.
+
+If a device implementation is already launched without supporting verified boot
+on an earlier version of Android, such a device can not add support for this feature
+with a system software update and thus are exempted from the requirement.
+
diff --git a/9_security-model/9_10_verified-boot.md b/9_security-model/9_10_verified-boot.md
deleted file mode 100644
index e548df7..0000000
--- a/9_security-model/9_10_verified-boot.md
+++ /dev/null
@@ -1,24 +0,0 @@
-## 9.10\. Verified Boot
-
-Verified boot is a feature that guarantees the integrity of the device
-software. If a device implementation supports the feature, it MUST:
-
-* Declare the platform feature flag android.software.verified_boot.
-* Perform verification on every boot sequence.
-* Start verification from an immutable hardware key that is the root of trust
-and go all the way up to the system partition.
-* Implement each stage of verification to check the integrity and
-authenticity of all the bytes in the next stage before executing the code in
-the next stage.
-* Use verification algorithms as strong as current recommendations from NIST
-for hashing algorithms (SHA-256) and public key sizes (RSA-2048).
-
-The upstream Android Open Source Project provides a preferred implementation of
-this feature based on the Linux kernel feature dm-verity.
-
-Starting from Android 6.0, device implementations with Advanced Encryption
-Standard (AES) crypto perfomance above 50MiB/seconds MUST support verified boot
-for device integrity. If a device implementation is already launched without
-supporting verified boot on an earlier version of Android, such a device can
-not add support for this feature with a system software update and thus are
-exempted from the requirement.
diff --git a/9_security-model/9_11_keys-and-credentials.md b/9_security-model/9_11_keys-and-credentials.md
index 058901c..c9c5de9 100644
--- a/9_security-model/9_11_keys-and-credentials.md
+++ b/9_security-model/9_11_keys-and-credentials.md
@@ -10,29 +10,22 @@
All Android device implementations MUST meet the following requirements:
* SHOULD not limit the number of keys that can be generated, and MUST at
-least allow more than 8,192 keys to be imported.
-* The lock screen authentication MUST rate limit attempts and SHOULD have an
- exponential backoff algorithm as implemented in the Android Open Source
- Project.
-* When the device implementation supports a secure lock screen and has a
-secure hardware such as a Secure Element (SE) where a Trusted Execution
-Environment (TEE) can be implemented, then it:
- * Is STRONGLY RECOMMENDED to back up the keystore implementation with the
-secure hardware. The upstream Android Open Source Project provides the
-Keymaster Hardware Abstraction Layer (HAL) implementation that can be used to
-satisfy this requirement.
- * MUST perform the lock screen authentication in the secure hardware if
-the device has a hardware-backed keystore implementation and only when
-successful allow the authentication-bound keys to be used. The upstream Android
-Open Source Project provides the [Gatekeeper Hardware Abstraction Layer
-(HAL)](http://source.android.com/devices/tech/security/authentication/gatekeeper.html)
-that can be used to satisfy this requirement.
+least allow more than 8,192 keys to be imported.
+* The lock screen authentication MUST rate limit attempts and MUST have an
+ exponential backoff algorithm. Beyond 150 failed attempts, the delay MUST be
+ at least 24 hours per attempt.
+* When the device implementation supports a secure lock screen it MUST back up the
+ keystore implementation with secure hardware and meet following requirements:
+ * MUST have hardware backed implementations of RSA, AES, ECDSA and HMAC cryptographic
+ algorithms and MD5, SHA1, SHA-2 Family hash functions to properly support the
+ [Android Keystore system's supported algorithms]
+ (https://developer.android.com/training/articles/keystore.html#SupportedAlgorithms).
+ * MUST perform the lock screen authentication in the secure hardware and only when
+ successful allow the authentication-bound keys to be used. The upstream Android
+ Open Source Project provides the [Gatekeeper Hardware Abstraction Layer
+ (HAL)](http://source.android.com/devices/tech/security/authentication/gatekeeper.html)
+ that can be used to satisfy this requirement.
-Note that while the above TEE-related requirements are stated as STRONGLY
-RECOMMENDED, the Compatibility Definition for the next API version is planned
-to changed these to REQIUIRED. If a device implementation is already launched
-on an earlier Android version and has not implemented a trusted operating
-system on the secure hardware, such a device might not be able to meet the
-requirements through a system software update and thus is STRONGLY RECOMMENDED
-to implement a TEE.
-
+Note that if a device implementation is already launched on an earlier Android version, and does
+not have a fingerprint scanner, such a device is exempted from the requirement to have a
+hardware-backed keystore.
\ No newline at end of file
diff --git a/9_security-model/9_12_data-deletion.md b/9_security-model/9_12_data-deletion.md
index d23e35c..7b8182a 100644
--- a/9_security-model/9_12_data-deletion.md
+++ b/9_security-model/9_12_data-deletion.md
@@ -1,9 +1,11 @@
## 9.12\. Data Deletion
Devices MUST provide users with a mechanism to perform a "Factory Data Reset"
-that allows logical and physical deletion of all data except for the system
-image and any operating system files required by the system image. All
-user-generated data MUST be deleted. This MUST satisfy relevant industry
+that allows logical and physical deletion of all data except for the following:
+ * The system image
+ * Any operating system files required by the system image
+
+All user-generated data MUST be deleted. This MUST satisfy relevant industry
standards for data deletion such as NIST SP800-88\. This MUST be used for the
implementation of the wipeData() API (part of the Android Device Administration
API) described in [section 3.9 Device
diff --git a/9_security-model/9_13_automotive-system-isolation.md b/9_security-model/9_13_automotive-system-isolation.md
new file mode 100644
index 0000000..b4c35bf
--- /dev/null
+++ b/9_security-model/9_13_automotive-system-isolation.md
@@ -0,0 +1,16 @@
+## 9.13\. Automotive Vehicle System Isolation
+
+Android Automotive devices are expected to exchange data with critical vehicle
+subsystems, e.g., by using the [vehicle
+HAL](http://source.android.com/devices/automotive.html) to send and receive
+messages over vehicle networks such as CAN bus. Android Automotive device
+implementations MUST implement security features below the Android framework
+layers to prevent malicious or unintentional interaction between the Android
+framework or third-party apps and vehicle subsystems. These security features
+are as follows:
+
+* Gatekeeping messages from Android framework vehicle subsystems, e.g.,
+ whitelisting permitted message types and message sources.
+* 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/9_security-model/9_5_multi-user-support.md b/9_security-model/9_5_multi-user-support.md
index d2b5863..a392990 100644
--- a/9_security-model/9_5_multi-user-support.md
+++ b/9_security-model/9_5_multi-user-support.md
@@ -12,6 +12,9 @@
multiple users, but when enabled MUST meet the following requirements related
to [multi-user support](http://source.android.com/devices/storage/traditional.html):
+* Android Automotive device implementations with multi-user support enabled
+MUST include a guest account that allows all functions provided by the vehicle
+system without requiring a user to log in.
* Device implementations that do not declare the android.hardware.telephony
feature flag MUST support restricted profiles, a feature that allows device
owners to manage additional users and their capabilities on the device. With
diff --git a/9_security-model/9_7_kernel-security-features.md b/9_security-model/9_7_kernel-security-features.md
index 2600cac..bddf21b 100644
--- a/9_security-model/9_7_kernel-security-features.md
+++ b/9_security-model/9_7_kernel-security-features.md
@@ -1,9 +1,9 @@
## 9.7\. Kernel Security Features
The Android Sandbox includes features that use the Security-Enhanced Linux
-(SELinux) mandatory access control (MAC) system and other security features in
-the Linux kernel. SELinux or any other security features implemented below the
-Android framework:
+(SELinux) mandatory access control (MAC) system, seccomp sandboxing, and other
+security features in the Linux kernel. SELinux or any other security features
+implemented below the Android framework:
* MUST maintain compatibility with existing applications.
* MUST NOT have a visible user interface when a security violation is
@@ -36,3 +36,10 @@
implementations MUST be compatible with the upstream Android Open Source
Project.
+Devices MUST implement a kernel application sandboxing mechanism which allows
+filtering of system calls using a configurable policy from multithreaded
+programs. The upstream Android Open Source Project meets this requirement
+through enabling the seccomp-BPF with threadgroup synchronization (TSYNC) as
+described (here)[http://source.android.com/security/overview/kernel-security.html#seccomp-with-tsync].
+
+
diff --git a/9_security-model/9_8_privacy.md b/9_security-model/9_8_privacy.md
index 8d795e8..94d6ea7 100644
--- a/9_security-model/9_8_privacy.md
+++ b/9_security-model/9_8_privacy.md
@@ -8,7 +8,11 @@
If a device implementation has a mechanism that routes network data traffic
through a proxy server or VPN gateway by default (for example, preloading a VPN
service with android.permission.CONTROL_VPN granted), the device implementation
-MUST ask for the user's consent before enabling that mechanism.
+MUST ask for the user's consent before enabling that mechanism, unless that
+VPN is enabled by the Device Policy Controller via the
+[`DevicePolicyManager.setAlwaysOnVpnPackage()`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setAlwaysOnVpnPackage(android.content.ComponentName, java.lang.String, boolean))
+, in which case the user does not need to provide a separate consent, but MUST
+only be notified.
If a device implementation has a USB port with USB peripheral mode support, it
MUST present a user interface asking for the user's consent before allowing
diff --git a/make_cdd.py b/make_cdd.py
old mode 100644
new mode 100755
index 396769d..348aef7
--- a/make_cdd.py
+++ b/make_cdd.py
@@ -1,3 +1,4 @@
+#!/usr/bin/python
"""
Utility for building the CDD from component markdown files.
@@ -32,7 +33,7 @@
# for rootdir, subdirs, files in os.walk(my_path):
for dir in get_immediate_subdirs(my_path):
# for dir in subdirs:
- if (not dir.isalpha() and dir != 'older-versions'):
+ if (not dir.isalpha() and dir != 'older-versions' and dir != '.git'):
child_data = []
print 'dir = ' + dir
for file in os.listdir(dir):