Tag Archives: androidq

Welcoming Android 10!

Posted by Stephanie Cuthbertson, Senior Director of Product Management, Android

After more than a year of development and months of testing by early adopters, we’re ready to introduce Android 10 to the world!

android 10 logo

Android 10 is built around three important themes. First, Android 10 is shaping the leading edge of mobile innovation with advanced machine-learning and support for emerging devices like foldables and 5G enabled phones. Next, Android 10 has a central focus on privacy and security, with almost 50 features that give users greater protection, transparency, and control. Finally, Android 10 expands users' digital wellbeing controls so individuals and families can find a better balance with technology.

Today we're releasing the Android 10 source code to Android Open Source Project (AOSP) and making it available to the broader ecosystem. We’re also starting the official Android 10 rollout to all three generations of Pixel devices worldwide. Many partner devices, including those in the Beta program, will receive the update by the end of the year.

Thank you for your support during this year’s Beta -- more than 200,000 of you tested early releases on 26 different Beta devices, reporting 20,000 unique issues. That’s on top of the many articles, discussions, surveys, and in-person meetings where you voiced your thoughts, and the work you did to make your apps compatible by today’s release. Your support and engagement are what make Android such an amazing platform. Together with our OEM partners you’ve created more excitement for this Android release than we’ve ever had. In fact, Android 10 will be available on more devices than any other previous release. Android is fortunate to have such a passionate community!

To get started developing for Android 10, visit developer.android.com/10.

What’s in Android 10?

Here’s a look at what’s in Android 10 and how you can use it today. Make sure to check out our Keyword blog for more too!

Innovation and new experiences

With Android 10 you can take advantage of the latest hardware and software innovations to build amazing app experiences for users.

Foldables - Building on robust multi-window support, Android 10 extends multitasking across app windows and provides screen continuity to maintain your app state as the device folds or unfolds. For details on how to optimize your apps for foldables, see the developer guide.

5G networks promise to deliver consistently faster speeds and lower latency, and Android 10 adds platform support for 5G and extends existing APIs to help you take advantage of these enhancements. You can use connectivity APIs to detect if the device has a high bandwidth connection and check whether the connection is metered. With these, your apps and games can tailor rich, immersive experiences to users over 5G.

Live Caption automatically captions media playing on users’ devices, from videos to podcasts and audio messages, across any app. The ML speech models run right on the phone, and no audio stream ever leaves the device. For developers, Live Caption is optional, but expands the audience for your apps and games by making your content more accessible with a single tap. Live Caption is coming to Pixel devices this fall, and we’re working closely with our partners to launch it broadly on devices running Android 10.

Smart Reply in notifications - Android 10 uses on-device ML to suggest contextual actions in notifications, such as smart replies for messages or opening a map for an address in the notification. We’ve built this feature with user privacy in mind, keeping the ML processing completely on the device. Your apps can take advantage of this feature right away, or you can opt-out if you’d rather generate your own suggestions.

mobile displaying Smart Reply notification

Smart Reply can suggest actions based on notification content.

Dark theme - Android 10 adds a system-wide dark theme that’s ideal for low light and helps save battery. You can build a custom dark theme for your app or let the system create one dynamically from your current theme. See the developer guide for details.

Dark theme to do lists

Dark theme in Google Keep

Gesture navigation - Android 10 introduces a fully gesture navigation mode that eliminates the navigation bar area and allows apps to use the full screen to deliver richer, more immersive experiences. Get started optimizing your app today.

gesture gif displaying closing of full screen map to display dinner with Layla in 30 min

Gesture navigation gives apps the full screen for content

Privacy for users

Privacy is a central focus in Android 10, from stronger protections in the platform to new features designed with privacy in mind. Building on previous releases, Android 10 includes extensive changes to protect privacy and give users control, with improved system UI, stricter permissions, and restrictions on what data apps can use. See the Android 10 developer site for details on how to support these in your apps.

Giving users more control over location data - Users have more control over their location data through a new permission option -- they can now allow an app to access location only while the app is actually in use (running in the foreground). For most apps this provides a sufficient level of access, while for users it’s a big improvement in transparency and control. To learn more about location changes, see the developer guide or our blog post.

notification displaying: Allow app 1 to access the device's location.

Protecting location data in network scans - Most of the APIs for scanning networks already required the coarse location permission. Android 10 increases the protection around those APIs by requiring the fine location permission instead.

Preventing device tracking - Apps can no longer access non-resettable device identifiers that could be used for tracking, including device IMEI, serial number, and similar identifiers. The device's MAC address is also randomized when connected to Wi-Fi networks by default. Read the best practices to help you choose the right identifiers for your use case, and see the details here.

Securing user data in external storage - Android 10 introduces a number of changes to give users more control over files in external storage and the app data within them. Apps can store their own files in their private sandboxes, but must use MediaStore to access shared media files and use the system file picker to access shared files in the new Downloads collection. Learn more here.

Blocking unwanted interruptions - Android 10 prevents app launches from the background that unexpectedly jump into the foreground and take over focus from another app. Learn more here.

Security

On Android we’re always working to assess our ongoing security investments; we refer to this as measurable security. One way we measure our ongoing investments is through third party analyst research such as Gartner’s May 2019 Mobile OSs and Device Security: A Comparison of Platforms report (subscription required) which scored Android the highest possible rating in 26 out of 30 categories, ahead on multiple points from authentication to network security and malware protection. Read more about our long-term work on Security in Quantifying Measurable Security. But there is no finish line when it comes to Security. In Android 10, we’ve introduced even more features to keep users secure through advances in encryption, platform hardening, and authentication.

Storage encryption - All compatible devices launching with Android 10 are required to encrypt user data, and to make this more efficient, Android 10 includes Adiantum, our new encryption mode.

TLS 1.3 by default - Android 10 also enables TLS 1.3 by default, a major revision to the TLS standard with performance benefits and enhanced security.

Platform hardening - Android 10 also includes hardening for several security-critical areas of the platform, and updates to the BiometricPrompt framework with robust support for face and fingerprint in both implicit and explicit authentication. Read more about Android 10 security updates here.

Camera and media

Dynamic depth for photos - Apps can now 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. These let you offer specialized blurs and bokeh options in your app. Dynamic Depth is an open format for the ecosystem and we're working with our partners to bring it to devices running Android 10 and later.

image of a shaggy dog's profile with patio furniture in the background image of a shaggy dog's profile with patio furniture blurred out in the background. image of a shaggy dog's profile in grayscale and blurred out

With Dynamic Depth image you can offer specialized blurs and bokeh options in your app

Audio playback capture - Now any app that plays audio can let other apps capture its audio stream using a new audio playback capture API. In addition to enabling captioning and subtitles, the API lets you support popular use-cases like live-streaming games. We’ve built this new capability with privacy and copyright protection in mind, so the ability for an app to capture another app's audio is constrained. Read more in our blog post.

New audio and video codecs - Android 10 adds support for the open source video codec AV1, which allows media providers to stream high quality video content to Android devices using less bandwidth. In addition, Android 10 supports audio encoding using Opus - an open, royalty-free codec optimized for speech and music streaming, and HDR10+ for high dynamic range video on devices that support it.

Native MIDI API - For apps that perform their audio processing in C++, Android 10 introduces a native MIDI API to 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.

Vulkan everywhere - Vulkan 1.1 is now a requirement on all 64-bit devices running Android 10 and higher, and a recommendation for all 32-bit devices. We already see significant momentum on Vulkan support in the ecosystem - among devices running Android N or above, over half support Vulkan 1.0.3 or better. With the new requirement in Android 10, we expect to see adoption rise even further in the coming year.

Connectivity

Improved peer-to-peer and internet connectivity - We’ve refactored the Wi-Fi stack to improve privacy and performance, and 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. The network suggestion APIs let apps surface preferred Wi-Fi networks to the user for internet connectivity.

Wi-Fi performance modes - Apps can now request adaptive Wi-Fi by enabling high performance and low latency modes. These can be a great benefit where low latency is important to the user experience, such as real-time gaming, active voice calls, and similar use-cases. The platform works with the device firmware to meet the requirement with the lowest power consumption.

Android foundations

ART optimizations - Improvements in the ART runtime help your apps start faster, consume less memory, and run smoother -- without requiring any work from you. ART profiles delivered by Google Play let ART pre-compile parts of your app even before it's run. At runtime, Generational Garbage Collection makes garbage collection more efficient in terms of time and CPU, reduces jank, and helps apps run better on lower-end devices.

Startup time improvement - Profiles in Play bar chart

This chart shows the percentage improvement in startup time for specific apps when tested using Play profiles.

Neural Networks API 1.2 - We’ve added 60 new operations including ARGMAX, ARGMIN, quantized LSTM, alongside a range of performance optimizations. This lays the foundation for accelerating a much greater 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 roll out support for NNAPI 1.2.

Faster updates, fresher code

With Android 10 we’re continuing our focus on bringing the new platform to devices more rapidly, working closely with our device-makers and silicon partners like Qualcomm. Project Treble has played a key role, helping us bring 18 partner devices into this year’s Beta program along with 8 Pixel devices -- more than double the number from last year. Even better, we expect those devices to get the official Android 10 update by the end of this year, and we’re working with several partners on other new flagship launches and updates. We’re seeing great momentum with Android 10 already, and more devices than any other previous Android release will be getting this new version in the months ahead.

