Today we’re releasing the second beta of Android 17, continuing our work to build a platform that prioritizes privacy, security, and refined performance. This update delivers a range of new capabilities, including the EyeDropper API and a privacy-preserving Contacts Picker. We’re also adding advanced ranging, cross-device handoff APIs, and more.

This release continues the shift in our release cadence, following this annual major SDK release in Q2 with a minor SDK update.

A new system-level EyeDropper API allows your app to request a color from any pixel on the display without requiring sensitive screen capture permissions.

val eyeDropperLauncher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) {
  result -> if (result.resultCode == Activity.RESULT_OK) {
    val color = result.data?.getIntExtra(Intent.EXTRA_COLOR, Color.BLACK)
    // Use the picked color in your app
  }
}

fun launchColorPicker() {
  val intent = Intent(Intent.ACTION_OPEN_EYE_DROPPER)
  eyeDropperLauncher.launch(intent)
}

val contactPicker = rememberLauncherForActivityResult(StartActivityForResult()) {
    if (it.resultCode == RESULT_OK) {
        val uri = it.data?.data ?: return@rememberLauncherForActivityResult
        // Handle result logic
        processContactPickerResults(uri)
    }
}

val dataFields = arrayListOf(Email.CONTENT_ITEM_TYPE, Phone.CONTENT_ITEM_TYPE)
val intent = Intent(ACTION_PICK_CONTACTS).apply {
    putStringArrayListExtra(EXTRA_PICK_CONTACTS_REQUESTED_DATA_FIELDS, dataFields)
    putExtra(EXTRA_ALLOW_MULTIPLE, true)
    putExtra(EXTRA_PICK_CONTACTS_SELECTION_LIMIT, 5)
}

contactPicker.launch(intent)

// To request the new default relative mode (mouse-like events)
// This is the same as requesting with View.POINTER_CAPTURE_MODE_RELATIVE
view.requestPointerCapture()

// To request the legacy absolute mode (raw touch coordinates)
view.requestPointerCapture(View.POINTER_CAPTURE_MODE_ABSOLUTE)

The Android 17 schedule

We’re going to be moving quickly from this Beta to our Platform Stability milestone, targeted for March. At this milestone, we’ll deliver final SDK/NDK APIs. From that time forward, your app can target SDK 37 and publish to Google Play to help you complete your testing and collect user feedback in the several months before the general availability of Android 17.

Posted by Matthew McCullough, VP of Product Management, Android Developer

Today we’re releasing the first beta of Android 17, continuing our work to build a platform that prioritizes privacy, security, and refined performance. This build continues our work for more adaptable Android apps, introduces significant enhancements to camera and media capabilities, new tools for optimizing connectivity, and expanded profiles for companion devices. This release also highlights a fundamental shift in the way we’re bringing new releases to the developer community, from the traditional Developer Preview model to the Android Canary program

Beyond the Developer Preview

Android has replaced the traditional “Developer Preview” with a continuous Canary channel. This new “always-on” model offers three main benefits:

• Faster Access: Features and APIs land in Canary as soon as they pass internal testing, rather than waiting for a quarterly release.
• Better Stability: Early “battle-testing” in Canary results in a more polished Beta experience with new APIs and behavior changes that are closer to being final.
• Easier Testing: Canary supports OTA updates (no more manual flashing) and, as a separate update channel, more easily integrates with CI workflows and gives you the earliest window to give immediate feedback on upcoming potential changes.

The Android 17 schedule

We’re going to be moving quickly from this Beta to our Platform Stability milestone, targeted for March. At this milestone, we’ll deliver final SDK/NDK APIs and largely final app-facing behaviors. From that time you’ll have several months before the final release to complete your testing.

A year of releases

We plan for Android 17 to continue to get updates in a series of quarterly releases. The upcoming release in Q2 is the only one where we introduce planned app breaking behavior changes. We plan to have a minor SDK release in Q4 with additional APIs and features.

Orientation and resizability restrictions

With the release of the Android 17 Beta, we’re moving to the next phase of our adaptive roadmap: Android 17 (API level 37) removes the developer opt-out for orientation and resizability restrictions on large screen devices (sw > 600 dp).

When your app targets SDK 37, it must be ready to adapt. Users expect their apps to work everywhere—whether multitasking on a tablet, unfolding a device, or using a desktop windowing environment—and they expect the UI to fill the space and respect their device posture.

Key Changes for SDK 37

Apps targeting Android 17 must ensure compatibility with the phase-out of manifest attributes and runtime APIs introduced in Android 16. When running on a large screen (smaller dimension ≥ 600dp), the following attributes and APIs will be ignored:

Manifest attributes/API	Ignored values
screenOrientation	portrait, reversePortrait, sensorPortrait, userPortrait, landscape, reverseLandscape, sensorLandscape, userLandscape
setRequestedOrientation()	portrait, reversePortrait, sensorPortrait, userPortrait, landscape, reverseLandscape, sensorLandscape, userLandscape
resizeableActivity	all
minAspectRatio	all
maxAspectRatio	all

Exemptions and User Control

These changes are specific to large screens; they do not apply to screens smaller than sw600dp (including traditional slate form factor phones). Additionally, apps categorized as games (based on the android:appCategory flag) are exempt from these restrictions.

It is also important to note that users remain in control. They can explicitly opt-in/out to using an app’s default behavior via the system’s aspect ratio settings.

Updates to configuration changes

To improve app compatibility and help minimize interrupted video playback, dropped input, and other types of disruptive state loss, we are updating the default behavior for Activity recreation. Starting with Android 17, the system will no longer restart activities by default for specific configuration changes that typically do not require a UI recreation, including CONFIG_KEYBOARD, CONFIG_KEYBOARD_HIDDEN, CONFIG_NAVIGATION, CONFIG_UI_MODE (when only UI_MODE_TYPE_DESK is changed), CONFIG_TOUCHSCREEN, and CONFIG_COLOR_MODE. Instead, running activities will simply receive these updates via onConfigurationChanged. If your application relies on a full restart to reload resources for these changes, you must now explicitly opt-in using the new android:recreateOnConfigChanges manifest attribute, which allows you to specify which configuration changes should trigger a complete activity lifecycle (from stop, to destroy and creation again), together with the related constants mcc, mnc, and the new ones keyboard, keyboardHidden, navigation, touchscreen and colorMode.

Prepare Your App

We’ve released tools and documentation to make it easy for you. Our focused blog post has more guidance, with strategies to address common issues. Apps will need to support landscape and portrait layouts for window sizes across the full range of aspect ratios, as restricting orientation or aspect ratio will no longer be an option. We recommend testing your app using the Android 17 Beta 1 with Pixel Tablet or Pixel Fold emulators (configured to targetSdkPreview = “CinnamonBun”) or by using the app compatibility framework to enable UNIVERSAL_RESIZABLE_BY_DEFAULT on Android 16 devices.

Performance

Lock-free MessageQueue

In Android 17, apps targeting SDK 37 or higher will receive a new implementation of android.os.MessageQueue where the implementation is lock-free. The new implementation improves performance and reduces missed frames, but may break clients that reflect on MessageQueue private fields and methods.

