Introduction

To disable orientation change on Android, you usually lock an Activity to portrait or landscape. The simplest approach is to declare the orientation in AndroidManifest.xml, although you can also set it programmatically at runtime.

The important distinction is that locking orientation is not the same as handling configuration changes yourself. If your goal is "do not rotate this screen," use screenOrientation, not a complicated configChanges workaround.

Locking Orientation in the Manifest

The most common solution is to lock a specific activity in the manifest:

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

This tells Android to keep MainActivity in portrait mode. If you want landscape instead, change the value:

<activity
    android:name=".VideoPlayerActivity"
    android:screenOrientation="landscape" />

This is usually the best choice because it is declarative, easy to review, and applies consistently whenever the activity is launched.

Locking Orientation in Code

If you need to decide at runtime, set requestedOrientation inside the activity:

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}

This is useful when the lock depends on state. For example, a form screen might stay portrait, while a media viewer may switch to landscape.

Common constants include:

• 'SCREEN_ORIENTATION_PORTRAIT'
• 'SCREEN_ORIENTATION_LANDSCAPE'
• 'SCREEN_ORIENTATION_SENSOR_PORTRAIT'
• 'SCREEN_ORIENTATION_SENSOR_LANDSCAPE'

The sensor-based variants allow upside-down or reverse orientations within the same general mode.

Why configChanges Is Usually the Wrong Tool

Some developers try to stop rotation by adding android:configChanges="orientation|screenSize" and overriding onConfigurationChanged. That does not truly lock the screen. It only tells Android that your activity will handle certain changes itself.

Use that path only when you really want to manage configuration changes manually. For a simple orientation lock, it adds complexity without solving the real problem cleanly.

Consider User Experience Before Locking

Orientation locking is sometimes necessary, but it should be intentional.

Good reasons include:

• a game designed for one layout only
• a camera or scanner workflow
• a fixed-format form that breaks badly in landscape

Poor reasons include:

• avoiding layout bugs that should actually be fixed
• skipping responsive design work
• forcing portrait on screens users naturally expect to rotate

In other words, locking orientation should be a product decision, not a shortcut for unfinished UI work.

Testing Matters

Even when you lock a screen, test how the activity behaves during lifecycle events such as process recreation, split-screen mode, and navigation between activities with different orientation policies.

For example, one activity may be portrait-only while another supports both orientations. Switching between them should feel deliberate, not jarring.

Also remember that orientation is controlled at the activity level. If a single fragment needs a different policy, that decision still has to be expressed through the hosting activity.

Common Pitfalls

• Using configChanges when all you needed was screenOrientation.
• Locking every activity globally when only one screen actually requires it.
• Forgetting tablets and foldables. An orientation choice that feels fine on a phone may feel restrictive elsewhere.
• Setting orientation in code too late, which can cause visible flicker.
• Treating orientation lock as a substitute for fixing broken layouts.

Summary

• The simplest way to disable orientation change is android:screenOrientation in the manifest.
• You can also set requestedOrientation in code when the choice depends on runtime state.
• Use portrait or landscape locks intentionally, not as a bandage for layout problems.
• 'configChanges is not the normal solution for locking orientation.'
• Test transitions and lifecycle behavior even when the screen no longer rotates.