Android 10 is also the first release to support Project Mainline (officially called Google Play system updates), our new technology for securing Android users and keeping their devices fresh with important code changes - direct from Google Play. With Google Play system updates, we’re able to update specific internal components across all devices running Android 10 and higher, without requiring a full system update from the device manufacturer. We’re expecting to bring the first updates to consumer devices over the next several months.

For developers, we expect these updates in Android 10 to help drive consistency of platform implementation broadly across devices, and over time bring greater uniformity that will reduce your development and testing costs.

Get your apps ready for Android 10!

Now with today’s public release of Android 10 and updates coming soon to devices, we’re asking all Android developers to update your current apps for compatibility as soon as possible to give your users a smooth transition to Android 10.

Here’s how to do it:

  • Install your app on Android 10: Install your current app from Google Play onto a Pixel or other device running Android 10 or an emulator, then test. Your app should look great and run well, with full functionality, and handle all of the Android 10 behavior changes properly. Watch for impacts from privacy changes, gesture navigation, changes to dynamic linker paths for Bionic libraries, and others.
  • Test with the Android 10 privacy features, such as the new location permissions, scoped storage, restrictions on background activity starts, changes to data and identifiers, and others. See the checklist of top privacy changes to get started, and review the privacy changes doc for more areas to test.
  • Test for uses of restricted non-SDK interfaces and move to public SDK or NDK equivalents instead. Details here.
  • Test the libraries and SDKs in your app: If you find an issue, try updating to the latest version of the SDK, or reach out to the SDK developer for help.
  • Update and publish your compatible app: When you’ve finished your testing and made any updates, we recommend publishing your compatible app right away. This helps you deliver a smooth transition to users as they update to Android 10.

Getting apps tested and ready for the new version of Android is crucial to faster platform updates throughout the ecosystem, so please prioritize this work if possible.

Enhance your app with Android 10 features and APIs

Next, when you're ready, dive into Android 10 and learn about the new features and APIs that you can use. Here are some of the top features to get started with.

We recommend these for every app:

  • Dark Theme: Ensure a consistent experience for users who enable system-wide dark theme by adding a Dark Theme or enabling Force Dark.
  • Gesture navigation: Support gesture navigation in your app by going edge-to-edge and making sure your custom gestures are complementary to the system navigation gestures.
  • Optimize for foldables: Deliver seamless experiences on today’s innovative devices by optimizing for foldables.

We recommend these if relevant for your app:

  • More interactive notifications: If your notifications include messages, enable Smart Reply in notifications to engage users and let them take action instantly.
  • Better biometrics: If you use biometric auth, move to BiometricPrompt, the preferred way to support fingerprint auth on modern devices.
  • Audio playback capture: To support captioning or gameplay recording, enable audio playback capture in your app -- it’s a great way to reach more users and make your app more accessible.
  • Better codecs: For media apps, try AV1 for video streaming and HDR10+ for high dynamic range video. For speech and music streaming, you can use Opus encoding, and for musicians, a native MIDI API is available.
  • Better networking APIs: If your app manages IoT devices over Wi-Fi, try the new network connection APIs for functions like configuring, downloading, or printing.

To read about all of the new features and changes, visit the Android 10 developer site.

To get started developing, download the official API 29 SDK and tools into Android Studio 3.5 or higher. Then follow these instructions to configure your environment.

Coming to a device near you!

Android 10 will begin rolling out today to the three generations of Pixel phones -- Pixel 3 (and 3a), Pixel 2, and even the original Pixel! All Pixel devices will get the update over the next week, including those enrolled in this year’s Beta program. If you own a Pixel device, watch for your official over-the-air update coming soon!

As always, the system images for Pixel devices are available here for manual download and flash, and you can get the latest Android Emulator system images via the SDK Manager in Android Studio. For broader testing on other Treble-compliant devices, Generic System Images (GSI) are available here.

If you're looking for the Android 10 source, you'll find it here in the Android Open Source Project repository under the Android 10 branches.

What’s next?

We'll soon be closing the Android Beta issue tracker and Feedback app, but please keep the feedback coming! You can file a new issue against Android 10 in the AOSP issue tracker.

Thanks again to the many developers and early adopters who participated in the Android Beta program this year! You gave us great feedback, and filed thousands of issues that helped us to make the Android 10 platform great for consumers and developers.

We're looking forward to seeing your apps on Android 10!

Android Q Beta 5 Update

Posted by Dave Burke, VP of Engineering

AndroidQ logo

Android Q Beta 5 launches today! Today we're rolling out Beta 5, bringing Android Q Beta very close to the system behaviors you'll see in the final release. Developer APIs were already finalized in the previous update. So, now is the time to test your apps for compatibility and make sure they are ready!

You can get Beta 5 today on Pixel devices by enrolling here. If you're already enrolled and received Beta 4 on your Pixel device, you'll automatically get the update to Beta 5. Partners participating in the Android Q Beta program will also be updating their devices to Beta 5 over the coming weeks.

To get started with Android Q Beta, visit developer.android.com/preview.

What’s in Beta 5?

The Beta 5 update includes the latest Android Q system images for Pixel and Android jEmulator, along with the final Android Q developer APIs (API level 29), the official API 29 SDK, and updated build tools for Android Studio. These give you everything you need to test your apps on Android Q and build with Android Q features.

Gestural navigation updates

As we talked about at Google I/O, we’ve been working closely with device-maker partners to ensure a standardized Android gestural navigation for users and developers. Gestural navigation lets apps use the full screen for content while minimizing the visible system chrome and navigation – which is particularly important on today’s edge-to-edge screens. In Beta 5 we’re continuing to improve and polish based on your feedback and we wanted to provide an update on a few key areas.

We’ve introduced a swipe gesture from either corner to get to the Assistant - you’ll notice indicators in the bottom corners that we’re continuing to tune.

For apps using a navigation drawer, we’ve added a peek behavior when users have grabbed the drawer to indicate that a swipe will bring in the navigation drawer. This works for all versions of DrawerLayout, with DrawerLayout 1.1.0-alpha02 optimized for the best experience.

Custom launchers are another area where we’ve heard feedback and we’re continuing to work on issues, particularly with stability and Recents. Starting in Beta 6, we’ll switch users to 3-button navigation when they are using a custom launcher by default. We’ll address the remaining issues in a post-launch update allowing all users to switch to gestural navigation. Meanwhile, please continue to give us your feedback.

Get your apps ready for Android Q!

With the consumer release coming soon, it’s highest priority for all Android developers to update your current apps for compatibility as soon as possible.

Here’s how to do it:

We realize that supporting these changes is an investment for you too, and we're working to minimize the impact on your apps and be responsive to your input as we move toward the final release.

Enhance your app with Android Q features and APIs

Next, when you're ready, dive into Android Q and learn about the new features and APIs that you can use. Here are some of the top features to get started with.

We recommend these for every app:

  • Dark Theme: Ensure a consistent experience for users who enable system-wide dark theme by adding a Dark Theme or enabling Force Dark.
  • Support gestural navigation in your app by going edge-to-edge and making sure your custom gestures are complementary to the system navigation gestures.
  • Optimize for foldables: Deliver seamless, edge-to-edge experiences on today’s innovative devices by optimizing for foldables.

We recommend these if relevant for your app:

  • More interactive notifications: If your notifications include messages, enable suggested replies and actions in notifications to engage users and let them take action instantly.
  • Better biometrics: If you use biometric auth, move to BiometricPrompt, the preferred way to support fingerprint auth on modern devices.
  • Enriched recording: To support captioning or gameplay recording, enable audio playback capture -- it’s a great way to reach more users and make your app more accessible.
  • Better codecs: For media apps, try AV1 for video streaming and HDR10+ for high dynamic range video. For speech and music streaming, you can use Opus encoding, and for musicians, a native MIDI API is available.
  • Better networking APIs: If your app manages IoT devices over Wi-Fi, try the new network connection APIs for functions like configuring, downloading, or printing.

These are just a few of the many new features and APIs in Android Q -- to see them all, visit the Android Q Beta site for developers.

Publish your app updates to Google Play

As soon as you're ready, publish your APK updates to Google Play that are compiled against, or optionally targeting, API 29. To make sure that your updated app runs well on Android Q as well as older versions, try using Google Play testing tracks. With tracks you can safely get early feedback from a small group of users -- including Beta 5 users — and then do a staged rollout to production.

How do I get Beta 5?

It’s easy! Just enroll any supported Pixel device here to get the update over-the-air. If you're already enrolled, you'll receive the update soon and no action is needed on your part. Downloadable system images are also available here. Partners who are participating in the Android Q Beta program will be updating their devices over the coming weeks. See android.com/beta for details.

To get started developing, download the official API 29 SDK and tools into the stable release of Android Studio 3.4, or for the latest Android Q support update to Android Studio 3.5 Beta. Then follow these instructions to configure your environment, and see the release notes for known issues.

There will be one more Beta release before the consumer launch later this quarter. Please continue to share your feedback and requests -- you can use our hotlists for filing platform issues (including privacy and behavior changes), app compatibility issues, and third-party SDK issues.

Also, the Android engineering team will host a Reddit AMA on r/androiddev to answer your technical questions about Android Q later this month. Look out for an announcement on r/androiddev with details in the coming weeks. We look forward to addressing your questions!

Android Q Beta 4 and Final APIs!

Posted by Dave Burke, VP of Engineering

AndroidQ logo

Last month at Google I/O we talked about what’s new for Android developers, from new features in Android Q to the latest in Kotlin and Jetpack.

With Android Q, we highlighted three themes: innovation, security and privacy, and digital wellbeing. We want to help you take advantage of the latest new technology -- 5G, foldables, edge-to-edge screens, on-device machine learning, and more -- while making sure users' security, privacy, and wellbeing are always a top priority.