Generational garbage collection

Android 17 introduces generational garbage collection to ART‘s Concurrent Mark-Compact collector. This optimization introduces more frequent, less resource-intensive young-generation collections alongside full-heap collections. aiming to reduce overall garbage collection CPU cost and time duration. ART improvements are also available to over a billion devices running Android 12 (API level 31) and higher through Google Play System updates.

Static final fields now truly final

Starting from Android 17 apps targeting Android 17 or later won’t be able to modify “static final” fields, allowing the runtime to apply performance optimizations more aggressively. An attempt to do so via reflection (and deep reflection) will always lead to IllegalAccessException being thrown. Modifying them via JNI’s SetStatic<Type>Field methods family will immediately crash the application.

Custom Notification View Restrictions

To reduce memory usage we are restricting the size of custom notification views. This update closes a loophole that allows apps to bypass existing limits using URIs. This behavior is gated by the target SDK version and takes effect for apps targeting API 37 and higher.

New performance debugging ProfilingManager triggers

We’ve introduced several new system triggers to ProfilingManager to help you collect in-depth data to debug performance issues. These triggers are TRIGGER_TYPE_COLD_START, TRIGGER_TYPE_OOM, and TRIGGER_TYPE_KILL_EXCESSIVE_CPU_USAGE.

To understand how to set up the new system triggers, check out the trigger-based profiling and retrieve and analyze profiling data documentation.

Media and Camera

Android 17 brings professional-grade tools to media and camera apps, with features like seamless transitions and standardized loudness.

Dynamic Camera Session Updates

We have introduced updateOutputConfigurations() to CameraCaptureSession. This allows you to dynamically attach and detach output surfaces without the need to reconfigure the entire camera capture session. This change enables seamless transitions between camera use cases and modes (such as shooting still images vs shooting videos) without the memory cost and code complexity of configuring and holding onto all camera output surfaces that your app might need during camera start up. This helps to eliminate user-visible glitches or freezes during operation.

fun updateCameraSession(session: CameraCaptureSession, newOutputConfigs:  List<OutputConfiguration>)) {
    // Dynamically update the session without closing and reopening
    try {
        
        // Update the output configurations
        session.updateOutputConfigurations(newOutputConfigs)
    } catch (e: CameraAccessException) {
        // Handle error
    }
}

Logical multi-camera device metadata

When working with logical cameras that combine multiple physical camera sensors, you can now request additional metadata from all active physical cameras involved in a capture, not just the primary one. Previously, you had to implement workarounds, sometimes allocating unnecessary physical streams, to obtain metadata from secondary active cameras (e.g., during a lens switch for zoom where a follower camera is active). This feature introduces a new key, LOGICAL_MULTI_CAMERA_ADDITIONAL_RESULTS, in CaptureRequest and CaptureResult. By setting this key to ON in your CaptureRequest, the TotalCaptureResult will include metadata from these additional active physical cameras. You can access this comprehensive metadata using TotalCaptureResult.getPhysicalCameraTotalResults() to get more detailed information that may enable you to optimize resource usage in your camera applications.

Versatile Video Coding (VVC) Support

Android 17 adds support for the Versatile Video Coding (VVC) standard. This includes defining the video/vvc MIME type in MediaFormat, adding new VVC profiles in MediaCodecInfo, and integrating support into MediaExtractor. This feature will be coming to devices with hardware decode support and capable drivers.

Constant Quality for Video Recording

We have added setVideoEncodingQuality() to MediaRecorder. This allows you to configure a constant quality (CQ) mode for video encoders, giving you finer control over video quality beyond simple bitrate settings.

Background Audio Hardening

Starting in Android 17, the audio framework will enforce restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs to ensure that these changes are started intentionally by the user. 

If the app tries to call audio APIs while the application is not in a valid lifecycle, the audio playback and volume change APIs will fail silently without an exception thrown or failure message provided. The audio focus API will fail with the result code AUDIOFOCUS_REQUEST_FAILED.

Privacy and Security

Deprecation of Cleartext Traffic Attribute

The android:usesCleartextTraffic attribute is now deprecated. If your app targets (Android 17) or higher and relies on usesCleartextTraffic=”true” without a corresponding Network Security Configuration, it will default to disallowing cleartext traffic. You are encouraged to migrate to Network Security Configuration files for granular control.

HPKE Hybrid Cryptography

We are introducing a public Service Provider Interface (SPI) for an implementation of HPKE hybrid cryptography, enabling secure communication using a combination of public key and symmetric encryption (AEAD).

Connectivity and Telecom

Enhanced VoIP Call History

We are introducing user preference management for app VoIP call history integration. This includes support for caller and participant avatar URIs in the system dialer, enabling granular user control over call log privacy and enriching the visual display of integrated VoIP call logs.

Wi-Fi Ranging and Proximity

Wi-Fi Ranging has been enhanced with new Proximity Detection capabilities, supporting continuous ranging and secure peer-to-peer discovery. Updates to Wi-Fi Aware ranging include new APIs for peer handles and PMKID caching for 11az secure ranging.

Developer Productivity and Tools

Updates for companion device apps

We have introduced two new profiles to the CompanionDeviceManager to improve device distinction and permission handling:

• Medical Devices: This profile allows medical device mobile applications to request all necessary permissions with a single tap, simplifying the setup process.

• Fitness Trackers: The DEVICE_PROFILE_FITNESS_TRACKER profile allows companion apps to explicitly indicate they are managing a fitness tracker. This ensures accurate user experiences with distinct icons while reusing existing watch role permissions.

Also, the CompanionDeviceManager now offers a unified dialog for device association and Nearby permission requests. You can leverage the new setExtraPermissions method in AssociationRequest.Builder to bundle nearby permission prompts within the existing association flow, reducing the number of dialogs presented to the user.

Get started with Android 17

You can enroll any supported Pixel device to get this and future Android Beta updates over-the-air. If you don’t have a Pixel device, you can use the 64-bit system images with the Android Emulator in Android Studio.

If you are currently in the Android Beta program, you will be offered an over-the-air update to Beta 1.

If you have Android 26Q1 Beta and would like to take the final stable release of 26Q1 and exit Beta, you need to ignore the over-the-air update to 26Q2 Beta 1 and wait for the release of 26Q1.

We’re looking for your feedback so please report issues and submit feature requests on the feedback page. The earlier we get your feedback, the more we can include in our work on the final release.

For the best development experience with Android 17, we recommend that you use the latest preview of Android Studio (Panda). Once you’re set up, here are some of the things you should do:

• Compile against the new SDK, test in CI environments, and report any issues in our tracker on the feedback page.

• Test your current app for compatibility, learn whether your app is affected by changes in Android 17, and install your app onto a device or emulator running Android 17 and extensively test it.

We’ll update the preview/beta system images and SDK regularly throughout the Android 17 release cycle. Once you’ve installed a beta build, you’ll automatically get future updates over-the-air for all later previews and Betas.

For complete information, visit the Android 17 developer site.

Join the conversation

As we move toward Platform Stability and the final stable release of Android 17 later this year, your feedback remains our most valuable asset. Whether you’re an early adopter on   the Canary channel or an app developer testing on Beta 1, consider joining our communities and filing feedback. We’re listening.

