Android Q (Updated to Beta 6): Everything developers need to know

From a user’s perspective, a new version of Android is usually an exciting time. Unless you happen to dislike a particular UI element, it generally means better performance, more stability, and a slew of new features.

Also read: The top Android Q features you should know

For developers, an update like Android Q tends to bring more mixed feelings. Those new features are still good news, potentially allowing for more interesting and powerful functionality in our apps. At the same time, the changes also represent a lot of work as we rush to ensure projects will not only support the new platform and meet its specifications, but be optimized for it to provide the best possible experience.

To that end, this post will help you get up to speed, by sharing all of the important changes and developments we know about so far for developers to keep in mind.

This currently includes all new developments up to Beta 6. This is likely the last time we’ll be updating this post before the final release!

Android Q for developers at a glance – what you really need to know

Here’s what you really need to know:

• New location permissions will be required.
• Support for multi-resume requires manifest changes.
• Scoped storage will change how you save and access files on external storage.
• Scanning for location now requires FINE location.
• Information such as IMEI is now restricted.
• Background apps can no longer launch foreground activities.
• While it’s not strictly related to Android Q, new specifications for app icons are being introduced.
• Likewise, later this year, developers will be forced to support Android Pie at the minimum. Warnings will appear on apps if they do not adhere.
• And all apps will need to provide 64-bit versions by the end of the year.
• New system gesture navigations may impact app UI.

Here are some cool new features you might be interested in:

• Multi-resume will allow for more powerful multitasking.
• You can test changes in the emulator via the Android 3.5 Canary release channel.
• Devs can now access more data from depth sensors.
• Devs can opt to support dark theme.
• High performance and low latency WiFi modes available.
• TextClassifier will let devs identify the language of a piece of text.
• MicrophoneDIrection API will let you choose the direction of the microphone when recording.
• Bubbles will allow for easier multitasking and rich notifications.
• Increased support for media codecs.
• Sharing shortcuts will make it easier to share media from apps.
• Quick settings will allow easy access to settings relating to the current app.
• Vulkan support is being pushed hard.
• More neural network operations.
• Improvements to the Android runtime will help your apps lunch faster (in theory).

For more details on all these things and more minor changes, keep reading. We’ll also take a look at how you can start testing your app on Android Q right now.

Location permissions see improved security options

Each new iteration of Android brings with it new features designed to provide a more secure and private experience for users. This time around, they are gaining more control over location information. Previously, users could either grant or deny access to location data wholesale. This time around, they’ll be able to select a third option to only provide that data while the app is in use — when it is running in the foreground.

This hopefully means that users won’t refuse to install an app entirely because they don’t want it “watching them,” though the wording used for the background location permission may be a little off-putting:

“Allow App to access this device’s location all the time?”

Ouch!

However you feel about it, it means you’ll need to make a few changes. Specifically, developers targeting Q will need to add the following line to their app manifest: android.permission.ACCESS_BACKGROUND_LOCATION.

If you have an older app, then Android will add this permission in addition to ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION by default.

More information on how to set this up is available from Google here.

Scoped storage changes the way you access external files

While we’re on the subject of privacy, users will also be able to control access to shared files in the Photos, Videos, and Audio folders with new runtime permissions replacing READ_EXTERNAL_STORAGE and WRITE_EXTERNAL_STORAGE. Access to the Downloads folder will also only be available through the system file picker, giving users total control over which files are made available.

To set this up, you’ll need to request new permissions such as READ_MEDIA_IMAGES and then access the collections via the MediaStore API. You can find the full instructions here.

To counterbalance, apps will now have their own “isolated storage sandbox” that provides a folder restricted to that app located on external storage. This is intended to reduce the need for permissions, while hopefully being a little more flexible than the internal storage currently provided. You’ll still need to back those files up by moving them to the MediaStore collections, or using the Storage Access Framework, if you want them to remain after the app has been uninstalled. It will inevitably create some obstacles in a few unique use-cases however.

