diff options
Diffstat (limited to 'src/compatibility/android-cdd.jd')
| -rw-r--r-- | src/compatibility/android-cdd.jd | 303 |
1 files changed, 150 insertions, 153 deletions
diff --git a/src/compatibility/android-cdd.jd b/src/compatibility/android-cdd.jd index bc46fe51..0053fd62 100644 --- a/src/compatibility/android-cdd.jd +++ b/src/compatibility/android-cdd.jd @@ -19,7 +19,7 @@ fullpage=true --> <div id="qv-wrapper"> <div id="qv"> - <h4>In this document</h5> + <h2>In this document</h2> <ol id="auto-toc"> </ol> </div> @@ -100,9 +100,9 @@ fullpage=true <p> 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 7.1 compatible, unless the requirement is explicitly described to be only applicable to a specific Android device type from above. </p> - <h2 id="2_1_device_configurations"> + <h3 id="2_1_device_configurations"> 2.1 Device Configurations - </h2> + </h3> <p> 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. </p> @@ -233,7 +233,7 @@ fullpage=true <td></td> </tr> <tr> - <td rowspan="5"> + <td rowspan="6"> Connectivity </td> <td> @@ -326,7 +326,7 @@ fullpage=true Cellular radio </td> <td> - <a href="#7_4_5_minimum-network-capability">7.4.5. Minimum Network Capability</a> + <a href="#7_4_5_minimum_network_capability">7.4.5. Minimum Network Capability</a> </td> <td></td> <td></td> @@ -383,9 +383,9 @@ fullpage=true <h2 id="3_software"> 3. Software </h2> - <h2 id="3_1_managed_api_compatibility"> + <h3 id="3_1_managed_api_compatibility"> 3.1. Managed API Compatibility - </h2> + </h3> <p> The managed Dalvik bytecode execution environment is the primary vehicle for Android applications. The Android application programming interface (API) is the set of Android platform interfaces exposed to applications running in the managed runtime environment. Device implementations MUST provide complete implementations, including all documented behaviors, of any documented API exposed by the <a href="http://developer.android.com/reference/packages.html">Android SDK</a> or any API decorated with the “@SystemApi” marker in the upstream Android source code. </p> @@ -398,15 +398,15 @@ fullpage=true <p> This Compatibility Definition permits some types of hardware for which Android includes APIs to be omitted by device implementations. In such cases, the APIs MUST still be present and behave in a reasonable way. See <a href="#7_hardware_compatibility">section 7</a> for specific requirements for this scenario. </p> - <h2 id="3_1_1_android_extensions"> + <h3 id="3_1_1_android_extensions"> 3.1.1. Android Extensions - </h2> + </h3> <p> Android includes the support of extending the managed APIs while keeping the same API level version. Android device implementations MUST preload the AOSP implementation of both the shared library <code>ExtShared</code> and services <code>ExtServices</code> with versions higher than or equal to the minimum versions allowed per each API level. For example, Android 7.0 device implementations, running API level 24 MUST include at least version 1. </p> - <h2 id="3_2_soft_api_compatibility"> + <h3 id="3_2_soft_api_compatibility"> 3.2. Soft API Compatibility - </h2> + </h3> <p> In addition to the managed APIs from <a href="#3_1_managed_api_compatibility">section 3.1</a> , Android also includes a significant runtime-only “soft” API, in the form of such things as intents, permissions, and similar aspects of Android applications that cannot be enforced at application compile time. </p> @@ -749,14 +749,14 @@ fullpage=true </li> <li>MUST honor the <a href="http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFC_PAYMENT_SETTINGS">android.settings.NFC_PAYMENT_SETTINGS</a> intent to show a default app settings menu for Tap and Pay, if the device implementation reports android.hardware.nfc.hce. </li> - <li>MUST honor the <a href="https://developer.android.com/reference/android/telecom/TelecomManager.html#ACTION_CHANGE_DEFAULT_DIALER"><code>android.telecom.action.CHANGE_DEFAULT_DIALER</code></a> intent to show a dialog to allow the user to change the default Phone application, if the device implementation reports <code>android.hardware.telephony</code> . + <li>MUST honor the <a href="https://developer.android.com/reference/android/telecom/TelecomManager.html#ACTION_CHANGE_DEFAULT_DIALER">android.telecom.action.CHANGE_DEFAULT_DIALER</a> intent to show a dialog to allow the user to change the default Phone application, if the device implementation reports <code>android.hardware.telephony</code> . </li> <li>MUST honor the <a href="https://developer.android.com/reference/android/provider/Settings.html#ACTION_VOICE_INPUT_SETTINGS">android.settings.ACTION_VOICE_INPUT_SETTINGS</a> intent when the device supports the VoiceInteractionService and show a default app settings menu for voice input and assist. </li> </ul> - <h2 id="3_3_native_api_compatibility"> + <h3 id="3_3_native_api_compatibility"> 3.3. Native API Compatibility - </h2> + </h3> <p> Native code compatibility is challenging. For this reason, device implementers are <strong>STRONGLY RECOMMENDED</strong> to use the implementations of the libraries listed below from the upstream Android Open Source Project. </p> @@ -826,7 +826,7 @@ fullpage=true </li> <li>libstdc++ (Minimal support for C++) </li> - <li>libvukan.so (Vulkan) + <li>libvulkan.so (Vulkan) </li> <li>libz (Zlib compression) </li> @@ -878,7 +878,7 @@ fullpage=true <ul> <li>MUST report 0 <code>VkPhysicalDevices</code> through the <code>vkEnumeratePhysicalDevices</code> call. </li> - <li>MUST NOT delare any of the Vulkan feature flags <a href="https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_VULKAN_HARDWARE_LEVEL"><code>PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL</code></a> and <a href="https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_VULKAN_HARDWARE_VERSION"><code>PackageManager#FEATURE_VULKAN_HARDWARE_VERSION</code></a> . + <li>MUST NOT declare any of the Vulkan feature flags <a href="https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_VULKAN_HARDWARE_LEVEL"><code>PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL</code></a> and <a href="https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_VULKAN_HARDWARE_VERSION"><code>PackageManager#FEATURE_VULKAN_HARDWARE_VERSION</code></a> . </li> </ul> <h4 id="3_3_2_32-bit_arm_native_code_compatibility"> @@ -907,9 +907,9 @@ fullpage=true <p> These requirements only apply when /proc/cpuinfo is read by 32-bit ARM applications. Devices SHOULD not alter /proc/cpuinfo when read by 64-bit ARM or non-ARM applications. </p> - <h2 id="3_4_web_compatibility"> + <h3 id="3_4_web_compatibility"> 3.4. Web Compatibility - </h2> + </h3> <h4 id="3_4_1_webview_compatibility"> 3.4.1. WebView Compatibility </h4> @@ -975,9 +975,9 @@ fullpage=true <p> Additionally, device implementations MUST support the HTML5/W3C <a href="http://www.w3.org/TR/webstorage/">webstorage API</a> and SHOULD support the HTML5/W3C <a href="http://www.w3.org/TR/IndexedDB/">IndexedDB API</a> . Note that as the web development standards bodies are transitioning to favor IndexedDB over webstorage, IndexedDB is expected to become a required component in a future version of Android. </p> - <h2 id="3_5_api_behavioral_compatibility"> + <h3 id="3_5_api_behavioral_compatibility"> 3.5. API Behavioral Compatibility - </h2> + </h3> <p> The behaviors of each of the API types (managed, soft, native, and web) must be consistent with the preferred implementation of the upstream <a href="http://source.android.com/">Android Open Source Project</a> . Some specific areas of compatibility are: </p> @@ -992,9 +992,9 @@ fullpage=true <p> The above list is not comprehensive. The Compatibility Test Suite (CTS) tests significant portions of the platform for behavioral compatibility, but not all. It is the responsibility of the implementer to ensure behavioral compatibility with the Android Open Source Project. For this reason, device implementers SHOULD use the source code available via the Android Open Source Project where possible, rather than re-implement significant parts of the system. </p> - <h2 id="3_6_api_namespaces"> + <h3 id="3_6_api_namespaces"> 3.6. API Namespaces - </h2> + </h3> <p> Android follows the package and class namespace conventions defined by the Java programming language. To ensure compatibility with third-party applications, device implementers MUST NOT make any prohibited modifications (see below) to these package namespaces: </p> @@ -1033,9 +1033,9 @@ fullpage=true <p> Note that the restrictions above correspond to standard conventions for naming APIs in the Java programming language; this section simply aims to reinforce those conventions and make them binding through inclusion in this Compatibility Definition. </p> - <h2 id="3_7_runtime_compatibility"> + <h3 id="3_7_runtime_compatibility"> 3.7. Runtime Compatibility - </h2> + </h3> <p> Device implementations MUST support the full Dalvik Executable (DEX) format and <a href="https://android.googlesource.com/platform/dalvik/">Dalvik bytecode specification and semantics</a> . Device implementers SHOULD use ART, the reference upstream implementation of the Dalvik Executable Format, and the reference implementation’s package management system. </p> @@ -1421,9 +1421,9 @@ fullpage=true </td> </tr> </table> - <h2 id="3_8_user_interface_compatibility"> + <h3 id="3_8_user_interface_compatibility"> 3.8. User Interface Compatibility - </h2> + </h3> <h4 id="3_8_1_launcher_(home_screen)"> 3.8.1. Launcher (Home Screen) </h4> @@ -1511,7 +1511,7 @@ fullpage=true </li> <li>MUST display <a href="https://developer.android.com/reference/android/app/NotificationManager.html#addAutomaticZenRule%28android.app.AutomaticZenRule%29">Automatic DND rules</a> created by applications alongside the user-created and pre-defined rules. </li> - <li>MUST honor the <a href="https://developer.android.com/reference/android/app/NotificationManager.Policy.html#suppressedVisualEffects"><code>suppressedVisualEffects</code></a> values passed along the <a href="https://developer.android.com/reference/android/app/NotificationManager.Policy.html#NotificationManager.Policy%28int,%20int,%20int,%20int%29"><code>NotificationManager.Policy</code></a> . + <li>MUST honor the <a href="https://developer.android.com/reference/android/app/NotificationManager.Policy.html#suppressedVisualEffects"><code>suppressedVisualEffects</code></a> values passed along the <a href="https://developer.android.com/reference/android/app/NotificationManager.Policy.html#NotificationManager.Policy%28int,%20int,%20int,%20int%29"><code>NotificationManager.Policy</code></a> and if an app has set any of the SUPPRESSED_EFFECT_SCREEN_OFF or SUPPRESSED_EFFECT_SCREEN_ON flags, it SHOULD indicate to the user that the visual effects are suppressed in the DND settings menu. </li> </ul> <h4 id="3_8_4_search"> @@ -1598,7 +1598,7 @@ fullpage=true <ul> <li>MUST support at least up to 20 displayed activities. </li> - <li>MUST at least display the title of 4 activities at a time. + <li>SHOULD display the titles of at least 4 activities at a time. </li> <li>MUST implement the <a href="http://developer.android.com/about/versions/android-5.0.html#ScreenPinning">screen pinning behavior</a> and provide the user with a settings menu to toggle the feature. </li> @@ -1673,9 +1673,9 @@ fullpage=true <li>If the PIP multi-window mode is supported the <a href="https://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_WINDOW"><code>KeyEvent.KEYCODE_WINDOW</code></a> key MUST be used to control the PIP window; otherwise, the key MUST be available to the foreground activity. </li> </ul> - <h2 id="3_9_device_administration"> + <h3 id="3_9_device_administration"> 3.9. Device Administration - </h2> + </h3> <p> Android includes features that allow security-aware applications to perform device administration functions at the system level, such as enforcing password policies or performing remote wipe, through the <a href="http://developer.android.com/guide/topics/admin/device-admin.html">Android Device Administration API</a> ]. Device implementations MUST provide an implementation of the <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html">DevicePolicyManager</a> class. Device implementations that supports a secure lock screen MUST implement the full range of <a href="http://developer.android.com/guide/topics/admin/device-admin.html">device administration</a> policies defined in the Android SDK documentation and report the platform feature android.software.device_admin. </p> @@ -1686,12 +1686,12 @@ fullpage=true 3.9.1.1 Device owner provisioning </h5> <p> - If a device implementation declares the <code>android.software.device_admin</code> feature then it MUST implement the provisioning of the <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp%28java.lang.String%29">Device Owner app</a> of a Device Policy Client (DPC) application as indicated below: + If a device implementation declares the <code>android.software.device_admin</code> feature then it MUST implement the provisioning of the <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)">Device Owner app</a> of a Device Policy Client (DPC) application as indicated below: </p> <ul> <li>When the device implementation has no user data configured yet, it: <ul> - <li>MUST report <code>true</code> for <a href="https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isProvisioningAllowed%28java.lang.String%29"><code>DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE)</code></a> . + <li>MUST report <code>true</code> for <a href="https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isProvisioningAllowed(java.lang.String)"><code>DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE)</code></a> . </li> <li>MUST enroll the DPC application as the Device Owner app in response to the intent action <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_DEVICE"><code>android.app.action.PROVISION_MANAGED_DEVICE</code></a> . </li> @@ -1701,7 +1701,7 @@ fullpage=true </li> <li>When the device implementation has user data, it: <ul> - <li>MUST report <code>false</code> for the <a href="https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isProvisioningAllowed%28java.lang.String%29"><code>DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE)</code></a> . + <li>MUST report <code>false</code> for the <a href="https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isProvisioningAllowed(java.lang.String)"><code>DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE)</code></a> . </li> <li>MUST not enroll any DPC application as the Device Owner App any more. </li> @@ -1715,7 +1715,7 @@ fullpage=true 3.9.1.2 Managed profile provisioning </h5> <p> - If a device implementation declares the android.software.managed_users, it MUST be possible to enroll a Device Policy Controller (DPC) application as the <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isProfileOwnerApp%28java.lang.String%29">owner of a new Managed Profile</a> . + If a device implementation declares the android.software.managed_users, it MUST be possible to enroll a Device Policy Controller (DPC) application as the <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isProfileOwnerApp(java.lang.String)">owner of a new Managed Profile</a> . </p> <p> The managed profile provisioning process (the flow initiated by <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_PROFILE">android.app.action.PROVISION_MANAGED_PROFILE</a> ) user experience MUST align with the AOSP implementation. @@ -1726,14 +1726,14 @@ fullpage=true <ul> <li>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. </li> - <li>A short explanation message, as provided by the Device Admin via the [ <code>setShortSupportMessage</code> ](https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setShortSupportMessage(android.content.ComponentName, java.lang.CharSequence). + <li>A short explanation message, as provided by the Device Admin via the <a href="https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setShortSupportMessage%28android.content.ComponentName,%20java.lang.CharSequence%29"><code>setShortSupportMessage</code></a> . </li> <li>The DPC application’s icon. </li> </ul> - <h2 id="3_9_2_managed_profile_support"> + <h3 id="3_9_2_managed_profile_support"> 3.9.2 Managed Profile Support - </h2> + </h3> <p> Managed profile capable devices are those devices that: </p> @@ -1785,14 +1785,14 @@ fullpage=true </li> <li>The lock screen credentials of the managed profile MUST use the same credential storage and management mechanisms as the parent profile, as documented on the <a href="http://source.android.com/security/authentication/index.html">Android Open Source Project Site</a> </li> - <li>The DPC <a href="https://developer.android.com/guide/topics/admin/device-admin.html#pwd">password policies</a> MUST apply to only the managed profile's lock screen credentials unless called upon the <code>DevicePolicyManager</code> instance returned by <a href="https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#getParentProfileInstance(android.content.ComponentName)">getParentProfileInstance</a> .. + <li>The DPC <a href="https://developer.android.com/guide/topics/admin/device-admin.html#pwd">password policies</a> MUST apply to only the managed profile's lock screen credentials unless called upon the <code>DevicePolicyManager</code> instance returned by <a href="https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#getParentProfileInstance%28android.content.ComponentName%29">getParentProfileInstance</a> . </li> </ul> </li> </ul> - <h2 id="3_10_accessibility"> + <h3 id="3_10_accessibility"> 3.10. Accessibility - </h2> + </h3> <p> Android provides an accessibility layer that helps users with disabilities to navigate their devices more easily. In addition, Android provides platform APIs that enable <a href="http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html">accessibility service implementations</a> to receive callbacks for user and system events and generate alternate feedback mechanisms, such as text-to-speech, haptic feedback, and trackball/d-pad navigation. </p> @@ -1829,9 +1829,9 @@ fullpage=true <p> Also, note that if there is a preloaded accessibility service, it MUST be a Direct Boot aware {directBootAware} app if the device has encrypted storage using File Based Encryption (FBE). </p> - <h2 id="3_11_text-to-speech"> + <h3 id="3_11_text-to-speech"> 3.11. Text-to-Speech - </h2> + </h3> <p> Android includes APIs that allow applications to make use of text-to-speech (TTS) services and allows service providers to provide implementations of TTS services. Device implementations reporting the feature android.hardware.audio.output MUST meet these requirements related to the <a href="http://developer.android.com/reference/android/speech/tts/package-summary.html">Android TTS framework</a> . </p> @@ -1855,9 +1855,9 @@ fullpage=true <li>MUST provide a user-accessible interface that allows users to select a TTS engine for use at the system level. </li> </ul> - <h2 id="3_12_tv_input_framework"> + <h3 id="3_12_tv_input_framework"> 3.12. TV Input Framework - </h2> + </h3> <p> The <a href="http://source.android.com/devices/tv/index.html">Android Television Input Framework (TIF)</a> simplifies the delivery of live content to Android Television devices. TIF provides a standard API to create input modules that control Android Television devices. Android Television device implementations MUST support TV Input Framework. </p> @@ -1934,9 +1934,9 @@ fullpage=true <p> Android Television device implementations are STRONGLY RECOMMENDED to support TV recording. If the TV input supports recording, the EPG MAY provide a way to <a href="https://developer.android.com/reference/android/media/tv/TvInputInfo.html#canRecord%28%29">record a program</a> if the recording of such a program is not <a href="https://developer.android.com/reference/android/media/tv/TvContract.Programs.html#COLUMN_RECORDING_PROHIBITED">prohibited</a> . Device implementations SHOULD provide a user interface to play recorded programs. </p> - <h2 id="3_13_quick_settings"> + <h3 id="3_13_quick_settings"> 3.13. Quick Settings - </h2> + </h3> <p> Android device implementations SHOULD include a Quick Settings UI component that allow quick access to frequently used or urgently needed actions. </p> @@ -1951,9 +1951,9 @@ fullpage=true <li>MUST display all the user-added tiles from third-party apps alongside the system-provided quick setting tiles. </li> </ul> - <h2 id="3_14_vehicle_ui_apis"> + <h3 id="3_14_vehicle_ui_apis"> 3.14. Vehicle UI APIs - </h2> + </h3> <h4 id="3_14_1__vehicle_media_ui"> 3.14.1. Vehicle Media UI </h4> @@ -1991,9 +1991,9 @@ fullpage=true <h2 id="5_multimedia_compatibility"> 5. Multimedia Compatibility </h2> - <h2 id="5_1_media_codecs"> + <h3 id="5_1_media_codecs"> 5.1. Media Codecs - </h2> + </h3> <p> Device implementations— </p> @@ -2592,9 +2592,9 @@ fullpage=true <p class="table_footnote"> 6 Applies only to Android Television device implementations. </p> - <h2 id="5_2_video_encoding"> + <h3 id="5_2_video_encoding"> 5.2. Video Encoding - </h2> + </h3> <div class="note"> Video codecs are optional for Android Watch device implementations. </div> @@ -2629,7 +2629,7 @@ fullpage=true 5.2.2. H-264 </h4> <p> - Android device implementations with H.264 codec support&emdash; + Android device implementations with H.264 codec support: </p> <ul> <li>MUST support Baseline Profile Level 3.<br /> @@ -2792,9 +2792,9 @@ fullpage=true <p class="table_footnote"> 1 When supported by hardware. </p> - <h2 id="5_3_video_decoding"> + <h3 id="5_3_video_decoding"> 5.3. Video Decoding - </h2> + </h3> <div class="note"> Video codecs are optional for Android Watch device implementations. </div> @@ -3035,7 +3035,7 @@ fullpage=true 4 Mbps </td> <td> - 10 Mbps + 5 Mbps </td> <td> 20 Mbps @@ -3243,9 +3243,9 @@ fullpage=true <p class="table_footnote"> 1 REQUIRED for Android Television device implementations with VP9 hardware decoding. </p> - <h2 id="5_4_audio_recording"> + <h3 id="5_4_audio_recording"> 5.4. Audio Recording - </h2> + </h3> <p> While some of the requirements outlined in this section are stated as SHOULD since Android 4.3, the Compatibility Definition for a future version is planned to change these to MUST. Existing and new Android devices are <strong>STRONGLY RECOMMENDED</strong> to meet these requirements that are stated as SHOULD, or they will not be able to attain Android compatibility when upgraded to the future version. </p> @@ -3326,9 +3326,9 @@ fullpage=true <li>STREAM_NOTIFICATION </li> </ul> - <h2 id="5_5_audio_playback"> + <h3 id="5_5_audio_playback"> 5.5. Audio Playback - </h2> + </h3> <p> Device implementations that declare android.hardware.audio.output MUST conform to the requirements in this section. </p> @@ -3380,9 +3380,9 @@ fullpage=true <p> Android Automotive device implementations SHOULD allow adjusting audio volume separately per each audio stream using the content type or usage as defined by <a href="" title="http://developer.android.com/reference/android/media/AudioAttributes.html">AudioAttributes</a> and car audio usage as publicly defined in <code>android.car.CarAudioManager</code> . </p> - <h2 id="5_6_audio_latency"> + <h3 id="5_6_audio_latency"> 5.6. Audio Latency - </h2> + </h3> <p> Audio latency is the time delay as an audio signal passes through a system. Many classes of applications rely on short latencies, to achieve real-time sound effects. </p> @@ -3451,9 +3451,9 @@ fullpage=true <li>minimize the cold input jitter </li> </ul> - <h2 id="5_7_network_protocols"> + <h3 id="5_7_network_protocols"> 5.7. Network Protocols - </h2> + </h3> <p> Devices MUST support the <a href="http://developer.android.com/guide/appendix/media-formats.html">media network protocols</a> for audio and video playback as specified in the Android SDK documentation. Specifically, devices MUST support the following media network protocols: </p> @@ -3655,15 +3655,15 @@ fullpage=true </td> </tr> </table> - <h2 id="5_8_secure_media"> + <h3 id="5_8_secure_media"> 5.8. Secure Media - </h2> + </h3> <p> Device implementations that support secure video output and are capable of supporting secure surfaces MUST declare support for Display.FLAG_SECURE. Device implementations that declare support for Display.FLAG_SECURE, if they support a wireless display protocol, MUST secure the link with a cryptographically strong mechanism such as HDCP 2.x or higher for Miracast wireless displays. Similarly if they support a wired external display, the device implementations MUST support HDCP 1.2 or higher. Android Television device implementations MUST support HDCP 2.2 for devices supporting 4K resolution and HDCP 1.4 or above for lower resolutions. The upstream Android open source implementation includes support for wireless (Miracast) and wired (HDMI) displays that satisfies this requirement. </p> - <h2 id="5_9_musical_instrument_digital_interface_(midi)"> + <h3 id="5_9_musical_instrument_digital_interface_(midi)"> 5.9. Musical Instrument Digital Interface (MIDI) - </h2> + </h3> <p> If a device implementation supports the inter-app MIDI software transport (virtual MIDI devices), and it supports MIDI over <em>all</em> of the following MIDI-capable hardware transports for which it provides generic non-MIDI connectivity, it is STRONGLY RECOMMENDED to report support for feature android.software.midi via the <a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">android.content.pm.PackageManager</a> class. </p> @@ -3681,9 +3681,9 @@ fullpage=true <p> 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. </p> - <h2 id="5_10_professional_audio"> + <h3 id="5_10_professional_audio"> 5.10. Professional Audio - </h2> + </h3> <p> If a device implementation meets <em>all</em> of the following requirements, it is STRONGLY RECOMMENDED to report support for feature android.hardware.audio.pro via the <a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">android.content.pm.PackageManager</a> class. </p> @@ -3749,9 +3749,9 @@ fullpage=true <li>Minimize touch latency variability under load (jitter). </li> </ul> - <h2 id="5_11_capture_for_unprocessed"> + <h3 id="5_11_capture_for_unprocessed"> 5.11. Capture for Unprocessed - </h2> + </h3> <p> Starting from Android 7.0, a new recording source has been added. It can be accessed using the <code>android.media.MediaRecorder.AudioSource.UNPROCESSED</code> audio source. In OpenSL ES, it can be accessed with the record preset <code>SL_ANDROID_RECORDING_PRESET_UNPROCESSED</code> . </p> @@ -3771,7 +3771,7 @@ fullpage=true </li> <li> <p> - 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. + The device MUST exhibit amplitude levels in the high frequency range: specifically from ±30 dB from 7000 Hz to 22 KHz compared to the mid-frequency range. </p> </li> <li> @@ -3812,9 +3812,9 @@ fullpage=true <h2 id="6_developer_tools_and_options_compatibility"> 6. Developer Tools and Options Compatibility </h2> - <h2 id="6_1_developer_tools"> + <h3 id="6_1_developer_tools"> 6.1. Developer Tools - </h2> + </h3> <p> Device implementations MUST support the Android Developer Tools provided in the Android SDK. Android compatible devices MUST be compatible with: </p> @@ -3840,7 +3840,7 @@ fullpage=true </ul> </li> <li> - <a href="http://developer.android.com/tools/help/monkey.html"><strong>Monkey</strong></a> . Device implementations MUST include the Monkey framework, and make it available for applications to use. + <a href="http://developer.android.com/tools/help/monkey.html"><strong>Monkey</strong></a> Device implementations MUST include the Monkey framework, and make it available for applications to use. </li> <li> <a href="http://developer.android.com/tools/help/systrace.html"><strong>SysTrace</strong></a> @@ -3854,9 +3854,9 @@ fullpage=true </ul> </li> </ul> - <h2 id="6_2_developer_options"> + <h3 id="6_2_developer_options"> 6.2. Developer Options - </h2> + </h3> <p> Android includes support for developers to configure application development-related settings. Device implementations MUST honor the <a href="http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS">android.settings.APPLICATION_DEVELOPMENT_SETTINGS</a> intent to show application development-related settings The upstream Android implementation hides the Developer Options menu by default and enables users to launch Developer Options after pressing seven (7) times on the <strong>Settings</strong> > <strong>About Device</strong> > <strong>Build Number</strong> menu item. Device implementations MUST provide a consistent experience for Developer Options. Specifically, device implementations MUST hide Developer Options by default and MUST provide a mechanism to enable Developer Options that is consistent with the upstream Android implementation. </p> @@ -3887,9 +3887,9 @@ fullpage=true <p> Device implementations MUST consistently report accurate hardware configuration information via the getSystemAvailableFeatures() and hasSystemFeature(String) methods on the <a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">android.content.pm.PackageManager</a> class for the same build fingerprint. </p> - <h2 id="7_1_display_and_graphics"> + <h3 id="7_1_display_and_graphics"> 7.1. Display and Graphics - </h2> + </h3> <p> Android includes facilities that automatically adjust application assets and UI layouts appropriately for the device to ensure that third-party applications run well on a <a href="http://developer.android.com/guide/practices/screens_support.html">variety of hardware configurations</a> . Devices MUST properly implement these APIs and behaviors, as detailed in this section. </p> @@ -4110,9 +4110,9 @@ fullpage=true <p> Android includes support for secondary display to enable media sharing capabilities and developer APIs for accessing external displays. If a device supports an external display either via a wired, wireless, or an embedded additional display connection then the device implementation MUST implement the <a href="http://developer.android.com/reference/android/hardware/display/DisplayManager.html">display manager API</a> as described in the Android SDK documentation. </p> - <h2 id="7_2_input_devices"> + <h3 id="7_2_input_devices"> 7.2. Input Devices - </h2> + </h3> <p> Devices MUST support a touchscreen or meet the requirements listed in 7.2.2 for non-touch navigation. </p> @@ -4234,7 +4234,7 @@ fullpage=true </li> </ul> <p> - Android includes support for a variety of touchscreens, touch pads, and fake touch input devices. <a href="http://source.android.com/devices/tech/input/touch-devices.html">Touchscreen based device implementations</a> are associated with a display such that the user has the impression of directly manipulating items on screen. Since the user is directly touching the screen, the system does not require any additional affordances to indicate the objects being manipulated. In contrast, a fake touch interface provides a user input system that approximates a subset of touchscreen capabilities. For example, a mouse or remote control that drives an on-screen cursor approximates touch, but requires the user to first point or focus then click. Numerous input devices like the mouse, trackpad, gyro-based air mouse, gyro-pointer, joystick, and multi-touch trackpad can support fake touch interactions. Android includes the feature constant android.hardware.faketouch, which corresponds to a high-fidelity non-touch (pointer-based) input device such as a mouse or trackpad that can adequately emulate touch-based input (including basic gesture support), and indicates that the device supports an emulated subset of touchscreen functionality. Device implementations that declare the fake touch feature MUST meet the fake touch requirements in <a href="#7_2_5_fake_touch_input">section 7.2.5</a> . + Android includes support for a variety of touchscreens, touch pads, and fake touch input devices. <a href="http://source.android.com/devices/tech/input/touch-devices.html">Touchscreen-based device implementations</a> are associated with a display such that the user has the impression of directly manipulating items on screen. Since the user is directly touching the screen, the system does not require any additional affordances to indicate the objects being manipulated. In contrast, a fake touch interface provides a user input system that approximates a subset of touchscreen capabilities. For example, a mouse or remote control that drives an on-screen cursor approximates touch, but requires the user to first point or focus then click. Numerous input devices like the mouse, trackpad, gyro-based air mouse, gyro-pointer, joystick, and multi-touch trackpad can support fake touch interactions. Android includes the feature constant android.hardware.faketouch, which corresponds to a high-fidelity non-touch (pointer-based) input device such as a mouse or trackpad that can adequately emulate touch-based input (including basic gesture support), and indicates that the device supports an emulated subset of touchscreen functionality. Device implementations that declare the fake touch feature MUST meet the fake touch requirements in <a href="#7_2_5_fake_touch_input">section 7.2.5</a> . </p> <p> Device implementations MUST report the correct feature corresponding to the type of input used. Device implementations that include a touchscreen (single-touch or better) MUST report the platform feature constant android.hardware.touchscreen. Device implementations that report the platform feature constant android.hardware.touchscreen MUST also report the platform feature constant android.hardware.faketouch. Device implementations that do not include a touchscreen (and rely on a pointer device only) MUST NOT report any touchscreen feature, and MUST report only android.hardware.faketouch if they meet the fake touch requirements in <a href="#7_2_5_fake_touch_input">section 7.2.5</a> . @@ -4511,9 +4511,9 @@ fullpage=true <strong>Navigation</strong> . All Android Television remotes MUST include <a href="http://developer.android.com/reference/android/view/KeyEvent.html">Back, Home, and Select buttons and support for D-pad events</a> . </li> </ul> - <h2 id="7_3_sensors"> + <h3 id="7_3_sensors"> 7.3. Sensors - </h2> + </h3> <p> Android includes APIs for accessing a variety of sensor types. Devices implementations generally MAY omit these sensors, as provided for in the following subsections. If a device includes a particular sensor type that has a corresponding API for third-party developers, the device implementation MUST implement that API as described in the Android SDK documentation and the Android Open Source documentation on <a href="http://source.android.com/devices/sensors/">sensors</a> . For example, device implementations: </p> @@ -4784,7 +4784,7 @@ fullpage=true </li> <li>SHOULD have a best-fit line non-linearity of ≤ 0.2%. </li> - <li>SHOULD have a noise density of ≤ 0.07 °/s/√Hz. + <li>SHOULD have a noise density of ≤ 0.007 °/s/√Hz. </li> </ul> </li> @@ -4924,7 +4924,7 @@ fullpage=true </li> <li>MUST have all identifiable fingerprint data encrypted and cryptographically authenticated such that they cannot be acquired, read or altered outside of the Trusted Execution Environment (TEE) as documented in the <a href="https://source.android.com/devices/tech/security/authentication/fingerprint-hal.html">implementation guidelines</a> on the Android Open Source Project site. </li> - <li>MUST prevent adding a fingerprint without first establishing a chain of trust by having the user confirm existing or add a new device credential (PIN/pattern/password) using the TEE as implemented in the Android Open Source project. + <li>MUST prevent adding a fingerprint without first establishing a chain of trust by having the user confirm existing or add a new device credential (PIN/pattern/password) that's secured by TEE; the Android Open Source Project implementation provides the mechanism in the framework to do so. </li> <li>MUST NOT enable 3rd-party applications to distinguish between individual fingerprints. </li> @@ -4965,9 +4965,9 @@ fullpage=true <p> Android Automotive implementations MUST provide vehicle speed defined as SENSOR_TYPE_CAR_SPEED. </p> - <h2 id="7_3_12_pose_sensor"> + <h3 id="7_3_12_pose_sensor"> 7.3.12. Pose Sensor - </h2> + </h3> <p> Device implementations MAY support pose sensor with 6 degrees of freedom. Android Handheld devices are RECOMMENDED to support this sensor. If a device implementation does support pose sensor with 6 degrees of freedom, it: </p> @@ -4977,9 +4977,9 @@ fullpage=true <li>MUST be more accurate than the rotation vector alone. </li> </ul> - <h2 id="7_4_data_connectivity"> + <h3 id="7_4_data_connectivity"> 7.4. Data Connectivity - </h2> + </h3> <h4 id="7_4_1_telephony"> 7.4.1. Telephony </h4> @@ -5302,9 +5302,9 @@ fullpage=true </p> </li> </ul> - <h2 id="7_5_cameras"> + <h3 id="7_5_cameras"> 7.5. Cameras - </h2> + </h3> <p> Device implementations SHOULD include a rear-facing camera and MAY include a front-facing camera. A rear-facing camera is a camera located on the side of the device opposite the display; that is, it images scenes on the far side of the device, like a traditional camera. A front-facing camera is a camera located on the same side of the device as the display; that is, a camera typically used to image the user, such as for video conferencing and similar applications. </p> @@ -5348,7 +5348,7 @@ fullpage=true <ul> <li>If the device implementation is capable of being rotated by user (such as automatically via an accelerometer or manually via user input), the camera preview MUST be mirrored horizontally relative to the device’s current orientation. </li> - <li>If the current application has explicitly requested that the Camera display be rotated via a call to the <a href="http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation%28int%29">android.hardware.Camera.setDisplayOrientation()</a> method, the camera preview MUST be mirrored horizontally relative to the orientation specified by the application. + <li>If the current application has explicitly requested that the Camera display be rotated via a call to the <a href="http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)">android.hardware.Camera.setDisplayOrientation()</a> method, the camera preview MUST be mirrored horizontally relative to the orientation specified by the application. </li> <li>Otherwise, the preview MUST be mirrored along the device’s default horizontal axis. </li> @@ -5423,9 +5423,9 @@ fullpage=true <p> Both front- and rear-facing cameras, if present, MUST be oriented so that the long dimension of the camera aligns with the screen’s long dimension. That is, when the device is held in the landscape orientation, cameras MUST capture images in the landscape orientation. This applies regardless of the device’s natural orientation; that is, it applies to landscape-primary devices as well as portrait-primary devices. </p> - <h2 id="7_6_memory_and_storage"> + <h3 id="7_6_memory_and_storage"> 7.6. Memory and Storage - </h2> + </h3> <h4 id="7_6_1_minimum_memory_and_storage"> 7.6.1. Minimum Memory and Storage </h4> @@ -5595,9 +5595,9 @@ fullpage=true <p> Device implementations such as a television, MAY enable adoption through USB 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. </p> - <h2 id="7_7_usb"> + <h3 id="7_7_usb"> 7.7. USB - </h2> + </h3> <p> Device implementations SHOULD support USB peripheral mode and SHOULD support USB host mode. </p> @@ -5669,9 +5669,9 @@ fullpage=true <li>SHOULD, if the Dual Role Port functionality is supported, implement the Try.* model that is most appropriate for the device form factor. For example a handheld device SHOULD implement the Try.SNK model. </li> </ul> - <h2 id="7_8_audio"> + <h3 id="7_8_audio"> 7.8. Audio - </h2> + </h3> <h4 id="7_8_1_microphone"> 7.8.1. Microphone </h4> @@ -5774,9 +5774,9 @@ fullpage=true <li>If <a href="http://developer.android.com/reference/android/media/AudioManager.html#PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND">PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND</a> is "true", then the speaker's mean response in 18.5 kHz - 20 kHz MUST be no lower than 40 dB below the response at 2 kHz. </li> </ul> - <h2 id="7_9_virtual_reality"> + <h3 id="7_9_virtual_reality"> 7.9. Virtual Reality - </h2> + </h3> <p> Android includes APIs and facilities to build "Virtual Reality" (VR) applications including high quality mobile VR experiences. Device implementations MUST properly implement these APIs and behaviors, as detailed in this section. </p> @@ -5797,7 +5797,7 @@ fullpage=true </li> <li>Device implementations MUST declare android.software.vr.mode feature. </li> - <li>Device implementations MUST provide an exclusive core to the foreground application and MUST support the Process.getExclusiveCores API to return the numbers of the cpu cores that are exclusive to the top foreground application. This core MUST not allow any other userspace processes to run on it (except device drivers used by the application), but MAY allow some kernel processes to run as necessary. + <li>Device implementations MAY provide an exclusive core to the foreground application and MAY support the <code>Process.getExclusiveCores</code> API to return the numbers of the CPU cores that are exclusive to the top foreground application. If exclusive core is supported, then the core MUST not allow any other userspace processes to run on it (except device drivers used by the application), but MAY allow some kernel processes to run as necessary. </li> <li>Device implementations MUST support sustained performance mode. </li> @@ -5842,9 +5842,9 @@ fullpage=true <p> Some minimum performance and power criteria are critical to the user experience and impact the baseline assumptions developers would have when developing an app. Android Watch devices SHOULD and other type of device implementations MUST meet the following criteria. </p> - <h2 id="8_1_user_experience_consistency"> + <h3 id="8_1_user_experience_consistency"> 8.1. User Experience Consistency - </h2> + </h3> <p> Device implementations MUST provide a smooth user interface by ensuring a consistent frame rate and response times for applications and games. Device implementations MUST meet the following requirements: </p> @@ -5859,9 +5859,9 @@ fullpage=true <strong>Task switching</strong> . When multiple applications have been launched, re-launching an already-running application after it has been launched MUST take less than 1 second. </li> </ul> - <h2 id="8_2_file_i/o_access_performance"> + <h3 id="8_2_file_i/o_access_performance"> 8.2. File I/O Access Performance - </h2> + </h3> <p> Device implementations MUST ensure internal storage file access performance consistency for read and write operations. </p> @@ -5879,18 +5879,18 @@ fullpage=true <strong>Random read</strong> . Device implementations MUST ensure a random read performance of at least 3.5MB/s for a 256MB file using 4KB write buffer. </li> </ul> - <h2 id="8_3_power-saving_modes"> + <h3 id="8_3_power-saving_modes"> 8.3. Power-Saving Modes - </h2> + </h3> <p> 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. </p> <p> 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. </p> - <h2 id="8_4_power_consumption_accounting"> + <h3 id="8_4_power_consumption_accounting"> 8.4. Power Consumption Accounting - </h2> + </h3> <p> A more accurate accounting and reporting of the power consumption provides the app developer both the incentives and the tools to optimize the power usage pattern of the application. Therefore, device implementations: </p> @@ -5912,9 +5912,9 @@ fullpage=true <li>MUST honor the <a href="http://developer.android.com/reference/android/content/Intent.html#ACTION_POWER_USAGE_SUMMARY">android.intent.action.POWER_USAGE_SUMMARY</a> intent and display a settings menu that shows this power usage. </li> </ul> - <h2 id="8_5_consistent_performance"> + <h3 id="8_5_consistent_performance"> 8.5. Consistent Performance - </h2> + </h3> <p> Performance can fluctuate dramatically for high-performance long-running apps, either because of the other apps running in the background or the CPU throttling due to temperature limits. Android includes programmatic interfaces so that when the device is capable, the top foreground application can request that the system optimize the allocation of the resources to address such fluctuations. </p> @@ -5939,9 +5939,9 @@ fullpage=true <p> Device implementations MUST implement a security model consistent with the Android platform security model as defined in <a href="http://developer.android.com/guide/topics/security/permissions.html">Security and Permissions reference document</a> in the APIs in the Android developer documentation. Device implementations MUST support installation of self-signed applications without requiring any additional permissions/certificates from any third parties/authorities. Specifically, compatible devices MUST support the security mechanisms described in the follow subsections. </p> - <h2 id="9_1_permissions"> + <h3 id="9_1_permissions"> 9.1. Permissions - </h2> + </h3> <p> Device implementations MUST support the <a href="http://developer.android.com/guide/topics/security/permissions.html">Android permissions model</a> as defined in the Android developer documentation. Specifically, implementations MUST enforce each permission defined as described in the SDK documentation; no permissions may be omitted, altered, or ignored. Implementations MAY add additional permissions, provided the new permission ID strings are not in the android.* namespace. </p> @@ -5965,21 +5965,21 @@ fullpage=true </ul> </li> </ul> - <h2 id="9_2_uid_and_process_isolation"> + <h3 id="9_2_uid_and_process_isolation"> 9.2. UID and Process Isolation - </h2> + </h3> <p> Device implementations MUST support the Android application sandbox model, in which each application runs as a unique Unixstyle UID and in a separate process. Device implementations MUST support running multiple applications as the same Linux user ID, provided that the applications are properly signed and constructed, as defined in the <a href="http://developer.android.com/guide/topics/security/permissions.html">Security and Permissions reference</a> . </p> - <h2 id="9_3_filesystem_permissions"> + <h3 id="9_3_filesystem_permissions"> 9.3. Filesystem Permissions - </h2> + </h3> <p> Device implementations MUST support the Android file access permissions model as defined in the <a href="http://developer.android.com/guide/topics/security/permissions.html">Security and Permissions reference</a> . </p> - <h2 id="9_4_alternate_execution_environments"> + <h3 id="9_4_alternate_execution_environments"> 9.4. Alternate Execution Environments - </h2> + </h3> <p> Device implementations MAY include runtime environments that execute applications using some other software or technology than the Dalvik Executable Format or native code. However, such alternate execution environments MUST NOT compromise the Android security model or the security of installed Android applications, as described in this section. </p> @@ -6013,9 +6013,9 @@ fullpage=true <p> When installing applications, alternate runtimes MUST obtain user consent for the Android permissions used by the application. If an application needs to make use of a device resource for which there is a corresponding Android permission (such as Camera, GPS, etc.), the alternate runtime MUST inform the user that the application will be able to access that resource. If the runtime environment does not record application capabilities in this manner, the runtime environment MUST list all permissions held by the runtime itself when installing any application using that runtime. </p> - <h2 id="9_5_multi-user_support"> + <h3 id="9_5_multi-user_support"> 9.5. Multi-User Support - </h2> + </h3> <div class="note"> This feature is optional for all device types. </div> @@ -6034,15 +6034,15 @@ fullpage=true <li>Each user instance on an Android device MUST have separate and isolated external storage directories. Device implementations MAY store multiple users' data on the same volume or filesystem. However, the device implementation MUST ensure that applications owned by and running on behalf a given user cannot list, read, or write to data owned by any other user. Note that removable media, such as SD card slots, can allow one user to access another’s data by means of a host PC. For this reason, device implementations that use removable media for the external storage APIs MUST encrypt the contents of the SD card if multiuser is enabled using a key stored only on non-removable media accessible only to the system. As this will make the media unreadable by a host PC, device implementations will be required to switch to MTP or a similar system to provide host PCs with access to the current user’s data. Accordingly, device implementations MAY but SHOULD NOT enable multi-user if they use <a href="http://developer.android.com/reference/android/os/Environment.html">removable media</a> for primary external storage. </li> </ul> - <h2 id="9_6_premium_sms_warning"> + <h3 id="9_6_premium_sms_warning"> 9.6. Premium SMS Warning - </h2> + </h3> <p> Android includes support for warning users of any outgoing <a href="http://en.wikipedia.org/wiki/Short_code">premium SMS message</a> . Premium SMS messages are text messages sent to a service registered with a carrier that may incur a charge to the user. Device implementations that declare support for android.hardware.telephony MUST warn users before sending a SMS message to numbers identified by regular expressions defined in /data/misc/sms/codes.xml file in the device. The upstream Android Open Source Project provides an implementation that satisfies this requirement. </p> - <h2 id="9_7_kernel_security_features"> + <h3 id="9_7_kernel_security_features"> 9.7. Kernel Security Features - </h2> + </h3> <p> The Android Sandbox includes features that use the Security-Enhanced Linux (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: </p> @@ -6079,14 +6079,14 @@ fullpage=true <p> 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 <a href="http://source.android.com/devices/tech/config/kernel.html#Seccomp-BPF-TSYNC">in the Kernel Configuration section of source.android.com</a> . </p> - <h2 id="9_8_privacy"> + <h3 id="9_8_privacy"> 9.8. Privacy - </h2> + </h3> <p> If the device implements functionality in the system that captures the contents displayed on the screen and/or records the audio stream played on the device, it MUST continuously notify the user whenever this functionality is enabled and actively capturing/recording. </p> <p> - 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, unless that VPN is enabled by the Device Policy Controller via the <a href="https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setAlwaysOnVpnPackage%28android.content.ComponentName,%20java.lang.String,%20boolean%29"><code>DevicePolicyManager.setAlwaysOnVpnPackage()</code></a> , in which case the user does not need to provide a separate consent, but MUST only be notified. + 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, unless that VPN is enabled by the Device Policy Controller via the <a href="https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setAlwaysOnVpnPackage(android.content.ComponentName,%20java.lang.String,%20boolean)"><code>DevicePolicyManager.setAlwaysOnVpnPackage()</code></a> , in which case the user does not need to provide a separate consent, but MUST only be notified. </p> <p> Device implementations MUST ship with an empty user-added Certificate Authority (CA) store, and MUST preinstall the same root certificates for the system-trusted CA store as <a href="https://source.android.com/security/overview/app-security.html#certificate-authorities">provided</a> in the upstream Android Open Source Project. @@ -6097,9 +6097,9 @@ fullpage=true <p> 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 access to the contents of the shared storage over the USB port. </p> - <h2 id="9_9_data_storage_encryption"> + <h3 id="9_9_data_storage_encryption"> 9.9. Data Storage Encryption - </h2> + </h3> <div class="note"> Optional for Android device implementations without a secure lock screen. </div> @@ -6158,9 +6158,9 @@ fullpage=true <p> Device implementations supporting <a href="http://source.android.com/devices/tech/security/encryption/index.html">full disk encryption</a> (FDE). MUST use AES with a key of 128-bits (or greater) and a mode designed for storage (for example, AES-XTS, AES-CBC-ESSIV). The encryption key MUST NOT be written to storage at any time without being encrypted. The user MUST be provided with the possibility to AES encrypt the encryption key, except when it is in active use, with the lock screen credentials stretched using a slow stretching algorithm (e.g. PBKDF2 or scrypt). If the user has not specified a lock screen credentials or has disabled use of the passcode for encryption, the system SHOULD use a default passcode to wrap the encryption key. If the device provides a hardware-backed keystore, the password stretching algorithm MUST be cryptographically bound to that keystore. The encryption key MUST NOT be sent off the device (even when wrapped with the user passcode and/or hardware bound key). The upstream Android Open Source project provides a preferred implementation of this feature based on the Linux kernel feature dm-crypt. </p> - <h2 id="9_10_device_integrity"> + <h3 id="9_10_device_integrity"> 9.10. Device Integrity - </h2> + </h3> <p> The following requirements ensures there is transparancy to the status of the device integrity. </p> @@ -6195,9 +6195,9 @@ fullpage=true <p> 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. </p> - <h2 id="9_11_keys_and_credentials"> + <h3 id="9_11_keys_and_credentials"> 9.11. Keys and Credentials - </h2> + </h3> <p> The <a href="https://developer.android.com/training/articles/keystore.html">Android Keystore System</a> allows app developers to store cryptographic keys in a container and use them in cryptographic operations through the <a href="https://developer.android.com/reference/android/security/KeyChain.html">KeyChain API</a> or the <a href="https://developer.android.com/reference/java/security/KeyStore.html">Keystore API</a> . </p> @@ -6260,13 +6260,13 @@ fullpage=true </li> <li>If the authentication method can not be treated as a secure lock screen, it: <ul> - <li>MUST return <code>false</code> for both the <a href="http://developer.android.com/reference/android/app/KeyguardManager.html#isKeyguardSecure()"><code>KeyguardManager.isKeyguardSecure()</code></a> and the <a href="https://developer.android.com/reference/android/app/KeyguardManager.html#isDeviceSecure%28%29"><code>KeyguardManager.isDeviceSecure()</code></a> methods. + <li>MUST return <code>false</code> for both the <a href="http://developer.android.com/reference/android/app/KeyguardManager.html#isKeyguardSecure%28%29"><code>KeyguardManager.isKeyguardSecure()</code></a> and the <a href="https://developer.android.com/reference/android/app/KeyguardManager.html#isDeviceSecure%28%29"><code>KeyguardManager.isDeviceSecure()</code></a> methods. </li> <li>MUST be disabled when the Device Policy Controller (DPC) application has set the password quality policy via the <a href="https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordQuality%28android.content.ComponentName,%20int%29"><code>DevicePolicyManager.setPasswordQuality()</code></a> method with a more restrictive quality constant than <code>PASSWORD_QUALITY_UNSPECIFIED</code> . </li> <li>MUST NOT reset the password expiration timers set by <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordExpirationTimeout%28android.content.ComponentName,%20long%29"><code>DevicePolicyManager.setPasswordExpirationTimeout()</code></a> . </li> - <li>MUST NOT authenticate access to keystores if the application has called <a href="https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired%28boolean%29"><code>KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true)</code></a> . + <li>MUST NOT authenticate access to keystores if the application has called <a href="https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired%28boolean%29"><code>KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true)</code></a> ). </li> </ul> </li> @@ -6279,9 +6279,9 @@ fullpage=true </ul> </li> </ul> - <h2 id="9_12_data_deletion"> + <h3 id="9_12_data_deletion"> 9.12. Data Deletion - </h2> + </h3> <p> 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 following: </p> @@ -6297,9 +6297,9 @@ fullpage=true <p> Devices MAY provide a fast data wipe that conducts a logical data erase. </p> - <h2 id="9_13_safe_boot_mode"> + <h3 id="9_13_safe_boot_mode"> 9.13. Safe Boot Mode - </h2> + </h3> <p> Android provides a mode enabling users to boot up into a mode where only preinstalled system apps are allowed to run and all third-party apps are disabled. This mode, known as "Safe Boot Mode", provides the user the capability to uninstall potentially harmful third-party apps. </p> @@ -6323,9 +6323,9 @@ fullpage=true </p> </li> </ul> - <h2 id="9_14_automotive_vehicle_system_isolation"> + <h3 id="9_14_automotive_vehicle_system_isolation"> 9.14. Automotive Vehicle System Isolation - </h2> + </h3> <p> Android Automotive devices are expected to exchange data with critical vehicle subsystems, e.g., by using the <a href="http://source.android.com/devices/automotive.html">vehicle HAL</a> 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: </p> @@ -6344,18 +6344,18 @@ fullpage=true <p> However, note that no software test package is fully comprehensive. For this reason, device implementers are <strong>STRONGLY RECOMMENDED</strong> to make the minimum number of changes as possible to the reference and preferred implementation of Android available from the Android Open Source Project. This will minimize the risk of introducing bugs that create incompatibilities requiring rework and potential device updates. </p> - <h2 id="10_1_compatibility_test_suite"> + <h3 id="10_1_compatibility_test_suite"> 10.1. Compatibility Test Suite - </h2> + </h3> <p> Device implementations MUST pass the <a href="http://source.android.com/compatibility/index.html">Android Compatibility Test Suite (CTS)</a> available from the Android Open Source Project, using the final shipping software on the device. Additionally, device implementers SHOULD use the reference implementation in the Android Open Source tree as much as possible, and MUST ensure compatibility in cases of ambiguity in CTS and for any reimplementations of parts of the reference source code. </p> <p> The CTS is designed to be run on an actual device. Like any software, the CTS may itself contain bugs. The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the CTS may be released for Android 7.1. Device implementations MUST pass the latest CTS version available at the time the device software is completed. </p> - <h2 id="10_2_cts_verifier"> + <h3 id="10_2_cts_verifier"> 10.2. CTS Verifier - </h2> + </h3> <p> Device implementations MUST correctly execute all applicable cases in the CTS Verifier. The CTS Verifier is included with the Compatibility Test Suite, and is intended to be run by a human operator to test functionality that cannot be tested by an automated system, such as correct functioning of a camera and sensors. </p> @@ -6455,9 +6455,9 @@ fullpage=true <a href="https://android.googlesource.com/platform/compatibility/cdd/+log/nougat-mr1-dev/13_contact-us?pretty=full&no-merges">Contact Us</a> </li> </ol> - <h2 id="12_1_changelog_viewing_tips"> + <h3 id="12_1_changelog_viewing_tips"> 12.1. Changelog Viewing Tips - </h2> + </h3> <p> Changes are marked as follows: </p> @@ -6484,6 +6484,3 @@ fullpage=true <p> You can join the <a href="https://groups.google.com/forum/#!forum/android-compatibility">android-compatibility forum</a> and ask for clarifications or bring up any issues that you think the document does not cover. </p> - </div> - </body> -</html> |