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.
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.
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.
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
smallestScreenWidthDpmakes 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
smallestScreenWidthDpto 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
- Android Fatal signal 11 SIGSEGV at 0x636f7d89 code1. How can it be tracked down?
- Android how many threads can I have going?
- Android Preventing Double Click On A Button
- Android splash screen image sizes to fit all devices
- Android and setting width and height programmatically in dp units
- Android API 21 Toolbar Padding
- Android Studio Google JAR file causing GC overhead limit exceeded error
- Android Studio gradle takes too long to build

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 courseTrack 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.