We also talked about how we’re going increasingly Kotlin-first, and continuing to expand Jetpack with new libraries like CameraX, Jetpack Security and Jetpack Compose -- a modern reactive-style UI toolkit for Android that takes advantage of Kotlin. If you missed the livestream for the keynotes or tech sessions, make sure to check out the full playlist of Android and Play sessions.

Today we’re releasing Beta 4 with the final Android Q APIs and official SDK -- the time is now to get your apps ready for the final release later in the summer!

You can get Beta 4 today on Pixel devices by enrolling here. If you're already enrolled and received the Beta 3 on your Pixel device, you'll automatically get the update to Beta 4. Partners participating in the Android Q Beta program will also be updating their devices to Beta 4 over the coming weeks.

To get started with Android Q Beta, visit developer.android.com/preview.

What’s in Beta 4?

The Beta 4 update includes the latest Android Q system images for Pixel and Android Emulator, along with the final Android Q developer APIs (API level 29), the official API 29 SDK, and updated build tools for Android Studio. Together, these give you everything you need to test your apps for compatibility with Android Q and build with Android Q features and APIs.

To get started, download the official API 29 SDK and tools into the stable release of Android Studio 3.4, or for the latest Android Q support update to Android Studio 3.5 Beta. Then follow these instructions to configure your environment, and see the release notes for known issues.

Make your apps compatible with Android Q!

With the developer APIs finalized and release candidate builds coming soon, it’s critical for all Android developers to test their current apps for compatibility with Android Q. We recommend getting started as soon as possible.

Just install your current app from Google Play onto an Android Q Beta device or emulator, then test. As you work through the flows, your app should run and look great and handle all of the Android Q behavior changes properly. Watch for impacts from privacy changes, gestural navigation, changes to dynamic linker paths for Bionic libraries, and others.

Make sure that you test with the Android Q privacy features, such as the new location permissions, restrictions on background activity starts, changes to data and identifiers, and other key privacy features. See the privacy checklist to get started, and review the behavior changes doc for more areas to test.

Android Developers YouTube channel UI on landscape mode.

You can use the updated Android Emulator to test your apps for compatibility.

If you plan to update your platform targeting to API 29, also make sure to test with scoped storage, location permission for wireless scans, and permission for fullscreen intents. You can read about other changes that could affect apps here.

It's also important to test for uses of restricted non-SDK interfaces and move to public SDK or NDK equivalents instead. Watch for logcat warnings that highlight these accesses and use the StrictMode method detectNonSdkApiUsage() to catch them programmatically.

Last, make sure to fully test the libraries and SDKs in your app to make sure they work as expected on Android Q and follow best practices for privacy, performance, UX, data handling, and permissions. If you find an issue, try updating to the latest version of the SDK, or reach out to the SDK developer for help. You can also report SDK compatibility issues here.

When you’ve finished your testing and made any updates, we recommend publishing your compatible app right away. This lets Android Beta users test the app now, and helps you deliver a smooth transition to users as they update to Android Q.

We realize that supporting these changes is an investment for you too, and we're working to minimize the impact on your apps and be responsive to your input as we move toward the final release in the coming months.

Enhance your app with Android Q features and APIs

When you're ready, dive into Android Q and learn about the new features and APIs that you can use in your apps. Android Q features can help you engage users, give them more control and security, and even improve your app's performance.

mobile device notification window

Android Q provides system-suggested replies and actions in notifications.

For example, you can deliver seamless, edge-to-edge experiences on today’s innovative devices by optimizing for foldables and supporting gestural navigation in your app. To engage more users, try supporting Dark Theme, suggested replies and actions in notifications, sharing shortcuts, and settings panels.

Google Maps app closes to display home screen with ocean aerial image

Gestural navigation lets you offer an edge-to-edge experience in your apps.

If your app manages IoT devices over Wi-Fi, try the new network connection APIs for functions like configuring, downloading, or printing. If your app manages Wi-Fi internet connections, try the network suggestion APIs as an easier way to surface preferred Wi-Fi networks, without needing to request location permission.

If you use the camera, learn about dynamic depth format. For media, you can use AV1 for video streaming and HDR10+ for high dynamic range video. For speech and music streaming, you can use Opus encoding, and for musicians, a native MIDI API is available.

Dynamic Depth lets you offer specialized blurs and bokeh options in your app.

To support captioning or gameplay recording, enable audio playback capture -- it’s a great way to reach more users and get your app noticed. If your app uses power intensively, try using the new thermal API to optimize app performance based on device temperature.

BiometricPrompt is now the preferred way to support fingerprint auth on modern devices, so all developers using fingerprint or other biometric auth should move to using this API as soon as possible. To make the transition easy, use the backwards-compatible BiometricPrompt API that we’re providing in the AndroidX library. Android Q supports both standard and passive (no confirmation, for face and other passive modes) auth flows.

These are just a few of the many new features and APIs in Android Q -- to see them all, visit the Android Q Beta site for developers.

Publish your app updates to Google Play

Today with Android Q Beta 4 we’re also opening up publishing on Google Play to apps that are compiled against, or optionally targeting, API 29. This means you can now push your updates to users now through Google Play to test your app’s compatibility, including on devices running Android Q Beta 4.

How do I get Beta 4?

It’s easy! Just enroll any supported Pixel device here to get the update over-the-air. If you're already enrolled, you'll receive the update soon and no action is needed on your part. Downloadable system images are also available here. Partners that are participating in the Android Q Beta program will be updating their devices over the coming weeks. See android.com/beta for details.

For even broader testing on supported devices, you can also get Android GSI images, and if you don’t have a device you can test on the Android Emulator.

As always, your input is critical, so please continue to let us know what you think. You can use our hotlists for filing platform issues (including privacy and behavior changes), app compatibility issues, and third-party SDK issues. You've shared great feedback with us so far and we're working to integrate as much of it as possible in the next Beta release.

We're looking forward to seeing your apps on Android Q!

What’s New in Android Q Security

Posted by Rene Mayrhofer and Xiaowen Xin, Android Security & Privacy Team

With every new version of Android, one of our top priorities is raising the bar for security. Over the last few years, these improvements have led to measurable progress across the ecosystem, and 2018 was no different.

In the 4th quarter of 2018, we had 84% more devices receiving a security update than in the same quarter the prior year. At the same time, no critical security vulnerabilities affecting the Android platform were publicly disclosed without a security update or mitigation available in 2018, and we saw a 20% year-over-year decline in the proportion of devices that installed a Potentially Harmful App. In the spirit of transparency, we released this data and more in our Android Security & Privacy 2018 Year In Review.

But now you may be asking, what’s next?

Today at Google I/O we lifted the curtain on all the new security features being integrated into Android Q. We plan to go deeper on each feature in the coming weeks and months, but first wanted to share a quick summary of all the security goodness we’re adding to the platform.

Encryption

Storage encryption is one of the most fundamental (and effective) security technologies, but current encryption standards require devices have cryptographic acceleration hardware. Because of this requirement many devices are not capable of using storage encryption. The launch of Adiantum changes that in the Android Q release. We announced Adiantum in February. Adiantum is designed to run efficiently without specialized hardware, and can work across everything from smart watches to internet-connected medical devices.

Our commitment to the importance of encryption continues with the Android Q release. All compatible Android devices newly launching with Android Q are required to encrypt user data, with no exceptions. This includes phones, tablets, televisions, and automotive devices. This will ensure the next generation of devices are more secure than their predecessors, and allow the next billion people coming online for the first time to do so safely.

However, storage encryption is just one half of the picture, which is why we are also enabling TLS 1.3 support by default in Android Q. TLS 1.3 is a major revision to the TLS standard finalized by the IETF in August 2018. It is faster, more secure, and more private. TLS 1.3 can often complete the handshake in fewer roundtrips, making the connection time up to 40% faster for those sessions. From a security perspective, TLS 1.3 removes support for weaker cryptographic algorithms, as well as some insecure or obsolete features. It uses a newly-designed handshake which fixes several weaknesses in TLS 1.2. The new protocol is cleaner, less error prone, and more resilient to key compromise. Finally, from a privacy perspective, TLS 1.3 encrypts more of the handshake to better protect the identities of the participating parties.

Platform Hardening

Android utilizes a strategy of defense-in-depth to ensure that individual implementation bugs are insufficient for bypassing our security systems. We apply process isolation, attack surface reduction, architectural decomposition, and exploit mitigations to render vulnerabilities more difficult or impossible to exploit, and to increase the number of vulnerabilities needed by an attacker to achieve their goals.

In Android Q, we have applied these strategies to security critical areas such as media, Bluetooth, and the kernel. We describe these improvements more extensively in a separate blog post, but some highlights include:

  • A constrained sandbox for software codecs.
  • Increased production use of sanitizers to mitigate entire classes of vulnerabilities in components that process untrusted content.
  • Shadow Call Stack, which provides backward-edge Control Flow Integrity (CFI) and complements the forward-edge protection provided by LLVM’s CFI.
  • Protecting Address Space Layout Randomization (ASLR) against leaks using eXecute-Only Memory (XOM).
  • Introduction of Scudo hardened allocator which makes a number of heap related vulnerabilities more difficult to exploit.

Authentication

Android Pie introduced the BiometricPrompt API to help apps utilize biometrics, including face, fingerprint, and iris. Since the launch, we’ve seen a lot of apps embrace the new API, and now with Android Q, we’ve updated the underlying framework with robust support for face and fingerprint. Additionally, we expanded the API to support additional use-cases, including both implicit and explicit authentication.