Posted by Matthew McCullough, VP of Product Management, Android Developer

if ((Build.VERSION.SDK_INT >= Build.VERSION_CODES.BAKLAVA) && (Build.VERSION.SDK_INT_FULL >= Build.VERSION_CODES_FULL.BAKLAVA_1)) {
    // Call new APIs from the Android 16 QPR2 release
}

Expanded Dark Theme

To create a more consistent user experience for users who have low vision, photosensitivity, or simply those who prefer a dark system-wide appearance, QPR2 introduced an expanded option under dark theme.

The old Fitbit app showing the impact of expanded dark theme; the new Fitbit app directly supports a dark theme

When the expanded dark theme setting is enabled by a user, the system uses your app’s isLightTheme theme attribute to determine whether to apply inversion. If your app inherits from one of the standard DayNight themes, this is done automatically for you. If it does not, make sure to declare isLightTheme=”false” in your dark theme to ensure your app is not inadvertently inverted. Standard Android Views, Composables, and WebViews will be inverted, while custom rendering engines like Flutter will not.

This is largely intended as an accessibility feature. We strongly recommend implementing a native dark theme, which gives you full control over your app’s appearance; you can protect your brand’s identity, ensure text is readable, and prevent visual glitches from happening when your UI is automatically inverted, guaranteeing a polished, reliable experience for your users.

Custom Icon Shapes & Auto-Theming

In QPR2, users can select specific shapes for their app icons, which apply to all icons and folder previews. Additionally, if your app does not provide a dedicated themed icon, the system can now automatically generate one by applying a color filtering algorithm to your existing launcher icon.

Custom Icon Shapes
Test Icon Shape & Color in Android Studio	Automatic system icon color filtering

Interactive Chooser Sessions

The sharing experience is now more dynamic. Apps can keep the UI interactive even when the system sharesheet is open, allowing for real-time content updates within the Chooser.

Boosting Your Productivity and App Performance

We are introducing tools and updates designed to streamline your workflow and improve app performance.

Linux Development Environment with GUI Applications

The Linux development environment feature has been expanded to support running Linux GUI applications directly within the terminal environment.

Wilber, the GIMP mascot, designed by Aryeom Han, is licensed under CC BY-SA 4.0. The screenshot of the GIMP interface is used with courtesy.

Generational Garbage Collection

The Android Runtime (ART) now includes a Generational Concurrent Mark-Compact (CMC) Garbage Collector. This focuses collection on newly allocated objects, resulting in reduced CPU usage and improved battery efficiency.

Widget Engagement Metrics

You can now query user interaction events—such as clicks, scrolls, and impressions—to better understand how users engage with your widgets.

16KB Page Size Readiness

To help prepare for future architecture requirements, we have added early warning dialogs for debuggable apps that are not 16KB page-aligned.

Media, Connectivity, and Health

QPR2 brings robust updates to media standards and device connectivity.

IAMF and Audio Sharing

We have added software decoding support for Immersive Audio Model and Formats (IAMF), an open-source spatial audio format. Additionally, Personal Audio Sharing for Bluetooth LE Audio is now integrated directly into the system Output Switcher.

Health Connect Updates

Health Connect now automatically tracks steps using the device’s sensors. If your app has the READ_STEPS permission, this data will be available from the “android” package. Not only does this simplify the code needed to do step tracking, it’s also more power efficient. It also can now track weight, set index, and Rate of Perceived Exertion (RPE) in exercise segments.

Smoother Migrations

A new 3rd-party Data Transfer API enables more reliable data migration between Android and iOS devices.

Strengthening Privacy and Security

Security remains a top priority with new features designed to protect user data and device integrity.

Developer Verification

We introduced APIs to support developer verification during app installation along with new ADB commands to simulate verification outcomes. As a developer, you are free to install apps without verification by using ADB, so you can continue to test apps that are not intended or not yet ready to distribute to the wider consumer population.

SMS OTP Protection

The delivery of messages containing an SMS retriever hash will be delayed for most apps for three hours to help prevent OTP hijacking. The RECEIVE_SMS broadcast will be withheld and sms provider database queries will be filtered. The SMS will be available to these apps after the three hour delay.

Secure Lock Device

A new system-level security state, Secure Lock Device, is being introduced. When enabled (e.g., remotely via “Find My Device”), the device locks immediately and requires the primary PIN, pattern, or password to unlock, heightening security. When active, notifications and quick affordances on the lock screen will be hidden, and biometric unlock may be temporarily disabled.

Get Started

If you’re not in the Beta or Canary programs, your Pixel device should get the Android 16 QPR2 release shortly. If you don’t have a Pixel device, you can use the 64-bit system images with the Android Emulator in Android Studio. If you are currently on the Android 16 QPR2 Beta and have not yet installed the Android 16 QPR3 beta, you can opt out of the program and you will then be offered the release version of Android 16 QPR2 over the air.
For the best development experience with Android 16 QPR2, we recommend that you use the latest Canary build of Android Studio Otter.
Thank you again to everyone who participated in our Android beta program. We’re looking forward to seeing how your apps take advantage of the updates in Android 16 QPR2.

For complete information on Android 16 QPR2 please visit the Android 16 developer site.

Posted by Matthew McCullough, VP of Product Management, Android Developer

Android 16 QPR2 has released Platform Stability today with Beta 2! That means that the API surface is locked, and the app-facing behaviors are final, so you can incorporate them into your apps and take advantage of our latest platform innovations.

New in the QPR2 Beta

At this later stage in the development cycle, we’re focused on the critical work of readying the platform for release. Here are the few impactful changes we want to highlight:

Testing developer verification

To better protect Android users from repeat offenders, Android is introducing developer verification, a new requirement to make app installation safer by preventing the spread of malware and scams. Starting in September 2026 and in specific regions, Android will require apps to be registered by verified developers to be installed on certified Android devices, with an exception made for installs made through the Android Debug Bridge (ADB).

As a developer, you are free to install apps without verification by using ADB, so you can continue to test apps that are not intended or not yet ready to distribute to the wider consumer population.

For apps that enable user-initiated installation of app packages, Android 16 QPR2 Beta 2 contains new APIs that support developer verification during installation, along with a new adb command to let you force a verification outcome for testing purposes.

adb shell pm set-developer-verification-result

By using this command, (see adb shell pm help for full details)  you can now simulate verification failures. This allows you to understand the end-to-end user experience for both successful and unsuccessful verification, so you can prepare accordingly before enforcement begins.

We encourage all developers who distribute apps on certified Android devices to sign up for early access to get ready and stay updated.

SMS OTP Protection

The delivery of messages containing an SMS retriever hash will be delayed for most apps for three hours to help prevent OTP hijacking. The RECEIVE_SMS broadcast will be withheld and sms provider database queries will be filtered. The SMS will be available to these apps after the three hour delay.

Certain apps such as the default SMS, assistant, and dialer apps, along with connected device companion, system apps, etc will be exempt from this delay, and apps can continue to use the SMS retriever API to access messages intended for them in a timely manner.

Custom app icon shapes

