Android Q's new features and characteristics

1. Introduction to Android Q

In 2019, mobile innovation was stronger than ever, from new technologies such as 5G to edge-to-edge displays and even foldable screens. Android is at the center of this innovation cycle, and thanks to a broad partner ecosystem across billions of devices, Android helps push the boundaries of hardware and software to bring new experiences and capabilities to users.

As the mobile ecosystem evolves, Android is focused on helping users take advantage of the latest innovations while ensuring that user security and privacy are always top priorities. Building on work like Google Play Protect and runtime permissions, Android Q brings many additional privacy and security features to users, as well as foldable enhancements, new APIs for connectivity, new media codecs and camera features, NNAPI extensions, Vulkan 1.1 support, faster app startup, and more.

[[280930]]

2. Android Q privacy protection

Android is designed with security and privacy at the center. As Android matured, we added a range of features to protect users, such as file-based encryption, OS controls that require apps to request permissions before accessing sensitive resources, locking down camera/microphone background access, Lockdown mode, encrypted backups, Google Play Protect (which scans over 50 billion apps a day to identify potentially harmful apps and remove them), and more. In Android Q, we've made even more enhancements to protect users. Many of these enhancements are part of our work on Project Strobe.

Give users more control over location

With Android Q, the OS gives users more control over when apps access location information. As with previous versions of the OS, apps can only access location if the app asks you for permission and you grant that permission.

One particularly sensitive thing is app access to location when the app is not in use (in the background). Android Q allows users to grant apps permission to never see their location, only when the app is in use (running), or always (in the background).

For example, an app asking the user for the location of a food delivery makes sense, and the user might want to grant it the ability to do that. But since the app might not need to be located outside of the location it's currently being used at, the user might not want to grant that access. Android Q now offers a higher level of control. Read the developer guide for details on how to adjust your app for this new control. Look for more user-centric improvements in the upcoming Betas. At the same time, our goal is to be very responsive and always give developers as much attention and support as possible with these changes.

More privacy protections in Android Q

In addition to the location changes, we will be making further updates to ensure transparency, give users control, and protect personal data.

In Android Q, the OS gives users more control over apps, controlling access to shared files. Users will be able to control app access to photo and video or audio collections through new runtime permissions. For downloads, apps must use the system file picker, allowing users to decide which downloaded files the app can access. For developers, there are changes to how apps can use shared areas on external storage. Be sure to read the Scoped Storage changes for details.

We've also seen that users (and developers!) get upset when apps unexpectedly jump to the foreground and regain focus. To reduce these interruptions, Android Q will prevent apps from launching activities in the background. If your app is in the background and needs to get the user's attention quickly — such as an incoming call or alarm — you can use a high-priority notification and deliver a full-screen intent. For more information, see the documentation.

We restrict access to non-resettable device identifiers, including device IMEI, serial number, and similar identifiers. Read the best practices to help you choose the right identifier for your use case, and see details here. We also randomize the device's MAC address by default when connecting to different Wi-Fi networks - this is an optional setting in Android 9 Pie.

We’ll be bringing these changes to you as early as possible, so you can have as much time to prepare as possible. We’re also working hard to provide detailed information to developers, and we recommend you review the detailed documentation on the privacy changes and start testing today.

New ways to engage users

In Android Q, we're enabling new ways to bring users into your app and simplify the experience when they transition from other apps.

3. Android Q is compatible with foldable screens

Foldable devices open up some innovative experiences and use cases. To help your app take advantage of these and other large-screen devices, we've made some improvements in Android Q, including changes to onResume and onPause to support multiple resumes and notify your app when it's focused. We've also changed how the resizeableActivity manifest attribute works to help you manage how your app displays on foldable and large screens. To start building and testing for these new devices, we've been working on updating the Android Emulator to support multiple display type switching — more details coming soon!

4. New style of Android Q sharing function