If you wish to access files from other apps’ isolated storage sandboxes on external storage, then there are some caveats. This is enabled by default for common media file types (like photos and music). If you wish to access other files created by a separate app however, you will be need to use the ACTION_OPEN_DOCUMENT and ACTION_OPEN_DOCUMENT_TREE intents to request access to a specific file (which the user will grant or revoke).

More security changes

A couple other security changes to consider:

• Background apps will no longer be able to launch activities in the foreground as this can be jarring for users. You’ll instead need to use a high-priority notification with a fullscreen intent for things like incoming calls.
• Devices will have randomized MAC addresses on different Wi-Fi networks by default (this was optional in Pie).
• Access to information such as device IMEI and serial number will now be limited. More information here.
• APIs for scanning networks will now require the FINE location permission.
• Added support for WPA3 and Enhanced Open Wi-Fi standards.
• It appears that apps will no longer be able to toggle Wi-Fi, instead being forced to rely on the new settings panel.

Future proofing – foldable devices, multi-resume, and neural networks

Android Q is also taking a number of steps to prepare for the future of hardware. You know what that means: foldables! Or, as Google calls them: “innovative new screens.”

The big developments are improvements to onResume and onPause. These will now support “multi-resume” and notify the app when it gains focus. Multi-Resume effectively allows two apps to run simultaneously without pausing (as they currently do). This will likely affect all apps in multi-window mode (not just those on foldable displays), ultimately bringing our phones yet closer to true desktop-like performance. If you would like to see what that looks like right now, you can try something similar through the MultiStar app on Samsung (part of Good Lock).

As well as multi-resume though, Android Q also sees changes to onResume and onPause – perhaps some of the most fundamental changes we’ve seen for a while.

The resizable Activity manifest attribute is also being changed, to help cope with regularly doubling in size as the displays are opened out.

This is all largely good news for developers who now need worry less about how to handle their apps being paused but visible. That said, it introduces yet more potential use-cases and display types to an already highly fragmented platform. Fun fun.

Again, to implement all this you’ll need to make some changes in the manifest, and specifically include the tag: android.allow_multiple_resumed_activities. As of Beta 2 and 3, developers will be able to test this out themselves using the foldables emulator via the AVD.

The Neural Networks API 1.2 is also coming, bringing 60 new operations and improved functionality. Ops include the likes of ARGMAX, ARGMIN, and Quantized LSTM, which should essentially enable better object detection and image segmentation.

More multitasking with bubbles

As if true multitasking wasn’t enough, Android Q will also introduce yet another way to do more than one thing at once: bubbles. These bubbles effectively act as a form of notification, but provide more information and even show entire activities on top of what the user is currently doing. This allows quick access to such things as notes, translations, and chats. Essentially chat heads then.

Developers will be able to access the new feature through an API built on top of the current notification system. To send bubbles, you will use setBubbleMetadata and then provide an activity to be displayed within the bubble along with an icon.

Sharing shortcuts and the settings panel

Google wants to make it easier for users to share content from apps, and thus it will be introducing “Sharing Shortcuts” to allow users to jump straight into another app. Developers will be able to publish “share targets” to launch specific activities with the content attached, and these will be shown to users via the UI. As of Beta 2, you can now provide a preview of the data being shared.

This will work similarly to App Shortcuts, and so will be accessible through the ShortcutInfo API. There will also be a new ShareTarget AndroidX library, which will work for devices not running Q. Google has shared a sample app for those who want to check out how this all works.

It seems making things quicker is the name of the game in general, with Android Q also making it easier to change system settings in the context of the currently running app. This will be available to devs through the Settings Panel API.

To display the settings panel, you’ll just need to use an intent like ACTION_VOLUME with a Settings Panel action.

Connectivity improvements

The Wi-Fi stack has been refactored in Android Q in order to improve privacy and performance, and to make things such as managing IoT devices or suggesting internet connections easier without needing location permission.

