Introduction

Preventing screen rotation on Android is usually done either in the manifest or at runtime from an Activity. The best option depends on whether the screen should always stay fixed or only stay fixed in certain situations. The technical part is simple. The real design question is whether locking orientation improves the experience or just hides layout problems.

Lock Orientation in the Manifest

If an activity should always stay in one orientation, declare it in AndroidManifest.xml:

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

Common values include:

• 'portrait'
• 'landscape'
• 'sensorPortrait'
• 'sensorLandscape'

For a hard lock, portrait or landscape is the usual choice.

This is the simplest solution because it applies before the activity is shown and does not require runtime code.

Lock Orientation at Runtime

If you only want to prevent rotation in certain states, set the requested orientation in code.

In 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        requestedOrientation = ActivityInfo.SCREEN_ORIENTATION_PORTRAIT
9    }
10}

In Java:

1import android.content.pm.ActivityInfo;
2import android.os.Bundle;
3import androidx.appcompat.app.AppCompatActivity;
4
5public class MainActivity extends AppCompatActivity {
6    @Override
7    protected void onCreate(Bundle savedInstanceState) {
8        super.onCreate(savedInstanceState);
9        setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_PORTRAIT);
10    }
11}

This is useful when orientation should change based on feature state, user action, or device mode.

Choose Manifest Versus Runtime Intentionally

Use the manifest when:

• the activity should always stay fixed
• the lock is part of the screen's permanent design
• you want the simplest configuration

Use runtime locking when:

• the orientation changes based on app state
• some screens or modes should rotate and others should not
• the lock should be toggled dynamically

That distinction keeps the code cleaner. Permanent behavior belongs in configuration. Conditional behavior belongs in code.

Avoid Confusing Orientation Lock with Configuration Handling

Some developers try to "prevent rotation" by handling configChanges manually. That is a different topic.

This:

android:configChanges="orientation|screenSize"

does not lock the screen by itself. It only changes how the activity reacts when a configuration change occurs.

If the goal is simply "do not rotate," screenOrientation or requestedOrientation is the direct solution.

Think About UX Before Locking

Orientation locks are sometimes necessary, but they are not always a good default.

Locking can make sense for:

• camera flows
• games designed for one orientation
• forms or flows that break badly in landscape

But it can be a poor choice for:

• content-reading apps
• video or media-heavy screens
• large-screen and tablet layouts

A forced portrait layout can feel restrictive on tablets or foldables if the UI could reasonably adapt instead.

Rotation Can Reveal State Bugs

Many apps lock orientation because recreation on rotation exposes weak state handling. That fixes the symptom, not the architecture.

If your UI loses data or resets incorrectly during rotation, the real fix may be:

• saving UI state properly
• using ViewModel
• making the layout responsive

Orientation locking is fine when it is a deliberate product decision. It is a poor substitute for state management.

Unlocking Again at Runtime

If you set orientation dynamically and later want to allow user-driven rotation again, use a less restrictive requested orientation:

requestedOrientation = ActivityInfo.SCREEN_ORIENTATION_UNSPECIFIED

That returns control to the normal system behavior.

This is useful in workflows such as:

• lock portrait during data entry
• unlock during media playback

The key is to make the transitions intentional and easy to reason about.

Common Pitfalls

The biggest mistake is using configChanges and assuming it prevents rotation. It does not.

Another issue is locking orientation to avoid dealing with state restoration bugs. That may make the app feel rigid without solving the real lifecycle problem.

Developers also sometimes apply runtime locking in onCreate() even though the activity should always be fixed. In that case, the manifest is simpler and clearer.

Finally, test on tablets, foldables, and devices with very different aspect ratios. An orientation policy that feels reasonable on one phone can feel wrong on larger screens.

Summary

• Use android:screenOrientation in the manifest when an activity should always stay fixed.
• Use requestedOrientation at runtime when the orientation policy should change dynamically.
• Do not confuse orientation locking with configChanges handling.
• Lock orientation only when it is a genuine UX decision, not just a workaround for lifecycle bugs.
• Re-enable normal rotation with SCREEN_ORIENTATION_UNSPECIFIED when appropriate.