When users want to share something like a photo with someone in another app, the process should be fast. In Android Q, we're making it faster and easier for users with "sharing shortcuts," so users can jump directly into another app to share content. Developers can publish share targets for specific activities in their app that add content, and show these targets to users in the share UI. Because they're pre-published, the share UI can load immediately at startup.

The Share Shortcuts mechanism is similar to how App Shortcuts work, so we extended the ShortcutInfo API to make integration of both features easier. The new ShareTarget AndroidX library also supports this new API. This allows apps to use the new features while allowing pre-Q devices to work with Direct Share. You can find an early sample app with source code here.

5.Android Q update settings function

You can also now surface key system settings directly in the context of your app with a new settings panel API that leverages the slices feature we introduced in Android 9 Pie.

The settings panel is a floating UI that you can call from your app to display system settings that the user might need, such as Internet connectivity, NFC, and volume. For example, a browser can display a panel with connection settings such as airplane mode, Wi-Fi (including nearby networks), and mobile data. There is no need to leave the app; users can manage settings as needed from the panel. To display the settings panel, simply trigger an intent using one of the new Settings.Panel actions.

connect

In Android Q, we've expanded the connectivity stack your apps can use with Android and added new connectivity APIs.

Connection permissions, privacy, and security

Most of our APIs for scanning networks require the COARSE location permission, but in Android Q, for Bluetooth, cellular, and Wi-Fi, we're increasing the protection of these APIs by requiring the FINE location permission. If your app only needs to establish peer-to-peer connections or suggest networks, check out the improved Wi-Fi APIs below—they simplify connections and don't require location permission.

In addition to the randomized MAC addresses that Android Q provides when connecting to different Wi-Fi networks, we've also added support for new Wi-Fi standards, WPA3 and Enhanced Open, to improve security on home and work networks, as well as open/public networks.

Improved peer-to-peer and internet connections

In Android Q, we've refactored the Wi-Fi stack to improve privacy and performance, while also improving common use cases like managing IoT devices and suggesting internet connections — without requiring location permission.

The Network Connection API makes it easier to manage IoT devices over local Wi-Fi, enabling peer-to-peer functions such as configuration, downloading, or printing. Applications initiate connection requests indirectly by specifying the preferred SSID and BSSID as WiFiNetworkSpecifiers. The platform handles the Wi-Fi scan itself and displays matching networks in the Wi-Fi selector. When the user selects, the platform automatically sets up the connection.

The Network Suggestions API allows apps to surface preferred Wi-Fi networks to users for Internet connections. Apps initiate connections indirectly by providing a ranked list of networks and credentials, as described in WifiNetworkSuggestions. The platform will seamlessly connect to those networks in range based on past performance.

Wi-Fi Performance Mode

You can now request adaptive Wi-Fi in Android Q by enabling high performance and low latency modes. These will be very beneficial if low latency is important to the user experience, such as real-time gaming, active voice calls, and similar use cases.

To use the new performance modes, use or call WifiManager.WifiLock.createWifiLock(). In these modes, the platform works with the device firmware to meet the requirements with the lowest power consumption. WIFI_MODE_FULL_LOW_LATENCY``WIFI_MODE_FULL_HIGH_PERF

6. Android Q updates Media

Dynamic depth format for photos

Many cameras on mobile devices can simulate narrow depth of field by blurring the foreground or background relative to the subject. They capture depth metadata at various points in the image, apply a static blur to the image, and then discard the depth metadata.

Starting in Android Q, apps can request a dynamic depth image, which consists of a JPEG with associated depth-related elements, XMP metadata, and depth and confidence maps embedded in the same file on ad-supported devices.

Requesting JPEG+ Dynamic Depth images lets you offer specialized blur and bokeh options in your app. You can even use the data to create 3D images or support AR photography use cases in the future. We are making Dynamic Depth an open format for the ecosystem, and we are working with our device manufacturer partners to make it available on devices running Android Q and higher.

New audio and video codecs

