AndroidLab From retrocomputing to AI, through Android.
Android Emulator: Test Adaptive Apps Faster

Android Emulator: Test Adaptive Apps Faster

by

Adaptive Android testing is usually slow for a boring reason: a layout that looks fine on one virtual phone still has to survive a folded cover screen, an unfolded display, a tablet-sized window and an orientation change. Android Developers has now documented a compact set of adb emu commands that lets a running Emulator move through those states from the terminal, without opening a small zoo of virtual devices.

Illustration of a foldable Android device changing from closed to tabletop to open states
A proprietary AndroidLab illustration of the closed, half-opened and open states used in adaptive testing.

The commands do not replace visual checks or automated UI tests. They remove the repetitive setup between them. That makes them particularly useful when a change must preserve state, keep navigation coherent and avoid a layout snapping into nonsense as the available window changes.

What the new workflow changes

Android Studio already includes the Resizable Emulator for manual form-factor testing. The newer workflow is the ability to send a console instruction with adb emu and immediately get the shell back. With more than one emulator running, target the intended virtual device explicitly:

adb -s <serial> emu <command> <parameter>

Find the serial with adb devices, then keep the app open while you change one condition at a time. The practical benefit is repeatability: the same sequence can be placed in a local test checklist or a CI-adjacent developer script instead of being recreated through mouse clicks.

Fold, unfold and rotate without restarting the app

On a compatible foldable virtual device, these two commands switch between the outer and inner display configurations:

adb emu fold
adb emu unfold

After each transition, check the unglamorous things that commonly regress: whether the current screen stays selected, whether typed text survives, whether a modal remains attached to the right window, and whether media or a network request is needlessly restarted. A layout that only redraws correctly after a clean launch has not passed an adaptive test.

Rotation is similarly direct:

adb emu rotate

Google documents this as a 90-degree clockwise rotation. It is a quick way to expose code that treats a configuration change as a shortcut to resetting the activity rather than a state the app must handle deliberately.

Test a tabletop posture, but query first

Foldable posture IDs are not a universal contract. Start by asking the running emulator what it supports:

adb emu posture

The command reports available positions. Google’s example lists closed, half-opened and opened as IDs 1, 2 and 3; a compatible emulator can then be placed in the half-opened state with adb emu posture 2. Standard templates such as Pixel Fold and the Resizable AVD do not necessarily expose every imaginable posture, so a failed request is a signal to inspect the list rather than invent another numeric ID.

Resize a single emulator across form factors

The Resizable Emulator can also move between its available display presets. Query them before selecting one:

adb emu resize-display
adb emu resize-display 1

In Google’s documented example, the listed presets are phone, unfolded and tablet. The exact index is what the running virtual device reports, not a value an app should hard-code. This matters because it turns one launch into a compact layout matrix: make a change, run a preset, inspect the UI and move to the next one.

A small repeatable test loop

  1. Launch a compatible AVD and deploy a debug build.
  2. Use adb devices and add -s <serial> when more than one emulator is active.
  3. Navigate to a state with real content: a list, a detail screen, an open keyboard or an in-progress form.
  4. Run fold, unfold, rotate, posture or resize commands one at a time.
  5. Verify preserved state, readable hierarchy, touch targets and navigation before moving on.
  6. Keep the command sequence with the bug report or test case so the regression is reproducible.

The important distinction is between testing a screenshot and testing a transition. Static previews can catch a cramped layout; they do not reveal whether a form drops unsaved input when a foldable opens, or whether a detail pane loses its selection when a window becomes tablet-sized.

Limits worth keeping in view

These commands model display and posture changes, not every property of a physical device. They do not replace checks for thermal behaviour, modem performance, cameras, stylus feel or OEM-specific software. They are also only useful where the chosen AVD supports the requested control. Treat an unsupported posture as a limitation of that virtual device, not proof that a real foldable will behave identically.

For a separate look at testing against the current Android preview track, see AndroidLab’s Android 17 QPR2 Beta 1 eligibility and exit guide. Preview-platform testing and adaptive-window testing answer different questions; a sound release process needs both.

In brief

  • adb emu can control fold, unfold, rotation, posture and Resizable Emulator display presets from the terminal.
  • Use adb -s <serial> to avoid sending a command to the wrong emulator.
  • Query posture and resize options first; supported IDs and presets depend on the active AVD.
  • Test state preservation during transitions, not only the final layout screenshot.
  • The controls complement physical-device testing rather than replacing it.

Sources

AUTHOR

IT specialist, developer and systems engineer with a long history across code, Linux servers, retrocomputers and e-learning platforms. On AndroidLab he brings a technical, pragmatic eye: less brochure smoke, more attention to infrastructure, usability, privacy, updates and the real consequences of manufacturers' choices.

Leave a Comment