Android 16 QPR2 allows users to select from a list of icon shapes that apply to all app icons and folder previews. Check to make sure that your adaptive icon works well with any shape the user selects.

More efficient garbage collection

The Android Runtime (ART) now includes a Generational Concurrent Mark-Compact (CMC) Garbage Collector in Android 16 QPR2 that focuses collection efforts on newly allocated objects, which are more likely to be garbage. You can expect reduced CPU usage from garbage collection, a smoother user experience with less jank, and improved battery efficiency.

Native step tracking and expanded exercise data in Health Connect

Health Connect now automatically tracks steps using the device’s sensors. If your app has the READ_STEPS permission, this data will be available from the “android” package. Not only does this simplify the code needed to do step tracking, it’s more power efficient as well.

Also, the ExerciseSegment and ExerciseSession data types have been updated. You can now record and read weight, set index, and Rate of Perceived Exertion (RPE) for exercise segments. Since Health Connect is updated independently of the platform, checking for feature availability before writing the data will ensure compatibility with the current local version of Health Connect.

// Check if the expanded exercise features are available
val newFieldsAvailable = healthConnectClient.features.getFeatureStatus(
    HealthConnectFeatures.FEATURE_EXPANDED_EXERCISE_RECORD
) == HealthConnectFeatures.FEATURE_STATUS_AVAILABLE

val segment = ExerciseSegment(
    //...
    // Conditionally add the new data fields
    weight = if (newFieldsAvailable) Mass.fromKilograms(50.0) else null,
    setIndex = if (newFieldsAvailable) 1 else null,
    rateOfPerceivedExertion = if (newFieldsAvailable) 7.0f else null
)

A minor SDK version

QPR2 marks the first Android release with a minor SDK version allowing us to more rapidly innovate with new platform APIs provided outside of our usual once-yearly timeline. Unlike the major platform release (Android 16) in 2025-Q2 that included behavior changes that impact app compatibility, the changes in this release are largely additive and designed to minimize the need for additional app testing.

Your app can safely call the new APIs on devices where they are available by using SDK_INT_FULL and the respective value from the VERSION_CODES_FULL enumeration.

if (Build.VERSION.SDK_INT_FULL >= Build.VERSION_CODES_FULL.BAKLAVA_1) {
    // Call new APIs from the Android 16 QPR2 release
}

You can also use the Build.getMinorSdkVersion() method to get just the minor SDK version number.

val minorSdkVersion = Build.getMinorSdkVersion(VERSION_CODES_FULL.BAKLAVA)

The original VERSION_CODES enumeration can still be used to compare against the SDK_INT enumeration for APIs declared in non minor releases.

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.BAKLAVA) {
    // Call new APIs from the Android 16 release
}

Since minor releases aren’t intended to have breaking behavior changes, they cannot be used in the uses-sdk manifest attributes.

Get started with the Android 16 QPR2 beta

You can enroll any supported Pixel device to get this and future Android Beta updates over-the-air. If you don’t have a Pixel device, you can use the 64-bit system images with the Android Emulator in Android Studio.  If you are already in the Android Beta program, you will be offered an over-the-air update to Beta 2. We’ll update the system images and SDK regularly throughout the Android 16 QPR2 release cycle.

If you are in the Canary program and would like to enter the Beta program, you will need to wipe your device and manually flash it to the beta release.

For the best development experience with Android 16 QPR2, we recommend that you use the latest Canary version of Android Studio Narwhal Feature Drop.

We’re looking for your feedback so please report issues and submit feature requests on the feedback page. The earlier we get your feedback, the more we can include in our work on the final release. Thank you for helping to shape the future of the Android platform.

Posted by Matthew McCullough – VP of Product Management, Android Developer

Today we’re releasing Android 16 quarterly platform release 2 (QPR2) Beta 1, providing you with an early opportunity to try out the APIs and features that are moving Android forward. This beta focuses on several key improvements:

• Enhanced User Experience: A better experience across all form factors, from phones to foldables and tablets.
• Enabling Richer Apps: New APIs for creative expression, productivity, media, and connectivity.
• Developer Productivity: new platform features to help you debug and test your apps.

A minor SDK version

This release marks the first Android beta with a minor SDK version allowing us to more rapidly innovate with new platform APIs provided outside of our usual once-yearly timeline. Unlike the major platform release in Q2 that included behavior changes that impact app compatibility, the changes in this release are largely additive and designed to minimize the need for additional app testing.

Your app can safely call the new APIs on devices where they are available by using SDK_INT_FULL and the respective value from the VERSION_CODES_FULL enumeration.

if (Build.VERSION.SDK_INT_FULL >= Build.VERSION_CODES_FULL.BAKLAVA_1) {
    // Call new APIs from the Android 16 QPR2 release
}

You can also use the Build.getMinorSdkVersion() method to get just the minor SDK version number.

val minorSdkVersion = Build.getMinorSdkVersion(VERSION_CODES_FULL.BAKLAVA)

The original VERSION_CODES enumeration can still be used to compare against the SDK_INT enumeration for APIs declared in non minor releases.

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.BAKLAVA) {
    // Call new APIs from the Android 16 release
}

Since minor releases aren’t intended to have breaking behavior changes, they cannot be used in the uses-sdk manifest attributes.

UI, system experience, and accessibility

This release introduces refinements to the system UI, user experience, and accessibility, from theming changes to input handling to new APIs for adaptive apps.

Dark theme’s new expanded option

To create a more consistent user experience for users who have low vision, photosensitivity, or simply those who prefer a dark system-wide appearance, an expanded option under dark theme is being introduced. When enabled by a user, the system will intelligently invert the UI of apps that appear light despite users having selected the dark theme.

The system uses your app’s isLightTheme theme attribute to determine whether to apply inversion. If your app inherits from one of the standard DayNight themes, this is done automatically for you, otherwise make sure to declare isLightTheme=”false” in your dark theme to ensure your app is not inadvertently inverted. Standard Android Views, Composables, and WebViews will be inverted, while custom rendering engines like Flutter will not. The system also automatically darkens your app’s splash screen and adjusts the status bar color for contrast.

This is largely intended as an accessibility feature. We strongly recommend implementing a native dark theme, which gives you full control over your app’s appearance; you can protect your brand’s identity, ensure text is always readable, and prevent any visual glitches from happening when your UI is automatically inverted, guaranteeing a polished, reliable experience for your users.

Auto-themed app icons

We recommend that apps control the design of their themed app icon by including a monochrome layer within their adaptive icon. You can preview the themed version of your app icon using Android Studio.

Android 16 QPR2 can automatically generate a themed icon for your app if you don’t provide a dedicated one. The system applies a color filtering algorithm to your existing launcher icon to render it in a monochrome style, allowing it to integrate with the user’s chosen theme.

Interactive chooser sessions

This new capability allows your app’s UI to remain fully interactive when the system sharesheet is open. You can display custom UI, dynamically update the content or targets in the Chooser, and programmatically control its state. You’ll use the new ChooserManager to start an interactive session and the ChooserSession object to manage it.

Smoother Android migrations

