The future is adaptive: Changes to orientation and resizability APIs in Android 16

Posted by Maru Ahues Bouza – Director, Product Management

With 3+ billion Android devices in use globally, the Android ecosystem is more vibrant than ever. Android mobile apps run on a diverse range of devices, from phones and foldables to tablets, Chromebooks, cars, and most recently XR. Users buy into an entire device ecosystem and expect their apps to work across all devices. To thrive in this multi-device environment, your apps need to adapt seamlessly to different screen sizes and form factors.

Many Android apps rely on user interface approaches that work in a single orientation and/or restrict resizability. However, users want apps to make full use of their large screens, so Android device manufacturers added well-received features that override these app restrictions.

With this in mind, Android 16 is removing the ability for apps to restrict orientation and resizability at the platform level, and shifting to a consistent model of adaptive apps that seamlessly adjust to different screen sizes and orientations. This change will reduce fragmentation with behavior that better meets user expectations, and improves accessibility by respecting the user’s preferred orientation. We're building tools, libraries, and platform APIs to help you do this to provide a consistently excellent user experience across the entire Android ecosystem.

What's changing?

Starting with Android 16, we're phasing out manifest attributes and runtime APIs used to restrict an app's orientation and resizability, enabling better user experiences for many apps across devices.

These changes will initially apply when the app is running on a large screen, where “large screen” means that the smaller dimension of the display is greater than or equal to 600dp. This includes:

• Inner displays of large screen foldables
• Tablets, including desktop windowing
• Desktop environments, including Chromebooks

The following manifest attributes and APIs will be ignored for apps targeting Android 16 (SDK 36) on large screens:

There are some exceptions to these changes for controlling orientation, aspect ratio, and resizability:

• As mentioned before, these changes won't apply for screens that are smaller than sw600dp (e.g. most phones, flippables, outer displays on large screen foldables)
• Games will be excluded from these changes, based on the android:appCategory flag

Also, users have control. They can explicitly opt-in to using the app’s default behavior in the aspect ratio settings.

Apps, targeting API level 36, that were previously letterboxed on large screen devices will fill the display in landscape orientation on Android 16

Get ready for this change, by making your app adaptive

Apps will need to support landscape and portrait layouts for window sizes in the full range of aspect ratios that users can choose to use apps in, as there will no longer be a way to restrict the aspect ratio and orientation to portrait or to landscape.

To test if your app will be impacted by these changes, use the Android 16 Beta 1 developer preview with the Pixel Tablet and Pixel Fold series emulators in Android Studio, and either set targetSdkPreview = “Baklava” or use the app compatibility framework by enabling the UNIVERSAL_RESIZABLE_BY_DEFAULT flag.

For existing apps that restrict orientation and aspect ratio, these changes may result in problems like overlapping layouts. To solve these issues and meet user expectations, our vision is that apps are built to be adaptive, to provide an optimal experience whether someone is using the app on a phone, foldable, tablet, Chromebook, XR or in a car.

Resolving common problems

• Avoid stretched UI components: If layouts were designed and built with the assumption of phone screens, then app functionality may break for other aspect ratios. For example, if a layout was built assuming a portrait aspect ratio, then UI elements that fill the max width of the window will appear stretched in landscape-oriented windows. If layouts aren’t built to scroll, then users may not be able to click on buttons or other UI elements that are offscreen, resulting in confusing or broken behavior. Add a maximum width to components to avoid stretching, and add scrolling to ensure all content is reachable.
• Ensure camera compatibility in both orientations: Camera viewfinder previews might assume a specific aspect ratio and orientation relative to the camera sensor, resulting in stretching or flipped previews when those assumptions are broken. Ensure viewfinders rotate properly and account for the UI aspect ratio differing from the sensor aspect ratio.
• Preserve state across when window size changes: Removing orientation and aspect ratio restrictions also means that the window sizes of apps will change more frequently in response to how the user prefers to use an app, such as by rotating, folding, or resizing an app in multi-window or free-form windowing modes. Orientation changes and resizing will result in Activity recreation by default. To ensure a good user experience, it is critical that app state is preserved through these configuration changes so that users don’t lose their place in the app when changing posture or changing windowing modes.

To account for different window sizes and aspect ratios, use window size classes to drive layout behavior in a way that doesn’t require device-specific customizations. Apps should also be built with the assumption that window sizes will frequently change. It’s not necessary to build duplicate orientation-specific layouts - instead, ensure your existing UIs can re-layout well no matter what the window size is. If you have a landscape- or portrait-specific layout, those layouts will still be used.

Optimizing for window sizes by building adaptive

If you're already building adaptive layouts and supporting all orientations, you're set up for success as your app will be prepared for each of the device types and windowing modes your users want to use your app in and these changes should have minimal impact.

We've also got a range of testing resources to help you guarantee reliability. You can automate testing with tools like the Espresso testing framework and Jetpack Compose testing APIs.

FlipaClip is a great example of why building for multiple form-factors matters: they saw 54% growth in tablet users in the four months after they optimized their app to be adaptive.

Timeline

We understand that the changes are significant for apps that have traditionally only supported portrait orientation. UI issues like buttons going off screen, overlapping content, or screens with camera viewfinders may need adjustments.

To help you plan ahead and make the necessary adjustments, here’s the planned timeline outlining when these changes will take effect:

• Android 16 (2025): Changes described above will be the baseline experience for large screen devices (smallest screen width > 600dp) for apps that target API level 36, with the option for developers to opt-out.
• Android release in 2026: Changes described above will be the baseline experience for large screen devices (smallest screen width >600dp) for apps that target API level 37. Developers will not have an option to opt-out.

The deadlines for targeting a specific API level are app store specific. For Google Play, the plan is that targeting API 36 will be required in August 2026 and targeting API 37 will be required in August 2027.

Preparing for Android 16

Refer to the Android 16 changes page for all changes impacting apps in Android 16, as well as additional resources for updating your apps if you are impacted. To test your app, download the Android 16 Beta 1 developer preview and update to targetSdkPreview = “Baklava” or use the app compatibility framework to enable specific changes.

We're committed to helping developers embrace this new era of adaptive apps and unlock the full potential of their apps across the diverse Android ecosystem. Check out the do’s and don’ts for designing and building across multiple window sizes and form factors, as well how to test across the variety of devices that your app will be used in.

Stay tuned for more updates and resources as we approach the release of Android 16!