In the explicit flow, the user must perform an action to proceed, such as tap their finger to the fingerprint sensor. If they’re using face or iris to authenticate, then the user must click an additional button to proceed. The explicit flow is the default flow and should be used for all high-value transactions such as payments.

Implicit flow does not require an additional user action. It is used to provide a lighter-weight, more seamless experience for transactions that are readily and easily reversible, such as sign-in and autofill.

Another handy new feature in BiometricPrompt is the ability to check if a device supports biometric authentication prior to invoking BiometricPrompt. This is useful when the app wants to show an “enable biometric sign-in” or similar item in their sign-in page or in-app settings menu. To support this, we’ve added a new BiometricManager class. You can now call the canAuthenticate() method in it to determine whether the device supports biometric authentication and whether the user is enrolled.

What’s Next?

Beyond Android Q, we are looking to add Electronic ID support for mobile apps, so that your phone can be used as an ID, such as a driver’s license. Apps such as these have a lot of security requirements and involves integration between the client application on the holder’s mobile phone, a reader/verifier device, and issuing authority backend systems used for license issuance, updates, and revocation.

This initiative requires expertise around cryptography and standardization from the ISO and is being led by the Android Security and Privacy team. We will be providing APIs and a reference implementation of HALs for Android devices in order to ensure the platform provides the building blocks for similar security and privacy sensitive applications. You can expect to hear more updates from us on Electronic ID support in the near future.

Queue the Hardening Enhancements

Posted by Jeff Vander Stoep, Android Security & Privacy Team and Chong Zhang, Android Media Team

Android Q Beta versions are now publicly available. Among the various new features introduced in Android Q are some important security hardening changes. While exciting new security features are added in each Android release, hardening generally refers to security improvements made to existing components.

When prioritizing platform hardening, we analyze data from a number of sources including our vulnerability rewards program (VRP). Past security issues provide useful insight into which components can use additional hardening. Android publishes monthly security bulletins which include fixes for all the high/critical severity vulnerabilities in the Android Open Source Project (AOSP) reported through our VRP. While fixing vulnerabilities is necessary, we also get a lot of value from the metadata - analysis on the location and class of vulnerabilities. With this insight we can apply the following strategies to our existing components:

  • Contain: isolating and de-privileging components, particularly ones that handle untrusted content. This includes:
    • Access control: adding permission checks, increasing the granularity of permission checks, or switching to safer defaults (for example, default deny).
    • Attack surface reduction: reducing the number of entry/exit points (i.e. principle of least privilege).
    • Architectural decomposition: breaking privileged processes into less privileged components and applying attack surface reduction.
  • Mitigate: Assume vulnerabilities exist and actively defend against classes of vulnerabilities or common exploitation techniques.

Here’s a look at high severity vulnerabilities by component and cause from 2018:

Most of Android’s vulnerabilities occur in the media and bluetooth components. Use-after-free (UAF), integer overflows, and out of bounds (OOB) reads/writes comprise 90% of vulnerabilities with OOB being the most common.

A Constrained Sandbox for Software Codecs

In Android Q, we moved software codecs out of the main mediacodec service into a constrained sandbox. This is a big step forward in our effort to improve security by isolating various media components into less privileged sandboxes. As Mark Brand of Project Zero points out in his Return To Libstagefright blog post, constrained sandboxes are not where an attacker wants to end up. In 2018, approximately 80% of the critical/high severity vulnerabilities in media components occurred in software codecs, meaning further isolating them is a big improvement. Due to the increased protection provided by the new mediaswcodec sandbox, these same vulnerabilities will receive a lower severity based on Android’s severity guidelines.

The following figure shows an overview of the evolution of media services layout in the recent Android releases.

  • Prior to N, media services are all inside one monolithic mediaserver process, and the extractors run inside the client.
  • In N, we delivered a major security re-architect, where a number of lower-level media services are spun off into individual service processes with reduced privilege sandboxes. Extractors are moved into server side, and put into a constrained sandbox. Only a couple of higher-level functionalities remained in mediaserver itself.
  • In O, the services are “treblized,” and further deprivileged that is, separated into individual sandboxes and converted into HALs. The media.codec service became a HAL while still hosting both software and hardware codec implementations.
  • In Q, the software codecs are extracted from the media.codec process, and moved back to system side. It becomes a system service that exposes the codec HAL interface. Selinux policy and seccomp filters are further tightened up for this process. In particular, while the previous mediacodec process had access to device drivers for hardware accelerated codecs, the software codec process has no access to device drivers.

With this move, we now have the two primary sources for media vulnerabilities tightly sandboxed within constrained processes. Software codecs are similar to extractors in that they both have extensive code parsing bitstreams from untrusted sources. Once a vulnerability is identified in the source code, it can be triggered by sending a crafted media file to media APIs (such as MediaExtractor or MediaCodec). Sandboxing these two services allows us to reduce the severity of potential security vulnerabilities without compromising performance.

In addition to constraining riskier codecs, a lot of work has also gone into preventing common types of vulnerabilities.

Bound Sanitizer

Incorrect or missing memory bounds checking on arrays account for about 34% of Android’s userspace vulnerabilities. In cases where the array size is known at compile time, LLVM’s bound sanitizer (BoundSan) can automatically instrument arrays to prevent overflows and fail safely.

BoundSan instrumentation

BoundSan is enabled in 11 media codecs and throughout the Bluetooth stack for Android Q. By optimizing away a number of unnecessary checks the performance overhead was reduced to less than 1%. BoundSan has already found/prevented potential vulnerabilities in codecs and Bluetooth.

More integer sanitizer in more places

Android pioneered the production use of sanitizers in Android Nougat when we first started rolling out integer sanization (IntSan) in the media frameworks. This work has continued with each release and has been very successful in preventing otherwise exploitable vulnerabilities. For example, new IntSan coverage in Android Pie mitigated 11 critical vulnerabilities. Enabling IntSan is challenging because overflows are generally benign and unsigned integer overflows are well defined and sometimes intentional. This is quite different from the bound sanitizer where OOB reads/writes are always unintended and often exploitable. Enabling Intsan has been a multi year project, but with Q we have fully enabled it across the media frameworks with the inclusion of 11 more codecs.

IntSan Instrumentation

IntSan works by instrumenting arithmetic operations to abort when an overflow occurs. This instrumentation can have an impact on performance, so evaluating the impact on CPU usage is necessary. In cases where performance impact was too high, we identified hot functions and individually disabled IntSan on those functions after manually reviewing them for integer safety.

BoundSan and IntSan are considered strong mitigations because (where applied) they prevent the root cause of memory safety vulnerabilities. The class of mitigations described next target common exploitation techniques. These mitigations are considered to be probabilistic because they make exploitation more difficult by limiting how a vulnerability may be used.

Shadow Call Stack

LLVM’s Control Flow Integrity (CFI) was enabled in the media frameworks, Bluetooth, and NFC in Android Pie. CFI makes code reuse attacks more difficult by protecting the forward-edges of the call graph, such as function pointers and virtual functions. Android Q uses LLVM’s Shadow Call Stack (SCS) to protect return addresses, protecting the backwards-edge of control flow graph. SCS accomplishes this by storing return addresses in a separate shadow stack which is protected from leakage by storing its location in the x18 register, which is now reserved by the compiler.

SCS Instrumentation

SCS has negligible performance overhead and a small memory increase due to the separate stack. In Android Q, SCS has been turned on in portions of the Bluetooth stack and is also available for the kernel. We’ll share more on that in an upcoming post.

eXecute-Only Memory

Like SCS, eXecute-Only Memory (XOM) aims at making common exploitation techniques more expensive. It does so by strengthening the protections already provided by address space layout randomization (ASLR) which in turn makes code reuse attacks more difficult by requiring attackers to first leak the location of the code they intend to reuse. This often means that an attacker now needs two vulnerabilities, a read primitive and a write primitive, where previously just a write primitive was necessary in order to achieve their goals. XOM protects against leaks (memory disclosures of code segments) by making code unreadable. Attempts to read execute-only code results in the process aborting safely.

Tombstone from a XOM abort

Starting in Android Q, platform-provided AArch64 code segments in binaries and libraries are loaded as execute-only. Not all devices will immediately receive the benefit as this enforcement has hardware dependencies (ARMv8.2+) and kernel dependencies (Linux 4.9+, CONFIG_ARM64_UAO). For apps with a targetSdkVersion lower than Q, Android’s zygote process will relax the protection in order to avoid potential app breakage, but 64 bit system processes (for example, mediaextractor, init, vold, etc.) are protected. XOM protections are applied at compile-time and have no memory or CPU overhead.

Scudo Hardened Allocator

Scudo is a dynamic heap allocator designed to be resilient against heap related vulnerabilities such as:

  • Use-after-frees: by quarantining freed blocks.
  • Double-frees: by tracking chunk states.
  • Buffer overflows: by check summing headers.
  • Heap sprays and layout manipulation: by improved randomization.

Scudo does not prevent exploitation but rather proactively manages memory in a way to make exploitation more difficult. It is configurable on a per-process basis depending on performance requirements. Scudo is enabled in extractors and codecs in the media frameworks.

Tombstone from Scudo aborts

Contributing security improvements to Open Source

AOSP makes use of a number of Open Source Projects to build and secure Android. Google is actively contributing back to these projects in a number of security critical areas:

