Android development
screen orientation
tablets vs phones
user interface
app optimization

Android allow portrait and landscape for tablets, but force portrait on phone?

Data Structures & Algorithms practice on Codemia

Step through 300 algorithm problems with animated visualisers that show the data structure changing as the code runs.

Practice algorithms

Introduction

This requirement comes up often in Android apps: keep phones portrait, but let tablets rotate. The modern answer is to let the app support multiple orientations generally, then apply a small-screen restriction only where it is still appropriate, while remembering that recent Android releases override some orientation locks on large screens.

The Old Idea vs the Current Reality

Historically, developers solved this with android:screenOrientation="portrait" in the manifest and device-specific overrides in code. That still works on phones, but it is no longer the full story on larger devices.

On modern large-screen Android, especially for apps targeting Android 16 and higher, orientation restrictions are increasingly ignored on displays with smallestWidth >= 600dp. That is intentional. The platform wants large-screen apps to be adaptive instead of permanently letterboxed.

Use Screen Size to Decide the Policy

A practical approach is:

  • allow normal orientation behavior by default
  • force portrait only on smaller screens
  • keep large screens unrestricted

In a view-based app, you can do that in the activity.

kotlin
1import android.content.pm.ActivityInfo
2import android.os.Bundle
3import androidx.appcompat.app.AppCompatActivity
4
5class MainActivity : AppCompatActivity() {
6    override fun onCreate(savedInstanceState: Bundle?) {
7        super.onCreate(savedInstanceState)
8
9        val sw = resources.configuration.smallestScreenWidthDp
10        requestedOrientation = if (sw < 600) {
11            ActivityInfo.SCREEN_ORIENTATION_PORTRAIT
12        } else {
13            ActivityInfo.SCREEN_ORIENTATION_UNSPECIFIED
14        }
15
16        setContentView(R.layout.activity_main)
17    }
18}

600dp is a common tablet breakpoint, though your product may need a different threshold.

Keep the Manifest Flexible

If the manifest already hard-locks the activity to portrait, the runtime code has less room to help. A better baseline is to leave the manifest unrestricted or use a user-permitted value when your app truly supports rotation.

xml
1<activity
2    android:name=".MainActivity"
3    android:exported="true"
4    android:screenOrientation="fullUser" />

That lets the activity participate in user-permitted orientation changes, while the runtime logic above can still clamp phones to portrait when needed.

Tablets Need Adaptive Layouts Too

Orientation policy alone is not enough. If you allow tablets to rotate, the UI must actually work in both orientations. That usually means using responsive layouts, fragments, size-based resources, or adaptive Compose layouts.

At minimum, test these scenarios:

  • phone portrait
  • phone rotation attempt
  • tablet portrait
  • tablet landscape
  • split-screen or freeform windowing on large devices

If the layout breaks in landscape, the orientation rule is not the real problem. The layout is.

Why Programmatic Control Is Often Better

Code-based control makes it easier to express the real requirement: small screens portrait, large screens flexible. It also ages better as the platform changes, because you can adjust the logic without hardcoding every activity in the manifest.

This is particularly relevant now that Android is pushing apps toward adaptive large-screen behavior. On tablets, your app may eventually be expected to support both orientations regardless of the old lock-based pattern.

Common Pitfalls

  • Locking portrait in the manifest and assuming tablets will somehow override it cleanly usually causes frustration.
  • Treating orientation control as a substitute for responsive layouts leads to broken large-screen UX.
  • Using width in pixels instead of smallestScreenWidthDp makes device classification less reliable.
  • Forgetting about multi-window mode causes surprises even when full-screen rotation works.
  • Assuming large-screen orientation locks will always be respected is increasingly unsafe on modern Android.

Summary

  • The practical goal is portrait on small screens and flexibility on larger ones.
  • Use smallestScreenWidthDp to distinguish phones from tablets in runtime logic.
  • Keep the manifest orientation policy flexible enough for large-screen behavior.
  • Support tablet landscape with adaptive layouts, not just orientation flags.
  • Recent Android versions increasingly ignore large-screen orientation locks, so plan for adaptive UI instead of hard restrictions.

Related reading
Course
Intermediate
27 lessons
15 hours
DSA Fundamentals

Master algorithmic patterns and data structures through hands-on LeetCode-style problems - from arrays and hashing to dynamic programming and advanced graphs.

View the course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

Data Structures & Algorithms practice on Codemia

Step through 300 algorithm problems with animated visualisers that show the data structure changing as the code runs.

Practice algorithms