Android Q is now available to download, but what has changed?
DOWNLOAD ANDROID Q BETA 1 (DEVELOPER PREVIEW 1) TODAY
Google just announced the launch of Android Q (Android 10.0), and once again Google have proved their worth, by announcing that Android Q Beta 1 will be available for ALL Pixel devices.
In this post we will look at answering questions like, what is the Android Q beta program? What has changed in Android Q and how to install to Android Q beta 1 to your pixel device! There are MANY exciting changes to the latest update to Android 10.0, and I am sure you guys cannot wait to install it before anyone else, on your Pixel smartphone! There are UI improvements, security improvements and many other features in the latest Android Q update, that we will cover in this post.
Check out my latest Android Q Video and please subscribe 🙂
WHAT IS ANDROID Q BETA PROGRAM?
Android Beta for Pixel offers you a simple way to try pre-release versions of Android, and test drive our new features. The feedback you provide will help us identify and fix issues, and make the platform even better. Registered devices will automatically receive updates for the latest beta version of Android. Learn more about eligible devices.
How do I participate?
Sign in to your Google Account to see a list of your eligible devices. After you opt in and accept the Android Beta Program Terms of Service, you can start sharing your thoughts about Android Q with us directly from your device and by joining the Android Beta Program Reddit community.
Before you enroll
The updates that you’ll receive as a part of this program are pre-release versions, and may contain errors and defects that can affect normal functioning of your device. You will not be able to unenroll and revert back to a lower public release version of Android without first wiping all locally saved data on your device. You may also encounter issues restoring a backup. See Pixel known issues. Note: You will not receive separate monthly security updates while on a beta build.
What devices can install the Android Q Beta 1 update?
If you have a Google Pixel device, it is your lucky day! The Android Q beta is available to download via OTA for Pixel, Pixel 2 and Pixel 3XL. All other devices and OEMs will provide access to the update via their standard OTA timescales.
Once you’re enrolled
You may remain in the Android Beta Program beyond the initial Q release to preview future Android Q updates. These may include bug fixes, feature updates, and improvements to stability and performance. If you choose to do so, you will automatically get pre-release updates as they become available. At the end of the program, you will begin to receive regular public updates.
Leaving the beta program
You may opt out of the program at any time to return to the stable, public version of Android. If you opt out when your device is running a beta version of Android, all user data on the device will be wiped. If you choose to stay enrolled until the end of the program, you will graduate from the program and receive an update to the stable public release of Q. Your device will not be wiped.
ANDROID Q UPDATE FEATURES AND CHANGES
Building on top of privacy protections in Android
Android was designed with security and privacy at the center. As Android has matured, we’ve added a wide range of features to protect users, like file-based encryption, OS controls requiring apps to request permission before accessing sensitive resources, locking down camera/mic 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 much more. In Android Q, we’ve made even more enhancements to protect our users. Many of these enhancements are part of our work in Project Strobe.
Giving users more control over location
With Android Q, the OS helps users have more control over when apps can get location. As in prior versions of the OS, apps can only get location once the app has asked you for permission, and you have granted it.
One thing that’s particularly sensitive is apps’ access to location while the app is not in use (in the background). Android Q enables users to give apps permission to see their location never, only when the app is in use (running), or all the time (when in the background).
For example, an app asking for a user’s location for food delivery makes sense and the user may want to grant it the ability to do that. But since the app may not need location outside of when it’s currently in use, the user may not want to grant that access. Android Q now offers this greater level of control. Read the developer guide for details on how to adapt your app for this new control. Look for more user-centric improvements to come in upcoming Betas. At the same time, our goal is to be very sensitive to always give developers as much notice and support as possible with these changes.
More privacy protections in Android Q
Beyond changes to location, we’re making further updates to ensure transparency, give users control, and secure personal data.
In Android Q, the OS gives users even more control over apps, controlling access to shared files. Users will be able to control apps’ access to the Photos and Videos or the Audio collections via new runtime permissions. For Downloads, apps must use the system file picker, which allows the user to decide which Download files the app can access. For developers, there are changes to how your apps can use shared areas on external storage. Make sure to read the Scoped Storage changes for details.
We’ve also seen that users (and developers!) get upset when an app unexpectedly jumps into the foreground and takes over focus. To reduce these interruptions, Android Q will prevent apps from launching an Activity while in the background. If your app is in the background and needs to get the user’s attention quickly — such as for incoming calls or alarms — you can use a high-priority notification and provide a full-screen intent. See the documentation for more information.
We’re limiting access to non-resettable device identifiers, including device IMEI, serial number, and similar identifiers. Read the best practices to help you choose the right identifiers for your use case, and see the details here. We’re also randomizing the device’s MAC address when connected to different Wi-Fi networks by default — a setting that was optional in Android 9 Pie.
We are bringing these changes to you early, so you can have as much time as possible to prepare. We’ve also worked hard to provide developers detailed information up front, we recommend reviewing the detailed docs on the privacy changes and getting started with testing right away.
New ways to engage users
In Android Q, we’re enabling new ways to bring users into your apps and streamlining the experience as they transition from other apps.
Foldables and innovative new screens
Foldable devices have opened up some innovative experiences and use-cases. To help your apps to take advantage of these and other large-screen devices, we’ve made a number of improvements in Android Q, including changes to onResume and onPause to support multi-resume and notify your app when it has focus. We’ve also changed how the resizeableActivitymanifest attribute works, to help you manage how your app is displayed on foldable and large screens. To you get started building and testing on these new devices, we’ve been hard at work updating the Android Emulator to support multiple-display type switching — more details coming soon!
When a user wants to share content like a photo with someone in another app, the process should be fast. In Android Q we’re making this quicker and easier with Sharing Shortcuts, which let users jump directly into another app to share content. Developers can publish share targets that launch a specific activity in their apps with content attached, and these are shown to users in the share UI. Because they’re published in advance, the share UI can load instantly when launched.
The Sharing Shortcuts mechanism is similar to how App Shortcuts works, so we’ve expanded the ShortcutInfo API to make the integration of both features easier. This new API is also supported in the new ShareTarget AndroidX library. This allows apps to use the new functionality, while allowing pre-Q devices to work using Direct Share. You can find an early sample app with source code here.
You can now also show key system settings directly in the context of your app, through a new Settings Panel API, which takes advantage of the Slices feature that we introduced in Android 9 Pie.
A settings panel is a floating UI that you invoke from your app to show system settings that users might need, such as internet connectivity, NFC, and audio volume. For example, a browser could display a panel with connectivity settings like Airplane Mode, Wi-Fi (including nearby networks), and Mobile Data. There’s no need to leave the app; users can manage settings as needed from the panel. To display a settings panel, just fire an intent with one of the new Settings.Panel actions.
In Android Q, we’ve extended what your apps can do with Android’s connectivity stack and added new connectivity APIs.
Connectivity permissions, privacy, and security
Most of our APIs for scanning networks already require COARSE location permission, but in Android Q, for Bluetooth, Cellular and Wi-Fi, we’re increasing the protection around those APIs by requiring the FINE location permission instead. If your app only needs to make peer-to-peer connections or suggest networks, check out the improved Wi-Fi APIs below — they simplify connections and do not require location permission.
In addition to the randomized MAC addresses that Android Q provides when connected to different Wi-Fi networks, we’re adding new Wi-Fi standard support, WP3 and OWE, to improve security for home and work networks as well as open/public networks.
Improved peer-to-peer and internet connectivity
In Android Q we refactored the Wi-Fi stack to improve privacy and performance, but also to improve common use-cases like managing IoT devices and suggesting internet connections — without requiring the location permission.
The network connection APIs make it easier to manage IoT devices over local Wi-Fi, for peer-to-peer functions like configuring, downloading, or printing. Apps initiate connection requests indirectly by specifying preferred SSIDs & BSSIDs as WiFiNetworkSpecifiers. The platform handles the Wi-Fi scanning itself and displays matching networks in a Wi-Fi Picker. When the user chooses, the platform sets up the connection automatically.
The network suggestion APIs let apps surface preferred Wi-Fi networks to the user for internet connectivity. Apps initiate connections indirectly by providing a ranked list of networks and credentials as WifiNetworkSuggestions. The platform will seamlessly connect based on past performance when in range of those networks.
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 of great benefit where 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, call WifiManager.WifiLock.createWifiLock() with
WIFI_MODE_FULL_HIGH_PERF. In these modes, the platform works with the device firmware to meet the requirement with lowest power consumption.
Camera, media, graphics
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 for various points in the image and apply a static blur to the image, after which they discard the depth metadata.
Starting in Android Q, apps can request a Dynamic Depth image which consists of a JPEG, XMP metadata related to depth related elements, and a depth and confidence map embedded in the same file on devices that advertise support.
Requesting a JPEG + Dynamic Depth image makes it possible for you to offer specialized blurs 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’re making Dynamic Depth an open format for the ecosystem, and we’re working with our device-maker partners to make it available across devices running Android Q and later.
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 speech and music streaming, and HDR10+ for high dynamic range video on devices that support it.
The MediaCodecInfo API introduces an easier way to determine the video rendering capabilities of an Android device. For any given codec, you can obtain a list of supported sizes and frame rates using VideoCodecCapabilities.getSupportedPerformancePoints(). This allows you to pick the best quality video content to render on any given device.
Native MIDI API
For apps that perform their audio processing in C++, Android Q introduces a native MIDI APIto communicate with MIDI devices through the NDK. This API allows MIDI data to be retrieved inside an audio callback using a non-blocking read, enabling low latency processing of MIDI messages. Give it a try with the sample app and source code here.
ANGLE on Vulkan
To enable more consistency for game and graphics developers, we are working towards a standard, updateable OpenGL driver for all devices built on Vulkan. In Android Q we’re adding experimental support for ANGLE on top of Vulkan on Android devices. ANGLE is a graphics abstraction layer designed for high-performance OpenGL compatibility across implementations. Through ANGLE, the many apps and games using OpenGL ES can take advantage of the performance and stability of Vulkan and benefit from a consistent, vendor-independent implementation of ES on Android devices. In Android Q, we’re planning to support OpenGL ES 2.0, with ES 3.0 next on our roadmap.
We’ll expand the implementation with more OpenGL functionality, bug fixes, and performance optimizations. See the docs for details on the current ANGLE support in Android, how to use it, and our plans moving forward. You can start testing with our initial support by opting-in through developer options in Settings. Give it a try today!
We’re continuing to expand the impact of Vulkan on Android, our implementation of the low-overhead, cross-platform API for high-performance 3D graphics. Our goal is to make Vulkan on Android a broadly supported and consistent developer API for graphics. We’re working together with our device manufacturer partners to make Vulkan 1.1 a requirement on all 64-bit devices running Android Q and higher, and a recommendation for all 32-bit devices. Going forward, this will help provide a uniform high-performance graphics API for apps and games to use.
Neural Networks API 1.2
Since introducing the Neural Networks API (NNAPI) in 2017, we’ve continued to expand the number of operations supported and improve existing functionality. In Android Q, we’ve added 60 new ops including ARGMAX, ARGMIN, quantized LSTM, alongside a range of performance optimisations. This lays the foundation for accelerating a much greater range of models — such as those for object detection and image segmentation. We are working with hardware vendors and popular machine learning frameworks such as TensorFlow to optimize and roll out support for NNAPI 1.2.
Strengthening Android’s Foundations
Android Q introduces several new improvements to the ART runtime which help apps start faster and consume less memory, without requiring any work from developers.
Since Android Nougat, ART has offered Profile Guided Optimization (PGO), which speeds app startup over time by identifying and precompiling frequently executed parts of your code. To help with initial app startup, Google Play is now delivering cloud-based profiles along with APKs. These are anonymized, aggregate ART profiles that let ART pre-compile parts of your app even before it’s run, giving a significant jump-start to the overall optimization process. Cloud-based profiles benefit all apps and they’re already available to devices running Android P and higher.
We’re also continuing to make improvements in ART itself. For example, in Android Q we’ve optimized the Zygote process by starting your app’s process earlier and moving it to a security container, so it’s ready to launch immediately. We’re storing more information in the app’s heap image, such as classes, and using threading 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 as it collects young-generation objects separately, incurring much lower cost as compared to full-heap GC, while still reclaiming a good amount of space. This makes garbage collection overall more efficient in terms of time and CPU, reducing jank and helping apps run better on lower-end devices.
Security for apps
BiometricPrompt is our unified authentication framework to support biometrics at a system level. In Android Q we’re extending support for passive authentication methods such as face, and adding implicit and explicit authentication flows. In the explicit flow, the user must explicitly confirm the transaction in the TEE during the authentication. The implicit flow is designed for a lighter-weight alternative for 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 to the TLS standard that includes performance benefits and enhanced security. Our benchmarks indicate that secure connections can be established as much as 40% faster with TLS 1.3 compared to TLS 1.2. TLS 1.3 is enabled by default for all TLS connections. See the docs for details.
Compatibility through public APIs
Another thing we all care about is ensuring that apps run smoothly as the OS changes and evolves. Apps using non-SDK APIs risk crashes for users and emergency rollouts for developers. In Android Q we’re continuing our long-term effort begun in Android P to move apps toward only using public APIs. We know that moving your app away from non-SDK APIs will take time, so we’re giving you advance notice.
In Android Q we’re restricting access to more non-SDK interfaces and asking you to use the public equivalents instead. To help you make the transition and prevent your apps from breaking, we’re enabling the restrictions only when your app is targeting Android Q. We’ll continue adding public alternative APIs based on your requests; in cases where there is no public API that meets your use case, please let us know.
It’s important to test your apps for uses of non-SDK interfaces. We recommend using the StrictMode method detectNonSdkApiUsage() to warn when your app accesses non-SDK APIs via reflection or JNI. Even if the APIs are exempted (grey-listed) at this time, it’s best to plan for the future and eliminate their use to reduce compatibility issues. For more details on the restrictions in Android Q, see the developer guide.
We’re expanding our efforts to have all apps take full advantage of the security and performance features in the latest version of Android. Later this year, Google Play will require you to set your app’s targetSdkVersion to 28 (Android 9 Pie) in new apps and updates. In line with these changes, Android Q will warn users with a dialog when they first run an app that targets a platform earlier than API level 23 (Android Marshmallow). Here’s a checklist of resources to help you migrate your app.
We’re also moving the ecosystem toward readiness for 64-bit devices. 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’ll need to provide 64-bit compliant versions of those SDKs or libraries. See the developer guide for details on how to get ready.
Get started with Android Q Beta
With important privacy features that are likely to affect your apps, we recommend getting started with testing right away. In particular, you’ll want to enable and test with Android Q storage changes, new location permission states, restrictions on background app launch, and restrictions on device identifiers. See the privacy documentation for details.
To get started, just install your current app from Google Play onto a device or Android Virtual Device running Android Q Beta and work through the user flows. The app should run and look great, and handle the Android Q behavior changes for all apps properly. If you find issues, we recommend fixing them in the current app, without changing your targeting level. Take a look at the migration guide for steps and a recommended timeline.
Next, update your app’s targetSdkVersion to ‘Q’ as soon as possible. This lets you test your app with all of the privacy and security features in Android Q, as well as any other behavior changes for apps targeting Q.
Explore the 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. Take a look at the API diff report, the Android Q Beta API reference, and developer guides as a starting point. Also, on the Android Q Beta developer site, you’ll 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 want the latest fixes for Android Q related changes, we recommend you use Android Studio 3.5 or higher.
How do I get Android Q Beta?
It’s easy – you can enroll here to get Android Q Beta updates over-the-air, on any Pixel device (and this year we’re supporting all three generations of Pixel — Pixel 3, Pixel 2, and even the original Pixel!). Downloadable system images for those devices are also available. If you don’t have a Pixel device, you can use the Android Emulator, and download the latest emulator system images via the SDK Manager in Android Studio.
We plan to update the preview system images and SDK regularly throughout the preview. We’ll have more features to share as the Beta program moves forward.
As always, your feedback is critical, so please let us know what you think — the sooner we hear from you, the more of your feedback we can integrate. When you find issues, please report them here. We have separate hotlists for filing platform issues, app compatibility issues, and third-party SDK issues.
Support and Release Notes
Two primary support channels are available to you when developing and testing with the Android Q Beta.
- Please file bugs at https://developer.android.com/preview/bug for device-specific, system, and Google App bugs.
- For issues in other apps, please contact the developer directly.
To discuss issues or ideas with other developers working with the Android Q Beta, join the android_beta community on Reddit.
Date: March 2019
Build: PPP1.180208.014 (Pixel, Pixel XL, Pixel 2, Pixel 2 XL, Pixel 3, Pixel 3 XL)
Emulator support: x86 (32/64-bit)
Security patch level: March 2019
Google Play services: 12.4.46
API diff: API 28 → Beta1
This Beta release is designed for use in compatibility testing and early development only. Please be aware of these general notes about the release:
- This release may contain various stability and performance issues on devices that may make it not suitable for daily use on phone or tablet.
- System and app performance are known to be periodically slow and janky, and devices may become occasionally unresponsive.
- Battery life may be regressed in this early release for screen-on and screen-off use cases.
- Some apps may not function normally on Beta 1. This includes Google’s apps as well as other apps.
- This early build is not Compatibility Test Suite (CTS) approved.
- This initial beta release of Android Q is available as an OTA update as well as through the Android Beta program.
Performance and battery
- System and app performance is known to be periodically slow and janky, and devices may become occasionally unresponsive. These problems may become more acute with prolonged use.
- Battery life may be regressed in this early release for screen-on and screen-off use cases.
- Launcher icon visibility – In Android Q, the All apps tray displays a launcher icon for every package installed on the device, except for the following cases:
- System apps
- Apps that don’t contain any components inside their respective manifest’s
Importantly, if an app contains code but doesn’t have a launchable activity, its icon still appears in the All apps tray. When users select this icon, they’re taken to the app’s settings screen.
Android Beta Feedback app
- Sharing a screenshot with the app directly from the system notification may result in a crash. To mitigate this, share your screenshot from the Files app.
- If using a work profile, granting the Phone permission to the app may cause uploads to fail or crash the app. To mitigate this, disable or deny the Phone permission in the app settings.
- To compile and use Android Q SDK APIs, set the following in your app’s
buildToolsVersion "29.0.0 rc1"