A new 3rd-party Data Transfer API is being introduced to enable more reliable and secure data migration between Android and iOS devices. Your app can now opt-in to participate in cross-platform data transfers. This requires updating your app’s data extraction rules XML with a new <cross-platform-transfer> tag and implementing custom logic in the BackupAgent to export and import app data to and from other platforms. New methods are also being added to BackupAgent, such as onMeasureFullBackup, to give you more control over the backup process for large datasets.

PDF document editing

The android.graphics.pdf package has been significantly expanded to support annotating and editing PDF documents. This class provides core APIs for apps that wish to create their own PDF user experience, and is the foundation for the Jetpack PDF library, which also provides the UI for an embedded PDF viewer. The PdfRenderer.Page class now allows you to:

• Edit Annotations: Add, remove, and update annotations like HighlightAnnotation, StampAnnotation, and FreeTextAnnotation.
• Edit Page Content: Add, update, or remove page objects, including PdfPageImageObject, PdfPagePathObject, and PdfPageTextObject.
• Query Page Objects: Use getPageObjects() to get a list of page objects, and getTopPageObjectAtPosition() to identify what object is at a specific coordinate.

With these new APIs, your apps can support use cases such as form filling, document signing, document review/collaboration, interactive study/note taking, and more. We’re also working to bring these annotation and editing capabilities to the Jetpack PDF library to further simplify the integration of these features.

Display Topology API

To support advanced multi-display experiences, the new Display Topology API provides your app with information about how multiple displays are arranged — their relative positions and absolute bounds. A new Display.isInternal() method helps distinguish between built-in and other screens. You can also register a TopologyListener to receive real-time updates when the display setup changes.

Device-aware ViewConfiguration

ViewConfiguration values (e.g., touch slop, long press timeout) can now be tailored to individual virtual devices. This means that an app running on a virtual device will now use configuration values appropriate for that device’s characteristics, not the host device’s.

To ensure your app behaves correctly in multi-display scenarios (e.g., an activity on the phone and another on a connected smart display), you should migrate from static ViewConfiguration methods to instance-based methods by calling ViewConfiguration.get(context).

// Instead of this:
// val longPressTimeout = ViewConfiguration.getLongPressTimeout()

// Do this, using the specific Activity's context:
val vc = ViewConfiguration.get(myActivityContext)
val longPressTimeout = vc.longPressTimeout

More granular haptic feedback control

A new API allows you to specify the usage in terms of VibrationAttributes (e.g., USAGE_TOUCH) when triggering haptic feedback. This ensures your app’s vibrations align more precisely with user-defined intensity settings for different contexts, like touch vs. accessibility.

Use the new View.performHapticFeedback(HapticFeedbackRequest) method to pass a request that specifies both the HapticFeedbackConstant and the desired Usage. Existing calls will continue to work as before.

Quick Settings Tile categories

To improve the discoverability of your app’s Quick Settings tiles, you can now optionally assign them to a predefined category. By adding a <meta-data> tag to your TileService declaration in the AndroidManifest.xml, your tile can be grouped with similar system tiles in the Quick Settings Edit mode.

Example for a connectivity-related tile:

<service
    android:name=".MyConnectivityTileService"
    ... >
    <intent-filter>
        <action android:name="android.service.quicksettings.action.QS_TILE" />
    </intent-filter>
    <meta-data
        android:name="android.service.quicksettings.TILE_CATEGORY"
        android:value="android.service.quicksettings.CATEGORY_CONNECTIVITY" />
</service>

Additional UI and System Experience updates

• Controlled Mouse Scrolling: A new mouse system setting allows users to enable “Controlled Scrolling” for external mice, which makes scrolling speed directly proportional to the physical wheel movement.
• Picture-in-Picture (PiP) Refactoring: The underlying mechanics of PiP transitions have been refactored, resulting in smoother and more reliable animations.
• Public System Update Intent: The android.settings.ACTION_SYSTEM_UPDATE_SETTINGS intent action is now a public API, providing a standardized way for apps to direct users to their device’s system update page. See the documentation for how to launch this intent securely.
• Time Zone Notifications: The system will now notify users when their time zone is automatically changed.
• Files Desktop UX: The DocumentsUI file manager is receiving a Material 3 Expressive design refresh and will show “Visual Signals” for file operations.
• Printer Info Screen: The Android Default Print Service now displays a more comprehensive printer information screen, including status and supply levels.

Media and Audio

This release brings support for new audio formats, provides more granular control over audio playback, and enhances the volume experience for voice interactions.

IAMF decoding support

Android 16 QPR2 adds software decoding for Immersive Audio Model and Formats (IAMF) audio. IAMF is a new open-source spatial audio format, available under a royalty free license from Alliance for Open Media. The IAMF decoder supports Opus, PCM, AAC and FLAC audio within IAMF files, in full compliance with the IAMF specification. You can leverage IAMF to deliver rich, immersive audio experiences in your Android apps.

ExoPlayer will automatically use the framework IAMF decoder when available. For backwards compatibility, the IAMF ExoPlayer Extension can also be used to decode IAMF.

Personal Audio Sharing in Output Switcher

Personal Audio Sharing for Bluetooth Low Energy (LE) Audio devices is now integrated directly into the system’s Output Switcher. This system-level UI enhancement provides a more intuitive and consistent way for users to manage and share audio from your app to multiple LE Audio devices without requiring any changes to your existing audio playback code.

New AAudio APIs for performance and control

The native AAudio library for high-performance audio has been updated. These new APIs provide more control and better performance for demanding audio applications that rely on the NDK, especially those focused on power-efficient, high-quality playback.

• Partial Buffer Processing in Callbacks: A new data callback, AAudioStream_partialDataCallback, allows your app to specify exactly how many frames it has processed. This gives you more flexibility when working with large data buffers (like in compressed offload scenarios), as you no longer need to provide the entire requested buffer at once.
• PCM Offload over MMAP: To improve power efficiency, AAudio now supports PCM offload over the MMAP path. You can request this by setting the performance mode to AAUDIO_PERFORMANCE_MODE_POWER_SAVING_OFFLOADED. A new API, AAudioStream_flushFromFrame, is also available for MMAP offload streams to reset the playback position when a user seeks or skips a track.

Additional Media and Audio updates

• HDR/SDR Brightness Slider: A new system-level slider allows users to adjust the perceived brightness of HDR content. Your app’s HDR content will automatically adapt to this user preference without any required code changes.
• LE Audio Enhancements: Support has been added for LE Audio connection subrating to speed up reconfiguration (onSubrateChange). The platform also now also supports the OPUS Hi-Res (SOURCE_CODEC_TYPE_OPUS_HI_RES) codec.
• Photo Picker: The Photo Picker can now be launched with a specific album or search query highlighted using extras like EXTRA_PICK_IMAGES_HIGHLIGHT_ALBUM and EXTRA_PICK_IMAGES_HIGHLIGHT_SEARCH_RESULTS.

Connectivity

New APIs are available to support emerging connectivity standards, enhance device management, and give users more control over network privacy.

Companion Device Management enhancements

The Companion Device Manager (CDM) is receiving several updates to improve cross-app interactions and user control in system Settings.

