| <!DOCTYPE html> |
| <head> |
| <title>Android 6.0 Compatibility Definition</title> |
| <link rel="stylesheet" type="text/css" href="source/android-cdd.css"/> |
| </head> |
| |
| <body> |
| <p class="toc_h1">Android 6.0 Compatibility Definition</p> |
| <hr/> |
| |
| <h6>Table of Contents</h6> |
| |
| <div id="toc"> |
| |
| <div id="toc_left"> |
| |
| <p class="toc_h1"><a href="#1_introduction">1. Introduction</a></p> |
| |
| <p class="toc_h1"><a href="#2_device_types">2. Device Types</a></p> |
| |
| <p class="toc_h2"><a href="#2_1_device_configurations">2.1 Device Configurations</a></p> |
| |
| <p class="toc_h1"><a href="#3_software">3. Software</a></p> |
| |
| <p class="toc_h2"><a href="#3_1_managed_api_compatibility">3.1. Managed API Compatibility</a></p> |
| |
| <p class="toc_h2"><a href="#3_2_soft_api_compatibility">3.2. Soft API Compatibility</a></p> |
| |
| <p class="toc_h3"><a href="#3_2_1_permissions">3.2.1. Permissions</a></p> |
| |
| <p class="toc_h3"><a href="#3_2_2_build_parameters">3.2.2. Build Parameters</a></p> |
| |
| <p class="toc_h3"><a href="#3_2_3_intent_compatibility">3.2.3. Intent Compatibility</a></p> |
| |
| <p class="toc_h4"><a href="#3_2_3_1_core_application_intents">3.2.3.1. Core Application Intents</a></p> |
| |
| <p class="toc_h4"><a href="#3_2_3_2_intent_resolution">3.2.3.2. Intent Resolution</a></p> |
| |
| <p class="toc_h4"><a href="#3_2_3_3_intent_namespaces">3.2.3.3. Intent Namespaces</a></p> |
| |
| <p class="toc_h4"><a href="#3_2_3_4_broadcast_intents">3.2.3.4. Broadcast Intents</a></p> |
| |
| <p class="toc_h4"><a href="#3_2_3_5_default_app_settings">3.2.3.5. Default App Settings</a></p> |
| |
| <p class="toc_h2"><a href="#3_3_native_api_compatibility">3.3. Native API Compatibility</a></p> |
| |
| <p class="toc_h3"><a href="#3_3_1_application_binary_interfaces">3.3.1. Application Binary Interfaces</a></p> |
| |
| <p class="toc_h3"><a href="#3_3_2_32-bit_arm_native_code_compatibility">3.3.2. 32-bit ARM Native Code Compatibility</a></p> |
| |
| <p class="toc_h2"><a href="#3_4_web_compatibility">3.4. Web Compatibility</a></p> |
| |
| <p class="toc_h3"><a href="#3_4_1_webview_compatibility">3.4.1. WebView Compatibility</a></p> |
| |
| <p class="toc_h3"><a href="#3_4_2_browser_compatibility">3.4.2. Browser Compatibility</a></p> |
| |
| <p class="toc_h2"><a href="#3_5_api_behavioral_compatibility">3.5. API Behavioral Compatibility</a></p> |
| |
| <p class="toc_h2"><a href="#3_6_api_namespaces">3.6. API Namespaces</a></p> |
| |
| <p class="toc_h2"><a href="#3_7_runtime_compatibility">3.7. Runtime Compatibility</a></p> |
| |
| <p class="toc_h2"><a href="#3_8_user_interface_compatibility">3.8. User Interface Compatibility</a></p> |
| |
| <p class="toc_h3"><a href="#3_8_1_launcher_home_screen">3.8.1. Launcher (Home Screen)</a></p> |
| |
| <p class="toc_h3"><a href="#3_8_2_widgets">3.8.2. Widgets</a></p> |
| |
| <p class="toc_h3"><a href="#3_8_3_notifications">3.8.3. Notifications</a></p> |
| |
| <p class="toc_h3"><a href="#3_8_4_search">3.8.4. Search</a></p> |
| |
| <p class="toc_h3"><a href="#3_8_5_toasts">3.8.5. Toasts</a></p> |
| |
| <p class="toc_h3"><a href="#3_8_6_themes">3.8.6. Themes</a></p> |
| |
| <p class="toc_h3"><a href="#3_8_7_live_wallpapers">3.8.7. Live Wallpapers</a></p> |
| |
| <p class="toc_h3"><a href="#3_8_8_activity_switching">3.8.8. Activity Switching</a></p> |
| |
| <p class="toc_h3"><a href="#3_8_9_input_management">3.8.9. Input Management</a></p> |
| |
| <p class="toc_h3"><a href="#3_8_10_lock_screen_media_control">3.8.10. Lock Screen Media Control</a></p> |
| |
| <p class="toc_h3"><a href="#3_8_11_dreams">3.8.11. Dreams</a></p> |
| |
| <p class="toc_h3"><a href="#3_8_12_location">3.8.12. Location</a></p> |
| |
| </div> |
| |
| <div id="toc_right"> |
| |
| |
| <p class="toc_h3"><a href="#3_8_13_unicode_and_font">3.8.13. Unicode and Font</a></p> |
| |
| <p class="toc_h2"><a href="#3_9_device_administration">3.9. Device Administration</a></p> |
| |
| <p class="toc_h3"><a href="#3_9_1_device_provisioning">3.9.1 Device Provisioning</a></p> |
| |
| <p class="toc_h4"><a href="#3_9_1_2_device_owner_provisioning">3.9.1.1 Device Owner provisioning</a></p> |
| |
| <p class="toc_h4"><a href="#3_9_1_2_managed_profile_provisioning">3.9.1.2 Managed profile provisioning</a></p> |
| |
| <p class="toc_h3"><a href="#3_9_2_managed_profile_support">3.9.2. Managed Profile Support</a></p> |
| |
| |
| <p class="toc_h2"><a href="#3_10_accessibility">3.10. Accessibility</a></p> |
| |
| <p class="toc_h2"><a href="#3_11_text-to-speech">3.11. Text-to-Speech</a></p> |
| |
| <p class="toc_h2"><a href="#3_12_tv_input_framework">3.12. TV Input Framework</a></p> |
| |
| <p class="toc_h3"><a href="#3_12_1_tv_app">3.12.1. TV App</a></p> |
| |
| <p class="toc_h4"><a href="#3_12_1_1_electronic_program_guide">3.12.1.1. Electronic Program Guide</a></p> |
| |
| <p class="toc_h4"><a href="#3_12_1_2_navigation">3.12.1.2. Navigation</a></p> |
| |
| <p class="toc_h4"><a href="#3_12_1_3_tv_input_app_linking">3.12.1.3. TV input app linking</a></p> |
| |
| <p class="toc_h1"><a href="#4_application_packaging_compatibility">4. Application Packaging Compatibility</a></p> |
| |
| <p class="toc_h1"><a href="#5_multimedia_compatibility">5. Multimedia Compatibility</a></p> |
| |
| <p class="toc_h2"><a href="#5_1_media_codecs">5.1. Media Codecs</a></p> |
| |
| <p class="toc_h3"><a href="#5_1_1_audio_codecs">5.1.1. Audio Codecs</a></p> |
| |
| <p class="toc_h3"><a href="#5_1_2_image_codecs">5.1.2. Image Codecs</a></p> |
| |
| <p class="toc_h3"><a href="#5_1_3_video_codecs">5.1.3. Video Codecs</a></p> |
| |
| <p class="toc_h2"><a href="#5_2_video_encoding">5.2. Video Encoding</a></p> |
| |
| <p class="toc_h2"><a href="#5_3_video_decoding">5.3. Video Decoding</a></p> |
| |
| <p class="toc_h2"><a href="#5_4_audio_recording">5.4. Audio Recording</a></p> |
| |
| <p class="toc_h3"><a href="#5_4_1_raw_audio_capture">5.4.1. Raw Audio Capture</a></p> |
| |
| <p class="toc_h3"><a href="#5_4_2_capture_for_voice_recognition">5.4.2. Capture for Voice Recognition</a></p> |
| |
| <p class="toc_h3"><a href="#5_4_3_capture_for_rerouting_of_playback">5.4.3. Capture for Rerouting of Playback</a></p> |
| |
| <p class="toc_h2"><a href="#5_5_audio_playback">5.5. Audio Playback</a></p> |
| |
| <p class="toc_h3"><a href="#5_5_1_raw_audio_playback">5.5.1. Raw Audio Playback</a></p> |
| |
| <p class="toc_h3"><a href="#5_5_2_audio_effects">5.5.2. Audio Effects</a></p> |
| |
| <p class="toc_h3"><a href="#5_5_3_audio_output_volume">5.5.3. Audio Output Volume</a></p> |
| |
| <p class="toc_h2"><a href="#5_6_audio_latency">5.6. Audio Latency</a></p> |
| |
| <p class="toc_h2"><a href="#5_7_network_protocols">5.7. Network Protocols</a></p> |
| |
| <p class="toc_h2"><a href="#5_8_secure_media">5.8. Secure Media</a></p> |
| |
| <p class="toc_h2"><a href="#5_9_midi">5.9. Musical Instrument Digital Interface (MIDI)</a></p> |
| |
| <p class="toc_h2"><a href="#5_10_pro_audio">5.10. Professional Audio</a></p> |
| |
| </div> |
| |
| <div style="clear: both; page-break-after:always; height:1px"></div> |
| |
| <div id="toc_left"> |
| |
| <p class="toc_h1"><a href="#6_developer_tools_and_options_compatibility">6. Developer Tools and Options Compatibility</a></p> |
| |
| <p class="toc_h2"><a href="#6_1_developer_tools">6.1. Developer Tools</a></p> |
| |
| <p class="toc_h2"><a href="#6_2_developer_options">6.2. Developer Options</a></p> |
| |
| <p class="toc_h1"><a href="#7_hardware_compatibility">7. Hardware Compatibility</a></p> |
| |
| <p class="toc_h2"><a href="#7_1_display_and_graphics">7.1. Display and Graphics</a></p> |
| |
| <p class="toc_h3"><a href="#7_1_1_screen_configuration">7.1.1. Screen Configuration</a></p> |
| |
| <p class="toc_h4"><a href="#7_1_1_1_screen_size">7.1.1.1. Screen Size</a></p> |
| |
| <p class="toc_h4"><a href="#7_1_1_2_screen_aspect_ratio">7.1.1.2. Screen Aspect Ratio</a></p> |
| |
| <p class="toc_h4"><a href="#7_1_1_3_screen_density">7.1.1.3. Screen Density</a></p> |
| |
| <p class="toc_h3"><a href="#7_1_2_display_metrics">7.1.2. Display Metrics</a></p> |
| |
| <p class="toc_h3"><a href="#7_1_3_screen_orientation">7.1.3. Screen Orientation</a></p> |
| |
| <p class="toc_h3"><a href="#7_1_4_2d_and_3d_graphics_acceleration">7.1.4. 2D and 3D Graphics Acceleration</a></p> |
| |
| <p class="toc_h3"><a href="#7_1_5_legacy_application_compatibility_mode">7.1.5. Legacy Application Compatibility Mode</a></p> |
| |
| <p class="toc_h3"><a href="#7_1_6_screen_technology">7.1.6. Screen Technology</a></p> |
| |
| <p class="toc_h3"><a href="#7_1_7_external_displays">7.1.7. Secondary Displays</a></p> |
| |
| <p class="toc_h2"><a href="#7_2_input_devices">7.2. Input Devices</a></p> |
| |
| <p class="toc_h3"><a href="#7_2_1_keyboard">7.2.1. Keyboard</a></p> |
| |
| <p class="toc_h3"><a href="#7_2_2_non-touch_navigation">7.2.2. Non-touch Navigation</a></p> |
| |
| <p class="toc_h3"><a href="#7_2_3_navigation_keys">7.2.3. Navigation Keys</a></p> |
| |
| <p class="toc_h3"><a href="#7_2_4_touchscreen_input">7.2.4. Touchscreen Input</a></p> |
| |
| <p class="toc_h3"><a href="#7_2_5_fake_touch_input">7.2.5. Fake Touch Input</a></p> |
| |
| <p class="toc_h3"><a href="#7_2_6_game_controller_support">7.2.6. Game Controller Support</a></p> |
| |
| <p class="toc_h4"><a href="#7_2_6_1_button_mapping">7.2.6.1. Button Mappings</a></p> |
| |
| <p class="toc_h3"><a href="#7_2_7_remote_control">7.2.7. Remote Control</a></p> |
| |
| <p class="toc_h2"><a href="#7_3_sensors">7.3. Sensors</a></p> |
| |
| <p class="toc_h3"><a href="#7_3_1_accelerometer">7.3.1. Accelerometer</a></p> |
| |
| <p class="toc_h3"><a href="#7_3_2_magnetometer">7.3.2. Magnetometer</a></p> |
| |
| <p class="toc_h3"><a href="#7_3_3_gps">7.3.3. GPS</a></p> |
| |
| </div> |
| |
| <div id="toc_right"> |
| |
| <p class="toc_h3"><a href="#7_3_4_gyroscope">7.3.4. Gyroscope</a></p> |
| |
| <p class="toc_h3"><a href="#7_3_5_barometer">7.3.5. Barometer</a></p> |
| |
| <p class="toc_h3"><a href="#7_3_6_thermometer">7.3.6. Thermometer</a></p> |
| |
| <p class="toc_h3"><a href="#7_3_7_photometer">7.3.7. Photometer</a></p> |
| |
| <p class="toc_h3"><a href="#7_3_8_proximity_sensor">7.3.8. Proximity Sensor</a></p> |
| |
| <p class="toc_h3"><a href="#7_3_9_hifi_sensors">7.3.9. High Fidelity Sensors</a></p> |
| |
| <p class="toc_h3"><a href="#7_3_10_fingerprint">7.3.10. Fingerprint Sensor</a></p> |
| |
| <p class="toc_h2"><a href="#7_4_data_connectivity">7.4. Data Connectivity</a></p> |
| |
| <p class="toc_h3"><a href="#7_4_1_telephony">7.4.1. Telephony</a></p> |
| |
| <p class="toc_h3"><a href="#7_4_2_ieee_80211_wi-fi">7.4.2. IEEE 802.11 (Wi-Fi)</a></p> |
| |
| <p class="toc_h4"><a href="#7_4_2_1_wi-fi_direct">7.4.2.1. Wi-Fi Direct</a></p> |
| |
| <p class="toc_h4"><a href="#7_4_2_2_wi-fi-tunneled-direct-link-setup">7.4.2.2. Wi-Fi Tunneled Direct Link Setup</a></p> |
| |
| <p class="toc_h3"><a href="#7_4_3_bluetooth">7.4.3. Bluetooth</a></p> |
| |
| <p class="toc_h3"><a href="#7_4_4_near-field_communications">7.4.4. Near-Field Communications</a></p> |
| |
| <p class="toc_h3"><a href="#7_4_5_minimum_network_capability">7.4.5. Minimum Network Capability</a></p> |
| |
| <p class="toc_h3"><a href="#7_4_6_sync_settings">7.4.6. Sync Settings</a></p> |
| |
| <p class="toc_h2"><a href="#7_5_cameras">7.5. Cameras</a></p> |
| |
| <p class="toc_h3"><a href="#7_5_1_rear-facing_camera">7.5.1. Rear-Facing Camera</a></p> |
| |
| <p class="toc_h3"><a href="#7_5_2_front-facing_camera">7.5.2. Front-Facing Camera</a></p> |
| |
| <p class="toc_h3"><a href="#7_5_3_external_camera">7.5.3. External Camera</a></p> |
| |
| <p class="toc_h3"><a href="#7_5_4_camera_api_behavior">7.5.4. Camera API Behavior</a></p> |
| |
| <p class="toc_h3"><a href="#7_5_5_camera_orientation">7.5.5. Camera Orientation</a></p> |
| |
| <p class="toc_h2"><a href="#7_6_memory_and_storage">7.6. Memory and Storage</a></p> |
| |
| <p class="toc_h3"><a href="#7_6_1_minimum_memory_and_storage">7.6.1. Minimum Memory and Storage</a></p> |
| |
| <p class="toc_h3"><a href="#7_6_2_application_shared_storage">7.6.2. Application Shared Storage</a></p> |
| |
| <p class="toc_h3"><a href="#7_6_3_adoptable_storage">7.6.3. Adoptable Storage</a></p> |
| |
| <p class="toc_h2"><a href="#7_7_usb">7.7. USB</a></p> |
| |
| <p class="toc_h2"><a href="#7_8_audio">7.8. Audio</a></p> |
| |
| <p class="toc_h3"><a href="#7_8_1_microphone">7.8.1. Microphone</a></p> |
| |
| <p class="toc_h3"><a href="#7_8_2_audio_output">7.8.2. Audio Output</a></p> |
| |
| <p class="toc_h4"><a href="#7_8_2_1_analog_audio_ports">7.8.2.1. Analog Audio Ports</a></p> |
| |
| <p class="toc_h3"><a href="#7_8_3_near_ultrasound">7.8.3. Near-Ultrasound</a></p> |
| |
| <p class="toc_h1"><a href="#8_performance_power">8. Performance and Power</a></p> |
| |
| <p class="toc_h2"><a href="#8_1_user_experience_consistency">8.1. User Experience Consistency</a></p> |
| |
| <p class="toc_h2"><a href="#8_2_file_i_o_access_performance">8.2. File I/O Access Performance</a></p> |
| |
| <p class="toc_h2"><a href="#8_3_power_saving_modes">8.3. Power-Saving Modes</a></p> |
| |
| <p class="toc_h2"><a href="#8_4_power_consumption_accounting">8.4. Power Consumption Accounting</a></p> |
| |
| </div> |
| |
| <div style="clear: both; page-break-after:always; height:1px"></div> |
| |
| <div id="toc_left"> |
| |
| <p class="toc_h1"><a href="#9_security_model_compatibility">9. Security Model Compatibility</a></p> |
| |
| <p class="toc_h2"><a href="#9_1_permissions">9.1. Permissions</a></p> |
| |
| <p class="toc_h2"><a href="#9_2_uid_and_process_isolation">9.2. UID and Process Isolation</a></p> |
| |
| <p class="toc_h2"><a href="#9_3_filesystem_permissions">9.3. Filesystem Permissions</a></p> |
| |
| <p class="toc_h2"><a href="#9_4_alternate_execution_environments">9.4. Alternate Execution Environments</a></p> |
| |
| <p class="toc_h2"><a href="#9_5_multi-user_support">9.5. Multi-User Support</a></p> |
| |
| <p class="toc_h2"><a href="#9_6_premium_sms_warning">9.6. Premium SMS Warning</a></p> |
| |
| <p class="toc_h2"><a href="#9_7_kernel_security_features">9.7. Kernel Security Features</a></p> |
| |
| <p class="toc_h2"><a href="#9_8_privacy">9.8. Privacy</a></p> |
| |
| <p class="toc_h2"><a href="#9_9_full-disk-encryption">9.9. Full-Disk Encryption</a></p> |
| |
| <p class="toc_h2"><a href="#9_10_verified_boot">9.10. Verified Boot</a></p> |
| |
| <p class="toc_h2"><a href="#9_11_keys_and_credentials">9.11. Keys and Credentials</a></p> |
| |
| <p class="toc_h2"><a href="#9_12_data_deletion">9.12. Data Deletion</a></p> |
| |
| <p class="toc_h1"><a href="#10_software_compatibility_testing">10. Software Compatibility Testing</a></p> |
| |
| <p class="toc_h2"><a href="#10_1_compatibility_test_suite">10.1. Compatibility Test Suite</a></p> |
| |
| <p class="toc_h2"><a href="#10_2_cts_verifier">10.2. CTS Verifier</a></p> |
| |
| <p class="toc_h1"><a href="#11_updatable_software">11. Updatable Software</a></p> |
| |
| <p class="toc_h1"><a href="#12_document_changelog">12. Document Changelog</a></p> |
| |
| <p class="toc_h1"><a href="#13_contact_us">13. Contact Us</a></p> |
| |
| </div> |
| |
| </div> |
| |
| <div style="clear: both"></div> |
| |
| <div id="main"> |
| |
| <h1 id="1_introduction">1. Introduction</h1> |
| |
| |
| <p>This document enumerates the requirements that must be met in order for |
| devices to be compatible with Android 6.0.</p> |
| |
| <p>The use of “MUST”, “MUST NOT”, |
| “REQUIRED”, “SHALL”, “SHALL NOT”, |
| “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, |
| “MAY”, and “OPTIONAL” is per the IETF standard |
| defined in <a href="http://www.ietf.org/rfc/rfc2119.txt">RFC2119</a>.</p> |
| |
| <p>As used in this document, a “device implementer” or |
| “implementer” is a person or organization developing a |
| hardware/software solution running Android 6.0. A “device |
| implementation” or “implementation is the hardware/software solution |
| so developed.</p> |
| |
| <p>To be considered compatible with Android 6.0, device |
| implementations MUST meet the requirements presented in this Compatibility |
| Definition, including any documents incorporated via reference.</p> |
| |
| <p>Where this definition or the software tests described in |
| <a href="#10_software_compatibility_testing">section 10</a> is silent, |
| ambiguous, or incomplete, it is the responsibility of the device |
| implementer to ensure compatibility with existing implementations.</p> |
| |
| <p>For this reason, the <a href="http://source.android.com/">Android Open Source |
| Project</a> is both the reference and preferred implementation of Android. |
| Device implementers are STRONGLY RECOMMENDED to base their implementations to |
| the greatest extent possible on the “upstream” source code available |
| from the Android Open Source Project. While some components can hypothetically |
| be replaced with alternate implementations, it is STRONGLY RECOMMENDED to not |
| follow this practice, as passing the software tests will become substantially |
| more difficult. It is the implementer’s responsibility to ensure full |
| behavioral compatibility with the standard Android implementation, including and |
| beyond the Compatibility Test Suite. Finally, note that certain component |
| substitutions and modifications are explicitly forbidden by this document.</p> |
| |
| <p>Many of the resources linked to in this document are derived directly or |
| indirectly from the Android SDK and will be functionally identical to the |
| information in that SDK’s documentation. In any cases where this |
| Compatibility Definition or the Compatibility Test Suite disagrees with the |
| SDK documentation, the SDK documentation is considered authoritative. Any |
| technical details provided in the linked resources throughout this document are |
| considered by inclusion to be part of this Compatibility Definition.</p> |
| |
| <h1 id="2_device_types">2. Device Types</h1> |
| |
| |
| <p>While the Android Open Source Project has been used in the implementation of |
| a variety of device types and form factors, many aspects of the architecture and |
| compatibility requirements were optimized for handheld devices. Starting from |
| Android 5.0, the Android Open Source Project aims to embrace a wider variety of |
| device types as described in this section.</p> |
| |
| <p><strong>Android Handheld device</strong> refers to an Android device |
| implementation that is typically used by holding it in the hand, such as mp3 |
| players, phones, and tablets. Android Handheld device implementations:</p> |
| |
| <ul> |
| <li>MUST have a touchscreen embedded in the device.</li> |
| <li>MUST have a power source that provides mobility, such as a battery.</li> |
| </ul> |
| |
| <p><strong>Android Television device</strong> refers to an Android device |
| implementation that is an entertainment interface for consuming digital media, |
| movies, games, apps, and/or live TV for users sitting about ten feet away (a |
| “lean back” or “10-foot user interface”). Android |
| Television devices:</p> |
| |
| <ul> |
| <li>MUST have an embedded screen OR include a video output port, such as VGA, |
| HDMI, or a wireless port for display.</li> |
| <li>MUST declare the features |
| <a href="http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK">android.software.leanback</a> |
| and android.hardware.type.television.</li> |
| </ul> |
| |
| <p><strong>Android Watch device</strong> refers to an Android device |
| implementation intended to be worn on the body, perhaps on the wrist, and:</p> |
| |
| <ul> |
| <li>MUST have a screen with the physical diagonal length in the range from |
| 1.1 to 2.5 inches.</li> |
| <li>MUST declare the feature android.hardware.type.watch.</li> |
| <li>MUST support uiMode = |
| <a href="http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH">UI_MODE_TYPE_WATCH</a>. |
| </li> |
| </ul> |
| |
| <p><strong>Android Automotive implementation</strong> refers to a vehicle head |
| unit running Android as an operating system for part or all of the system and/or |
| infotainment functionality. Android Automotive implementations:</p> |
| |
| <ul> |
| <li>MUST declare the feature android.hardware.type.automotive.</li> |
| <li>MUST support uiMode = |
| <a href="http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR">UI_MODE_TYPE_CAR</a>. |
| </li> |
| </ul> |
| |
| <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 |
| 6.0 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">2.1 Device Configurations</h2> |
| |
| |
| <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> |
| <table> |
| <tr> |
| <th>Category</th> |
| <th>Feature</th> |
| <th>Section</th> |
| <th>Handheld</th> |
| <th>Television</th> |
| <th>Watch</th> |
| <th>Automotive</th> |
| <th>Other</th> |
| </tr> |
| <tr> |
| <td rowspan="3">Input</td> |
| <td>D-pad</td> |
| <td><a href="#7_2_2_non-touch-navigation">7.2.2. Non-touch Navigation</a></td> |
| <td></td> |
| <td>MUST</td> |
| <td></td> |
| <td></td> |
| <td></td> |
| </tr> |
| <tr> |
| <td>Touchscreen </td> |
| <td><a href="#7_2_4_touchscreen_input">7.2.4. Touchscreen input</a></td> |
| <td>MUST</td> |
| <td></td> |
| <td>MUST</td> |
| <td></td> |
| <td>SHOULD</td> |
| </tr> |
| <tr> |
| <td>Microphone </td> |
| <td><a href="#7_8_1_microphone">7.8.1. Microphone</a></td> |
| <td>MUST</td> |
| <td>SHOULD </td> |
| <td>MUST</td> |
| <td>MUST</td> |
| <td>SHOULD</td> |
| </tr> |
| <tr> |
| <td rowspan="2">Sensors</td> |
| <td>Accelerometer </td> |
| <td><a href="#7_3_1_accelerometer">7.3.1 Accelerometer</a></td> |
| <td>SHOULD</td> |
| <td></td> |
| <td>SHOULD</td> |
| <td></td> |
| <td>SHOULD</td> |
| </tr> |
| <tr> |
| <td>GPS</td> |
| <td><a href="#7_3_3_gps">7.3.3. GPS</a></td> |
| <td>SHOULD</td> |
| <td></td> |
| <td></td> |
| <td>SHOULD</td> |
| <td></td> |
| </tr> |
| <tr> |
| <td rowspan="5">Connectivity</td> |
| <td>Wi-Fi</td> |
| <td><a href="#7_4_2_ieee_802.11">7.4.2. IEEE 802.11</a></td> |
| <td>SHOULD</td> |
| <td> MUST</td> |
| <td></td> |
| <td>SHOULD</td> |
| <td>SHOULD</td> |
| </tr> |
| <tr> |
| <td>Wi-Fi Direct</td> |
| <td><a href="#7_4_2_1_wi-fi-direct">7.4.2.1. Wi-Fi Direct</a></td> |
| <td>SHOULD</td> |
| <td>SHOULD</td> |
| <td></td> |
| <td></td> |
| <td>SHOULD</td> |
| </tr> |
| <tr> |
| <td>Bluetooth</td> |
| <td><a href="#7_4_3_bluetooth">7.4.3. Bluetooth</a></td> |
| <td>SHOULD</td> |
| <td>MUST</td> |
| <td>MUST</td> |
| <td>MUST</td> |
| <td>SHOULD</td> |
| </tr> |
| <tr> |
| <td>Bluetooth Low Energy</td> |
| <td><a href="#7_4_3_bluetooth">7.4.3. Bluetooth</a></td> |
| <td>SHOULD</td> |
| <td>MUST</td> |
| <td>SHOULD</td> |
| <td>SHOULD</td> |
| <td>SHOULD</td> |
| </tr> |
| <tr> |
| <td>USB peripheral/host mode</td> |
| <td><a href="#7_7_usb">7.7. USB</a></td> |
| <td>SHOULD</td> |
| <td></td> |
| <td></td> |
| <td>SHOULD</td> |
| <td>SHOULD</td> |
| </tr> |
| <tr> |
| <td>Output</td> |
| <td>Speaker and/or Audio output ports</td> |
| <td><a href="#7_8_2_audio_output">7.8.2. Audio Output</a></td> |
| <td>MUST</td> |
| <td>MUST</td> |
| <td></td> |
| <td>MUST</td> |
| <td>MUST</td> |
| </tr> |
| </table> |
| |
| |
| <h1 id="3_software">3. Software</h1> |
| |
| |
| <h2 id="3_1_managed_api_compatibility">3.1. Managed API Compatibility</h2> |
| |
| |
| <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> |
| |
| <p>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.</p> |
| |
| <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_2_soft_api_compatibility">3.2. Soft API Compatibility</h2> |
| |
| |
| <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> |
| |
| <h3 id="3_2_1_permissions">3.2.1. Permissions</h3> |
| |
| |
| <p>Device implementers MUST support and enforce all permission constants as |
| documented by the |
| <a href="http://developer.android.com/reference/android/Manifest.permission.html">Permission |
| reference page</a>. Note that <a href="#9_security_model_compatibility">section |
| 9</a> lists additional requirements related to the Android security model.</p> |
| |
| <h3 id="3_2_2_build_parameters">3.2.2. Build Parameters</h3> |
| |
| |
| <p>The Android APIs include a number of constants on the |
| <a href="http://developer.android.com/reference/android/os/Build.html">android.os.Build |
| class</a> that are intended to describe the current device. To provide |
| consistent, meaningful values across device implementations, the table below |
| includes additional restrictions on the formats of these values to which device |
| implementations MUST conform.</p> |
| <table> |
| <tr> |
| <th>Parameter</th> |
| <th>Details</th> |
| </tr> |
| <tr> |
| <td>VERSION.RELEASE</td> |
| <td>The version of the currently-executing Android system, in human-readable |
| format. This field MUST have one of the string values defined in |
| <a href="http://source.android.com/compatibility/6.0/versions.html">6.0</a>.</td> |
| </tr> |
| <tr> |
| <td>VERSION.SDK</td> |
| <td>The version of the currently-executing Android system, in a format |
| accessible to third-party application code. For Android 6.0, |
| this field MUST have the integer value 6.0_INT.</td> |
| </tr> |
| <tr> |
| <td>VERSION.SDK_INT</td> |
| <td>The version of the currently-executing Android system, in a format |
| accessible to third-party application code. For Android 6.0, |
| this field MUST have the integer value 6.0_INT.</td> |
| </tr> |
| <tr> |
| <td>VERSION.INCREMENTAL</td> |
| <td>A value chosen by the device implementer designating the specific build |
| of the currently-executing Android system, in human-readable format. This |
| value MUST NOT be reused for different builds made available to end users. A |
| typical use of this field is to indicate which build number or |
| source-control change identifier was used to generate the build. There are |
| no requirements on the specific format of this field, except that it MUST |
| NOT be null or the empty string ("").</td> |
| </tr> |
| <tr> |
| <td>BOARD</td> |
| <td>A value chosen by the device implementer identifying the specific |
| internal hardware used by the device, in human-readable format. A possible |
| use of this field is to indicate the specific revision of the board powering |
| the device. The value of this field MUST be encodable as 7-bit ASCII and |
| match the regular expression “^[a-zA-Z0-9_-]+$”.</td> |
| </tr> |
| <tr> |
| <td>BRAND</td> |
| <td>A value reflecting the brand name associated with the device as known to |
| the end users. MUST be in human-readable format and SHOULD represent the |
| manufacturer of the device or the company brand under which the device is |
| marketed. The value of this field MUST be encodable as 7-bit ASCII and match |
| the regular expression “^[a-zA-Z0-9_-]+$”.</td> |
| </tr> |
| <tr> |
| <td>SUPPORTED_ABIS</td> |
| <td>The name of the instruction set (CPU type + ABI convention) of native |
| code. See <a href="#3_3_native_api_compatibility">section 3.3. Native API |
| Compatibility</a>.</td> |
| </tr> |
| <tr> |
| <td>SUPPORTED_32_BIT_ABIS</td> |
| <td>The name of the instruction set (CPU type + ABI convention) of native |
| code. See <a href="#3_3_native_api_compatibility">section 3.3. Native API |
| Compatibility</a>.</td> |
| </tr> |
| <tr> |
| <td>SUPPORTED_64_BIT_ABIS</td> |
| <td>The name of the second instruction set (CPU type + ABI convention) of |
| native code. See <a href="#3_3_native_api_compatibility">section 3.3. Native |
| API Compatibility</a>.</td> |
| </tr> |
| <tr> |
| <td>CPU_ABI</td> |
| <td>The name of the instruction set (CPU type + ABI convention) of native |
| code. See <a href="#3_3_native_api_compatibility">section 3.3. Native API |
| Compatibility</a>.</td> |
| </tr> |
| <tr> |
| <td>CPU_ABI2</td> |
| <td>The name of the second instruction set (CPU type + ABI convention) of |
| native code. See <a href="#3_3_native_api_compatibility">section 3.3. Native |
| API Compatibility</a>.</td> |
| </tr> |
| <tr> |
| <td>DEVICE</td> |
| <td>A value chosen by the device implementer containing the development name |
| 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> |
| </tr> |
| <tr> |
| <td>FINGERPRINT</td> |
| <td>A string that uniquely identifies this build. It SHOULD be reasonably |
| human-readable. It MUST follow this template: |
| <p class="small">$(BRAND)/$(PRODUCT)/<br> |
| $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)</p> |
| <p>For example:</p> |
| <p class="small">acme/myproduct/<br> |
| mydevice:6.0/LMYXX/3359:userdebug/test-keys</p> |
| <p>The fingerprint MUST NOT include whitespace characters. If other fields |
| included in the template above have whitespace characters, they MUST be |
| replaced in the build fingerprint with another character, such as the |
| underscore ("_") character. The value of this field MUST be encodable as |
| 7-bit ASCII.</p></td> |
| </tr> |
| <tr> |
| <td>HARDWARE</td> |
| <td>The name of the hardware (from the kernel command line or /proc). It |
| SHOULD be reasonably human-readable. The value of this field MUST be |
| encodable as 7-bit ASCII and match the regular expression |
| “^[a-zA-Z0-9_-]+$”.</td> |
| </tr> |
| <tr> |
| <td>HOST</td> |
| <td>A string that uniquely identifies the host the build was built on, in |
| human-readable format. There are no requirements on the specific format of |
| this field, except that it MUST NOT be null or the empty string ("").</td> |
| </tr> |
| <tr> |
| <td>ID</td> |
| <td>An identifier chosen by the device implementer to refer to a specific |
| release, in human-readable format. This field can be the same as |
| android.os.Build.VERSION.INCREMENTAL, but SHOULD be a value sufficiently |
| meaningful for end users to distinguish between software builds. The value |
| of this field MUST be encodable as 7-bit ASCII and match the regular |
| expression “^[a-zA-Z0-9._-]+$”.</td> |
| </tr> |
| <tr> |
| <td>MANUFACTURER</td> |
| <td>The trade name of the Original Equipment Manufacturer (OEM) of the |
| product. There are no requirements on the specific format of this field, |
| except that it MUST NOT be null or the empty string ("").</td> |
| </tr> |
| <tr> |
| <td>MODEL</td> |
| <td>A value chosen by the device implementer containing the name of the |
| device as known to the end user. This SHOULD be the same name under which |
| the device is marketed and sold to end users. There are no requirements on |
| the specific format of this field, except that it MUST NOT be null or the |
| empty string ("").</td> |
| </tr> |
| <tr> |
| <td>PRODUCT</td> |
| <td>A value chosen by the device implementer containing the development name |
| 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> |
| </tr> |
| <tr> |
| <td>SERIAL</td> |
| <td>A hardware serial number, which MUST be available and unique across |
| devices with the same MODEL and MANUFACTURER. The value of this field MUST |
| be encodable as 7-bit ASCII and match the regular expression |
| “^([a-zA-Z0-9]{6,20})$”.</td> |
| </tr> |
| <tr> |
| <td>TAGS</td> |
| <td>A comma-separated list of tags chosen by the device implementer that |
| further distinguishes the build. This field MUST have one of the values |
| corresponding to the three typical Android platform signing configurations: |
| release-keys, dev-keys, test-keys.</td> |
| </tr> |
| <tr> |
| <td>TIME</td> |
| <td>A value representing the timestamp of when the build occurred.</td> |
| </tr> |
| <tr> |
| <td>TYPE</td> |
| <td>A value chosen by the device implementer specifying the runtime |
| configuration of the build. This field MUST have one of the values |
| corresponding to the three typical Android runtime configurations: user, |
| userdebug, or eng.</td> |
| </tr> |
| <tr> |
| <td>USER</td> |
| <td>A name or user ID of the user (or automated user) that generated the |
| build. There are no requirements on the specific format of this field, |
| except that it MUST NOT be null or the empty string ("").</td> |
| </tr> |
| <tr> |
| <td>SECURITY_PATCH</td> |
| <td>A value indicating the security patch level of a build. It MUST signify |
| that the build includes all security patches issued up through the |
| designated Android Public Security Bulletin. It MUST be in the format |
| [YYYY-MM-DD], matching one of the Android Security Patch Level strings of |
| the <a href="source.android.com/security/bulletin"> Public Security |
| Bulletins</a>, for example "2015-11-01".</td> |
| </tr> |
| <tr> |
| <td>BASE_OS</td> |
| <td>A value representing the FINGERPRINT parameter of the build that is |
| otherwise identical to this build except for the patches provided in the |
| Android Public Security Bulletin. It MUST report the correct value and if |
| such a build does not exist, report an emtpy string ("").</td> |
| </tr> |
| </table> |
| |
| |
| <h3 id="3_2_3_intent_compatibility">3.2.3. Intent Compatibility</h3> |
| |
| |
| <p>Device implementations MUST honor Android’s loose-coupling intent |
| system, as described in the sections below. By “honored” it is meant |
| that the device implementer MUST provide an Android Activity or Service that |
| specifies amatching intent filter that binds to and implements correct behavior |
| for each specified intent pattern.</p> |
| |
| <h4 id="3_2_3_1_core_application_intents">3.2.3.1. Core Application Intents</h4> |
| |
| |
| <p>Android intents allow application components to request functionality from |
| other Android components. The Android upstream project includes a list of |
| applications considered core Android applications, which implements several |
| intent patterns to perform common actions. The core Android applications are: |
| </p> |
| |
| <ul> |
| <li>Desk Clock</li> |
| <li>Browser</li> |
| <li>Calendar</li> |
| <li>Contacts</li> |
| <li>Gallery</li> |
| <li>GlobalSearch</li> |
| <li>Launcher</li> |
| <li>Music</li> |
| <li>Settings</li> |
| </ul> |
| |
| <p>Device implementations SHOULD include the core Android applications as |
| appropriate but MUST include a component implementing the same intent patterns |
| defined by all the “public” Activity or Service components of these |
| core Android applications. Note that Activity or Service components are |
| considered “public” when the attribute android:exported is absent or |
| has the value true.</p> |
| |
| <h4 id="3_2_3_2_intent_resolution">3.2.3.2. Intent Resolution</h4> |
| |
| |
| <p>As Android is an extensible platform, device implementations MUST allow each |
| intent pattern referenced in <a href="#3_2_3_1_core_application_intents">section |
| 3.2.3.1</a> to be overridden by third-party applications. The upstream Android |
| open source implementation allows this by default; device implementers MUST NOT |
| attach special privileges to system applications' use of these intent patterns, |
| or prevent third-party applications from binding to and assuming control of |
| these patterns. This prohibition specifically includes but is not limited to |
| disabling the “Chooser” user interface that allows the user to |
| select between multiple applications that all handle the same intent pattern. |
| </p> |
| |
| <p>Device implementations MUST provide a user interface for users to modify the |
| default activity for intents.</p> |
| |
| <p>However, device implementations MAY provide default activities for specific |
| URI patterns (e.g. http://play.google.com) when the default activity provides a |
| more specific attribute for the data URI. For example, an intent filter pattern |
| specifying the data URI “http://www.android.com” is more specific |
| than the browser's core intent pattern for “http://”.</p> |
| |
| <p>Android also includes a mechanism for third-party apps to declare an |
| authoritative default |
| <a href="https://developer.android.com/training/app-links">app linking |
| behavior</a> for certain types of web URI intents. When such authoritative |
| declarations are defined in an app's intent filter patterns, device |
| implementations:</p> |
| |
| <ul> |
| <li>MUST attempt to validate any intent filters by performing the validation |
| steps defined in the |
| <a href="https://developers.google.com/digital-asset-links">Digital Asset |
| Links specification</a> as implemented by the Package Manager in the upstream |
| Android Open Source Project.</li> |
| <li>MUST attempt validation of the intent filters during the installation of |
| the application and set all successfully validated UIR intent filters as |
| default app handlers for their UIRs.</li> |
| <li>MAY set specific URI intent filters as default app handlers for their |
| URIs, if they are successfully verified but other candidate URI filters fail |
| verification. If a device implementation does this, it MUST provide the user |
| appropriate per-URI pattern overrides in the settings menu.</li> |
| <li>MUST provide the user with per-app App Links controls in Settings as |
| follows: |
| <ul> |
| <li>The user MUST be able to override holistically the default app links |
| behavior for an app to be: always open, always ask, or never open, which |
| must apply to all candidate URI intent filters equally.</li> |
| <li>The user MUST be able to see a list of the candidate URI intent filters. |
| </li> |
| <li>The device implementation MAY provide the user with the ability to |
| override specific candidate URI intent filters that were successfully |
| verified, on a per-intent filter basis.</li> |
| <li>The device implementation MUST provide users with the ability to view |
| and override specific candidate URI intent filters if the device |
| implementation lets some candidate URI intent filters succeed verification |
| while some others can fail.</li> |
| </ul> |
| </li> |
| </ul> |
| |
| <h4 id="3_2_3_3_intent_namespaces">3.2.3.3. Intent Namespaces</h4> |
| |
| |
| <p>Device implementations MUST NOT include any Android component that honors any |
| new intent or broadcast intent patterns using an ACTION, CATEGORY, or other key |
| string in the android.* or com.android.* namespace. Device implementers MUST NOT |
| include any Android components that honor any new intent or broadcast intent |
| patterns using an ACTION, CATEGORY, or other key string in a package space |
| belonging to another organization. Device implementers MUST NOT alter or extend |
| any of the intent patterns used by the core apps listed in |
| <a href="#3_2_3_1_core_application_intents">section 3.2.3.1</a>. Device |
| implementations MAY include intent patterns using namespaces clearly and |
| obviously associated with their own organization. This prohibition is analogous |
| to that specified for Java language classes in |
| <a href="#3_6_api_namespaces">section 3.6</a>.</p> |
| |
| <h4 id="3_2_3_4_broadcast_intents">3.2.3.4. Broadcast Intents</h4> |
| |
| |
| <p>Third-party applications rely on the platform to broadcast certain intents to |
| notify them of changes in the hardware or software environment. |
| Android-compatible devices MUST broadcast the public broadcast intents in |
| response to appropriate system events. Broadcast intents are described in the |
| SDK documentation.</p> |
| |
| <h4 id="3_2_3_5_default_app_settings">3.2.3.5. Default App Settings</h4> |
| |
| |
| <p>Android includes settings that provide users an easy way to select their |
| default applications, for example for Home screen or SMS. Where it makes sense, |
| device implementations MUST provide a similar settings menu and be compatible |
| with the intent filter pattern and API methods described in the SDK |
| documentation as below.</p> |
| |
| <p>Device implementations:</p> |
| |
| <ul> |
| <li>MUST honor the <a href="http://developer.android.com/reference/android/provider/Settings.html#ACTION_HOME_SETTINGS">android.settings.HOME_SETTINGS</a> |
| intent to show a default app settings menu for Home Screen, if the device |
| implementation reports android.software.home_screen.</li> |
| <li>MUST provide a settings menu that will call the |
| <a href="http://developer.android.com/reference/android/provider/Telephony.Sms.Intents.html">android.provider.Telephony.ACTION_CHANGE_DEFAULT</a> |
| intent to show a dialog to change the default SMS application, if the device |
| implementation reports android.hardware.telephony.</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> |
| </ul> |
| |
| <h2 id="3_3_native_api_compatibility">3.3. Native API Compatibility</h2> |
| |
| |
| <h3 id="3_3_1_application_binary_interfaces">3.3.1. Application Binary Interfaces</h3> |
| |
| |
| <p>Managed Dalvik bytecode can call into native code provided in the application |
| .apk file as an ELF .so file compiled for the appropriate device hardware |
| architecture. As native code is highly dependent on the underlying processor |
| technology, Android defines a number of Application Binary Interfaces (ABIs) in |
| the Android NDK. Device implementations MUST be compatible with one or more |
| defined ABIs, and MUST implement compatibility with the Android NDK, as below.</p> |
| |
| <p>If a device implementation includes support for an Android ABI, it:</p> |
| |
| <ul> |
| <li>MUST include support for code running in the managed environment to call |
| into native code, using the standard Java Native Interface (JNI) semantics.</li> |
| <li>MUST be source-compatible (i.e. header compatible) and binary-compatible |
| (for the ABI) with each required library in the list below.</li> |
| <li>MUST support the equivalent 32-bit ABI if any 64-bit ABI is supported.</li> |
| <li>MUST accurately report the native Application Binary Interface (ABI) |
| supported by the device, via the android.os.Build.SUPPORTED_ABIS, |
| android.os.Build.SUPPORTED_32_BIT_ABIS, and |
| android.os.Build.SUPPORTED_64_BIT_ABIS parameters, each a comma separated list |
| of ABIs ordered from the most to the least preferred one.</li> |
| <li>MUST report, via the above parameters, only those ABIs documented and |
| described in the latest version of the |
| <a href="https://developer.android.com/ndk/guides/abis.html">Android NDK ABI |
| Management documentation</a>, and MUST include support for the |
| <a href="http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/Beijfcja.html">Advanced |
| SIMD</a> (a.k.a. NEON) extension.</li> |
| <li>SHOULD be built using the source code and header files available in the |
| upstream Android Open Source Project</li> |
| </ul> |
| |
| <p>The following native code APIs MUST be available to apps that include native |
| code:</p> |
| |
| <ul> |
| <li>libc (C library)</li> |
| <li>libm (math library)</li> |
| <li>Minimal support for C++</li> |
| <li>JNI interface</li> |
| <li>liblog (Android logging)</li> |
| <li>libz (Zlib compression)</li> |
| <li>libdl (dynamic linker)</li> |
| <li>libGLESv1_CM.so (OpenGL ES 1.x)</li> |
| <li>libGLESv2.so (OpenGL ES 2.0)</li> |
| <li>libGLESv3.so (OpenGL ES 3.x)</li> |
| <li>libEGL.so (native OpenGL surface management)</li> |
| <li>libjnigraphics.so</li> |
| <li>libOpenSLES.so (OpenSL ES 1.0.1 audio support)</li> |
| <li>libOpenMAXAL.so (OpenMAX AL 1.0.1 support)</li> |
| <li>libandroid.so (native Android activity support)</li> |
| <li>libmediandk.so (native media APIs support)</li> |
| <li>Support for OpenGL, as described below</li> |
| </ul> |
| |
| <p>Note that future releases of the Android NDK may introduce support for |
| additional ABIs. If a device implementation is not compatible with an existing |
| predefined ABI, it MUST NOT report support for any ABIs at all.</p> |
| |
| <p>Note that device implementations MUST include libGLESv3.so and it MUST symlink |
| (symbolic link) to libGLESv2.so. in turn, MUST export all the OpenGL ES 3.1 and |
| <a href="http://developer.android.com/guide/topics/graphics/opengl.html#aep">Android |
| Extension Pack</a> function symbols as defined in the NDK release android-21. |
| Although all the symbols must be present, only the corresponding functions for |
| OpenGL ES versions and extensions actually supported by the device must be fully |
| implemented.</p> |
| |
| <p>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.</p> |
| |
| <p>Native code compatibility is challenging. For this reason, device |
| implementers are <strong>STRONGLY RECOMMENDED</strong> to use the |
| implementations of the libraries listed above from the upstream Android Open |
| Source Project.</p> |
| |
| <h3 id="3_3_2_32-bit_arm_native_code_compatibility">3.3.2. |
| 32-bit ARM Native Code Compatibility</h3> |
| |
| <p>The ARMv8 architecture deprecates several CPU operations, including some |
| operations used in existing native code. On 64-bit ARM devices, the following |
| deprecated operations MUST remain available to 32-bit native ARM code, either |
| through native CPU support or through software emulation:</p> |
| |
| <ul> |
| <li>SWP and SWPB instructions</li> |
| <li>SETEND instruction</li> |
| <li>CP15ISB, CP15DSB, and CP15DMB barrier operations</li> |
| </ul> |
| |
| <p>Legacy versions of the Android NDK used /proc/cpuinfo to discover CPU |
| features from 32-bit ARM native code. For compatibility with applications built |
| using this NDK, devices MUST include the following lines in /proc/cpuinfo when |
| it is read by 32-bit ARM applications:</p> |
| |
| <ul> |
| <li>"Features: ", followed by a list of any optional ARMv7 CPU |
| features supported by the device.</li> |
| <li>"CPU architecture: ", followed by an integer describing the |
| device's highest supported ARM architecture (e.g., "8" for ARMv8 |
| devices).</li> |
| </ul> |
| |
| <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">3.4. Web Compatibility</h2> |
| |
| |
| <h3 id="3_4_1_webview_compatibility">3.4.1. WebView Compatibility</h3> |
| |
| <div class="note"> |
| <p>Android Watch devices MAY, but all other device implementations MUST provide |
| a complete implementation of the android.webkit.Webview API.</p> |
| </div> |
| |
| |
| <p>The platform feature android.software.webview MUST be reported on any device |
| that provides a complete implementation of the android.webkit.WebView API, and |
| MUST NOT be reported on devices without a complete implementation of the API. |
| The Android Open Source implementation uses code from the Chromium Project to |
| implement the |
| <a href="http://developer.android.com/reference/android/webkit/WebView.html">android.webkit.WebView</a>. |
| Because it is not feasible to develop a comprehensive test suite for a web |
| rendering system, device implementers MUST use the specific upstream build of |
| Chromium in the WebView implementation. Specifically:</p> |
| |
| <ul> |
| <li>Device android.webkit.WebView implementations MUST be based on the |
| <a href="http://www.chromium.org/">Chromium</a> build from the upstream |
| Android Open Source Project for Android 6.0. This build includes |
| a specific set of functionality and security fixes for the WebView.</li> |
| <li>The user agent string reported by the WebView MUST be in this format: |
| <p>Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv) |
| AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile |
| Safari/537.36</p> |
| <ul> |
| <li>The value of the $(VERSION) string MUST be the same as the value for |
| android.os.Build.VERSION.RELEASE.</li> |
| <li>The value of the $(MODEL) string MUST be the same as the value for |
| android.os.Build.MODEL.</li> |
| <li>The value of the $(BUILD) string MUST be the same as the value for |
| android.os.Build.ID.</li> |
| <li>The value of the $(CHROMIUM_VER) string MUST be the version of Chromium |
| in the upstream Android Open Source Project.</li> |
| <li>Device implementations MAY omit Mobile in the user agent string.</li> |
| </ul> |
| </li> |
| </ul> |
| |
| <p>The WebView component SHOULD include support for as many HTML5 features as |
| possible and if it supports the feature SHOULD conform to the |
| <a href="http://html.spec.whatwg.org/multipage/">HTML5 specification</a>.</p> |
| |
| <h3 id="3_4_2_browser_compatibility">3.4.2. Browser Compatibility</h3> |
| |
| <div class="note"> |
| <p>Android Television, Watch, and Android Automotive implementations MAY omit a |
| browser application, but MUST support the public intent patterns as described in |
| <a href="#3_2_3_1_core_application_intents">section 3.2.3.1</a>. All other types |
| of device implementations MUST include a standalone Browser application for |
| general user web browsing.</p> |
| </div> |
| |
| <p>The standalone Browser MAY be based on a browser technology other than WebKit. |
| However, even if an alternate Browser application is used, the |
| android.webkit.WebView component provided to third-party applications MUST be |
| based on WebKit, as described in <a href="#3_4_1_webview_compatibility">section |
| 3.4.1</a>.</p> |
| |
| <p>Implementations MAY ship a custom user agent string in the standalone Browser |
| application.</p> |
| |
| <p>The standalone Browser application (whether based on the upstream WebKit |
| Browser application or a third-party replacement) SHOULD include support for as |
| much of <a href="http://html.spec.whatwg.org/multipage/">HTML5</a> as possible. |
| Minimally, device implementations MUST support each of these APIs associated |
| with HTML5:</p> |
| |
| <ul> |
| <li><a href="http://www.w3.org/html/wg/drafts/html/master/browsers.html#offline">application |
| cache/offline operation</a></li> |
| <li><a href="http://www.w3.org/html/wg/drafts/html/master/semantics.html#video"><video> |
| tag</a></li> |
| <li><a href="http://www.w3.org/TR/geolocation-API/">geolocation</a></li> |
| </ul> |
| |
| <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">3.5. API Behavioral Compatibility</h2> |
| |
| |
| <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> |
| |
| <ul> |
| <li>Devices MUST NOT change the behavior or semantics of a standard intent. |
| </li> |
| <li>Devices MUST NOT alter the lifecycle or lifecycle semantics of a |
| particular type of system component (such as Service, Activity, |
| ContentProvider, etc.).</li> |
| <li>Devices MUST NOT change the semantics of a standard permission.</li> |
| </ul> |
| |
| <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">3.6. API Namespaces</h2> |
| |
| |
| <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> |
| |
| <ul> |
| <li>java.*</li> |
| <li>javax.*</li> |
| <li>sun.*</li> |
| <li>android.*</li> |
| <li>com.android.*</li> |
| </ul> |
| |
| <p><strong>Prohibited modifications include</strong>:</p> |
| |
| <ul> |
| <li>Device implementations MUST NOT modify the publicly exposed APIs on the |
| Android platform by changing any method or class signatures, or by removing |
| classes or class fields.</li> |
| <li>Device implementers MAY modify the underlying implementation of the APIs, |
| but such modifications MUST NOT impact the stated behavior and Java-language |
| signature of any publicly exposed APIs.</li> |
| <li>Device implementers MUST NOT add any publicly exposed elements (such as |
| classes or interfaces, or fields or methods to existing classes or interfaces) |
| to the APIs above.</li> |
| </ul> |
| |
| <p>A “publicly exposed element” is any construct that is not |
| decorated with the“@hide” marker as used in the upstream Android |
| source code. In other words, device implementers MUST NOT expose new APIs or |
| alter existing APIs in the namespaces noted above. Device implementers MAY make |
| internal-only modifications, but those modifications MUST NOT be advertised or |
| otherwise exposed to developers.</p> |
| |
| <p>Device implementers MAY add custom APIs, but any such APIs MUST NOT be in a |
| namespace owned by or referring to another organization. For instance, device |
| implementers MUST NOT add APIs to the com.google.* or similar namespace: only |
| Google may do so. Similarly, Google MUST NOT add APIs to other companies' |
| namespaces. Additionally, if a device implementation includes custom APIs |
| outside the standard Android namespace, those APIs MUST be packaged in an |
| Android shared library so that only apps that explicitly use them (via the |
| lt;uses-librarygt; mechanism) are affected by the increased memory usage of such |
| APIs.</p> |
| |
| <p>If a device implementer proposes to improve one of the package namespaces |
| above (such as by adding useful new functionality to an existing API, or adding |
| a new API), the implementer SHOULD visit |
| <a href="http://source.android.com/">source.android.com</a> and begin the |
| process for contributing changes and code, according to the information on that |
| site.</p> |
| |
| <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">3.7. Runtime Compatibility</h2> |
| |
| |
| <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> |
| |
| <p>Device implementations MUST configure Dalvik runtimes to allocate memory in |
| accordance with the upstream Android platform, and as specified by the |
| following table. (See <a href="#7_1_1_screen_configuration">section 7.1.1</a> |
| for screen size and screen density definitions.) Note that memory values |
| specified below are considered minimum values and device implementations MAY |
| allocate more memory per application.</p> |
| |
| <table> |
| <tr> |
| <th>Screen Layout</th> |
| <th>Screen Density</th> |
| <th>Minimum Application Memory</th> |
| </tr> |
| <tr> |
| <td rowspan="12">Android Watch</td> |
| <td>120 dpi (ldpi)</td> |
| <td rowspan="3">32MB</td> |
| </tr> |
| <tr> |
| <td>160 dpi (mdpi)</td> |
| </tr> |
| <tr> |
| <td>213 dpi (tvdpi)</td> |
| </tr> |
| <tr> |
| <td>240 dpi (hdpi)</td> |
| <td rowspan="2">36MB</td> |
| </tr> |
| <tr> |
| <td>280 dpi (280dpi)</td> |
| </tr> |
| <tr> |
| <td>320 dpi (xhdpi)</td> |
| <td rowspan="2">48MB</td> |
| </tr> |
| <tr> |
| <td>360 dpi (360dpi)</td> |
| </tr> |
| <tr> |
| <td>400 dpi (400dpi)</td> |
| <td>56MB</td> |
| </tr> |
| <tr> |
| <td>420 dpi (420dpi)</td> |
| <td>64MB</td> |
| </tr> |
| <tr> |
| <td>480 dpi (xxhdpi)</td> |
| <td>88MB</td> |
| </tr> |
| <tr> |
| <td>560 dpi (560dpi)</td> |
| <td>112MB</td> |
| </tr> |
| <tr> |
| <td>640 dpi (xxxhdpi)</td> |
| <td>154MB</td> |
| </tr> |
| <tr> |
| <td rowspan="12">small/normal</td> |
| <td>120 dpi (ldpi)</td> |
| <td rowspan="2">32MB</td> |
| </tr> |
| <tr> |
| <td>160 dpi (mdpi)</td> |
| </tr> |
| <tr> |
| <td>213 dpi (tvdpi)</td> |
| <td rowspan="3">48MB</td> |
| </tr> |
| <tr> |
| <td>240 dpi (hdpi)</td> |
| </tr> |
| <tr> |
| <td>280 dpi (280dpi)</td> |
| </tr> |
| <tr> |
| <td>320 dpi (xhdpi)</td> |
| <td rowspan="2">80MB</td> |
| </tr> |
| <tr> |
| <td>360 dpi (360dpi)</td> |
| </tr> |
| <tr> |
| <td>400 dpi (400dpi)</td> |
| <td>96MB</td> |
| </tr> |
| <tr> |
| <td>420 dpi (420dpi)</td> |
| <td>112MB</td> |
| </tr> |
| <tr> |
| <td>480 dpi (xxhdpi)</td> |
| <td>128MB</td> |
| </tr> |
| <tr> |
| <td>560 dpi (560dpi)</td> |
| <td>192MB</td> |
| </tr> |
| <tr> |
| <td>640 dpi (xxxhdpi)</td> |
| <td>256MB</td> |
| </tr> |
| <tr> |
| <td rowspan="12">large</td> |
| <td>120 dpi (ldpi)</td> |
| <td>32MB</td> |
| </tr> |
| <tr> |
| <td>160 dpi (mdpi)</td> |
| <td>48MB</td> |
| </tr> |
| <tr> |
| <td>213 dpi (tvdpi)</td> |
| <td rowspan="2">80MB</td> |
| </tr> |
| <tr> |
| <td>240 dpi (hdpi)</td> |
| </tr> |
| <tr> |
| <td>280 dpi (280dpi)</td> |
| <td>96MB</td> |
| </tr> |
| <tr> |
| <td>320 dpi (xhdpi)</td> |
| <td>128MB</td> |
| </tr> |
| <tr> |
| <td>360 dpi (360dpi)</td> |
| <td>160MB</td> |
| </tr> |
| <tr> |
| <td>400 dpi (400dpi)</td> |
| <td>192MB</td> |
| </tr> |
| <tr> |
| <td>420 dpi (420dpi)</td> |
| <td>228MB</td> |
| </tr> |
| <tr> |
| <td>480 dpi (xxhdpi)</td> |
| <td>256MB</td> |
| </tr> |
| <tr> |
| <td>560 dpi (560dpi)</td> |
| <td>384MB</td> |
| </tr> |
| <tr> |
| <td>640 dpi (xxxhdpi)</td> |
| <td>512MB</td> |
| </tr> |
| <tr> |
| <td rowspan="12">xlarge</td> |
| <td>120 dpi (ldpi)</td> |
| <td>48MB</td> |
| </tr> |
| <tr> |
| <td>160 dpi (mdpi)</td> |
| <td>80MB</td> |
| </tr> |
| <tr> |
| <td>213 dpi (tvdpi)</td> |
| <td rowspan="2">96MB</td> |
| </tr> |
| <tr> |
| <td>240 dpi (hdpi)</td> |
| </tr> |
| <tr> |
| <td>280 dpi (280dpi)</td> |
| <td>144MB</td> |
| </tr> |
| <tr> |
| <td>320 dpi (xhdpi)</td> |
| <td>192MB</td> |
| </tr> |
| <tr> |
| <td>360 dpi (360dpi)</td> |
| <td>240MB</td> |
| </tr> |
| <tr> |
| <td>400 dpi (400dpi)</td> |
| <td>288MB</td> |
| </tr> |
| <tr> |
| <td>420 dpi (420dpi)</td> |
| <td>336MB</td> |
| </tr> |
| <tr> |
| <td>480 dpi (xxhdpi)</td> |
| <td>384MB</td> |
| </tr> |
| <tr> |
| <td>560 dpi (560dpi)</td> |
| <td>576MB</td> |
| </tr> |
| <tr> |
| <td>640 dpi (xxxhdpi)</td> |
| <td>768MB</td> |
| </tr> |
| </table> |
| |
| |
| <h2 id="3_8_user_interface_compatibility">3.8. User Interface Compatibility</h2> |
| |
| |
| <h3 id="3_8_1_launcher_home_screen">3.8.1. Launcher (Home Screen)</h3> |
| |
| |
| <p>Android includes a launcher application (home screen) and support for |
| third-party applications to replace the device launcher (home screen). Device |
| implementations that allow third-party applications to replace the device home |
| screen MUST declare the platform feature android.software.home_screen.</p> |
| |
| <h3 id="3_8_2_widgets">3.8.2. Widgets</h3> |
| |
| <div class="note"> |
| <p>Widgets are optional for all Android device implementations, but SHOULD be |
| supported on Android Handheld devices.</p> |
| </div> |
| |
| |
| <p>Android defines a component type and corresponding API and lifecycle that |
| allows applications to expose an |
| <a href="http://developer.android.com/guide/practices/ui_guidelines/widget_design.html">“AppWidget”</a> |
| to the end user, a feature that is STRONGLY RECOMMENDED to be supported on |
| Handheld Device implementations. Device implementations that support embedding |
| widgets on the home screen MUST meet the following requirements and declare |
| support for platform feature android.software.app_widgets.</p> |
| |
| <ul> |
| <li>Device launchers MUST include built-in support for AppWidgets and expose |
| user interface affordances to add, configure, view, and remove AppWidgets |
| directly within the Launcher.</li> |
| <li>Device implementations MUST be capable of rendering widgets that are 4 x 4 |
| in the standard grid size. See the |
| <a href="http://developer.android.com/guide/practices/ui_guidelines/widget_design.html">App |
| Widget Design Guidelines</a> in the Android SDK documentation for details. |
| </li> |
| <li>Device implementations that include support for lock screen MAY support |
| application widgets on the lock screen.</li> |
| </ul> |
| |
| <h3 id="3_8_3_notifications">3.8.3. Notifications</h3> |
| |
| |
| <p>Android includes APIs that allow developers to |
| <a href="http://developer.android.com/guide/topics/ui/notifiers/notifications.html">notify |
| users of notable events</a> using hardware and software features of the device.</p> |
| |
| <p>Some APIs allow applications to perform notifications or attract attention |
| using hardware—specifically sound, vibration, and light. Device |
| implementations MUST support notifications that use hardware features, as |
| described in the SDK documentation, and to the extent possible with the device |
| implementation hardware. For instance, if a device implementation includes a |
| vibrator, it MUST correctly implement the vibration APIs. If a device |
| implementation lacks hardware, the corresponding APIs MUST be implemented as |
| no-ops. This behavior is further detailed in |
| <a href="#7_hardware_compatibility">section 7</a>.</p> |
| |
| <p>Additionally, the implementation MUST correctly render all |
| <a href="https://developer.android.com/guide/topics/resources/available-resources.html">resources</a> |
| (icons, animation files etc.) provided for in the APIs, or in the Status/System |
| Bar <a href="http://developer.android.com/design/style/iconography.html">icon |
| style guide</a>, which in the case of an Android Television device includes the |
| possibility to not display the notifications. Device implementers MAY provide an |
| alternative user experience for notifications than that provided by the |
| reference Android Open Source implementation; however, such alternative |
| notification systems MUST support existing notification resources, as above.</p> |
| |
| <p>Android includes support for various notifications, such as:</p> |
| |
| <ul> |
| <li><strong>Rich notifications</strong>. Interactive Views for ongoing |
| notifications.</li> |
| <li><strong>Heads-up notifications</strong>. Interactive Views users can act |
| on or dismiss without leaving the current app.</li> |
| <li><strong>Lockscreen notifications</strong>. Notifications shown over a lock |
| screen with granular control on visibility.</li> |
| </ul> |
| |
| <p>Android device implementations, when such notifications are made visible, |
| MUST properly execute Rich and Heads-up notifications and include the |
| title/name, icon, text as |
| <a href="https://developer.android.com/design/patterns/notifications.html">documented |
| in the Android APIs</a>.</p> |
| |
| <p>Android includes Notification Listener Service APIs that allow apps (once |
| explicitly enabled by the user) to receive a copy of all notifications as they |
| are posted or updated. Device implementations MUST correctly and promptly send |
| notifications in their entirety to all such installed and user-enabled listener |
| services, including any and all metadata attached to the Notification object. |
| </p> |
| |
| <h3 id="3_8_4_search">3.8.4. Search</h3> |
| |
| |
| <p>Android includes APIs that allow developers to |
| <a href="http://developer.android.com/reference/android/app/SearchManager.html">incorporate |
| search</a> into their applications and expose their application’s data |
| into the global system search. Generally speaking, this functionality consists |
| of a single, system-wide user interface that allows users to enter queries, |
| displays suggestions as users type, and displays results. The Android APIs allow |
| developers to reuse this interface to provide search within their own apps and |
| allow developers to supply results to the common global search user interface. |
| </p> |
| |
| <p>Android device implementations SHOULD include global search, a single, |
| shared, system-wide search user interface capable of real-time suggestions in |
| response to user input. Device implementations SHOULD implement the APIs that |
| allow developers to reuse this user interface to provide search within their own |
| applications. Device implementations that implement the global search interface |
| MUST implement the APIs that allow third-party applications to add suggestions |
| to the search box when it is run in global search mode. If no third-party |
| applications are installed that make use of this functionality, the default |
| behavior SHOULD be to display web search engine results and suggestions.</p> |
| |
| <p>Android device implementations SHOULD implement an assistant on the device |
| to handle the |
| <a href="http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST">Assist |
| action</a>.</p> |
| |
| <p>Android also includes the |
| <a href="https://developer.android.com/reference/android/app/assist/package-summary.html">Assist |
| APIs</a> 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 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.</p> |
| |
| <h3 id="3_8_5_toasts">3.8.5. Toasts</h3> |
| |
| |
| <p>Applications can use the <a href="http://developer.android.com/reference/android/widget/Toast.html">“Toast” |
| API</a> to display short non-modal strings to the end user that disappear after |
| a brief period of time. Device implementations MUST display Toasts from |
| applications to end users in some high-visibility manner.</p> |
| |
| <h3 id="3_8_6_themes">3.8.6. Themes</h3> |
| |
| |
| <p>Android provides “themes” as a mechanism for applications to |
| apply styles across an entire Activity or application.</p> |
| |
| <p>Android includes a “Holo” theme family as a set of defined styles |
| for application developers to use if they want to match the |
| <a href="http://developer.android.com/guide/topics/ui/themes.html">Holo theme |
| look and feel</a> as defined by the Android SDK. Device implementations MUST NOT |
| alter any of the |
| <a href="http://developer.android.com/reference/android/R.style.html">Holo |
| theme attributes</a> exposed to applications.</p> |
| |
| <p>Android includes a “Material” theme family as a set of defined |
| styles for application developers to use if they want to match the design |
| theme’s look and feel across the wide variety of different Android device |
| types. Device implementations MUST support the “Material” theme |
| family and MUST NOT alter any of the |
| <a href="http://developer.android.com/reference/android/R.style.html#Theme_Material">Material |
| theme attributes</a> or their assets exposed to applications.</p> |
| |
| <p>Android also includes a “Device Default” theme family as a set of |
| defined styles for application developers to use if they want to match the look |
| and feel of the device theme as defined by the device implementer. Device |
| implementations MAY modify the |
| <a href="http://developer.android.com/reference/android/R.style.html">Device |
| Default theme attributes</a> exposed to applications.</p> |
| |
| <p>Android supports a variant theme with translucent system bars, which allows |
| application developers to fill the area behind the status and navigation bar |
| with their app content. To enable a consistent developer experience in this |
| configuration, it is important the status bar icon style is maintained across |
| different device implementations. Therefore, Android device implementations |
| MUST use white for system status icons (such as signal strength and battery |
| level) and notifications issued by the system, unless the icon is indicating a |
| problematic status or an app requests a light status bar using the |
| SYSTEM_UI_FLAG_LIGHT_STATUS_BAR flag. When an app requests a light status bar, |
| Android device implementations MUST change the color of the system status icons |
| to black (for details, refer to |
| <a href="http://developer.android.com/reference/android/R.style.html">R.style</a>).</p> |
| |
| <h3 id="3_8_7_live_wallpapers">3.8.7. Live Wallpapers</h3> |
| |
| |
| <p>Android defines a component type and corresponding API and lifecycle that |
| allows applications to expose one or more |
| <a href="http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html">“Live |
| Wallpapers”</a> to the end user. Live wallpapers are animations, patterns, |
| or similar images with limited input capabilities that display as a wallpaper, |
| behind other applications.</p> |
| |
| <p>Hardware is considered capable of reliably running live wallpapers if it can |
| run all live wallpapers, with no limitations on functionality, at a reasonable |
| frame rate with no adverse effects on other applications. If limitations in the |
| hardware cause wallpapers and/or applications to crash, malfunction, consume |
| excessive CPU or battery power, or run at unacceptably low frame rates, the |
| hardware is considered incapable of running live wallpaper. As an example, some |
| live wallpapers may use an OpenGL 2.0 or 3.x context to render their content. |
| Live wallpaper will not run reliably on hardware that does not support multiple |
| OpenGL contexts because the live wallpaper use of an OpenGL context may |
| conflict with other applications that also use an OpenGL context.</p> |
| |
| <p>Device implementations capable of running live wallpapers reliably as |
| described above SHOULD implement live wallpapers, and when implemented MUST |
| report the platform feature flag android.software.live_wallpaper.</p> |
| |
| <h3 id="3_8_8_activity_switching">3.8.8. Activity Switching</h3> |
| |
| <div class="note"> |
| <p>As the Recent function navigation key is OPTIONAL, the requirements to |
| implement the overview screen is OPTIONAL for Android Television devices and |
| Android Watch devices.</p> |
| </div> |
| |
| |
| <p>The upstream Android source code includes the |
| <a href="http://developer.android.com/guide/components/recents.html">overview |
| screen</a>, a system-level user interface for task switching and displaying |
| recently accessed activities and tasks using a thumbnail image of the |
| application’s graphical state at the moment the user last left the |
| application. Device implementations including the recents function navigation |
| key as detailed in <a href="#7_2_3_navigation_keys">section 7.2.3</a> MAY alter |
| the interface but MUST meet the following requirements:</p> |
| |
| <ul> |
| <li>MUST display affiliated recents as a group that moves together.</li> |
| <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> |
| <li>SHOULD display highlight color, icon, screen title in recents.</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> |
| <li>SHOULD display a closing affordance ("x") but MAY delay this until user |
| interacts with screens.</li> |
| </ul> |
| |
| <p>Device implementations are STRONGLY RECOMMENDED to use the upstream Android |
| user interface (or a similar thumbnail-based interface) for the overview screen. |
| </p> |
| |
| <h3 id="3_8_9_input_management">3.8.9. Input Management</h3> |
| |
| |
| <p>Android includes support for |
| <a href="http://developer.android.com/guide/topics/text/creating-input-method.html">Input |
| Management</a> and support for third-party input method editors. Device |
| implementations that allow users to use third-party input methods on the device |
| MUST declare the platform feature android.software.input_methods and support IME |
| APIs as defined in the Android SDK documentation.</p> |
| |
| <p>Device implementations that declare the |
| android.software.input_methods feature MUST provide a user-accessible mechanism |
| to add and configure third-party input methods. Device implementations MUST |
| display the settings interface in response to the |
| android.settings.INPUT_METHOD_SETTINGS intent.</p> |
| |
| <h3 id="3_8_10_lock_screen_media_control">3.8.10. Lock Screen Media Control</h3> |
| |
| |
| <p>The Remote Control Client API is deprecated from Android 5.0 in favor of the |
| <a href="http://developer.android.com/reference/android/app/Notification.MediaStyle.html">Media |
| Notification Template</a> that allows media applications to integrate with |
| playback controls that are displayed on the lock screen. Device implementations |
| that support a lock screen, unless an Android Automotive or Watch |
| implementation, MUST display the Lockscreen Notifications including the Media |
| Notification Template.</p> |
| |
| <h3 id="3_8_11_dreams">3.8.11. Dreams</h3> |
| |
| |
| <p>Android includes support for interactive screensavers called |
| <a href="http://developer.android.com/reference/android/service/dreams/DreamService.html">Dreams</a>. |
| 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.</p> |
| |
| <h3 id="3_8_12_location">3.8.12. Location</h3> |
| |
| |
| <p>When a device has a hardware sensor (e.g. GPS) that is capable of providing |
| the location coordinates, |
| <a href="http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE">location |
| modes</a> MUST be displayed in the Location menu within Settings.</p> |
| |
| <h3 id="3_8_13_unicode_and_font">3.8.13. Unicode and Font</h3> |
| |
| |
| <p>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 |
| <a href="http://www.unicode.org/versions/Unicode6.1.0/">Unicode 6.1</a>. All |
| devices MUST be capable of rendering these emoji characters in color glyph.</p> |
| |
| <p>Android includes support for Roboto 2 font with different |
| weights—sans-serif-thin, sans-serif-light, sans-serif-medium, |
| sans-serif-black, sans-serif-condensed, sans-serif-condensed-light—which |
| MUST all be included for 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. |
| </p> |
| |
| <h2 id="3_9_device_administration">3.9. Device Administration</h2> |
| |
| <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 include support for PIN (numeric) or PASSWORD |
| (alphanumeric) based lock screens MUST support 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> |
| |
| <h3 id="3_9_1_device_provisioning">3.9.1 Device Provisioning</h3> |
| |
| <h4 id="3_9_1_1_device_owner_provisioning">3.9.1.1 Device owner provisioning</h4> |
| <p>If a device implementation declares the android.software.device_admin |
| feature, the out of box setup flow MUST make it possible to enroll a Device |
| Policy Controller (DPC) application as the |
| <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)">Device |
| Owner app</a>. Device implementations MAY have a preinstalled application |
| performing device administration functions but this application MUST NOT be set |
| as the Device Owner app without explicit consent or action from the user or the |
| administrator of the device.</p> |
| |
| <p>The device owner provisioning process (the flow initiated by |
| <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_DEVICE">android.app.action.PROVISION_MANAGED_DEVICE</a>) |
| user experience MUST align with the AOSP implementation.</p> |
| |
| <p>If the device implementation reports android.hardware.nfc, it MUST have NFC |
| enabled, even during the out-of-box setup flow, in order to allow for |
| <a href="https://source.android.com/devices/tech/admin/provision.html#device_owner_provisioning_via_nfc">NFC |
| provisioning of Device owners</a>.</p> |
| |
| <h4 id="3_9_1_2_managed_profile_provisioning">3.9.1.2 Managed profile |
| provisioning</h4> |
| <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(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.</p> |
| |
| |
| <h2 id="3_9_2_managed_profile_support">3.9.2 Managed Profile Support</h2> |
| |
| <p>Managed profile capable devices are those devices that:</p> |
| <ul> |
| <li>Declare android.software.device_admin (see |
| <a href="#3_9_device_administration">section 3.9 Device Administration</a>). |
| </li> |
| <li>Are not low RAM devices (see |
| <a href="#7_6_1_minimum_memory_and_storage">section 7.6.1</a>).</li> |
| <li>Allocate internal (non-removable) storage as shared storage (see |
| <a href="#7_6_2_application_shared_storage">section 7.6.2</a>).</li> |
| </ul> |
| <p>Managed profile capable devices MUST:</p> |
| <ul> |
| <li>Declare the platform feature flag android.software.managed_users.</li> |
| <li>Support managed profiles via the android.app.admin.DevicePolicyManager APIs.</li> |
| <li>Allow one and only |
| <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_PROFILE">one |
| managed profile to be created</a>.</li> |
| <li>Use an icon badge (similar to the AOSP upstream work badge) to represent |
| the managed applications and widgets and other badged UI elements like Recents |
| & Notifications.</li> |
| <li>Display a notification icon (similar to the AOSP upstream work badge) to |
| indicate when user is within a managed profile application.</li> |
| <li>Display a toast indicating that the user is in the managed profile if and |
| when the device wakes up (ACTION_USER_PRESENT) and the foreground application |
| is within the managed profile.</li> |
| <li>Where a managed profile exists, show a visual affordance in the Intent |
| 'Chooser' to allow the user to forward the intent from the managed profile to |
| the primary user or vice versa, if enabled by the Device Policy Controller. |
| </li> |
| <li>Where a managed profile exists, expose the following user affordances for |
| both the primary user and the managed profile: |
| <ul> |
| <li>Separate accounting for battery, location, mobile data and storage usage |
| for the primary user and managed profile.</li> |
| <li>Independent management of VPN Applications installed within the primary |
| user or managed profile.</li> |
| <li>Independent management of applications installed within the primary user |
| or managed profile.</li> |
| <li>Independent management of accounts within the primary user or managed |
| profile.</li> |
| </ul> |
| </li> |
| <li>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.</li> |
| <li>MUST ensure that it satisfies all the security requirements applicable for |
| a device with multiple users enabled (see |
| <a href="#9_5_multi-user_support">section 9.5</a>), even though the managed |
| profile is not counted as another user in addition to the primary user.</li> |
| </ul> |
| |
| <h2 id="3_10_accessibility">3.10. Accessibility</h2> |
| |
| |
| <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> |
| |
| <p>Device implementations include the following requirements:</p> |
| |
| <ul> |
| <li>Android Automotive implementations SHOULD provide an implementation of the |
| Android accessibility framework consistent with the default Android |
| implementation.</li> |
| <li>Device implementations (Android Automotive excluded) MUST provide an |
| implementation of the Android accessibility framework consistent with the |
| default Android implementation.</li> |
| <li>Device implementations (Android Automotive excluded) MUST support |
| third-party accessibility service implementations through the |
| <a href="http://developer.android.com/reference/android/view/accessibility/package-summary.html">android.accessibilityservice APIs</a>. |
| </li> |
| <li>Device implementations (Android Automotive excluded) MUST generate |
| AccessibilityEvents and deliver these events to all registered |
| AccessibilityService implementations in a manner consistent with the default |
| Android implementation</li> |
| <li>Device implementations (Android Automotive and Android Watch devices with |
| no audio output excluded), MUST provide a user-accessible mechanism to enable |
| and disable accessibility services, and MUST display this interface in |
| response to the android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS |
| intent.</li> |
| </ul> |
| |
| <p>Additionally, device implementations SHOULD provide an implementation of an |
| accessibility service on the device, and SHOULD provide a mechanism for users |
| to enable the accessibility service during device setup. An open source |
| implementation of an accessibility service is available from the |
| <a href="http://code.google.com/p/eyes-free/">Eyes Free project</a>.</p> |
| |
| <h2 id="3_11_text-to-speech">3.11. Text-to-Speech</h2> |
| |
| |
| <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> |
| |
| <p>Android Automotive implementations:</p> |
| <ul> |
| <li>MUST support the Android TTS framework APIs.</li> |
| <li>MAY support installation of third-party TTS engines. If supported, |
| partners MUST provide a user-accessible interface that allows the user to |
| select a TTS engine for use at system level.</li> |
| </ul> |
| |
| <p>All other device implementations:</p> |
| |
| <ul> |
| <li>MUST support the Android TTS framework APIs and SHOULD include a TTS |
| engine supporting the languages available on the device. Note that the |
| upstream Android open source software includes a full-featured TTS engine |
| implementation. |
| <li>MUST support installation of third-party TTS engines. |
| <li>MUST provide a user-accessible interface that allows users to select a TTS |
| engine for use at the system level. |
| </ul> |
| |
| <h2 id="3_12_tv_input_framework">3.12. TV Input Framework</h2> |
| |
| |
| <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> |
| |
| <p>Device implementations that support TIF MUST declare the platform feature |
| android.software.live_tv.</p> |
| |
| <h3 id="3_12_1_tv_app">3.12.1. TV App</h3> |
| |
| <p>Any device implementation that declares support for Live TV MUST have an |
| installed TV application (TV App). The Android Open Source Project provides an |
| implementation of the TV App.</p> |
| |
| <p>The TV App MUST provide facilities to install and use |
| <a href="http://developer.android.com/reference/android/media/tv/TvContract.Channels.html">TV |
| Channels</a> and meet the following requirements:</p> |
| |
| <ul> |
| <li>Device implementations MUST allow third-party TIF-based inputs |
| (<a href="https://source.android.com/devices/tv/index.html#third-party_input_example">third-party |
| inputs</a>) to be installed and managed.</li> |
| <li>Device implementations MAY provide visual separation between pre-installed |
| <a href="https://source.android.com/devices/tv/index.html#tv_inputs">TIF-based |
| inputs</a> (installed inputs) and third-party inputs.</li> |
| <li>Device implementations MUST NOT display the third-party inputs more than a |
| single navigation action away from the TV App (i.e. expanding a list of |
| third-party inputs from the TV App).</li> |
| </ul> |
| |
| <h4 id="3_12_1_1_electronic_program_guide">3.12.1.1. Electronic Program |
| Guide</h4> |
| |
| <p>Android Television device implementations MUST show an informational and |
| interactive overlay, which MUST include an electronic program guide (EPG) |
| generated from the values in the |
| <a href="https://developer.android.com/reference/android/media/tv/TvContract.Programs.html">TvContract.Programs</a> |
| fields. The EPG MUST meet the following requirements:</p> |
| |
| <ul> |
| <li>The EPG MUST display information from all installed inputs and third-party |
| inputs.</li> |
| <li>The EPG MAY provide visual separation between the installed inputs and |
| third-party inputs.</li> |
| <li>The EPG is STRONGLY RECOMMENDED to display installed inputs and |
| third-party inputs with equal prominence. The EPG MUST NOT display the |
| third-party inputs more than a single navigation action away from the |
| installed inputs on the EPG.</li> |
| <li>On channel change, device implementations MUST display EPG data for the |
| currently playing program.</li> |
| </ul> |
| |
| <h4 id="3_12_1_2_navigation">3.12.1.2. Navigation</h4> |
| |
| <p>Android Television device input devices (i.e. remote control, remote control |
| application, or game controller) MUST allow navigation to all actionable |
| sections of the screen via the D-pad. D-pad up and down MUST be used to change |
| live TV channels when there is no actionable section on the screen.</p> |
| |
| <p>The TV App SHOULD pass key events to HDMI inputs through CEC.</p> |
| |
| <h4 id="3_12_1_3_tv_input_app_linking">3.12.1.3. TV input app linking</h4> |
| |
| <p>Android Television device implementations MUST support |
| <a href="http://developer.android.com/reference/android/media/tv/TvContract.Channels.html#COLUMN_APP_LINK_INTENT_URI">TV |
| input app linking</a>, which allows all inputs to provide activity links from |
| the current activity to another activity (i.e. a link from live programming to |
| related content). The TV App MUST show TV input app linking when it is provided. |
| </p> |
| |
| <h1 id="4_application_packaging_compatibility">4. Application Packaging |
| Compatibility</h1> |
| |
| |
| <p>Device implementations MUST install and run Android “.apk” files |
| as generated by the “aapt” tool included in the |
| <a href="http://developer.android.com/tools/help/index.html">official Android |
| SDK</a>.</p> |
| |
| <p>Devices implementations MUST NOT extend either the |
| <a href="http://developer.android.com/guide/components/fundamentals.html">.apk</a>, |
| <a href="http://developer.android.com/guide/topics/manifest/manifest-intro.html">Android |
| Manifest</a>, <a href="https://android.googlesource.com/platform/dalvik/">Dalvik |
| bytecode</a>, or RenderScript bytecode formats in such a way that would prevent |
| those files from installing and running correctly on other compatible devices. |
| </p> |
| |
| <h1 id="5_multimedia_compatibility">5. Multimedia Compatibility</h1> |
| |
| |
| <h2 id="5_1_media_codecs">5.1. Media Codecs</h2> |
| |
| |
| <p>Device implementations MUST support the |
| <a href="http://developer.android.com/guide/appendix/media-formats.html">core |
| media formats</a> 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 |
| <a href="http://developer.android.com/reference/android/media/MediaCodecList.html">MediaCodecList</a>. |
| Device implementations MUST also be able to decode all profiles reported in its |
| <a href="http://developer.android.com/reference/android/media/CamcorderProfile.html">CamcorderProfile</a> |
| 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.</p> |
| |
| <p>Please note that neither Google nor the Open Handset Alliance make any |
| representation that these codecs are free from third-party patents. Those |
| intending to use this source code in hardware or software products are advised |
| that implementations of this code, including in open source software or |
| shareware, may require patent licenses from the relevant patent holders.</p> |
| |
| <h3 id="5_1_1_audio_codecs">5.1.1. Audio Codecs</h3> |
| |
| <table> |
| <tr> |
| <th>Format/Codec</th> |
| <th>Encoder</th> |
| <th>Decoder</th> |
| <th>Details</th> |
| <th>Supported File Types/Container Formats</th> |
| </tr> |
| <tr> |
| <td>MPEG-4 AAC Profile<br /> |
| |
| (AAC LC)</td> |
| <td>REQUIRED<sup>1</sup></td> |
| <td>REQUIRED</td> |
| <td>Support for mono/stereo/5.0/5.1<sup>2</sup> content with standard |
| sampling rates from 8 to 48 kHz.</td> |
| <td> |
| <ul> |
| <li class="table_list">3GPP (.3gp)</li> |
| <li class="table_list">MPEG-4 (.mp4, .m4a)</li> |
| <li class="table_list">ADTS raw AAC (.aac, decode in Android 3.1+, encode in |
| Android 4.0+, ADIF not supported)</li> |
| <li class="table_list">MPEG-TS (.ts, not seekable, Android 3.0+)</li></ul> |
| </td> |
| </tr> |
| <tr> |
| <td>MPEG-4 HE AAC Profile (AAC+)</td> |
| <td>REQUIRED<sup>1</sup><br>(Android 4.1+)</td> |
| <td>REQUIRED</td> |
| <td>Support for mono/stereo/5.0/5.1<sup>2</sup> content with standard |
| sampling rates from 16 to 48 kHz.</td> |
| <td></td> |
| </tr> |
| <tr> |
| <td>MPEG-4 HE AACv2<br /> |
| |
| Profile (enhanced AAC+)</td> |
| <td> </td> |
| <td>REQUIRED</td> |
| <td>Support for mono/stereo/5.0/5.1<sup>2</sup> content with standard |
| sampling rates from 16 to 48 kHz.</td> |
| <td></td> |
| </tr> |
| <tr> |
| <td>AAC ELD (enhanced low delay AAC)</td> |
| <td>REQUIRED<sup>1</sup> <br /> |
| |
| (Android 4.1+)</td> |
| <td>REQUIRED<br /> |
| |
| (Android 4.1+)</td> |
| <td>Support for mono/stereo content with standard sampling rates from 16 to |
| 48 kHz.</td> |
| <td></td> |
| </tr> |
| <tr> |
| <td>AMR-NB</td> |
| <td>REQUIRED<sup>3</sup></td> |
| <td>REQUIRED<sup>3</sup></td> |
| <td>4.75 to 12.2 kbps sampled @ 8 kHz</td> |
| <td>3GPP (.3gp)</td> |
| </tr> |
| <tr> |
| <td>AMR-WB</td> |
| <td>REQUIRED<sup>3</sup></td> |
| <td>REQUIRED<sup>3</sup></td> |
| <td>9 rates from 6.60 kbit/s to 23.85 kbit/s sampled @ 16 kHz</td> |
| <td></td> |
| </tr> |
| <tr> |
| <td>FLAC</td> |
| <td></td> |
| <td>REQUIRED <br>(Android 3.1+)</td> |
| <td>Mono/Stereo (no multichannel). Sample rates up to 48 kHz (but up to 44.1 |
| kHz is RECOMMENDED on devices with 44.1 kHz output, as the 48 to 44.1 kHz |
| downsampler does not include a low-pass filter). 16-bit RECOMMENDED; no |
| dither applied for 24-bit.</td> |
| <td>FLAC (.flac) only</td> |
| </tr> |
| <tr> |
| <td>MP3</td> |
| <td></td> |
| <td>REQUIRED</td> |
| <td>Mono/Stereo 8-320Kbps constant (CBR) or variable bitrate (VBR)</td> |
| <td>MP3 (.mp3)</td> |
| </tr> |
| <tr> |
| <td>MIDI</td> |
| <td></td> |
| <td>REQUIRED</td> |
| <td>MIDI Type 0 and 1. DLS Version 1 and 2. XMF and Mobile XMF. Support for |
| ringtone formats RTTTL/RTX, OTA, and iMelody</td> |
| <td><ul> |
| <li class="table_list">Type 0 and 1 (.mid, .xmf, .mxmf)</li> |
| <li class="table_list">RTTTL/RTX (.rtttl, .rtx)</li> |
| <li class="table_list">OTA (.ota)</li> |
| <li class="table_list">iMelody (.imy)</li></ul></td> |
| </tr> |
| <tr> |
| <td>Vorbis</td> |
| <td></td> |
| <td>REQUIRED</td> |
| <td></td> |
| <td><ul> |
| <li class="table_list">Ogg (.ogg)</li> |
| <li class="table_list">Matroska (.mkv, Android 4.0+)</li></ul></td> |
| </tr> |
| <tr> |
| <td>PCM/WAVE</td> |
| <td>REQUIRED<sup>4</sup><br> (Android 4.1+)</td> |
| <td>REQUIRED</td> |
| <td>16-bit linear PCM (rates up to limit of hardware). Devices MUST support |
| sampling rates for raw PCM recording at 8000, 11025, 16000, and 44100 Hz |
| frequencies.</td> |
| <td>WAVE (.wav)</td> |
| </tr> |
| <tr> |
| <td>Opus</td> |
| <td></td> |
| <td>REQUIRED<br> (Android 5.0+)</td> |
| <td></td> |
| <td>Matroska (.mkv)</td> |
| </tr> |
| </table> |
| |
| |
| <p class="table_footnote"> 1 Required for device implementations that define |
| 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">3 Required for Android Handheld device |
| implementations.</p> |
| |
| <p class="table_footnote">4 Required for device implementations that define |
| android.hardware.microphone, including Android Watch device implementations.</p> |
| |
| <h3 id="5_1_2_image_codecs">5.1.2. Image Codecs</h3> |
| |
| <table> |
| <tr> |
| <th>Format/Codec</th> |
| <th>Encoder</th> |
| <th>Decoder</th> |
| <th>Details</th> |
| <th>Supported File Types/Container Formats</th> |
| </tr> |
| <tr> |
| <td>JPEG</td> |
| <td>REQUIRED</td> |
| <td>REQUIRED</td> |
| <td>Base+progressive</td> |
| <td>JPEG (.jpg)</td> |
| </tr> |
| <tr> |
| <td>GIF</td> |
| <td></td> |
| <td>REQUIRED</td> |
| <td></td> |
| <td>GIF (.gif)</td> |
| </tr> |
| <tr> |
| <td>PNG</td> |
| <td>REQUIRED</td> |
| <td>REQUIRED</td> |
| <td></td> |
| <td>PNG (.png)</td> |
| </tr> |
| <tr> |
| <td>BMP</td> |
| <td></td> |
| <td>REQUIRED</td> |
| <td></td> |
| <td>BMP (.bmp)</td> |
| </tr> |
| <tr> |
| <td>WebP</td> |
| <td>REQUIRED</td> |
| <td>REQUIRED</td> |
| <td></td> |
| <td>WebP (.webp)</td> |
| </tr> |
| </table> |
| |
| |
| <h3 id="5_1_3_video_codecs">5.1.3. Video Codecs</h3> |
| |
| <table> |
| <tr> |
| <th>Format/Codec</th> |
| <th>Encoder</th> |
| <th>Decoder</th> |
| <th>Details</th> |
| <th>Supported File Types/<br>Container Formats</th> |
| </tr> |
| <tr> |
| <td>H.263</td> |
| <td>REQUIRED<sup>1</sup></td> |
| <td>REQUIRED<sup>2</sup></td> |
| <td></td> |
| <td><ul> |
| <li class="table_list">3GPP (.3gp)</li> |
| <li class="table_list">MPEG-4 (.mp4)</li></ul></td> |
| </tr> |
| <tr> |
| <td>H.264 AVC</td> |
| <td>REQUIRED<sup>2</sup></td> |
| <td>REQUIRED<sup>2</sup></td> |
| <td>See <a href="#5_2_video_encoding">section 5.2 </a>and |
| <a href="#5_3_video_decoding">5.3</a> for details</td> |
| <td><ul> |
| <li class="table_list">3GPP (.3gp)</li> |
| <li class="table_list">MPEG-4 (.mp4)</li> |
| <li class="table_list">MPEG-2 TS (.ts, AAC audio only, not seekable, Android |
| 3.0+)</li></ul></td> |
| </tr> |
| <tr> |
| <td>H.265 HEVC</td> |
| <td></td> |
| <td>REQUIRED<sup>5</sup></td> |
| <td>See <a href="#5_3_video_decoding">section 5.3</a> for details</td> |
| <td>MPEG-4 (.mp4)</td> |
| </tr> |
| <tr> |
| <td>MPEG-2</td> |
| <td></td> |
| <td>STRONGLY RECOMMENDED<sup>6</sup></td> |
| <td>Main Profile</td> |
| <td>MPEG2-TS</td> |
| </tr> |
| <tr> |
| <td>MPEG-4 SP</td> |
| <td></td> |
| <td>REQUIRED<sup>2</sup></td> |
| <td></td> |
| <td>3GPP (.3gp)</td> |
| </tr> |
| <tr> |
| <td>VP8<sup>3</sup></td> |
| <td>REQUIRED<sup>2</sup><br /> |
| |
| (Android 4.3+)</td> |
| <td>REQUIRED<sup>2</sup><br /> |
| |
| (Android 2.3.3+)</td> |
| <td>See <a href="#5_2_video_encoding">section 5.2</a> and |
| <a href="#5_3_video_decoding">5.3</a> for details</td> |
| <td><ul> |
| <li class="table_list"><a href="http://www.webmproject.org/">WebM |
| (.webm)</a></li> |
| <li class="table_list">Matroska (.mkv, Android 4.0+)<sup>4</sup></li></ul> |
| </td> |
| </tr> |
| <tr> |
| <td>VP9</td> |
| <td></td> |
| <td>REQUIRED<sup>2</sup><br> (Android 4.4+)</td> |
| <td>See <a href="#5_3_video_decoding">section 5.3</a> for details</td> |
| <td><ul> |
| <li class="table_list"><a href="http://www.webmproject.org/">WebM |
| (.webm)</a></li> |
| <li class="table_list">Matroska (.mkv, Android 4.0+)<sup>4</sup></li></ul> |
| </td> |
| </tr> |
| </table> |
| |
| |
| <p class="table_footnote">1 Required for device implementations that include |
| camera hardware and define android.hardware.camera or |
| android.hardware.camera.front.</p> |
| |
| <p class="table_footnote">2 Required for device implementations except Android |
| Watch devices. </p> |
| |
| <p class="table_footnote">3 For acceptable quality of web video streaming and |
| video-conference services, device implementations SHOULD use a hardware VP8 |
| codec that meets the |
| <a href="http://www.webmproject.org/hardware/rtc-coding-requirements/">requirements</a>. |
| </p> |
| |
| <p class="table_footnote">4 Device implementations SHOULD support writing |
| Matroska WebM files.</p> |
| |
| <p class="table_footnote">5 STRONGLY RECOMMENDED for Android Automotive, |
| optional for Android Watch, and required for all other device types.</p> |
| |
| <p class="table_footnote">6 Applies only to Android Television device |
| implementations.</p> |
| |
| <h2 id="5_2_video_encoding">5.2. Video Encoding</h2> |
| |
| <div class="note"> |
| <p>Video codecs are optional for Android Watch device implementations.</p> |
| </div> |
| |
| <p>Android device implementations with H.263 encoders MUST support Baseline |
| Profile Level 45.</p> |
| |
| <p>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.</p> |
| <table> |
| <tr> |
| <th></th> |
| <th>SD (Low quality)</th> |
| <th>SD (High quality)</th> |
| <th>HD 720p<sup>1</sup></th> |
| <th>HD 1080p<sup>1</sup></th> |
| </tr> |
| <tr> |
| <th>Video resolution</th> |
| <td>320 x 240 px</td> |
| <td>720 x 480 px</td> |
| <td>1280 x 720 px</td> |
| <td>1920 x 1080 px</td> |
| </tr> |
| <tr> |
| <th>Video frame rate</th> |
| <td>20 fps</td> |
| <td>30 fps</td> |
| <td>30 fps</td> |
| <td>30 fps</td> |
| </tr> |
| <tr> |
| <th>Video bitrate</th> |
| <td>384 Kbps</td> |
| <td>2 Mbps</td> |
| <td>4 Mbps</td> |
| <td>10 Mbps</td> |
| </tr> |
| </table> |
| |
| |
| <p class="table_footnote">1 When supported by hardware, but STRONGLY RECOMMENDED |
| for Android Television devices.</p> |
| |
| <p>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.</p> |
| <table> |
| <tr> |
| <th></th> |
| <th>SD (Low quality)</th> |
| <th>SD (High quality)</th> |
| <th>HD 720p<sup>1</sup></th> |
| <th>HD 1080p<sup>1</sup></th> |
| </tr> |
| <tr> |
| <th>Video resolution</th> |
| <td>320 x 180 px</td> |
| <td>640 x 360 px</td> |
| <td>1280 x 720 px</td> |
| <td>1920 x 1080 px</td> |
| </tr> |
| <tr> |
| <th>Video frame rate</th> |
| <td>30 fps</td> |
| <td>30 fps</td> |
| <td>30 fps</td> |
| <td>30 fps</td> |
| </tr> |
| <tr> |
| <th>Video bitrate</th> |
| <td>800 Kbps </td> |
| <td>2 Mbps</td> |
| <td>4 Mbps</td> |
| <td>10 Mbps</td> |
| </tr> |
| </table> |
| |
| <p class="table_footnote">1 When supported by hardware.</p> |
| |
| <h2 id="5_3_video_decoding">5.3. Video Decoding</h2> |
| |
| <div class="note"> |
| <p>Video codecs are optional for Android Watch device implementations.</p> |
| </div> |
| |
| <p>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.</p> |
| |
| <p>Android device implementations with H.263 decoders MUST support Baseline |
| Profile Level 30.</p> |
| |
| <p>Android device implementations with MPEG-4 decoders MUST support Simple |
| Profile Level 3.</p> |
| |
| <p>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.</p> |
| <table> |
| <tr> |
| <th></th> |
| <th>SD (Low quality)</th> |
| <th>SD (High quality)</th> |
| <th>HD 720p<sup>1</sup></th> |
| <th>HD 1080p<sup>1</sup></th> |
| </tr> |
| <tr> |
| <th>Video resolution</th> |
| <td>320 x 240 px</td> |
| <td>720 x 480 px</td> |
| <td>1280 x 720 px</td> |
| <td>1920 x 1080 px</td> |
| </tr> |
| <tr> |
| <th>Video frame rate</th> |
| <td>30 fps</td> |
| <td>30 fps</td> |
| <td>60 fps</td> |
| <td>30 fps / 60 fps<sup>2</sup></td> |
| </tr> |
| <tr> |
| <th>Video bitrate</th> |
| <td>800 Kbps </td> |
| <td>2 Mbps</td> |
| <td>8 Mbps</td> |
| <td>20 Mbps</td> |
| </tr> |
| </table> |
| |
| |
| <p class="table_footnote">1 REQUIRED for when the height as reported by the |
| Display.getSupportedModes() method is equal or greater than the video resolution.</p> |
| |
| <p class="table_footnote">2 REQUIRED for Android Television device |
| implementations.</p> |
| |
| <p>Android device implementations, when supporting VP8 codec as described in |
| <a href="#5_1_3_video_codecs">section 5.1.3</a>, MUST support the following SD |
| decoding profiles and SHOULD support the HD decoding profiles. Android |
| Television devices MUST support the HD 1080p decoding profile.</p> |
| <table> |
| <tr> |
| <th></th> |
| <th>SD (Low quality)</th> |
| <th>SD (High quality)</th> |
| <th>HD 720p<sup>1</sup></th> |
| <th>HD 1080p<sup>1</sup></th> |
| </tr> |
| <tr> |
| <th>Video resolution</th> |
| <td>320 x 180 px</td> |
| <td>640 x 360 px</td> |
| <td>1280 x 720 px</td> |
| <td>1920 x 1080 px</td> |
| </tr> |
| <tr> |
| <th>Video frame rate</th> |
| <td>30 fps</td> |
| <td>30 fps</td> |
| <td>30 fps / 60 fps<sup>2</sup></td> |
| <td>30 / 60 fps<sup>2</sup></td> |
| </tr> |
| <tr> |
| <th>Video bitrate</th> |
| <td>800 Kbps </td> |
| <td>2 Mbps</td> |
| <td>8 Mbps</td> |
| <td>20 Mbps</td> |
| </tr> |
| </table> |
| |
| <p class="table_footnote">1 REQUIRED for when the height as reported by the |
| Display.getSupportedModes() method is equal or greater than the video resolution.</p> |
| |
| <p class="table_footnote">2 REQUIRED for Android Television device |
| implementations.</p> |
| |
| <p>Android device implementations, when supporting VP9 codec as described in |
| <a href="#5_1_3_video_codecs">section 5.1.3</a>, 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).</p> |
| <table> |
| <tr> |
| <th></th> |
| <th>SD (Low quality)</th> |
| <th>SD (High quality)</th> |
| <th>HD 720p<sup>1</sup></th> |
| <th>HD 1080p<sup>2</sup></th> |
| <th>UHD<sup>2</sup></th> |
| </tr> |
| <tr> |
| <th>Video resolution</th> |
| <td>320 x 180 px</td> |
| <td>640 x 360 px</td> |
| <td>1280 x 720 px</td> |
| <td>1920 x 1080 px</td> |
| <td>3840 x 2160 px</td> |
| </tr> |
| <tr> |
| <th>Video frame rate</th> |
| <td>30 fps</td> |
| <td>30 fps</td> |
| <td>30 fps</td> |
| <td>60 fps</td> |
| <td>60 fps</td> |
| </tr> |
| <tr> |
| <th>Video bitrate</th> |
| <td>600 Kbps</td> |
| <td>1.6 Mbps</td> |
| <td>4 Mbps</td> |
| <td>5 Mbps</td> |
| <td>20 Mbps</td> |
| </tr> |
| </table> |
| |
| |
| <p class="table_footnote">1 Required for Android Television device |
| implementations, but for other type of devices only when supported by hardware. |
| </p> |
| |
| <p class="table_footnote">2 STRONGLY RECOMMENDED for existing Android Television |
| device implementations when supported by hardware.</p> |
| |
| <p>Android device implementations, when supporting H.265 codec as described in |
| <a href="#5_1_3_video_codecs">section 5.1.3</a>, 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 5 Main Tier profile and the UHD decoding profile.</p> |
| <table> |
| <tr> |
| <th></th> |
| <th>SD (Low quality)</th> |
| <th>SD (High quality)</th> |
| <th>HD 720p<sup>1</sup></th> |
| <th>HD 1080p<sup>1</sup></th> |
| <th>UHD<sup>2</sup></th> |
| </tr> |
| <tr> |
| <th>Video resolution</th> |
| <td>352 x 288 px</td> |
| <td>640 x 360 px</td> |
| <td>1280 x 720 px</td> |
| <td>1920 x 1080 px</td> |
| <td>3840 x 2160 px</td> |
| </tr> |
| <tr> |
| <th>Video frame rate</th> |
| <td>30 fps</td> |
| <td>30 fps</td> |
| <td>30 fps</td> |
| <td>60 fps<sup>2</sup></td> |
| <td>60 fps</td> |
| </tr> |
| <tr> |
| <th>Video bitrate</th> |
| <td>600 Kbps </td> |
| <td>1.6 Mbps</td> |
| <td>4 Mbps</td> |
| <td>10 Mbps</td> |
| <td>20 Mbps</td> |
| </tr> |
| </table> |
| |
| |
| <p class="table_footnote">1 Required for Android Television device |
| implementations, but for other type of devices only when supported by hardware. |
| </p> |
| |
| <p class="table_footnote">2 STRONGLY RECOMMENDED for existing Android Television |
| device implementations when supported by hardware.</p> |
| |
| <h2 id="5_4_audio_recording">5.4. Audio Recording</h2> |
| |
| |
| <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> |
| |
| <h3 id="5_4_1_raw_audio_capture">5.4.1. Raw Audio Capture</h3> |
| |
| |
| <p>Device implementations that declare android.hardware.microphone MUST allow |
| capture of raw audio content with the following characteristics:</p> |
| |
| <ul> |
| <li><strong>Format</strong>: Linear PCM, 16-bit |
| <li><strong>Sampling rates</strong>: 8000, 11025, 16000, 44100 |
| <li><strong>Channels</strong>: Mono |
| </ul> |
| |
| <p>The capture for the above sample rates MUST be done without up-sampling, and |
| any down-sampling MUST include an appropriate anti-aliasing filter.</p> |
| |
| <p>Device implementations that declare android.hardware.microphone SHOULD allow |
| capture of raw audio content with the following characteristics:</p> |
| |
| <ul> |
| <li><strong>Format</strong>: Linear PCM, 16-bit |
| <li><strong>Sampling rates</strong>: 22050, 48000 |
| <li><strong>Channels</strong>: Stereo |
| </ul> |
| |
| <p>If capture for the above sample rates is supported, then the capture MUST be |
| done without up-sampling at any ratio higher than 16000:22050 or 44100:48000. |
| Any up-sampling or down-sampling MUST include an appropriate anti-aliasing |
| filter.</p> |
| |
| <h3 id="5_4_2_capture_for_voice_recognition">5.4.2. Capture for Voice |
| Recognition</h3> |
| |
| |
| <p>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:</p> |
| |
| <ul> |
| <li>The device SHOULD exhibit approximately flat amplitude versus frequency |
| characteristics: specifically, ±3 dB, from 100 Hz to 4000 Hz.</li> |
| <li>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.</li> |
| <li>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.</li> |
| <li>Total harmonic distortion SHOULD be less than 1% for 1 kHz at 90 dB SPL |
| input level at the microphone.</li> |
| <li>Noise reduction processing, if present, MUST be disabled.</li> |
| <li>Automatic gain control, if present, MUST be disabled.</li> |
| </ul> |
| |
| <p>If the platform supports noise suppression technologies tuned for speech |
| recognition, the effect MUST be controllable from the |
| android.media.audiofx.NoiseSuppressor API. Moreover, the UUID field for the |
| noise suppressor’s effect descriptor MUST uniquely identify each |
| implementation of the noise suppression technology.</p> |
| |
| <h3 id="5_4_3_capture_for_rerouting_of_playback">5.4.3. Capture for Rerouting of |
| Playback</h3> |
| |
| |
| <p>The android.media.MediaRecorder.AudioSource class includes the REMOTE_SUBMIX |
| audio source. Devices that declare android.hardware.audio.output MUST properly |
| implement the REMOTE_SUBMIX audio source so that when an application uses the |
| android.media.AudioRecord API to record from this audio source, it can capture |
| a mix of all audio streams except for the following:</p> |
| |
| <ul> |
| <li>STREAM_RING |
| <li>STREAM_ALARM |
| <li>STREAM_NOTIFICATION |
| </ul> |
| |
| <h2 id="5_5_audio_playback">5.5. Audio Playback</h2> |
| |
| |
| <p>Device implementations that declare android.hardware.audio.output MUST |
| conform to the requirements in this section.</p> |
| |
| <h3 id="5_5_1_raw_audio_playback">5.5.1. Raw Audio Playback</h3> |
| |
| |
| <p>The device MUST allow playback of raw audio content with the following |
| characteristics:</p> |
| |
| <ul> |
| <li><strong>Format</strong>: Linear PCM, 16-bit</li> |
| <li><strong>Sampling rates</strong>: 8000, 11025, 16000, 22050, 32000, |
| 44100</li> |
| <li><strong>Channels</strong>: Mono, Stereo</li> |
| </ul> |
| |
| <p>The device SHOULD allow playback of raw audio content with the following |
| characteristics:</p> |
| |
| <ul> |
| <li><strong>Sampling rates</strong>: 24000, 48000</li> |
| </ul> |
| |
| <h3 id="5_5_2_audio_effects">5.5.2. Audio Effects</h3> |
| |
| |
| <p>Android provides an |
| <a href="http://developer.android.com/reference/android/media/audiofx/AudioEffect.html">API |
| for audio effects</a> for device implementations. Device implementations that |
| declare the feature android.hardware.audio.output:</p> |
| |
| <ul> |
| <li>MUST support the EFFECT_TYPE_EQUALIZER and EFFECT_TYPE_LOUDNESS_ENHANCER |
| implementations controllable through the AudioEffect subclasses Equalizer, |
| LoudnessEnhancer.</li> |
| <li>MUST support the visualizer API implementation, controllable through the |
| Visualizer class.</li> |
| <li>SHOULD support the EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, |
| EFFECT_TYPE_PRESET_REVERB, and EFFECT_TYPE_VIRTUALIZER implementations |
| controllable through the AudioEffect sub-classes BassBoost, |
| EnvironmentalReverb, PresetReverb, and Virtualizer.</li> |
| </ul> |
| |
| <h3 id="5_5_3_audio_output_volume">5.5.3. Audio Output Volume</h3> |
| |
| |
| <p>Android Television device implementations MUST include support for system |
| Master Volume and digital audio output volume attenuation on supported outputs, |
| except for compressed audio passthrough output (where no audio decoding is done |
| on the device).</p> |
| |
| <h2 id="5_6_audio_latency">5.6. Audio Latency</h2> |
| |
| |
| <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> |
| |
| <p>For the purposes of this section, use the following definitions:</p> |
| |
| <ul> |
| <li><strong>output latency</strong>. 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.</li> |
| <li><strong>cold output latency</strong>. The output latency for the first |
| frame, when the audio output system has been idle and powered down prior to |
| the request.</li> |
| <li><strong>continuous output latency</strong>. The output latency for |
| subsequent frames, after the device is playing audio.</li> |
| <li><strong>input latency</strong>. The interval between when an external |
| sound is presented to the device and when an application reads the |
| corresponding frame of PCM-coded data.</li> |
| <li><strong>cold input latency</strong>. 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.</li> |
| <li><strong>continuous input latency</strong>. The input latency for |
| subsequent frames, while the device is capturing audio.</li> |
| <li><strong>cold output jitter</strong>. The variance among separate |
| measurements of cold output latency values.</li> |
| <li><strong>cold input jitter</strong>. The variance among separate |
| measurements of cold input latency values.</li> |
| <li><strong>continuous round-trip latency</strong>. 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 between input and output streams.</li> |
| <li><strong>OpenSL ES PCM buffer queue API</strong>. The set of PCM-related |
| OpenSL ES APIs within Android NDK; see NDK_root/docs/opensles/index.html.</li> |
| </ul> |
| |
| <p>Device implementations that declare android.hardware.audio.output are |
| STRONGLY RECOMMENDED to meet or exceed these audio output requirements:</p> |
| |
| <ul> |
| <li>cold output latency of 100 milliseconds or less</li> |
| <li>continuous output latency of 45 milliseconds or less</li> |
| <li>minimize the cold output jitter</li> |
| </ul> |
| |
| <p>If a device implementation meets the requirements of this section after any |
| initial calibration when using the OpenSL ES PCM buffer queue API, for |
| continuous output latency and cold output latency over at least one supported |
| audio output device, it is STRONGLY RECOMMENDED to report support for |
| low-latency audio, by reporting the feature android.hardware.audio.low_latency |
| via the |
| <a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">android.content.pm.PackageManager</a> |
| class. Conversely, if the device implementation does not meet these requirements |
| it MUST NOT report support for low-latency audio.</p> |
| |
| <p>Device implementations that include android.hardware.microphone are STRONGLY |
| RECOMMENDED to meet these input audio requirements:</p> |
| |
| <ul> |
| <li>cold input latency of 100 milliseconds or less</li> |
| <li>continuous input latency of 30 milliseconds or less</li> |
| <li>continuous round-trip latency of 50 milliseconds or less</li> |
| <li>minimize the cold input jitter</li> |
| </ul> |
| |
| <h2 id="5_7_network_protocols">5.7. Network Protocols</h2> |
| |
| |
| <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> |
| |
| <ul> |
| <li>RTSP (RTP, SDP)</li> |
| <li>HTTP(S) progressive streaming</li> |
| <li>HTTP(S) |
| <a href="http://tools.ietf.org/html/draft-pantos-http-live-streaming-03">Live |
| Streaming draft protocol, Version 3</a></li> |
| </ul> |
| |
| <h2 id="5_8_secure_media">5.8. Secure Media</h2> |
| |
| |
| <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_midi">5.9. Musical Instrument Digital Interface (MIDI)</h2> |
| |
| <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> |
| |
| <p>The MIDI-capable hardware transports are:</p> |
| <ul> |
| <li>USB host mode (section 7.7 USB)</li> |
| <li>USB peripheral mode (section 7.7 USB)</li> |
| </ul> |
| |
| <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> |
| |
| <p>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.</p> |
| |
| <h2 id="5_10_pro_audio">5.10. Professional Audio</h2> |
| |
| <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> |
| |
| <ul> |
| <li>The device implementation MUST report support for feature |
| android.hardware.audio.low_latency.</li> |
| <li>The continuous round-trip audio latency, as defined in section 5.6 Audio |
| Latency, MUST be 20 milliseconds or less and SHOULD be 10 milliseconds or less |
| over at least one supported path.</li> |
| <li>If the device includes a 4 conductor 3.5mm audio jack, the continuous |
| round-trip audio latency MUST be 20 milliseconds or less over the audio jack |
| path, and SHOULD be 10 milliseconds or less over at the audio jack path.</li> |
| <li>The device implementation MUST include a USB port(s) supporting USB host |
| mode and USB peripheral mode.</li> |
| <li>The USB host mode MUST implement the USB audio class.</li> |
| <li>If the device includes an HDMI port, the device implementation MUST |
| support output in stereo and eight channels at 20-bit or 24-bit depth and 192 |
| kHz without bit-depth loss or resampling.</li> |
| <li>The device implementation MUST report support for feature |
| android.software.midi.</li> |
| <li>If the device includes a 4 conductor 3.5mm audio jack, the device |
| implementation is STRONGLY RECOMMENDED to comply with section |
| <a href="https://source.android.com/accessories/headset/specification.html#mobile_device_jack_specifications">Mobile |
| device (jack) specifications</a> of the |
| <a href="https://source.android.com/accessories/headset/specification.html">Wired |
| Audio Headset Specification (v1.1)</a>.</li> |
| </ul> |
| |
| <h1 id="6_developer_tools_and_options_compatibility">6. Developer Tools and |
| Options Compatibility</h1> |
| |
| <h2 id="6_1_developer_tools">6.1. Developer Tools</h2> |
| |
| <p>Device implementations MUST support the Android Developer Tools provided in |
| the Android SDK. Android compatible devices MUST be compatible with:</p> |
| |
| <ul> |
| <li><a href="http://developer.android.com/tools/help/adb.html"><strong>Android |
| Debug Bridge (adb)</strong></a> |
| <ul> |
| <li>Device implementations MUST support all adb functions as documented in |
| the Android SDK including |
| <a href="https://source.android.com/devices/input/diagnostics.html">dumpsys</a>. |
| </li> |
| <li>The device-side adb daemon MUST be inactive by default and there MUST be |
| a user-accessible mechanism to turn on the Android Debug Bridge. If a device |
| implementation omits USB peripheral mode, it MUST implement the Android |
| Debug Bridge via local-area network (such as Ethernet or 802.11).</li> |
| <li>Android includes support for secure adb. Secure adb enables adb on known |
| authenticated hosts. Device implementations MUST support secure adb.</li> |
| </ul></li> |
| <li><a href="http://developer.android.com/tools/debugging/ddms.html"><strong>Dalvik |
| Debug Monitor Service (ddms)</strong></a> |
| <ul> |
| <li>Device implementations MUST support all ddms features as documented in |
| the Android SDK.</li> |
| <li>As ddms uses adb, support for ddms SHOULD be inactive by default, but |
| MUST be supported whenever the user has activated the Android Debug Bridge, |
| as above.</li> |
| </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.</li> |
| <li><a href="http://developer.android.com/tools/help/systrace.html"><strong>SysTrace</strong></a> |
| <ul> |
| <li>Device implementations MUST support systrace tool as documented in the |
| Android SDK. Systrace must be inactive by default, and there MUST be a |
| user-accessible mechanism to turn on Systrace.</li> |
| <li>Most Linux-based systems and Apple Macintosh systems recognize Android |
| devices using the standard Android SDK tools, without additional support; |
| however Microsoft Windows systems typically require a driver for new Android |
| devices. (For instance, new vendor IDs and sometimes new device IDs require |
| custom USB drivers for Windows systems.)</li> |
| <li>If a device implementation is unrecognized by the adb tool as provided |
| in the standard Android SDK, device implementers MUST provide Windows |
| drivers allowing developers to connect to the device using the adb protocol. |
| These drivers MUST be provided for Windows XP, Windows Vista, Windows 7, |
| Windows 8, and Windows 10 in both 32-bit and 64-bit versions.</li> |
| </ul></li> |
| </ul> |
| |
| <h2 id="6_2_developer_options">6.2. Developer Options</h2> |
| |
| |
| <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> |
| |
| <h1 id="7_hardware_compatibility">7. Hardware Compatibility</h1> |
| |
| |
| <p>If a device includes a particular hardware component that has a corresponding |
| API for third-party developers, the device implementation MUST implement that |
| API as described in the Android SDK documentation. If an API in the SDK |
| interacts with a hardware component that is stated to be optional and the |
| device implementation does not possess that component:</p> |
| |
| <ul> |
| <li>Complete class definitions (as documented by the SDK) for the component |
| APIs MUST still be presented.</li> |
| <li>The API’s behaviors MUST be implemented as no-ops in some reasonable |
| fashion.</li> |
| <li>API methods MUST return null values where permitted by the SDK |
| documentation.</li> |
| <li>API methods MUST return no-op implementations of classes where null values |
| are not permitted by the SDK documentation.</li> |
| <li>API methods MUST NOT throw exceptions not documented by the SDK |
| documentation.</li> |
| </ul> |
| |
| <p>A typical example of a scenario where these requirements apply is the |
| telephony API: Even on non-phone devices, these APIs must be implemented as |
| reasonable no-ops.</p> |
| |
| <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">7.1. Display and Graphics</h2> |
| |
| |
| <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> |
| |
| <p>The units referenced by the requirements in this section are defined as |
| follows:</p> |
| |
| <ul> |
| <li><strong>physical diagonal size</strong>. The distance in inches between |
| two opposing corners of the illuminated portion of the display.</li> |
| <li><strong>dots per inch (dpi)</strong>. The number of pixels encompassed by |
| a linear horizontal or vertical span of 1”. Where dpi values are listed, |
| both horizontal and vertical dpi must fall within the range.</li> |
| <li><strong>aspect ratio</strong>. The ratio of the pixels of the longer |
| dimension to the shorter dimension of the screen. For example, a display of |
| 480x854 pixels would be 854/480 = 1.779, or roughly “16:9”.</li> |
| <li><strong>density-independent pixel (dp)</strong>. The virtual pixel unit |
| normalized to a 160 dpi screen, calculated as: pixels = dps * (density/160). |
| </li> |
| </ul> |
| |
| <h3 id="7_1_1_screen_configuration">7.1.1. Screen Configuration</h3> |
| |
| |
| <h4 id="7_1_1_1_screen_size">7.1.1.1. Screen Size</h4> |
| |
| <div class="note"> |
| <p>Android Watch devices (detailed in <a href="#2_device_types">section 2</a>) |
| MAY have smaller screen sizes as described in this section.</p> |
| </div> |
| |
| <p>The Android UI framework supports a variety of different screen sizes, and |
| allows applications to query the device screen size (aka “screen layout") |
| via android.content.res.Configuration.screenLayout with the |
| SCREENLAYOUT_SIZE_MASK. Device implementations MUST report the correct |
| <a href="http://developer.android.com/guide/practices/screens_support.html">screen |
| size</a> as defined in the Android SDK documentation and determined by the |
| upstream Android platform. Specifically, device implementations MUST report the |
| correct screen size according to the following logical density-independent pixel |
| (dp) screen dimensions.</p> |
| |
| <ul> |
| <li>Devices MUST have screen sizes of at least 426 dp x 320 dp |
| (‘small’), unless it is an Android Watch device.</li> |
| <li>Devices that report screen size ‘normal’ MUST have screen |
| sizes of at least 480 dp x 320 dp.</li> |
| <li>Devices that report screen size ‘large’ MUST have screen sizes |
| of at least 640 dp x 480 dp.</li> |
| <li>Devices that report screen size ‘xlarge’ MUST have screen |
| sizes of at least 960 dp x 720 dp.</li> |
| </ul> |
| |
| <p>In addition:</p> |
| |
| <ul> |
| <li>Android Watch devices MUST have a screen with the physical diagonal size |
| in the range from 1.1 to 2.5 inches.</li> |
| <li>Other types of Android device implementations, with a physically |
| integrated screen, MUST have a screen at least 2.5 inches in physical diagonal |
| size.</li> |
| </ul> |
| |
| <p>Devices MUST NOT change their reported screen size at any time.</p> |
| |
| <p>Applications optionally indicate which screen sizes they support via the |
| <supports-screens> attribute in the AndroidManifest.xml file. Device |
| implementations MUST correctly honor applications' stated support for small, |
| normal, large, and xlarge screens, as described in the Android SDK |
| documentation.</p> |
| |
| <h4 id="7_1_1_2_screen_aspect_ratio">7.1.1.2. Screen Aspect Ratio</h4> |
| |
| <div class="note"> |
| <p>Android Watch devices MAY have an aspect ratio of 1.0 (1:1).</p> |
| </div> |
| |
| |
| <p>The screen aspect ratio MUST be a value from 1.3333 (4:3) to 1.86 (roughly |
| 16:9), but Android Watch devices MAY have an aspect ratio of 1.0 (1:1) because |
| such a device implementation will use a UI_MODE_TYPE_WATCH as the |
| android.content.res.Configuration.uiMode.</p> |
| |
| <h4 id="7_1_1_3_screen_density">7.1.1.3. Screen Density</h4> |
| |
| |
| <p>The Android UI framework defines a set of standard logical densities to help |
| application developers target application resources. Device implementations |
| MUST report only one of the following logical Android framework densities |
| through the android.util.DisplayMetrics APIs, and MUST execute applications at |
| this standard density and MUST NOT change the value at at any time for the |
| default display.</p> |
| |
| <ul> |
| <li>120 dpi (ldpi)</li> |
| <li>160 dpi (mdpi)</li> |
| <li>213 dpi (tvdpi)</li> |
| <li>240 dpi (hdpi)</li> |
| <li>280 dpi (280dpi)</li> |
| <li>320 dpi (xhdpi)</li> |
| <li>360 dpi (360dpi)</li> |
| <li>400 dpi (400dpi)</li> |
| <li>420 dpi (420dpi)</li> |
| <li>480 dpi (xxhdpi)</li> |
| <li>560 dpi (560dpi)</li> |
| <li>640 dpi (xxxhdpi)</li> |
| </ul> |
| |
| <p>Device implementations SHOULD define the standard Android framework density |
| that is numerically closest to the physical density of the screen, unless that |
| logical density pushes the reported screen size below the minimum supported. If |
| the standard Android framework density that is numerically closest to the |
| physical density results in a screen size that is smaller than the smallest |
| supported compatible screen size (320 dp width), device implementations SHOULD |
| report the next lowest standard Android framework density.</p> |
| |
| <h3 id="7_1_2_display_metrics">7.1.2. Display Metrics</h3> |
| |
| |
| <p>Device implementations MUST report correct values for all display metrics |
| defined in |
| <a href="http://developer.android.com/reference/android/util/DisplayMetrics.html">android.util.DisplayMetrics</a> |
| and MUST report the same values regardless of whether the embedded or external |
| screen is used as the default display.</p> |
| |
| <h3 id="7_1_3_screen_orientation">7.1.3. Screen Orientation</h3> |
| |
| |
| <p>Devices MUST report which screen orientations they support |
| (android.hardware.screen.portrait and/or android.hardware.screen.landscape) and |
| MUST report at least one supported orientation. For example, a device with a |
| fixed orientation landscape screen, such as a television or laptop, SHOULD only |
| report android.hardware.screen.landscape.</p> |
| |
| <p>Devices that report both screen orientations MUST support dynamic orientation |
| by applications to either portrait or landscape screen orientation. That is, |
| the device must respect the application’s request for a specific screen |
| orientation. Device implementations MAY select either portrait or landscape |
| orientation as the default.</p> |
| |
| <p>Devices MUST report the correct value for the device’s current |
| orientation, whenever queried via the |
| android.content.res.Configuration.orientation, |
| android.view.Display.getOrientation(), or other APIs.</p> |
| |
| <p>Devices MUST NOT change the reported screen size or density when changing |
| orientation.</p> |
| |
| <h3 id="7_1_4_2d_and_3d_graphics_acceleration">7.1.4. 2D and 3D Graphics |
| Acceleration</h3> |
| |
| |
| <p>Device implementations MUST support both OpenGL ES 1.0 and 2.0, as embodied |
| and detailed in the Android SDK documentations. Device implementations SHOULD |
| support OpenGL ES 3.0 or 3.1 on devices capable of supporting it. Device |
| implementations MUST also support |
| <a href="http://developer.android.com/guide/topics/renderscript/">Android |
| RenderScript</a>, as detailed in the Android SDK documentation.</p> |
| |
| <p>Device implementations MUST also correctly identify themselves as supporting |
| OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0 or OpenGL 3.1. That is:</p> |
| |
| <ul> |
| <li>The managed APIs (such as via the GLES10.getString() method) MUST report |
| support for OpenGL ES 1.0 and OpenGL ES 2.0.</li> |
| <li>The native C/C++ OpenGL APIs (APIs available to apps via libGLES_v1CM.so, |
| libGLES_v2.so, or libEGL.so) MUST report support for OpenGL ES 1.0 and OpenGL |
| ES 2.0.</li> |
| <li>Device implementations that declare support for OpenGL ES 3.0 or 3.1 MUST |
| support the corresponding managed APIs and include support for native C/C++ |
| APIs. On device implementations that declare support for OpenGL ES 3.0 or 3.1, |
| libGLESv2.so MUST export the corresponding function symbols in addition to the |
| OpenGL ES 2.0 function symbols.</li> |
| </ul> |
| |
| <p>In addition to OpenGL ES 3.1, Android provides an |
| <a href="https://developer.android.com/reference/android/opengl/GLES31Ext.html">extension |
| pack</a> with Java interfaces and native support for advanced graphics |
| functionality such as tessellation and the ASTC texture compression format. |
| Android device implementations MAY support this extension pack, and—only |
| if fully implemented—MUST identify the support through the |
| android.hardware.opengles.aep feature flag.</p> |
| |
| <p>Also, device implementations MAY implement any desired OpenGL ES extensions. |
| However, device implementations MUST report via the OpenGL ES managed and |
| native APIs all extension strings that they do support, and conversely MUST NOT |
| report extension strings that they do not support.</p> |
| |
| <p>Note that Android includes support for applications to optionally specify |
| that they require specific OpenGL texture compression formats. These formats are |
| typically vendor-specific. Device implementations are not required by Android |
| to implement any specific texture compression format. However, they SHOULD |
| accurately report any texture compression formats that they do support, via the |
| getString() method in the OpenGL API.</p> |
| |
| <p>Android includes a mechanism for applications to declare that they want to |
| enable hardware acceleration for 2D graphics at the Application, Activity, |
| Window, or View level through the use of a manifest tag |
| <a href="http://developer.android.com/guide/topics/graphics/hardware-accel.html">android:hardwareAccelerated</a> |
| or direct API calls.</p> |
| |
| <p>Device implementations MUST enable hardware acceleration by default, and MUST |
| disable hardware acceleration if the developer so requests by setting |
| android:hardwareAccelerated="false” or disabling hardware acceleration |
| directly through the Android View APIs.</p> |
| |
| <p>In addition, device implementations MUST exhibit behavior consistent with the |
| Android SDK documentation on |
| <a href="http://developer.android.com/guide/topics/graphics/hardware-accel.html">hardware |
| acceleration</a>.</p> |
| |
| <p>Android includes a TextureView object that lets developers directly integrate |
| hardware-accelerated OpenGL ES textures as rendering targets in a UI hierarchy. |
| Device implementations MUST support the TextureView API, and MUST exhibit |
| consistent behavior with the upstream Android implementation.</p> |
| |
| <p>Android includes support for EGL_ANDROID_RECORDABLE, an EGLConfig attribute |
| that indicates whether the EGLConfig supports rendering to an ANativeWindow |
| that records images to a video. Device implementations MUST support |
| <a href="https://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt">EGL_ANDROID_RECORDABLE</a> |
| extension.</p> |
| |
| <h3 id="7_1_5_legacy_application_compatibility_mode">7.1.5. Legacy Application |
| Compatibility Mode</h3> |
| |
| |
| <p>Android specifies a “compatibility mode” in which the framework |
| operates in a 'normal' screen size equivalent (320dp width) mode for the benefit |
| of legacy applications not developed for old versions of Android that pre-date |
| screen-size independence.</p> |
| |
| <ul> |
| <li>Android Automotive does not support legacy compatibility mode.</li> |
| <li>All other device implementations MUST include support for legacy |
| application compatibility mode as implemented by the upstream Android open |
| source code. That is, device implementations MUST NOT alter the triggers or |
| thresholds at which compatibility mode is activated, and MUST NOT alter the |
| behavior of the compatibility mode itself.</li> |
| </ul> |
| |
| <h3 id="7_1_6_screen_technology">7.1.6. Screen Technology</h3> |
| |
| |
| <p>The Android platform includes APIs that allow applications to render rich |
| graphics to the display. Devices MUST support all of these APIs as defined by |
| the Android SDK unless specifically allowed in this document. </p> |
| |
| <ul> |
| <li>Devices MUST support displays capable of rendering 16-bit color graphics |
| and SHOULD support displays capable of 24-bit color graphics.</li> |
| <li>Devices MUST support displays capable of rendering animations.</li> |
| <li>The display technology used MUST have a pixel aspect ratio (PAR) between |
| 0.9 and 1.15. That is, the pixel aspect ratio MUST be near square (1.0) with a |
| 10 ~ 15% tolerance.</li> |
| </ul> |
| |
| <h3 id="7_1_7_external_displays">7.1.7. Secondary Displays</h3> |
| |
| |
| <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">7.2. Input Devices</h2> |
| |
| <p>Devices MUST support a touchscreen or meet the requirements listed in 7.2.2 |
| for non-touch navigation.</p> |
| |
| <h3 id="7_2_1_keyboard">7.2.1. Keyboard</h3> |
| |
| <div class="note"> |
| <p>Android Watch and Android Automotive implementations MAY implement a soft |
| keyboard. All other device implementations MUST implement a soft keyboard and:</p> |
| </div> |
| |
| |
| <p>Device implementations:</p> |
| |
| <ul> |
| <li>MUST include support for the Input Management Framework (which allows |
| third-party developers to create Input Method Editors—i.e. soft |
| keyboard) as detailed at |
| <a href="http://developer.android.com">http://developer.android.com</a>.</li> |
| <li>MUST provide at least one soft keyboard implementation (regardless of |
| whether a hard keyboard is present) except for Android Watch devices where the |
| screen size makes it less reasonable to have a soft keyboard.</li> |
| <li>MAY include additional soft keyboard implementations.</li> |
| <li>MAY include a hardware keyboard.</li> |
| <li>MUST NOT include a hardware keyboard that does not match one of the |
| formats specified in |
| <a href="http://developer.android.com/reference/android/content/res/Configuration.html">android.content.res.Configuration.keyboard</a> |
| (QWERTY or 12-key).</li> |
| </ul> |
| |
| <h3 id="7_2_2_non-touch_navigation">7.2.2. Non-touch Navigation</h3> |
| |
| <div class="note"> |
| <p>Android Television devices MUST support D-pad.</p> |
| </div> |
| |
| <p>Device implementations:</p> |
| |
| <ul> |
| <li>MAY omit a non-touch navigation option (trackball, d-pad, or wheel) if the |
| device implementation is not an Android Television device.</li> |
| <li>MUST report the correct value for |
| <a href="http://developer.android.com/reference/android/content/res/Configuration.html">android.content.res.Configuration.navigation</a>. |
| </li> |
| <li>MUST provide a reasonable alternative user interface mechanism for the |
| selection and editing of text, compatible with Input Management Engines. The |
| upstream Android open source implementation includes a selection mechanism |
| suitable for use with devices that lack non-touch navigation inputs.</li> |
| </ul> |
| |
| <h3 id="7_2_3_navigation_keys">7.2.3. Navigation Keys</h3> |
| |
| <div class="note"> |
| <p>The availability and visibility requirement of the Home, Recents, and Back |
| functions differ between device types as described in this section.</p> |
| </div> |
| |
| <p>The Home, Recents, and Back functions (mapped to the key events KEYCODE_HOME, |
| KEYCODE_APP_SWITCH, KEYCODE_BACK, respectively) are essential to the Android |
| navigation paradigm and therefore:</p> |
| |
| <ul> |
| <li>Android Handheld device implementations MUST provide the Home, Recents, |
| and Back functions.</li> |
| <li>Android Television device implementations MUST provide the Home and Back |
| functions.</li> |
| <li>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.</li> |
| <li>Android Automotive implementations MUST provide the Home function and MAY |
| provide Back and Recent functions.</li> |
| <li>All other types of device implementations MUST provide the Home and Back |
| functions.</li> |
| </ul> |
| |
| <p>These functions MAY be implemented via dedicated physical buttons (such as |
| mechanical or capacitive touch buttons), or MAY be implemented using dedicated |
| software keys on a distinct portion of the screen, gestures, touch panel, etc. |
| Android supports both implementations. All of these functions MUST be |
| accessible with a single action (e.g. tap, double-click or gesture) when |
| visible.</p> |
| |
| <p>Recents function, if provided, MUST have a visible button or icon unless |
| hidden together with other navigation functions in full-screen mode. This does |
| not apply to devices upgrading from earlier Android versions that have physical |
| buttons for navigation and no recents key.</p> |
| |
| <p>The Home and Back functions, if provided, MUST each have a visible button or |
| icon unless hidden together with other navigation functions in full-screen mode |
| or when the uiMode UI_MODE_TYPE_MASK is set to UI_MODE_TYPE_WATCH.</p> |
| |
| <p>The Menu function is deprecated in favor of action bar since Android 4.0. |
| Therefore the new device implementations shipping with Android 6.0 |
| and later MUST NOT implement a dedicated physical button for the Menu function. |
| Older device implementations SHOULD NOT implement a dedicated physical button |
| for the Menu function, but if the physical Menu button is implemented and the |
| device is running applications with targetSdkVersion > 10, the device |
| implementation:</p> |
| |
| <ul> |
| <li>MUST display the action overflow button on the action bar when it is |
| visible and the resulting action overflow menu popup is not empty. For a |
| device implementation launched before Android 4.4 but upgrading to Android |
| 6.0, this is RECOMMENDED.</li> |
| <li>MUST NOT modify the position of the action overflow popup displayed by |
| selecting the overflow button in the action bar.</li> |
| <li>MAY render the action overflow popup at a modified position on the screen |
| when it is displayed by selecting the physical menu button.</li> |
| </ul> |
| |
| <p>For backwards compatibility, device implementations MUST make the Menu |
| function available to applications when targetSdkVersion is less than 10, either |
| by a physical button, a software key, or gestures. This Menu function should be |
| presented unless hidden together with other navigation functions.</p> |
| |
| <p>Android device implementations with the support of the |
| <a href="http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST">Assist |
| action</a> MUST make this accessisble with a single action (e.g. tap, |
| double-click, or gesture) when other navigation keys are visible, and are |
| STRONGLY RECOMMENDED to use the long-press on the Home button or software key as |
| the single action.</p> |
| |
| <p>Device implementations MAY use a distinct portion of the screen to display |
| the navigation keys, but if so, MUST meet these requirements:</p> |
| |
| <ul> |
| <li>Device implementation navigation keys MUST use a distinct portion of the |
| screen, not available to applications, and MUST NOT obscure or otherwise |
| interfere with the portion of the screen available to applications.</li> |
| <li>Device implementations MUST make available a portion of the display to |
| applications that meets the requirements defined in |
| <a href="#7_1_1_screen_configuration">section 7.1.1</a>.</li> |
| <li>Device implementations MUST display the navigation keys when applications |
| do not specify a system UI mode, or specify SYSTEM_UI_FLAG_VISIBLE.</li> |
| <li>Device implementations MUST present the navigation keys in an unobtrusive |
| “low profile” (eg. dimmed) mode when applications specify |
| SYSTEM_UI_FLAG_LOW_PROFILE.</li> |
| <li>Device implementations MUST hide the navigation keys when applications |
| specify SYSTEM_UI_FLAG_HIDE_NAVIGATION.</li> |
| </ul> |
| |
| <h3 id="7_2_4_touchscreen_input">7.2.4. Touchscreen Input</h3> |
| |
| <div class="note"> |
| <p>Android Handhelds and Watch Devices MUST support touchscreen input.</p> |
| </div> |
| |
| |
| <p>Device implementations SHOULD have a pointer input system of some kind |
| (either mouse-like or touch). However, if a device implementation does not |
| support a pointer input system, it MUST NOT report the |
| android.hardware.touchscreen or android.hardware.faketouch feature constant. |
| Device implementations that do include a pointer input system:</p> |
| |
| <ul> |
| <li>SHOULD support fully independently tracked pointers, if the device input |
| system supports multiple pointers.</li> |
| <li>MUST report the value of |
| <a href="http://developer.android.com/reference/android/content/res/Configuration.html">android.content.res.Configuration.touchscreen</a> |
| corresponding to the type of the specific touchscreen on the device.</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>.</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>.</p> |
| |
| <h3 id="7_2_5_fake_touch_input">7.2.5. Fake Touch Input</h3> |
| |
| |
| <p>Device implementations that declare support for android.hardware.faketouch:</p> |
| |
| <ul> |
| <li>MUST report the |
| <a href="http://developer.android.com/reference/android/view/MotionEvent.html">absolute |
| X and Y screen positions</a>of the pointer location and display a visual |
| pointer on the screen.</li> |
| <li>MUST report touch event with the action code that specifies the state |
| change that occurs on the pointer |
| <a href="http://developer.android.com/reference/android/view/MotionEvent.html">going |
| down or up on the screen</a>.</li> |
| <li>MUST support pointer down and up on an object on the screen, which allows |
| users to emulate tap on an object on the screen.</li> |
| <li>MUST support pointer down, pointer up, pointer down then pointer up in the |
| same place on an object on the screen within a time threshold, which allows |
| users to |
| <a href="http://developer.android.com/reference/android/view/MotionEvent.html">emulate |
| double tap</a> on an object on the screen.</li> |
| <li>MUST support pointer down on an arbitrary point on the screen, pointer |
| move to any other arbitrary point on the screen, followed by a pointer up, |
| which allows users to emulate a touch drag.</li> |
| <li>MUST support pointer down then allow users to quickly move the object to a |
| different position on the screen and then pointer up on the screen, which |
| allows users to fling an object on the screen.</li> |
| </ul> |
| |
| <p>Devices that declare support for |
| android.hardware.faketouch.multitouch.distinct MUST meet the requirements for |
| faketouch above, and MUST also support distinct tracking of two or more |
| independent pointer inputs.</p> |
| |
| <h3 id="7_2_6_game_controller_support">7.2.6. Game Controller Support</h3> |
| |
| |
| <p>Android Television device implementations MUST support button mappings for game |
| controllers as listed below. The upstream Android implementation includes |
| implementation for game controllers that satisfies this requirement. </p> |
| |
| <h4 id="7_2_6_1_button_mappings">7.2.6.1. Button Mappings</h4> |
| |
| |
| <p>Android Television device implementations MUST support the following key |
| mappings:</p> |
| <table> |
| <tr> |
| <th>Button</th> |
| <th>HID Usage<sup>2</sup></th> |
| <th>Android Button</th> |
| </tr> |
| <tr> |
| <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_A">A</a><sup>1</sup></td> |
| <td>0x09 0x0001</td> |
| <td>KEYCODE_BUTTON_A (96)</td> |
| </tr> |
| <tr> |
| <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_B">B</a><sup>1</sup></td> |
| <td>0x09 0x0002</td> |
| <td>KEYCODE_BUTTON_B (97)</td> |
| </tr> |
| <tr> |
| <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_X">X</a><sup>1</sup></td> |
| <td>0x09 0x0004</td> |
| <td>KEYCODE_BUTTON_X (99)</td> |
| </tr> |
| <tr> |
| <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_Y">Y</a><sup>1</sup></td> |
| <td>0x09 0x0005</td> |
| <td>KEYCODE_BUTTON_Y (100)</td> |
| </tr> |
| <tr> |
| <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_DPAD_UP">D-pad up</a><sup>1</sup><br /> |
| |
| <a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_DPAD_DOWN">D-pad down</a><sup>1</sup></td> |
| <td>0x01 0x0039<sup>3</sup></td> |
| <td><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_HAT_Y">AXIS_HAT_Y</a><sup>4</sup></td> |
| </tr> |
| <tr> |
| <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_DPAD_LEFT">D-pad left</a>1<br /> |
| |
| <a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_DPAD_RIGHT">D-pad right</a><sup>1</sup></td> |
| <td>0x01 0x0039<sup>3</sup></td> |
| <td><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_HAT_X">AXIS_HAT_X</a><sup>4</sup></td> |
| </tr> |
| <tr> |
| <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_L1">Left shoulder button</a><sup>1</sup></td> |
| <td>0x09 0x0007</td> |
| <td>KEYCODE_BUTTON_L1 (102)</td> |
| </tr> |
| <tr> |
| <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_R1">Right shoulder button</a><sup>1</sup></td> |
| <td>0x09 0x0008</td> |
| <td>KEYCODE_BUTTON_R1 (103)</td> |
| </tr> |
| <tr> |
| <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_THUMBL">Left stick click</a><sup>1</sup></td> |
| <td>0x09 0x000E</td> |
| <td>KEYCODE_BUTTON_THUMBL (106)</td> |
| </tr> |
| <tr> |
| <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_THUMBR">Right stick click</a><sup>1</sup></td> |
| <td>0x09 0x000F</td> |
| <td>KEYCODE_BUTTON_THUMBR (107)</td> |
| </tr> |
| <tr> |
| <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_HOME">Home</a><sup>1</sup></td> |
| <td>0x0c 0x0223</td> |
| <td>KEYCODE_HOME (3)</td> |
| </tr> |
| <tr> |
| <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK">Back</a><sup>1</sup></td> |
| <td>0x0c 0x0224</td> |
| <td>KEYCODE_BACK (4)</td> |
| </tr> |
| </table> |
| |
| |
| <p class="table_footnote">1 <a href="http://developer.android.com/reference/android/view/KeyEvent.html">KeyEvent</a></p> |
| |
| <p class="table_footnote">2 The above HID usages must be declared within a Game pad CA (0x01 0x0005).</p> |
| |
| <p class="table_footnote">3 This usage must have a Logical Minimum of 0, a |
| Logical Maximum of 7, a Physical Minimum of 0, a Physical Maximum of 315, Units |
| in Degrees, and a Report Size of 4. The logical value is defined to be the |
| clockwise rotation away from the vertical axis; for example, a logical value of |
| 0 represents no rotation and the up button being pressed, while a logical value |
| of 1 represents a rotation of 45 degrees and both the up and left keys being |
| pressed.</p> |
| |
| <p class="table_footnote">4 <a href="http://developer.android.com/reference/android/view/MotionEvent.html">MotionEvent</a></p> |
| |
| <table> |
| <tr> |
| <th>Analog Controls<sup>1</sup></th> |
| <th>HID Usage</th> |
| <th>Android Button</th> |
| </tr> |
| <tr> |
| <td><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_LTRIGGER">Left Trigger</a></td> |
| <td>0x02 0x00C5</td> |
| <td>AXIS_LTRIGGER </td> |
| </tr> |
| <tr> |
| <td><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_THROTTLE">Right Trigger</a></td> |
| <td>0x02 0x00C4</td> |
| <td>AXIS_RTRIGGER </td> |
| </tr> |
| <tr> |
| <td><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_Y">Left Joystick</a></td> |
| <td>0x01 0x0030<br /> |
| |
| 0x01 0x0031</td> |
| <td>AXIS_X<br /> |
| |
| AXIS_Y</td> |
| </tr> |
| <tr> |
| <td><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_Z">Right Joystick</a></td> |
| <td>0x01 0x0032<br /> |
| |
| 0x01 0x0035</td> |
| <td>AXIS_Z<br /> |
| |
| AXIS_RZ</td> |
| </tr> |
| </table> |
| |
| |
| <p class="table_footnote">1 <a href="http://developer.android.com/reference/android/view/MotionEvent.html">MotionEvent</a></p> |
| |
| <h3 id="7_2_7_remote_control">7.2.7. Remote Control</h3> |
| |
| |
| <p>Android Television device implementations SHOULD provide a remote control to |
| allow users to access the TV interface. The remote control MAY be a physical |
| remote or can be a software-based remote that is accessible from a mobile phone |
| or tablet. The remote control MUST meet the requirements defined below.</p> |
| |
| <ul> |
| <li><strong>Search affordance</strong>. Device implementations MUST fire |
| KEYCODE_SEARCH when the user invokes voice search either on the physical or |
| software-based remote.</li> |
| <li><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">7.3. Sensors</h2> |
| |
| |
| <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> |
| |
| <ul> |
| <li>MUST accurately report the presence or absence of sensors per the |
| <a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">android.content.pm.PackageManager</a> |
| class.</li> |
| <li>MUST return an accurate list of supported sensors via the |
| SensorManager.getSensorList() and similar methods.</li> |
| <li>MUST behave reasonably for all other sensor APIs (for example, by |
| returning true or false as appropriate when applications attempt to register |
| listeners, not calling sensor listeners when the corresponding sensors are not |
| present; etc.).</li> |
| <li>MUST |
| <a href="http://developer.android.com/reference/android/hardware/SensorEvent.html">report |
| all sensor measurements</a> using the relevant International System of Units |
| (metric) values for each sensor type as defined in the Android SDK |
| documentation.</li> |
| <li>SHOULD |
| <a href="http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp">report |
| the event time</a> in nanoseconds as defined in the Android SDK documentation, |
| representing the time the event happened and synchronized with the |
| SystemClock.elapsedRealtimeNano() clock. Existing and new Android devices are |
| <strong>STRONGLY RECOMMENDED</strong> to meet these requirements so they will |
| be able to upgrade to the future platform releases where this might become a |
| REQUIRED component. The synchronization error SHOULD be below 100 |
| milliseconds.</li> |
| <li>MUST report sensor data with a maximum latency of 100 milliseconds + 2 * |
| sample_time for the case of a sensor streamed with a minimum required latency |
| of 5 ms + 2 * sample_time when the application processor is active. This delay |
| does not include any filtering delays.</li> |
| <li>MUST report the first sensor sample within 400 milliseconds + 2 * |
| sample_time of the sensor being activated. It is acceptable for this sample to |
| have an accuracy of 0.</li> |
| </ul> |
| |
| <p>The list above is not comprehensive; the documented behavior of the Android |
| SDK and the Android Open Source Documentations on |
| <a href="http://source.android.com/devices/sensors/">sensors</a> is to be |
| considered authoritative.</p> |
| |
| <p>Some sensor types are composite, meaning they can be derived from data |
| provided by one or more other sensors. (Examples include the orientation sensor |
| and the linear acceleration sensor.) Device implementations SHOULD implement |
| these sensor types, when they include the prerequisite physical sensors as |
| described in |
| <a href="https://source.android.com/devices/sensors/sensor-types.html">sensor |
| types</a>. If a device implementation includes a composite sensor it MUST |
| implement the sensor as described in the Android Open Source documentation on |
| <a href="https://source.android.com/devices/sensors/sensor-types.html#composite_sensor_type_summary">composite |
| sensors</a>.</p> |
| |
| <p>Some Android sensors support a |
| <a href="https://source.android.com/devices/sensors/report-modes.html#continuous">“continuous” |
| trigger mode</a>, which returns data continuously. For any API indicated by the |
| Android SDK documentation to be a continuous sensor, device implementations MUST |
| continuously provide periodic data samples that SHOULD have a jitter below 3%, |
| where jitter is defined as the standard deviation of the difference of the |
| reported timestamp values between consecutive events.</p> |
| |
| <p>Note that the device implementations MUST ensure that the sensor event stream |
| MUST NOT prevent the device CPU from entering a suspend state or waking up from |
| a suspend state.</p> |
| |
| <p>Finally, when several sensors are activated, the power consumption SHOULD NOT |
| exceed the sum of the individual sensor’s reported power consumption.</p> |
| |
| <h3 id="7_3_1_accelerometer">7.3.1. Accelerometer</h3> |
| |
| |
| <p>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: |
| </p> |
| |
| <ul> |
| <li>MUST implement and report |
| <a href="http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER">TYPE_ACCELEROMETER sensor</a>. |
| </li> |
| <li>MUST be able to report events up to a frequency of at least 50 Hz for |
| Android Watch devices as such devices have a stricter power constraint and |
| 100 Hz for all other device types.</li> |
| <li>SHOULD report events up to at least 200 Hz.</li> |
| <li>MUST comply with the |
| <a href="http://developer.android.com/reference/android/hardware/SensorEvent.html">Android |
| sensor coordinate system</a> as detailed in the Android APIs.</li> |
| <li>MUST be capable of measuring from freefall up to four times the gravity |
| (4g) or more on any axis.</li> |
| <li>MUST have a resolution of at least 12-bits and SHOULD have a resolution of |
| at least 16-bits.</li> |
| <li>SHOULD be calibrated while in use if the characteristics changes over the |
| life cycle and compensated, and preserve the compensation parameters between |
| device reboots.</li> |
| <li>SHOULD be temperature compensated.</li> |
| <li>MUST have a standard deviation no greater than 0.05 m/s^, where the |
| standard deviation should be calculated on a per axis basis on samples |
| collected over a period of at least 3 seconds at the fastest sampling rate. |
| </li> |
| <li>SHOULD implement the TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR, |
| TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER composite sensors as described in the |
| Android SDK document. Existing and new Android devices are <strong>STRONGLY |
| RECOMMENDED</strong> to implement the TYPE_SIGNIFICANT_MOTION composite |
| sensor. If any of these sensors are implemented, the sum of their power |
| consumption MUST always be less than 4 mW and SHOULD each be below 2 mW and |
| 0.5 mW for when the device is in a dynamic or static condition.</li> |
| <li>If a gyroscope sensor is included, MUST implement the TYPE_GRAVITY and |
| TYPE_LINEAR_ACCELERATION composite sensors and SHOULD implement the |
| TYPE_GAME_ROTATION_VECTOR composite sensor. Existing and new Android devices |
| are STRONGLY RECOMMENDED to implement the TYPE_GAME_ROTATION_VECTOR sensor. |
| </li> |
| <li>MUST implement a TYPE_ROTATION_VECTOR composite sensor, if a gyroscope |
| sensor and a magnetometer sensor is also included.</li> |
| </ul> |
| |
| <h3 id="7_3_2_magnetometer">7.3.2. Magnetometer</h3> |
| |
| |
| <p>Device implementations SHOULD include a 3-axis magnetometer (compass). If a |
| device does include a 3-axis magnetometer, it:</p> |
| |
| <ul> |
| <li>MUST implement the TYPE_MAGNETIC_FIELD sensor and SHOULD also implement |
| TYPE_MAGNETIC_FIELD_UNCALIBRATED sensor. Existing and new Android devices are |
| STRONGLY RECOMMENDED to implement the TYPE_MAGNETIC_FIELD_UNCALIBRATED sensor. |
| </li> |
| <li>MUST be able to report events up to a frequency of at least 10 Hz and |
| SHOULD report events up to at least 50 Hz.</li> |
| <li>MUST comply with the |
| <a href="http://developer.android.com/reference/android/hardware/SensorEvent.html">Android |
| sensor coordinate system</a> as detailed in the Android APIs.</li> |
| <li>MUST be capable of measuring between -900 µT and +900 µT on |
| each axis before saturating.</li> |
| <li>MUST have a hard iron offset value less than 700 µT and SHOULD have |
| a value below 200 µT, by placing the magnetometer far from dynamic |
| (current-induced) and static (magnet-induced) magnetic fields.</li> |
| <li>MUST have a resolution equal or denser than 0.6 µT and SHOULD have a |
| resolution equal or denser than 0.2 µ.</li> |
| <li>SHOULD be temperature compensated.</li> |
| <li>MUST support online calibration and compensation of the hard iron bias, |
| and preserve the compensation parameters between device reboots.</li> |
| <li>MUST have the soft iron compensation applied—the calibration can be |
| done either while in use or during the production of the device.</li> |
| <li>SHOULD have a standard deviation, calculated on a per axis basis on |
| samples collected over a period of at least 3 seconds at the fastest sampling |
| rate, no greater than 0.5 µT.</li> |
| <li>MUST implement a TYPE_ROTATION_VECTOR composite sensor, if an |
| accelerometer sensor and a gyroscope sensor is also included.</li> |
| <li>MAY implement the TYPE_GEOMAGNETIC_ROTATION_VECTOR sensor if an |
| accelerometer sensor is also implemented. However if implemented, it MUST |
| consume less than 10 mW and SHOULD consume less than 3 mW when the sensor is |
| registered for batch mode at 10 Hz.</li> |
| </ul> |
| |
| <h3 id="7_3_3_gps">7.3.3. GPS</h3> |
| |
| |
| <p>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.</p> |
| |
| <h3 id="7_3_4_gyroscope">7.3.4. Gyroscope</h3> |
| |
| |
| <p>Device implementations SHOULD include a gyroscope (angular change sensor). |
| Devices SHOULD NOT include a gyroscope sensor unless a 3-axis accelerometer is |
| also included. If a device implementation includes a gyroscope, it:</p> |
| |
| <ul> |
| <li>MUST implement the TYPE_GYROSCOPE sensor and SHOULD also implement |
| TYPE_GYROSCOPE_UNCALIBRATED sensor. Existing and new Android devices are |
| STRONGLY RECOMMENDED to implement the SENSOR_TYPE_GYROSCOPE_UNCALIBRATED |
| sensor.</li> |
| <li>MUST be capable of measuring orientation changes up to 1,000 degrees per |
| second.</li> |
| <li>MUST be able to report events up to a frequency of at least 50 Hz for |
| Android Watch devices as such devices have a stricter power constraint and 100 |
| Hz for all other device types.</li> |
| <li>SHOULD report events up to at least 200 Hz.</li> |
| <li>MUST have a resolution of 12-bits or more and SHOULD have a resolution of |
| 16-bits or more.</li> |
| <li>MUST be temperature compensated.</li> |
| <li>MUST be calibrated and compensated while in use, and preserve the |
| compensation parameters between device reboots.</li> |
| <li>MUST have a variance no greater than 1e-7 rad^2 / s^2 per Hz (variance per |
| Hz, or rad^2 / s). The variance is allowed to vary with the sampling rate, but |
| must be constrained by this value. In other words, if you measure the variance |
| of the gyro at 1 Hz sampling rate it should be no greater than 1e-7 rad^2/s^2. |
| </li> |
| <li>MUST implement a TYPE_ROTATION_VECTOR composite sensor, if an |
| accelerometer sensor and a magnetometer sensor is also included.</li> |
| <li>If an accelerometer sensor is included, MUST implement the TYPE_GRAVITY |
| and TYPE_LINEAR_ACCELERATION composite sensors and SHOULD implement the |
| TYPE_GAME_ROTATION_VECTOR composite sensor. Existing and new Android devices |
| are STRONGLY RECOMMENDED to implement the TYPE_GAME_ROTATION_VECTOR sensor. |
| </li> |
| </ul> |
| |
| <h3 id="7_3_5_barometer">7.3.5. Barometer</h3> |
| |
| |
| <p>Device implementations SHOULD include a barometer (ambient air pressure |
| sensor). If a device implementation includes a barometer, it:</p> |
| |
| <ul> |
| <li>MUST implement and report TYPE_PRESSURE sensor.</li> |
| <li>MUST be able to deliver events at 5 Hz or greater.</li> |
| <li>MUST have adequate precision to enable estimating altitude.</li> |
| <li>MUST be temperature compensated.</li> |
| </ul> |
| |
| <h3 id="7_3_6_thermometer">7.3.6. Thermometer</h3> |
| |
| |
| <p>Device implementations MAY include an ambient thermometer (temperature |
| sensor). If present, it MUST be defined as SENSOR_TYPE_AMBIENT_TEMPERATURE and |
| it MUST measure the ambient (room) temperature in degrees Celsius.</p> |
| |
| <p>Device implementations MAY but SHOULD NOT include a CPU temperature sensor. |
| If present, it MUST be defined as SENSOR_TYPE_TEMPERATURE, it MUST measure the |
| 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.</p> |
| |
| <h3 id="7_3_7_photometer">7.3.7. Photometer</h3> |
| |
| |
| <p>Device implementations MAY include a photometer (ambient light sensor).</p> |
| |
| <h3 id="7_3_8_proximity_sensor">7.3.8. Proximity Sensor</h3> |
| |
| |
| <p>Device implementations MAY include a proximity sensor. Devices that can make |
| a voice call and indicate any value other than PHONE_TYPE_NONE in getPhoneType |
| SHOULD include a proximity sensor. If a device implementation does include a |
| proximity sensor, it:</p> |
| |
| <ul> |
| <li>MUST measure the proximity of an object in the same direction as the |
| screen. That is, the proximity sensor MUST be oriented to detect objects close |
| to the screen, as the primary intent of this sensor type is to detect a phone |
| in use by the user. If a device implementation includes a proximity sensor |
| with any other orientation, it MUST NOT be accessible through this API.</li> |
| <li>MUST have 1-bit of accuracy or more.</li> |
| </ul> |
| |
| |
| <h3 id="7_3_9_hifi_sensors">7.3.9. High Fidelity Sensors</h3> |
| |
| <p>Device implementations supporting a set of higher quality sensors that can |
| meet all the requirements listed in this section MUST identify the support |
| through the <code>android.hardware.sensor.hifi_sensors</code> feature flag.</p> |
| |
| <p>A device declaring android.hardware.sensor.hifi_sensors MUST support all of |
| the following sensor types meeting the quality requirements as below:</p> |
| |
| <ul> |
| <li>SENSOR_TYPE_ACCELEROMETER |
| <ul> |
| <li>MUST have a measurement range between at least -8g and +8g.</li> |
| <li>MUST have a measurement resolution of at least 1024 LSB/G.</li> |
| <li>MUST have a minimum measurement frequency of 12.5 Hz or lower.</li> |
| <li>MUST have a maxmium measurement frequency of 200 Hz or higher.</li> |
| <li>MUST have a measurement noise not above 400uG/√Hz.</li> |
| <li>MUST implement a non-wake-up form of this sensor with a buffering |
| capability of at least 3000 sensor events.</li> |
| <li>MUST have a batching power consumption not worse than 3 mW.</li> |
| </ul> |
| </li> |
| <li>SENSOR_TYPE_GYROSCOPE |
| <ul> |
| <li>MUST have a measurement range between at least -1000 and +1000 dps.</li> |
| <li>MUST have a measurement resolution of at least 16 LSB/dps.</li> |
| <li>MUST have a minimum measurement frequency of 12.5 Hz or lower.</li> |
| <li>MUST have a maxmium measurement frequency of 200 Hz or higher.</li> |
| <li>MUST have a measurement noise not above 0.014°/s/√Hz.</li> |
| </ul> |
| </li> |
| <li>SENSOR_TYPE_GYROSCOPE_UNCALIBRATED with the same quality requirements as |
| SENSOR_TYPE_GYROSCOPE.</li> |
| <li>SENSOR_TYPE_GEOMAGNETIC_FIELD |
| <ul> |
| <li>MUST have a measurement range between at least -900 and +900 uT.</li> |
| <li>MUST have a measurement resolution of at least 5 LSB/uT.</li> |
| <li>MUST have a minimum measurement frequency of 5 Hz or lower.</li> |
| <li>MUST have a maxmium measurement frequency of 50 Hz or higher.</li> |
| <li>MUST have a measurement noise not above 0.5 uT.</li> |
| </ul> |
| </li> |
| <li>SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED with the same quality requirements |
| as SENSOR_TYPE_GEOMAGNETIC_FIELD and in addition: |
| <ul> |
| <li>MUST implement a non-wake-up form of this sensor with a buffering |
| capability of at least 600 sensor events.</li> |
| </ul> |
| </li> |
| <li>SENSOR_TYPE_PRESSURE |
| <ul> |
| <li>MUST have a measurement range between at least 300 and 1100 hPa.</li> |
| <li>MUST have a measurement resolution of at least 80 LSB/hPa.</li> |
| <li>MUST have a minimum measurement frequency of 1 Hz or lower.</li> |
| <li>MUST have a maximum measurement frequency of 10 Hz or higher.</li> |
| <li>MUST have a measurement noise not above 2 Pa/√Hz.</li> |
| <li>MUST implement a non-wake-up form of this sensor with a buffering |
| capability of at least 300 sensor events.</li> |
| <li>MUST have a batching power consumption not worse than 2 mW.</li> |
| </ul> |
| </li> |
| <li>SENSOR_TYPE_ROTATION_VECTOR |
| <ul> |
| <li>MUST have a batching power consumption not worse than 4 mW.</li> |
| </ul> |
| </li> |
| <li>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.</li> |
| <li>SENSOR_TYPE_SIGNIFICANT_MOTION |
| <ul> |
| <li>MUST have a power consumption not worse than 0.5 mW when device is |
| static and 1.5 mW when device is moving.</li> |
| </ul> |
| </li> |
| <li>SENSOR_TYPE_STEP_DETECTOR |
| <ul> |
| <li>MUST implement a non-wake-up form of this sensor with a buffering |
| capability of at least 100 sensor events.</li> |
| <li>MUST have a power consumption not worse than 0.5 mW when device is |
| static and 1.5 mW when device is moving.</li> |
| <li>MUST have a batching power consumption not worse than 4 mW.</li> |
| </ul> |
| </li> |
| <li>SENSOR_TYPE_STEP_COUNTER |
| <ul> |
| <li>MUST have a power consumption not worse than 0.5 mW when device is |
| static and 1.5 mW when device is moving.</li> |
| </ul> |
| </li> |
| <li>SENSOR_TILT_DETECTOR |
| <ul> |
| <li>MUST have a power consumption not worse than 0.5 mW when device is |
| static and 1.5 mW when device is moving.</li> |
| </ul> |
| </li> |
| </ul> |
| |
| <p>Also such a device MUST meet the following sensor subsystem requirements:</p> |
| |
| <ul> |
| <li>The event timestamp of the same physical event reported by the |
| Accelerometer, Gyroscope sensor and Magnetometer MUST be within 2.5 |
| milliseconds of each other.</li> |
| <li>The Gyroscope sensor event timestamps MUST be on the same time base as the |
| camera subsystem and within 1 millisconds of error.</li> |
| <li>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.</li> |
| <li>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: |
| <ul> |
| <li>SENSOR_TYPE_SIGNIFICANT_MOTION</li> |
| <li>SENSOR_TYPE_STEP_DETECTOR</li> |
| <li>SENSOR_TYPE_STEP_COUNTER</li> |
| <li>SENSOR_TILT_DETECTORS</li> |
| </ul> |
| </li> |
| </ul> |
| |
| <p>Note that all power consumption requirements in this section do not include |
| the power consumption of the Application Processor. It is inclusive of the power |
| drawn by the entire sensor chain—the sensor, any supporting circuitry, any |
| dedicated sensor processing system, etc.</p> |
| |
| <p>The following sensor types MAY also be supported on a device implementation |
| declaring android.hardware.sensor.hifi_sensors, but if these sensor types are |
| present they MUST meet the following minimum buffering capability requirement: |
| </p> |
| |
| <ul> |
| <li>SENSOR_TYPE_PROXIMITY: 100 sensor events</li> |
| </ul> |
| |
| <h3 id="7_3_10_fingeprint">7.3.10. Fingerprint Sensor</h3> |
| |
| <p>Device implementations with a secure lock screen SHOULD include a fingerprint |
| sensor. If a device implementation includes a fingerprint sensor and has a |
| corresponding API for third-party developers, it:</p> |
| |
| <ul> |
| <li>MUST declare support for the android.hardware.fingerprint feature.</li> |
| <li>MUST fully implement the |
| <a href="https://developer.android.com/reference/android/hardware/fingerprint/package-summary.html">corresponding |
| API</a> as described in the Android SDK documentation.</li> |
| <li>MUST have a false acceptance rate not higher than 0.002%.</li> |
| <li>Is STRONGLY RECOMMENDED to have a false rejection rate of less than |
| 10%, as measured on the device</li> |
| <li>Is STRONGLY RECOMMENDED to have a latency below 1 second, measured from |
| when the fingerprint sensor is touched until the screen is unlocked, |
| for one enrolled finger.</li> |
| <li>MUST rate limit attempts for at least 30 seconds after five false trials for |
| fingerprint verification.</li> |
| <li>MUST have a hardware-backed keystore implementation, and perform the |
| fingerprint matching in a Trusted Execution Environment (TEE) or on a chip |
| with a secure channel to the TEE.</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> |
| <li>MUST NOT enable 3rd-party applications to distinguish between individual |
| fingerprints.</li> |
| <li>MUST honor the DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT flag.</li> |
| <li>MUST, when upgraded from a version earlier than Android 6.0, have the |
| fingerprint data securely migrated to meet the above requirements or removed. |
| </li> |
| <li>SHOULD use the Android Fingerprint icon provided in the Android Open |
| Source Project.</li> |
| </ul> |
| |
| <h2 id="7_4_data_connectivity">7.4. Data Connectivity</h2> |
| |
| |
| <h3 id="7_4_1_telephony">7.4.1. Telephony</h3> |
| |
| |
| <p>“Telephony” as used by the Android APIs and this document refers |
| specifically to hardware related to placing voice calls and sending SMS messages |
| via a GSM or CDMA network. While these voice calls may or may not be |
| packet-switched, they are for the purposes of Android considered independent of |
| any data connectivity that may be implemented using the same network. In other |
| words, the Android “telephony” functionality and APIs refer |
| specifically to voice calls and SMS. For instance, device implementations that |
| cannot place calls or send/receive SMS messages MUST NOT report the |
| android.hardware.telephony feature or any subfeatures, regardless of whether |
| they use a cellular network for data connectivity.</p> |
| |
| <p>Android MAY be used on devices that do not include telephony hardware. That |
| is, Android is compatible with devices that are not phones. However, if a device |
| implementation does include GSM or CDMA telephony, it MUST implement full |
| support for the API for that technology. Device implementations that do not |
| include telephony hardware MUST implement the full APIs as no-ops.</p> |
| |
| <h3 id="7_4_2_ieee_802_11_wi-fi">7.4.2. IEEE 802.11 (Wi-Fi)</h3> |
| |
| <div class="note"> |
| <p>Android Television device implementations MUST include Wi-Fi support.</p> |
| </div> |
| |
| |
| <p>Android Television device implementations MUST include support for one or |
| more forms of 802.11 (b/g/a/n, etc.) and other types of Android device |
| implementation SHOULD include support for one or more forms of 802.11. If a |
| device implementation does include support for 802.11 and exposes the |
| functionality to a third-party application, it MUST implement the corresponding |
| Android API and:</p> |
| |
| <ul> |
| <li>MUST report the hardware feature flag android.hardware.wifi.</li> |
| <li>MUST implement the |
| <a href="http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html">multicast |
| API</a> as described in the SDK documentation.</li> |
| <li>MUST support multicast DNS (mDNS) and MUST NOT filter mDNS packets |
| (224.0.0.251) at any time of operation including: |
| <ul> |
| <li>Even when the screen is not in an active state.</li> |
| <li>For Android Television device implementations, even when in standby |
| power states.</li> |
| </ul> |
| </ul> |
| |
| <h4 id="7_4_2_1_wi-fi_direct">7.4.2.1. Wi-Fi Direct</h4> |
| |
| |
| <p>Device implementations SHOULD include support for Wi-Fi Direct (Wi-Fi |
| peer-to-peer). If a device implementation does include support for Wi-Fi Direct, |
| it MUST implement the |
| <a href="http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html">corresponding |
| Android API</a> as described in the SDK documentation. If a device |
| implementation includes support for Wi-Fi Direct, then it:</p> |
| |
| <ul> |
| <li>MUST report the hardware feature android.hardware.wifi.direct.</li> |
| <li>MUST support regular Wi-Fi operation.</li> |
| <li>SHOULD support concurrent Wi-Fi and Wi-Fi Direct operation.</li> |
| </ul> |
| |
| <h4 id="7_4_2_2_wi-fi_tunneled_direct_link_setup">7.4.2.2. Wi-Fi Tunneled Direct |
| Link Setup</h4> |
| |
| <div class="note"> |
| <p>Android Television device implementations MUST include support for Wi-Fi |
| Tunneled Direct Link Setup (TDLS).</p> |
| </div> |
| |
| |
| <p>Android Television device implementations MUST include support for |
| <a href="http://developer.android.com/reference/android/net/wifi/WifiManager.html">Wi-Fi |
| Tunneled Direct Link Setup (TDLS)</a> and other types of Android device |
| implementations SHOULD include support for Wi-Fi TDLS as described in the |
| Android SDK Documentation. If a device implementation does include support for |
| TDLS and TDLS is enabled by the WiFiManager API, the device:</p> |
| |
| <ul> |
| <li>SHOULD use TDLS only when it is possible AND beneficial.</li> |
| <li>SHOULD have some heuristic and NOT use TDLS when its performance might be |
| worse than going through the Wi-Fi access point.</li> |
| </ul> |
| |
| <h3 id="7_4_3_bluetooth">7.4.3. Bluetooth</h3> |
| |
| <div class="note"> |
| <p>Android Watch and Automotive implementations MUST support Bluetooth. Android |
| Television implementations MUST support Bluetooth and Bluetooth LE.</p> |
| </div> |
| |
| |
| <p>Android includes support for |
| <a href="http://developer.android.com/reference/android/bluetooth/package-summary.html">Bluetooth |
| and Bluetooth Low Energy </a>. Device implementations that include support for |
| Bluetooth and Bluetooth Low 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.</p> |
| |
| <p>Device implementations including support for Bluetooth Low Energy:</p> |
| |
| <ul> |
| <li>MUST declare the hardware feature android.hardware.bluetooth_le.</li> |
| <li>MUST enable the GATT (generic attribute profile) based Bluetooth APIs as |
| described in the SDK documentation and |
| <a href="http://developer.android.com/reference/android/bluetooth/package-summary.html">android.bluetooth</a>. |
| </li> |
| <li>are STRONGLY RECOMMENDED to implement a Resolvable Private Address (RPA) |
| timeout no longer than 15 minutes and rotate the address at timeout to protect |
| user privacy.</li> |
| <li>SHOULD support offloading of the filtering logic to the bluetooth chipset |
| when implementing the |
| <a href="https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html">ScanFilter |
| API</a>, and MUST report the correct value of where the filtering logic is |
| implemented whenever queried via the |
| android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported() method. |
| </li> |
| <li>SHOULD support offloading of the batched scanning to the bluetooth |
| chipset, but if not supported, MUST report ‘false’ whenever |
| queried via the |
| android.bluetooth.BluetoothAdapter.isOffloadedScanBatchingSupported() method. |
| </li> |
| <li>SHOULD support multi advertisement with at least 4 slots, but if not |
| supported, MUST report ‘false’ whenever queried via the |
| android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported() method. |
| </li> |
| </ul> |
| |
| <h3 id="7_4_4_near-field_communications">7.4.4. Near-Field Communications</h3> |
| |
| |
| <p>Device implementations SHOULD include a transceiver and related hardware for |
| Near-Field Communications (NFC). If a device implementation does include NFC |
| hardware and plans to make it available to third-party apps, then it:</p> |
| |
| <ul> |
| <li>MUST report the android.hardware.nfc feature from the |
| <a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">android.content.pm.PackageManager.hasSystemFeature() |
| method</a>.</li> |
| <li>MUST be capable of reading and writing NDEF messages via the following NFC |
| standards: |
| <ul> |
| <li>MUST be capable of acting as an NFC Forum reader/writer (as defined by |
| the NFC Forum technical specification NFCForum-TS-DigitalProtocol-1.0) via |
| the following NFC standards: |
| <ul> |
| <li>NfcA (ISO14443-3A)</li> |
| <li>NfcB (ISO14443-3B)</li> |
| <li>NfcF (JIS X 6319-4)</li> |
| <li>IsoDep (ISO 14443-4)</li> |
| <li>NFC Forum Tag Types 1, 2, 3, 4 (defined by the NFC Forum)</li> |
| </ul> |
| <li>STRONGLY RECOMMENDED to be capable of reading and writing NDEF messages as |
| well as raw data via the following NFC standards. Note that while the NFC |
| standards below are stated as STRONGLY RECOMMENDED, the Compatibility |
| Definition for a future version is planned to change these to MUST. These |
| standards are optional in this version but will be required in future |
| versions. Existing and new devices that run this version of Android are very |
| strongly encouraged to meet these requirements now so they will be able to |
| upgrade to the future platform releases. |
| <ul> |
| <li>NfcV (ISO 15693)</li> |
| </ul></li> |
| <li>SHOULD be capable of reading the barcode and URL (if encoded) of |
| <a href="http://developer.android.com/reference/android/nfc/tech/NfcBarcode.html">Thinfilm |
| NFC Barcode</a> products.</li> |
| <li>MUST be capable of transmitting and receiving data via the following |
| peer-to-peer standards and protocols: |
| <ul> |
| <li>ISO 18092</li> |
| <li>LLCP 1.2 (defined by the NFC Forum)</li> |
| <li>SDP 1.0 (defined by the NFC Forum)</li> |
| <li><a href="http://static.googleusercontent.com/media/source.android.com/en/us/compatibility/ndef-push-protocol.pdf">NDEF |
| Push Protocol</a></li> |
| <li>SNEP 1.0 (defined by the NFC Forum)</li> |
| </ul></li> |
| <li>MUST include support for <a href="http://developer.android.com/guide/topics/connectivity/nfc/nfc.html">Android Beam</a>: |
| <ul> |
| <li>MUST implement the SNEP default server. Valid NDEF messages received by |
| the default SNEP server MUST be dispatched to applications using the |
| android.nfc.ACTION_NDEF_DISCOVERED intent. Disabling Android Beam in |
| settings MUST NOT disable dispatch of incoming NDEF message.</li> |
| <li>MUST honor the android.settings.NFCSHARING_SETTINGS intent to show |
| <a href="http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS">NFC |
| sharing settings</a>.</li> |
| <li>MUST implement the NPP server. Messages received by the NPP server MUST |
| be processed the same way as the SNEP default server.</li> |
| <li>MUST implement a SNEP client and attempt to send outbound P2P NDEF to |
| the default SNEP server when Android Beam is enabled. If no default SNEP |
| server is found then the client MUST attempt to send to an NPP server.</li> |
| <li>MUST allow foreground activities to set the outbound P2P NDEF message |
| using android.nfc.NfcAdapter.setNdefPushMessage, and |
| android.nfc.NfcAdapter.setNdefPushMessageCallback, and |
| android.nfc.NfcAdapter.enableForegroundNdefPush.</li> |
| <li>SHOULD use a gesture or on-screen confirmation, such as 'Touch to Beam', |
| before sending outbound P2P NDEF messages.</li> |
| <li>SHOULD enable Android Beam by default and MUST be able to send and |
| receive using Android Beam, even when another proprietary NFC P2p mode is |
| turned on.</li> |
| <li>MUST support NFC Connection handover to Bluetooth when the device |
| supports Bluetooth Object Push Profile. Device implementations MUST support |
| connection handover to Bluetooth when using |
| android.nfc.NfcAdapter.setBeamPushUris, by implementing the |
| “<a href="http://members.nfc-forum.org/specs/spec_list/#conn_handover">Connection |
| Handover version 1.2</a>” and |
| “<a href="http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf">Bluetooth |
| Secure Simple Pairing Using NFC version 1.0</a>” specs from the NFC |
| Forum. Such an implementation MUST implement the handover LLCP service with |
| service name “urn:nfc:sn:handover” for exchanging the handover |
| request/select records over NFC, and it MUST use the Bluetooth Object Push |
| Profile for the actual Bluetooth data transfer. For legacy reasons (to |
| remain compatible with Android 4.1 devices), the implementation SHOULD still |
| accept SNEP GET requests for exchanging the handover request/select records |
| over NFC. However an implementation itself SHOULD NOT send SNEP GET requests |
| for performing connection handover.</li> |
| </ul></li> |
| <li>MUST poll for all supported technologies while in NFC discovery mode.</li> |
| <li>SHOULD be in NFC discovery mode while the device is awake with the screen |
| active and the lock-screen unlocked.</li> |
| </ul> |
| </ul> |
| |
| <p>(Note that publicly available links are not available for the JIS, ISO, and |
| NFC Forum specifications cited above.)</p> |
| |
| <p>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:</p> |
| |
| <ul> |
| <li>MUST report the android.hardware.nfc.hce feature constant.</li> |
| <li>MUST support |
| <a href="http://developer.android.com/guide/topics/connectivity/nfc/hce.html">NFC |
| HCE APIs</a> as defined in the Android SDK.</li> |
| </ul> |
| |
| <p>Additionally, device implementations MAY include reader/writer support for |
| the following MIFARE technologies.</p> |
| |
| <ul> |
| <li>MIFARE Classic</li> |
| <li>MIFARE Ultralight</li> |
| <li>NDEF on MIFARE Classic</li> |
| </ul> |
| |
| <p>Note that Android includes APIs for these MIFARE types. If a device |
| implementation supports MIFARE in the reader/writer role, it:</p> |
| |
| <ul> |
| <li>MUST implement the corresponding Android APIs as documented by the Android |
| SDK.</li> |
| <li>MUST report the feature com.nxp.mifare from the |
| <a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">android.content.pm.PackageManager.hasSystemFeature()</a> |
| method. Note that this is not a standard Android feature and as such does not |
| appear as a constant in the android.content.pm.PackageManager class.</li> |
| <li>MUST NOT implement the corresponding Android APIs nor report the |
| com.nxp.mifare feature unless it also implements general NFC support as |
| described in this section.</li> |
| </ul> |
| |
| <p>If a device implementation does not include NFC hardware, it MUST NOT declare |
| the android.hardware.nfc feature from the |
| <a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">android.content.pm.PackageManager.hasSystemFeature()</a> |
| method, and MUST implement the Android NFC API as a no-op.</p> |
| |
| <p>As the classes android.nfc.NdefMessage and android.nfc.NdefRecord represent a |
| protocol-independent data representation format, device implementations MUST |
| implement these APIs even if they do not include support for NFC or declare the |
| android.hardware.nfc feature.</p> |
| |
| <h3 id="7_4_5_minimum_network_capability">7.4.5. Minimum Network Capability</h3> |
| |
| |
| <p>Device implementations MUST include support for one or more forms of data |
| networking. Specifically, device implementations MUST include support for at |
| least one data standard capable of 200Kbit/sec or greater. Examples of |
| technologies that satisfy this requirement include EDGE, HSPA, EV-DO, 802.11g, |
| Ethernet, Bluetooth PAN, etc.</p> |
| |
| <p>Device implementations where a physical networking standard (such as |
| Ethernet) is the primary data connection SHOULD also include support for at |
| least one common wireless data standard, such as 802.11 (Wi-Fi).</p> |
| |
| <p>Devices MAY implement more than one form of data connectivity.</p> |
| |
| <p>Devices MUST include an IPv6 networking stack and support IPv6 communication |
| using the managed APIs, such as <code>java.net.Socket</code> and |
| <code>java.net.URLConnection</code>, as well as the native APIs, such as |
| <code>AF_INET6</code> sockets. The required level of IPv6 support depends on |
| the network type, as follows:</p> |
| <ul> |
| <li>Devices that support Wi-Fi networks MUST support dual-stack and IPv6-only |
| operation on Wi-Fi.</li> |
| <li>Devices that support Ethernet networks MUST support dual-stack operation |
| on Ethernet.</li> |
| <li>Devices that support cellular data SHOULD support IPv6 operation |
| (IPv6-only and possibly dual-stack) on cellular data.</li> |
| <li>When a device is simultaneously connected to more than one network (e.g., |
| Wi-Fi and cellular data), it MUST simultaneously meet these requirements on |
| each network to which it is connected.</li> |
| </ul> |
| |
| <p>IPv6 MUST be enabled by default.</p> |
| |
| <p>In order to ensure that IPv6 communication is as reliable as IPv4, unicast |
| IPv6 packets sent to the device MUST NOT be dropped, even when the screen is |
| not in an active state. Redundant multicast IPv6 packets, such as repeated |
| identical Router Advertisements, MAY be rate-limited in hardware or firmware |
| if doing so is necessary to save power. In such cases, rate-limiting MUST NOT |
| cause the device to lose IPv6 connectivity on any IPv6-compliant network that |
| uses RA lifetimes of at least 180 seconds.</p> |
| |
| <p>IPv6 connectivity MUST be maintained in doze mode.</p> |
| |
| <h3 id="7_4_6_sync_settings">7.4.6. Sync Settings</h3> |
| |
| |
| <p>Device implementations MUST have the master auto-sync setting on by default so |
| that the method |
| <a href="http://developer.android.com/reference/android/content/ContentResolver.html">getMasterSyncAutomatically()</a> |
| returns “true”.</p> |
| |
| <h2 id="7_5_cameras">7.5. Cameras</h2> |
| |
| |
| <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> |
| |
| <p>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.</p> |
| |
| <h3 id="7_5_1_rear-facing_camera">7.5.1. Rear-Facing Camera</h3> |
| |
| |
| <p>Device implementations SHOULD include a rear-facing camera. If a device |
| implementation includes at least one rear-facing camera, it:</p> |
| |
| <ul> |
| <li>MUST report the feature flag android.hardware.camera and |
| android.hardware.camera.any.</li> |
| <li>MUST have a resolution of at least 2 megapixels.</li> |
| <li>SHOULD have either hardware auto-focus or software auto-focus implemented |
| in the camera driver (transparent to application software).</li> |
| <li>MAY have fixed-focus or EDOF (extended depth of field) hardware.</li> |
| <li>MAY include a flash. If the Camera includes a flash, the flash lamp MUST |
| NOT be lit while an android.hardware.Camera.PreviewCallback instance has been |
| registered on a Camera preview surface, unless the application has explicitly |
| enabled the flash by enabling the FLASH_MODE_AUTO or FLASH_MODE_ON attributes |
| of a Camera.Parameters object. Note that this constraint does not apply to the |
| device’s built-in system camera application, but only to third-party |
| applications using Camera.PreviewCallback.</li> |
| </ul> |
| |
| <h3 id="7_5_2_front-facing_camera">7.5.2. Front-Facing Camera</h3> |
| |
| |
| <p>Device implementations MAY include a front-facing camera. If a device |
| implementation includes at least one front-facing camera, it:</p> |
| |
| <ul> |
| <li>MUST report the feature flag android.hardware.camera.any and |
| android.hardware.camera.front.</li> |
| <li>MUST have a resolution of at least VGA (640x480 pixels).</li> |
| <li>MUST NOT use a front-facing camera as the default for the Camera API. The |
| camera API in Android has specific support for front-facing cameras and device |
| implementations MUST NOT configure the API to to treat a front-facing camera |
| as the default rear-facing camera, even if it is the only camera on the |
| device.</li> |
| <li>MAY include features (such as auto-focus, flash, etc.) available to |
| rear-facing cameras as described in |
| <a href="#7_5_1_rear-facing_camera">section 7.5.1</a>.</li> |
| <li>MUST horizontally reflect (i.e. mirror) the stream displayed by an app in |
| a CameraPreview, as follows: |
| <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(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> |
| </ul></li> |
| <li>MUST mirror the image displayed by the postview in the same manner as the |
| camera preview image stream. If the device implementation does not support |
| postview, this requirement obviously does not apply.</li> |
| <li>MUST NOT mirror the final captured still image or video streams returned |
| to application callbacks or committed to media storage.</li> |
| </ul> |
| |
| <h3 id="7_5_3_external_camera">7.5.3. External Camera</h3> |
| |
| |
| <p>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:</p> |
| |
| <ul> |
| <li>MUST declare the platform feature android.hardware.camera.external and |
| android.hardware camera.any.</li> |
| <li>MUST support USB Video Class (UVC 1.0 or higher).</li> |
| <li>MAY support multiple cameras.</li> |
| </ul> |
| |
| <p>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.</p> |
| |
| <h3 id="7_5_4_camera_api_behavior">7.5.4. Camera API Behavior</h3> |
| |
| |
| <p>Android includes two API packages to access the camera, the newer |
| android.hardware.camera2 API expose lower-level camera control to the app, |
| including efficient zero-copy burst/streaming flows and per-frame controls of |
| exposure, gain, white balance gains, color conversion, denoising, sharpening, |
| and more.</p> |
| |
| <p>The older API package, android.hardware.Camera, is marked as deprecated in |
| Android 5.0 but as it should still be available for apps to use Android device |
| implementations MUST ensure the continued support of the API as described in |
| this section and in the Android SDK.</p> |
| |
| <p>Device implementations MUST implement the following behaviors for the |
| camera-related APIs, for all available cameras:</p> |
| |
| <ul> |
| <li>If an application has never called |
| android.hardware.Camera.Parameters.setPreviewFormat(int), then the device MUST |
| use android.hardware.PixelFormat.YCbCr_420_SP for preview data provided to |
| application callbacks.</li> |
| <li>If an application registers an android.hardware.Camera.PreviewCallback |
| instance and the system calls the onPreviewFrame() method when the preview |
| format is YCbCr_420_SP, the data in the byte[] passed into onPreviewFrame() |
| must further be in the NV21 encoding format. That is, NV21 MUST be the |
| default.</li> |
| <li>For android.hardware.Camera, device implementations MUST support the YV12 |
| format (as denoted by the android.graphics.ImageFormat.YV12 constant) for |
| camera previews for both front- and rear-facing cameras. (The hardware video |
| encoder and camera may use any native pixel format, but the device |
| implementation MUST support conversion to YV12.)</li> |
| <li>For android.hardware.camera2, device implementations must support the |
| android.hardware.ImageFormat.YUV_420_888 and android.hardware.ImageFormat.JPEG |
| formats as outputs through the android.media.ImageReader API.</li> |
| </ul> |
| |
| <p>Device implementations MUST still implement the full |
| <a href="http://developer.android.com/reference/android/hardware/Camera.html">Camera |
| API</a> included in the Android SDK documentation, regardless of whether the |
| device includes hardware autofocus or other capabilities. For instance, cameras |
| that lack autofocus MUST still call any registered |
| android.hardware.Camera.AutoFocusCallback instances (even though this has no |
| relevance to a non-autofocus camera.) Note that this does apply to front-facing |
| cameras; for instance, even though most front-facing cameras do not support |
| autofocus, the API callbacks must still be “faked” as described.</p> |
| |
| <p>Device implementations MUST recognize and honor each parameter name defined |
| as a constant on the |
| <a href="http://developer.android.com/reference/android/hardware/Camera.Parameters.html">android.hardware.Camera.Parameters</a> |
| class, if the underlying hardware supports the feature. If the device hardware |
| does not support a feature, the API must behave as documented. Conversely, |
| device implementations MUST NOT honor or recognize string constants passed to |
| the android.hardware.Camera.setParameters() method other than those documented |
| as constants on the android.hardware.Camera.Parameters. That is, device |
| implementations MUST support all standard Camera parameters if the hardware |
| allows, and MUST NOT support custom Camera parameter types. For instance, device |
| implementations that support image capture using high dynamic range (HDR) |
| imaging techniques MUST support camera parameter Camera.SCENE_MODE_HDR.</p> |
| |
| <p>Because not all device implementations can fully support all the features of |
| the android.hardware.camera2 API, device implementations MUST report the proper |
| level of support with the |
| <a href="https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL">android.info.supportedHardwareLevel</a> |
| property as described in the Android SDK and report the appropriate |
| <a href="http://source.android.com/devices/camera/versioning.html">framework |
| feature flags</a>.</p> |
| |
| <p>Device implementations MUST also declare its Individual camera capabilities |
| of android.hardware.camera2 via the android.request.availableCapabilities |
| property and declare the appropriate |
| <a href="http://source.android.com/devices/camera/versioning.html">feature |
| flags</a>; a device must define the feature flag if any of its attached camera |
| devices supports the feature.</p> |
| |
| <p>Device implementations MUST broadcast the Camera.ACTION_NEW_PICTURE intent |
| whenever a new picture is taken by the camera and the entry of the picture has |
| been added to the media store.</p> |
| |
| <p>Device implementations MUST broadcast the Camera.ACTION_NEW_VIDEO intent |
| whenever a new video is recorded by the camera and the entry of the picture has |
| been added to the media store.</p> |
| |
| <h3 id="7_5_5_camera_orientation">7.5.5. Camera Orientation</h3> |
| |
| |
| <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">7.6. Memory and Storage</h2> |
| |
| |
| <h3 id="7_6_1_minimum_memory_and_storage">7.6.1. Minimum Memory and Storage</h3> |
| |
| <div class="note"> |
| <p>Android Television devices MUST have at least 5GB of non-volatile storage |
| available for application private data.</p> |
| </div> |
| |
| |
| <p>The memory available to the kernel and userspace on device implementations |
| MUST be at least equal or larger than the minimum values specified by the |
| following table. (See <a href="#7_1_1_screen_configuration">section 7.1.1</a> |
| for screen size and density definitions.)</p> |
| <table> |
| <tr> |
| <th>Density and screen size</th> |
| <th>32-bit device</th> |
| <th>64-bit device</th> |
| </tr> |
| <tr> |
| <td>Android Watch devices (due to smaller screens)</td> |
| <td>416MB</td> |
| <td>Not applicable</td> |
| </tr> |
| <tr> |
| <td><ul> |
| <li class="table_list">280dpi or lower on small/normal screens</li> |
| <li class="table_list">mdpi or lower on large screens</li> |
| <li class="table_list">ldpi or lower on extra large screens</li> |
| </ul></td> |
| <td>424MB</td> |
| <td>704MB</td> |
| </tr> |
| <tr> |
| <td><ul> |
| <li class="table_list">xhdpi or higher on small/normal screens</li> |
| <li class="table_list">hdpi or higher on large screens</li> |
| <li class="table_list">mdpi or higher on extra large screens</li></ul></td> |
| <td>512MB</td> |
| <td>832MB</td> |
| </tr> |
| <tr> |
| <td><ul> |
| <li class="table_list">400dpi or higher on small/normal screens</li> |
| <li class="table_list">xhdpi or higher on large screens</li> |
| <li class="table_list">tvdpi or higher on extra large screens</li></ul></td> |
| <td>896MB</td> |
| <td>1280MB</td> |
| </tr> |
| <tr> |
| <td><ul> |
| <li class="table_list">560dpi or higher on small/normal screens</li> |
| <li class="table_list">400dpi or higher on large screens</li> |
| <li class="table_list">xhdpi or higher on extra large screens</li></ul></td> |
| <td>1344MB</td> |
| <td>1824MB</td> |
| </tr> |
| </table> |
| |
| |
| <p>The minimum memory values MUST be in addition to any memory space already |
| dedicated to hardware components such as radio, video, and so on that is not |
| under the kernel’s control.</p> |
| |
| <p>Device implementations with less than 512MB of memory available to the kernel |
| and userspace, unless an Android Watch, MUST return the value "true" for |
| ActivityManager.isLowRamDevice().</p> |
| |
| <p>Android Television devices MUST have at least 5GB and other device |
| implementations MUST have at least 1.5GB of non-volatile storage available for |
| application private data. That is, the /data partition MUST be at least 5GB for |
| Android Television devices and at least 1.5GB for other device implementations. |
| Device implementations that run Android are <strong>STRONGLY |
| RECOMMENDED</strong> to have at least 3GB of non-volatile storage for |
| application private data so they will be able to upgrade to the future platform |
| releases.</p> |
| |
| <p>The Android APIs include a |
| <a href="http://developer.android.com/reference/android/app/DownloadManager.html">Download |
| Manager</a> that applications MAY use to download data files. The device |
| implementation of the Download Manager MUST be capable of downloading individual |
| files of at least 100MB in size to the default “cache” location.</p> |
| |
| <h3 id="7_6_2_application_shared_storage">7.6.2. Application Shared Storage</h3> |
| |
| |
| <p>Device implementations MUST offer shared storage for applications also often |
| referred as “shared external storage”.</p> |
| |
| <p>Device implementations MUST be configured with shared storage mounted by |
| default, “out of the box”. If the shared storage is not mounted on |
| the Linuxpath /sdcard, then the device MUST include a Linux symbolic link from |
| /sdcard to the actual mount point.</p> |
| |
| <p>Device implementations MAY have hardware for user-accessible removable |
| storage, such as a Secure Digital (SD) card slot. If this slot is used to |
| satisfy the shared storage requirement, the device implementation:</p> |
| |
| <ul> |
| <li>MUST implement a toast or pop-up user interface warning the user when |
| there is no SD card.</li> |
| <li>MUST include a FAT-formatted SD card 1GB in size or larger OR show on the |
| box and other material available at time of purchase that the SD card has to |
| be separately purchased.</li> |
| <li>MUST mount the SD card by default.</li> |
| </ul> |
| |
| <p>Alternatively, device implementations MAY allocate internal (non-removable) |
| storage as shared storage for apps as included in the upstream Android Open |
| Source Project; device implementations SHOULD use this configuration and |
| software implementation. If a device implementation uses internal |
| (non-removable) storage to satisfy the shared storage requirement, while that |
| storage MAY share space with the application private data, it MUST be at least |
| 1GB in size and mounted on /sdcard (or /sdcard MUST be a |
| symbolic link to the physical location if it is mounted elsewhere).</p> |
| |
| <p>Device implementations MUST enforce as documented the |
| android.permission.WRITE_EXTERNAL_STORAGE permission on this shared storage. |
| Shared storage MUST otherwise be writable by any application that obtains that |
| permission.</p> |
| |
| <p>Device implementations that include multiple shared storage paths (such as both |
| an SD card slot and shared internal storage) MUST allow only pre-installed & |
| privileged Android applications with the WRITE_EXTERNAL_STORAGE permission to |
| write to the secondary external storage, except when writing to their |
| package-specific directories or within the <code>URI</code> returned by firing |
| the <code>ACTION_OPEN_DOCUMENT_TREE</code> intent.</p> |
| |
| <p>However, device implementations SHOULD expose content from |
| both storage paths transparently through Android’s media scanner service |
| and android.provider.MediaStore.</p> |
| |
| <p>Regardless of the form of shared storage used, if the device implementation |
| has a USB port with USB peripheral mode support, it MUST provide some mechanism |
| to access the contents of shared storage from a host computer. Device |
| implementations MAY use USB mass storage, but SHOULD use Media Transfer Protocol |
| to satisfy this requirement. If the device implementation supports Media |
| Transfer Protocol, it:</p> |
| |
| <ul> |
| <li>SHOULD be compatible with the reference Android MTP host, |
| <a href="http://www.android.com/filetransfer">Android File Transfer</a>.</li> |
| <li>SHOULD report a USB device class of 0x00.</li> |
| <li>SHOULD report a USB interface name of 'MTP'.</li> |
| </ul> |
| |
| <h3 id="7_6_3_adoptable_storage">7.6.3. Adoptable Storage</h3> |
| |
| <p>Device implementations are STRONGLY RECOMMENDED to implement |
| <a href="http://source.android.com/devices/storage/adoptable.html">adoptable |
| storage</a> if the removable storage device port is in a long-term stable |
| location, such as within the battery compartment or other protective cover.</p> |
| |
| <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">7.7. USB</h2> |
| |
| |
| <p>Device implementations SHOULD support USB peripheral mode and SHOULD support |
| USB host mode.</p> |
| |
| <p>If a device implementation includes a USB port supporting peripheral mode: |
| </p> |
| |
| <ul> |
| <li>The port MUST be connectable to a USB host that has a standard type-A or |
| type-C USB port.</li> |
| <li>The port SHOULD use micro-B, micro-AB or Type-C USB form factor. Existing |
| and new Android devices are <strong>STRONGLY RECOMMENDED to meet these |
| requirements</strong> so they will be able to upgrade to the future platform |
| releases.</li> |
| <li>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 <strong>STRONGLY RECOMMENDED to meet these requirements</strong> so they |
| will be able to upgrade to future platform releases.</li> |
| <li>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.</li> |
| <li>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: |
| <ul> |
| <li>MUST declare support for the hardware feature |
| <a href="http://developer.android.com/guide/topics/connectivity/usb/accessory.html">android.hardware.usb.accessory</a>. |
| </li> |
| <li>MUST support establishing an |
| <a href="http://source.android.com/devices/accessories/aoa.html">AOA protocol based communication</a> |
| 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.</li> |
| <li>MUST implement the |
| <a href="http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO">USB |
| audio class</a>as documented in the Android SDK documentation.</li> |
| <li>The USB mass storage class MUST include the string "android" at the end |
| of the interface description <code>iInterface</code> string of the USB mass |
| storage</li> |
| </ul> |
| </li> |
| <li>It SHOULD implement support to draw 1.5 A current during HS chirp and |
| traffic as specified in the |
| <a href="http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip">USB |
| Battery Charging specification, revision 1.2</a>. Existing and new Android |
| devices are |
| <strong>STRONGLY RECOMMENDED to meet these requirements</strong> so they will |
| be able to upgrade to the future platform releases.</li> |
| <li>The value of iSerialNumber in USB standard device descriptor MUST be equal |
| to the value of android.os.Build.SERIAL.</li> |
| </ul> |
| |
| <p>If a device implementation includes a USB port supporting host mode, it:</p> |
| |
| <ul> |
| <li>SHOULD use a type-C USB port, if the device implementation supports USB |
| 3.1.</li> |
| <li>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.</li> |
| <li>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.</li> |
| <li>is <strong>STRONGLY RECOMMENDED</strong> to implement the |
| <a href="http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO">USB |
| audio class</a> as documented in the Android SDK documentation.</li> |
| <li>MUST implement the Android USB host API as documented in the Android SDK, |
| and MUST declare support for the hardware feature |
| <a href="http://developer.android.com/guide/topics/connectivity/usb/host.html">android.hardware.usb.host</a>. |
| </li> |
| <li>SHOULD support the Charging Downstream Port output current range of 1.5 A |
| ~ 5 A as specified in the |
| <a href="http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip">USB |
| Battery Charging specifications, revision 1.2</a>.</li> |
| </ul> |
| |
| <h2 id="7_8_audio">7.8. Audio</h2> |
| |
| |
| <h3 id="7_8_1_microphone">7.8.1. Microphone</h3> |
| |
| <div class="note"> |
| <p>Android Handheld, Watch, and Automotive implementations MUST include a |
| microphone.</p> |
| </div> |
| |
| |
| <p>Device implementations MAY omit a microphone. However, if a device |
| implementation omits a microphone, it MUST NOT report the |
| android.hardware.microphone feature constant, and MUST implement the audio |
| recording API at least as no-ops, per |
| <a href="#7_hardware_compatibility">section 7</a>. Conversely, device |
| implementations that do possess a microphone:</p> |
| |
| <ul> |
| <li>MUST report the android.hardware.microphone feature constant.</li> |
| <li>MUST meet the audio recording requirements in |
| <a href="#5_4_audio_recording">section 5.4</a>.</li> |
| <li>MUST meet the audio latency requirements in |
| <a href="#5_6_audio_latency">section 5.6</a>.</li> |
| <li>STRONGLY RECOMMENDED to support near-ultrasound recording as described in |
| <a href="#7_8_3_near_ultrasound">section 7.8.3</a>.</li> |
| </ul> |
| |
| <h3 id="7_8_2_audio_output">7.8.2. Audio Output</h3> |
| |
| <div class="note"> |
| <p>Android Watch devices MAY include an audio output.</p> |
| </div> |
| |
| <p>Device implementations including a speaker or with an audio/multimedia output |
| port for an audio output peripheral as a headset or an external speaker:</p> |
| |
| <ul> |
| <li>MUST report the android.hardware.audio.output feature constant.</li> |
| <li>MUST meet the audio playback requirements in |
| <a href="#5_5_audio_playback">section 5.5</a>.</li> |
| <li>MUST meet the audio latency requirements in |
| <a href="#5_6_audio_latency">section 5.6</a>.</li> |
| <li>STRONGLY RECOMMENDED to support near-ultrasound playback as described in |
| <a href="#7_8_3_near_ultrasound">section 7.8.3</a>.</li> |
| </ul> |
| |
| <p>Conversely, if a device implementation does not include a speaker or audio |
| output port, it MUST NOT report the android.hardware.audio output feature, and |
| MUST implement the Audio Output related APIs as no-ops at least. </p> |
| |
| <p>Android Watch device implementation MAY but SHOULD NOT have audio output, but |
| other types of Android device implementations MUST have an audio output and |
| declare android.hardware.audio.output.</p> |
| |
| <h4 id="7_8_2_1_analog_audio_ports">7.8.2.1. Analog Audio Ports</h4> |
| |
| |
| <p>In order to be compatible with the |
| <a href="http://source.android.com/accessories/headset-spec.html">headsets and |
| other audio accessories</a> using the 3.5mm audio plug across the Android |
| ecosystem, if a device implementation includes one or more analog audio ports, |
| at least one of the audio port(s) SHOULD be a 4 conductor 3.5mm audio jack. If a |
| device implementation has a 4 conductor 3.5mm audio jack, it:</p> |
| |
| <ul> |
| <li>MUST support audio playback to stereo headphones and stereo headsets with |
| a microphone, and SHOULD support audio recording from stereo headsets with a |
| microphone.</li> |
| <li>MUST support TRRS audio plugs with the CTIA pin-out order, and SHOULD |
| support audio plugs with the OMTP pin-out order.</li> |
| <li>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.</li> |
| <li>SHOULD 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: |
| <ul> |
| <li><strong>70 ohm or less</strong>: KEYCODE_HEADSETHOOK</li> |
| <li><strong>210-290 Ohm</strong>: KEYCODE_VOLUME_UP</li> |
| <li><strong>360-680 Ohm</strong>: KEYCODE_VOLUME_DOWN</li> |
| </ul></li> |
| <li>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: |
| <ul> |
| <li><strong>110-180 Ohm: </strong>KEYCODE_VOICE_ASSIST</li> |
| </ul></li> |
| <li>MUST trigger ACTION_HEADSET_PLUG upon a plug insert, but only after all |
| contacts on plug are touching their relevant segments on the jack.</li> |
| <li>MUST be capable of driving at least 150mV ± 10% of output voltage |
| on a 32 Ohm speaker impedance.</li> |
| <li>MUST have a microphone bias voltage between 1.8V ~ 2.9V.</li> |
| </ul> |
| |
| <h3 id="7_8_3_near_ultrasound">7.8.3. Near-Ultrasound </h3> |
| |
| <p>Near-Ultrasound audio is the 18.5 kHz to 20 kHz band. Device implementations |
| MUST correctly report the support of near-ultrasound audio capability via the |
| <a href="http://developer.android.com/reference/android/media/AudioManager.html#getProperty(java.lang.String)">AudioManager.getProperty</a> |
| API as follows: |
| </p> |
| |
| <ul> |
| <li>If |
| <a href="http://developer.android.com/reference/android/media/AudioManager.html#PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND">PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND</a> |
| is "true", then |
| <ul> |
| <li>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.</li> |
| <li>The signal to noise ratio of the microphone MUST be no lower than 80 dB. |
| </li> |
| </ul> |
| </li> |
| <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> |
| |
| <h1 id="8_performance_power">8. Performance and Power</h1> |
| |
| |
| <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">8.1. User Experience Consistency</h2> |
| |
| |
| <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> |
| |
| <ul> |
| <li><strong>Consistent frame latency</strong>. Inconsistent frame latency or a |
| delay to render frames MUST NOT happen more often than 5 frames in a second, |
| and SHOULD be below 1 frames in a second.</li> |
| <li><strong>User interface latency</strong>. Device implementations MUST |
| ensure low latency user experience by scrolling a list of 10K list entries as |
| defined by the Android Compatibility Test Suite (CTS) in less than 36 secs. |
| </li> |
| <li><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">8.2. File I/O Access Performance</h2> |
| |
| |
| <p>Device implementations MUST ensure internal storage file access performance |
| consistency for read and write operations.</p> |
| |
| <ul> |
| <li><strong>Sequential write</strong>. Device implementations MUST ensure a |
| sequential write performance of at least 5MB/s for a 256MB file using 10MB |
| write buffer.</li> |
| <li><strong>Random write</strong>. Device implementations MUST ensure a random |
| write performance of at least 0.5MB/s for a 256MB file using 4KB write buffer. |
| </li> |
| <li><strong>Sequential read</strong>. Device implementations MUST ensure a |
| sequential read performance of at least 15MB/s for a 256MB file using 10MB |
| write buffer.</li> |
| <li><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">8.3. Power-Saving Modes</h2> |
| |
| <p>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 Open Source Project.</p> |
| |
| <h2 id="8_4_power_consumption_accounting">8.4. Power Consumption Accounting</h2> |
| |
| <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> |
| |
| <ul> |
| <li>MUST be able to track hardware component power usage and attribute that |
| power usage to specific applications. Specifically, implementations: |
| <ul> |
| <li>MUST provide a per-component power profile that defines the |
| <a href="http://source.android.com/devices/tech/power/values.html">current |
| consumption value</a> for each hardware component and the approximate |
| battery drain caused by the components over time as documented in the |
| Android Open Source Project site.</li> |
| <li>MUST report all power consumption values in milliampere hours (mAh). |
| </li> |
| <li>SHOULD be attributed to the hardware component itself if unable to |
| attribute hardware component power usage to an application.</li> |
| <li>MUST report CPU power consumption per each process's UID. The Android |
| Open Source Project meets the requirement through the |
| <code>uid_cputime</code> kernel module implementation.</li> |
| </ul> |
| </li> |
| <li>MUST make this power usage available via the |
| <a href="http://source.android.com/devices/tech/power/batterystats.html"><code>adb |
| shell dumpsys batterystats</code></a> shell command to the app developer.</li> |
| <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> |
| |
| <h1 id="9_security_model_compatibility">9. Security Model Compatibility</h1> |
| |
| |
| <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">9.1. Permissions</h2> |
| |
| |
| <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> |
| |
| <p>Permissions with a protection level of dangerous are runtime permissions. |
| Applications with targetSdkVersion > 22 request them at runtime. Device |
| implementations:</p> |
| |
| <ul> |
| <li>MUST show a dedicated interface for the user to decide whether to grant |
| the requested runtime permissions and also provide an interface for the user |
| to manage runtime permissions.</li> |
| <li>MUST have one and only one implementation of both user interfaces.</li> |
| <li>MUST NOT grant any runtime permissions to preinstalled apps unless: |
| <ul> |
| <li>the user's consent can be obtained before the application uses it</li> |
| <li>the runtime permissions are associated with an intent pattern for which |
| the preinstalled application is set as the default handler</li> |
| </ul> |
| </li> |
| </ul> |
| |
| <h2 id="9_2_uid_and_process_isolation">9.2. UID and Process Isolation</h2> |
| |
| |
| <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">9.3. Filesystem Permissions</h2> |
| |
| |
| <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">9.4. Alternate Execution |
| Environments</h2> |
| |
| |
| <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> |
| |
| <p>Alternate runtimes MUST themselves be Android applications, and abide by the |
| standard Android security model, as described elsewhere in |
| <a href="#9_security_model_compatibility">section 9</a>.</p> |
| |
| <p>Alternate runtimes MUST NOT be granted access to resources protected by |
| permissions not requested in the runtime’s AndroidManifest.xml file via |
| the <uses-permission> mechanism.</p> |
| |
| <p>Alternate runtimes MUST NOT permit applications to make use of features |
| protected by Android permissions restricted to system applications.</p> |
| |
| <p>Alternate runtimes MUST abide by the Android sandbox model. Specifically, |
| alternate runtimes:</p> |
| |
| <ul> |
| <li>SHOULD install apps via the PackageManager into separate Android sandboxes |
| (Linux user IDs, etc.).</li> |
| <li>MAY provide a single Android sandbox shared by all applications using the |
| alternate runtime.</li> |
| <li>Installed applications using an alternate runtime MUST NOT reuse the |
| sandbox of any other app installed on the device, except through the standard |
| Android mechanisms of shared user ID and signing certificate.</li> |
| <li>MUST NOT launch with, grant, or be granted access to the sandboxes |
| corresponding to other Android applications.</li> |
| <li>MUST NOT be launched with, be granted, or grant to other applications any |
| privileges of the superuser (root), or of any other user ID.</li> |
| </ul> |
| |
| <p>The .apk files of alternate runtimes MAY be included in the system image of a |
| device implementation, but MUST be signed with a key distinct from the key used |
| to sign other applications included with the device implementation.</p> |
| |
| <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">9.5. Multi-User Support</h2> |
| |
| <div class="note"> |
| <p>This feature is optional for all device types.</p> |
| </div> |
| |
| |
| <p>Android includes |
| <a href="http://developer.android.com/reference/android/os/UserManager.html">support |
| for multiple users</a> and provides support for full user isolation. Device |
| implementations MAY enable multiple users, but when enabled MUST meet the |
| following requirements related to |
| <a href="http://source.android.com/devices/storage/traditional.html">multi-user |
| support</a>:</p> |
| |
| <ul> |
| <li>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 |
| restricted profiles, device owners can quickly set up separate environments |
| for additional users to work in, with the ability to manage finer-grained |
| restrictions in the apps that are available in those environments.</li> |
| <li>Conversely device implementations that declare the |
| android.hardware.telephony feature flag MUST NOT support restricted profiles |
| but MUST align with the AOSP implementation of controls to enable /disable |
| other users from accessing the voice calls and SMS.</li> |
| <li>Device implementations MUST, for each user, 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.</li> |
| <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">9.6. Premium SMS Warning</h2> |
| |
| |
| <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">9.7. Kernel Security Features</h2> |
| |
| |
| <p>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:</p> |
| |
| <ul> |
| <li>MUST maintain compatibility with existing applications.</li> |
| <li>MUST NOT have a visible user interface when a security violation is |
| detected and successfully blocked, but MAY have a visible user interface when |
| an unblocked security violation occurs resulting in a successful exploit.</li> |
| <li>SHOULD NOT be user or developer configurable.</li> |
| </ul> |
| |
| <p>If any API for configuration of policy is exposed to an application that can |
| affect another application (such as a Device Administration API), the API MUST |
| NOT allow configurations that break compatibility.</p> |
| |
| <p>Devices MUST implement SELinux or, if using a kernel other than Linux, an |
| equivalent mandatory access control system. Devices MUST also meet the |
| following requirements, which are satisfied by the reference implementation |
| in the upstream Android Open Source Project.</p> |
| |
| <p>Device implementations:</p> |
| |
| <ul> |
| <li>MUST set SELinux to global enforcing mode.</li> |
| <li>MUST configure all domains in enforcing mode. No permissive mode domains |
| are allowed, including domains specific to a device/vendor.</li> |
| <li>MUST NOT modify, omit, or replace the neverallow rules present within the |
| external/sepolicy folder provided in the upstream Android Open Source Project |
| (AOSP) and the policy MUST compile with all neverallow rules present, for both |
| AOSP SELinux domains as well as device/vendor specific domains.</li> |
| </ul> |
| |
| <p>Device implementations SHOULD retain the default SELinux policy provided in |
| the external/sepolicy folder of the upstream Android Open Source Project and |
| only further add to this policy for their own device-specific configuration. |
| Device implementations MUST be compatible with the upstream Android Open Source |
| Project.</p> |
| |
| <h2 id="9_8_privacy">9.8. Privacy</h2> |
| |
| <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.</p> |
| |
| <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_full-disk_encryption">9.9. Full-Disk Encryption</h2> |
| |
| <div class="note"> |
| <p>Optional for Android device implementations without a lock screen.</p> |
| </div> |
| |
| <p>If the device implementation supports a secure lock screen reporting |
| "<code>true</code>" for |
| <a href="http://developer.android.com/reference/android/app/KeyguardManager.html#isDeviceSecure()">KeyguardManager.isDeviceSecure()</a>, |
| and is not a device with restricted memory as reported through the |
| ActivityManager.isLowRamDevice() method, then the device MUST support full-disk |
| <a href="http://source.android.com/devices/tech/security/encryption/index.html">encryption</a> |
| of the application private data (/data partition), as well as the application |
| shared storage partition (/sdcard partition) if it is a permanent, non-removable |
| part of the device.</p> |
| |
| <p>For device implementations supporting full-disk encryption and with Advanced |
| Encryption Standard (AES) crypto performance above 50MiB/sec, the full-disk |
| encryption MUST be enabled by default at the time the user has completed the |
| out-of-box setup experience. If a device implementation is already launched on |
| an earlier Android version with full-disk encryption disabled by default, such a |
| device cannot meet the requirement through a system software update and thus MAY |
| be exempted.</p> |
| |
| <p>Encryption 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. Other than when in |
| active use, the encryption key SHOULD be AES encrypted with the lockscreen |
| passcode stretched using a slow stretching algorithm (e.g. PBKDF2 or scrypt). |
| If the user has not specified a lockscreen passcode 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_verified_boot">9.10. Verified Boot</h2> |
| |
| <p> |
| Verified boot is a feature that guarantees the integrity of the device software. |
| If a device implementation supports the feature, it MUST: |
| </p> |
| <ul> |
| <li>Declare the platform feature flag android.software.verified_boot.</li> |
| <li>Perform verification on every boot sequence.</li> |
| <li>Start verification from an immutable hardware key that is the root of |
| trust and go all the way up to the system partition.</li> |
| <li>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.</li> |
| <li>Use verification algorithms as strong as current recommendations from NIST |
| for hashing algorithms (SHA-256) and public key sizes (RSA-2048).</li> |
| </ul> |
| |
| <p>The upstream Android Open Source Project provides a preferred implementation |
| of this feature based on the Linux kernel feature dm-verity.</p> |
| |
| <p>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.</p> |
| |
| <h2 id="9_11_keys_and_credentials">9.11. Keys and Credentials</h2> |
| |
| <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> |
| |
| <p>All Android device implementations MUST meet the following requirements:</p> |
| |
| <ul> |
| <li>SHOULD not limit the number of keys that can be generated, and MUST at |
| least allow more than 8,192 keys to be imported.</li> |
| <li>The lock screen authentication MUST rate limit attempts and SHOULD have an |
| exponential backoff algorithm as implemented in the Android Open Source |
| Project.</li> |
| <li>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: |
| <ul> |
| <li>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.</li> |
| <li>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 |
| <a href="http://source.android.com/devices/tech/security/authentication/gatekeeper.html">Gatekeeper |
| Hardware Abstraction Layer (HAL)</a> that can be used to satisfy this |
| requirement.</li> |
| </ul> |
| </li> |
| </ul> |
| |
| <p>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.</p> |
| |
| <h2 id="9_12_data_deletion">9.12. Data Deletion</h2> |
| |
| <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 system |
| image and 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 <a href="#3_9_device_administration">section |
| 3.9 Device Administration</a>.</p> |
| |
| <p>Devices MAY provide a fast data wipe that conducts a logical data erase.</p> |
| |
| <h1 id="10_software_compatibility_testing">10. Software Compatibility |
| Testing</h1> |
| |
| |
| <p>Device implementations MUST pass all tests described in this section.</p> |
| |
| <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">10.1. Compatibility Test Suite</h2> |
| |
| |
| <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 6.0. Device implementations MUST pass the latest CTS version |
| available at the time the device software is completed.</p> |
| |
| <h2 id="10_2_cts_verifier">10.2. CTS Verifier</h2> |
| |
| |
| <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> |
| |
| <p>The CTS Verifier has tests for many kinds of hardware, including some |
| hardware that is optional. Device implementations MUST pass all tests for |
| hardware that they possess; for instance, if a device possesses an |
| accelerometer, it MUST correctly execute the Accelerometer test case in the CTS |
| Verifier. Test cases for features noted as optional by this Compatibility |
| Definition Document MAY be skipped or omitted.</p> |
| |
| <p>Every device and every build MUST correctly run the CTS Verifier, as noted |
| above. However, since many builds are very similar, device implementers are not |
| expected to explicitly run the CTS Verifier on builds that differ only in |
| trivial ways. Specifically, device implementations that differ from an |
| implementation that has passed the CTS Verifier only by the set of included |
| locales, branding, etc. MAY omit the CTS Verifier test.</p> |
| |
| <h1 id="11_updatable_software">11. Updatable Software</h1> |
| |
| |
| <p>Device implementations MUST include a mechanism to replace the entirety of |
| the system software. The mechanism need not perform “live” |
| upgrades—that is, a device restart MAY be required.</p> |
| |
| <p>Any method can be used, provided that it can replace the entirety of the |
| software preinstalled on the device. For instance, any of the following |
| approaches will satisfy this requirement:</p> |
| |
| <ul> |
| <li>“Over-the-air (OTA)” downloads with offline update via |
| reboot.</li> |
| <li>“Tethered” updates over USB from a host PC.</li> |
| <li>“Offline” updates via a reboot and update from a file on |
| removable storage.</li> |
| </ul> |
| |
| <p>However, if the device implementation includes support for an unmetered data |
| connection such as 802.11 or Bluetooth PAN (Personal Area Network) profile:</p> |
| |
| <ul> |
| <li>Android Automotive implementations SHOULD support OTA downloads with |
| offline update via reboot.</li> |
| <li>All other device implementations MUST support OTA downloads with offline |
| update via reboot.</li> |
| </ul> |
| |
| <p>The update mechanism used MUST support updates without wiping user data. That |
| is, the update mechanism MUST preserve application private data and application |
| shared data. Note that the upstream Android software includes an update |
| mechanism that satisfies this requirement.</p> |
| |
| <p>For device implementations that are launching with Android 6.0 |
| and later, the update mechanism SHOULD support verifying that the system image |
| is binary identical to expected result following an OTA. The block-based OTA |
| implementation in the upstream Android Open Source Project, added since Android |
| 5.1, satisfies this requirement.</p> |
| |
| <p>If an error is found in a device implementation after it has been released |
| but within its reasonable product lifetime that is determined in consultation |
| with the Android Compatibility Team to affect the compatibility of third-party |
| applications, the device implementer MUST correct the error via a software |
| update available that can be applied per the mechanism just described.</p> |
| |
| <p>Android includes features that allow the Device Owner app (if present) to |
| control the installation of system updates. To facilitate this, the system |
| update subsystem for devices that report android.software.device_admin MUST |
| implement the behavior described in the |
| <a href="http://developer.android.com/reference/android/app/admin/SystemUpdatePolicy.html">SystemUpdatePolicy</a> |
| class.</p> |
| |
| <h1 id="12_document_changelog">12. Document Changelog</h1> |
| |
| <p>For a summary of changes to the Compatibility Definition in this release, |
| refer to the <a href="https://android.googlesource.com/platform/docs/source.android.com/+log/master/src/compatibility/android-cdd.html">changelog</a>. |
| </p> |
| |
| <h1 id="13_contact_us">13. Contact Us</h1> |
| |
| <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> |