Exclusive: 3 of Android 11’s best features won’t be available on every device

Every year, Google releases a new version of the Android operating system. Google released the first Android 11 Developer Preview back in February followed by the second, third, and fourth developer previews over the last few months. Earlier this month, Google unveiled the first Android 11 Beta and talked in-depth about the best features for users to enjoy and for developers to implement. However, we’ve now learned that three of the top features in Android 11 won’t be available on every Android device.

To understand how that’s possible, we have to briefly explain how the Android OS is distributed from Google to smartphone device makers. Android is an open-source operating system licensed under Apache 2.0, meaning that anyone, from indie developers to big companies, is free to modify and distribute the OS on their own devices. Most of the new OS features that Google unveiled for Android 11 will be part of the Android Open Source Project (AOSP) that smartphone device makers base their own software on, but the Apache 2.0 license, as I mentioned before, lets anyone modify the software as they see fit. In order to maintain consistency in APIs and platform behavior between Android devices, Google bundles the distribution of Google Mobile Services (which includes applications and frameworks like the Google Play Store and Google Play Services) with license agreements mandating that devices adhere to the rules under Google’s “Android Compatibility Program” (among other requirements). The Android Compatibility Program consists of multiple automated test suites and a set of rules enumerated in the Android Compatibility Definition Document (CDD).

In the CDD, Google lists software and hardware features that device makers “MUST” implement, are only “STRONGLY RECOMMENDED” to implement, or “SHOULD NOT” implement. If a feature is listed as “MUST” implement, then the device maker has to add that feature or they can’t ship Google apps on their devices. If a feature is listed as “SHOULD NOT” implement, then the device maker can’t add that feature or they can’t bundle Google apps. Finally, if a feature is listed as “STRONGLY RECOMMENDED,” then it’s up to the device maker whether or not they want to implement the feature. The CDD is a constantly changing document, even before its publication every year following the public release of a new Android version. Google frequently updates the document to remove features, change the language to be clearer, and relax requirements based on feedback from its partners. However, once Google makes a CDD public for a particular Android version, those requirements will be set in stone for Google-certified devices running that Android OS version.

The Android 11 CDD won’t become public until later this year, likely in early September. However, developer @deletescape shared a pre-release copy of a document that details changes coming to the CDD, giving us an early look at how Google is shaping Android 11 across the ecosystem. The vast majority of the over 60 changes to the CDD aren’t very interesting to users—they describe how device makers have to implement certain APIs, declare certain features, and implement certain kernel features. However, 3 of the changes to the CDD caught our attention because they relate to some of the most interesting features in Android 11. Here’s what we uncovered.

Device Controls

Device Controls is a feature in Android 11 that allows for smart home automation controls to be shown in the power menu. You can turn off your lights, open your garage door, start your vacuum cleaner, change your home’s temperature, and do much more without opening up a dozen different smart home apps. Google added APIs that developers of smart home apps can use to surface controls in the power menu. We think this is a neat feature that finally brings your smartphone into the smart home. Unfortunately, there’s no requirement for OEMs to actually implement it. If an OEM thinks the feature is lame or they want to go a different route (such as only allowing smart home controls from devices in their own ecosystem), then they can simply disable support for Device Controls.

When Google first added Device Controls to the CDD on February 25th, 2020, they mandated its inclusion by adding a “MUST” requirement in Section 2.2.3 – Handheld Software Requirements. However, on May 20th, 2020, Google updated the text to remove the proposed “MUST”. The new Section 3.8.16 – Device Controls outlines how the feature has to be implemented but does not actually require that it be implemented in the first place! We hope OEMs won’t disable this nifty feature, but there’s no way for us to know if they have disabled it until they’re ready to unveil their own flavors of Android built on top of Android 11, which won’t happen until several months from now.

Conversations in Notifications

One of Android’s biggest advantages compared to iOS is how the former handles notifications. That gap in usability will get even wider in Android 11 with the introduction of “Conversations.” In Android 11, notifications from messaging apps are grouped together and are shown in a separate section in the notification panel above most other notifications. This lets you quickly see and respond to messages without having to scroll through all your other pending notifications. Unfortunately, this nifty change to notifications may not be available on all devices. Google is giving OEMs the option to choose whether they want to “group and display conversation notifications ahead of non-conversation notifications.” OEMs frequently customize the notification panel, and so it’s no surprise that Google is giving OEMs a choice here. Still, it’s unfortunate that Google isn’t choosing to enforce more consistency in notifications in Android 11.

IdentityCredential – Mobile Driver’s Licenses

Finally, one of the features that I’m most excited about is the IdentityCredential API. As we detailed last year, the IdentityCredential API is designed to allow applications to store identity documents, such as mobile driver’s licenses, on the device. Several countries (and some U.S. States) around the world already allow their citizens to store their driver’s licenses in a mobile app. However, Google is working to make this more secure by having the data stored offline in a secure environment.

The source code for Android 11 includes the IdentityCredential API (which developers will call to store identity documents in the phone’s secure environment) and the IdentityCredential HAL (which interfaces with the phone’s secure environment), but OEMs are not required to implement them. When Google first proposed the inclusion of IdentityCredential in the CDD on January 10, 2020, they listed it as a requirement. However, they relaxed this requirement on March 18, 2020, and now only strongly recommend that OEMs support this feature. We’re not surprised that Google relaxed this requirement—adding a change that impacts the trusted execution environment will require effort from OEMs to implement. It’s possible that OEMs simply need more time to get ready for this change. For users, though, that means there’s no guarantee your particular Android 11 smartphone will support securely storing a mobile driver’s license in the phone’s secure environment.

We should note that there’s no technical limitation preventing the widespread adoption of the IdentityCredential system among Android 11 devices. One of the requirements for implementing the IdentityCredential system is that the device has a Trusted Execution Environment (TEE) or a dedicated secure processor in which a “trusted application” interacts with the stored identity documents. Since Android 7.0 Nougat, Google has required all modern Android devices to support an “isolated execution environment” (per Section 2.2.5 – Security Model in the CDD). Devices with ARM processors typically feature ARM’s TrustZone TEE, and Google provides the Trusty OS that runs on TrustZone. The presence of a TEE is enough to support the IdentityCredential system, though it would be more secure if the credentials are stored in an embedded secure CPU (such as in the Secure Processing Unit of some Qualcomm Snapdragon processors) or a discrete secure CPU (such as in Google’s Titan M or Samsung’s new security chips). Notably, devices with discrete secure CPUs may also be able to support the “Direct Access mode” feature of the IdentityCredential system, which will allow the user to pull up their identity document even when there isn’t enough power left in the device to boot up the main OS.

Google is also working on an IdentityCredential Jetpack library to make it easier for developers to add support for securely storing identity documents on Android, but the real challenge will be getting governments to authorize apps using this API to securely store government IDs. According to Engadget, South Korea just rolled out support for storing driver licenses in a mobile app, so we’re starting to see an uptick in acceptance for this technology. I, for one, am excited to see where this goes because it’ll mean one less thing to carry with me when I go outside.

Copyright © 2020 Blogstore.net