• Custom device icons: Your app can now provide a custom icon for self-managed device associations by supplying a Bitmap using the new setDeviceIcon() method on the AssociationRequest.Builder. The icon will be displayed in system dialogs and settings, creating a more recognizable and trusted user experience. You can also retrieve the icon for an existing association using AssociationInfo.getDeviceIcon().
• Association removal notifications: Your app can now listen for the EVENT_ASSOCIATION_REMOVED callback via startObservingDevicePresence. This event fires when a user “forgets” a device in system Settings or when your app’s data is cleared, allowing your app to maintain an accurate connection state.
• Cross-App verification: System apps can now verify if your companion app has a legitimate association with a device and monitor the presence of devices managed by your app using the DeviceId created during association with the new createAndSetDeviceId API.

Additional connectivity updates

• Bluetooth: BluetoothLeScanner now supports passive scanning by delivering advertising packets without sending a scan response, using ScanSettings.SCAN_TYPE_PASSIVE. A reason for bond loss is now provided via BluetoothDevice.EXTRA_BOND_LOSS_REASON. You can also now retrieve service UUIDs directly from BLE advertising data using the BluetoothDevice.EXTRA_UUID_LE extra.
• Wi-Fi RTT Ranging: The ranging stack has been updated with new classes and parameters to support Wi-Fi Round-Trip-Time (RTT) ranging against stations (RttStationRangingParams, RttStationRangingParams.Builder).
• Phone Number Parsing: A new PhoneNumberManager is available for parsing and validating phone numbers from an IMS P-Associated-URI header. You can access it via getSystemService with the TELEPHONY_PHONE_NUMBER_SERVICE parameter . The ParsedPhoneNumber class uses the passed-in country ISO setting to return an E.164 representation of a parsed number.

MediaRouter Network Privacy improvements

To support casting to devices over new mediums like Bluetooth and UWB, the MediaRouter framework is evolving. Your app can now cast to a wider array of devices, including in-car displays and gym equipment, while contributing to a more privacy-preserving discovery model.

The recommended approach is to use the system Output Switcher, which handles discovery over sensitive mediums without requiring your app to hold extra permissions. If your app uses a custom in-app picker and you want to discover devices over these new mediums, you will need to request permissions from the NEARBY_DEVICES permission group (e.g., BLUETOOTH_SCAN). New MediaRoute2Info.Builder methods are available for route providers to declare required permissions.

Privacy and Security

This release continues to enhance user privacy and device security with new features for locking devices and managing sensitive data.

Secure Lock Device

A new system-level security state, Secure Lock Device, is being introduced. When enabled (e.g., remotely via “Find My Device”), the device locks immediately and requires the primary PIN, pattern, or password to unlock, heightening security. When active, notifications and quick affordances on the lock screen will be hidden, and biometric unlock may be temporarily disabled.

Phone Theft Protection toggle

A user-facing toggle is being added to Theft Protection Settings, allowing users to enable or disable the “Failed Authentication Lock” security feature (introduced in Android 15) that automatically locks down your device after multiple failed login attempts.

Additional Security updates

• Biometric fallback Options: BiometricPrompt.Builder can now add fallback authentication options (e.g., using a password or QR code) with addFallbackOption().
• Keyinfo Improvement: The KeyInfo class now provides a method isUnlockedDeviceRequired() which checks whether the key can be used only when the device is unlocked.

Developer productivity

New features and APIs are available to streamline debugging, testing, and profiling.

Widget engagement metrics

New AppWidgetManager APIs allow you to query for user interaction events with your widgets within a given time range, including clicks, scrolls, and impressions, providing data you can use to help you improve your widget’s design.

Early warnings for 16KB page size compatibility

To help you prepare for the future requirement that all apps are 16 KB page-aligned, Android will now show alignment warnings on 4 KB production devices for debuggable apps installed via ADB. If your app is not 16 KB-aligned, a dialog will appear at launch, listing the specific native libraries that need to be fixed — allowing you to address them ahead of the Play Store deadline.

Enhanced profiling with new system triggers

The ProfilingManager has added support for new system-initiated profiling triggers, including when your app is killed by the user from the Recents screen, Force Stop, or the task manager. You can also now request the currently running background system trace using ProfilingManager.requestRunningSystemTrace(), allowing you to capture profiling that has occurred before the request takes place. Note that the background trace runs intermittently and will not be available all the time.

Debug printing with a new developer toggle

A new “Verbose print logging” toggle is now available in Developer Options. When enabled, the Android Print Framework and associated services will output additional debug information to logcat, which can help you troubleshoot printing-related issues in your apps.

More robust testing for desktop and multi-display experiences

To facilitate more robust testing of your apps on connected displays, new public APIs are available in UiAutomation to programmatically capture screenshots on non-default displays. Additionally, the AccessibilityWindowInfo.refresh() method is now public, allowing accessibility services to ensure they are working with the most up-to-date window information.

You can integrate these new UiAutomation capabilities into your test suites to expand coverage for your app’s desktop mode or external monitor use cases. For accessibility service developers, calling refresh() can improve the reliability of your service.

• API for Backported Fixes: Android 16 QPR2 contains support for the upcoming androidx.core:core-backported-fixes library, which will allow your app to programmatically query if a specific critical bug has been fixed on a device, enabling you to roll out features that depend on the fix much faster, without waiting for an OS release.
• GUI Apps in Linux Terminal: The Linux terminal feature is being expanded to support running Linux GUI applications directly within the terminal environment virtual machine.
• RootView Changed Listener: The WindowInspector class now includes addGlobalWindowViewsListener(), which allows your app or testing framework to be notified in real-time when root views (like Toasts) are added or removed, improving telemetry and test efficiency.

Program timeline

The Android 16 QPR2 beta program runs from August 2025 until the final public release in Q4. At key development milestones, we’ll deliver updates for your development and testing environments. Each update includes SDK tools, system images, emulators, API reference, and API diffs. We’ll highlight new APIs and features for you to try out as they are ready to test in blogs and on the Android 16 developer website.

We’re targeting October of 2025 for our Platform Stability milestone. At this milestone, we’ll deliver final SDK/NDK APIs. From that time you’ll have several months before the final release to complete any integrations. Check out the release timeline details for milestones and updates.

Get started with the Android 16 QPR2 beta

You can enroll any supported Pixel device to get this and future Android Beta updates over-the-air. If you don’t have a Pixel device, you can use the 64-bit system images with the Android Emulator in Android Studio. If you are already in the Android Beta program, you will be offered an over-the-air update to Beta 1. We’ll update the system images and SDK regularly throughout the Android 16 QPR2 release cycle.

If you are in the Canary program and would like to enter the Beta program, you will need to wipe your device and manually flash it to the beta release.

For the best development experience with Android 16 QPR2, we recommend that you use the latest Canary of the feature drop of Android Studio (Narwhal).

We’re looking for your feedback so please report issues and submit feature requests on the feedback page. The earlier we get your feedback, the more we can include in our work on the final release.

Thank you for helping to shape the future of the Android platform.

Posted by Dan Galpin – Android Developer Relations

