Android 11 Developer Preview: All the new Privacy and Security features

Ahead of schedule, Google today released the first Developer Preview of the next version of the Android OS: Android 11. System images are available for the Pixel 2, Pixel 3, Pixel 3a, Pixel 4, but if you don’t own one of these devices, you can also try out the Developer Preview via the Android Studio emulator or the Generic System Image. Although Google is saving most of the exciting new user and developer features for a grand announcement at Google I/O 2020, the company has shared a plethora of changes that are available in the first Developer Preview. Here’s a summary of all the new privacy and security-related features that Google has announced in Android 11 Developer Preview 1.

Android 11 Developer Preview 1 – New Privacy Features

One-time Permission Access

Android controls what kinds of data apps can access through its permission system. Before Android 6.0 Marshmallow, apps requested to be granted permissions at installation, so users had to decide whether they were okay with an app having certain permissions before installing it. Android 6.0 Marshmallow introduced runtime permissions for a select set of sensitive permissions, including location access, microphone access, and camera access. Runtime permissions can only be granted after installation, and the app requesting them must prompt the user through a system-provided dialog to allow access. Finally, in Android 10, Google introduced a special version of the runtime permission which allows the user to grant access only while the app is in active use; however, Google only introduced the “while app is in use” option for the location permission.

In Android 11, Google is giving users more fine-grained control over other sensitive permissions, including camera and microphone access. The company has introduced a new “one-time permission” feature in the Android 11 Developer Preview that allows the user to temporarily grant an app access to a permission so long as that app is in the foreground. Once the user navigates away from the app, the app loses access to that permission and must request it again.

Scoped Storage changes

In Android 10 beta 2, Google proposed a radical change to the way that apps access the external storage on Android. (External storage, here, is defined as the data visible to the user and other apps located in /data/media.) The change, dubbed “Scoped Storage,” was aimed at eliminating the overly broad use of the READ_EXTERNAL_STORAGE permission. Too many apps on the Google Play Store were requesting and being granted access to the entire external storage where users were saving their private documents, photos, videos, and other files. With Scoped Storage, apps would, by default, only be granted the ability to see their private data directories. If an app holds the READ_EXTERNAL_STORAGE permission under Scoped Storage enforcement, then it can view certain media files accessible through the MediaStore API. Alternatively, the app can use the Storage Access Framework to have the user manually select files through the system file picker. Finally, apps that need broad access to the external storage, such as file managers, can use the Storage Access Framework to request the user to grant the app access to the root directory of the external storage, thereby granting access to all its subdirectories, too.

Enforcement of Scoped Storage was set to take effect for all apps in Android 10, but after feedback and criticism from developers, Google relaxed the changes, only requiring them for apps targeting API level 29 (Android 10). After August 1st, 2020, all new apps submitted to the Google Play Store must target Android 10, and the same is true for all updates to existing apps after November 1st, 2020. Furthermore, in Android 11, developers of file manager apps must submit a declaration form to Google to be allowed broad access to the external storage; once accepted, file manager apps will have an unfiltered view of MediaStore but will not have access to external app directories.

In addition, Google has introduced other changes to Scoped Storage in the Android 11 Developer Preview. Apps can opt-in to get the raw file path and perform batch edit operations for media files in the MediaStore. The DocumentsUI has been updated to be simpler for users. These changes were announced at the Android Dev Summit last year, and we’re promised additional enhancements to Scoped Storage in future Android 11 releases.

New Security Features

Mobile Driver License Support

Since early last year, Google has been working on the IdentityCredential API and HAL in AOSP. This feature lays the groundwork for securely storing identification documents on your mobile device, and in particular, ISO 18013-5 compliant mobile driving licenses. Google officially announced this feature at Google I/O 2019, and now it’s finally supported in Android 11 Developer Preview

Google didn’t have a lot to say about this feature in the press release, but because the feature is being developed in the open, we already know a lot of what’s planned. At I/O 2019, Google stated that they were working with the ISO to standardize an implementation of electronic passports; we still don’t have an inkling of when ePassports will be available, but there are already several U.S. states where eDLs are implemented or are in the trial phase. Google also said they are working to provide a Jetpack library so developers can create identity apps. We don’t know how soon developers will be able to test this feature, though, since proper support requires secure hardware on the device. The Secure Processing Unit on the Qualcomm Snapdragon 865 supports the IdentityCredential API, though it may not support the API’s Direct Access mode since the SPU is integrated into the SoC; Direct Access mode would allow the user to pull up a stored electronic ID even when there isn’t enough power to boot Android. For more information on this API, I recommend reading our initial coverage where Shawn Willden, the Android hardware-backed security team lead, provided his input.

New Project Mainline Modules

One of the biggest changes in Android 10 for newly launched devices was the introduction of Project Mainline, which despite its name, has nothing to do with supporting the mainline Linux kernel on Android. (That project, by the way, is called Generic Kernel Image and is still a work-in-progress.) Instead, the purpose of Project Mainline is for Google to wrest control of key framework components and system applications away from OEMs. Each Mainline module is encapsulated as either an APK or an APEX file and is updateable by Google through the Play Store. The user sees updates as a “Google Play System Update” (GPSU) on their device, and updates are released on a regular cadence as a train (ie. they’re downloaded and installed at the same time).

BiometricPrompt Changes

Android 9 Pie introduced the BiometricPrompt API, a unified API for biometric authentication hardware. The API provides developers a way to challenge the user through their saved biometrics, whether that be fingerprint, face, or iris. Before BiometricPrompt, developers had to create their own authentication dialog and use the FingerprintManager API, which only supported fingerprint authentication, to challenge the user. On Galaxy smartphones with iris scanners, developers had to use Samsung’s SDK to challenge the user. With BiometricPrompt, developers can challenge the user with any supported biometric method, and the system provides the dialog to the user. Thus, developers no longer need to worry about specifically providing support for a particular kind of biometric hardware, and they also no longer had to code the UI for the authentication dialog. The Pixel 4’s secure facial recognition hardware, for example, can be used for authentication in apps that use BiometricPrompt

Credit: Google

Thank you for reading.