Google details Android 6.0 requirements: Disk encryption by default, fingerprint sensors, and Doze

Google has updated its Compatibility Definition document for Android 6.0, outlining for phone and tablet makers what they need to do to properly run the company’s latest and greatest operating system. There are at least three highlights worth pointing out: Android 6.0 requires that manufacturers enable full-disk encryption by default, Doze mode cannot be modified, and the exact requirements for fingerprint sensors are outlined.

Google unveiled Android Marshmallow at its I/O 2015 conference in May. After three developer previews, Google launched the Nexus 5X and the Nexus 6P, which are powered by the new OS out of the box. Now, the company has shared what companies need to keep in mind if they want to do the same.

[aditude-amp id="flyingcarpet" targeting='{"env":"staging","page_type":"article","post_id":1824655,"post_type":"story","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,dev,mobile,","session":"A"}']

First and foremost, full disk encryption is now mandatory. There is some important history here: Google not only enabled encryption by default on the Nexus 6 and Nexus 9, but with Android 5.0 Lollipop, even required it for other devices. The company then backpedaled and decided to “strongly recommend” encryption, though it promised to change that to a requirement in future versions of Android.

Apparently “future versions” means Android 6.0:

For device implementations supporting full-disk encryption and with Advanced Encryption Standard (AES) crypto performance above 50MiB/sec, the full-disk encryption MUST be enabled by default at the time the user has completed the out-of-box setup experience. If a device implementation is already launched on an earlier Android version with full-disk encryption disabled by default, such a device cannot meet the requirement through a system software update and thus MAY be exempted.

That second sentence means this is really just applicable to new devices, since, aside from the Nexus 6 and Nexus 9, almost no Android device launched with encryption by default. A lockscreen is still not required, but if a user decides to start using one, this change means it is now no longer necessary to re-encrypt the whole disk.

The new Nexus devices have fingerprint sensors, so you can expect that more and more Android devices will, as well. While many flagships already support fingerprint authentication, it was up to OEMs to implement the feature. As of Android 6.0, the operating system can handle it. You can use your fingerprint to unlock your device, authorize transactions in the Google Play store, sign into third-party apps, and check out with Android Pay.

The rules for implementing fingerprint sensors are as follows.

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.

Device makers have to follow these requirements to ensure fingerprint sensors work with Marshmallow and any apps that use its APIs. How exactly this will impact phones and tablets that upgrade to Android 6.0 remains to be seen, though it shouldn’t take more than re-scanning your fingerprint.

Last but not least, Doze mode is meant to limit the resources your device uses when left unattended: It automatically goes into a deep sleep state to conserve power. That said, even if you forget to plug in your phone before bed, your phone’s alarm clock will still ring (assuming your battery doesn’t completely run out). App Standby puts your seldom-used apps into a reduced activity state to conserve battery for the apps you use more frequently.

Google isn’t letting companies mess with either:

[aditude-amp id="medium1" targeting='{"env":"staging","page_type":"article","post_id":1824655,"post_type":"story","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,dev,mobile,","session":"A"}']

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.

It’s great that Google is stopping device makers from screwing around with Marshmallow’s power management improvements. How app developers will try to circumvent them, however, remains to be seen.

If that wasn’t enough for you, check out the full 74-page document right here: Compatibility Definition (PDF).