Google today launched Android Q Beta 1, available for download now at google.com/android/beta. The first beta includes a preview SDK for developers with system images for the Pixel, Pixel XL, Pixel 2, Pixel 2 XL, Pixel 3, Pixel 3 XL, and the official Android Emulator.
This is the fourth year running that Google has released the first developer preview of the next Android version in March — Android N (later named Android Nougat), Android O (Android Oreo), and Android P (Android Pie). For the past two years, Google did not use the Android Beta Program, which lets you get early Android builds via over-the-air updates on select devices. That changes with Android Q — Google is making the first preview available as a beta, not just as a developer preview. That signals Android Q is ready for early adopters to try, in addition to developers. As before, this preview version will be referred to as Android Q until Google picks a name starting with that letter.
In past years, Google would wait until the second developer preview before making it available on more phones, and that’s likely to stay the same. The first Android Q developer preview is, however, technically available on more phones (six Pixels as opposed to four).
With Android P, the feature that stood out the most in the first developer preview was support for notches and other screen cutouts. The same would likely have been the case for Android Q in terms of foldables, but Google unveiled native support for foldables in November.
If you want the short version, here are the first Android Q beta highlights: additional privacy and security features, enhancements for foldables, new connectivity APIs, new media codecs and camera capabilities, NNAPI extensions, Vulkan 1.1 support, and faster app startup.
Beta 1 features
Still not satisfied? Here is the longer version of all the new APIs and features (and there is more to come; this is just the first beta, after all)
- Device location: Giving users more control over when apps can get location, including when the app is not in use (in the background). Users will be able 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).
- Scoped storage: Giving more control over access to shared files. Users will be able to control apps’ access to Photos, Videos, and 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. Developers will also have to change how apps use shared areas on external storage.
- Background activity starts: Reduce interruptions like apps unexpectedly jumping into the foreground and taking over focus. Apps will be prevented from launching an Activity while in the background. Developers will still be able to get the user’s attention quickly — such as for incoming calls or alarms — with a high-priority notification or a full-screen intent.
- User data IDs: Limiting access to non-resettable device identifiers, including device IMEI, serial number, and similar identifiers. Android Q will also randomize the device’s MAC address when connected to different Wi-Fi networks by default (optional in Android 9 Pie).
- Foldables and innovative new screens: Apps will be able to take better advantage of these and other large-screen devices. Changes to onResume and onPause support multi-resume and notify your app when it has focus. The resizeableActivity manifest attribute now helps manage how your app is displayed on foldable and large screens.
- Sharing shortcuts: Faster sharing to other apps. Sharing Shortcuts, which let users jump directly into another app to share content, are getting faster. Developers can publish share targets that launch a specific activity in their apps with content attached, shown to users in the share UI instantly because they are published in advanced. Because Sharing Shortcuts is similar to how App Shortcuts works, the ShortcutInfo API now integrates both and is supported in the new ShareTarget AndroidX library (early sample app source code).
- Settings Panel: Show key system settings directly in the context of an app. The new Settings Panel API uses the Slices feature introduced in Android 9 Pie to give users a floating UI with relevant system settings (such as Wi-Fi, airplane mode, mobile data, NFC, and audio volume). There’s no need to leave the app.
- Connectivity permissions, privacy, and security: For Bluetooth, cellular, and Wi-Fi, the FINE location permission will be required. Wi-Fi standard support, WP3 and OWE, will also be included to improve security for home and work networks as well as open/public networks.
- Improved peer-to-peer and internet connectivity: The Wi-Fi stack has been refactored to improve privacy, performance, and common use-cases like managing IoT devices and suggesting internet connections. The network connection APIs will help apps initiate connection requests indirectly by specifying preferred SSIDs & BSSIDs as WiFiNetworkSpecifiers. The network suggestion APIs will let apps initiate connections indirectly by providing a ranked list of networks and credentials as WifiNetworkSuggestions. Android Q will handle the Wi-Fi scanning itself, display matching networks in a Wi-Fi Picker, and connect based on past performance when in range of those networks.
- Wi-Fi performance mode: High performance and low latency modes will let developers request adaptive Wi-Fi by calling WifiManager.WifiLock.createWifiLock() with WIFI_MODE_FULL_LOW_LATENCY or WIFI_MODE_FULL_HIGH_PERF. Google expects these to be useful for real-time gaming, active voice calls, and similar use-cases.
- Dynamic depth format for photos: 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. Requesting a JPEG + Dynamic Depth image makes it possible for developers to offer specialized blurs, bokeh options, or use the data to create 3D images and support AR photography use-cases. Dynamic Depth will be an open format for the Android ecosystem.
- New audio and video codecs: Support for the open source video codec AV1, audio encoding using Opus, and HDR10+ for high dynamic range video. The MediaCodecInfo API will help determine the video rendering capabilities of an Android device (use VideoCodecCapabilities.getSupportedPerformancePoints() to get a list of supported sizes and frame rates).
- Native MIDI API: This API lets apps that perform their audio processing in C++ communicate with MIDI devices through the NDK. It allows MIDI data to be retrieved inside an audio callback using a non-blocking read, enabling low latency processing of MIDI messages (sample app source code).
- ANGLE on Vulkan: Experimental support for ANGLE, a graphics abstraction layer designed for high-performance OpenGL compatibility, on top of Vulkan. Apps and games that use OpenGL ES will be able to take advantage of the performance and stability of Vulkan and benefit from a consistent, vendor-independent implementation of ES. Android Q will support OpenGL ES 2.0 — ES 3.0 will come next.
- Vulkan everywhere: Google is working with 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. Vulkan will thus become a uniform high-performance graphics API for apps and games to use.
- Neural Networks API 1.2: 60 new ops including ARGMAX, ARGMIN, quantized LSTM, alongside a range of performance optimisations. This will accelerate a much greater range of models — such as those for object detection and image segmentation. Google is working with hardware vendors and popular machine learning frameworks such as TensorFlow to optimize and roll out support for NNAPI 1.2.
- ART performance: Improvements to the ART runtime that help apps start faster and consume less memory. Garbage collection overall has been made more efficient in terms of time and CPU, reducing jank and helping apps run better on lower-end devices.
- BiometricPrompt has been extended to passive authentication methods such as face, plus implicit and explicit authentication flows. Google has also improved the fallback for device credentials when needed.
- TLS 1.3 support has been added and enabled by default for all TLS connections. Google says its benchmarks indicate that secure connections can be established as much as 40 percent faster with TLS 1.3 compared to TLS 1.2.
- Compatibility through public APIs: Google is restricting access to more non-SDK interfaces and asking developers to use the public equivalents instead. The restrictions are only for apps targeting Android Q, so make sure to test accordingly. Use the StrictMode method detectNonSdkApiUsage() to warn when your app accesses non-SDK APIs via reflection or JNI.
- Modern Android: Google Play will require targetSdkVersion set to 28 (Android 9 Pie) in new apps and updates later this year. 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). Also later this year, Google Play will require 64-bit support in all apps (developer guide).
Beta schedule
The goal of the first beta is to let early adopters and developers play with the build early so they can explore new features and APIs for apps, test for compatibility, and give feedback before more details are shared at I/O 2019, scheduled for May 7 to May 9. More new features and capabilities will be released in subsequent betas.
Last year, there were five developer previews (four betas). This year, Google is planning six betas in total. Here’s the preview schedule:
- March: Beta 1 (initial release, beta)
- April: Beta 2 (incremental update, beta)
- May: Beta 3 (incremental update, beta)
- June: Beta 4 (final APIs and official SDK, Play publishing, beta)
- Beta 5 (release candidate for testing)
- Beta 6 (release candidate for final testing)
- Q3: Final release to AOSP and ecosystem
Google is asking developers to make their apps compatible with Android Q so that their users can expect a seamless transition when they upgrade.