Thank you to Ivan Lozano, Kevin Deus, Kostya Kortchinsky, Kostya Serebryany, and Mike Logan for their contributions to this post.

Google I/O 2019: Empowering developers to build the best experiences on Android + Play

Posted by Chet Haase

It's great to be in our backyard again for Google I/O to connect with Android’s developers around the world. The 7,200 attendees at Shoreline Amphitheatre, millions of viewers on the livestream, and thousand of developers at local I/O Extended events across 80+ countries heard about our efforts to make the lives of developers easier. Today at Google I/O, we talked about two big themes; helping our developers become more productive and strengthening user privacy and security in the platform. Let's take a closer look at the major developer news at I/O so far:

Developer Productivity

This year, we focused on a simple idea - we want to save you time every today. By making everything you use even better.

Kotlin

Two years ago, we announced Kotlin was a supported language for Android. Our top developers loved it already, and since then, it’s amazing how fast it’s grown. Over 50% of professional Android developers now use Kotlin, it’s been one of the most-loved languages two years running on Stack Overflow, and one of the fastest-growing on GitHub in number of contributors.

Today we’re announcing another big step: Android development will become increasingly Kotlin-first. Many new Jetpack APIs and features will be offered first in Kotlin. If you’re starting a new project, you should write it in Kotlin; code written in Kotlin often mean much less code for you–less code to type, test, and maintain. And, in partnership with Jetbrains and the Kotlin Foundation, we’re continuing to invest in tooling, docs, trainings and events to make Kotlin even easier to learn and use. This includes Kotlin/Everywhere, a new, global series of events where you can learn more about the language, new Udacity courses, and more.

Android Jetpack

Last year, we announced Android Jetpack, Android’s API to accelerate Android development and make writing high-quality apps easy, with less code. Over 80% of our top 1000 apps are already using Jetpack, as we continue to simplify more every-day developer challenges. Today, we are releasing 6 new Jetpack libraries (in alpha), and bringing 5 libraries to beta quality. Here are 3 highlights:

  • CameraX - You’ve told us working effectively across the range of unique Android devices was tough. CameraX is a new open-source Android Jetpack library to make camera development easier and faster. It provides a consistent camera experience across devices, so you no longer have to maintain device specific configurations. You’ll find support for leading-edge hardware and software features like optical zoom, bokeh, HDR, and night mode on participating manufacturer devices. It works with almost 90% of devices (backwards compatible to L). There’s also an easy migration path from legacy Camera APIs and it works seamlessly with camera2 APIs. 70% of camera usage on Android comes from installed apps (not the device camera app) so we’re really excited to make camera development easier.

  • Architecture Components - We’ve made a number of additions and enhancements based on your feedback. You’ve told us concurrency on Android was hard. So we’re bringing you LiveData and Lifecycles w/ coroutines to support common one-shot asynchronous operations. With the ViewModel with SavedState module, you can eliminate boilerplate code and gain the benefits of using both ViewModel and SavedState with simple APIs to save and retrieve data right from your ViewModel. And in case you missed it, we announced stable releases of WorkManager (background processing) and Navigation (navigation between app screens) just a couple of months ago.
  • Jetpack Compose - Many of you have been asking us for a modern, reactive style UI toolkit for Android, which takes advantage of Kotlin and integrates seamlessly with the platform and all of your existing code. Today, we’re sharing the team’s work on Jetpack Compose. Jetpack Compose is designed to simplify UI development by combining a reactive programming model with the conciseness and ease-of-use of Kotlin. It’s compatible with the existing UI toolkit, so you can mix and match views with direct access to all of the Android and Jetpack APIs. It’s also fully declarative for defining UI components. And, it’s designed with Material, animations, and tools in mind from the start. Starting today we’re developing this in the open, and you can find all the code on AOSP.

Android Studio

Today we’re releasing Android Studio 3.5 to Beta. For months, the team has been exclusively focused on refining and polishing day-to-day development workflows, with Project Marble. Android Studio 3.5 includes better IDE memory management for large projects, lower typing latency, lint improvements, CPU usage optimizations, layout editor improvements, emulator improvements, build changes, as well as a complete rewrite of Instant Run, now called Apply Changes, that now reliably accelerates the ability to see your code changes on a device - plus over 400 high- priority bug fixes.

Machine Learning at Android scale

In Android Q, we’ve made significant improvements to Android’s Neural Networks API (NNAPI). First, we have increased the number of Operators supported from 38 to over 90. The vast majority of models can now be accelerated by NNAPI with no alterations. We’ve also introduced an introspection API for advanced users, allowing full control over which hardware components handle acceleration (e.g. DSP vs. NPU). And, we’ve worked closely with hardware vendors to deliver significant improvements in performance, both in latency and power consumption. Working with MediaTek, we were able to accelerate ML Kit’s face detection API by 9X on the Helio P90. Working with Qualcomm, we were able to accelerate Google’s Lens OCR on the Snapdragon 855’s AI Engine, increasing speed by 3X while also reducing power consumption by 3.7X.

Dynamic features and in-app updates

Last year we introduced the Android App Bundle to help you reduce app size and increase installs. Since then, we’ve seen over 80,000 app bundles in production, with average size savings of 20%. And today we have a number of announcements to help you reduce size and deliver updates to your users even faster. Today we’re glad to share that dynamic feature modules are moving from beta to stable. With dynamic feature modules, you can reduce your app size even more by choosing which parts of your app to deliver - based on conditions like device features, country. You can even deliver modules on-demand, instead of at install time. And today we’re also moving in-app updates from beta to stable. The ability to dynamically update apps is something you’ve been requesting for a long time. Let’s say you have a crucial bug in your app, and you need to push it out right away; you don’t want to wait until users discover an update in the Play Store. Now you can.

User privacy and security in Android Q

As a developer community, we all care about getting this right. It’s about building a platform that offers powerful capabilities for developers, while making sure that user safety and privacy is protected. We introduced Android Q Beta a few months ago with over 50 features and improvements around user privacy and security. These Q changes provide users more transparency and control.

As always, we are working hard to do everything we can for developers adopting the new release. We know you have your own features to build. That’s why, with these Q changes, we’ve worked very hard to minimize the impact for you, as well as to incorporate your feedback. We’ve given as long a notice period as possible, as well as complete and detailed technical information up front, to make it as easy as possible to adopt. We also want to thank the community for your ongoing feedback. It’s been a huge help to the team who are working hard to get this right. A great example are the Beta 3 storage changes, where your feedback helped us evolve the feature over the course of the Betas. Android has a longstanding commitment to minimizing all breaking changes. Our commitment is unchanged, and we’ll work hard to keep Android the open, flexible, and developer friendly platform we all love.

Be a part of Google I/O!

We’ve got a lot of great content in store for you over the next three days, including over 45 sessions across Android. We’re excited for you to join us in-person here at Shoreline, at an I/O Extended event, or online through the livestream. We’re constantly investing in our platform that connects developers to billions of users around the world. To the entire Android community, thank you for your continued support and feedback, and for being a part of Android.

What’s New in Android: Q Beta 3 & More

Posted by Dave Burke, VP, Engineering

Today Android is celebrating two amazing milestones. It’s Android’s version 10! And today, Android is running on more than 2.5B active Android devices.

With Android Q, we’ve focused on three themes: innovation, security and privacy, and digital wellbeing. We want to help you take advantage of the latest new technology -- 5G, foldables, edge-to-edge screens, on-device AI, and more -- while making sure users' security, privacy, and wellbeing are always a top priority.

Earlier at Google I/O we highlighted what’s new in Android Q and unveiled the latest update, Android Q Beta 3. Your feedback continues to be extremely valuable in shaping today’s update as well as our final release to the ecosystem in the fall.

This year, Android Q Beta 3 is available on 15 partner devices from 12 OEMs -- that’s twice as many devices as last year! It’s all thanks to Project Treble and especially to our partners who are committed to accelerating updates to Android users globally -- Huawei, Xiaomi, Nokia, Sony, Vivo, OPPO, OnePlus, ASUS, LGE, TECNO, Essential, and realme.

Visit android.com/beta to see the full list of Beta devices and learn how to get today’s update on your device. If you have a Pixel device, you can enroll here to get Beta 3 -- if you’re already enrolled, watch for the update coming soon. To get started developing with Android Q Beta, visit developer.android.com/preview.

Privacy and security

As we talked about at Google I/O, privacy and security are important to our whole company and in Android Q we’ve added many more protections for users.

Privacy

In Android Q, privacy has been a central focus, from strengthening protections in the platform to designing new features with privacy in mind. It’s more important than ever to give users control -- and transparency -- over how information is collected and used by apps, and by our phones.

Building on our work in previous releases, Android Q includes extensive changes across the platform to improve privacy and give users control -- from improved system UI to stricter permissions to restrictions on what data apps can use.

For example, Android Q gives users more control over when apps can get location. Apps still ask the user for permission, but now in Android Q the user has greater choice over when to allow access to location -- such as only while the app is in use, all the time, or never. Read the developer guide for details on how to adapt your app for the new location controls.

Outside of location, we also introduced the Scoped Storage feature to give users control over files and prevent apps from accessing sensitive user or app data. Your feedback has helped us refine this feature, and we recently announced several changes to make it easier to support. These are now available in Beta 3.

Another important change is restricting app launches from the background, which prevents apps from unexpectedly jumping into the foreground and taking over focus. In Beta 3 we’re transitioning from toast warnings to actually blocking these launches.

