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.
Proposed Section 3.8.16 (New) - Device Controls (Updated 5/20/2020)
3.8.16 Device Controls
Android includes ControlsProviderService and Control APIs to allow developers to publish device controls for quick status and action for users.
3.8.16.1 Device Controls User Affordance
If devices implement Device Controls, then they:
- [C-1-1] MUST report the android.software.controls.feature flag to be TRUE
- [C-1-2] MUST provide a user affordance with the ability to add, edit, select and operate the user’s favorites from the controls registered by the 3rd-party apps through the android.service.controls.ControlsProviderService and the android.service.controls.Control APIs.
- [C-1-3] MUST provide access to this user affordance within three interactions from the Launcher
- [C-1-4] MUST accurately render in this user affordance the name and icon of each 3rd-party app that provides controls via the android.service.controls.ControlsProviderService API as well as any specified icon, status text , device type, name, structure, zone, custom color, and subtitle provided by the android.service.controls.Control API
Conversely, If device implementations do not implement such controls, then they
- [C-2-1] MUST report Null for the ControlsProviderService and the Control APIs.
Conversations in Notifications
Conversations in Android 11. Source: Google
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.
Proposed changes to Section 3.8.3.1 - Presentation of Notifications (Updated 4/08/2020)
If device implementations allow third party apps to notify users of notable events, they:
…
Android R introduces support for conversation notification, which is a notification that uses NotificationManager.MessageStyle and provides a published People Shortcut ID.
Device implementations are:
- [H-SR] STRONGLY RECOMMENDED to group and display conversation notifications ahead of non conversation notifications with the exception of ongoing foreground service notifications and importance:high notifications.
If conversation notifications are grouped into a separate section, device implementations
- [H-1-8] MUST display conversation notifications ahead of non conversation notifications with the exception of ongoing foreground service notifications and importance:high notifications.
Device implementations are:
- [H-SR] STRONGLY RECOMMENDED to provide access to the following actions from conversation notifications: display this conversation as a bubble if the app provides the required data for bubbles
The AOSP implementation meets these requirements with the default System UI, Settings, and Launcher.
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.
A sample image of a digital driver’s license accessed through the LA Wallet app. Source: Envoc
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.
Proposed Section 9.11.3 (New) - Identity Credential (Updated 3/18/2020)
The Identity Credential System allows app developers to store and retrieve user identity documents.
Device implementations:
- [C-SR] are STRONGLY RECOMMENDED to implement the Identity Credential System.
If device implementations implement the Identity Credential System they:
- [C-0-1] MUST return non-null for the IdentityCredentialStore#getInstance() method.
- [C-0-2] MUST implement the `android.security.identity.*` APIs with code communicating with a trusted application running in either a Trusted Execution Environment (TEE) or on a dedicated secure processor. The trusted application must be implemented such that the Trusted Computing Base for the Identity Credential System does not include the Android Operating System.
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.
The document that we obtained listed changes to the CDD by the date those changes were made. The latest changes were made on June 10, 2020, which means that the document that we have is fairly up-to-date. It’s possible that Google could renege on these changes and make them all requirements again before the public release of Android 11, but we doubt Google will all of a sudden make the CDD more stringent. These changes were likely relaxed due to feedback from OEMs who are the ones that will have to go back and implement these features if they weren’t already planned on doing so. That takes time, effort, and money, which would just delay the release of Android 11 for non-Google devices even further. Still, if Google does make these features required once more, we’ll post an update on the XDA Portal.
The post Exclusive: 3 of Android 11’s best features won’t be available on every device appeared first on xda-developers.
from xda-developers https://ift.tt/3dAOJ2U
via IFTTT