To better support you and provide earlier, more consistent access to in-development features, we are announcing a significant evolution in our pre-release program. Moving forward, the Android platform will have a Canary release channel, which will replace the previous developer preview program. This Canary release channel will function alongside the existing beta program.

This change is designed to provide a more streamlined and continuous opportunity for you to try out new platform capabilities and provide feedback throughout the entire year, not just in the early months of a new release cycle.

Limitations of the previous developer preview model

The Developer Preview program has been a critical part of our release cycle, but its structure had inherent limitations:

• Developer Previews were not tied to a release channel, and had to be manually flashed to devices every time the cycle would restart.
• Because previews were tied to the next designated Android release, they were only available during the earliest part of the cycle. Once a platform version reached the Beta stage, the preview track would end, creating a gap where features that were promising but not yet ready for Beta had no official channel for feedback.

A continuous flow of features with the Canary channel

The new Android platform Canary channel addresses these challenges directly. By flashing your supported Pixel device to the Canary release channel, you can now receive a continuous, rolling stream of the latest platform builds via over-the-air (OTA) updates.

• You can try out and provide input on new features and planned behavior changes in their earliest stages. These changes may not always make it into a stable Android release.
• The Canary release channel will run in parallel with the beta program. The beta program remains the way for you to try a more polished set of likely soon-to-be-released features.
• You can use the Canary builds with your CI to see if any of our in-development features cause unexpected problems with your app, maximizing the time we have to address your concerns.

Who should use the Canary channel?

The Canary channel is intended for developers that want to explore and test with the earliest pre-release Android APIs and potential behavior changes. Builds from the Canary channel will have passed our automated tests as well as experienced a short test cycle with internal users. You should expect bugs and breaking changes. These bleeding-edge builds will not be the best choice for someone to use as their primary or only device.

The existing beta channel will remain the primary way for you to make sure that your apps are both compatible with and take advantage of upcoming platform features.

Getting started and providing feedback

You can use the Android Flash Tool to get the most recent Canary build onto your supported Pixel device. Once flashed, you should expect OTA updates for the latest Canary builds as they become available. To exit the channel, flash a Beta or Public build to your device. This will require a data partition wipe.

Canary releases will be available on the Android Emulator through the Device Manager in Android Studio (currently, just in the Android Studio Canary channel), and Canary SDKs will be available for you to develop against through the SDK Manager.

Since most behavior changes require targeting a release, you can target Canary releases the way you can target any other platform SDK version, or use the Compatibility Framework with supported features to enable behavior changes in your apps.

Feedback is a critical component of this new program, so please file feature feedback and bug reports on your Canary experience through the Google Issue Tracker.

By transitioning to a true Canary channel, we aim to create a more transparent, collaborative, and efficient development process, giving you the seamless access you need to prepare for the future of Android.

Posted by Matthew McCullough – VP of Product Management, Android Developer

Today, Android is launching a few updates across the platform! This includes the start of Android 16’s rollout with details for both developers and users, a Developer Preview for enhanced Android desktop experiences with connected displays, updates for Android users across Google apps and more, plus the June Pixel Drop. We’re also recapping all the Google I/O updates for Android developers focused on building excellent, adaptive Android apps.

Today we’re releasing Android 16 and making it available on most supported Pixel devices. Look for new devices running Android 16 in the coming months.

This also marks the availability of the source code at the Android Open Source Project (AOSP). You can examine the source code for a deeper understanding of how Android works, and our focus on compatibility means that you can leverage your app development skills in Android Studio with Jetpack Compose to create applications that thrive across the entire ecosystem.

Major and minor SDK releases

With Android 16, we’ve added the concept of a minor SDK release to allow us to iterate our APIs more quickly, reflecting the rapid pace of the innovation Android is bringing to apps and devices.

We plan to have another release in Q4 of 2025 which also will include new developer APIs. Today’s major release will be the only release in 2025 to include planned app-impacting behavior changes.
In addition to new developer APIs, the Q4 minor release will pick up feature updates, optimizations, and bug fixes.

We’ll continue to have quarterly Android releases. The Q3 update in-between the API releases is providing much of the new visual polish associated with Material Expressive, and you can get the Q3 beta today on your supported Pixel device.

Camera and media APIs to empower creators

Android 16 enhances support for professional camera users, allowing for night mode scene detection, hybrid auto exposure, and precise color temperature adjustments. It’s easier than ever to capture motion photos with new Intent actions, and we’re continuing to improve UltraHDR images, with support for HEIC encoding and new parameters from the ISO 21496-1 draft standard. Support for the Advanced Professional Video (APV) codec improves Android’s place in professional recording and post-production workflows, with perceptually lossless video quality that survives multiple decodings/re-encodings without severe visual quality degradation.

Also, Android’s photo picker can now be embedded in your view hierarchy, and users will appreciate the ability to search cloud media.

More consistent, beautiful apps

Android 16 introduces changes to improve the consistency and visual appearance of apps, laying the foundation for the upcoming Material 3 Expressive changes. Apps targeting Android 16 can no longer opt-out of going edge-to-edge, and ignores the elegantTextHeight attribute to ensure proper spacing in Arabic, Lao, Myanmar, Tamil, Gujarati, Kannada, Malayalam, Odia, Telugu or Thai.

Adaptive Android apps

With Android apps now running on a variety of devices and more windowing modes on large screens, developers should build Android apps that adapt to any screen and window size, regardless of device orientation. For apps targeting Android 16 (API level 36), Android 16 includes changes to how the system manages orientation, resizability, and aspect ratio restrictions. On displays with smallest width >= 600dp, the restrictions no longer apply and apps will fill the entire display window. You should check your apps to ensure your existing UIs scale seamlessly, working well across portrait and landscape aspect ratios. We’re providing frameworks, tools, and libraries to help.

You can test these overrides without targeting using the app compatibility framework by enabling the UNIVERSAL_RESIZABLE_BY_DEFAULT flag. Read more about changes to orientation and resizability APIs in Android 16.

Predictive back by default and more

Apps targeting Android 16 will have system animations for back-to-home, cross-task, and cross-activity by default. In addition, Android 16 extends predictive back navigation to three-button navigation, meaning that users long-pressing the back button will see a glimpse of the previous screen before navigating back.

To make it easier to get the back-to-home animation, Android 16 adds support for the onBackInvokedCallback with the new PRIORITY_SYSTEM_NAVIGATION_OBSERVER. Android 16 additionally adds the finishAndRemoveTaskCallback and moveTaskToBackCallback for custom back stack behavior with predictive back.

Consistent progress notifications

Android 16 introduces Notification.ProgressStyle, which lets you create progress-centric notifications that can denote states and milestones in a user journey using points and segments. Key use cases include rideshare, delivery, and navigation. It’s the basis for Live Updates, which will be fully realized in an upcoming Android 16 update.

Custom AGSL graphical effects

Android 16 adds RuntimeColorFilter and RuntimeXfermode, allowing you to author complex effects like Threshold, Sepia, and Hue Saturation in AGSL and apply them to draw calls.

Help to create better performing, more efficient apps and games

