Google's Android Marshmallow OEM guidelines expand tools, but with a shorter leash

20.10.2015
With a fresh Android treat comes new tools and new rules for those that make Android-powered phones, tablets, and other gadgets. 

That’s because with each version of Android, Google updates its Compatibility Definition document. This tells hardware partners (OEMs) what they can and can’t do in order to make an Android device that earns the blessing of Google.

Without passing the requirements and getting the go from the Compatibility Test Site, the device won’t get Google Play services. That means no Google apps or Play Store access for you.

There are quite a number of new hardware capabilities and requirements with Marshmallow. In all, it shows that Google is trying to push ahead with an effort it made in Lollipop to provide a framework for more attractive devices, while dangling enough carrots to keep OEMs in line. Left to their own devices, too many Android manufacturers stray far from the vision of building a phone that taps into the power of Android. Or, they provide similar capabilities while trying to keep the technology proprietary to their own phones, making it hard for developers to support all devices throughout the Android ecosystem.

Here’s a brief rundown of the most important new rules for Android manufacturers, and what it might mean for your next Android device.

Google is requiring that OEMs put Doze Mode into place and let you know which apps are exempted from it. In stock Marshmallow you’ll only see Google Play Services and Android Device Manager as opted out. However, expect Samsung, LG, and others to exclude some of their preinstalled apps from this feature. The upside for you is that you should get significantly better battery life with your next phone. However, don’t be surprised if manufacturers mess with this by opting out carrier bloatware.

This one deserves a big, “finally.” Full-disk encryption and secure boot are now mandatory for Marshmallow devices. This was the plan with Lollipop, but it was pushed aside due to performance issues. This brings a much-needed level of security to your device, especially since you’re likely to sell it off in a year and get a new one. When you wipe it, your old data is encrypted and non-recoverable.

Devices that flag themselves as low-memory (less than 512MB) and don't have a secure lock screen can still opt out of this. Those requirements preclude basically all modern phones and tablets—it seems like an out for those making other Android-based devices (smart network players, robots, internet-of-things devices, and so on).

This is an area where Google is playing much-needed catch-up to Apple’s Touch ID. There’s a long list of requirements for those OEMs that want to include a fingerprint sensor. The devices must limit a user to five attempts and limit third-party access to merely authenticating prints, not identifying which particular prints are used. While Samsung and others have fingerprint sensors in its devices for a couple of generations, this enables the rest of Android OEMs to include this feature without developing their own custom software. And it builds a standard interface that app developers can use to authenticate you using your fingerprint. For example, a password manager might auto-fill forms after you authenticate with your fingerprint.

You can check out the lengthy list of requirements from Google here.

Android has struggled in the past with audio latency problems, ceding a huge advantage to Apple. Google attempts to fix this with more requirements for how devices perform when paired with speakers or other hardware, and how quickly the operating system and audio software stack and respond to and playback sounds from inputs. Google has added a professional audio package manager, which dictates the details for audio latency and support of USB audio connections. Devices that meet strict requirements can make themselves available for APIs that should bring far better audio performance to certain apps.

If you follow Android you know it’s incredibly fragmented and that the developer and user experience varies sharply. Google is trying to repair this without turning into an autocrat and banishing others from making Android devices. With Lollipop Google arguably tightened the screws, but perhaps not nearly enough.

If you want to find out all the specifics and understand the complex details surrounding hardware requirements, then check out the Android Compatibility Definition document. That will give you a full picture of what you can expect with Marshmallow, which should come with the next wave of Android devices.

(www.greenbot.com)

Derek Walter

Zur Startseite