| <!DOCTYPE html> |
| <html> |
| <head> |
| <title> |
| Android 7.1 Compatibility Definition |
| </title> |
| <link href="source/android-cdd.css" rel="stylesheet" type="text/css"/> |
| </head> |
| <body> |
| <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_1_1_android_extensions"> |
| 3.1.1. Android Extensions |
| </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_h4"> |
| <a href="#3_3_1_1_graphic_libraries"> |
| 3.3.1.1. Graphic Libraries |
| </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> |
| </div> |
| <div id="toc_right"> |
| <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_screen_savers_(previously_dreams)"> |
| 3.8.11. Screen savers (previously Dreams) |
| </a> |
| </p> |
| <p class="toc_h3"> |
| <a href="#3_8_12_location"> |
| 3.8.12. Location |
| </a> |
| </p> |
| <p class="toc_h3"> |
| <a href="#3_8_13_unicode_and_font"> |
| 3.8.13. Unicode and Font |
| </a> |
| </p> |
| <p class="toc_h3"> |
| <a href="#3_8_14_multi-windows"> |
| 3.8.14. Multi-windows |
| </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_1_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_h2"> |
| <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_h4"> |
| <a href="#3_12_1_4_time_shifting"> |
| 3.12.1.4. Time shifting |
| </a> |
| </p> |
| <p class="toc_h4"> |
| <a href="#3_12_1_5_tv_recording"> |
| 3.12.1.5. TV recording |
| </a> |
| </p> |
| <p class="toc_h2"> |
| <a href="#3_13_quick_settings"> |
| 3.13. Quick Settings |
| </a> |
| </p> |
| <p class="toc_h2"> |
| <a href="#3_14_vehicle_ui_apis"> |
| 3.14. Vehicle UI APIs |
| </a> |
| </p> |
| <p class="toc_h3"> |
| <a href="#3_14_1__vehicle_media_ui"> |
| 3.14.1. Vehicle Media UI |
| </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_h3"> |
| <a href="#5_2_1_h_263"> |
| 5.2.1. H.263 |
| </a> |
| </p> |
| <p class="toc_h3"> |
| <a href="#5_2_2_h-264"> |
| 5.2.2. H-264 |
| </a> |
| </p> |
| <p class="toc_h3"> |
| <a href="#5_2_3_vp8"> |
| 5.2.3. VP8 |
| </a> |
| </p> |
| <p class="toc_h2"> |
| <a href="#5_3_video_decoding"> |
| 5.3. Video Decoding |
| </a> |
| </p> |
| </div> |
| <div style="clear: both; page-break-after:always; height:1px"> |
| </div> |
| <div id="toc_left"> |
| <p class="toc_h3"> |
| <a href="#5_3_1_mpeg-2"> |
| 5.3.1. MPEG-2 |
| </a> |
| </p> |
| <p class="toc_h3"> |
| <a href="#5_3_2_h_263"> |
| 5.3.2. H.263 |
| </a> |
| </p> |
| <p class="toc_h3"> |
| <a href="#5_3_3_mpeg-4"> |
| 5.3.3. MPEG-4 |
| </a> |
| </p> |
| <p class="toc_h3"> |
| <a href="#5_3_4_h_264"> |
| 5.3.4. H.264 |
| </a> |
| </p> |
| <p class="toc_h3"> |
| <a href="#5_3_5_h_265_(hevc)"> |
| 5.3.5. H.265 (HEVC) |
| </a> |
| </p> |
| <p class="toc_h3"> |
| <a href="#5_3_6_vp8"> |
| 5.3.6. VP8 |
| </a> |
| </p> |
| <p class="toc_h3"> |
| <a href="#5_3_7_vp9"> |
| 5.3.7. VP9 |
| </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_musical_instrument_digital_interface_(midi)"> |
| 5.9. Musical Instrument Digital Interface (MIDI) |
| </a> |
| </p> |
| <p class="toc_h2"> |
| <a href="#5_10_professional_audio"> |
| 5.10. Professional Audio |
| </a> |
| </p> |
| <p class="toc_h2"> |
| <a href="#5_11_capture_for_unprocessed"> |
| 5.11. Capture for Unprocessed |
| </a> |
| </p> |
| <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> |
| </div> |
| <div id="toc_right"> |
| <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_secondary_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_mappings"> |
| 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> |
| <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_high_fidelity_sensors"> |
| 7.3.9. High Fidelity Sensors |
| </a> |
| </p> |
| <p class="toc_h3"> |
| <a href="#7_3_10_fingerprint_sensor"> |
| 7.3.10. Fingerprint Sensor |
| </a> |
| </p> |
| <p class="toc_h3"> |
| <a href="#7_3_11_android_automotive-only_sensors"> |
| 7.3.11. Android Automotive-only sensors |
| </a> |
| </p> |
| <p class="toc_h4"> |
| <a href="#7_3_11_1_current_gear"> |
| 7.3.11.1. Current Gear |
| </a> |
| </p> |
| <p class="toc_h4"> |
| <a href="#7_3_11_2_day_night_mode"> |
| 7.3.11.2. Day Night Mode |
| </a> |
| </p> |
| <p class="toc_h4"> |
| <a href="#7_3_11_3_driving_status"> |
| 7.3.11.3. Driving Status |
| </a> |
| </p> |
| <p class="toc_h4"> |
| <a href="#7_3_11_4_wheel_speed"> |
| 7.3.11.4. Wheel Speed |
| </a> |
| </p> |
| <p class="toc_h2"> |
| <a href="#7_3_12_pose_sensor"> |
| 7.3.12. Pose 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_h4"> |
| <a href="#7_4_1_1_number_blocking_compatibility"> |
| 7.4.1.1. Number Blocking Compatibility |
| </a> |
| </p> |
| <p class="toc_h3"> |
| <a href="#7_4_2_ieee_802_11_(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> |
| </div> |
| <div style="clear: both; page-break-after:always; height:1px"> |
| </div> |
| <div id="toc_left"> |
| <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_h3"> |
| <a href="#7_4_7_data_saver"> |
| 7.4.7. Data Saver |
| </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_h3"> |
| <a href="#7_7_1_usb_peripheral_mode"> |
| 7.7.1. USB peripheral mode |
| </a> |
| </p> |
| <p class="toc_h3"> |
| <a href="#7_7_2_usb_host_mode"> |
| 7.7.2. USB host mode |
| </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_h2"> |
| <a href="#7_9_virtual_reality"> |
| 7.9. Virtual Reality |
| </a> |
| </p> |
| <p class="toc_h3"> |
| <a href="#7_9_1_virtual_reality_mode"> |
| 7.9.1. Virtual Reality Mode |
| </a> |
| </p> |
| <p class="toc_h3"> |
| <a href="#7_9_2_virtual_reality_high_performance"> |
| 7.9.2. Virtual Reality High Performance |
| </a> |
| </p> |
| <p class="toc_h1"> |
| <a href="#8_performance_and_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> |
| <p class="toc_h2"> |
| <a href="#8_5_consistent_performance"> |
| 8.5. Consistent Performance |
| </a> |
| </p> |
| <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> |
| </div> |
| <div id="toc_right"> |
| <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_data_storage_encryption"> |
| 9.9. Data Storage Encryption |
| </a> |
| </p> |
| <p class="toc_h3"> |
| <a href="#9_9_1_direct_boot"> |
| 9.9.1. Direct Boot |
| </a> |
| </p> |
| <p class="toc_h3"> |
| <a href="#9_9_2_file_based_encryption"> |
| 9.9.2. File Based Encryption |
| </a> |
| </p> |
| <p class="toc_h3"> |
| <a href="#9_9_3_full_disk_encryption"> |
| 9.9.3. Full Disk Encryption |
| </a> |
| </p> |
| <p class="toc_h2"> |
| <a href="#9_10_device_integrity"> |
| 9.10. Device Integrity |
| </a> |
| </p> |
| <p class="toc_h2"> |
| <a href="#9_11_keys_and_credentials"> |
| 9.11. Keys and Credentials |
| </a> |
| </p> |
| <p class="toc_h3"> |
| <a href="#9_11_1_secure_lock_screen"> |
| 9.11.1. Secure Lock Screen |
| </a> |
| </p> |
| <p class="toc_h2"> |
| <a href="#9_12_data_deletion"> |
| 9.12. Data Deletion |
| </a> |
| </p> |
| <p class="toc_h2"> |
| <a href="#9_13_safe_boot_mode"> |
| 9.13. Safe Boot Mode |
| </a> |
| </p> |
| <p class="toc_h2"> |
| <a href="#9_14_automotive_vehicle_system_isolation"> |
| 9.14. Automotive Vehicle System Isolation |
| </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_h2"> |
| <a href="#12_1_changelog_viewing_tips"> |
| 12.1. Changelog Viewing Tips |
| </a> |
| </p> |
| <p class="toc_h1"> |
| <a href="#13_contact_us"> |
| 13. Contact Us |
| </a> |
| </p> |
| </div> |
| <div style="clear: both; page-break-after:always; height:1px"> |
| </div> |
| <div style="clear: both"> |
| </div> |
| </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 7.1. |
| </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 |
| 7.1. A “device implementation” or “implementation is the |
| hardware/software solution so developed. |
| </p> |
| <p> |
| To be considered compatible with Android 7.1, 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 have a screen with the physical diagonal length equal to or greater |
| than 6 inches. |
| </li> |
| <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> |
| <li> |
| Android Automotive implementations MUST support all public APIs in the |
| <code> |
| android.car.* |
| </code> |
| namespace. |
| </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 |
| 7.1 compatible, unless the requirement is explicitly described to |
| be only applicable to a specific Android device type from above. |
| </p> |
| <h2 id="2_1_device_configurations"> |
| 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="6"> |
| Connectivity |
| </td> |
| <td> |
| Wi-Fi |
| </td> |
| <td> |
| <a href="#7_4_2_ieee_802.11"> |
| 7.4.2. IEEE 802.11 |
| </a> |
| </td> |
| <td> |
| SHOULD |
| </td> |
| <td> |
| SHOULD |
| </td> |
| <td> |
| </td> |
| <td> |
| SHOULD |
| </td> |
| <td> |
| SHOULD |
| </td> |
| </tr> |
| <tr> |
| <td> |
| Wi-Fi Direct |
| </td> |
| <td> |
| <a href="#7_4_2_1_wi-fi-direct"> |
| 7.4.2.1. Wi-Fi Direct |
| </a> |
| </td> |
| <td> |
| SHOULD |
| </td> |
| <td> |
| SHOULD |
| </td> |
| <td> |
| </td> |
| <td> |
| </td> |
| <td> |
| SHOULD |
| </td> |
| </tr> |
| <tr> |
| <td> |
| Bluetooth |
| </td> |
| <td> |
| <a href="#7_4_3_bluetooth"> |
| 7.4.3. Bluetooth |
| </a> |
| </td> |
| <td> |
| SHOULD |
| </td> |
| <td> |
| MUST |
| </td> |
| <td> |
| MUST |
| </td> |
| <td> |
| MUST |
| </td> |
| <td> |
| SHOULD |
| </td> |
| </tr> |
| <tr> |
| <td> |
| Bluetooth Low Energy |
| </td> |
| <td> |
| <a href="#7_4_3_bluetooth"> |
| 7.4.3. Bluetooth |
| </a> |
| </td> |
| <td> |
| SHOULD |
| </td> |
| <td> |
| MUST |
| </td> |
| <td> |
| SHOULD |
| </td> |
| <td> |
| SHOULD |
| </td> |
| <td> |
| SHOULD |
| </td> |
| </tr> |
| <tr> |
| <td> |
| Cellular radio |
| </td> |
| <td> |
| <a href="#7_4_5_minimum_network_capability"> |
| 7.4.5. Minimum Network Capability |
| </a> |
| </td> |
| <td> |
| </td> |
| <td> |
| </td> |
| <td> |
| </td> |
| <td> |
| SHOULD |
| </td> |
| <td> |
| </td> |
| </tr> |
| <tr> |
| <td> |
| USB 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 support/preserve all classes, methods, and |
| associated elements marked by the TestApi annotation (@TestApi). |
| </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_1_1_android_extensions"> |
| 3.1.1. Android Extensions |
| </h2> |
| <p> |
| Android includes the support of extending the managed APIs while keeping the same API |
| level version. Android device implementations MUST preload the AOSP implementation |
| of both the shared library |
| <code> |
| ExtShared |
| </code> |
| and services |
| <code> |
| ExtServices |
| </code> |
| with versions higher |
| than or equal to the minimum versions allowed per each API level. |
| For example, Android 7.0 device implementations, running API level 24 MUST include |
| at least version 1. |
| </p> |
| <h2 id="3_2_soft_api_compatibility"> |
| 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/7.1/versions.html"> |
| 7.1 |
| </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 7.1, |
| this field MUST have the integer value 7.1_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 7.1, |
| this field MUST have the integer value 7.1_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_-]+$”. This device name MUST NOT change during the |
| lifetime of the product. |
| </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:7.1/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_-]+$”. This product |
| name MUST NOT change during the lifetime of the product. |
| </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 empty string (""). |
| </td> |
| </tr> |
| </table> |
| <h3 id="3_2_3_intent_compatibility"> |
| 3.2.3. Intent Compatibility |
| </h3> |
| <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 MUST include the core Android applications as |
| appropriate or a component implementing the same intent patterns defined by |
| all the Activity or Service components of these core Android applications |
| exposed to other applications, implicitly or explicitly, through the |
| <code> |
| android:exported |
| </code> |
| attribute. |
| </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. |
| <em> |
| or com.android. |
| </em> |
| 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> |
| <li> |
| MUST honor the |
| <a href="https://developer.android.com/reference/android/telecom/TelecomManager.html#ACTION_CHANGE_DEFAULT_DIALER"> |
| android.telecom.action.CHANGE_DEFAULT_DIALER |
| </a> |
| intent to show a dialog to allow the user to change the default Phone application, if the |
| device implementation reports |
| <code> |
| android.hardware.telephony |
| </code> |
| . |
| </li> |
| <li> |
| MUST honor the |
| <a href="https://developer.android.com/reference/android/provider/Settings.html#ACTION_VOICE_INPUT_SETTINGS"> |
| android.settings.ACTION_VOICE_INPUT_SETTINGS |
| </a> |
| intent when the device supports the VoiceInteractionService and show a |
| default app settings menu for voice input and assist. |
| </li> |
| </ul> |
| <h2 id="3_3_native_api_compatibility"> |
| 3.3. Native API Compatibility |
| </h2> |
| <p> |
| Native code compatibility is challenging. For this reason, device implementers |
| are |
| <strong> |
| STRONGLY RECOMMENDED |
| </strong> |
| to use the implementations of the libraries listed |
| below from the upstream Android Open Source Project. |
| </p> |
| <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> |
| 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> |
| The following native code APIs MUST be available to apps that include native code: |
| </p> |
| <ul> |
| <li> |
| libandroid.so (native Android activity support) |
| </li> |
| <li> |
| libc (C library) |
| </li> |
| <li> |
| libcamera2ndk.so |
| </li> |
| <li> |
| libdl (dynamic linker) |
| </li> |
| <li> |
| libEGL.so (native OpenGL surface management) |
| </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> |
| libicui18n.so |
| </li> |
| <li> |
| libicuuc.so |
| </li> |
| <li> |
| libjnigraphics.so |
| </li> |
| <li> |
| liblog (Android logging) |
| </li> |
| <li> |
| libmediandk.so (native media APIs support) |
| </li> |
| <li> |
| libm (math library) |
| </li> |
| <li> |
| libOpenMAXAL.so (OpenMAX AL 1.0.1 support) |
| </li> |
| <li> |
| libOpenSLES.so (OpenSL ES 1.0.1 audio support) |
| </li> |
| <li> |
| libRS.so |
| </li> |
| <li> |
| libstdc++ (Minimal support for C++) |
| </li> |
| <li> |
| libvulkan.so (Vulkan) |
| </li> |
| <li> |
| libz (Zlib compression) |
| </li> |
| <li> |
| JNI interface |
| </li> |
| <li> |
| Support for OpenGL, as described below |
| </li> |
| </ul> |
| <p> |
| For the native libraries listed above, the device implementation MUST NOT add |
| or remove the public functions. |
| </p> |
| <p> |
| Native libraries not listed above but implemented and provided in AOSP as system |
| libraries are reserved and MUST NOT be exposed to third-party apps targeting API |
| level 24 or higher. |
| </p> |
| <p> |
| Device implementations MAY add non-AOSP libraries and expose them directly as |
| an API to third-party apps but the additional libraries SHOULD be in |
| <code> |
| /vendor/lib |
| </code> |
| or |
| <code> |
| /vendor/lib64 |
| </code> |
| and MUST be listed in |
| <code> |
| /vendor/etc/public.libraries.txt |
| </code> |
| . |
| </p> |
| <p> |
| Note that device implementations MUST include libGLESv3.so and 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-24. 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> |
| <h4 id="3_3_1_1_graphic_libraries"> |
| 3.3.1.1. Graphic Libraries |
| </h4> |
| <p> |
| <a href="https://www.khronos.org/registry/vulkan/specs/1.0-wsi_extensions/xhtml/vkspec.html"> |
| Vulkan |
| </a> |
| is a low-overhead, cross-platform API for high-performance 3D graphics. Device |
| implementations, even if not including support of the Vulkan APIs, MUST satisfy |
| the following requirements: |
| </p> |
| <ul> |
| <li> |
| It MUST always provide a native library named |
| <code> |
| libvulkan.so |
| </code> |
| which exports |
| function symbols for the core Vulkan 1.0 API as well as the |
| <code> |
| VK_KHR_surface |
| </code> |
| , |
| <code> |
| VK_KHR_android_surface |
| </code> |
| , and |
| <code> |
| VK_KHR_swapchain |
| </code> |
| extensions. |
| </li> |
| </ul> |
| <p> |
| Device implementations, if including support of the Vulkan APIs: |
| </p> |
| <ul> |
| <li> |
| MUST report, one or more |
| <code> |
| VkPhysicalDevices |
| </code> |
| through the |
| <code> |
| vkEnumeratePhysicalDevices |
| </code> |
| call. |
| </li> |
| <li> |
| Each enumerated |
| <code> |
| VkPhysicalDevices |
| </code> |
| MUST fully implement the Vulkan 1.0 API. |
| </li> |
| <li> |
| MUST report the correct |
| <a href="https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_VULKAN_HARDWARE_LEVEL"> |
| <code> |
| PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL |
| </code> |
| </a> |
| and |
| <a href="https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_VULKAN_HARDWARE_VERSION"> |
| <code> |
| PackageManager#FEATURE_VULKAN_HARDWARE_VERSION |
| </code> |
| </a> |
| feature flags. |
| </li> |
| <li> |
| MUST enumerate layers, contained in native libraries named |
| <code> |
| libVkLayer*.so |
| </code> |
| in the application package’s native library directory, through the |
| <code> |
| vkEnumerateInstanceLayerProperties |
| </code> |
| and |
| <code> |
| vkEnumerateDeviceLayerProperties |
| </code> |
| functions in |
| <code> |
| libvulkan.so |
| </code> |
| </li> |
| <li> |
| MUST NOT enumerate layers provided by libraries outside of the application |
| package, or provide other ways of tracing or intercepting the Vulkan API, |
| unless the application has the |
| <code> |
| android:debuggable=”true” |
| </code> |
| attribute. |
| </li> |
| </ul> |
| <p> |
| Device implementations, if not including support of the Vulkan APIs: |
| </p> |
| <ul> |
| <li> |
| MUST report 0 |
| <code> |
| VkPhysicalDevices |
| </code> |
| through the |
| <code> |
| vkEnumeratePhysicalDevices |
| </code> |
| call. |
| </li> |
| <li> |
| MUST NOT declare any of the Vulkan feature flags |
| <a href="https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_VULKAN_HARDWARE_LEVEL"> |
| <code> |
| PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL |
| </code> |
| </a> |
| and |
| <a href="https://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_VULKAN_HARDWARE_VERSION"> |
| <code> |
| PackageManager#FEATURE_VULKAN_HARDWARE_VERSION |
| </code> |
| </a> |
| . |
| </li> |
| </ul> |
| <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"> |
| Android Watch devices MAY, but all other device implementations MUST provide a |
| complete implementation of the android.webkit.Webview API. |
| </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 7.1. This build includes a specific |
| set of functionality and security fixes for the WebView. |
| </li> |
| <li> |
| <p> |
| The user agent string reported by the WebView MUST be in this format: |
| </p> |
| <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"> |
| 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. |
| </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 |
| <uses-library> 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"> |
| Widgets are optional for all Android device implementations, but SHOULD be |
| supported on Android Handheld devices. |
| </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> |
| <li> |
| SHOULD trigger the fast-switch action between the two most recently used apps, |
| when the recents function key is tapped twice. |
| </li> |
| <li> |
| SHOULD trigger the split-screen multiwindow-mode, if supported, when the recents |
| functions key is long pressed. |
| </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> |
| <div class="note"> |
| Android Automotive implementations MAY manage the visibility and timing of |
| notifications to mitigate driver distraction, but MUST display |
| notifications that use |
| <a href="https://developer.android.com/reference/android/app/Notification.CarExtender.html"> |
| CarExtender |
| </a> |
| when requested by applications. |
| </div> |
| <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> |
| Lock screen 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> |
| <p> |
| Handheld device implementations MUST support the behaviors of updating, |
| removing, replying to, and bundling notifications as described in this |
| <a href="https://developer.android.com/guide/topics/ui/notifiers/notifications.html#Managing"> |
| section |
| </a> |
| . |
| </p> |
| <p> |
| Also, handheld device implementations MUST provide: |
| </p> |
| <ul> |
| <li> |
| The ability to control notifications directly in the notification shade. |
| </li> |
| <li> |
| The visual affordance to trigger the control panel in the notification shade. |
| </li> |
| <li> |
| The ability to BLOCK, MUTE and RESET notification preference from a |
| package, both in the inline control panel as well as in the settings app. |
| </li> |
| </ul> |
| <p> |
| All 6 direct subclasses of the |
| <code> |
| Notification.Style class |
| </code> |
| MUST be supported as |
| described in the |
| <a href="https://developer.android.com/reference/android/app/Notification.Style.html"> |
| SDK documents |
| </a> |
| . |
| </p> |
| <p> |
| Device implementations that support the DND (Do not Disturb) feature MUST meet |
| the following requirements: |
| </p> |
| <ul> |
| <li> |
| MUST implement an activity where the user can grant or deny the app access |
| to DND policy configurations in response to the intent |
| <a href="https://developer.android.com/reference/android/provider/Settings.html#ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS"> |
| ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS |
| </a> |
| . |
| </li> |
| <li> |
| MUST display |
| <a href="https://developer.android.com/reference/android/app/NotificationManager.html#addAutomaticZenRule%28android.app.AutomaticZenRule%29"> |
| Automatic DND rules |
| </a> |
| created by applications alongside the user-created and pre-defined rules. |
| </li> |
| <li> |
| MUST honor the |
| <a href="https://developer.android.com/reference/android/app/NotificationManager.Policy.html#suppressedVisualEffects"> |
| <code> |
| suppressedVisualEffects |
| </code> |
| </a> |
| values passed along the |
| <a href="https://developer.android.com/reference/android/app/NotificationManager.Policy.html#NotificationManager.Policy%28int, int, int, int%29"> |
| <code> |
| NotificationManager.Policy |
| </code> |
| </a> |
| and if an app has set any of the SUPPRESSED_EFFECT_SCREEN_OFF or |
| SUPPRESSED_EFFECT_SCREEN_ON flags, it SHOULD indicate to the user that the |
| visual effects are suppressed in the DND settings menu. |
| </li> |
| </ul> |
| <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, and Android Automotive implementations |
| MUST, 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 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> |
| <p> |
| This indication MAY be disabled by default for preinstalled apps using the Assist and |
| VoiceInteractionService API, if all following requirements are met: |
| </p> |
| <ul> |
| <li> |
| <p> |
| The preinstalled app MUST request the context to be shared only when the |
| user invoked the app by one of the following means, and the app is running in the |
| foreground: |
| </p> |
| <ul> |
| <li> |
| hotword invocation |
| </li> |
| <li> |
| input of the ASSIST navigation key/button/gesture |
| </li> |
| </ul> |
| </li> |
| <li> |
| <p> |
| The device implementation MUST provide an affordance to enable the |
| indication, less than two navigations away from |
| (the default voice input and assistant app settings menu) |
| <a href="#3_2_3_5_default_app_settings"> |
| section 3.2.3.5 |
| </a> |
| . |
| </p> |
| </li> |
| </ul> |
| <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"> |
| As the Recent function navigation key is OPTIONAL, the requirement to implement |
| the overview screen is OPTIONAL for Android Watch and Android Automotive implementations, |
| and RECOMMENDED for Android Television devices. There SHOULD still be a |
| method to switch between activities on Android Automotive implementations. |
| </div> |
| <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 support at least up to 20 displayed activities. |
| </li> |
| <li> |
| SHOULD display the titles of at least 4 activities at a time. |
| </li> |
| <li> |
| MUST implement the |
| <a href="http://developer.android.com/about/versions/android-5.0.html#ScreenPinning"> |
| screen pinning behavior |
| </a> |
| and provide the user with a settings menu to toggle the feature. |
| </li> |
| <li> |
| SHOULD display highlight color, icon, screen title in recents. |
| </li> |
| <li> |
| SHOULD display a closing affordance ("x") but MAY delay this until user interacts with screens. |
| </li> |
| <li> |
| SHOULD implement a shortcut to switch easily to the previous activity |
| </li> |
| <li> |
| MAY display affiliated recents as a group that moves together. |
| </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 |
| Lock screen Notifications including the Media Notification Template. |
| </p> |
| <h3 id="3_8_11_screen_savers_(previously_dreams)"> |
| 3.8.11. Screen savers (previously Dreams) |
| </h3> |
| <p> |
| Android includes support for |
| <a href="http://developer.android.com/reference/android/service/dreams/DreamService.html"> |
| interactivescreensavers |
| </a> |
| , |
| previously referred to as Dreams. Screen savers allow users to interact with |
| applications when a device connected to a power source is idle or docked in a |
| desk dock. Android Watch devices MAY implement screen savers, but other types |
| of device implementations SHOULD include support for screen savers and provide |
| a settings option for users toconfigure screen savers in response to the |
| <code> |
| android.settings.DREAM_SETTINGS |
| </code> |
| 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 the emoji characters defined in |
| <a href="http://www.unicode.org/versions/Unicode9.0.0/"> |
| Unicode 9.0 |
| </a> |
| . All device |
| implementations MUST be capable of rendering these emoji characters |
| in color glyph and when Android device implementations include an IME, |
| it SHOULD provide an input method to the user for these emoji characters. |
| </p> |
| <p> |
| Android handheld devices SHOULD support the skin tone and diverse family emojis |
| as specified in the |
| <a href="http://unicode.org/reports/tr51"> |
| Unicode Technical Report #51 |
| </a> |
| . |
| </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> |
| <h3 id="3_8_14_multi-windows"> |
| 3.8.14. Multi-windows |
| </h3> |
| <p> |
| A device implementation MAY choose not to implement any multi-window modes, but |
| if it has the capability to display multiple activities at the same time it |
| MUST implement such multi-window mode(s) in accordance with the application |
| behaviors and APIs described in the Android SDK |
| <a href="https://developer.android.com/preview/features/multi-window.html"> |
| multi-window mode support documentation |
| </a> |
| and meet the following requirements: |
| </p> |
| <ul> |
| <li> |
| Applications can indicate whether they are capable of operating in |
| multi-window mode in the AndroidManifest.xml file, either explicitly via the |
| <a href="https://developer.android.com/reference/android/R.attr.html#resizeableActivity"> |
| <code> |
| android:resizeableActivity |
| </code> |
| </a> |
| attribute or implicitly by having the targetSdkVersion > 24. Apps that |
| explicitly set this attribute to false in their manifest MUST not be |
| launched in multi-window mode. Apps that don't set the attribute in their |
| manifest file (targetSdkVersion < 24) can be launched in multi-window mode, |
| but the system MUST provide warning that the app may not work as expected in |
| multi-window mode. |
| </li> |
| <li> |
| Device implementations MUST NOT offer split-screen or freeform mode |
| if both the screen height and width is less than 440 dp. |
| </li> |
| <li> |
| Device implementations with screen size |
| <code> |
| xlarge |
| </code> |
| SHOULD support freeform mode. |
| </li> |
| <li> |
| Android Television device implementations MUST support picture-in-picture (PIP) mode multi-window |
| and place the PIP multi-window in the top right corner when PIP is ON. |
| </li> |
| <li> |
| Device implementations with PIP mode multi-window support |
| MUST allocate at least 240x135 dp for the PIP window. |
| </li> |
| <li> |
| If the PIP multi-window mode is supported the |
| <a href="https://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_WINDOW"> |
| <code> |
| KeyEvent.KEYCODE_WINDOW |
| </code> |
| </a> |
| key MUST be used to control the PIP window; otherwise, the key MUST be |
| available to the foreground activity. |
| </li> |
| </ul> |
| <h2 id="3_9_device_administration"> |
| 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 supports a secure lock screen MUST implement |
| the full range of |
| <a href="http://developer.android.com/guide/topics/admin/device-admin.html"> |
| device administration |
| </a> |
| policies defined in the Android SDK documentation and report the platform |
| feature android.software.device_admin. |
| </p> |
| <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 |
| <code> |
| android.software.device_admin |
| </code> |
| feature |
| then it MUST implement the provisioning of the |
| <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)"> |
| Device Owner app |
| </a> |
| of a Device Policy Client (DPC) application as indicated below: |
| </p> |
| <ul> |
| <li> |
| When the device implementation has no user data configured yet, it: |
| <ul> |
| <li> |
| MUST report |
| <code> |
| true |
| </code> |
| for |
| <a href="https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isProvisioningAllowed(java.lang.String)"> |
| <code> |
| DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) |
| </code> |
| </a> |
| . |
| </li> |
| <li> |
| MUST enroll the DPC application as the Device Owner app in response to |
| the intent action |
| <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_DEVICE"> |
| <code> |
| android.app.action.PROVISION_MANAGED_DEVICE |
| </code> |
| </a> |
| . |
| </li> |
| <li> |
| MUST enroll the DPC application as the Device Owner app if the device |
| declares Near-Field Communications (NFC) support via the feature flag |
| <code> |
| android.hardware.nfc |
| </code> |
| and receives an NFC message containing a record |
| with MIME type |
| <a href="https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#MIME_TYPE_PROVISIONING_NFC"> |
| <code> |
| MIME_TYPE_PROVISIONING_NFC |
| </code> |
| </a> |
| . |
| </li> |
| </ul> |
| </li> |
| <li> |
| When the device implementation has user data, it: |
| <ul> |
| <li> |
| MUST report |
| <code> |
| false |
| </code> |
| for the |
| <a href="https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isProvisioningAllowed(java.lang.String)"> |
| <code> |
| DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) |
| </code> |
| </a> |
| . |
| </li> |
| <li> |
| MUST not enroll any DPC application as the Device Owner App any more. |
| </li> |
| </ul> |
| </li> |
| </ul> |
| <p> |
| 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> |
| <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> |
| <p> |
| Device implementations MUST provide the following user affordances within the |
| Settings user interface to indicate to the user when a particular system function |
| has been disabled by the Device Policy Controller (DPC): |
| </p> |
| <ul> |
| <li> |
| A consistent icon or other user affordance (for example the upstream AOSP |
| info icon) to represent when a particular setting is restricted by a |
| Device Admin. |
| </li> |
| <li> |
| A short explanation message, as provided by the Device Admin via the |
| <a href="https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setShortSupportMessage%28android.content.ComponentName, java.lang.CharSequence%29"> |
| <code> |
| setShortSupportMessage |
| </code> |
| </a> |
| . |
| </li> |
| <li> |
| The DPC application’s icon. |
| </li> |
| </ul> |
| <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 |
| <code> |
| android.software.managed_users |
| </code> |
| . |
| </li> |
| <li> |
| Support managed profiles via the |
| <code> |
| android.app.admin.DevicePolicyManager |
| </code> |
| 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 preinstalled dialer, contacts and messaging applications can |
| search for and look up caller information from the managed profile (if one |
| exists) alongside those from the primary profile, if the Device Policy |
| Controller permits it. When contacts from the managed profile are displayed |
| in the preinstalled call log, in-call UI, in-progress and missed-call |
| notifications, contacts and messaging apps they SHOULD be badged with the |
| same badge used to indicate managed profile applications. |
| </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> |
| <li> |
| Support the ability to specify a separate lock screen meeting the following |
| requirements to grant access to apps running in a managed profile. |
| <ul> |
| <li> |
| Device implementations MUST honor the |
| <a href="https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_SET_NEW_PASSWORD"> |
| <code> |
| DevicePolicyManager.ACTION_SET_NEW_PASSWORD |
| </code> |
| </a> |
| intent and show an interface to configure a separate lock screen |
| credential for the managed profile. |
| </li> |
| <li> |
| The lock screen credentials of the managed profile MUST use the same |
| credential storage and management mechanisms as the parent profile, |
| as documented on the |
| <a href="http://source.android.com/security/authentication/index.html"> |
| Android Open Source Project Site |
| </a> |
| </li> |
| <li> |
| The DPC |
| <a href="https://developer.android.com/guide/topics/admin/device-admin.html#pwd"> |
| password policies |
| </a> |
| MUST apply to only the managed profile's lock screen credentials unless |
| called upon the |
| <code> |
| DevicePolicyManager |
| </code> |
| instance returned by |
| <a href="https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#getParentProfileInstance%28android.content.ComponentName%29"> |
| getParentProfileInstance |
| </a> |
| . |
| </li> |
| </ul> |
| </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> |
| <p> |
| 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. |
| </p> |
| </li> |
| <li> |
| <p> |
| Android device implementations with audio output are STRONGLY RECOMMENDED to provide |
| implementations of accessibility services on the device comparable in or exceeding functionality |
| of the TalkBack** and Switch Access accessibility services (https://github.com/google/talkback). |
| </p> |
| </li> |
| <li> |
| Android Watch devices with audio output SHOULD provide implementations of an accessibility service |
| on the device comparable in or exceeding functionality of the TalkBack accessibility service |
| (https://github.com/google/talkback). |
| </li> |
| <li> |
| Device implementations SHOULD provide a mechanism in the out-of-box setup flow for users to enable |
| relevant accessibility services, as well as options to adjust the font size, display size and |
| magnification gestures. |
| </li> |
| </ul> |
| <p> |
| ** For languages supported by Text-to-speech. |
| </p> |
| <p> |
| Also, note that if there is a preloaded accessibility service, it MUST be a Direct Boot aware |
| {directBootAware} app if the device has encrypted storage using File Based |
| Encryption (FBE). |
| </p> |
| <h2 id="3_11_text-to-speech"> |
| 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> |
| <li> |
| MUST support installation of third-party TTS engines. |
| </li> |
| <li> |
| MUST provide a user-accessible interface that allows users to select a TTS |
| engine for use at the system level. |
| </li> |
| </ul> |
| <h2 id="3_12_tv_input_framework"> |
| 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> |
| The TV App MUST allow navigation for the following functions via the D-pad, |
| Back, and Home keys on the Android Television device’s input device(s) |
| (i.e. remote control, remote control application, or game controller): |
| </p> |
| <ul> |
| <li> |
| Changing TV channels |
| </li> |
| <li> |
| Opening EPG |
| </li> |
| <li> |
| Configuring and tuning to third-party TIF-based inputs |
| </li> |
| <li> |
| Opening Settings menu |
| </li> |
| </ul> |
| <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> |
| <h4 id="3_12_1_4_time_shifting"> |
| 3.12.1.4. Time shifting |
| </h4> |
| <p> |
| Android Television device implementations MUST support time shifting, which |
| allows the user to pause and resume live content. Device implementations MUST |
| provide the user a way to pause and resume the currently playing program, if |
| time shifting for that program |
| <a href="https://developer.android.com/reference/android/media/tv/TvInputManager.html#TIME_SHIFT_STATUS_AVAILABLE"> |
| is available |
| </a> |
| . |
| </p> |
| <h4 id="3_12_1_5_tv_recording"> |
| 3.12.1.5. TV recording |
| </h4> |
| <p> |
| Android Television device implementations are STRONGLY RECOMMENDED to support |
| TV recording. If the TV input supports recording, the EPG MAY provide a way to |
| <a href="https://developer.android.com/reference/android/media/tv/TvInputInfo.html#canRecord%28%29"> |
| record a program |
| </a> |
| if the recording of such a program is not |
| <a href="https://developer.android.com/reference/android/media/tv/TvContract.Programs.html#COLUMN_RECORDING_PROHIBITED"> |
| prohibited |
| </a> |
| . |
| Device implementations SHOULD provide a user interface to play recorded programs. |
| </p> |
| <h2 id="3_13_quick_settings"> |
| 3.13. Quick Settings |
| </h2> |
| <p> |
| Android device implementations SHOULD include a Quick Settings UI component that |
| allow quick access to frequently used or urgently needed actions. |
| </p> |
| <p> |
| Android includes the |
| <a href="https://developer.android.com/reference/android/service/quicksettings/package-summary.html"> |
| <code> |
| quicksettings |
| </code> |
| </a> |
| API allowing third party apps to implement tiles that can be added by the user |
| alongside the system-provided tiles in the Quick Settings UI component. If a |
| device implementation has a Quick Settings UI component, it: |
| </p> |
| <ul> |
| <li> |
| MUST allow the user to add or remove tiles from a third-party app to Quick |
| Settings. |
| </li> |
| <li> |
| MUST NOT automatically add a tile from a third-party app directly to Quick |
| Settings. |
| </li> |
| <li> |
| MUST display all the user-added tiles from third-party apps alongside the |
| system-provided quick setting tiles. |
| </li> |
| </ul> |
| <h2 id="3_14_vehicle_ui_apis"> |
| 3.14. Vehicle UI APIs |
| </h2> |
| <h3 id="3_14_1__vehicle_media_ui"> |
| 3.14.1. Vehicle Media UI |
| </h3> |
| <p> |
| Any device implementation that |
| <a href="https://developer.android.com/reference/android/content/pm/PackageManager.html?#FEATURE_AUTOMOTIVE?"> |
| declares automotive support |
| </a> |
| MUST include a UI framework to support third-party apps consuming the |
| <a href="http://developer.android.com/reference/android/media/browse/MediaBrowser.html"> |
| MediaBrowser |
| </a> |
| and |
| <a href="http://developer.android.com/reference/android/media/session/MediaSession.html"> |
| MediaSession |
| </a> |
| APIs. |
| </p> |
| <p> |
| The UI framework supporting third-party apps that depend on MediaBrowser and |
| MediaSession has the following visual requirements: |
| </p> |
| <ul> |
| <li> |
| MUST display |
| <a href="http://developer.android.com/reference/android/media/browse/MediaBrowser.MediaItem.html"> |
| MediaItem |
| </a> |
| icons and notification icons unaltered. |
| </li> |
| <li> |
| MUST display those items as described by MediaSession, e.g., metadata, icons, |
| imagery. |
| </li> |
| <li> |
| MUST show app title. |
| </li> |
| <li> |
| MUST have drawer to present |
| <a href="http://developer.android.com/reference/android/media/browse/MediaBrowser.html"> |
| MediaBrowser |
| </a> |
| hierarchy. |
| </li> |
| </ul> |
| <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> |
| . |
| For this reason device implementations SHOULD use the reference implementation’s |
| package management system. |
| </p> |
| <p> |
| The package manager MUST support verifying “.apk” files using the |
| <a href="https://source.android.com/security/apksigning/v2.html"> |
| APK Signature Scheme v2 |
| </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> |
| <p> |
| Device implementations MUST NOT allow apps other than the current |
| "installer of record" for the package to silently uninstall the app without any |
| prompt, as documented in the SDK for the |
| <a href="https://developer.android.com/reference/android/Manifest.permission.html#DELETE_PACKAGES"> |
| <code> |
| DELETE_PACKAGE |
| </code> |
| </a> |
| permission. The only exceptions are the system package verifier app handling |
| <a href="https://developer.android.com/reference/android/content/Intent.html#ACTION_PACKAGE_NEEDS_VERIFICATION"> |
| PACKAGE_NEEDS_VERIFICATION |
| </a> |
| intent and the storage manager app handling |
| <a href="https://developer.android.com/reference/android/os/storage/StorageManager.html#ACTION_MANAGE_STORAGE"> |
| ACTION_MANAGE_STORAGE |
| </a> |
| intent. |
| </p> |
| <h1 id="5_multimedia_compatibility"> |
| 5. Multimedia Compatibility |
| </h1> |
| <h2 id="5_1_media_codecs"> |
| 5.1. Media Codecs |
| </h2> |
| <p> |
| Device implementations— |
| </p> |
| <ul> |
| <li> |
| <p> |
| 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. |
| </p> |
| </li> |
| <li> |
| <p> |
| 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> |
| . |
| </p> |
| </li> |
| <li> |
| <p> |
| MUST also be able to decode all profiles reported in its |
| <a href="http://developer.android.com/reference/android/media/CamcorderProfile.html"> |
| CamcorderProfile |
| </a> |
| </p> |
| </li> |
| <li> |
| <p> |
| MUST be able to decode all formats it can encode. This includes all |
| bitstreams that its encoders generate. |
| </p> |
| </li> |
| </ul> |
| <p> |
| Codecs SHOULD aim for minimum codec latency, in other words, codecs— |
| </p> |
| <ul> |
| <li> |
| SHOULD NOT consume and store input buffers and return input buffers only |
| once processed |
| </li> |
| <li> |
| SHOULD NOT hold onto decoded buffers for longer than as specified by the |
| standard (e.g. SPS). |
| </li> |
| <li> |
| SHOULD NOT hold onto encoded buffers longer than required by the GOP |
| structure. |
| </li> |
| </ul> |
| <p> |
| All of the codecs listed in the table below are provided as software |
| implementations in the preferred Android implementation from the Android Open |
| Source Project. |
| </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), Ogg(.ogg) |
| </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 Recording or playback MAY be performed in mono |
| or stereo, but the decoding of AAC input buffers of multichannel streams |
| (i.e. more than two channels) to PCM through the default AAC audio decoder |
| in the android.media.MediaCodec API, the following MUST be supported: |
| </p> |
| <ul> |
| <li> |
| decoding is performed without downmixing (e.g. a 5.0 AAC stream must be |
| decoded to five channels of PCM, a 5.1 AAC stream must be decoded to six |
| channels of PCM), |
| </li> |
| <li> |
| dynamic range metadata, as defined in "Dynamic Range Control (DRC)" |
| in ISO/IEC 14496-3, and the android.media.MediaFormat DRC keys to |
| configure the dynamic range-related behaviors of the audio decoder. The |
| AAC DRC keys were introduced in API 21,and are: |
| KEY_AAC_DRC_ATTENUATION_FACTOR, KEY_AAC_DRC_BOOST_FACTOR, |
| KEY_AAC_DRC_HEAVY_COMPRESSION, KEY_AAC_DRC_TARGET_REFERENCE_LEVEL and |
| KEY_AAC_ENCODED_TARGET_LEVEL |
| </li> |
| </ul> |
| <p 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> |
| <tr> |
| <td> |
| Raw |
| </td> |
| <td> |
| </td> |
| <td> |
| REQUIRED |
| </td> |
| <td> |
| </td> |
| <td> |
| ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), |
| PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw) |
| </td> |
| </tr> |
| </table> |
| <h3 id="5_1_3_video_codecs"> |
| 5.1.3. Video Codecs |
| </h3> |
| <ul> |
| <li> |
| <p> |
| Codecs advertising HDR profile support MUST support HDR static metadata |
| parsing and handling. |
| </p> |
| </li> |
| <li> |
| <p> |
| If a media codec advertises intra refresh support, then it MUST support the |
| refresh periods in the range of 10 - 60 frames and accurately operate within |
| 20% of configured refresh period. |
| </p> |
| </li> |
| <li> |
| <p> |
| Video codecs MUST support output and input bytebuffer sizes that |
| accommodate the largest feasible compressed and uncompressed frame as dictated |
| by the standard and configuration but also not overallocate. |
| </p> |
| </li> |
| <li> |
| <p> |
| Video encoders and decoders MUST support YUV420 flexible color format |
| (COLOR_FormatYUV420Flexible). |
| </p> |
| </li> |
| </ul> |
| <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> |
| MAY |
| </td> |
| <td> |
| MAY |
| </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"> |
| Video codecs are optional for Android Watch device implementations. |
| </div> |
| <p> |
| H.264, VP8, VP9 and HEVC video encoders— |
| </p> |
| <ul> |
| <li> |
| MUST support dynamically configurable bitrates. |
| </li> |
| <li> |
| SHOULD support variable frame rates, where video encoder SHOULD determine |
| instantaneous frame duration based on the timestamps of input buffers, and |
| allocate its bit bucket based on that frame duration. |
| </li> |
| </ul> |
| <p> |
| H.263 and MPEG-4 video encoder SHOULD support dynamically configurable |
| bitrates. |
| </p> |
| <p> |
| All video encoders SHOULD meet the following bitrate targets over two sliding |
| windows: |
| </p> |
| <ul> |
| <li> |
| It SHOULD be not more than ~15% over the bitrate between intraframe |
| (I-frame) intervals. |
| </li> |
| <li> |
| It SHOULD be not more than ~100% over the bitrate over a sliding window of |
| 1 second. |
| </li> |
| </ul> |
| <h3 id="5_2_1_h_263"> |
| 5.2.1. H.263 |
| </h3> |
| <p> |
| Android device implementations with H.263 encoders MUST support Baseline Profile Level 45. |
| </p> |
| <h3 id="5_2_2_h-264"> |
| 5.2.2. H-264 |
| </h3> |
| <p> |
| Android device implementations with H.264 codec support: |
| </p> |
| <ul> |
| <li> |
| MUST support Baseline Profile Level 3. |
| <br/> |
| However, support for ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock |
| Ordering) and RS (Redundant Slices) is OPTIONAL. Moreover, to maintain |
| compatibility with other Android devices, it is RECOMMENDED that ASO, FMO |
| and RS are not used for Baseline Profile by encoders. |
| </li> |
| <li> |
| MUST support the SD (Standard Definition) video encoding profiles in the following table. |
| </li> |
| <li> |
| SHOULD support Main Profile Level 4. |
| </li> |
| <li> |
| SHOULD support the HD (High Definition) video encoding profiles as indicated in the following table. |
| </li> |
| <li> |
| In addition, Android Television devices are STRONGLY RECOMMENDED to encode HD 1080p video at 30 fps. |
| </li> |
| </ul> |
| <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> |
| <h3 id="5_2_3_vp8"> |
| 5.2.3. VP8 |
| </h3> |
| <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"> |
| Video codecs are optional for Android Watch device implementations. |
| </div> |
| <p> |
| Device implementations— |
| </p> |
| <ul> |
| <li> |
| <p> |
| 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> |
| </li> |
| <li> |
| <p> |
| Implementations that support the Dolby Vision decoder— |
| </p> |
| </li> |
| <li> |
| MUST provide a Dolby Vision-capable extractor. |
| </li> |
| <li> |
| <p> |
| MUST properly display Dolby Vision content on the device screen or on a |
| standard video output port (e.g., HDMI). |
| </p> |
| </li> |
| <li> |
| <p> |
| Implementations that provide a Dolby Vision-capable extractor MUST set the |
| track index of backward-compatible base-layer(s) (if present) to be the same |
| as the combined Dolby Vision layer's track index. |
| </p> |
| </li> |
| </ul> |
| <h3 id="5_3_1_mpeg-2"> |
| 5.3.1. MPEG-2 |
| </h3> |
| <p> |
| Android device implementations with MPEG-2 decoders must support the Main |
| Profile High Level. |
| </p> |
| <h3 id="5_3_2_h_263"> |
| 5.3.2. H.263 |
| </h3> |
| <p> |
| Android device implementations with H.263 decoders MUST support Baseline Profile |
| Level 30 and Level 45. |
| </p> |
| <h3 id="5_3_3_mpeg-4"> |
| 5.3.3. MPEG-4 |
| </h3> |
| <p> |
| Android device implementations with MPEG-4 decoders MUST support Simple Profile |
| Level 3. |
| </p> |
| <h3 id="5_3_4_h_264"> |
| 5.3.4. H.264 |
| </h3> |
| <p> |
| Android device implementations with H.264 decoders: |
| </p> |
| <ul> |
| <li> |
| MUST support Main Profile Level 3.1 and Baseline Profile. |
| <br/> |
| Support for ASO (Arbitrary Slice Ordering), FMO (Flexible Macroblock Ordering) |
| and RS (Redundant Slices) is OPTIONAL. |
| </li> |
| <li> |
| MUST be capable of decoding videos with the SD (Standard Definition) |
| profiles listed in the following table and encoded with the Baseline Profile and |
| Main Profile Level 3.1 (including 720p30). |
| </li> |
| <li> |
| SHOULD be capable of decoding videos with the HD (High Definition) profiles |
| as indicated in the following table. |
| </li> |
| <li> |
| In addition, Android Television devices— |
| <ul> |
| <li> |
| MUST support High Profile Level 4.2 and the HD 1080p60 decoding profile. |
| </li> |
| <li> |
| MUST be capable of decoding videos with both HD profiles as indicated |
| in the following table and encoded with either the Baseline Profile, Main |
| Profile, or the High Profile Level 4.2 |
| </li> |
| </ul> |
| </li> |
| </ul> |
| <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> |
| <h3 id="5_3_5_h_265_(hevc)"> |
| 5.3.5. H.265 (HEVC) |
| </h3> |
| <p> |
| Android device implementations, when supporting H.265 codec as described in |
| <a href="#5_1_3_video_codecs"> |
| section 5.1.3 |
| </a> |
| : |
| </p> |
| <ul> |
| <li> |
| MUST support the Main Profile Level 3 Main tier and the SD video decoding profiles |
| as indicated in the following table. |
| </li> |
| <li> |
| SHOULD support the HD decoding profiles as indicated in the following table. |
| </li> |
| <li> |
| MUST support the HD decoding profiles as indicated in the following table |
| if there is a hardware decoder. |
| </li> |
| <li> |
| In addition, Android Television devices: |
| </li> |
| <li> |
| MUST support the HD 720p decoding profile. |
| </li> |
| <li> |
| STRONGLY RECOMMENDED to support the HD 1080p decoding profile. If the HD 1080p |
| decoding profile is supported, it MUST support the Main Profile Level 4.1 Main tier. |
| </li> |
| <li> |
| SHOULD support the UHD decoding profile. If the UHD decoding profile is supported the |
| codec MUST support Main10 Level 5 Main Tier profile. |
| </li> |
| </ul> |
| <table> |
| <tr> |
| <th> |
| </th> |
| <th> |
| SD (Low quality) |
| </th> |
| <th> |
| SD (High quality) |
| </th> |
| <th> |
| HD 720p |
| </th> |
| <th> |
| HD 1080p |
| </th> |
| <th> |
| UHD |
| </th> |
| </tr> |
| <tr> |
| <th> |
| Video resolution |
| </th> |
| <td> |
| 352 x 288 px |
| </td> |
| <td> |
| 720 x 480 px |
| </td> |
| <td> |
| 1280 x 720 px |
| </td> |
| <td> |
| 1920 x 1080 px |
| </td> |
| <td> |
| 3840 x 2160 px |
| </td> |
| </tr> |
| <tr> |
| <th> |
| Video frame rate |
| </th> |
| <td> |
| 30 fps |
| </td> |
| <td> |
| 30 fps |
| </td> |
| <td> |
| 30 fps |
| </td> |
| <td> |
| 30 fps (60 fps |
| <sup> |
| 1 |
| </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> |
| 5 Mbps |
| </td> |
| <td> |
| 20 Mbps |
| </td> |
| </tr> |
| </table> |
| <p class="table_footnote"> |
| 1 REQUIRED for Android Television device |
| implementations with H.265 hardware decoding. |
| </p> |
| <h3 id="5_3_6_vp8"> |
| 5.3.6. VP8 |
| </h3> |
| <p> |
| Android device implementations, when supporting VP8 codec as described in |
| <a href="https://source.android.com/compatibility/android-cdd.html#5_1_3_video_codecs"> |
| section 5.1.3 |
| </a> |
| : |
| </p> |
| <ul> |
| <li> |
| MUST support the SD decoding profiles in the following table. |
| </li> |
| <li> |
| SHOULD support the HD decoding profiles in the following table. |
| </li> |
| <li> |
| Android Television devices MUST support the HD 1080p60 decoding profile. |
| </li> |
| </ul> |
| <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> |
| <h3 id="5_3_7_vp9"> |
| 5.3.7. VP9 |
| </h3> |
| <p> |
| Android device implementations, when supporting VP9 codec as described in |
| <a href="https://source.android.com/compatibility/android-cdd.html#5_1_3_video_codecs"> |
| section 5.1.3 |
| </a> |
| : |
| </p> |
| <ul> |
| <li> |
| MUST support the SD video decoding profiles as indicated in the following table. |
| </li> |
| <li> |
| SHOULD support the HD decoding profiles as indicated in the following table. |
| </li> |
| <li> |
| MUST support the HD decoding profiles as indicated in the following table, |
| if there is a hardware decoder. |
| </li> |
| <li> |
| <p> |
| In addition, Android Television devices: |
| </p> |
| <ul> |
| <li> |
| MUST support the HD 720p decoding profile. |
| </li> |
| <li> |
| STRONGLY RECOMMENDED to support the HD 1080p decoding profile. |
| </li> |
| <li> |
| SHOULD support the UHD decoding profile. If the UHD video decoding |
| profile is supported, it MUST support 8-bit color depth and SHOULD |
| support VP9 Profile 2 (10-bit). |
| </li> |
| </ul> |
| </li> |
| </ul> |
| <table> |
| <tr> |
| <th> |
| </th> |
| <th> |
| SD (Low quality) |
| </th> |
| <th> |
| SD (High quality) |
| </th> |
| <th> |
| HD 720p |
| </th> |
| <th> |
| HD 1080p |
| </th> |
| <th> |
| UHD |
| </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> |
| 30 fps (60 fps |
| <sup> |
| 1 |
| </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> |
| 5 Mbps |
| </td> |
| <td> |
| 20 Mbps |
| </td> |
| </tr> |
| </table> |
| <p class="table_footnote"> |
| 1 REQUIRED for Android Television |
| device implementations with VP9 hardware decoding. |
| </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> |
| <li> |
| <strong> |
| Sampling rates |
| </strong> |
| : 8000, 11025, 16000, 44100 |
| </li> |
| <li> |
| <strong> |
| Channels |
| </strong> |
| : Mono |
| </li> |
| </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> |
| <li> |
| <strong> |
| Sampling rates |
| </strong> |
| : 22050, 48000 |
| </li> |
| <li> |
| <strong> |
| Channels |
| </strong> |
| : Stereo |
| </li> |
| </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> |
| The android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION audio source MUST |
| support capture at one of the sampling rates, 44100 and 48000. |
| </p> |
| <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> |
| <li> |
| STREAM_ALARM |
| </li> |
| <li> |
| STREAM_NOTIFICATION |
| </li> |
| </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> |
| <p> |
| Android Automotive device implementations SHOULD allow adjusting audio volume |
| separately per each audio stream using the content type or usage as defined |
| by |
| <a href="" title="http://developer.android.com/reference/android/media/AudioAttributes.html"> |
| AudioAttributes |
| </a> |
| and car audio usage as publicly defined in |
| <code> |
| android.car.CarAudioManager |
| </code> |
| . |
| </p> |
| <h2 id="5_6_audio_latency"> |
| 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 is presented to environment at an on-device transducer |
| or signal leaves the device via a port and can be observed externally. |
| </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 a sound is presented by environment to device |
| at an on-device transducer or signal enters the device via a port |
| and when an application reads the corresponding frame of |
| PCM-coded data. |
| </li> |
| <li> |
| <strong> |
| lost input |
| </strong> |
| . The initial portion of an input signal that is unusable or unavailable. |
| </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 variability among separate measurements of cold |
| output latency values. |
| </li> |
| <li> |
| <strong> |
| cold input jitter |
| </strong> |
| . The variability 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 allows |
| time for the app to process the signal and time 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 |
| <a href="https://developer.android.com/ndk/index.html"> |
| Android NDK |
| </a> |
| . |
| </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> |
| <p> |
| HTTP(S) progressive streaming |
| <br/> |
| All required codecs and container formats in |
| <a href="#5_1_media_codecs"> |
| section 5.1 |
| </a> |
| MUST |
| be supported over HTTP(S) |
| </p> |
| </li> |
| <li> |
| <p> |
| <a href="http://tools.ietf.org/html/draft-pantos-http-live-streaming-07"> |
| HTTP Live Streaming draft protocol, Version 7 |
| </a> |
| <br/> |
| The following media segment formats MUST be supported: |
| </p> |
| </li> |
| </ul> |
| <table> |
| <tr> |
| <th> |
| Segment formats |
| </th> |
| <th> |
| Reference(s) |
| </th> |
| <th> |
| Required codec support |
| </th> |
| </tr> |
| <tr id="mp2t"> |
| <td> |
| MPEG-2 Transport Stream |
| </td> |
| <td> |
| <a href="http://www.iso.org/iso/catalogue_detail?csnumber=44169"> |
| ISO 13818 |
| </a> |
| </td> |
| <td> |
| Video codecs: |
| <ul> |
| <li class="table_list"> |
| H264 AVC |
| </li> |
| <li class="table_list"> |
| MPEG-4 SP |
| </li> |
| <li class="table_list"> |
| MPEG-2 |
| </li> |
| </ul> |
| See |
| <a href="#5_1_3_video_codecs"> |
| section 5.1.3 |
| </a> |
| for details on H264 AVC, MPEG2-4 SP, |
| <br/> |
| and MPEG-2. |
| <p> |
| Audio codecs: |
| </p> |
| <ul> |
| <li class="table_list"> |
| AAC |
| </li> |
| </ul> |
| See |
| <a href="#5_1_1_audio_codecs"> |
| section 5.1.1 |
| </a> |
| for details on AAC and its variants. |
| </td> |
| </tr> |
| <tr> |
| <td> |
| AAC with ADTS framing and ID3 tags |
| </td> |
| <td> |
| <a href="http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=43345"> |
| ISO 13818-7 |
| </a> |
| </td> |
| <td> |
| See |
| <a href="#5_1_1_audio_codecs"> |
| section 5.1.1 |
| </a> |
| for details on AAC and its variants |
| </td> |
| </tr> |
| <tr> |
| <td> |
| WebVTT |
| </td> |
| <td> |
| <a href="http://dev.w3.org/html5/webvtt/"> |
| WebVTT |
| </a> |
| </td> |
| <td> |
| </td> |
| </tr> |
| </table> |
| <ul> |
| <li> |
| <p> |
| RTSP (RTP, SDP) |
| </p> |
| <p> |
| The following RTP audio video profile and related codecs MUST be supported. |
| For exceptions please see the table footnotes in |
| <a href="#5_1_media_codecs"> |
| section 5.1 |
| </a> |
| . |
| </p> |
| </li> |
| </ul> |
| <table> |
| <tr> |
| <th> |
| Profile name |
| </th> |
| <th> |
| Reference(s) |
| </th> |
| <th> |
| Required codec support |
| </th> |
| </tr> |
| <tr> |
| <td> |
| H264 AVC |
| </td> |
| <td> |
| <a href="https://tools.ietf.org/html/rfc6184"> |
| RFC 6184 |
| </a> |
| </td> |
| <td> |
| See |
| <a href="#5_1_3_video_codecs"> |
| section 5.1.3 |
| </a> |
| for details on H264 AVC |
| </td> |
| </tr> |
| <tr> |
| <td> |
| MP4A-LATM |
| </td> |
| <td> |
| <a href="https://tools.ietf.org/html/rfc6416"> |
| RFC 6416 |
| </a> |
| </td> |
| <td> |
| See |
| <a href="#5_1_1_audio_codecs"> |
| section 5.1.1 |
| </a> |
| for details on AAC and its variants |
| </td> |
| </tr> |
| <tr> |
| <td> |
| H263-1998 |
| </td> |
| <td> |
| <a href="https://tools.ietf.org/html/rfc3551"> |
| RFC 3551 |
| </a> |
| <br/> |
| <a href="https://tools.ietf.org/html/rfc4629"> |
| RFC 4629 |
| </a> |
| <br/> |
| <a href="https://tools.ietf.org/html/rfc2190"> |
| RFC 2190 |
| </a> |
| </td> |
| <td> |
| See |
| <a href="#5_1_3_video_codecs"> |
| section 5.1.3 |
| </a> |
| for details on H263 |
| </td> |
| </tr> |
| <tr> |
| <td> |
| H263-2000 |
| </td> |
| <td> |
| <a href="https://tools.ietf.org/html/rfc4629"> |
| RFC 4629 |
| </a> |
| </td> |
| <td> |
| See |
| <a href="#5_1_3_video_codecs"> |
| section 5.1.3 |
| </a> |
| for details on H263 |
| </td> |
| </tr> |
| <tr> |
| <td> |
| AMR |
| </td> |
| <td> |
| <a href="https://tools.ietf.org/html/rfc4867"> |
| RFC 4867 |
| </a> |
| </td> |
| <td> |
| See |
| <a href="#5_1_1_audio_codecs"> |
| section 5.1.1 |
| </a> |
| for details on AMR-NB |
| </td> |
| </tr> |
| <tr> |
| <td> |
| AMR-WB |
| </td> |
| <td> |
| <a href="https://tools.ietf.org/html/rfc4867"> |
| RFC 4867 |
| </a> |
| </td> |
| <td> |
| See |
| <a href="#5_1_1_audio_codecs"> |
| section 5.1.1 |
| </a> |
| for details on AMR-WB |
| </td> |
| </tr> |
| <tr> |
| <td> |
| MP4V-ES |
| </td> |
| <td> |
| <a href="https://tools.ietf.org/html/rfc6416"> |
| RFC 6416 |
| </a> |
| </td> |
| <td> |
| See |
| <a href="#5_1_3_video_codecs"> |
| section 5.1.3 |
| </a> |
| for details on MPEG-4 SP |
| </td> |
| </tr> |
| <tr> |
| <td> |
| mpeg4-generic |
| </td> |
| <td> |
| <a href="https://tools.ietf.org/html/rfc3640"> |
| RFC 3640 |
| </a> |
| </td> |
| <td> |
| See |
| <a href="#5_1_1_audio_codecs"> |
| section 5.1.1 |
| </a> |
| for details on AAC and its variants |
| </td> |
| </tr> |
| <tr> |
| <td> |
| MP2T |
| </td> |
| <td> |
| <a href="https://tools.ietf.org/html/rfc2250"> |
| RFC 2250 |
| </a> |
| </td> |
| <td> |
| See |
| <a href="#mp2t"> |
| MPEG-2 Transport Stream |
| </a> |
| underneath HTTP Live Streaming for details |
| </td> |
| </tr> |
| </table> |
| <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_musical_instrument_digital_interface_(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> |
| <li> |
| MIDI over Bluetooth LE acting in central role (section 7.4.3 Bluetooth) |
| </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> |
| <h2 id="5_10_professional_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> |
| <p> |
| Latencies and USB audio requirements MUST be met using the |
| <a href="https://developer.android.com/ndk/guides/audio/opensl-for-android.html"> |
| OpenSL ES |
| </a> |
| PCM buffer queue API. |
| </p> |
| <p> |
| In addition, a device implementation that reports support for this feature SHOULD: |
| </p> |
| <ul> |
| <li> |
| Provide a sustainable level of CPU performance while audio is active. |
| </li> |
| <li> |
| Minimize audio clock inaccuracy and drift relative to standard time. |
| </li> |
| <li> |
| Minimize audio clock drift relative to the CPU |
| <code> |
| CLOCK_MONOTONIC |
| </code> |
| when both are active. |
| </li> |
| <li> |
| Minimize audio latency over on-device transducers. |
| </li> |
| <li> |
| Minimize audio latency over USB digital audio. |
| </li> |
| <li> |
| Document audio latency measurements over all paths. |
| </li> |
| <li> |
| Minimize jitter in audio buffer completion callback entry times, as this affects usable percentage of full CPU bandwidth by the callback. |
| </li> |
| <li> |
| Provide zero audio underruns (output) or overruns (input) under normal use at reported latency. |
| </li> |
| <li> |
| Provide zero inter-channel latency difference. |
| </li> |
| <li> |
| Minimize MIDI mean latency over all transports. |
| </li> |
| <li> |
| Minimize MIDI latency variability under load (jitter) over all transports. |
| </li> |
| <li> |
| Provide accurate MIDI timestamps over all transports. |
| </li> |
| <li> |
| Minimize audio signal noise over on-device transducers, including the period immediately after cold start. |
| </li> |
| <li> |
| Provide zero audio clock difference between the input and output sides of corresponding |
| end-points, when both are active. Examples of corresponding end-points include |
| the on-device microphone and speaker, or the audio jack input and output. |
| </li> |
| <li> |
| Handle audio buffer completion callbacks for the input and output sides of corresponding |
| end-points on the same thread when both are active, and enter the output callback immediately |
| after the return from the input callback. Or if it is not feasible to handle the callbacks |
| on the same thread, then enter the output callback shortly after entering the input callback |
| to permit the application to have a consistent timing of the input and output sides. |
| </li> |
| <li> |
| Minimize the phase difference between HAL audio buffering for the input and output |
| sides of corresponding end-points. |
| </li> |
| <li> |
| Minimize touch latency. |
| </li> |
| <li> |
| Minimize touch latency variability under load (jitter). |
| </li> |
| </ul> |
| <h2 id="5_11_capture_for_unprocessed"> |
| 5.11. Capture for Unprocessed |
| </h2> |
| <p> |
| Starting from Android 7.0, |
| a new recording source has been added. It can be accessed using |
| the |
| <code> |
| android.media.MediaRecorder.AudioSource.UNPROCESSED |
| </code> |
| audio |
| source. In OpenSL ES, it can be accessed with the record preset |
| <code> |
| SL_ANDROID_RECORDING_PRESET_UNPROCESSED |
| </code> |
| . |
| </p> |
| <p> |
| A device MUST satisfy all of the following requirements to report support |
| of the unprocessed audio source via the |
| <code> |
| android.media.AudioManager |
| </code> |
| property |
| <a href="http://developer.android.com/reference/android/media/AudioManager.html#PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED"> |
| PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED |
| </a> |
| : |
| </p> |
| <ul> |
| <li> |
| <p> |
| The device MUST exhibit approximately flat amplitude-versus-frequency |
| characteristics in the mid-frequency range: specifically ±10dB from |
| 100 Hz to 7000 Hz. |
| </p> |
| </li> |
| <li> |
| <p> |
| The device MUST exhibit amplitude levels in the low frequency range: |
| specifically from ±20 dB from 5 Hz to 100 Hz compared to the mid-frequency range. |
| </p> |
| </li> |
| <li> |
| <p> |
| The device MUST exhibit amplitude levels in the high frequency range: |
| specifically from ±30 dB from 7000 Hz to 22 KHz compared to the mid-frequency range. |
| </p> |
| </li> |
| <li> |
| <p> |
| Audio input sensitivity MUST be set such that a 1000 Hz sinusoidal tone |
| source played at 94 dB Sound Pressure Level (SPL) |
| yields a response with RMS of 520 for 16 |
| bit-samples (or -36 dB Full Scale for floating point/double precision |
| samples). |
| </p> |
| </li> |
| <li> |
| <p> |
| SNR > 60 dB (difference between 94 dB SPL and equivalent SPL of self |
| noise, A-weighted). |
| </p> |
| </li> |
| <li> |
| <p> |
| Total harmonic distortion MUST be less than 1% for 1 kHZ at 90 dB SPL |
| input level at the microphone. |
| </p> |
| </li> |
| <li> |
| <p> |
| The only signal processing allowed in the path is a level multiplier |
| to bring the level to desired range. This level multiplier MUST NOT |
| introduce delay or latency to the signal path. |
| </p> |
| </li> |
| <li> |
| <p> |
| No other signal processing is allowed in the path, such as Automatic Gain |
| Control, High Pass Filter, or Echo Cancellation. If any signal processing |
| is present in the architecture for any reason, it MUST be disabled and |
| effectively introduce zero delay or extra latency to the signal path. |
| </p> |
| </li> |
| </ul> |
| <p> |
| All SPL measurements are made directly next to the microphone under test. |
| </p> |
| <p> |
| For multiple microphone configurations, these requirements apply to each |
| microphone. |
| </p> |
| <p> |
| It is STRONGLY RECOMMENDED that a device satisfy as many of the requirements for the signal |
| path for the unprocessed recording source; however, a device must satisfy |
| <em> |
| all |
| </em> |
| of these |
| requirements, listed above, if it claims to support the unprocessed audio source. |
| </p> |
| <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> |
| <div class="note"> |
| Android Automotive implementations MAY limit access to the Developer Options |
| menu by visually hiding or disabling the menu when the vehicle is in motion. |
| </div> |
| <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"> |
| Android Watch devices (detailed in |
| <a href="#2_device_types"> |
| section 2 |
| </a> |
| ) MAY have |
| smaller screen sizes as described in this section. |
| </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> |
| Android Automotive devices MUST have a screen with the physical diagonal |
| size greater than or equal to 6 inches. |
| </li> |
| <li> |
| Android Automotive devices MUST have a screen size of at least 750 dp x |
| 480 dp. |
| </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"> |
| Android Watch devices MAY have an aspect ratio of 1.0 (1:1). |
| </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> |
| <p> |
| Device implementations are STRONGLY RECOMMENDED to provide users a setting to change |
| the display size. If there is an implementation to change the display size of the device, |
| it MUST align with the AOSP implementation as indicated below: |
| </p> |
| <ul> |
| <li> |
| The display size MUST NOT be scaled any larger than 1.5 times the native density or |
| produce an effective minimum screen dimension smaller than 320dp (equivalent |
| to resource qualifier sw320dp), whichever comes first. |
| </li> |
| <li> |
| Display size MUST NOT be scaled any smaller than 0.85 times the native density. |
| </li> |
| <li> |
| To ensure good usability and consistent font sizes, it is RECOMMENDED that the |
| following scaling of Native Display options be provided (while complying with the limits |
| specified above) |
| </li> |
| <li> |
| Small: 0.85x |
| </li> |
| <li> |
| Default: 1x (Native display scale) |
| </li> |
| <li> |
| Large: 1.15x |
| </li> |
| <li> |
| Larger: 1.3x |
| </li> |
| <li> |
| Largest 1.45x |
| </li> |
| </ul> |
| <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, 3.1, or 3.2 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, OpenGL 3.1, or OpenGL 3.2. 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, 3.1, or 3.2 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, 3.1, or |
| 3.2 libGLESv2.so MUST export the corresponding function symbols in addition to |
| the OpenGL ES 2.0 function symbols. |
| </li> |
| </ul> |
| <p> |
| Android provides an OpenGL ES |
| <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 MUST support the extension pack if the device supports OpenGL |
| ES 3.2 and MAY support it otherwise. If the extension pack is supported in its |
| entirety, the device MUST identify the support through the |
| <code> |
| android.hardware.opengles.aep |
| </code> |
| 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_secondary_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"> |
| Android Watch and Android Automotive implementations MAY implement a soft |
| keyboard. All other device implementations MUST implement a soft keyboard and: |
| </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"> |
| Android Television devices MUST support D-pad. |
| </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"> |
| The availability and visibility requirement of the Home, Recents, and Back |
| functions differ between device types as described in this section. |
| </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 |
| <code> |
| UI_MODE_TYPE_WATCH |
| </code> |
| . |
| </li> |
| <li> |
| Android Watch device implementations, and no other Android device types, |
| MAY consume the long press event on the key event |
| <a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK"> |
| <code> |
| KEYCODE_BACK |
| </code> |
| </a> |
| and omit it from being sent to the foreground application. |
| </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 7.1 |
| 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 |
| 7.1, 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 supporting the |
| <a href="http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST"> |
| Assist action |
| </a> |
| and/or |
| <a href="https://developer.android.com/reference/android/service/voice/VoiceInteractionService.html"> |
| <code> |
| VoiceInteractionService |
| </code> |
| </a> |
| MUST be able to launch an assist app with a single interaction (e.g. tap, |
| double-click, or gesture) when other navigation keys are visible. It is STRONGLY |
| RECOMMENDED to use long press on home as this interaction. The designated |
| interaction MUST launch the user-selected assist app, in other words the app |
| that implements a VoiceInteractionService, or an activity handling the ACTION_ASSIST intent. |
| </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"> |
| Android Handhelds and Watch Devices MUST support touchscreen input. |
| </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, Android Automotive implementations, and Android Watch devices are STRONGLY |
| RECOMMENDED to include this sensor. If a device implementation does include a |
| 3-axis accelerometer, it: |
| </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. Android Automotive implementations MUST comply |
| with the Android |
| <a href="http://source.android.com/devices/sensors/sensor-types.html#auto_axes"> |
| car sensor coordinate system |
| </a> |
| . |
| </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 µT. |
| </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/GNSS receiver. If a device implementation |
| does include a GPS/GNSS receiver and reports the capability to applications through the |
| <code> |
| android.hardware.location.gps |
| </code> |
| feature flag: |
| </p> |
| <ul> |
| <li> |
| It is STRONGLY RECOMMENDED that the device continue to deliver normal GPS/GNSS |
| outputs to applications during an emergency phone call and that location output |
| not be blocked during an emergency phone call. |
| </li> |
| <li> |
| It MUST support location outputs at a rate of at least 1 Hz when requested via |
| <code> |
| LocationManager#requestLocationUpdate |
| </code> |
| . |
| </li> |
| <li> |
| It MUST be able to determine the location in open-sky conditions (strong signals, |
| negligible multipath, HDOP < 2) within 10 seconds (fast time to first fix), when |
| connected to a 0.5 Mbps or faster data speed internet connection. This requirement |
| is typically met by the use of some form of Assisted or Predicted GPS/GNSS technique |
| to minimize GPS/GNSS lock-on time (Assistance data includes Reference Time, Reference |
| Location and Satellite Ephemeris/Clock). |
| <ul> |
| <li> |
| After making such a location calculation, it is STRONGLY RECOMMENDED for the device to |
| be able to determine its location, in open sky, within 10 seconds, when location |
| requests are restarted, up to an hour after the initial location calculation, |
| even when the subsequent request is made without a data connection, and/or after a power |
| cycle. |
| </li> |
| </ul> |
| </li> |
| <li> |
| In open sky conditions after determining the location, while stationary or moving with less |
| than 1 meter per second squared of acceleration: |
| <ul> |
| <li> |
| It MUST be able to determine location within 20 meters, and speed within 0.5 meters |
| per second, at least 95% of the time. |
| </li> |
| <li> |
| It MUST simultaneously track and report via |
| <a href="https://developer.android.com/reference/android/location/GnssStatus.Callback.html#GnssStatus.Callback()'"> |
| GnssStatus.Callback |
| </a> |
| at least 8 satellites from one constellation. |
| </li> |
| <li> |
| It SHOULD be able to simultaneously track at least 24 satellites, from multiple |
| constellations (e.g. GPS + at least one of Glonass, Beidou, Galileo). |
| </li> |
| </ul> |
| </li> |
| <li> |
| It MUST report the GNSS technology generation through the test API ‘getGnssYearOfHardware’. |
| </li> |
| <li> |
| It is STRONGLY RECOMMENDED to meet and MUST meet all requirements below if the GNSS technology |
| generation is reported as the year "2016" or newer. |
| <ul> |
| <li> |
| It MUST report GPS measurements, as soon as they are found, even if a location calculated |
| from GPS/GNSS is not yet reported. |
| </li> |
| <li> |
| It MUST report GPS pseudoranges and pseudorange rates, that, in open-sky conditions |
| after determining the location, while stationary or moving with less than 0.2 meter |
| per second squared of acceleration, are sufficient to calculate position within |
| 20 meters, and speed within 0.2 meters per second, at least 95% of the time. |
| </li> |
| </ul> |
| </li> |
| </ul> |
| <p> |
| Note that while some of the GPS requirements above are stated as STRONGLY RECOMMENDED, the |
| Compatibility Definition for the next major version is expected to change these to a MUST. |
| </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> |
| <div class="note"> |
| For Android Automotive implementations, SENSOR_TYPE_AMBIENT_TEMPERATURE MUST |
| measure the temperature inside the vehicle cabin. |
| </div> |
| <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_high_fidelity_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 maximum measurement frequency of 400 Hz or higher. |
| </li> |
| <li> |
| MUST have a measurement noise not above 400 uG/√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> |
| <li> |
| SHOULD have a stationary noise bias stability of \<15 μg √Hz from 24hr static |
| dataset. |
| </li> |
| <li> |
| SHOULD have a bias change vs. temperature of ≤ +/- 1mg / °C. |
| </li> |
| <li> |
| SHOULD have a best-fit line non-linearity of ≤ 0.5%, and sensitivity change vs. temperature of ≤ |
| 0.03%/C°. |
| </li> |
| </ul> |
| </li> |
| <li> |
| <p> |
| SENSOR_TYPE_GYROSCOPE |
| </p> |
| <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 maximum measurement frequency of 400 Hz or higher. |
| </li> |
| <li> |
| MUST have a measurement noise not above 0.014°/s/√Hz. |
| </li> |
| <li> |
| SHOULD have a stationary bias stability of < 0.0002 °/s √Hz from 24-hour static dataset. |
| </li> |
| <li> |
| SHOULD have a bias change vs. temperature of ≤ +/- 0.05 °/ s / °C. |
| </li> |
| <li> |
| SHOULD have a sensitivity change vs. temperature of ≤ 0.02% / °C. |
| </li> |
| <li> |
| SHOULD have a best-fit line non-linearity of ≤ 0.2%. |
| </li> |
| <li> |
| SHOULD have a noise density of ≤ 0.007 °/s/√Hz. |
| </li> |
| </ul> |
| </li> |
| <li> |
| <p> |
| SENSOR_TYPE_GYROSCOPE_UNCALIBRATED with the same quality requirements as |
| SENSOR_TYPE_GYROSCOPE. |
| </p> |
| </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 maximum 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_GAME_ROTATION_VECTOR |
| <ul> |
| <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 4 mW. |
| </li> |
| </ul> |
| </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 milliseconds of error. |
| </li> |
| <li> |
| High Fidelity sensors MUST deliver samples to applications within 5 |
| milliseconds from the time when the data is available on the physical sensor |
| to the application. |
| </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_fingerprint_sensor"> |
| 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) that's secured by TEE; the Android Open Source Project |
| implementation provides the mechanism in the framework to do so. |
| </li> |
| <li> |
| MUST NOT enable 3rd-party applications to distinguish between individual |
| fingerprints. |
| </li> |
| <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> |
| <h3 id="7_3_11_android_automotive-only_sensors"> |
| 7.3.11. Android Automotive-only sensors |
| </h3> |
| <p> |
| Automotive-specific sensors are defined in the |
| <code> |
| android.car.CarSensorManager API |
| </code> |
| . |
| </p> |
| <h4 id="7_3_11_1_current_gear"> |
| 7.3.11.1. Current Gear |
| </h4> |
| <p> |
| Android Automotive implementations SHOULD provide current gear as SENSOR_TYPE_GEAR. |
| </p> |
| <h4 id="7_3_11_2_day_night_mode"> |
| 7.3.11.2. Day Night Mode |
| </h4> |
| <p> |
| Android Automotive implementations MUST support day/night mode defined as |
| SENSOR_TYPE_NIGHT. The value of this flag MUST be consistent with dashboard |
| day/night mode and SHOULD be based on ambient light sensor input. The |
| underlying ambient light sensor MAY be the same as |
| <a href="#7_3_7_photometer"> |
| Photometer |
| </a> |
| . |
| </p> |
| <h4 id="7_3_11_3_driving_status"> |
| 7.3.11.3. Driving Status |
| </h4> |
| <p> |
| Android Automotive implementations MUST support driving status defined as |
| SENSOR_TYPE_DRIVING_STATUS, with a default value of DRIVE_STATUS_UNRESTRICTED |
| when the vehicle is fully stopped and parked. It is the responsibility of device |
| manufacturers to configure SENSOR_TYPE_DRIVING_STATUS in compliance with all |
| laws and regulations that apply to markets where the product is shipping. |
| </p> |
| <h4 id="7_3_11_4_wheel_speed"> |
| 7.3.11.4. Wheel Speed |
| </h4> |
| <p> |
| Android Automotive implementations MUST provide vehicle speed defined as |
| SENSOR_TYPE_CAR_SPEED. |
| </p> |
| <h2 id="7_3_12_pose_sensor"> |
| 7.3.12. Pose Sensor |
| </h2> |
| <p> |
| Device implementations MAY support pose sensor with 6 degrees of freedom. Android Handheld |
| devices are RECOMMENDED to support this sensor. If a device implementation does support pose |
| sensor with 6 degrees of freedom, it: |
| </p> |
| <ul> |
| <li> |
| MUST implement and report |
| <a href="https://developer.android.com/reference/android/hardware/Sensor.html#TYPE_POSE_6DOF"> |
| <code> |
| TYPE_POSE_6DOF |
| </code> |
| </a> |
| sensor. |
| </li> |
| <li> |
| MUST be more accurate than the rotation vector alone. |
| </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> |
| <h4 id="7_4_1_1_number_blocking_compatibility"> |
| 7.4.1.1. Number Blocking Compatibility |
| </h4> |
| <p> |
| Android Telephony device implementations MUST include number blocking support |
| and: |
| </p> |
| <ul> |
| <li> |
| MUST fully implement |
| <a href="http://developer.android.com/reference/android/provider/BlockedNumberContract.html"> |
| BlockedNumberContract |
| </a> |
| and the corresponding API as described in the SDK documentation. |
| </li> |
| <li> |
| MUST block all calls and messages from a phone number in |
| 'BlockedNumberProvider' without any interaction with apps. The only exception |
| is when number blocking is temporarily lifted as described in the SDK |
| documentation. |
| </li> |
| <li> |
| MUST NOT write to the |
| <a href="http://developer.android.com/reference/android/provider/CallLog.html"> |
| platform call log provider |
| </a> |
| for a blocked call. |
| </li> |
| <li> |
| MUST NOT write to the |
| <a href="http://developer.android.com/reference/android/provider/Telephony.html"> |
| Telephony provider |
| </a> |
| for a blocked message. |
| </li> |
| <li> |
| MUST implement a blocked numbers management UI, which is opened with the |
| intent returned by TelecomManager.createManageBlockedNumbersIntent() method. |
| </li> |
| <li> |
| MUST NOT allow secondary users to view or edit the blocked numbers on the |
| device as the Android platform assumes the primary user to have full control |
| of the telephony services, a single instance, on the device. All blocking |
| related UI MUST be hidden for secondary users and the blocked list MUST still |
| be respected. |
| </li> |
| <li> |
| SHOULD migrate the blocked numbers into the provider when a device updates |
| to Android 7.0. |
| </li> |
| </ul> |
| <h3 id="7_4_2_ieee_802_11_(wi-fi)"> |
| 7.4.2. IEEE 802.11 (Wi-Fi) |
| </h3> |
| <p> |
| All Android device implementations 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> |
| </li> |
| </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> |
| <p> |
| Device implementations SHOULD include support for |
| <a href="http://developer.android.com/reference/android/net/wifi/WifiManager.html"> |
| Wi-Fi |
| Tunneled Direct Link Setup (TDLS) |
| </a> |
| 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"> |
| Android Watch implementations MUST support Bluetooth. Android Television |
| implementations MUST support Bluetooth and Bluetooth LE. Android Automotive |
| implementations MUST support Bluetooth and SHOULD support Bluetooth LE. |
| </div> |
| <p> |
| Device implementations that support |
| <code> |
| android.hardware.vr.high_performance |
| </code> |
| feature MUST |
| support Bluetooth 4.2 and Bluetooth LE Data Length Extension. |
| </p> |
| <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. |
| </p> |
| <p> |
| Android Automotive implementations SHOULD support Message Access Profile (MAP). |
| Android Automotive implementations MUST support the following Bluetooth |
| profiles: |
| </p> |
| <ul> |
| <li> |
| Phone calling over Hands-Free Profile (HFP). |
| </li> |
| <li> |
| Media playback over Audio Distribution Profile (A2DP). |
| </li> |
| <li> |
| Media playback control over Remote Control Profile (AVRCP). |
| </li> |
| <li> |
| Contact sharing using the Phone Book Access Profile (PBAP). |
| </li> |
| </ul> |
| <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> |
| <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> |
| . |
| </li> |
| <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> |
| <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> |
| </li> |
| </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 (for NfcA |
| and/or NfcB) and it supports 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> |
| If a device implementation does include an NFC controller chipset capable of HCE |
| for NfcF, and it implements the feature for third-party applications, then it: |
| </p> |
| <ul> |
| <li> |
| MUST report the android.hardware.nfc.hcef feature constant. |
| </li> |
| <li> |
| MUST implement the [NfcF Card Emulation APIs] |
| (https://developer.android.com/reference/android/nfc/cardemulation/NfcFCardEmulation.html) |
| 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> |
| <h3 id="7_4_7_data_saver"> |
| 7.4.7. Data Saver |
| </h3> |
| <p> |
| Device implementations with a metered connection are STRONGLY RECOMMENDED to provide the |
| data saver mode. |
| </p> |
| <p> |
| If a device implementation provides the data saver mode, it: |
| </p> |
| <ul> |
| <li> |
| <p> |
| MUST support all the APIs in the |
| <code> |
| ConnectivityManager |
| </code> |
| class as described in the |
| <a href="https://developer.android.com/training/basics/network-ops/data-saver.html"> |
| SDK documentation |
| </a> |
| </p> |
| </li> |
| <li> |
| <p> |
| MUST provide a user interface in the settings, allowing users to add |
| applications to or remove applications from the whitelist. |
| </p> |
| </li> |
| </ul> |
| <p> |
| Conversely if a device implementation does not provide the data saver mode, it: |
| </p> |
| <ul> |
| <li> |
| <p> |
| MUST return the value |
| <code> |
| RESTRICT_BACKGROUND_STATUS_DISABLED |
| </code> |
| for |
| <a href="https://developer.android.com/reference/android/net/ConnectivityManager.html#getRestrictBackgroundStatus%28%29"> |
| <code> |
| ConnectivityManager.getRestrictBackgroundStatus() |
| </code> |
| </a> |
| </p> |
| </li> |
| <li> |
| <p> |
| MUST not broadcast |
| <code> |
| ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED |
| </code> |
| </p> |
| </li> |
| <li> |
| <p> |
| MUST have an activity that handles the |
| <code> |
| Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS |
| </code> |
| intent but MAY implement it as a no-op. |
| </p> |
| </li> |
| </ul> |
| <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 MUST be possible for |
| an application to simultaneously allocate 3 RGBA_8888 bitmaps equal to the size |
| of the images produced by the largest-resolution camera sensor on the device, |
| while camera is open for the purpose of basic preview and still capture. |
| </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 MAY include support for an external camera that is not |
| necessarily always connected. If a device includes support for an external camera, |
| it: |
| </p> |
| <ul> |
| <li> |
| MUST declare the platform feature flag |
| <code> |
| android.hardware.camera.external |
| </code> |
| and |
| <code> |
| android.hardware camera.any |
| </code> |
| . |
| </li> |
| <li> |
| MAY support multiple cameras. |
| </li> |
| <li> |
| MUST support USB Video Class (UVC 1.0 or higher) if the external camera |
| connects through the USB port. |
| </li> |
| <li> |
| SHOULD support video compressions such as MJPEG to enable transfer of |
| high-quality unencoded streams (i.e. raw or independently compressed picture |
| streams). |
| </li> |
| <li> |
| MAY support camera-based video encoding. If supported, a simultaneous |
| unencoded / MJPEG stream (QVGA or greater resolution) MUST be accessible to |
| the device implementation. |
| </li> |
| </ul> |
| <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"> |
| Android Television devices MUST have at least 4GB of non-volatile storage |
| available for application private data. |
| </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> |
| 512MB |
| </td> |
| <td> |
| 816MB |
| </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> |
| 608MB |
| </td> |
| <td> |
| 944MB |
| </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 4GB and other device |
| implementations MUST have at least 3GB of non-volatile storage available for |
| application private data. That is, the /data partition MUST be at least 4GB for |
| Android Television devices and at least 3GB for other device implementations. |
| Device implementations that run Android are |
| <strong> |
| STRONGLY RECOMMENDED |
| </strong> |
| to have at |
| least 4GB 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> |
| <h3 id="7_7_1_usb_peripheral_mode"> |
| 7.7.1. USB peripheral mode |
| </h3> |
| <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 be located 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 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> |
| Type-C devices MUST detect 1.5A and 3.0A chargers per the Type-C resistor |
| standard and it must detect changes in the advertisement. |
| </li> |
| <li> |
| Type-C devices also supporting USB host mode are STRONGLY RECOMMENDED to |
| support Power Delivery for data and power role swapping. |
| </li> |
| <li> |
| Type-C devices SHOULD support Power Delivery for high-voltage charging and |
| support for Alternate Modes such as display out. |
| </li> |
| <li> |
| The value of iSerialNumber in USB standard device descriptor MUST be equal |
| to the value of android.os.Build.SERIAL. |
| </li> |
| <li> |
| Type-C devices are STRONGLY RECOMMENDED to not support proprietary charging |
| methods that modify Vbus voltage beyond default levels, or alter sink/source |
| roles as such may result in interoperability issues with the chargers or |
| devices that support the standard USB Power Delivery methods. While this is |
| called out as "STRONGLY RECOMMENDED", in future Android versions we might |
| REQUIRE all type-C devices to support full interoperability with standard |
| type-C chargers. |
| </li> |
| </ul> |
| <h3 id="7_7_2_usb_host_mode"> |
| 7.7.2. USB host mode |
| </h3> |
| <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> |
| <li> |
| USB Type-C devices are STRONGLY RECOMMENDED to support DisplayPort, SHOULD |
| support USB SuperSpeed Data Rates, and are STRONGLY RECOMMENDED to support |
| Power Delivery for data and power role swapping. |
| </li> |
| <li> |
| Devices with any type-A or type-AB ports MUST NOT ship with an adapter converting |
| from this port to a type-C receptacle. |
| </li> |
| <li> |
| MUST recognize any remotely connected MTP (Media Transfer Protocol) devices |
| and make their contents accessible through the |
| <code> |
| ACTION_GET_CONTENT |
| </code> |
| , |
| <code> |
| ACTION_OPEN_DOCUMENT |
| </code> |
| , and |
| <code> |
| ACTION_CREATE_DOCUMENT |
| </code> |
| intents, if the Storage Access |
| Framework (SAF) is supported. |
| </li> |
| <li> |
| MUST, if using a Type-C USB port and including support for peripheral mode, |
| implement Dual Role Port functionality as defined by the USB Type-C |
| specification (section 4.5.1.3.3). |
| </li> |
| <li> |
| SHOULD, if the Dual Role Port functionality is supported, implement the |
| Try.* model that is most appropriate for the device form factor. For |
| example a handheld device SHOULD implement the Try.SNK model. |
| </li> |
| </ul> |
| <h2 id="7_8_audio"> |
| 7.8. Audio |
| </h2> |
| <h3 id="7_8_1_microphone"> |
| 7.8.1. Microphone |
| </h3> |
| <div class="note"> |
| Android Handheld, Watch, and Automotive implementations MUST include a |
| microphone. |
| </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"> |
| Android Watch devices MAY include an audio output. |
| </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> |
| MUST support the detection and mapping to the keycodes for the following |
| 3 ranges of equivalent impedance between the microphone and ground conductors |
| on the audio plug: |
| <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> |
| STRONGLY RECOMMENDED to detect and map to the keycode for the following |
| range of equivalent impedance between the microphone and ground conductors |
| on the audio plug: |
| <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%28java.lang.String%29"> |
| 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 the following requirements must be met by the |
| VOICE_RECOGNITION and UNPROCESSED audio sources: |
| <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 microphone's unweighted signal to noise ratio over 18.5 kHz to 20 kHz |
| for a 19 kHz tone at -26 dBFS MUST be no lower than 50 dB. |
| </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> |
| <h2 id="7_9_virtual_reality"> |
| 7.9. Virtual Reality |
| </h2> |
| <p> |
| Android includes APIs and facilities to build "Virtual Reality" (VR) applications including high |
| quality mobile VR experiences. Device implementations MUST properly implement these APIs and |
| behaviors, as detailed in this section. |
| </p> |
| <h3 id="7_9_1_virtual_reality_mode"> |
| 7.9.1. Virtual Reality Mode |
| </h3> |
| <p> |
| Android handheld device implementations that support a mode for VR applications that handles |
| stereoscopic rendering of notifications and disable monocular system UI components while a VR |
| application has user focus MUST declare |
| <code> |
| android.software.vr.mode |
| </code> |
| feature. Devices declaring this |
| feature MUST include an application implementing |
| <code> |
| android.service.vr.VrListenerService |
| </code> |
| that can be |
| enabled by VR applications via |
| <code> |
| android.app.Activity#setVrModeEnabled |
| </code> |
| . |
| </p> |
| <h3 id="7_9_2_virtual_reality_high_performance"> |
| 7.9.2. Virtual Reality High Performance |
| </h3> |
| <p> |
| Android handheld device implementations MUST identify the support of high performance virtual |
| reality for longer user periods through the |
| <code> |
| android.hardware.vr.high_performance |
| </code> |
| feature flag and |
| meet the following requirements. |
| </p> |
| <ul> |
| <li> |
| Device implementations MUST have at least 2 physical cores. |
| </li> |
| <li> |
| Device implementations MUST declare android.software.vr.mode feature. |
| </li> |
| <li> |
| Device implementations MAY provide an exclusive core to the foreground |
| application and MAY support the |
| <code> |
| Process.getExclusiveCores |
| </code> |
| API to return |
| the numbers of the CPU cores that are exclusive to the top foreground |
| application. If exclusive core is supported, then the core MUST not allow |
| any other userspace processes to run on it (except device drivers used |
| by the application), but MAY allow some kernel processes to run as |
| necessary. |
| </li> |
| <li> |
| Device implementations MUST support sustained performance mode. |
| </li> |
| <li> |
| Device implementations MUST support OpenGL ES 3.2. |
| </li> |
| <li> |
| Device implementations MUST support Vulkan Hardware Level 0 and SHOULD support |
| Vulkan Hardware Level 1. |
| </li> |
| <li> |
| Device implementations MUST implement EGL_KHR_mutable_render_buffer and |
| EGL_ANDROID_front_buffer_auto_refresh, EGL_ANDROID_create_native_client_buffer, |
| EGL_KHR_fence_sync and EGL_KHR_wait_sync so that they may be used for Shared Buffer Mode, and |
| expose the extensions in the list of available EGL extensions. |
| </li> |
| <li> |
| The GPU and display MUST be able to synchronize access to the shared front buffer such that |
| alternating-eye rendering of VR content at 60fps with two render contexts will be displayed with |
| no visible tearing artifacts. |
| </li> |
| <li> |
| Device implementations MUST implement EGL_IMG_context_priority, and expose the extension in the |
| list of available EGL extensions. |
| </li> |
| <li> |
| Device implementations MUST implement GL_EXT_multisampled_render_to_texture, GL_OVR_multiview, |
| GL_OVR_multiview2 and GL_OVR_multiview_multisampled_render_to_texture, and expose the extensions |
| in the list of available GL extensions. |
| </li> |
| <li> |
| Device implementations MUST implement EGL_EXT_protected_content and GL_EXT_protected_textures so |
| that it may be used for Secure Texture Video Playback, and expose the extensions in the list of |
| available EGL and GL extensions. |
| </li> |
| <li> |
| Device implementations MUST support H.264 decoding at least 3840x2160@30fps-40Mbps (equivalent |
| to 4 instances of 1920x1080@30fps-10Mbps or 2 instances of 1920x1080@60fps-20Mbps). |
| </li> |
| <li> |
| Device implementations MUST support HEVC and VP9, MUST be capable to decode at least |
| 1920x1080@30fps-10Mbps and SHOULD be capable to decode 3840x2160@30fps-20Mbps (equivalent to |
| 4 instances of 1920x1080@30fps-5Mbps). |
| </li> |
| <li> |
| The device implementations are STRONGLY RECOMMENDED to support |
| android.hardware.sensor.hifi_sensors feature and MUST meet the gyroscope, accelerometer, and |
| magnetometer related requirements for android.hardware.hifi_sensors. |
| </li> |
| <li> |
| Device implementations MUST support HardwarePropertiesManager.getDeviceTemperatures API and |
| return accurate values for skin temperature. |
| </li> |
| <li> |
| The device implementation MUST have an embedded screen, and its resolution MUST be at least be |
| FullHD(1080p) and STRONGLY RECOMMENDED TO BE be QuadHD (1440p) or higher. |
| </li> |
| <li> |
| The display MUST measure between 4.7" and 6" diagonal. |
| </li> |
| <li> |
| The display MUST update at least 60 Hz while in VR Mode. |
| </li> |
| <li> |
| The display latency on Gray-to-Gray, White-to-Black, and Black-to-White switching time MUST |
| be ≤ 3 ms. |
| </li> |
| <li> |
| The display MUST support a low-persistence mode with ≤5 ms persistence,persistence being |
| defined as the amount of time for which a pixel is emitting light. |
| </li> |
| <li> |
| Device implementations MUST support Bluetooth 4.2 and Bluetooth LE Data Length Extension |
| <a href="#7_4_3_bluetooth"> |
| section 7.4.3 |
| </a> |
| . |
| </li> |
| </ul> |
| <h1 id="8_performance_and_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> |
| Android 6.0 introduced App Standby and Doze power-saving modes to optimize |
| battery usage. All Apps exempted from these modes MUST be made visible to the |
| end user. Further, the triggering, maintenance, wakeup algorithms and the use of |
| global system settings of these power-saving modes MUST not deviate from the |
| Android Open Source Project. |
| </p> |
| <p> |
| In addition to the power-saving modes, Android device implementations MAY |
| implement any or all of the 4 sleeping power states as defined by the Advanced |
| Configuration and Power Interface (ACPI), but if it implements S3 and S4 |
| power states, it can only enter these states when closing a lid that is |
| physically part of the device. |
| </p> |
| <h2 id="8_4_power_consumption_accounting"> |
| 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> |
| <h2 id="8_5_consistent_performance"> |
| 8.5. Consistent Performance |
| </h2> |
| <p> |
| Performance can fluctuate dramatically for high-performance long-running apps, |
| either because of the other apps running in the background or the CPU throttling |
| due to temperature limits. Android includes programmatic interfaces so that when |
| the device is capable, the top foreground application can request that the system |
| optimize the allocation of the resources to address such fluctuations. |
| </p> |
| <p> |
| Device implementations SHOULD support Sustained Performance Mode which can |
| provide the top foreground application a consistent level of performance for a |
| prolonged amount of time when requested through the |
| <a href="https://developer.android.com/reference/android/view/Window.html#setSustainedPerformanceMode%28boolean%29"> |
| <code> |
| Window.setSustainedPerformanceMode() |
| </code> |
| </a> |
| API method. A Device implementation MUST report the support of Sustained |
| Performance Mode accurately through the |
| <a href="https://developer.android.com/reference/android/os/PowerManager.html#isSustainedPerformanceModeSupported%28%29"> |
| <code> |
| PowerManager.isSustainedPerformanceModeSupported() |
| </code> |
| </a> |
| API method. |
| </p> |
| <p> |
| Device implementations with two or more CPU cores SHOULD provide at least one exclusive core that |
| can be reserved by the top foreground application. If provided, implementations MUST meet the |
| following requirements: |
| </p> |
| <ul> |
| <li> |
| Implementations MUST report through the |
| <a href="https://developer.android.com/reference/android/os/Process.html#getExclusiveCores%28%29"> |
| <code> |
| Process.getExclusiveCores() |
| </code> |
| </a> |
| API method the id numbers of the exclusive cores that can be reserved by the top foreground |
| application. |
| </li> |
| <li> |
| Device implementations MUST not allow any user space processes except the device drivers used |
| by the application to run on the exclusive cores, but MAY allow some kernel processes to run |
| as necessary. |
| </li> |
| </ul> |
| <p> |
| If a device implementation does not support an exclusive core, it MUST return an |
| empty list through the |
| <a href="https://developer.android.com/reference/android/os/Process.html#getExclusiveCores%28%29"> |
| <code> |
| Process.getExclusiveCores() |
| </code> |
| </a> |
| API method. |
| </p> |
| <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 |
| <code> |
| protectionLevel |
| </code> |
| of |
| <a href="https://developer.android.com/reference/android/content/pm/PermissionInfo.html#PROTECTION_FLAG_PRIVILEGED"> |
| 'PROTECTION_FLAG_PRIVILEGED' |
| </a> |
| MUST only be granted to apps preloaded in the whitelisted privileged path(s) |
| of the system image, such as the |
| <code> |
| system/priv-app |
| </code> |
| path in the AOSP |
| implementation. |
| </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"> |
| This feature is optional for all device types. |
| </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> |
| Android Automotive device implementations with multi-user support enabled |
| MUST include a guest account that allows all functions provided by the vehicle |
| system without requiring a user to log in. |
| </li> |
| <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, seccomp sandboxing, 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 |
| system/sepolicy folder provided in the upstream Android Open Source Project |
| (AOSP) and the policy MUST compile with all neverallow rules present, for both |
| AOSP SELinux domains as well as device/vendor specific domains. |
| </li> |
| <li> |
| MUST split the media framework into multiple processes so that it |
| is possible to more narrowly grant access for each process as |
| <a href="https://source.android.com/devices/media/framework-hardening.html#arch_changes"> |
| described |
| </a> |
| in the Android Open Source Project site. |
| </li> |
| </ul> |
| <p> |
| Device implementations SHOULD retain the default SELinux policy provided in the |
| system/sepolicy folder of the upstream Android Open Source Project and only |
| further add to this policy for their own device-specific configuration. Device |
| implementations MUST be compatible with the upstream Android Open Source |
| Project. |
| </p> |
| <p> |
| Devices MUST implement a kernel application sandboxing mechanism which allows |
| filtering of system calls using a configurable policy from multithreaded |
| programs. The upstream Android Open Source Project meets this requirement |
| through enabling the seccomp-BPF with threadgroup synchronization (TSYNC) as |
| described |
| <a href="http://source.android.com/devices/tech/config/kernel.html#Seccomp-BPF-TSYNC"> |
| in the Kernel Configuration section of source.android.com |
| </a> |
| . |
| </p> |
| <h2 id="9_8_privacy"> |
| 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, unless that |
| VPN is enabled by the Device Policy Controller via the |
| <a href="https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setAlwaysOnVpnPackage(android.content.ComponentName, java.lang.String, boolean)"> |
| <code> |
| DevicePolicyManager.setAlwaysOnVpnPackage() |
| </code> |
| </a> |
| , in which case the user does not need to provide a separate consent, but MUST |
| only be notified. |
| </p> |
| <p> |
| Device implementations MUST ship with an empty user-added Certificate Authority |
| (CA) store, and MUST preinstall the same root certificates for the system-trusted |
| CA store as |
| <a href="https://source.android.com/security/overview/app-security.html#certificate-authorities"> |
| provided |
| </a> |
| in the upstream Android Open Source Project. |
| </p> |
| <p> |
| When devices are routed through a VPN, or a user root CA is installed, the |
| implementation MUST display a warning indicating the network traffic may be |
| monitored to the user. |
| </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_data_storage_encryption"> |
| 9.9. Data Storage Encryption |
| </h2> |
| <div class="note"> |
| Optional for Android device implementations without a secure lock screen. |
| </div> |
| <p> |
| If the device implementation supports a secure lock screen as described in section 9.11.1, |
| then the device MUST support data storage encryption 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 data storage encryption and with Advanced |
| Encryption Standard (AES) crypto performance above 50MiB/sec, the data storage |
| 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 encryption disabled by default, such |
| a device cannot meet the requirement through a system software update and thus |
| MAY be exempted. |
| </p> |
| <p> |
| Device implementations SHOULD meet the above data storage encryption requirement |
| via implementing |
| <a href="https://source.android.com/security/encryption/file-based.html"> |
| File Based Encryption |
| </a> |
| (FBE). |
| </p> |
| <h3 id="9_9_1_direct_boot"> |
| 9.9.1. Direct Boot |
| </h3> |
| <p> |
| All devices MUST implement the |
| <a href="http://developer.android.com/preview/features/direct-boot.html"> |
| Direct Boot mode |
| </a> |
| APIs even |
| if they do not support Storage Encryption. In particular, the |
| <a href="https://developer.android.com/reference/android/content/Intent.html#LOCKED_BOOT_COMPLETED"> |
| LOCKED_BOOT_COMPLETED |
| </a> |
| and |
| <a href="https://developer.android.com/reference/android/content/Intent.html#ACTION_USER_UNLOCKED"> |
| ACTION_USER_UNLOCKED |
| </a> |
| Intents must still be broadcast to signal Direct Boot aware applications that |
| Device Encrypted (DE) and Credential Encrypted (CE) storage locations are |
| available for user. |
| </p> |
| <h3 id="9_9_2_file_based_encryption"> |
| 9.9.2. File Based Encryption |
| </h3> |
| <p> |
| Device implementations supporting FBE: |
| </p> |
| <ul> |
| <li> |
| MUST boot up without challenging the user for credentials and allow Direct |
| Boot aware apps to access to the Device Encrypted (DE) storage after the |
| LOCKED_BOOT_COMPLETED message is broadcasted. |
| </li> |
| <li> |
| MUST only allow access to Credential Encrypted (CE) storage after the user |
| has unlocked the device by supplying their credentials (eg. passcode, pin, |
| pattern or fingerprint) and the ACTION_USER_UNLOCKED message is broadcasted. |
| Device implementations MUST NOT offer any |
| method to unlock the CE protected storage without the user supplied |
| credentials. |
| </li> |
| <li> |
| MUST support Verified Boot and ensure that DE keys are cryptographically |
| bound to the device's hardware root of trust. |
| </li> |
| <li> |
| MUST support encrypting file contents using AES with a key length of 256-bits |
| in XTS mode. |
| </li> |
| <li> |
| MUST support encrypting file name using AES with a key length of 256-bits in |
| CBC-CTS mode. |
| </li> |
| <li> |
| MAY support alternative ciphers, key lengths and modes for file content and |
| file name encryption, but MUST use the mandatorily supported ciphers, |
| key lengths and modes by default. |
| </li> |
| <li> |
| SHOULD make preloaded essential apps (e.g. Alarm, Phone, Messenger) |
| Direct Boot aware. |
| </li> |
| </ul> |
| <p> |
| The keys protecting CE and DE storage areas: |
| </p> |
| <ul> |
| <li> |
| MUST be cryptographically bound to a hardware-backed Keystore. CE keys |
| must be bound to a user's lock screen credentials. If the user has |
| specified no lock screen credentials then the CE keys MUST be bound to |
| a default passcode. |
| </li> |
| <li> |
| MUST be unique and distinct, in other words no user's CE or DE key |
| may match any other user's CE or DE keys. |
| </li> |
| </ul> |
| <p> |
| The upstream Android Open Source project provides a preferred implementation of |
| this feature based on the Linux kernel ext4 encryption feature. |
| </p> |
| <h3 id="9_9_3_full_disk_encryption"> |
| 9.9.3. Full Disk Encryption |
| </h3> |
| <p> |
| Device implementations supporting |
| <a href="http://source.android.com/devices/tech/security/encryption/index.html"> |
| full disk encryption |
| </a> |
| (FDE). MUST use AES with a key of 128-bits |
| (or greater) and a mode designed for storage (for example, AES-XTS, |
| AES-CBC-ESSIV). The encryption key MUST NOT be written to storage at any time |
| without being encrypted. The user MUST be provided with the possibility to AES |
| encrypt the encryption key, except when it is in active use, with the lock |
| screen credentials stretched using a slow stretching algorithm |
| (e.g. PBKDF2 or scrypt). If the user has not specified a lock screen |
| credentials or has disabled use of the passcode for encryption, the system |
| SHOULD use a default passcode to wrap the encryption key. If the device |
| provides a hardware-backed keystore, the password stretching algorithm MUST |
| be cryptographically bound to that keystore. The encryption key MUST NOT be |
| sent off the device (even when wrapped with the user passcode and/or hardware |
| bound key). The upstream Android Open Source project provides a preferred |
| implementation of this feature based on the Linux kernel feature dm-crypt. |
| </p> |
| <h2 id="9_10_device_integrity"> |
| 9.10. Device Integrity |
| </h2> |
| <p> |
| The following requirements ensures there is transparancy to the status of the |
| device integrity. |
| </p> |
| <p> |
| Device implementations MUST correctly report through the System API method |
| PersistentDataBlockManager.getFlashLockState() whether their bootloader state |
| permits flashing of the system image. The |
| <code> |
| FLASH_LOCK_UNKNOWN |
| </code> |
| state is reserved |
| for device implementations upgrading from an earlier version of Android where this |
| new system API method did not exist. |
| </p> |
| <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> |
| <li> |
| MUST NOT allow boot to complete when system verification fails, unless the |
| user consents to attempt booting anyway, in which case the data from any |
| non-verified storage blocks MUST not be used. |
| </li> |
| <li> |
| MUST NOT allow verified partitions on the device to be modified unless the |
| user has explicitly unlocked the boot loader. |
| </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 performance above 50 MiB/seconds MUST support verified boot |
| for device integrity. |
| </p> |
| <p> |
| If a device implementation is already launched without supporting verified boot |
| on an earlier version of Android, such a device can not add support for this feature |
| with a system software update and thus are exempted from the requirement. |
| </p> |
| <h2 id="9_11_keys_and_credentials"> |
| 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 MUST have an |
| exponential backoff algorithm. Beyond 150 failed attempts, the delay MUST be |
| at least 24 hours per attempt. |
| </li> |
| <li> |
| When the device implementation supports a secure lock screen it MUST back up the |
| keystore implementation with secure hardware and meet following requirements: |
| <ul> |
| <li> |
| MUST have hardware backed implementations of RSA, AES, ECDSA and HMAC cryptographic |
| algorithms and MD5, SHA1, SHA-2 Family hash functions to properly support the |
| <a href="https://developer.android.com/training/articles/keystore.html#SupportedAlgorithms"> |
| Android Keystore system's supported algorithms |
| </a> |
| . |
| </li> |
| <li> |
| MUST perform the lock screen authentication in the secure hardware and only when |
| successful allow the authentication-bound keys to be used. The upstream Android |
| Open Source Project provides the |
| <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 if a device implementation is already launched on an earlier Android version, and does |
| not have a fingerprint scanner, such a device is exempted from the requirement to have a |
| hardware-backed keystore. |
| </p> |
| <h3 id="9_11_1_secure_lock_screen"> |
| 9.11.1. Secure Lock Screen |
| </h3> |
| <p> |
| Device implementations MAY add or modify the authentication methods to unlock |
| the lock screen, but MUST still meet the following requirements: |
| </p> |
| <ul> |
| <li> |
| The authentication method, if based on a known secret, MUST NOT be treated |
| as a secure lock screen unless it meets all following requirements: |
| <ul> |
| <li> |
| The entropy of the shortest allowed length of inputs MUST be greater |
| than 10 bits. |
| </li> |
| <li> |
| The maximum entropy of all possible inputs MUST be greater than 18 bits. |
| </li> |
| <li> |
| MUST not replace any of the existing authentication methods (PIN, |
| pattern, password) implemented and provided in AOSP. |
| </li> |
| <li> |
| MUST be disabled when the Device Policy Controller (DPC) application |
| has set the password quality policy via the |
| <a href="https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordQuality%28android.content.ComponentName,%20int%29"> |
| <code> |
| DevicePolicyManager.setPasswordQuality() |
| </code> |
| </a> |
| method with a more restrictive quality constant than |
| <code> |
| PASSWORD_QUALITY_SOMETHING |
| </code> |
| . |
| </li> |
| </ul> |
| </li> |
| <li> |
| The authenticaion method, if based on a physical token or the location, |
| MUST NOT be treated as a secure lock screen unless it meets all following |
| requirements: |
| <ul> |
| <li> |
| It MUST have a fall-back mechanism to use one of the primary |
| authentication methods which is based on a known secret and meets |
| the requirements to be treated as a secure lock screen. |
| </li> |
| <li> |
| It MUST be disabled and only allow the primary authentication to |
| unlock the screen when the Device Policy Controller (DPC) application |
| has set the policy with either the |
| <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setKeyguardDisabledFeatures%28android.content.ComponentName,%20int%29"> |
| <code> |
| DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) |
| </code> |
| </a> |
| method or the |
| <a href="https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordQuality%28android.content.ComponentName,%20int%29"> |
| <code> |
| DevicePolicyManager.setPasswordQuality() |
| </code> |
| </a> |
| method with a more restrictive quality constant than |
| <code> |
| PASSWORD_QUALITY_UNSPECIFIED |
| </code> |
| . |
| </li> |
| </ul> |
| </li> |
| <li> |
| The authentication method, if based on biometrics, MUST NOT be treated as a |
| secure lock screen unless it meets all following requirements: |
| <ul> |
| <li> |
| It MUST have a fall-back mechanism to use one of the primary |
| authentication methods which is based on a known secret and meets |
| the requirements to be treated as a secure lock screen. |
| </li> |
| <li> |
| It MUST be disabled and only allow the primary authentication to |
| unlock the screen when the Device Policy Controller (DPC) application |
| has set the keguard feature policy by calling the method |
| <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setKeyguardDisabledFeatures%28android.content.ComponentName,%20int%29"> |
| <code> |
| DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT) |
| </code> |
| </a> |
| . |
| </li> |
| <li> |
| It MUST have a false acceptance rate that is equal or stronger than |
| what is required for a fingerprint sensor as described in |
| section 7.3.10, or otherwise MUST be disabled and only allow the |
| primary authentication to unlock the screen when the Device Policy |
| Controller (DPC) application has set the password quality policy |
| via the |
| <a href="https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordQuality%28android.content.ComponentName,%20int%29"> |
| <code> |
| DevicePolicyManager.setPasswordQuality() |
| </code> |
| </a> |
| method with a more restrictive quality constant than |
| <code> |
| PASSWORD_QUALITY_BIOMETRIC_WEAK |
| </code> |
| . |
| </li> |
| </ul> |
| </li> |
| <li> |
| If the authentication method can not be treated as a secure lock screen, |
| it: |
| <ul> |
| <li> |
| MUST return |
| <code> |
| false |
| </code> |
| for both the |
| <a href="http://developer.android.com/reference/android/app/KeyguardManager.html#isKeyguardSecure%28%29"> |
| <code> |
| KeyguardManager.isKeyguardSecure() |
| </code> |
| </a> |
| and the |
| <a href="https://developer.android.com/reference/android/app/KeyguardManager.html#isDeviceSecure%28%29"> |
| <code> |
| KeyguardManager.isDeviceSecure() |
| </code> |
| </a> |
| methods. |
| </li> |
| <li> |
| MUST be disabled when the Device Policy Controller (DPC) application |
| has set the password quality policy via the |
| <a href="https://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordQuality%28android.content.ComponentName,%20int%29"> |
| <code> |
| DevicePolicyManager.setPasswordQuality() |
| </code> |
| </a> |
| method with a more restrictive quality constant than |
| <code> |
| PASSWORD_QUALITY_UNSPECIFIED |
| </code> |
| . |
| </li> |
| <li> |
| MUST NOT reset the password expiration timers set by |
| <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordExpirationTimeout%28android.content.ComponentName,%20long%29"> |
| <code> |
| DevicePolicyManager.setPasswordExpirationTimeout() |
| </code> |
| </a> |
| . |
| </li> |
| <li> |
| MUST NOT authenticate access to keystores if the application has called |
| <a href="https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired%28boolean%29"> |
| <code> |
| KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true) |
| </code> |
| </a> |
| ). |
| </li> |
| </ul> |
| </li> |
| <li> |
| If the authentication method is based on a physical token, the location, |
| or biometrics that has higher false acceptance rate than what is required |
| for fingerprint sensors as described in section 7.3.10, then it: |
| <ul> |
| <li> |
| MUST NOT reset the password expiration timers set by |
| <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#setPasswordExpirationTimeout%28android.content.ComponentName,%20long%29"> |
| <code> |
| DevicePolicyManager.setPasswordExpirationTimeout() |
| </code> |
| </a> |
| . |
| </li> |
| <li> |
| MUST NOT authenticate access to keystores if the application has called |
| <a href="https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUserAuthenticationRequired%28boolean%29"> |
| <code> |
| KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true) |
| </code> |
| </a> |
| . |
| </li> |
| </ul> |
| </li> |
| </ul> |
| <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 following: |
| </p> |
| <ul> |
| <li> |
| The system image |
| </li> |
| <li> |
| Any operating system files required by the system image |
| </li> |
| </ul> |
| <p> |
| 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> |
| <h2 id="9_13_safe_boot_mode"> |
| 9.13. Safe Boot Mode |
| </h2> |
| <p> |
| Android provides a mode enabling users to boot up into a mode where only |
| preinstalled system apps are allowed to run and all third-party apps are |
| disabled. This mode, known as "Safe Boot Mode", provides the user the |
| capability to uninstall potentially harmful third-party apps. |
| </p> |
| <p> |
| Android device implementations are STRONGLY RECOMENDED to implement Safe Boot |
| Mode and meet following requirements: |
| </p> |
| <ul> |
| <li> |
| <p> |
| Device implementations SHOULD provide the user an option to enter Safe Boot |
| Mode from the boot menu which is reachable through a workflow that is different |
| from that of normal boot. |
| </p> |
| </li> |
| <li> |
| <p> |
| Device implementations MUST provide the user an option to enter Safe Boot Mode |
| in such a way that is uninterruptible from third-party apps installed on |
| the device, except for when the third party app is a Device Policy Controller |
| and has set the |
| <a href="https://developer.android.com/reference/android/os/UserManager.html#DISALLOW_SAFE_BOOT"> |
| <code> |
| UserManager.DISALLOW_SAFE_BOOT |
| </code> |
| </a> |
| flag as true. |
| </p> |
| </li> |
| <li> |
| <p> |
| Device implementations MUST provide the user the capability to uninstall |
| any third-party apps within Safe Mode. |
| </p> |
| </li> |
| </ul> |
| <h2 id="9_14_automotive_vehicle_system_isolation"> |
| 9.14. Automotive Vehicle System Isolation |
| </h2> |
| <p> |
| Android Automotive devices are expected to exchange data with critical vehicle |
| subsystems, e.g., by using the |
| <a href="http://source.android.com/devices/automotive.html"> |
| vehicle HAL |
| </a> |
| to send and receive messages over vehicle networks such as CAN bus. Android |
| Automotive device implementations MUST implement security features below the |
| Android framework layers to prevent malicious or unintentional interaction |
| between the Android framework or third-party apps and vehicle subsystems. These |
| security features are as follows: |
| </p> |
| <ul> |
| <li> |
| Gatekeeping messages from Android framework vehicle subsystems, e.g., |
| whitelisting permitted message types and message sources. |
| </li> |
| <li> |
| Watchdog against denial of service attacks from the Android framework or |
| third-party apps. This guards against malicious software flooding the vehicle |
| network with traffic, which may lead to malfunctioning vehicle subsystems. |
| </li> |
| </ul> |
| <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 7.1. Device implementations MUST pass the latest CTS |
| version available at the time the device software is completed. |
| </p> |
| <h2 id="10_2_cts_verifier"> |
| 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, it |
| MUST support OTA downloads with offline update via reboot. |
| </p> |
| <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> |
| Also, device implementations SHOULD support |
| <a href="https://source.android.com/devices/tech/ota/ab_updates.html"> |
| A/B system updates |
| </a> |
| . |
| The AOSP implements this feature using the boot control HAL. |
| </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: |
| </p> |
| <ul> |
| <li> |
| <a href="https://android.googlesource.com/platform/compatibility/cdd/+log/nougat-mr1-dev/?pretty=full&no-merges"> |
| Document changelog |
| </a> |
| </li> |
| </ul> |
| <p> |
| For a summary of changes to individuals sections: |
| </p> |
| <ol> |
| <li> |
| <a href="https://android.googlesource.com/platform/compatibility/cdd/+log/nougat-mr1-dev/1_introduction?pretty=full&no-merges"> |
| Introduction |
| </a> |
| </li> |
| <li> |
| <a href="https://android.googlesource.com/platform/compatibility/cdd/+log/nougat-mr1-dev/2_device_types?pretty=full&no-merges"> |
| Device Types |
| </a> |
| </li> |
| <li> |
| <a href="https://android.googlesource.com/platform/compatibility/cdd/+log/nougat-mr1-dev/3_software?pretty=full&no-merges"> |
| Software |
| </a> |
| </li> |
| <li> |
| <a href="https://android.googlesource.com/platform/compatibility/cdd/+log/nougat-mr1-dev/4_application-packaging?pretty=full&no-merges"> |
| Application Packaging |
| </a> |
| </li> |
| <li> |
| <a href="https://android.googlesource.com/platform/compatibility/cdd/+log/nougat-mr1-dev/5_multimedia?pretty=full&no-merges"> |
| Multimedia |
| </a> |
| </li> |
| <li> |
| <a href="https://android.googlesource.com/platform/compatibility/cdd/+log/nougat-mr1-dev/6_dev-tools-and-options?pretty=full&no-merges"> |
| Developer Tools and Options |
| </a> |
| </li> |
| <li> |
| <a href="https://android.googlesource.com/platform/compatibility/cdd/+log/nougat-mr1-dev/7_hardware-compatibility?pretty=full&no-merges"> |
| Hardware Compatibility |
| </a> |
| </li> |
| <li> |
| <a href="https://android.googlesource.com/platform/compatibility/cdd/+log/nougat-mr1-dev/8_performance-and-power?pretty=full&no-merges"> |
| Performance and Power |
| </a> |
| </li> |
| <li> |
| <a href="https://android.googlesource.com/platform/compatibility/cdd/+log/nougat-mr1-dev/9_security-model?pretty=full&no-merges"> |
| Security Model |
| </a> |
| </li> |
| <li> |
| <a href="https://android.googlesource.com/platform/compatibility/cdd/+log/nougat-mr1-dev/10_software-compatibility-testing?pretty=full&no-merges"> |
| Software Compatibility Testing |
| </a> |
| </li> |
| <li> |
| <a href="https://android.googlesource.com/platform/compatibility/cdd/+log/nougat-mr1-dev/11_updatable-software?pretty=full&no-merges"> |
| Updatable Software |
| </a> |
| </li> |
| <li> |
| <a href="https://android.googlesource.com/platform/compatibility/cdd/+log/nougat-mr1-dev/12_document-changelog?pretty=full&no-merges"> |
| Document Changelog |
| </a> |
| </li> |
| <li> |
| <a href="https://android.googlesource.com/platform/compatibility/cdd/+log/nougat-mr1-dev/13_contact-us?pretty=full&no-merges"> |
| Contact Us |
| </a> |
| </li> |
| </ol> |
| <h2 id="12_1_changelog_viewing_tips"> |
| 12.1. Changelog Viewing Tips |
| </h2> |
| <p> |
| Changes are marked as follows: |
| </p> |
| <ul> |
| <li> |
| <p> |
| <strong> |
| CDD |
| </strong> |
| <br/> |
| Substantive changes to the compatibility requirements. |
| </p> |
| </li> |
| <li> |
| <p> |
| <strong> |
| Docs |
| </strong> |
| <br/> |
| Cosmetic or build related changes. |
| </p> |
| </li> |
| </ul> |
| <p> |
| For best viewing, append the |
| <code> |
| pretty=full |
| </code> |
| and |
| <code> |
| no-merges |
| </code> |
| URL parameters to your |
| changelog URLs. |
| </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> |