To prevent tracking we're limiting access to non-resettable device identifiers, including device IMEI, serial number, and similar identifiers. Read the best practices to choose the right identifiers for your use case. We're also randomizing MAC address when your device is connected to different Wi-Fi networks and gating connectivity APIs behind the location permission. We’re bringing these changes to you early, so you can have as much time as possible to prepare your apps.

Security

To keep users secure, we’ve extended our BiometricPrompt authentication framework to support biometrics at a system level. We're extending support for passive authentication methods such as face, and we’ve added implicit and explicit authentication flows. In the explicit flow, the user must explicitly confirm the transaction. The new implicit flow is designed for a lighter-weight alternative for transactions with passive authentication, and there’s no need for users to explicitly confirm.

Android Q also 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 made through Android’s TLS stack, called Conscrypt, regardless of target API level. See the docs for details.

Project Mainline

Today we also announced Project Mainline, a new approach to keeping Android users secure and their devices up-to-date with important code changes, direct from Google Play. With Project Mainline, we’re now able to update specific internal components within the OS itself, without requiring a full system update from your device manufacturer. This means we can help keep the OS code on devices fresher, drive a new level of consistency, and bring the latest AOSP code to users faster -- and for a longer period of time.

We plan to update Project Mainline modules in much the same way as app updates are delivered today -- downloading the latest versions from Google Play in the background and loading them the next time the phone starts up. The source code for the modules will continue to live in the Android Open Source Project, and updates will be fully open-sourced as they are released. Also, because they’re open source, they’ll include improvements and bug fixes contributed by our many partners and developer community worldwide.

For users, the benefits are huge, since their devices will always be running the latest versions of the modules, including the latest updates for security, privacy, and consistency. For device makers, carriers, and enterprises, the benefits are also huge, since they can optimize and secure key parts of the OS without the cost of a full system update.

For app and game developers, we expect Project Mainline to help drive consistency of platform implementation in key areas across devices, over time bringing greater uniformity that will reduce development and testing costs and help to make sure your apps work as expected. All devices running Android Q or later will be able to get Project Mainline, and we’re working closely with our partners to make sure their devices are ready.

Innovation and new experiences

Android is shaping the leading edge of innovation. With our ecosystem partners, we’re enabling new experiences through a combination of hardware and software advances.

Foldables

This year, display technology will take a big leap with foldable devices coming to the Android ecosystem from several top device makers. When folded these devices work like a phone, then you unfold a beautiful tablet-sized screen.

We’ve optimized Android Q to ensure that screen continuity is seamless in these transitions, and apps and games can pick up right where they left off. For multitasking, we’ve made some changes to onResume and onPause to support multi-resume and notify your app when it has focus. We've also changed how the resizeableActivity manifest attribute works, to help you manage how your app is displayed on large screens.

Our partners have already started showing their innovative foldable devices, with more to come. You can get started building and testing today with our foldables emulator in canary release of Android Studio 3.5.

5G networks

5G networks are the next evolution of wireless technology -- providing consistently faster speeds and lower latency. For developers, 5G can unlock new kinds of experiences in your apps and supercharge existing ones.

Android Q adds platform support for 5G and extends existing APIs to help you transform your apps for 5G. You can use connectivity APIs to detect if the device has a high bandwidth connection and check whether the connection is metered. With these your apps and games can tailor rich, immersive experiences to users over 5G.

With Android’s open ecosystem and range of partners, we expect the Android ecosystem to scale to support 5G quickly. This year, over a dozen Android device makers are launching 5G-ready devices, and more than 20 carriers will launch 5G networks around the world, with some already broad-scale.

Live Caption

On top of hardware innovation, we’re continuing to see Android’s AI transforming the OS itself to make it smarter and easier to use, for a wider range of people. A great example is Live Caption, a new feature in Android Q that automatically captions media playing on your phone.

Many people watch videos with captions on -- the captions help them keep up, even when on the go or in a crowded place. But for 466 million Deaf and Hard of Hearing people around the world, captions are more than a convenience -- they make content accessible. We worked with the Deaf community to develop Live Caption.

Live Caption brings real-time captions to media on your phone - videos, podcasts, and audio messages, across any app—even stuff you record yourself. Best of all, it doesn’t even require a network connection -- everything happens on the device, thanks to a breakthrough in speech recognition that we made earlier this year. The live speech models run right on the phone, and no audio stream ever leaves your device.

For developers, Live Caption expands the audience for your apps and games by making digital media more accessible with a single tap. Live Caption will be available later this year.

Suggested actions in notifications

In Android Pie we introduced smart replies for notifications that let users engage with your apps direct from notifications. We provided the APIs to attach replies and actions, but you needed to build those on your own.

Now in Android Q we want to make smart replies available to all apps right now, without you needing to do anything. Starting in Beta 3, we’re enabling system-provided smart replies and actions that are inserted directly into notifications by default.

You can still supply your own replies and actions if you want -- such as if you are using ML Kit or other ML frameworks. Just opt out of the system-provided replies or actions on a per-notification basis using setAllowGeneratedReplies() and setAllowSystemGeneratedContextualActions().

Android Q suggestions are powered by an on-device ML service built into the platform -- the same service that backs our text classifier entity recognition service. We’ve built it with user privacy in mind, and the ML processing happens completely on the device, not on a backend server.

Because suggested actions are based on the TextClassifier service, they can take advantage of new capabilities we’ve added in Android Q, such as language detection. You can also use TextClassifier APIs directly to generate system-provided notifications and actions, and you can mix those with your own replies and actions as needed.

Dark theme

Many users prefer apps that offer a UI with a dark theme they can switch to when light is low, to reduce eye strain and save battery. Users have also asked for a simple way to enable dark theme everywhere across their devices. Dark theme has been a popular request for a while, and in Android Q, it’s finally here.

Starting in Android Q Beta 3, users can activate a new system-wide dark theme by going to Settings > Display, using the new Quick Settings tile, or turning on Battery Saver. This changes the system UI to dark, and enables the dark theme of apps that support it. Apps can build their own dark themes, or they can opt-in to a new Force Dark feature that lets the OS create a dark version of their existing theme. All you have to do is opt-in by setting android:forceDarkAllowed="true" in your app’s current theme.

You may also want to take complete control over your app’s dark styling, which is why we’ve also been hard at work improving AppCompat’s DayNight feature. By using DayNight, apps can offer a dark theme to all of their users, regardless of what version of Android they’re using on their devices. For more information, see here.

Gestural navigation

Many of the latest Android devices feature beautiful edge-to-edge screens, and users want to take advantage of every bit of them. In Android Q we’re introducing a new fully gestural navigation mode that eliminates the navigation bar area and allows apps and games to use the full screen to deliver their content. It retains the familiar Back, Home, and recents navigation through edge swipes rather than visible buttons.

Users can switch to gestures in Settings > System > Gestures. There are currently two gestures: Swiping up from the bottom of the screen takes the user to the Home screen, holding brings up Recents. Swiping from the screen’s left or right edge triggers the Back action.

To blend seamlessly with gestural navigation, apps should go edge-to-edge, drawing behind the navigation bar to create an immersive experience. To implement this, apps should use the setSystemUiVisibility() API to be laid out fullscreen, and then handle WindowInsets as appropriate to ensure that important pieces of UI are not obscured. More information is here.

Digital wellbeing

Digital wellbeing is another theme of our work on Android -- we want to give users the visibility and tools to find balance with the way they use their phones. Last year we launched Digital Wellbeing with Dashboards, App Timers, Flip to Shush, and Wind Down mode. These tools are really helping. App timers helped users stick to their goals over 90% of the time, and users of Wind Down had a 27% drop in nightly usage.

This year we’re continuing to expand our features to help people find balance with digital devices, adding Focus Mode and Family Link.

Focus Mode

Focus Mode is designed for all those times you’re working or studying, and you want to to focus to get something done. With focus mode, you can pick the apps that you think might distract you and silence them - for example, pausing email and the News while leaving maps and text message apps active. You can then use Quick Tiles to turn on Focus Mode any time you want to focus. Under the covers, these apps will be paused - until you come out of Focus Mode! Focus Mode is coming to Android 9 Pie and Android Q devices this Fall.

Family Link

Family Link is a new set of controls to help parents. Starting in Android Q, Family Link will be built right into the Settings on the device. When you set up a new device for your child, Family Link will help you connect it to you. You’ll be able to set daily screen time limits, see the apps where your child is spending time, review any new apps your child wants to install, and even set a device bedtime so your child can disconnect and get to sleep. And now in Android Q you can also set time limits on specific apps… as well as give your kids Bonus Time if you want them to have just 5 more minutes at bedtime. Family Link is coming to Android P and Q devices this Fall. Make sure to check out the other great wellbeing apps in the recent Google Play awards.

Family link lets parents set device bedtime and even give bonus minutes.

Android Foundations

We’re continuing to extend the foundations of Android with more capabilities to help you build new experiences for your users -- here are just a few.

Improved peer-to-peer and internet connectivity

In Android Q we’ve refactored the Wi-Fi stack to improve privacy and performance, and 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. The network suggestion APIs let apps surface preferred Wi-Fi networks to the user for internet connectivity.

Wi-Fi performance modes

In Android Q apps can now request adaptive Wi-Fi 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. The platform works with the device firmware to meet the requirement with the lowest power consumption. To use the new performance modes, call WifiManager.WifiLock.createWifiLock().

Full support for Wi-Fi RTT accurate indoor positioning