From APIs to help you understand app performance, to platform changes designed to increase efficiency, Android 16 is focused on making sure your apps perform well. Android 16 introduces system-triggered profiling to ProfilingManager, ensures at most one missed execution of scheduleAtFixedRate is immediately executed when the app returns to a valid lifecycle for better efficiency, introduces hasArrSupport and getSuggestedFrameRate(int) to make it easier for your apps to take advantage of adaptive display refresh rates, and introduces the getCpuHeadroom and getGpuHeadroom APIs along with CpuHeadroomParams and GpuHeadroomParams in SystemHealthManager to provide games and resource-intensive apps estimates of available GPU and CPU resources on supported devices.

JobScheduler updates

JobScheduler.getPendingJobReasons in Android 16 returns multiple reasons why a job is pending, due to both explicit constraints you set and implicit constraints set by the system. The new JobScheduler.getPendingJobReasonsHistory returns the list of the most recent pending job reason changes, allowing you to better tune the way your app works in the background.

Android 16 is making adjustments for regular and expedited job runtime quota based on which apps standby bucket the app is in, whether the job starts execution while the app is in a top state, and whether the job is executing while the app is running a Foreground Service.

To detect (and then reduce) abandoned jobs, apps should use the new STOP_REASON_TIMEOUT_ABANDONED job stop reason that the system assigns for abandoned jobs, instead of STOP_REASON_TIMEOUT.

16KB page sizes

Android 15 introduced support for 16KB page sizes to improve the performance of app launches, system boot-ups, and camera starts, while reducing battery usage. Android 16 adds a 16 KB page size compatibility mode, which, combined with new Google Play technical requirements, brings Android closer to having devices shipping with this important change. You can validate if your app needs updating using the 16KB page size checks & APK Analyzer in the latest version of Android Studio.

ART internal changes

Android 16 includes the latest updates to the Android Runtime (ART) that improve the Android Runtime’s (ART’s) performance and provide support for additional language features. These improvements are also available to over a billion devices running Android 12 (API level 31) and higher through Google Play System updates. Apps and libraries that rely on internal non-SDK ART structures may not continue to work correctly with these changes.

Privacy and security

Android 16 continues our mission to improve security and ensure user privacy. It includes Improved security against Intent redirection attacks, makes MediaStore.getVersion unique to each app, adds an API that allows apps to share Android Keystore keys, incorporates the latest version of the Privacy Sandbox on Android, introduces a new behavior during the companion device pairing flow to protect the user’s location privacy, and allows a user to easily select from and limit access to app-owned shared media in the photo picker.

Local network permission testing

Android 16 allows your app to test the upcoming local network permission feature, which will require your app to be granted NEARBY_WIFI_DEVICES permission. This change will be enforced in a future Android major release.

An Android built for everyone

Android 16 adds features such as Auracast broadcast audio with compatible LE Audio hearing aids, Accessibility changes such as extending TtsSpan with TYPE_DURATION, a new list-based API within AccessibilityNodeInfo, improved support for expandable elements using setExpandedState, RANGE_TYPE_INDETERMINATE for indeterminate ProgressBar widgets, AccessibilityNodeInfo getChecked and setChecked(int) methods that support a “partially checked” state, setSupplementalDescription so you can provide text for a ViewGroup without overriding information from its children, and setFieldRequired so apps can tell an accessibility service that input to a form field is required.

Outline text for maximum text contrast

Android 16 introduces outline text, replacing high contrast text, which draws a larger contrasting area around text to greatly improve legibility, along with new AccessibilityManager APIs to allow your apps to check or register a listener to see if this mode is enabled.

Get your apps, libraries, tools, and game engines ready!

If you develop an SDK, library, tool, or game engine, it’s even more important to prepare any necessary updates now to prevent your downstream app and game developers from being blocked by compatibility issues and allow them to target the latest SDK features. Please let your developers know if updates to your SDK are needed to fully support Android 16.

Testing involves installing your production app or a test app making use of your library or engine using Google Play or other means onto a device or emulator running Android 16. Work through all your app’s flows and look for functional or UI issues. Review the behavior changes to focus your testing. Each release of Android contains platform changes that improve privacy, security, and overall user experience, and these changes can affect your apps. Here are several changes to focus on that apply, even if you aren’t yet targeting Android 16:

• JobScheduler: JobScheduler quotas are enforced more strictly in Android 16; enforcement will occur if a job executes while the app is on top, when a foreground service is running, or in the active standby bucket. setImportantWhileForeground is now a no-op. The new stop reason STOP_REASON_TIMEOUT_ABANDONED occurs when we detect that the app can no longer stop the job.
• Broadcasts: Ordered broadcasts using priorities only work within the same process. Use another IPC if you need cross-process ordering.
• ART: If you use reflection, JNI, or any other means to access Android internals, your app might break. This is never a best practice. Test thoroughly.
• Intents: Android 16 has stronger security against Intent redirection attacks. Test your Intent handling, and only opt-out of the protections if absolutely necessary.
• 16KB Page Size: If your app isn’t 16KB-page-size ready, you can use the new compatibility mode flag, but we recommend migrating to 16KB for best performance.
• Accessibility: announceForAccessibility is deprecated; use the recommended alternatives. Make sure to test with the new outline text feature.
• Bluetooth: Android 16 improves Bluetooth bond loss handling that impacts the way re-pairing occurs.

Other changes that will be impactful once your app targets Android 16:

• User Experience: Changes include the removal of edge-to-edge opt-out, required migration or opt-out for predictive back, and the disabling of elegant font APIs.
• Core Functionality: Optimizations have been made to fixed-rate work scheduling.
• Large Screen Devices: Orientation, resizability, and aspect ratio restrictions will be ignored. Ensure your layouts support all orientations across a variety of aspect ratios to adapt to different surfaces.
• Health and Fitness: Changes have been implemented for health and fitness permissions.

Get your app ready for the future:

• Local network protection: Consider testing your app with the upcoming Local Network Protection feature. It will give users more control over which apps can access devices on their local network in a future Android major release.

Remember to thoroughly exercise libraries and SDKs that your app is using during your compatibility testing. You may need to update to current SDK versions or reach out to the developer for help if you encounter any issues.

Once you’ve published the Android 16-compatible version of your app, you can start the process to update your app’s targetSdkVersion. Review the behavior changes that apply when your app targets Android 16 and use the compatibility framework to help quickly detect issues.

Get started with Android 16

Your Pixel device should get Android 16 shortly if you haven’t already been on the Android Beta. If you don’t have a Pixel device, you can use the 64-bit system images with the Android Emulator in Android Studio. If you are currently on Android 16 Beta 4.1 and have not yet taken an Android 16 QPR1 beta, you can opt out of the program and you will then be offered the release version of Android 16 over the air.

For the best development experience with Android 16, we recommend that you use the latest Canary build of Android Studio Narwhal. Once you’re set up, here are some of the things you should do:

• Test your current app for compatibility, learn whether your app is affected by changes in Android 16, and install your app onto a device or Android Emulator running Android 16 and extensively test it.

Thank you again to everyone who participated in our Android developer preview and beta program. We’re looking forward to seeing how your apps take advantage of the updates in Android 16, and have plans to bring you updates in a fast-paced release cadence going forward.

For complete information on Android 16 please visit the Android 16 developer site.