What You Need to Know to Get Your Apps Ready for Android 11
An Android 11 checklist for developers
Android 11 is currently in beta with a public release planned for the third quarter of 2020.
From a native screen recorder with the ability to enable device audio-recording to scheduled dark modes and viewing message notifications as bubbles, a lot of exciting new changes are set to roll out with Android R this year.
Privacy has been the primary focus for the next Android update, which means the work for developers has been cut out.
In the following sections, I’ll take you through a checklist to refer to when shipping your next app for Android 11.
Permissions Now Have ‘Only this time’ Option
Android 11 bumps up its permission model by including one-time permissions to give users more granular control over their location, camera, microphone, and other system permissions access.
This means if the user kills the app and re-opens it, the permission dialog will be prompted again before accessing the relevant system controls.
It’s worth noting that if the user puts your app in the background, the permission will still be intact while the activity or service is running.
This makes handling system resources access all the more crucial as it can be terminated anytime.
System Will Now Auto-Revoke Permission for Unused Apps and Hide Dialog on Repeated ‘Deny’
Android 11 system now has a lot more emphasis on data and privacy. A user who’s not used a particular app for months might not be aware of the permissions it had been granted in the past.
Hence, to make the user more conscious and in control of their resources, the system will automatically reset all permissions for unused apps.
In doing so, developers could hit a roadblock with background services that require those permissions for tasks such as syncing data or fetching location.
Luckily, you can inform users to disable auto-revoke of permissions from the settings. All you need to do is launch an intent to the app’s setting page using
Also, invoke the
isAutoRevokeWhitelisted() method to determine the status of your app’s permissions.
Another important change in the runtime permissions flow with Android 11 is the introduction of implicit “don’t ask again.” Up until Android 10, the developer could keep prompting the permission request every time the user pressed Deny. Now, if the user repeatedly taps Deny consecutive times for a specific permission, the action implies “don’t ask again.”
A Separate Background Location Permission
The third big change you need to address in Android 11 is the handling of background location permissions.
We know that Android 10 required defining a new permission
ACCESS_BACKGROUND_LOCATION in the manifest to request background locations.
Android 11 now brings a new flow wherein the developers are required to be more descriptive about the usage of background location. This means that the permission request dialog which is called using
ACCESS_COARSE_LOCATION will only allow location access while using the app.
For a background location request, you’ll have to call the
requestPermission method separately with the
ACCESS_BACKGROUND_LOCATION. This will take the user to the app’s settings page wherein they can allow it. The settings page now shows a new option, “Allow all the time,” for full location access if the user chooses to grant it.
It’s important to note that calling foreground and background location requests together or calling
ACCESS_BACKGROUND_LOCATION before the foreground request will be ignored by the system.
Package Visibility Restrictions
Android 11 bumps up privacy by forcing developers to specify the applications they wish to explicitly interact with.
To do this, you need to specify the
<package> names of those applications inside the new
<queries> element in your manifest file. But you can also specify
<intent> category to allow access to a set of applications.
So in order to access all applications on the device, you’ll need to specify the following in your manifest file.
queryIntentActivities() in Android 11 will only return those applications which are defined in the
In cases where your app falls under a browser, launcher, or security app, you may want to access all applications on the installed device instead of manually adding queries and updating your app each time. In such cases, there’s a new permission,
android.permission.QUERY_ALL_PACKAGES, that you’ll need to specify.
Do note that in case you’re using implicit intents to interact with other apps, the above package visibility restrictions in Android 11 won’t impact your application.
Improved Scoped Storage Implementation
Before scoped storages were introduced in Android 10, developers could read sensitive data in the system storage and also write files anywhere, leading to storage clutter, as files would remain even after app uninstalls.
Scoped storage was introduced in a bid to prevent developers from abusing full storage access. It ensures that each app has its own designated directory.
But at the time of launch, scoped storage required you to use the Storage Access Framework for accessing files beyond your app’s directory. Essentially, the
java.io.File API no longer worked. This led to a backlash by the developer community. Things like batch deletions of files became cumbersome — users had to manually give confirmation for access to each file(s) in their system.
But happily, in Android 10, scoped storage implementation was made optional. You can specify
android:requestLegacyExternalStorage=true in the manifest to opt out of it.
But starting with Android 11, using scoped storage is now mandatory.
So Android has made it more convenient by bringing back the
java.io.File API to allow easy access to direct file paths.
Also, Android 11 brings new media store APIs for batch processing:
createFavoriteRequest(). To learn more about these, refer to “Storage updates in Android 11.”
The trash request brings a new hidden trash mechanism that keeps deleted files in your system for a defined period before completely deleting them.
Apps that require full fill access (like third-party installers) need to specify the new
MANAGE_EXTERNAL_STORAGE permission in the
New Conversation Notifications
Notifications are an indispensable part of every application today. Android 11 now brings a dedicated section for chat message notifications.
If your application contains a chat functionality, you need to ensure that the respective notification is set to
MessagingStyle for displaying it in the conversation space.
Also, to ensure that conversation notification can be presented as bubbles, you need to set an associated
shortcutId for that notification.
Conversation notification also provides quick functions such as snooze, automated replies, and prioritizing a specific chat.
Bye-Bye Toasts on the Home Screen and API Changes
Toasts have been around for a long while. Despite the emergence of Snackbar, toasts are heavily used and abused. For instance, since toasts needn’t be bound to an activity, developers could show them even when the app is in the background.
Android 11 has completely blocked the ability to display custom toasts when sent from the background.
Also, text toasts no longer support
setView. Doing a
getView() on them will return null.
We can no longer set margins and gravity on the text toasts.
One important addition to the Toasts API in Android 11 is the new
addCallback() method to listen to toast appearance and disappearance.
Android 11 is privacy-focused and though package visibility restrictions won’t really prevent apps from not interacting, much of the remaining features are towards improving the security of your Android applications.
I hope you have a smooth migration to Android 11.
That’s it for this one. Thanks for reading.