If you're struggling with the aspect ratio of your apps on a foldable phone, you're not alone: the variety of sizes, orientations, and folded/unfolded states It turns fine-tuning into an art form. Between the changes in Android 16, system options, and design best practices, there's a clear path to making your apps (and websites too) look amazing on compact, medium, and large screens.
The truth is that Android is strongly pushing for all apps to be resizable. and work in all orientations and aspect ratios when there's ample space (tablets, desktop mode, and the internal screen of many foldable devices). In parallel, there are testing tools, compatibility flags, specific exceptions, and user tricks that can save the day while you're updating your UI.
What changes in Android 16 (API 36) and why it affects you
With Android 16, the system ignores orientation, aspect ratio, and resizing restrictions This applies to apps targeting API 36 when the device has a width of at least 600dp. This includes tablets, the inner screen of foldable phones with large panels, and desktop window mode. The goal is to provide a consistent experience and utilize screen space without forcing an app into a narrow vertical orientation if there's room for more.
Furthermore, All activities become resizable by default and they can enter multi-window mode if the device meets that threshold of sw ≥ 600dp. In practice, it's equivalent to having resizeableActivity=true, but without having to declare it in the manifest.
Manifest attributes and APIs that are no longer usable on large screens
On devices with sw ≥ 600dp, when you target API 36, the system ignores several historical attributes. Among them are the fixed values of screenOrientation (portrait, landscape and their sensor/user variants), any value of resizeableActivity, and minAspectRatio y maxAspectRatioCalls to [unclear - possibly "phone" or "phone"] also lose their effectiveness. setRequestedOrientation()/getRequestedOrientation() with those rigid modes.
If for justified reasons you need to unsubscribe from API 36, there is a temporary solution: declares ownership android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITYYou can apply it per activity or globally in the app like this:
<activity ...><property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" /></activity>
<application ...><property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" /></application>
Keep in mind an important detail: This disabling disappears in API 37Based on that goal, the framework will always ignore orientation, aspect ratio, and size restrictions on screens with sw ≥ 600dp, so it's best to start adapting your UI now.
Exceptions, special cases and user preferences
There are situations where the change does not apply. Screens with sw < 600dp (Most phones, including many foldable models) are not affected. Games are also excluded when the app is marked with the category android:appCategory="game".
Additionally, if the user enables an app's default behavior in the system's aspect ratio settings, that preference rules above and beyond the general rules. For games, publishing with Android App Bundles and Play's app signing helps ensure the category is well managed by Google Play.
Quick settings for foldable users: full screen and density
If you have a Galaxy Fold, Pixel Fold or similar and you see Instagram, Reddit or some games stretched or super zoomed in, you can try the system options. Look for Settings > Display > Fullscreen apps / App scaling and enables the best-looking mode for each app. It's not miraculous if the app isn't optimized, but sometimes it greatly improves the result; for example, YouTube changes its appearance on smart TVs.
Another, more advanced, approach is to adjust the parameter “Smaller width” In Developer Options, increasing the value makes everything "shrink" (more content visible), and decreasing it makes elements larger. Do this carefully, note the original value, and remember that it can affect the entire system interface.
How to test: emulators, compatibility flags, and automated tests
To check if your app is affected by the new features of Android 16, use emulators of Pixel Tablet and Pixel Fold In Android Studio. Configure in your module. targetSdkPreview="Baklava" and plays with rotations, folding/unfolding, multi-window and desktop mode.
On physical test devices, you can enable the compatibility framework markup. UNIVERSAL_RESIZABLE_BY_DEFAULT to simulate universal, resizable behavior. And if you want to automate workflows, Espresso and Jetpack Compose test APIs They allow you to validate interactions while the window resizes.
Typical problems when changing aspect ratio and how to avoid them
Apps that block orientation, aspect ratio, or resizing often struggle on large screens: stretched layouts, overlaps, off-screen buttons and even distorted camera previews. Their approach is to embrace responsive design and cover these points:
- Set maximum widths to components prone to "spreading" horizontally (cards, bars, images).
- Enable scroll down where necessary so that actions are not "lost" when switching to landscape or multi-window mode.
- Camera: that the viewfinder turn correctlyand that it accepts UI aspect ratios different from the sensor.
- Preserves state in size changes: the activity can be recreated; Don't lose forms or context.
- Think about Window Size Classes and use responsive designs within each class.
Compose done right: classes that don't break, including size, state, and layouts
Jetpack Compose is ideal for building UIs that resize seamlessly. Material 3 Window Size Class You can classify the width and height as Compact, Medium, and Expanded and adapt the UI without being tied to a specific device model.
In the root composable, calculate the window size and propagate it as state down. Avoid decisions like “is it a tablet?”The app can run in multi-window mode, on an external monitor, or in a screen segment. Tools such as BoxWithConstraints They allow you to change the displayed content according to the available space.
To avoid losing UI state when the activity is recreated, replace remember by rememberSaveable in anything that needs to survive configuration changes. And for true continuity, it elevates the state to a ViewModel: initializes in the init of the ViewModel and not in onCreate() of the activity, so that costly burdens are not repeated when resizing.
A typical pattern: on narrow screens, it displays a list; on wider screens, switch to a 2-3 column gridIncrease font sizes and margins, and distribute the information more effectively. Always pass the complete data to the composable file and decide what is visible based on the available space to avoid undesirable effects when resizing.
XML and resources: from classic densities to class-based windows
For years we relied on folders like ldpi, mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi for images, layouts, and dimensions, with variations by orientation. That's still useful, but the current variety of looks and states makes the Window Size Classes be more scalable in the long term.
As a reference recommended by Google for width: 0–599dp Compact, 600–839dp Medium, 840+dp ExpandedFor high, analogous ranges are used (e.g., 0–479, 480–899, 900+). A vertically foldable It can fall into Medium, while when deployed horizontally it usually goes to Expanded.
Web design: CSS, aspect ratio, and screen segments
If your challenge is a website, foldables require going a step beyond classic responsive design. Combine breakpoints by width with media queries by aspect ratio for folded/unfolded states. An illustrative example:
@media (min-width: 600px) and (max-width: 900px) { /* Estilos para un plegable semiabierto */ }
@media (aspect-ratio: 3/4) { /* Vertical plegado */ }
@media (aspect-ratio: 16/9) { /* Apaisado desplegado */ }
In multi-panel environments, the Window Segments API It gives you the active visual area: window.screenSegments It returns the segments to distribute content and avoid folds or hinges. Add viewport-fit: cover in CSS so that the content takes advantage of all the space, and detect orientation with the Screen Orientation API to adjust the UI without flickering.
In terms of performance, consider that foldable phones are very good at multitasking: lazy loading, optimized images, and compressed resources They are mandatory. Tools like Lighthouse or WebPageTest will show you bottlenecks instantly.
Jetpack WindowManager: folds, hinges and positions (table and book)
For native Android, the library Jetpack WindowManager It exposes the information of the foldable device through WindowInfoTracker and its emissions of WindowLayoutInfoYou can collect them using coroutines. repeatOnLifecycle (it restarts automatically when the activity returns to STARTED) or with Java callbacks through WindowInfoTrackerCallbackAdapterIf you use RxJava, you have artifacts for Observable/Flowable and subscribe to the main thread.
Within WindowLayoutInfo or Display Features , the FoldingFeature, which report status (FLAT o HALF_OPENED), orientation of the fold (HORIZONTAL o VERTICAL), type of occlusion (NONE o FULL) what if isSeparating It's true. With bounds You can align the UI so as not to place crucial content over the fold or hinge.
With that data, it detects the tabletop positionHorizontal hinge, semi-open. Place the main content above the fold and controls and auxiliary elements below; it's very convenient for videos, photos, and hands-free video calls. You can also detect the book posture (vertical fold, semi-open) for double-page reading UIs or captures with a different aspect ratio.
Important: The aperture angle is not specified in the API (accuracy varies by device), so no critical animation bases on itIn dual-screen foldable devices, also apply designs that respect physical separation, and use occlusionType to decide whether to avoid the hinge area.
Window size changes and metrics
When rotating, folding/unfolding, or entering multi-window mode, the WindowMetrics. With WindowMetricsCalculator (Backward compatible) You get current and maximum limits, and you can react on the fly. Since API 24, only "significant" changes recreate the activity, but this can happen when switching from half screen to full screen or when connecting an external monitor with a different density.
To simplify the logic, use a top layer (Window Size Class) and do not propagate physical sizes to all components. Observe LocalConfiguration.current In Compose you need to react to orientation/widths/heights, but try to let the children decide based on their available space.
Life cycle, status, and background work
It records lifecycle events with a LifecycleEventObserver To see what happens when you minimize, bring to the front, or roughly resize an item, you'll see pauses and resumes on many devices, and in some cases, recreations of the activity if the change is significant. This directly impacts your UI state and initial load times.
To avoid losing the user's intent, employ rememberSaveable in Compose and elevates the state to ViewModelIt removes costly initializations from onCreate() and move them to init of the ViewModel: this will prevent you from duplicating network or I/O calls every time the activity is recreated due to a resizing.
Practical UI tips: components, typography, and grids
Components that occupy the full width tend to stretch unevenly horizontally; Define maximum widths and use centered containers For cards and forms, adjust fonts and spacing when you switch to Expanded, and remember that a 2–3 column grid gains readability and information density where appropriate.
Switching from list to grid increases the size of icons or images and Maintain visual hierarchy with larger titles on big screens. If your layout changes from one to two columns, raise status flags like "see more" so the user's action isn't lost when recomposing.
Testing on remote devices and laboratories
In addition to Android Studio emulators, you can test remotely with BrowserStack or Samsung Remote Test Lab To validate real-world folded/unfolded states. In Chrome DevTools, emulate various sizes and aspect ratios for websites. You'll quickly see where your UI falls short and what breakpoints you're missing.
For Android devices, don't forget the compatibility mark. UNIVERSAL_RESIZABLE_BY_DEFAULT and the official codelabs focused on resizing. If something goes wrong, it's better to discover it here than in the hands of your users and consider... create a lite version of the app.
Dates and release: what's coming in store
Android 16 establishes as a reference that, on screens with sw ≥ 600dp, The default experience is compatible with all orientations and aspect ratios in apps that target API 36 (with temporary opt-out). And Android 37 will eliminate that possibility of disabling it.
Deadlines vary by store, but Google Play will require target API 36 starting in August 2026If you're still tied to fixed orientations and rigid ratios, it's time to plan your migration to avoid publishing blocks and, above all, improve the experience on large screens.
What the community says (and an interesting tidbit)
It is common to read that in foldable phones like Fold or Pixel Fold, Some apps appear stretched or with exaggerated zoom.And some games don't take advantage of the available space. Forcing full screen per app might improve things in the short term, but the real leap in quality comes when developers adopt adaptive UI with size classes and responsive layouts.
And if after trying everything you're still not comfortable with your device, the original content mentioned that there are buyback services like “Moviloff” to sell the phone and give it a second life. It doesn't solve the technical problem, but it might work for you if you decide to change devices.
Mastering aspect ratio in apps for foldable devices is easier if you embrace the new model: Let the system handle large windows, build responsive UIs, preserve state, and test thoroughly.Between Window Size Classes, Jetpack WindowManager, Compose best practices, media queries by aspect, and testing in emulators and labs, you have everything you need to make your apps and websites look good in any position and size, with less stretching and more useful content in view.
