Android Is Taking Away Orientation Locks on Large Screens. Here’s What Developers Need to Know

For years, Android developers have had a simple way to control how their apps behave: tell the system that an activity should stay in portrait, keep it in landscape, or otherwise restrict how the app can rotate.

That familiar approach is changing.

Starting with Android 16, API level 36, apps targeting API 36 or higher can no longer rely on orientation restrictions on large-screen devices. That includes tablets and other devices where the display has a smallest width of 600dp or more. On those screens, Android can ignore an app's requested orientation and allow the user and the device to determine how the app is displayed.

And this is not just a small API change. It represents a bigger shift in how Android expects developers to think about app layouts.

The old assumption: "This app is portrait"

Many Android apps were built around an implicit assumption:

This is a phone app, so portrait is the normal orientation.

Developers could enforce that assumption through the manifest or at runtime. A typical application might declare a portrait-only activity, or call setRequestedOrientation() when it needed to lock the screen.

That worked reasonably well when the majority of Android devices were phones with relatively predictable screen sizes.

But today's Android ecosystem is considerably messier, in the good sense.

There are tablets, foldables, desktop-style windows, external displays and devices whose natural orientation may not match what an app developer expects. Google is increasingly treating Android as a platform where an application should be able to adapt to the space it is given rather than dictate the shape of that space.

What actually changes in Android 16?

For apps targeting Android 16/API 36 or higher, Android ignores several mechanisms that developers previously used to restrict large-screen applications.

That includes:

• android:screenOrientation
• android:resizeableActivity
• android:minAspectRatio
• android:maxAspectRatio
• setRequestedOrientation()
• getRequestedOrientation()

The orientation values developers are accustomed to, such as portrait, landscape, sensorPortrait, and sensorLandscape, are ignored on those large displays.

So imagine an app that has always been portrait-only.

On a phone, it can continue behaving as expected.

On a sufficiently large tablet, however, targeting API 36 means the system is allowed to display that app in landscape even though the developer requested portrait.

That can be a rather uncomfortable surprise.

Why is Google doing this?

Google's reasoning is fairly straightforward: large screens are no longer supposed to behave like oversized phones.

A tablet can be used in portrait or landscape. A foldable can change its available space dramatically. Desktop-style windowing can give an app a window that changes size while the application is running.

From Android's perspective, locking an application to one orientation makes these experiences harder to support.

Google describes orientation and resizability restrictions as increasingly restrictive in a world of multiple device types and window sizes. The direction Android is taking is therefore toward adaptive applications, where the UI responds to the available space rather than assuming one fixed screen shape.

In other words, Android is effectively saying:

"Don't tell me what shape your screen must be. Tell me how your UI behaves when the shape changes."

That is a reasonable philosophy.

It is also a potentially painful migration for existing applications.

The real problem for developers

The difficult part is not rotation itself.

The difficult part is discovering how many parts of your application quietly depended on rotation never happening.

An app may have:

• fixed-width layouts
• UI elements positioned with hardcoded assumptions
• animations that assume a particular screen ratio
• camera previews tied to a specific orientation
• custom drawing code that expects portrait dimensions
• fragments or activities that were never designed for resizing
• state that is not restored correctly when an activity is recreated

Google specifically warns that applications designed around small-screen layouts and a fixed portrait orientation can experience problems such as stretched layouts, components appearing off-screen, or animations behaving incorrectly when these restrictions are removed. Device rotation can also cause activity recreation, which makes proper state preservation important.

This is where the change stops being a policy decision and becomes a real engineering problem.

"But my app works perfectly in portrait"

That may be exactly the problem.

If your application works perfectly because it has never been exposed to anything else, Android 16 can expose assumptions that were previously hidden.

Take a simple example.

Suppose a screen was designed around a width of 400dp and a vertical list of controls. In portrait mode, everything looks fine.

Now put that same screen into a much wider window.

The controls might spread too far apart. A fixed-width panel may look tiny. A button positioned near the bottom may end up somewhere unexpected. A custom animation may calculate its movement based on dimensions that no longer make sense.

Nothing is technically "broken" in Android.

The application simply wasn't designed for the new environment.

Tablets are only part of the story

Although this change is often described as the "tablet orientation lock problem," tablets are really just the most obvious example.

The Android documentation specifically points to:

• tablets
• large foldable displays
• desktop windowing
• different window sizes and configurations

The common factor is available screen space, not the marketing category of the device. Android uses the sw600dp threshold to determine the large-screen behavior.

This also explains why a developer may see behavior that seems inconsistent between devices.

One Android device may respect the old behavior because its available screen width falls below the threshold, while another larger device may ignore the orientation request.

There is a temporary escape hatch

Android 16 does provide developers with a temporary compatibility option.

An application or activity can use the PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY manifest property to retain the older restricted behavior while the app is being migrated.

That sounds comforting, but there is an important catch.

It is temporary.

Google's current documentation says this opt-out will not be available once an application targets Android 17/API 37. At that point, orientation, aspect-ratio and resizability restrictions will always be ignored on displays meeting the large-screen threshold.

So the compatibility property is better thought of as a migration bridge, not a permanent solution.

What should developers do instead?

The answer is not necessarily "remove every orientation restriction tomorrow."

The more useful approach is to start identifying what your application actually depends on.

If an application truly needs a particular layout, make that layout work at different sizes.

If a camera screen needs special handling, make the camera preview respond correctly to the available orientation and display configuration.

If a screen contains a large collection of controls, redesign it so those controls can reflow, resize or reposition instead of assuming a fixed portrait canvas.

Modern Android development increasingly revolves around responsive and adaptive UI. The goal is not simply to support portrait and landscape as two separate versions of a screen. It is to make the interface respond to the amount of space available.

That distinction is important.

This may actually be good for Android users

From a user's perspective, Google's decision makes sense.

If someone buys a large tablet, they reasonably expect the tablet to behave like a tablet. If they rotate it, they expect applications to make reasonable use of that space.

Being greeted by a narrow portrait application floating awkwardly inside a huge display is not exactly the premium large-screen experience.

Android 16's change is intended to reduce that kind of compatibility behavior by allowing apps to use the full available display instead of remaining locked into older aspect-ratio and orientation assumptions.

The downside is that Android is moving some of the complexity from the platform to the developer.

Previously, the system could help maintain the developer's preferred shape.

Now the developer increasingly has to make the application comfortable with whatever shape it receives.

One more thing: API 36 is becoming unavoidable

This change matters even more now because targeting API 36 is no longer a distant concern for Android developers.

Google's current documentation states that Google Play requires apps to target API level 36 as of August 2026.

That means this is moving from "something to keep an eye on" to a practical compatibility issue for applications distributed through Google Play.

And with Android 17/API 37 removing the temporary orientation/resizability opt-out entirely, developers shouldn't build their migration strategy around keeping the old behavior forever.

The bigger change isn't orientation

At first glance, Android 16's large-screen change looks like Google taking away a useful switch.

But the bigger message is different:

Android is moving from device-specific UI to space-specific UI.

Instead of thinking:

"This is my portrait screen."

Developers increasingly need to think:

"This is the space my application has right now. How should my interface behave inside it?"

That's a bigger mental shift than simply changing an AndroidManifest setting.

For new applications, this philosophy can lead to much better interfaces. For older applications, especially those built around fixed portrait screens, it can mean a painful round of testing and redesign.

Either way, the old assumption that a large Android screen will politely obey a portrait-orientation lock is becoming a thing of the past.

And Android 17 makes it clear that Google isn't planning to turn the clock back.