Android Q introduces support for the open source video codec AV1. This allows media providers to stream high-quality video content to Android devices using less bandwidth. In addition, Android Q supports audio encoding using Opus (a codec optimized for voice and music streaming), and HDR10+ for high dynamic range video on devices that support it.

The MediaCodecInfo API introduces a simpler way to determine the video rendering capabilities of an Android device. For any given codec, you can use VideoCodecCapabilities.getSupportedPerformancePoints() to get a list of supported sizes and frame rates. This allows you to choose the best quality video content to render on any given device.

Native MIDI API

For apps that perform audio processing in C++, Android Q introduces a native MIDI API to communicate with MIDI devices through the NDK. This API allows retrieval of MIDI data within an audio callback using non-blocking reads, enabling low-latency processing of MIDI messages. Try it out with the sample app and source code here.

The Vulkan perspective

To make things more consistent for game and graphics developers, we're working on a standard, updatable OpenGL driver for all devices built on Vulkan. In Android Q, we're adding experimental support for ANGLE on Vulkan on Android devices. ANGLE is a graphics abstraction layer designed to enable high-performance OpenGL compatibility across implementations. With ANGLE, many apps and games using OpenGL ES can take advantage of the performance and stability of Vulkan and benefit from a consistent, vendor-independent ES implementation on Android devices. In Android Q, we plan to support OpenGL ES 2.0, ES 3.0 on the roadmap.

We will be expanding the implementation with more OpenGL features, bug fixes, and performance optimizations. For details on Android's current ANGLE support, how to use it, and our future plans, see the documentation. You can start testing with our initial support by selecting Developer options in Settings. Give it a try today!

Vulkan Everywhere

We're continuing to expand the reach of Vulkan on Android, our low-overhead, cross-platform API for high-performance 3D graphics. Our goal is to make Vulkan on Android a broadly supported and consistent graphics developer API. We're working with our device manufacturer partners to make Vulkan 1.1 a requirement for all 64-bit devices running Android Q and higher, and recommended for all 32-bit devices. Going forward, this will help provide apps and games with a unified, high-performance graphics API.

7.Android Q optimizes neural network API 1.2

Since introducing the Neural Networks API (NNAPI) in 2017, we've continued to expand the number of supported operations and improve existing features. In Android Q, we've added 60 new operations, including ARGMAX, ARGMIN, quantized LSTM, and a range of performance optimizations. This lays the foundation for accelerating a wider range of models - such as those for object detection and image segmentation. We're working with hardware vendors and popular machine learning frameworks such as TensorFlow to optimize and launch support for NNAPI 1.2.

8. Android Q optimizes basic Android functions

ART manifestations

Android Q introduces several new improvements to the ART runtime that help apps launch faster and consume less memory without any work from developers.

Since Android Nougat, ART has provided Profile Guided Optimization (PGO), which speeds up app startup by identifying and precompiling frequently executed parts of your code. To help with initial app startup, Google Play now provides cloud-based profiles along with your APK. These are anonymous, aggregated ART profiles that let ART precompile parts of your app before it runs, providing an important jumpstart to the entire optimization process. Cloud-based profiles benefit all apps, and they are already available for devices running Android P and higher.

We're also continuing to improve ART itself. For example, in Android Q, we're optimizing the Zygote process by starting your app's process earlier and moving it to a secure container, so it can start right away. We're storing more information in your app's heap image, such as classes, and using threads to load the image faster. We're also adding Generational Garbage Collection to ART's Concurrent Copying (CC) garbage collector. Generational CC is more efficient because it collects young generation objects separately, which is less expensive than a full-heap GC while still reclaiming a lot of space. This makes garbage collection more efficient overall in terms of time and CPU, reducing jank and helping apps run better on lower-end devices.

Application Security

BiometricPrompt is our unified authentication framework for supporting system-wide biometrics. In Android Q, we've expanded support for passive authentication methods like face, as well as adding implicit and explicit authentication flows. In the explicit flow, the user must explicitly confirm a transaction in the TEE during authentication. The implicit flow is designed as a lightweight alternative to transactions with passive authentication. We've also improved the fallback for device credentials when needed.

