Android Marshmallow: What the Phones Are Going to Look Like
While some Android fans are looking forward to upgrading their existing Android smartphones to the latest version of the operating system, Android 6.0 Marshmallow, others are anticipating the release of new Android smartphones that will run the operating system out of the box. A document that Google has released to outline its requirements for manufacturers of Android smartphones and tablets gives us a glimpse of how phones for Android Marshmallow are going to handle some of the release’s most exciting new features.
Emil Protalinski reports for VentureBeat that Google has updated its Compatibility Definition document for Android 6.0 Marshmallow. The 74-page document (PDF), which is intended for smartphone and tablet makers looking to build new devices that run Android Marshmallow, outlines what those devices will need to look like to properly run the latest version of Google’s operating system. The highlights of the document reveal what you can expect of Android smartphones built for Android 6.0 Marshmallow.
Google first unveiled Android Marshmallow at its I/O developer conference in May. After releasing three developer previews of the operating system, Google then launched the Nexus 5X and Nexus 6P, impressive new smartphones that not only demonstrate the full capability of the new operating system, as Nexus phones traditionally do, but also illustrate a smoother, more secure version of Android that Google likely hopes will take hold throughout the sprawling Android ecosystem. The Compatibility Definition document outlines what hardware manufacturers need to do to make devices that run Android Marshmallow out of the box. Read on for the highlights.
Mandatory full-disk encryption
Google enabled full encryption by default on the Nexus 6 and Nexus 9, and with Android 5.0 Lollipop, started out by requiring it for other devices. However, Google backpedaled to “strongly recommend” encryption, and promised to change the recommendation to a requirement with a future version of the operating system. That future version turns out to be Android Marshmallow. The Compatibility Definition document explains:
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.
As Protalinski points out, the requirement seems relevant only to new devices, since almost no Android devices — aside from the Nexus 6 and the Nexus 9 — have launched with encryption by default. As David Ruddock reports for Android Police, Google won’t require users to set a lockscreen out of the box, and is asking that if the manufacturer allows the user to forego setting up a password, that the encryption is secured with a default passcode instead. If, or when, the user does decide to secure the phone with a lockscreen and passcode, there won’t be any need to re-encrypt the whole disk.
The new Nexus 5X and Nexus 6P have fingerprint sensors, and it’s likely that many other devices built for Android Marshmallow will adopt them too. Many manufacturers’ flagship phones already support fingerprint authentication, but until now, it’s been up to the manufacturers to implement it. With Android 6.0, the operating system handles the process. You’ll be able to use your fingerprint to unlock your device, authorize transactions in the Google Play store, sign in to third-party apps, or check out with Android Pay.
Protalinski notes that there are numerous requirements for device makers to follow, which ensures that fingerprint sensors will work with Android Marshmallow and any apps that use its APIs. If a device includes a fingerprint sensor and a corresponding API for third-party developers, then it must implement that API according to Google’s instructions in the Android SDK documentation. The fingerprint authentication must have a false acceptance rate of 0.002% or lower, and is recommended not to have a false rejection rate above 10%.
Google also recommends that the fingerprint sensor will unlock the screen less than a second after the fingerprint sensor is touched. Additionally, the fingerprint authentication system has to limit attempts for at least 30 seconds after five false trials. All fingerprint data needs to be encrypted and cryptographically authenticated, and the system needs to prevent the addition of a new fingerprint without first establishing a chain of trust, and can’t enable third-party apps to distinguish between individual fingerprints.
Ryan Whitwam reports for Android Police that any smartphones that are updated from an earlier version of Android to Marshmallow will also have to migrate fingerprint data to match Google’s new specifications, or will have to wipe the data from the device. There may be some devices that will require you to set up your fingerprints again after upgrading, though we won’t know for sure how many until smartphone makers get around to rolling out updates.
The final highlight that Protalinski notes will be significant for users is Google’s set of requirements for Android phones’ Doze mode. Doze limits the resources that your device uses when you leave it unattended, and enables it to automatically go into a deep sleep mode to conserve power. Protalinski explains that it won’t prevent your phone’s alarm clock from ringing if you forgot to plug it in before going to bed. A related feature, called App Standby, will put seldom-used apps into a reduced activity state to conserve battery power for the apps that you use more frequently.
The new Compatibility Definition document explains that Google isn’t letting smartphone bankers mess with either Doze mode or App Standby. The document warns, “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.”
Protalinski notes that it’s “great” that Google is taking steps to stop device makers from “screwing around with Marshmallow’s power management improvements,” but adds, “How app developers will try to circumvent them, however, remains to be seen.”