Simulating Android screen sizes and densities in the emulator

An Android interface can look correct on a developer’s handset and still fail on another device. A compact phone may truncate a button label, a high-density display can expose blurry bitmap assets, and a tablet-sized viewport may leave an awkward gap around a carefully positioned panel. These issues often appear only when the emulator is configured with a different screen size or pixel density.

The Android emulator makes this variation practical to test. You can create virtual devices for small phones, large phones, tablets and foldables, then adjust their resolution, density, orientation and Android version. The useful goal is not to copy every handset sold in Australia, but to cover the display characteristics that influence layout behaviour.

This matters for teams supporting users in Sydney, Melbourne, Brisbane and regional areas, where customers may use inexpensive Android models alongside premium Google Pixel or Samsung devices. A stable NBN connection makes downloading system images easy, but it does not remove the need to test offline states, slow image loading or older hardware profiles.

Emulator testing also complements real-device checks rather than replacing them. It is particularly effective for repeatable layout tests, screenshot comparisons and unusual configurations that may be expensive to keep on a desk.

Profile type	What it represents	Useful checks
Small phone, low resolution	Compact or older handset	Text wrapping, touch targets, clipped controls
Standard phone, medium density	Common everyday Android device	General navigation and responsive layouts
Large phone, high density	Recent premium handset	Bitmap scaling, spacing and edge-to-edge content
Tablet or foldable	Wide or changing viewport	Two-pane layouts, rotation and configuration changes
Custom profile	A known customer or production device	Reproduction of a specific bug

Why density changes behaviour

Android layouts are generally expressed in density-independent pixels, or dp, rather than physical pixels. Text uses scale-independent pixels, or sp. The system converts these logical units into actual pixels according to the emulator’s density setting. A 48 dp button therefore occupies a different number of physical pixels on a mdpi device than on a xxhdpi device, while retaining approximately the same physical size.

This distinction is easy to miss when inspecting screenshots. A 1080-pixel-wide emulator is not automatically “larger” than a 720-pixel-wide one in layout terms. Its density may cause Android to report a similar logical width, or it may produce a much wider layout if the profile has been configured differently.

The practical implication is that both dimensions matter. Test the available dp width and height, the pixel resolution, the density bucket, font scale and system insets. A view can pass at one combination and fail at another because the same resource, padding or breakpoint is being selected differently.

Choosing emulator profiles

Start with profiles supplied by Android Studio’s Device Manager. A recent compact phone, a standard phone, a large phone and a tablet usually provide better coverage than a long list of nearly identical devices. Select system images that match the minimum Android version and the versions used by your customers.

The device frame is less important than the reported configuration. Review the emulator’s resolution, density, API level, navigation mode and orientation. A profile representing a 6.7-inch handset may still be a poor test case if its density and logical width do not resemble the production device you are investigating.

For Australian applications, include a configuration that resembles the lower-cost phones commonly sold through supermarkets, carrier shops and online retailers, as well as a current flagship. If the product is used by field workers in Perth or regional Queensland, test landscape mode and intermittent connectivity alongside the screen profile.

Understanding dp, sp and px

Use dp for layout dimensions and sp for text unless a deliberate pixel-based operation is required. Hard-coded px values can make icons, dividers and touch targets look inconsistent across densities. If a custom drawing component must use pixels, convert through the device density instead of assuming that one dp equals one px.

The same principle applies to raster images. Android resource directories such as drawable-mdpi, drawable-xhdpi and drawable-xxhdpi allow the system to choose an appropriate asset. Vector drawables are often preferable for simple icons, but they still need checking at small sizes, where strokes can become visually heavy.

Font scaling deserves a separate pass. Users may increase text size for accessibility, and Android can then make a screen effectively narrower even though its physical resolution has not changed. Australian teams should treat accessibility as a product requirement, not merely a visual preference, particularly when supporting obligations related to inclusive service delivery and the Disability Discrimination Act 1992.

Building configurable virtual devices

Create a baseline AVD first, then duplicate it for controlled variations. Change one factor at a time where possible: keep the same Android version while altering density, or keep the density fixed while changing the resolution. This makes a regression easier to explain than a profile that differs in five ways.

The emulator’s Extended Controls panel is useful for rotation, fold posture, location and network conditions. The command line can also launch a named AVD consistently, which helps when a build server or a team member needs to reproduce a test. Snapshot support reduces startup time, though a clean boot is valuable when checking first-run permissions and database migrations.

Do not rely on changing only the emulator window size. Resizing the host window may alter how the device is displayed without changing the Android configuration reported to the application. Use an actual virtual device profile or modify its hardware settings when you need a different logical screen.

A repeatable environment is especially helpful when debugging code that appears unrelated to the UI. A silent background failure can leave the interface in an incomplete state and look like a rendering problem; the techniques described in this Rails debugging note illustrate why logs and explicit failure signals matter during reproduction.

A practical validation checklist

Run a compact set of checks on every meaningful profile:

• Launch, login, logout and restore the application from the background.
• Rotate the device and inspect state restoration.
• Increase font scale and confirm that text remains readable.
• Test touch targets near navigation bars, cut-outs and rounded corners.

Then exercise content variation rather than relying on sample strings:

• Use long names, translated labels and multiline error messages.
• Load empty, partially complete and very large data sets.
• Check images at low bandwidth and with missing thumbnails.
• Verify dialogs, bottom sheets and keyboards on short screens.

Capture screenshots using the same emulator scale and configuration. Compare the logical layout as well as the image: an apparent one-pixel difference may be harmless anti-aliasing, while a shifted baseline or clipped descender indicates a real density or font issue. Keep the test data stable so that visual changes can be attributed to code rather than changing content.

Diagnosing layout and rendering defects

When a view fails, record the emulator model, API level, resolution, density, font scale, orientation and navigation mode. Android Studio’s Layout Inspector can show bounds and hierarchy, while adb shell wm size and adb shell wm density help confirm what the device is reporting. These values are more useful than a screenshot alone.

Check resource qualifiers before rewriting constraints. A layout may be selecting a values-sw600dp resource, a landscape variant or a density-specific asset unexpectedly. Also inspect system window insets: edge-to-edge layouts can place content beneath a status bar or gesture area if padding is applied inconsistently.

Input and networking failures can resemble display defects. A form that appears stuck may be rejecting an address or waiting for a request. When validating server-side data, the notes on PHP IP validation provide a useful reminder to separate input handling from presentation. That separation makes emulator diagnosis much faster.

For screenshot mismatches, distinguish structural from cosmetic differences. Structural problems include clipped controls, overlapping text and unreachable actions. Cosmetic differences include small anti-aliasing changes or a slightly different shadow. Fix structural defects first, then tune typography, colour and asset sharpness.

Keeping results reproducible

Record each AVD configuration in the project documentation, including the system image identifier and custom hardware values. If a defect is found on a customer handset, create a matching profile where possible and save a short reproduction note with the exact screen, orientation and data state.

Teams can keep a small matrix in version control and run smoke tests against the most important entries on every release. Full visual testing across every API level may be reserved for nightly builds. This approach controls emulator overhead without reducing coverage to a single developer phone.

Also test the application’s legal and operational context. If an app collects location, contacts or identifiers, verify permission wording and data handling on each supported Android generation. The Australian Privacy Act and the Australian Privacy Principles make it important to understand what information is collected and why, while Australian Consumer Law makes misleading product behaviour a business risk.

The same disciplined testing mindset applies to supporting tools and external services. Even a small content or food-ordering project such as Domowe Frykasy benefits from checking narrow screens, long item names and clear checkout actions rather than assuming a desktop layout will translate automatically.

A practical final matrix might include one compact phone, one current standard phone, one high-density large phone and one tablet. Run the release smoke test across those profiles, retain screenshots for important screens and reproduce customer reports before changing production code. Configure the emulator matrix now, document the reported dimensions and make screen variation part of every Android release check.