Android 11 Features – What developers need to know about the new APIs
Android 11 is here, and with it, a whole bunch of changes from Android 10. And those changes mean that developers are going to need to update their apps to take advantage of everything Android 11 has to offer (and everything it restricts).
This article goes over the more important API and feature changes and additions in Android 11. We have a separate article on the more user-focused features that you can also check out. Now, let’s get started!
One of the bigger features introduced in Android 11 is known as Device Controls. Device Controls’ intended purpose is to make controlling your smart devices easier. Open the power menu, and you’ll be able to see and quickly interact with any connected smart devices you have. This isn’t a closed feature, either. Any developer can make their own widgets for Device Controls.
Currently, there are 5 different widget types available: Toggle, which is a simple status indicator with on/off functionality; Range, which can be used to adjust some value between 0-100%; Toggle with Slider, which combines the functionality of Toggle and Range; Stateless, which is a simple button with no status indicators; and Temperature Panel, which allows you to view and control the temperature settings of a thermostat.
While it’s clear that these widgets are meant to be used to things like lights and window blinds, there’s certainly a potential to “abuse” them for more functionality. If you want to get started developing your own Device Controls widget, check out Google’s docs. If you want to learn more about why Device Controls might be useful, check out our editorial.
Controlling media in Android 11 is pretty interesting. Instead of the standard playback notification, you can have your media controls show up in the quick settings panel. This part of the panel will also show up to 5 total media “sessions,” allowing the user to swipe through and easily resume playback from other apps and devices. It seems that there can even be multiple sessions from a single app.
At long last, Android has built-in screen recording. In Android 11, recording your screen is as simple as adding a quick settings tile and tapping it. Before you start recording, you can choose whether you want to record audio from the microphone and if you want to show touches on-screen.
This has some implications for developers, though. There are an absolute ton of screen recording apps on the market. While Android 11 doesn’t break their functionality, it does mean that third-party screen recorders will need to provide some compelling features if they want to be used instead of what’s built into Android.
One-Time & Auto-Revoking Permissions
Google has been concentrating a lot on user privacy features in Android lately, and they haven’t stopped with Android 11. This release has two very important changes to the runtime (or “dangerous”) permissions model.
In previous versions of Android, if your app needed a dangerous-level permission, it would request access from the user, and that was pretty much it. Your app would keep that permission until it was uninstalled, its data was cleared, or the user manually revoked it.
Android 11, however, no longer has this guarantee. Now, when a user is prompted to grant a permission, they’ll have the option to grant it “only this time.” The permission will be granted to the app only as long as it’s in the foreground. Here’s how Google describes its behavior:
“While your app’s activity is visible, your app can access the data.
If the user brings your app to the background, your app can continue to access the data for a short period of time.
If you launch a foreground service while the activity is visible, and the user then moves your app to the background, your app can continue to access the data until that foreground service stops.
If the user revokes the one-time permission, such as in system settings, your app cannot access the data, regardless of whether you launched a foreground service. As with any permission, if the user revokes your app’s one-time permission, your app’s process terminates.”
Obviously, there are some pretty major implications for developers here. Since a permission revocation acts like a force-stop, it can cause things like alarms and jobs to fail. According to the Commonsware blog, that “short period of time” your app can work in the background is only about a minute. So if your app has something that relies on precise wakeups, you’re going to need to recommend that the user not use the one-time permission option for your app.
One-time permissions aren’t the only thing added in Android 11, though. If Android detects that you haven’t used an app for a while, it’ll automatically revoke all granted permissions. This is a nice privacy feature in theory, but again, it has some serious implications, especially for apps whose primary purpose is to run and collect data in the background (like battery trackers).
Messaging App Notifications
Android 11 is apparently very “people-focused.” While that’s a bit of a vague term, at least part of it involves a better messaging experience, with properly-marked message notifications appearing in their own category at the top of the notification center. It also means supporting Android’s Bubbles feature, which is similar to Facebook Messenger’s Chat Heads.
If you’re interested in implementing the new “people-focused” messaging features in your app, head on over to Google’s documentation.
File Managers and Scoped Storage
Scoped Storage is a mess. There, I said it. As a feature, it’s confusing enough for developers, and Google is only making things worse with its weird semi-rollouts and policies.
Previously, in Android 10, developers had the ability to opt-out of using Scoped Storage with the
requestLegacyExternalStorage flag. This is still possible in Android 11 if your app is still targeting Android 10. But as soon as you target Android 11, this flag is ignored.
If you’re working on migrating your data model to support Scoped Storage, you can use the
preserveLegacyExternalStorage flag. This will allow your app to continue accessing external storage as long as the user upgraded to the version containing this flag. If the user clears the app’s data, reinstalls, or is a new user, this flag won’t have any effect.
Google does at least partially recognize the importance of full user-space filesystem access, though. There is a new permission (MANAGE_EXTERNAL_STORAGE) to allow you to have mostly-full access again. However, this permission is not allowed in apps published to the Play Store until sometime in 2021. If you have a file manager or antivirus app on the Play Store, you’ll need to hold off on targeting API 30 for now.
These aren’t the only changes to Scoped Storage, though. The
obb directories under
/sdcard/Android/ are no longer accessible under any circumstances, even with the MANAGE_EXTERNAL_STORAGE permission. You also aren’t able to use ACTION_OPEN_DOCUMENT_TREE to target the root of any “reliable” storage or the Download folder anymore. What constitutes as “reliable” storage is up to the manufacturer of the device, but it’s safe to say internal and adopted storage probably both count.
If your app needs access to location data in the background, the process is now more involved. Android 10 added the ability to only allow an app access to location data when it’s in the foreground or to allow it all the time. Android 11 further separates these options.
Now, instead of a user choosing one or the other, they have to first allow access to location while using the app, and then go to Settings to allow background access. If your app targets Android 11 (API 30), and you need access to location data in the background, you’ll need to update your permission flow to keep this into account. Take a look at Google’s documentation for instructions on implementing this.
As authentication methods like fingerprint readers and face recognition become more widespread, it’s important to be able to specify what forms of authentication you want to allow. A new API in Android 11 will let you specify the “strength” of the biometric authentication you want to allow.
Identity Credential API
With our payment methods going virtual through apps like Google Pay and Samsung Pay, it’s only natural that there would be a push to make various forms of identity virtual, as well. Android 11 is working on functionality to properly support virtual identities. The native API is there in Android 11, but Google is also working on a Jetpack library for Android versions as far back as Android 7.0 Nougat.
“Yay! 5G!” – said no one ever.
Android 11 has some new APIs to help app developers learn more about the current 5G network that the device is connected to. You can do things like check the type of 5G (5Ge, 5G sub6, 5G mmW), check if it’s metered, and even get a value for the estimated bandwidth of the connection. On top of that, if you don’t have a 5G-capable device (or 5G service in your area), the Android emulator is getting support for virtual 5G, so you’ll be able to properly test how your app responds to the different network modes.
Display Cutout APIs
Notches, holes, screen curves, whatever. Android devices have a lot of obstructions in their screens these days. Whether or not those obstructions look good is up to you.
Working around cutouts from a developer perspective can be a bit of a nightmare, though. While Android has had display cutout APIs for a while now, they’re not complete. Android 11 is working to fix this issue by adding more flexibility to the cutout APIs, along with support for working around curved or “waterfall” displays.
Hinge Fold API
Foldable phones have been getting pretty popular lately. With the large manufacturers like Samsung and Huawei and even smaller ones like Motorola releasing quite a few different spins on the foldable design, they’re only going to get more popular.
Android 11 is ready for this with a new API that lets apps detect when a device is folding. You can check it out here. The Android emulator in Android Studio is also getting a “hardware” upgrade to support hinges.
Spam calls are a pretty big problem right now. And with things like number spoofing, it’s gotten pretty difficult to tell whether an incoming call is real or spam. In the US and other regions, carriers have implemented the STIR/SHAKEN standards in an attempt to authenticate caller ID and prevent number spoofing. However, not every carrier will actually block calls that fail to validate, so you might still receive some unwanted calls.
Android 11 has a new API to allow apps to check the STIR/SHAKEN status of incoming calls. This means that third-party (and first-party) call-blockers can better filter calls without having to resort to unstable hacks. You can learn more about this here.
Privacy isn’t the only focus of Android 11, though. Google has been working on general performance improvements, too. Android has an interesting system of communication between processes that allows third-party apps to interact with the system server, using AIDLs/Binders. The separation this system provides is great for security, but there’s a significant trade-off in terms of performance. Calls between processes can take a lot longer than a similar call within the same process.
To help combat this, Android 11 will cache the return values of certain Binder calls to improve performance for apps that use them. Google says it’s currently focusing on highly-used and relatively-static APIs.
One of the more janky parts of Android is how apps deal with appearing and disappearing input methods and system bars. While some manufacturers may implement custom animations in their skins or apps, transitions aren’t universal.
Unfortunately, Android 11 doesn’t quite fix the problem, but it at least provides the tools to help developers do it themselves. There’s a new API added that lets you listen and respond to changes in the window insets for your app. With the right window configuration, this will let you detect when the keyboard or system bars are showing or hiding, and resize your app’s layout accordingly.
If you’re interested in putting this into your own app, check out this Medium article.
Animated HEIF Support
GIFs are terrible. Sure, they let you share animations, but they’re huge. For people with slow internet and/or data caps, loading GIFs just isn’t feasible. In some cases, it’s possible to use the more-efficient WebM format, but Android 11 now also has native support for animated HEIFs.
NDK Image Decoder
If you develop parts of your Android app in C++ using NDK, you may have noticed the lack of a framework-side image decoder and encoder. Including C libraries can be costly in terms of app size, especially if you’re building for multiple architectures.
Well, Android 11 adds an image decoding and encoding API to the framework. Obviously, this isn’t very helpful right now, but over the next few years, it’ll definitely help make some apps smaller and easier to maintain.
Low-Latency Video Decoding
Low-latency video is a pretty important feature for things like streaming video, especially with the upcoming launch of cloud gaming platforms like NVIDIA’s GeForce NOW, Google’s Stadia, and Microsoft’s xCloud. Android 11’s MediaCodec API now has full support for encoding and decoding low-latency video streams.
Variable Refresh Rate
With high-refresh-rate displays becoming more and more ubiquitous, functionality across devices with the hardware is becoming more and more fragmented. To combat this, Android 11 introduces an option to set the preferred frame rate of your app. So if you need the display to run at a specified refresh rate (e.g 24Hz for a film movie), this API can help.
Check out the details at Google’s documentation site.
Possibly one of the most exciting additions to Android 11 is the ability to dynamically load and modify resources. Previously, this wasn’t possible. If you wanted to “change” a resource, you’d have to either have pre-defined values in XML or avoid using XML resources altogether and rely on code.
App Exit Reasons
It’s always frustrating when your app crashes on a device you don’t control, since it makes it harder to find out why. You can implement libraries like Crashlytics to get more details on what happened, but these don’t capture everything.
Android 11 adds the ActivityManager.getHistoricalProcessExitReasons() API, which allows you to query if and why your app may have force-quit. Reasons include ANRs, crashes, native crashes, and quite a bit more.
If you’re developing a large app, you probably know how tedious it can be to try to install it through ADB. It might fail halfway through, and even if it doesn’t, there’s a lot of wasted time just waiting for the APK to transfer.
Android 11 is here to save the day, with ADB Incremental. This feature installs enough of the app to allow it to run while streaming the extra data in the background. The threshold for this feature is currently 2GB, and it requires that your app be signed with the APK Signature Scheme v4. It also requires the target device supports the Incremental File System, which is currently only supported on the Pixel 4 but is a launch requirement for Android 11.
More Nullability Annotations
Kotlin has become one of the more popular languages for developing Android apps. Thanks to some handy syntax features, like built-in null-protection, it’s become the favorite of quite a few developers (including me).
Because of this rise in popularity, Google has been working on the Android framework to make it more Kotlin-friendly. This mostly comes in the form of adding explicit nullability annotations to methods and variables. While Kotlin can handle ambiguous method returns from Java, it does so at the cost of explicit null-protection.
Android 11 adds even more nullability annotations to the framework, making it even easier to use Kotlin to develop Android apps.
Because of all the new privacy restrictions in Android 11, it may be difficult to see how they affect your app, without targeting API 30 and hoping for the best.
To help make debugging and updating easier, Android 11 has a feature that allows you to manually toggle the new restrictions, even if your app isn’t targeting API 30. You can enable them individually for more granular testing or all at once to see if anything breaks.
Check out Google’s documentation for more details.
Data Access Auditing
On a similar note to the compatibility tools, Android 11 also adds the ability to audit what data your app is accessing. You can use this to make sure you won’t run into issues with the new Scoped Storage restrictions on Android 11.
For the implementation and usage instructions, visit Google’s documentation.
APK Sideloading Permissions
Thanks to the new Scoped Storage model being further enforced on Android 11, sideloading APKs has gotten a little more difficult, at least on the developer end.
In earlier developer previews of Android 11, granting permission to an app to sideload APKs would immediately force-quit it. This is a confusing experience for both users and developers, as users get thrown out of the app they were using and developers have to handle their app being force-stopped.
While the full release of Android 11 hasn’t fully solved this issue, it’s at least made it manageable. Now, instead of quitting the entire app, granting the permission merely causes the current Activity to restart. If your app installs APKs from an Activity with nested Fragments or some other form of navigation, make sure you properly save the state of it in anticipation of a potential recreation.
Listing Installed Packages
Another privacy feature in Android 11 is its restrictions on retrieving the list of installed apps. In previous versions of Android, using the
PackageManager.getInstalledPackages() method would list all matching applications on the device.
In Android 11, however, this method will only return your app and a list of preinstalled applications. The supposed reasoning for this is to avoid apps being able to fingerprint your device by checking what other apps you have installed. However, it’s pretty easy to work around this restriction, at least partially. If your app needs to see user-installed packages, you can use the
<queries> manifest element to say what types of apps you want to see. This doesn’t require any user interaction; you’ll be automatically granted the ability to see apps matching your queries.
Check out this Commonsware blog post for more details.
Quick Access Wallet
Partially introduced in Android 10, this feature allows developers to have payment methods show up right in the power menu. In Android 10, the feature was disabled by default and only worked on Pixel devices with Google Pay. Android 11, however, adds a proper API to access it.
To see more about how it works, check out our previous article on Quick Access Wallet.
Third-Party Camera App Restrictions
A big advantage of Android is the ability to specify which app you want to use for a certain service. Unfortunately, this has gotten harder, at least for the camera app.
In general, with Android 11, third-party camera apps will no longer show up in the camera picker when an app requests a photo to be taken. For the full details and reasoning, check out our previous article on this.
Auto Low-Latency Mode
Android 11-based TVs and TV boxes now allow apps to request that the TV disable all post-processing on the displayed image, to allow for lower latency. Take a look at our article on the new Android TV features to learn more.
Block Store Library
Android 11 adds the ability for developers to have users’ app credentials backed up to Google Drive for easier sign-in on new devices. While this feature is optional, it should make migrating to a new device easier for apps that implement it.
Gallery Recycle Bin
While a bunch of manufacturers have added a Trash or Recycle Bin feature to their own gallery apps, it’s a feature that’s been missing from Android itself. Android 11 adds a new API to MediaStore to allow “trashing” photos and videos instead of outright deleting them.
No More Overscan
Overscan was a feature in Android that allowed, well, overscan. While it was mainly meant for TVs, the APIs were present in mobile Android as well and were particularly useful for things like third-party navigation gestures apps. Unfortunately, Google has entirely removed overscan from Android 11.
If you use AsyncTask, it may be time to find an alternative, such as RxJava or Kotlin’s coroutines. Android 11 is officially deprecating the AsyncTask API. While this is only a deprecation and not a removal, it’s still probably a good idea to migrate to something else as soon as possible.
Meta Reflection Patched
Android 9 introduced the hidden API blacklist with the goal to prevent third-party app developers from using parts of the Android framework that aren’t part of the SDK, in the name of stability. Through the use of meta (or double) reflection, though, it was pretty trivial to work around and even disable this restriction altogether.
Android 11, however, is cracking down on this bypass. Meta reflection will no longer work, and even more hidden APIs are restricted. While it still seems to be possible to bypass the new restrictions, the bypass involves using native code, which might not be desirable for all developers.
Share to Print
Printing on Android should be easier with Android 11, thanks to the new Share to Print Intent. This allows developers to share a document directly to a print service, bypassing the normal sharing screen, making printing more convenient for users.
Still No Call Recording API
A feature was introduced in Android 11 Developer Preview 2 that allowed third-party dialer apps to record calls. However, this was quickly removed in Developer Preview 3. If you were seeing stories about this feature, sorry to disappoint, but it’s not available in Android 11.
Android 10 added the ability to “temporarily” install a GSI straight from Google, to more easily test your apps on newer versions of Android. This feature worked on any Google-certified device running Android 10. Unfortunately, it required an unlocked bootloader, since proper signature verification wasn’t fully implemented.
In Android 11, however, it should now be possible to select and install a Google GSI straight from Developer Options without an unlocked bootloader. Keep in mind that we haven’t been able to test this, so if you have, let us know how it goes!
As you can see, an awful lot has happened with Android 11. There have been changes to how file access works, new features involving smart devices, and even the potential ability to install GSIs without an unlocked bootloader.
Hopefully, this article helped you learn what you’ll need to consider going forward in Android app development. If not, oh well. If you’re interested in booting Android 11 on your Pixel device, we have the download links for you here. If you have an OEM device from OnePlus, Xiaomi, OPPO, or Realme, check out this article to see if your device is eligible for a beta. Alternatively, you can fire up Android Studio to launch the latest Android 11 emulator build, or you can flash one of the Android 11 GSIs released today. Happy developing!