Android Q adds support for TLS 1.3, a major revision of the TLS standard that includes performance benefits and enhanced security. Our benchmarks show that secure connections can be up to 40% faster using TLS 1.3 compared to TLS 1.2. TLS 1.3 is enabled by default for all TLS connections. See the documentation for more details.

Compatibility via public API

Another thing we care about is making sure apps run smoothly as the OS changes and evolves. Apps that use non-SDK APIs can be at risk of crashes for users and emergency deployments for developers. In Android Q, we're continuing the long-term effort we started in Android P to move apps to use only public APIs. We know it takes time to move your apps away from non-SDK APIs, so we're giving you advance notice.

In Android Q, we're restricting access to more non-SDK interfaces and requiring you to use public equivalents. To help you make the transition and prevent your apps from breaking, we enable restrictions only if your app targets Android Q. We'll continue to add public alternative APIs based on your requests; if there's no public API that fits your use case, let us know.

It's important to test your app for use of non-SDK interfaces. We recommend using the StrictMode method detectNonSdkApiUsage() to warn your app when it accesses non-SDK APIs through reflection or JNI. Even though the API is exempt (greylisted) at this time, it's best to plan for the future and eliminate its use to reduce compatibility issues. For more details on the restrictions in Android Q, see the developer guide.

Modern Android

We're working to make sure all apps take advantage of the security and performance features in the latest versions of Android. Later this year, Google Play will require you to set your app's targetSdkVersion to 28 (Android 9 Pie) for new apps and updates. With these changes, Android Q will warn users the first time they run an app that targets a platform prior to API level 23 (Android Marshmallow). Here's a checklist of resources to help you migrate your app.

We are also moving the ecosystem towards 64-bit device readiness. Later this year, Google Play will require 64-bit support in all apps. If your app uses native SDKs or libraries, keep in mind that you will need to provide 64-bit compatible versions of those SDKs or libraries. For more information on how to get ready, see the developer guide.

Get started with Android Q Beta

Because of the important privacy features that may affect your app, we recommend that you start testing now. In particular, you need to enable and test Android Q storage changes, new location permission states, background app launch restrictions, and device identifier restrictions. For more information, see the privacy documentation.

To get started, simply install your current app from Google Play onto a device or Android Virtual Device running Android Q Beta and complete the user flow. The app should run and look great, and correctly handle the Android Q behavior changes for all apps. If you find issues, we recommend that you fix them in your current app without changing targeting levels. Check out the migration guide for steps and recommended timelines.

Next, update your app's targetSdkVersion to "Q" as soon as possible. This allows you to test your app with all the privacy and security features in Android Q, as well as any other behavioral changes for apps targeting Q.

Explore new features and APIs

When you're ready, dive into Android Q and learn about the new features and APIs you can use in your apps. Use the API diff report, the Android Q Beta API reference, and the developer guide as a starting point. Additionally, on the Android Q Beta developer site, you can find release notes and support resources for reporting issues.

To build with Android Q, download the Android Q Beta SDK and tools into Android Studio 3.3 or higher and follow these instructions to configure your environment. If you need the latest fixes for Android Q-related changes, we recommend that you use Android Studio 3.5 or higher.

How do I get Android Q Beta?

It's easy - you can sign up here to get Android Q Beta updates over the air on any Pixel device (this year we support all three generations of Pixel - Pixel 3, Pixel 2, and even the original Pixel!). Downloadable system images for these devices are also available. If you don't have a Pixel device, you can use the Android Emulator and download the latest emulator system image through the SDK Manager in Android Studio.

We plan to update the preview system images and SDK regularly throughout the preview period. We will have more features to share as the Beta program progresses.

As always, your feedback is important, please let us know what you think - the sooner we hear from you, the better we can incorporate your feedback. When you find an issue, please report it here. We have separate hotlists for submitting platform issues, app compatibility issues, and third-party SDK issues.