Android testing: emulator vs physical device
An emulator and a physical device are not two competing options. Each answers a different question: a virtual device provides a fast and repeatable check, while a physical phone shows the behaviour of specific hardware and manufacturer customisations. A good testing strategy uses both layers to an appropriate extent.
What an emulator can do and what it lacks
The Android Emulator can change the system version, resolution, orientation and various hardware or network conditions. It can simulate an incoming call or message, location, different network speeds and selected sensors. It is therefore suitable for test development, fast smoke scenarios and broader coverage of Android versions without purchasing devices.
A simulation, however, is not identical to a specific phone. A virtual device may not reproduce precisely the performance of weaker hardware, the graphics driver, camera, biometric sensor or manufacturer system customisations. Differences may also appear in background process management, notifications or memory usage.
A physical device includes these characteristics, but operating it comes at a cost. Phones need to be prepared, reset, updated and managed securely. With a cloud service, model availability, waiting time, price and rules for test data also enter into the decision.
How to create a sensible device matrix
First, we divide tests according to the information they are intended to provide.
The fast layer on virtual devices verifies that the application installs, launches and handles the most important journeys. It runs after relevant changes or in a regular CI run and uses several representative Android versions.
The targeted layer on physical devices focuses on risks that depend on the hardware or manufacturer. This includes, for example, performance on a lower-powered model, the camera, biometrics, background behaviour or a problem that analytics associate with a specific group of devices. For a major release, the matrix can be expanded without requiring every test to run on it.
We base the choice of models on anonymised data about the system versions, manufacturers and devices used by customers. We supplement it with the minimum supported Android version and commercially important segments. The matrix changes regularly along with the user base.
Both Appium and Maestro can run locally on an emulator and a connected physical device. Cloud platforms differ in their types of devices and supported frameworks, so we verify compatibility before designing the entire infrastructure.
What to watch out for
An emulator can also simulate a network outage, a call or screen rotation, so these scenarios do not automatically belong only on a physical phone. Conversely, a test on one real model does not prove compatibility with every manufacturer. It is important to identify the risk and choose an environment that can verify it credibly.
Test accounts must not contain unnecessary personal data. For videos, screenshots and logs from cloud devices, retention and access need to be set according to internal security rules.
What you gain
Virtual devices provide early feedback without unnecessarily long waits. Physical models are used where they provide new information, keeping device costs and test run times under control.
At the same time, the team has a better understanding of what the result means. A successful emulator run confirms basic functionality in the selected environment; a targeted physical run adds confidence for specific hardware and a user segment.
Next step
Use analytics to select the three most commonly used combinations of manufacturer and Android version, and add one high-risk edge combination. Assign scenarios that make sense to each one and leave the rest in the fast virtual layer. The overview of mobile scenarios suitable for automation can also help with the selection. If customers use the same product in a browser, supplement the device matrix with a separate plan for automated testing of the web application.