In Android 9 Pie we introduced RTT APIs for indoor positioning to accurately measure distance to nearby Wi-Fi Access Points (APs) that support the IEEE 802.11mc protocol, based on measuring the round-trip time of Wi-Fi packets. Now in Android Q, we’ve completed our implementation of the 802.11mc standard, adding an API to obtain location information of each AP being ranged, configured by their owner during installation.

Audio playback capture

You saw how Live Caption can take audio from any app and instantly turn it into on-screen captions. It’s a seamless experience that shows how powerful it can be for one app to share its audio stream with another. In Android Q, any app that plays audio can let other apps capture its audio stream using a new API. In addition to enabling captioning and subtitles, the API lets you support popular use-cases like live-streaming games, all without latency impact on the source app or game.

We’ve designed this new capability with privacy and copyright protection in mind, so the ability for an app to capture another app's audio is constrained, giving apps full control over whether their audio streams can be captured. Read more here.

Dynamic depth for photos

Apps can now 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. Dynamic Depth is an open format for the ecosystem -- the latest version of the spec is here. We're working with our device-maker partners to make it available across devices running Android Q and later.

With Dynamic Depth image you can offer specialized blurs and bokeh options in your app

New audio and video codecs

Android Q adds support for the open source video codec AV1, which 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.

Vulkan 1.1 and ANGLE

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. 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. For game and graphics developers using OpenGL, we’re also 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. See the docs for details.

Neural Networks API 1.2

In NNAPI 1.2 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.

Thermal API

When devices get too warm, they may throttle the CPU and/or GPU, and this can affect apps and games in unexpected ways. Now in Android Q, apps and games can use a thermal API to monitor changes on the device and take action to help restore normal temperature. For example, streaming apps can reduce resolution/bit rate or network traffic, a camera app could disable flash or intensive image enhancement, or a game could reduce frame rate or polygon tesselation. Read more here.

ART optimizations

Android Q introduces several improvements to the ART runtime to help your apps start faster, consume less memory, and run smoother -- without requiring any work from you. 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. Cloud-based profiles benefit all apps and they're already available to devices running Android P and higher.

We’re also adding Generational Garbage Collection to ART's Concurrent Copying (CC) Garbage Collector. Generational CC collects young-generation objects separately, incurring much lower cost as compared to full-heap GC. It makes garbage collection more efficient in terms of time and CPU, reduces jank, and helps apps run better on lower-end devices.

More Android Q Beta devices, more Treble momentum than ever

In 2017 we launched Project Treble as part of Android Oreo, with a goal of accelerating OS updates. Treble provides a consistent, testable interface between Android and the underlying device code from device makers and silicon manufacturers, which makes porting a new OS version much simpler and more modular.

In 2018 we worked closely with our partners to bring the first OS updates to their Treble devices. The result: last year at Google I/O we had 8 devices from 7 partners joining our Android P Beta program, together with our Pixel and Pixel 2 devices. Fast forward to today -- we’re seeing updates to Android Pie accelerating strongly, with 2.5 times the footprint compared to Android Oreo's at the same time last year.

This year with Android Q we’re seeing even more momentum, and we have 21 devices from 12 top global partners joining us to release Android Q Beta 3 -- in addition all Pixel devices. We’re also providing Q Beta 3 Generic System Images (GSI), a testing environment for other supported Treble devices. All of these offer the same behaviors, APIs, and features -- giving you an incredible variety of devices for testing your apps, and more ways for you to get an early look at Android Q.

You can see the full list of supported partner and Pixel devices at android.com/beta. Try Android Q Beta on your favorite device today and let us know your feedback!

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 for an overview of what's changed in Beta 3, and see the Android Q Beta API reference for details. Visit the Android Q Beta developer site for more resources, including release notes and how to report 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 Beta 3?

It's easy! Just enroll any Pixel device here to get the update over-the-air. If you're already enrolled, you'll receive the update soon, and, no action is needed on your part. Downloadable system images are also available.

You can also get Beta 3 on any of the other devices participating in the Android Q Beta program, from some of our top device maker partners. You can see the full list of supported partner and Pixel devices at android.com/beta. For each device you'll find specs and links to the manufacturer's dedicated site for downloads, support, and to report issues.

For even broader testing on supported devices, you can also get Android GSI images, and if you don’t have a device you can test on the Android Emulator -- just download the latest emulator system images via the SDK Manager in Android Studio.

As always, your input is critical, so please let us know what you think. You can use our hotlists for filing platform issues (including privacy and behavior changes), app compatibility issues, and third-party SDK issues. You've shared great feedback with us so far and we're working to integrate as much of it as possible in the next Beta release.

We're looking forward to seeing your apps on Android Q!

Android Q Scoped Storage: Best Practices and Updates

Posted by Jeff Sharkey, Software Engineer, and Seb Grubb, Product Manager

Application Sandboxing is a core part of Android’s design, isolating apps from each other. In Android Q, taking the same fundamental principle from Application Sandboxing, we introduced Scoped Storage.

Since the Beta 1 release, you’ve given us a lot of valuable feedback on these changes -- thank you for helping shape Android! Because of your feedback, we've evolved the feature during the course of Android Q Beta. In this post, we'll share options for declaring your app’s support for Scoped Storage on Android Q devices, and best practices for questions we've heard from the community.

Updates to help you adopt Scoped Storage

We expect that Scoped Storage should have minimal impact to apps following current storage best practices. However, we also heard from you that Scoped Storage can be an elaborate change for some apps and you could use more time to assess the impact. Being developers ourselves, we understand you may need some additional time to ensure your app’s compatibility with this change. We want to help.

In the upcoming Beta 3 release, apps that target Android 9 Pie (API level 28) or lower will see no change, by default, to how storage works from previous Android versions. As you update your existing app to work with Scoped Storage, you’ll be able to use a new manifest attribute to enable the new behavior for your app on Android Q devices, even if your app is targeting API level 28 or lower.

The implementation details of these changes will be available with the Beta 3 release, but we wanted to share this update with you early, so you can better prepare your app for Android Q devices. Scoped Storage will be required in next year’s major platform release for all apps, independent of target SDK level, so we recommend you add support to your app well in advance. Please continue letting us know your feedback and how we can better align Scoped Storage with your app’s use cases. You can give us input through this survey, or file bugs and feature requests here.

Best practices for common feedback areas

Your feedback is incredibly valuable and has helped us shape these design decisions. We also want to take a moment to share some best practices for common questions we’ve heard:

  • Storing shared media files. For apps that handle files that users expect to be sharable with other apps (such as photos) and be retained after the app has been uninstalled, use the MediaStore API. There are specific collections for common media files: Audio, Video, and Images. For other file types, you can store them in the new Downloads collection. To access files from the Downloads collection, apps must use the system picker.
  • Storing app-internal files. If your app is designed to handle files not meant to be shared with other apps, store them in your package-specific directories. This helps keep files organized and limit file clutter as the OS will manage cleanup when the app is uninstalled. Calls to Context.getExternalFilesDir() will continue to work.
  • Working with permissions and file ownership. For MediaStore, no permissions are necessary for apps that only access their own files. Your app will need to request permission to access media contributed by other apps. However, if your app is uninstalled and then reinstalled later, you’ll need to request permission from the user in order to be able to access media your app previously contributed.
  • Working with native code or libraries. The recommended pattern is to begin your media file discovery in your Java-based or Kotlin-based code, then pass the file's associated file descriptor into your native code.
  • Working with many files efficiently. If you need to perform bulk file operations in a single transaction, consider using ContentProvider.applyBatch(). Learn more about ContentProvider batch processing here.
  • Integrating with the system file picker.
    • Documents apps, such as a word processor, can use the ACTION_OPEN_DOCUMENT or ACTION_GET_CONTENT action to open a system file picker. You can learn more about the differences here.
    • File management apps typically work with collections of apps in a directory hierarchy. Use ACTION_OPEN_DOCUMENT_TREE to let the user pick a directory subtree. The app can further manipulate files available in the returned directory. Through this support, users can access files from any installed DocumentsProvider instance, which can be supported by any cloud-based or locally-backed storage solutions.

We’ve also provided a detailed Scoped Storage developer guide with additional information.

What’s ahead

It’s been amazing to see the community engagement on Android Q Beta so far. As we finalize the release in the next several months, please continue testing and keep the feedback coming. Join us at Google I/O 2019 for more details on Scoped Storage and other Android Q features. We’re giving a ”What’s new on Shared Storage” talk on May 8, and you’ll be able to find the livestream and recorded video on the Google I/O site.

Android Q Beta 2 update

Posted by Dave Burke, VP of Engineering

A few weeks ago we Introduced Android Q Beta, a first look at the next version of Android. Along with new privacy features for users, Android Q adds new capabilities for developers - like enhancements for foldables, new APIs for connectivity, new media codecs and camera capabilities, NNAPI extensions, Vulkan 1.1 graphics, and more.

Android's program of early, open previews is driven by our core philosophy of openness, and collaboration with our community. Your feedback since Beta 1 proves yet again the value of that openness - it's been loud, clear, and incredibly valuable. You've sent us thousands of bug reports, giving us insights and directional feedback, changing our plans in ways that make the platform better for users and developers. We're taking your feedback to heart, so please stay tuned. We're fortunate to have such a passionate community helping to guide Android Q toward the final product later this year.

Today we're releasing Android Q Beta 2 and an updated SDK for developers. It includes the latest bug fixes, optimizations, and API updates for Android Q, along with the April 2019 security patches. You'll also notice isolated storage becoming more prominent as we look for your wider testing and feedback to help us refine that feature.

