Compatibility Definition

Recommendations

Info

SENSOR_TYPE_STEP_COUNTER SENSOR_TILT_DETECTORS 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. 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: SENSOR_TYPE_PROXIMITY: 100 sensor events 7.3.10. Fingerprint Sensor 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: MUST declare support for the android.hardware.fingerprint feature. MUST fully implement the corresponding API as described in the Android SDK documentation [Resources, 95]. MUST have a false acceptance rate not higher than 0.002%. Is STRONGLY RECOMMENDED to have a false rejection rate not higher than 10%, and a latency from when the fingerprint sensor is touched until the screen is unlocked below 1 second, for 1 enrolled finger. MUST rate limit attempts for at least 30 seconds after 5 false trials for fingerprint verification. 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. 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 implementation guidelines on the Android Open Source Project site [Resources, 96]. MUST prevent adding a fingerprint without first establishing a chain of trust by having the user confirm existing or add a new device credential (PIN/pattern/password) using the TEE as implemented in the Android Open Source project. MUST NOT enable 3rd-party applications to distinguish between individual fingerprints. MUST honor the DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT flag. MUST, when upgraded from a version earlier than Android 6.0, have the fingerprint data securely migrated to meet the above requirements or removed. SHOULD use the Android Fingerprint icon provided in the Android Open Source Project. 7.4. Data Connectivity 7.4.1. Telephony “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 Page 48 of 74
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. 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. 7.4.2. IEEE 802.11 (Wi-Fi) Android Television device implementations MUST include Wi-Fi support. Android Television device implementations MUST include support for one or more forms of 802.11 (b/g/a/n, etc.) and other types of Android device implementation SHOULD include support for one or more forms of 802.11. If a device implementation does include support for 802.11 and exposes the functionality to a third-party application, it MUST implement the corresponding Android API and: MUST report the hardware feature flag android.hardware.wifi. MUST implement the multicast API as described in the SDK documentation [Resources, 97]. MUST support multicast DNS (mDNS) and MUST NOT filter mDNS packets (224.0.0.251) at any time of operation including: Even when the screen is not in an active state. For Android Television device implementations, even when in standby power states. 7.4.2.1. Wi-Fi Direct 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 corresponding Android API as described in the SDK documentation [Resources, 98]. If a device implementation includes support for Wi-Fi Direct, then it: MUST report the hardware feature android.hardware.wifi.direct. MUST support regular Wi-Fi operation. SHOULD support concurrent Wi-Fi and Wi-Fi Direct operation. 7.4.2.2. Wi-Fi Tunneled Direct Link Setup Android Television device implementations MUST include support for Wi-Fi Tunneled Direct Link Setup (TDLS). Android Television device implementations MUST include support for Wi-Fi Tunneled Direct Link Setup (TDLS) and other types of Android device implementations SHOULD include support for Wi-Fi TDLS as described in the Android SDK Documentation [Resources, 99]. If a device implementation does include support for TDLS and TDLS is enabled by the WiFiManager API, the device: SHOULD use TDLS only when it is possible AND beneficial. SHOULD have some heuristic and NOT use TDLS when its performance might be worse than going through the Wi-Fi access point. 7.4.3. Bluetooth Android Watch and Automotive implementations MUST support Bluetooth. Android Television Page 49 of 74
Page 1 and 2: Compatibility Definition Android 6.
Page 3 and 4: 6. Developer Tools and Options Comp
Page 5 and 6: 1. Introduction This document enume
Page 7 and 8: 3. Software 3.1. Managed API Compat
Page 9 and 10: ID MANUFACTURER MODEL PRODUCT SERIA
Page 11 and 12: MUST provide the user with per-app
Page 13 and 14: present, only the corresponding fun
Page 15 and 16: Android follows the package and cla
Page 17 and 18: 120 dpi (ldpi) 48MB 160 dpi (mdpi)
Page 19 and 20: applications to end users in some h
Page 21 and 22: Android includes support for Roboto
Page 23 and 24: device setup. An open source implem
Page 25 and 26: Format/Codec Encoder Decoder Detail
Page 27 and 28: H.265 HEVC REQUIRED 5 See section 5
Page 29 and 30: Video bitrate 600 Kbps 1.6 Mbps 4 M
Page 31 and 32: implementations that declare the fe
Page 33 and 34: connectivity over Bluetooth LE, SHO
Page 35 and 36: The units referenced by the require
Page 37 and 38: Device implementations MUST support
Page 39 and 40: MAY omit a non-touch navigation opt
Page 41 and 42: pointer device only) MUST NOT repor
Page 43 and 44: as appropriate when applications at
Page 45 and 46: atch mode at 10 Hz. 7.3.3. GPS Devi
Page 47: MUST have a measurement range betwe
Page 51 and 52: SHOULD be capable of reading the ba
Page 53 and 54: possibly dual-stack) on cellular da
Page 55 and 56: If an application has never called
Page 57 and 58: Device implementations MUST be conf
Page 59 and 60: Device implementations MAY omit a m
Page 61 and 62: Random read. Device implementations
Page 63 and 64: permissions used by the application
Page 65 and 66: already launched on an earlier Andr
Page 67 and 68: skipped or omitted. Every device an
Page 69 and 70: Sensor 7.4.2. IEEE 802.11 (Wi- Fi)
Page 71 and 72: 43. Unicode 6.1.0: http://www.unico
Page 73 and 74: 105. Android NFC Sharing Settings:

Compatibility Definition

Create successful ePaper yourself

Delete template?

Save as template?