How to Test Your Game on Foldable Phones and Tablets

Your mobile game works beautifully on the iPhones and Samsung Galaxy phones your team uses. You ship to the Play Store and start getting bug reports with screenshots showing UI elements off the edge of the screen, buttons hidden behind the fold hinge, and “the game goes black when I unfold my phone.” Welcome to foldable devices, the fastest-growing phone category that most indie mobile games ignore until it’s too late.

The Foldable Device Landscape

Foldables are no longer a novelty. In 2026, the Galaxy Z Fold, Pixel Fold, Xiaomi Mix Fold, and Oppo Find N variants represent single-digit percentages of Android users but growing quickly. Add iPads and Android tablets to the picture and you’re looking at 10–20% of your player base on devices with aspect ratios your phone-only UI wasn’t designed for.

The core challenge is that foldables change shape at runtime. A phone is a 20:9 phone one second and a 6:5 near-square tablet the next. Your game has to handle this transition without:

• Losing game state
• Crashing on the configuration change
• Leaving UI stuck at the old aspect ratio
• Misplacing touch input
• Cutting off the safe area behind the hinge

Step 1: Declare Support in Your Manifest

For Android, your manifest must declare support for multi-window and configuration changes. Without this, Android treats your game as a fixed-size legacy app and letterboxes it on foldables.

<!-- AndroidManifest.xml -->
<application
    android:resizeableActivity="true"
    android:requestLegacyExternalStorage="false">

    <activity
        android:name=".GameActivity"
        android:configChanges="screenSize|screenLayout|orientation|keyboardHidden|density"
        android:resizeableActivity="true"
        android:supportsPictureInPicture="false">

        <meta-data
            android:name="android.allow_multiple_resumed_activities"
            android:value="true" />

        <meta-data
            android:name="android.supports_size_changes"
            android:value="true" />
    </activity>
</application>

The android:configChanges declaration tells Android that your game will handle these config changes itself instead of recreating the activity. If you omit this, your activity gets destroyed and recreated on fold/unfold — usually losing game state unless you handle onSaveInstanceState correctly.

Step 2: Handle Configuration Changes

When the device folds or unfolds, Android fires a config change event. In Unity, this surfaces as Screen.width and Screen.height updating and the orientation changing. Listen for these updates and re-layout your UI:

// Unity example
using UnityEngine;

public class ResponsiveLayout : MonoBehaviour
{
    private Vector2 lastScreenSize;
    [SerializeField] private RectTransform hudPanel;
    [SerializeField] private RectTransform menuPanel;

    void Update()
    {
        var currentSize = new Vector2(Screen.width, Screen.height);
        if (currentSize != lastScreenSize)
        {
            lastScreenSize = currentSize;
            OnScreenResized(currentSize);
        }
    }

    void OnScreenResized(Vector2 size)
    {
        float aspect = size.x / size.y;

        if (aspect > 1.8f)
        {
            // Narrow phone layout
            ApplyPhoneLayout();
        }
        else if (aspect > 1.2f)
        {
            // Tablet landscape / unfolded phone
            ApplyTabletLandscapeLayout();
        }
        else
        {
            // Portrait tablet or square unfolded
            ApplyTabletPortraitLayout();
        }

        // Force canvas scaler to update
        var scaler = GetComponentInParent<UnityEngine.UI.CanvasScaler>();
        if (scaler != null) scaler.enabled = false;
        if (scaler != null) scaler.enabled = true;
    }
}

Step 3: Avoid the Hinge Area

Foldable devices have a physical hinge that runs down the center of the unfolded screen. Depending on the device, this area may be slightly darker, less responsive to touch, or have a visible crease. Don’t place critical interactive elements across the hinge.

Android provides APIs to detect the hinge position. Use WindowInfoTracker from the Jetpack Window Manager library to get FoldingFeature information including the hinge bounds:

// Kotlin side (in your Unity Android plugin)
import androidx.window.layout.WindowInfoTracker

WindowInfoTracker.getOrCreate(activity).windowLayoutInfo(activity)
    .collect { layoutInfo ->
        val foldingFeature = layoutInfo.displayFeatures
            .filterIsInstance<FoldingFeature>()
            .firstOrNull()

        if (foldingFeature != null) {
            val hingeBounds = foldingFeature.bounds
            // Send this to Unity so the game can avoid placing UI here
            UnityPlayer.UnitySendMessage(
                "FoldManager", "OnHingeBounds",
                "${hingeBounds.left},${hingeBounds.top}," +
                "${hingeBounds.right},${hingeBounds.bottom}")
        }
    }

On the Unity side, receive the hinge bounds and inflate a safe area rectangle that excludes the hinge. Layout your HUD elements inside this safe area.

Step 4: Test the Fold/Unfold Transition

Android Studio’s emulator has a fold/unfold button in the extended controls. Use it to fold and unfold during different game states:

• During the main menu
• During active gameplay
• During a loading screen
• During a cutscene
• While the player is holding a button (make sure the touch event isn’t lost)
• While a modal dialog is open
• While typing in a text field

For each state, verify that: the game continues running without crashing, UI elements reposition correctly for the new aspect ratio, touch input still maps to the correct game world position, and game state (score, current level, remaining health) is preserved.

Step 5: Test Split-Screen Multitasking

On Android, players can long-press your game in the recents view and open it in split-screen with another app. Your game runs in half the screen at unusual aspect ratios. Test this explicitly.

Common split-screen bugs:

• UI elements that require minimum size get cut off
• Game pauses unexpectedly (you’re not in focus but still visible)
• Touch input coordinates get confused by the resized window
• Performance drops because the device is running two apps at once

iPad and Tablet Testing

iPads don’t have the fold/unfold transition, but they do support multiple orientations, Split View, Slide Over, and Stage Manager. Test in each mode. Xcode Simulator supports all iPad sizes. The key thing to test is that your game handles sudden size changes when the user drops your app into Split View at 1/3 or 2/3 of the screen.

Android tablets are simpler — they’re just large Android devices with different default orientations. The main thing to verify is that your UI doesn’t look absurdly stretched or leave enormous blank areas. Use auto-scaling canvases and anchor UI elements to screen edges rather than hardcoded positions.

Capturing Foldable Bugs in the Wild

Add device form factor detection to your bug report metadata. Include: screen width/height in pixels and DP, device name, form factor (phone, foldable, tablet), folded state, and density. When foldable-specific bugs come in, you can filter your dashboard by form factor and see them clearly.

Related Issues

For general mobile testing across devices, see How to Test Your Game on Multiple Platforms. For Android-specific bug reporting, see Crash Reporting for Mobile Games on iOS and Android. For UI bug testing in general, check UI Bug Testing Strategies for Game Developers.

A foldable is two devices pretending to be one. Your game has to handle both.