More interesting though, is that devs will be able to access high performance and low latency modes. The latter will be particularly useful for games (and game streaming!).

You can access these by calling WiFiManager.WiFiLock.creatWifiLock() and using WIFI_MODE_FULL_LOW_LATENCY or WIFI_MODE_FULL_HIGH_PERF.

New media options – codec support and depth data

Devs will now be able to take advantage of those depth-sensing cameras. Dynamic Depth images can be requested and will contain a JPG, XMP metadata describing depth elements, and a depth confidence map.

This could be useful for camera apps and imaging editing apps, but perhaps more exciting is the potential for AR applications. Google is working with OEMs to ensure this is available across all Q-supporting devices.

Android Q will also support the open source video codec AV1, which allows for high quality streaming with lower bandwidth requirements. Audio encoding via Opus is also coming. Through the MediaCodecInfo API, it will also now be easier to discern the rendering options available on a given device.

A native MIDI API will also allow communication with MIDI devices via the NDK. The new MicrophoneDirection API will allow developers to set the direction of the microphone during audio recording. This will also standardize control over zoomable microphones.

Another new feature is the ability to record audio from other apps. This will be useful for things like game streaming, captioning, and translating.

Performance upgraded – Vulkan and the Android Runtime

Game devs should benefit from improved Vulkan support across the board. Google’s stated goal is to ensure that the API is supported on all 64-bit devices running Android Q. The company is also working on a standard and updateable OpenGL driver for devices built on Vulkan. Android Q will also add experimental support for ANGLE – an abstraction layer that should allow games using OpenGL ES to take advantage of Vulkan’s performance and stability. OpenGL ES 2.0 will also be supported in Q, with support for 3.0 coming shortly thereafter.

You can likewise expect to see improved general performance across your apps. This will partly be achieved through improvements to the Android runtime, which will let apps start faster and consume less memory (though Gary didn’t find this in his Speed Test G using an older device).

In a bid to improve stability, Google will also be restricting access to private APIs. You can find a list of those being greylisted here. Google pledges that public alternatives will be made available in all cases.

UI changes – gestural navigation and dark mode

As of Beta 3, devs can now opt to support the “dark theme” by extending their theme from “Theme.AppCompat.DayNight” or material components.  You can then set your own default night theme settings. Make sure to give users the option to switch themes as they wish too, and think about how your layout and visibility.

Android Q will also be supporting gesture navigation like almost every Android Skin, which will introduce new UI considerations for users. For example: consider whether gestures baked into your app’s unique UI will cause confusion for users. In cases like this, developers can choose whether to use “gesture exclusion rectangles” to override the system gestures, or to simply change the way users interact with their apps. Likewise, think about making more use of that extra screen real-estate afforded by the loss of buttons.

The TextClassifier class will allow developers to detect the language of a piece of text.  Finally, Smart Actions will populate quick response fields within notifications with logical options. This will reduce some overhead for devs who will no longer need to code that functionality from scratch.

Responding to feedback, the latest changes in Beta 5 have added a “peek” option for apps using the navigation draw, and a quick shortcut for accessing the assistant. Beta 6 brought a sensitivity setting for the back gesture, along with a 200dp vertical app exclusion limit.

How to give it a go

If all that has sparked your imagination (or made you just a little anxious), there are a few ways you can give Android Q a spin.

You can load the Android Q Beta onto a Pixel device. If you don’t happen to have a Pixel lying around though – or if you’re not keen to install a beta operating system onto your daily driver – then you can instead go the easier route of setting it up on using the AVD Manager. Just open up the SDK Manager and then you should be able to choose a system image for Android Q Beta to download it.

As of Android Q Beta 4 and above, all APIs are now available for devs to begin testing their apps and Google is already accepting those targeting API 29 on the Play Store.

What do you think of these changes? Can you think of any new features you’ll be able to bring to your projects? Or do you have a lot of work now to get around the security updates?