It’s that time of the year again. Google has pushed out betas for its latest, greatest, as-yet-unnamed version of Android: Q. Your eagle-eyed Android Police editors have been combing through looking for new features, changes, improvements, and even setbacks. We’ve enumerated everything we’ve found here, together with a brief description of what’s new. So, let’s take a look at Android Q.

As always, we have to thank our tipsters (❤️) for our feature-level coverage. Without all of you, our job would be much harder.

We’ve kept our general categories the same as last year for now, though they may be reorganized later if we determine different groups make sense. And keep in mind that we are still finding new features, so this document may sometimes lag a bit behind our series coverage. Based on a request I received last year, we’ve changed our format for these Android feature roundups to make them a little easier to follow over time, with our additions since the last update included just below:

What’s new?

This could be the last major update to both Android Q and our list of its features for a little while. Google’s timeline gets a bit vague after Beta 4, with Beta 5 and 6 as release candidates landing back-to-back sometime in Q3 — likely in July or early August, before the expected and traditional late-August release.

The Android Q Beta 4 landed back at the beginning of the month, and in the intervening time, we think we’ve found most of the principal changes. There may still be a few as-yet-undiscovered stragglers we’ll cover later, but most of the changes Android Q has seen up through Beta 4 (including a few stragglers from Beta 3) should be included.

The Android Q feature list

Entirely new Q features

General visual changes

Modifications to existing features

Privacy tweaks

  • Tweaks to identifiable permissions like location, IMEI MAC address, background app changes: Android Q, as of Beta 1, limits access to non-changeable device IDs like the MAC address or IMEI, and further changes permissions to provide options so they can be granted “only while the app is in use,” rather than just a blanket yes/no. That means an app that isn’t immediately open doesn’t necessarily have access to your location. Background apps also can’t suddenly change focus to bring themselves forward anymore.
  • Clipboard managers are ded: Although clipboard managers can provide utility in some workflows, the permissions they rely on could be used surreptitiously by nefarious apps in ways that could violate your privacy. From Android Q on, Google’s giving them the boot. Only input method editors (keyboard apps, etc.) and foreground apps with focus will get access to the clipboard.
  • Revoke permissions at first launch for apps targeting older (pre-Oreo) API levels: Apps that haven’t updated to target Android 8.0 Oreo will spit a new interstitial screen at launch that asks which permissions you’d like to enable, allowing you to manually disable those you don’t want — and maybe break the app in the process.
    • As of Beta 2, Android will ask for permissions to be granted again when launching apps installed before the update.
  • Overlay attack mitigation: In the world of Android security, overlay-based attacks are one of the bigger problems, but Android Q works to mitigate their effect by changing how the overlay permissions work. From now on they’ll need to be granted again every time you open an app that uses them.
  • Smart Lock developer options: Tweaks to how “trust agents” (like Google’s Smart Lock) can keep the device unlocked.
  • MAC address randomization: Initially added in Android P as an experimental feature, MAC address randomization is now on by default in Android Q — though it’s consistent, you will see the same randomly generated address when connecting to the same network again. It can be disabled if you need to turn it off, though.
  • Scoped Storage in Android Q nerfs filesystem access: Apps targeting Android Q will be limited in how they can access the filesystem via new isolated storage sandboxes. That means apps won’t need permissions to write their own files, while also enhancing security between apps through isolated storage. It also means that they won’t have blanket filesystem access by default. Old permissions aren’t going away any time soon, and apps targeting platforms before Q will work via a “compatibility mode” that doesn’t include these restrictions.
  • Encryption for all devices, including low-end hardware: Performance remains a question, but Android Q will require disc encryption, even on low-end hardware and.
  • TLS 1.3 will be enabled by default, and biometrics will now be classified as explicit and implicit based on type for different levels of security and privacy in different circumstances, plus other developer-facing improvements and changes.

Under the hood/API/developer stuff

  • Dynamic Depth data: Android Q will allow for apps to request depth information from the cameras. Google’s done some incredible work to extract that information from its cameras (without the help of parallax, I should add), and in Android Q, even third-party apps will be able to make use of that extra data in new and interesting ways. I can’t wait to see what gets cooked up.
  • ART enhancements: Developers can enjoy enhanced performance and more efficient garbage collection on Android Q via a suite of impressive but highly technical Android runtime enhancements.
  • Further non-SDK API deprecation: As much as possible, Google doesn’t want developers using undocumented APIs in Android, and Android Q furthers this crackdown, expanding the list of affected APIs.
  • Folding phone tweaks: Android Q will feature some developer-facing modifications to better work with the emerging device form factor, but they’re all too technical to get into here.
  • Smart home/IoT tweaks for Wi-Fi setup: Configuring smart home gadgets, which almost always need their own special app and require a peer-to-peer Wi-Fi connection, can be easier in Android Q. Developers will be able to configure their setup apps to have a list of preferred SSIDs, and paired with the expansion of slices to offer a built-in Wi-Fi picker in those apps, that can make the often tedious IoT setup process a little bit faster and simpler for consumers.
  • Apps assigned to default roles will get more permissions: Details are a little sparse on precisely which permissions each category gets, but apps that you assign as the default for a given role — like browser, SMS app, launcher, etc. — will pick up elevated access to certain functions based on that role.
  • Foldables (running Q) added to Android Studio emulator: Developers looking to get a head start on developing for foldable devices can do so via the Canary release of Android Studio 3.5, which includes emulator images that have folding functionality.
  • API for microphone direction: Android Q includes new APIs that allow developers to request specific microphone directions like “front” or “back.”
  • New “Notification Assistant” API for apps like Tasker: Android Q may be making things harder for apps that harness things like automation or overlays, but Google is introducing a new default app setting and associated API that might mitigate things for those sorts of apps slightly — at least when it comes to notifications.
    • This feature isn’t intended for general public use, though. After enabling it in Beta 3 and accidentally publishing documentation for the API, the pages have been taken down, and Google has confirmed that these actions were intentional. Notification Assistant is an invite-only API club.
  • Vulkan 1.1 required on all 64-bit devices running Q or higher: Support for Vulkan API 1.1 was introduced on Android P, but as of Q and forward it will be a hard requirement for 64-bit devices.
  • AV1 video codec, Opus audio codec: Android Q will have native support for the new, data-saving AV1 video codec and the Opus audio codec.
  • Device temperature API: Smartphones get a lot warmer now than they used to — at least, excluding Qualcomm’s wonderful Snapdragon 808/810. With developers already pushing the limits of passive cooling with heatpipes, as well as external active cooling solutions, a new Thermal API can further help apps respond to changes in temperature for an enhanced experience.
  • Audio Playback Capture API: A new API is behind the upcoming magic of Live Caption shown off at I/O, which allows for real-time subtitling of any audio being played on your device. However, the app could also be used for other novel purposes by enterprising developers.