We're still in early Beta with Android Q so expect rough edges! Before you install, check out the Known Issues. In particular, expect the usual transitional issues with apps that we typically see during early Betas as developers get their app updates ready. For example, you might see issues with apps that access photos, videos, media, or other files stored on your device, such as when browsing or sharing in social media apps.

You can get Beta 2 today by enrolling any Pixel device here. If you're already enrolled, watch for the Beta 2 update coming soon. Stay tuned for more at Google I/O in May.

What's new in Beta 2?

Privacy features for testing and feedback

As we shared at Beta 1, we're making significant privacy investments in Android Q in addition to the work we've done in previous releases. Our goals are improving transparency, giving users more control, and further securing personal data across platform and apps. We know that to reach those goals, we need to partner with you, our app developers. We realize that supporting these features is an investment for you too, so we'll do everything we can to minimize the impact on your apps.

For features like Scoped Storage, we're sharing our plans as early as possible to give you more time to test and give us your input. To generate broader feedback, we've also enabled Scoped Storage for new app installs in Beta 2, so you can more easily see what is affected.

With Scoped Storage, apps can use their private sandbox without permission, but they need new permissions to access shared collections for photos, videos and audio. Apps using files in shared collections -- for example, photo and video galleries and pickers, media browsing, and document storage -- may behave differently under Scoped Storage.

We recommend getting started with Scoped Storage soon -- the developer guide has details on how to handle key use-cases. For testing, make sure to enable Scoped Storage for your app using the adb command. If you discover that your app has a use-case that's not supported by Scoped Storage, please let us know by taking this short survey. We appreciate the great feedback you've given us already, it's a big help as we move forward with the development of this feature.

Bubbles: a new way to multitask

In Android Q we're adding platform support for bubbles, a new way for users to multitask and re-engage with your apps. Various apps have already built similar interactions from the ground up, and we're excited to bring the best from those into the platform, while helping to make interactions consistent, safeguard user privacy, reduce development time, and drive innovation.

Bubbles will let users multitask as they move between activities.

Bubbles help users prioritize information and take action deep within another app, while maintaining their current context. They also let users carry an app's functionality around with them as they move between activities on their device.

Bubbles are great for messaging because they let users keep important conversations within easy reach. They also provide a convenient view over ongoing tasks and updates, like phone calls or arrival times. They can provide quick access to portable UI like notes or translations, and can be visual reminders of tasks too.

We've built bubbles on top of Android's notification system to provide a familiar and easy to use API for developers. To send a bubble through a notification you need to add a BubbleMetadata by calling setBubbleMetadata. Within the metadata you can provide the Activity to display as content within the bubble, along with an icon (disabled in beta 2) and associated person.

We're just getting started with bubbles, but please give them a try and let us know what you think. You can find a sample implementation here.

Foldables emulator

As the ecosystem moves quickly toward foldable devices, new use-cases are opening up for your apps to take advantage of these new screens. With Beta 2, you can build for foldable devices through Android Q enhanced platform support, combined with a new foldable device emulator, available as an Android Virtual device in Android Studio 3.5 available in the canary release channel.

7.3" Foldable AVD switches between the folded and unfolded states

On the platform side, we've made a number of improvements in onResume and onPause to support multi-resume and notify your app when it has focus. We've also changed how the resizeableActivity manifest attribute works, to help you manage how your app is displayed on foldable and large screens. You can read more in the foldables developer guide.

To set up a runtime environment for your app, you can now configure a foldable emulator as a virtual device (AVD) in Android Studio. The foldable AVD is a reference device that lets you test with standard hardware configurations, behaviors, and states, as will be used by our device manufacturer partners. To ensure compatibility, the AVD meets CTS/GTS requirements and models CDD compliance. It supports runtime configuration change, multi-resume and the new resizeableActivity behaviors.

Use the canary release of Android Studio 3.5 to create a foldable virtual device to support either of two hardware configurations 7.3" (4.6" folded) and 8" (6.6" folded) with Beta 2. In each configuration, the emulator gives you on-screen controls to trigger fold/unfold, change orientation, and quick actions.

Android Studio - AVD Manager: Foldable Device Setup

Try your app on the foldable emulator today by downloading the canary release of Android Studio 3.5 and setting up a foldable AVD that uses the Android Q Beta 2 system image.

Improved sharesheet

Following on the initial Sharing Shortcuts APIs in Beta 1, you can now offer a preview of the content being shared by providing an EXTRA_TITLE extra in the Intent for the title, or by setting the Intent's ClipData for a thumbnail image. See the updated sample application for the implementation details.

Directional, zoomable microphones

Android Q Beta 2 gives apps more control over audio capture through a new MicrophoneDirection API. You can use the API to specify a preferred direction of the microphone when taking an audio recording. For example, when the user is taking a "selfie" video, you can request the front-facing microphone for audio recording (if it exists) by calling setMicrophoneDirection(MIC_DIRECTION_FRONT).

Additionally, this API introduces a standardized way of controlling zoomable microphones, allowing your app to have control over the recording field dimension using setMicrophoneFieldDimension(float).

Compatibility through public APIs

In Android Q we're continuing our long-term effort to move apps toward only using public APIs. We introduced most of the new restrictions in Beta 1, and we're making a few minor updates to those lists in Beta 2 to minimize impact on apps. Our goal is to provide public alternative APIs for valid use-cases before restricting access, so if an interface that you currently use in Android 9 Pie is now restricted, you should request a new public API for that interface.

Get started with Android Q Beta

Today's update includes Beta 2 system images for all Pixel devices and the Android Emulator, as well updated SDK and tools for developers. These give you everything you need to get started testing your apps on the new platform and build with the latest APIs.

First, make your app compatible and give your users a seamless transition to Android Q, including your users currently participating in the Android Beta program. To get started, just install your current app from Google Play onto a device or emulator running Beta 2 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. See the migration guide for steps and a recommended timeline.

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 test against scoped storage, new location permissions, restrictions on background Activity starts, and restrictions on device identifiers. See the privacy checklist as a starting point.

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. Here's a video highlighting many of the changes for developers in Beta 1 and Beta 2. Take a look at the API diff report for an overview of what's changed in Beta 2, and see the Android Q Beta API reference for details. Visit the Android Q Beta developer site for more resources, including release notes and how to report 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 Beta 2?

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!). If you're already enrolled, you'll receive the update to Beta 2 soon, no action is needed on your part. Downloadable system images are also available. If you don't have a Pixel device, you can use the Android Emulator -- just download the latest emulator system images via the SDK Manager in Android Studio.

As always, your input is critical, so please let us know what you think. You can use our hotlists for filing platform issues (including privacy and behavior changes), app compatibility issues, and third-party SDK issues. You've shared great feedback with us so far and we're working to integrate as much of it as possible in the next Beta release.

Giving users more control over their location data

Posted by Jen Chai, Product Manager

Location data can deliver amazing, rich mobile experiences for users on Android such as finding a restaurant nearby, tracking the distance of a run, and getting turn-by-turn directions as you drive. Location is also one of the most sensitive types of personal information for a user. We want to give users simple, easy-to-understand controls for what data they are providing to apps, and yesterday, we announced in Android Q that we are giving users more control over location permissions. We are delighted by the innovative location experiences you provide to users through your apps, and we want to make this transition as straightforward for you as possible. This post dives deeper into the location permission changes in Q, what it may mean for your app, and how to get started with any updates needed.

Previously, a user had a single control to allow or deny an app access to device location, which covered location usage by the app both while it was in use and while it wasn't. Starting in Android Q, users have a new option to give an app access to location only when the app is being used; in other words, when the app is in the foreground. This means users will have a choice of three options for providing location to an app:

  • "All the time" - this means an app can access location at any time
  • "While in use" - this means an app can access location only while the app is being used
  • "Deny" - this means an app cannot access location

Some apps or features within an app may only need location while the app is being used. For example, if a feature allows a user to search for a restaurant nearby, the app only needs to understand the user's location when the user opens the app to search for a restaurant.

However, some apps may need location even when the app is not in use. For example, an app that automatically tracks the mileage you drive for tax filing, without requiring you to interact with the app.

The new location control allows users to decide when device location data is provided to an app and prevents an app from getting location data that it may not need. Users will see this new option in the same permissions dialog that is presented today when an app requests access to location. This permission can also be changed at any time for any app from Settings-> Location-> App permission.

Here's how to get started

We know these updates may impact your apps. We respect our developer community, and our goal is to approach any change like this very carefully. We want to support you as much as we can by (1) releasing developer-impacting features in the first Q Beta to give you as much time as possible to make any updates needed in your apps and (2) providing detailed information in follow-up posts like this one as well as in the developer guides and privacy checklist. Please let us know if there are ways we can make the guides more helpful!

If your app has a feature requiring "all the time" permission, you'll need to add the new ACCESS_BACKGROUND_LOCATION permission to your manifest file when you target Android Q. If your app targets Android 9 (API level 28) or lower, the ACCESS_BACKGROUND_LOCATION permission will be automatically added for you by the system if you request either ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION. A user can decide to provide or remove these location permissions at any time through Settings. To maintain a good user experience, design your app to gracefully handle when your app doesn't have background location permission or when it doesn't have any access to location.

Users will also be more likely to grant the location permission if they clearly understand why your app needs it. Consider asking for the location permission from users in context, when the user is turning on or interacting with a feature that requires it, such as when they are searching for something nearby. In addition, only ask for the level of access required for that feature. In other words, don't ask for "all the time" permission if the feature only requires "while in use" permission.

To learn more, read the developer guide on how to handle the new location controls.