Handling orientation and screen size in Android apps

An Android app can appear stable in portrait mode and then lose its layout when a user rotates the phone, opens a foldable device, or resizes a window. Configuration changes can alter available width, height, density, font scale, and navigation space without changing the underlying feature.

Orientation is only one part of the problem. Screen size varies between a compact handset in Sydney, a large tablet used in a Melbourne office, and a desktop-style window on a Chromebook. A reliable interface responds to the space available rather than assuming that every device has a fixed portrait or landscape shape.

Android usually recreates an Activity when a relevant configuration changes. This refreshes resources and gives the application a chance to load a suitable layout, but it also means ordinary in-memory variables can disappear. UI state, database data, and temporary workflow state therefore need different handling strategies.

The most maintainable approach combines responsive XML resources, lifecycle-aware state storage, and deliberate testing. Developers working through Android tutorials can also use this Android development resource to compare platform patterns before choosing an implementation.

Why configuration changes matter

A configuration change occurs when the environment available to an application changes. Common examples include portrait-to-landscape rotation, window resizing, a change in screen density, font scaling, keyboard availability, and switching between screen sizes. Android may destroy and recreate the current activity so it can apply the correct resources.

This recreation is useful because the new activity can inflate a layout designed for the new dimensions. It also exposes fragile code. A selected item, typed form value, scroll position, or pending network request may vanish if it exists only in fields such as var selectedId: Long = 0.

Screen size should be treated as available space, not as a simple phone-versus-tablet label. A landscape phone may have less vertical room than a portrait phone, while a resizable tablet window may move through several width classes during one session. Android’s density-independent pixels, or dp, help maintain usable physical proportions, but they do not remove the need for adaptive layouts.

Let the lifecycle handle recreation

The default recommendation is to allow Android to recreate the activity. In an XML-based application, onCreate() should restore state, inflate the current layout, connect views, and observe data. A ViewModel can retain screen-related data across recreation, while a repository or database should hold durable application data.

Use onSaveInstanceState() for small, temporary values needed to reconstruct the current screen. Examples include an item ID, a search query, a selected tab, or a draft form field. The saved bundle is not a general database: it should remain compact and should not contain large bitmaps, complete result sets, or complex object graphs.

ViewModel instances survive activity recreation during ordinary configuration changes, but they do not replace persistent storage. If a user adds a shopping item in Brisbane and the process is later removed from memory, the item should come from SQLite, Room, or another durable source rather than from the ViewModel alone. SavedStateHandle can bridge small UI state values into a ViewModel.

Avoid placing every configuration event inside manual callbacks. Code such as android:configChanges="orientation|screenSize" prevents recreation for selected changes, but then the activity must update every affected view itself. This can hide bugs, leave stale resources active, and make future screen-size support harder. Use it only when there is a specific, tested reason.

Build layouts for available width

Resource qualifiers let Android select an appropriate design automatically. A default res/layout/activity_main.xml should work on narrow screens, while folders such as res/layout-land/ can provide a landscape arrangement. Width-qualified resources, including res/layout-w600dp/, are often more useful than orientation alone because they describe the space available to the layout.

A compact screen might stack a list above a detail view. A wider screen can place both in adjacent columns, reducing navigation and making better use of a tablet window. ConstraintLayout, RecyclerView, weights used carefully, and minimum touch targets help layouts stretch without forcing fixed dimensions.

Use values dimens for spacing and text-related dimensions, and use alternative resources for meaningful structural differences. Avoid selecting layouts based on a hard-coded pixel width. A 600-pixel area can represent very different physical sizes across devices, whereas dp and width qualifiers provide a more stable basis.

Preserve state without duplicating data

A useful separation is to distinguish durable data, screen state, and view state. A customer record belongs in a database. A selected customer ID belongs in a ViewModel or saved state. A view’s current scroll position may be restored automatically by Android if the view has a stable ID and is configured correctly.

For a ListView or RecyclerView, observe a data source rather than rebuilding the list from a temporary array during every onCreate(). When the activity returns after rotation, the adapter should receive the current data again, while the selected position or filter is restored separately. This prevents duplicate rows and avoids treating the visual list as the source of truth.

Dialogs and animations need similar care. A dialog should be recreated from a stable state value, such as “confirm delete for record 42”, rather than retained as a stale activity reference. An animation may need to restart or resume based on state; it should not assume that its old view hierarchy still exists.

Test orientation and size in Australian contexts

Test on both portrait and landscape profiles, then resize the window gradually instead of checking only two fixed orientations. Android Studio’s emulator can model small phones, tablets, foldables, different densities, and large font settings. Physical testing is valuable too, since touch targets and keyboard behaviour can feel different from an emulator.

Australian users may switch between mobile data and Wi-Fi during commutes, use one hand while travelling through Sydney or Melbourne, and rely on a device with a large accessibility font. A form that fits a developer’s handset may clip labels when text is enlarged. Check long suburb names, dollar amounts in Australian format, and dates such as 31/12/2025 so controls do not overlap.

The local Android market includes inexpensive handsets alongside premium phones and tablets, creating substantial variation in memory, density, and Android version. Test a narrow, lower-cost device as well as a modern large-screen model. If an application stores names, addresses, or location information, review collection and retention practices against Australia’s Privacy Act 1988 and explain the handling clearly.

Practical habits for robust responsive screens

A repeatable development routine catches configuration errors early. Build the smallest working screen first, rotate it during each feature change, and inspect logs for duplicate requests or lost state. Keep data loading lifecycle-aware so recreation does not trigger uncontrolled network calls.

Use these practices when implementing orientation and screen-size support:

• Keep durable records in Room, SQLite, or another persistent data layer.
• Store small temporary values with SavedStateHandle or onSaveInstanceState().
• Prefer dp, sp, constraints, and width-qualified resources over pixel dimensions.
• Test portrait, landscape, split-screen, foldable, large-font, and keyboard states.
• Give important views stable IDs so Android can restore suitable view state.
• Treat configChanges as an exception requiring a documented reason and tests.
• Recheck privacy, accessibility, and Australian currency or date presentation before release.

A screen that survives rotation is only the starting point. The stronger result is an interface that remains readable, preserves the user’s work, and rearranges itself sensibly as Android changes the space around it.