Google outlines Android OEM requirements for full-disk encryption, fingerprint sensors, doze mode, more

Google has updated the Android Compatibility Definition document, and as is the case with every other major release of Android, this means that there are new requirements that manufacturers must follow if they want their phones to pass Google’s Compatibility Test Suite. Among the most obvious changes spotted today are a new mandate that full-disk encryption be enabled by default, as well as requirements for Marshmallow’s new doze mode and fingerprint sensors…

Before we get into this, it’s worth explaining the different levels of recommendation when it comes to the Android Compatibility Definition. Use of the word MAY seems to be a light suggestion from Google, SHOULD is a stronger level of recommendation, and MUST is the highest. If a device doesn’t comply with how any given feature MUST behave, it’s not technically “compatible” with Android Marshmallow. Conversely, there are things that the document deems MUST NOT.

Full-disc encryption

First up is full-disk encryption, something that only Nexus devices (for the most part) have had enabled by default up to this point. With Android Lollipop, Google said that while this requirement is stated as SHOULD for that version of the platform, it was “very strongly recommended” as the company expected this to change to MUST soon. It appears that Android Marshmallow is the version that finally requires full-disk encryption to be enabled by default:

For device implementations supporting full-disk encryption and with Advanced Encryption Standard (AES) crypto performance above 50MiB/sec, the full-disk encryption MUST be enabled by default at the time the user has completed the out-of-box setup experience.

Doze mode

Next up is Doze mode, a feature of the Android Open Source Project that hopes to conserve standby battery life. Thankfully, Google is requiring that manufacturers leave this functionality in place and visually present a list of apps that they include that are exempt from power-saving modes. If you head into the Settings app in stock, you’ll find that Android Device Manager and Google Play Services are the only exemptions, but you’ll definitely notice more of these apps on a device coming from Samsung, LG, or Huawei. Here’s the full verbiage:

8.3.Power-Saving Modes

All apps exempted from App Standby and/or Doze mode MUST be made visible to the end user. Further, the triggering, maintenance, wakeup algorithms and the use of Global system settings of these power-saving modes MUST not deviate from the Android Open Source Project.

Fingerprint sensor

Google is setting a laundry list of requirements for manufacturers that intend to incorporate a fingerprint sensor. In fact, Google says that devices with a secure lock screen option SHOULD include fingerprint sensor hardware, and MUST comply with many guidelines. The technology MUST have a false acceptance rate not higher than 0.002%, MUST rate limit attempts after 5 false attempts, MUST NOT enable 3rd-party apps to differentiate between prints, and more.

Here’s the full list:

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.

Professional Audio

As you may know, Apple’s laptops have long been favored by musicians for many reasons, one of them being much less trouble with inconsistent audio latency problems. Android is also one of those platforms that has had trouble with latency in previous versions, but that was much improved with Android Lollipop. Now, Google has even more requirements for Android Marshmallow.

5.10. Professional Audio

If a device implementation meets all of the following requirements, it is STRONGLY RECOMMENDED to report support for feature android.hardware.audio.pro via theandroid.content.pm.PackageManager class [Resources, 70].

• The device implementation MUST report support for featureandroid.hardware.audio.low_latency.
• 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.
• 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.
• The device implementation MUST include a USB port(s) supporting USB host mode and USB peripheral mode.
• The USB host mode MUST implement the USB audio class.
• 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.
• The device implementation MUST report support for featureandroid.software.midi.
• If the device includes a 4 conductor 3.5mm audio jack, the device implementation is STRONGLY RECOMMENDED to comply with section Mobile device (jack) specifications of the Wired Audio Headset Specification (v1.1).

Google also outlined requirements for runtime permissions:

9.1 Permissions

Permissions with a protection level of dangerous are runtime permissions. Applications with targetSdkVersion > 22 request them at runtime. Device implementations:

• 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.
• MUST have one and only one implementation of both user interfaces.
• MUST NOT grant any runtime permissions to preinstalled apps unless: the user’s consent can be obtained before the application uses it or the runtime permissions are associated with an intent pattern for which the preinstalled application is set as the default handler.

If you want to read more, head over and read the incredibly boring Android Compatibility Definition document.

(via Android Police 1, 2, 3, 4)