Adaptive Android Layouts: One App for Phones, Tablets and Foldables

A shopkeeper hands a billing tablet to a new cashier. The app on it is the same one installed on the owner's phone, and the screen is stretched into a tall phone layout with huge empty margins. Or a field supervisor unfolds a foldable phone and the app does not know what to do with the extra width. Both are layout problems, and Android has a standard approach to solve them. This post explains it in business terms and helps you decide whether you need it.

The idea: design for the window, not the device

Google's guidance is built around window size classes. These are named ranges of the space your app has been given. Importantly, they describe the app's window, not the physical device. A tablet running two apps side by side gives each app a smaller window, and a phone unfolded to its inner screen gives a larger one. The app should respond to whatever room it has at that moment.

According to the Android developer documentation, width is classified like this:

• Compact: under 600dp. Almost all phones held upright.
• Medium: 600dp to under 840dp. Many tablets held upright and unfolded foldables.
• Expanded: 840dp to under 1200dp. Tablets held sideways.
• Large: 1200dp to under 1600dp. Large tablet displays.
• Extra large: 1600dp and above. Desktop-style displays.

The dp unit is Android's size measure that stays roughly consistent across screen densities. The same page notes that most apps can adapt by looking at width alone, and that height matters for cases such as a phone in landscape, where two panels would not fit.

Two patterns that cover most business apps

List and detail

Think of an order list on the left and the selected order on the right. On a phone, only the list is shown, and tapping an item opens the detail full screen. On a tablet, both appear together. Google's documentation describes this as list-detail and offers a ready-made component, NavigableListDetailPaneScaffold, which also handles back navigation and predictive back animations. It belongs to the Material 3 adaptive libraries (adaptive, adaptive-layout and adaptive-navigation). This suits order management, student lists, patient queues, inventory and ticket systems.

Navigation that changes shape

On a phone, main sections such as Home, Orders and Reports sit in a bar at the bottom. On a wide screen, a bar on the left side is easier to reach. The documentation describes NavigationSuiteScaffold, from the Material 3 adaptive navigation suite library, which picks a bottom bar in compact windows or in tabletop posture and a side rail for everything else, and switches live when the window changes.

What is changing at the platform level

Until recently, an app could lock itself to portrait and ask Android to keep it that way. The Android 16 behaviour notes say that for apps targeting API level 36, orientation, resizability and aspect-ratio restrictions no longer apply on displays whose smallest width is 600dp or more. Such an app fills the whole window instead of sitting in a letterboxed strip. There is a temporary per-app opt-out, and the Android 17 notes state that this opt-out will not be available for apps that target Android 17 (API level 37) or higher. Our post on orientation locks going away covers that change in detail.

The result for you: if customers use your app on tablets, Chromebooks or foldables, an app with only a phone layout will look worse over time, not better.

Does your business need this?

Be honest about your users. Many apps are used almost only on phones, and a good phone layout is enough. Adaptive work is worth the money in these cases:

• Billing counters and POS: a tablet at the counter, a phone for the owner. Retail, pharmacy and restaurant owners often use both.
• Field and warehouse tablets: technicians, surveyors and stock checkers working on rugged tablets.
• Classrooms and clinics: teacher or doctor tablets that show a list on one side and a record on the other.
• Managers who use foldables or desktop modes to review dashboards.

If none of these describes you, keep the phone layout polished and revisit later.

Steps to plan it

1. Check your app analytics and ask staff which devices are really in use.
2. Pick the two or three screens where extra width would save time: usually a list, a detail screen and a form.
3. Ask your developer to compute the window size class once at the top of the app and pass it down.
4. Use list-detail and adaptive navigation components rather than custom code.
5. Test in the emulator at compact, medium and expanded widths, in landscape and in split-screen.
6. Keep the phone experience unchanged and check it again before release.

How VS Tech Builders approaches it

We build in Jetpack Compose, where adaptive layouts are part of the standard toolkit, so the extra cost is mostly design and testing time rather than a rewrite. We quote it as a separate, clearly scoped item. See our native Android app development and enterprise mobility apps services, the guide to software for supermarkets for a billing-counter example, and the article on Android app costs in India. You can also contact us through the contact page.

Sources

Checked on 3 November 2026. Technology changes quickly; always confirm details with the official source before you act on them.

• Use window size classes | Jetpack Compose | Android Developers — Android Developers
• Build a list-detail layout | Jetpack Compose | Android Developers — Android Developers
• Build adaptive navigation | Jetpack Compose | Android Developers — Android Developers
• Behavior changes: Apps targeting Android 17 or higher | Android Developers — Android Developers

Frequently asked questions

What are window size classes in Android?

They are named ranges of the screen space available to an app: compact, medium, expanded, large and extra large for width. Compact is under 600dp, which covers most upright phones. They describe the app's current window, not the physical device, so they change when a foldable unfolds or two apps share the screen.

Does my business app need a tablet layout?

Only if tablets, foldables or Chromebooks are actually used by your staff or customers, for example billing counters, warehouse tablets or clinic desks. If almost everyone uses phones, a well-tested phone layout is enough for now. Check device data first, then add adaptive layouts to the two or three screens that benefit.

What happens to apps that lock the screen to portrait?

For apps targeting Android 16 (API 36), Google says orientation, resizability and aspect-ratio restrictions are ignored on displays 600dp or wider, so the app fills the window. A temporary opt-out exists, but the Android 17 notes say it is not available to apps targeting API 37 or higher. Plan layouts that work in landscape.

Is it expensive to make an Android app adaptive?

It depends on how many screens need to change. In Jetpack Compose, ready-made list-detail and navigation components reduce the work, so a small app can often be adapted in days of design and testing. Older view-based apps may need more effort. Ask for a quote scoped to specific screens rather than the whole app.