Android 11 (R) : An Overview of the Developer Preview
A couple of weeks ago, Google announced a new version called Android 11. As you’ve probably noticed, starting with Android 10 Google abandoned its convention of naming Android versions after desserts, so the new version is simply Android 11, or Android R.
Along with the new release, Google introduces a new release milestone called Platform Stability. Upon reaching this milestone, the platform’s internal and external APIs are expected to be finalized, so developers can reliably test their applications, knowing that their app will continue to work after release.
Android R is expected to be released in the third quarter of this year, so there’s still a lot of time to get accustomed to what it brings to the table.
You may start using it right away! (At your own risk)
Developer Preview includes system images for Pixel devices which can also be used on Android emulators. Since it’s still in its early stages, Google doesn’t provide a way to automatically update to Android R, so you have to do it manually. As Google mentions it in the developer preview, these images are mostly meant for developers at the moment. Source code is also not released yet so if you want to start building your own images, you are out of luck.
If you want to build for Android R, all you need to do is target it in build.gradle:
android {
compileSdkVersion 'android-R'
defaultConfig {
targetSdkVersion 'R'
}
...
}Now that you know how to build your application for it, let’s take a look at some of the updates!
Scoped Storage Enforcement
Android 10 introduced something called scoped storage. In the older versions of android, you could simply grab READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE permissions and reign free in the external storage. Android 10 made it so you would only need these permissions if you’re trying to access other application files. With scoped storage, you could create anything under the external storage (no permission required), but cannot read or change anything that was not created by your application. Still, if you preferred the old way of doing things, you could specify requestLegacyExternalStorage application tag in your manifest file to keep the old behavior, until now!
With Android 11, requestLegacyExternalStorage is now removed, so you have no other choice but use scoped storage.
One Time Permissions
Following iOS 13’s Allow Once option, Android also introduces a way to grant permission for one time only.
From now on, people have the option to grant location, microphone and camera permissions to an application temporarily. This temporary permission will remain with the application while app’s activity is still visible. If the app has a foreground service running at the time of getting the temporary permission, it will keep it as long as that service is alive, even if the app moves to background (Does not apply to background services, so don’t worry about it).
You can also grant permissions separately to a WebView instance of the app. This way you can grant location services permanently to a WebView instance that display a map, and grant temporary permission to the rest of the application whenever it’s needed.
In order to improve user experience, Android will no longer display your permission request if user denies it twice, interpreting as don’t ask again. Permission may still be granted from settings, but none of your permission requests will be displayed.
Data Access Auditing
AppOpsManager now allows you to register to AppOpsCollector in order to monitor private data access by 3rd party libraries. AppOpsCollector tracks the API calls that access private data in order to do this. You may log this information or analyze it whenever AppOpsCollector’s callbacks are triggered. These heads-up callbacks may be triggered internally by your application or externally(broadcast listener callbacks).
Background Location Access
Google encourages developers to request a baseline permission first and then gradually improve it for more access. In order to enforce this, in-app dialog for requesting location permissions no longer have the allow all the time option.
In order to gain such permission, you must first request either ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION permission. Once one of them is granted, you may request the ACCESS_BACKGROUND_LOCATION permission in order to increase your application’s access level.
Securely Sharing Large Blobs of Data
For machine learning purposes, you can now securely share large datasets with other applications using BlobStoreManager System Service. This service allows you to create a secure blob to store your dataset and give various levels of access to other applications. Access levels include:
- Public Access — All apps may access your blob.
- Package-specific Access — Specify all application packages that are allowed to access your blob.
- Signature-level Access — Only applications that are signed using the same key as your app are allowed to access your blob.
Biometric Authentication Strength
You can now query biometric authentication strength to see if you can authenticate using the required level. BiometricManager now includes a method called callAuthenticate() that takes a bit field parameter for you to query the availability of required biometric authentication strength, such as BIOMETRIC_WEAK, BIOMETRIC_STRONG or BIOMETRIC_CREDENTIAL (Pin,pattern,etc.). callAuthenticate() returns a bit field value to indicate if the requested strength is available (Whether the HW is present for it or the user registered any sort of biometric information to be used).
ACTION_BIOMETRIC_ENROLL intent trigger system settings and requests the user to enroll biometrics. Required level can be provided as extra along with the intent.
App Process Exit Reasons
You may now get a detailed information about your process’s recent termination. getHistoricalProcessExitReasons() in ActivityManager now returns a list of ApplicationExitInfo records containing the recent application deaths. By using this new method, you will be able to determine the reason for termination, and examine stack traces if termination was due to a crash.
Other Improvements/Changes
There are a lot of small changes to various features/APIs in Android 11. A full list of API changes can be found here:
Some of the other improvements worth noting include:
- MediaStore API improvements for batch operations. Now that the external storage is restricted, you may request special access to a group of media files.
- Accessing files via raw paths. After getting the READ_EXTERNAL_STORAGE permission, you can read media files with direct paths.
MANAGE_EXTERNAL_STORAGEpermission. External storage access is changed, but by requesting this permission, you may gain broad access all external storage files (Excluding the app specific subdirectories under Android/data/).- Users can now insert images into quick reply notifications.
- MediaCodec now supports low-latency decoding for real-time applications. If you don’t want to use JNI to access the framework API, NDK also has the ImageDecoder API to be used directly by C/C++ applications.
- You may now use the new API classes ResourceLoader and ResourceProvider in order to provide a directory for loading resources, rather than using the resources bundled with your application. This way you may load custom assets and change them at will.
- Neural Networks API 1.3 is introduced. Extended TensorFlow Lite support, new operations and some optimization to existing APIs.
- Wi-Fi Passpoints may now have an enforced expiration date to avoid auto-connection with expired credentials.
- Bubbles are no longer an experimental feature. Performance is improved and some of the API is changed.
Wrap Up
We will keep getting frequent updates by Google related to the latest status of Android 11. Most of the things mentioned in this article are subject to change, so take it with a grain of salt. It’s a good idea to keep an eye on the following places:
