Introduction

Locking an Android app to portrait mode is straightforward technically, but it has UX and lifecycle tradeoffs you should understand before enforcing it globally. Some apps benefit from orientation lock (forms, kiosk flows, scan screens), while others become less usable on tablets and foldables if forced portrait. If you decide portrait-only is correct for product requirements, the cleanest approach is to set orientation at the activity level in AndroidManifest.xml.

You can also set orientation in code for specific runtime conditions, but manifest-based configuration is usually more predictable and easier to audit.

Core Sections

1. Lock a single activity in manifest

<activity
    android:name=".MainActivity"
    android:screenOrientation="portrait" />

This forces portrait for that activity only.

2. Apply portrait lock to all activities

If the app has multiple activities, set each one explicitly or create a base configuration policy.

1<application ...>
2    <activity android:name=".LoginActivity" android:screenOrientation="portrait" />
3    <activity android:name=".MainActivity" android:screenOrientation="portrait" />
4    <activity android:name=".SettingsActivity" android:screenOrientation="portrait" />
5</application>

Be explicit per activity so future screens do not unintentionally default differently.

3. Runtime orientation lock in code

Use code only when lock should be conditional.

1import android.content.pm.ActivityInfo
2
3override fun onCreate(savedInstanceState: Bundle?) {
4    super.onCreate(savedInstanceState)
5    requestedOrientation = ActivityInfo.SCREEN_ORIENTATION_PORTRAIT
6}

This is useful for feature flags or specific workflow states.

4. Understand lifecycle implications

Orientation changes normally trigger recreation unless handled via config changes. Locking orientation avoids rotation recreation but does not remove other recreation causes (multi-window changes, locale updates, process death).

1override fun onSaveInstanceState(outState: Bundle) {
2    super.onSaveInstanceState(outState)
3    outState.putString("draft", draftText)
4}

Do not skip state restoration just because orientation is fixed.

5. Tablet and foldable considerations

Portrait lock on large screens can waste space. If UX allows, lock only specific activities.

1val shouldLock = resources.getBoolean(R.bool.lock_portrait_on_phone)
2if (shouldLock) {
3    requestedOrientation = ActivityInfo.SCREEN_ORIENTATION_PORTRAIT
4}

Device-class-aware policy often gives better long-term UX.

6. Test behavior in modern Android environments

Validate on phone, tablet, split-screen, and foldable emulator profiles.

adb shell settings put system accelerometer_rotation 1
adb shell settings put system user_rotation 1

Orientation lock can interact with OS-level rotation preferences and multi-window behavior.

7. Jetpack Compose note

Compose itself does not change orientation policy; activity settings still apply.

setContent {
    AppRoot()
}

Keep orientation decisions in activity/manifest layers rather than composables.

Common Pitfalls

• Locking orientation globally without considering tablet or foldable UX.
• Setting orientation in code and manifest inconsistently across activities.
• Assuming orientation lock eliminates the need for state persistence.
• Forgetting to apply policy to newly added activities.
• Ignoring accessibility and user-preference impacts of forced orientation.

Summary

To run an Android app in portrait mode, set android:screenOrientation="portrait" on target activities, preferably in the manifest. Use runtime locking only for conditional cases and continue handling state restoration as usual. Review large-screen UX before enforcing app-wide lock. With a deliberate per-activity policy and device testing, portrait mode can be stable without sacrificing maintainability.

A practical way to harden this topic in real projects is to add a small operational checklist and treat it as part of your engineering standard, not a one-off fix. Start by creating one minimal failing case and one passing case that represent real input from production logs. Then automate those checks in CI so regressions are caught before release. Add lightweight instrumentation around the critical branch where this logic runs, and include structured fields that let you filter by version, environment, and error type. This gives you fast feedback when behavior changes after dependency upgrades or refactors.

For long-term maintainability on i want my android application to be only run in portrait mode, keep one source of truth for helper logic instead of duplicating variants across services or UI layers. Document assumptions near the code, including data format, edge-case behavior, and expected fallback policy. During code review, verify that example inputs and tests cover empty values, malformed values, and high-volume scenarios. Teams that combine explicit assumptions, repeatable tests, and basic observability typically avoid the same category of bug recurring every quarter.