Professional mobile application development inevitably faces the problem of ecosystem fragmentation. Millions of combinations of operating system versions, screen resolutions, and hardware configurations make quality assurance one of the most resource-intensive tasks in the IT industry. The correct choice of physical devices for testing is not just a purchase of popular models, but strategic planning of a laboratory fleet, which directly affects the stability of the product.
Unlike emulators, which often distort the real behavior of hardware, physical devices allow you to identify problems with memory, overheating, antennas and specific drivers. To create an effective set of gadgets, you need to analyze the usage statistics of your target audience, but there are also universal recommendations that apply to most projects.
It is not always necessary to purchase dozens of devices. A competent approach to creating a test bench allows you to reduce the budget while maintaining a high coverage of use cases. It is important to understand the difference between devices for functional testing, layout checking and load testing, since the requirements for them can vary significantly.
Analysis of statistics and priority of OS versions
The first step should always be to analyze the market share of different versions of Android. Global Google Play Console statistics show which OS versions your potential users are currently using. You should focus not on the latest version, which was released yesterday, but on those releases that occupy leading positions in the region of your presence.
For the correct operation of most banking applications and instant messengers, it is critical to keep them up-to-date. API levels. However, support for legacy versions such as Android 8.0 or 9.0 often remains mandatory in the enterprise sector, where fleet updates are slow. Ignoring these versions can lead to the loss of a significant part of B2B clients.
When forming a device matrix, you should take into account not only major versions of the system, but also popular custom shells. Firmware from Samsung One UI, Xiaomi MIUI or ColorOS from Oppo have their own power management features that can kill the background processes of your application.
Don't forget about Android Go Edition - a lightweight version of the system for budget devices with a small amount of RAM. Testing on such devices often reveals critical optimization errors that are invisible on flagships with 12 GB RAM.
⚠️ Attention: Statistics on the use of Android versions changes quarterly. Before purchasing equipment, be sure to check the current data in the public Google Play Console panel or reports from analytical agencies so as not to buy a fleet of devices that have already gone out of mass use.
Form factors and display characteristics
Diversity of screens is the second biggest headache for QA engineers. The modern market offers devices with cutouts, camera holes, folding mechanisms and even dual displays. Your application must display correctly on all types of matrix, without overlapping important interface elements with system controls.
Particular attention should be paid to the aspect ratio. Standard 16:9 is becoming a thing of the past, giving way to elongated formats of 20:9 and higher. On such screens, there are often problems with scaling images or “cutting off” content at the bottom of the application if safe display areas are not taken into account.
The sample must necessarily include devices with different types of matrices: IPS and AMOLED. Differences in color rendering, contrast and working with a dark theme can be critical for design-oriented projects. In addition, AMOLED screens sometimes exhibit problems with flickering or artifacts at low brightness.
Be sure to include at least one foldable smartphone (Fold or Flip) in your kit. Testing the responsiveness of the interface when the physical geometry of the screen changes is the new quality standard for 2026.
Pixel density (DPI) also plays a role, especially if the application uses a lot of small text or complex graphics. Testing on low-resolution devices will help ensure that the interface remains readable for budget segment users.
| Device category | Screen diagonal | Resolution (example) | Testing purpose |
|---|---|---|---|
| Compact smartphone | 5.8 - 6.1 inches | 1080 x 2340 | Checking ergonomics with one hand |
| Standard flagship | 6.4 - 6.7 inches | 1440 x 3200 | Main use case |
| Folding phone | 7.6 inches (unfolded) | 2176 x 1812 | Adaptability and multitasking |
| Tablet | 10 - 11 inches | 2560 x 1600 | Split-screen mode |
Hardware power and memory management
CPU performance and RAM directly affect how your app behaves under load. Testing only on high-end devices with excess resources creates a false sense of security. An application that "flies" on Snapdragon 8 Gen 3may completely freeze on a budget MediaTek processor.
A critically important parameter is the amount of available RAM. When there is a shortage of RAM, the system begins to aggressively unload background processes. This is an ideal scenario for testing how your application recovers from being killed by the system in the background.
- 📱 Devices with 4 GB RAM - a must for testing performance under severe resource constraints.
- 🚀 Smartphones with 12+ GB RAM - essential for stress testing multitasking and working with heavy graphics elements.
- 💾 Devices with slow flash memory (eMMC) - help identify problems with long startup times and interface slowdowns.
It is also worth considering heat dissipation. Long sessions of use, video calls or navigation can cause CPU throttling. On devices with a poor cooling system, performance can drop significantly after just 15 minutes of active operation, which must be recorded in reports.
☑️ Selection criteria for hardware
The processor architecture should not be ignored. Although most modern chips use ARM64, there are nuances of working with native libraries (JNI), which can only appear on specific cores.
Vendor specifics and interface customization
Pure Android is becoming increasingly rare. The vast majority of devices on the market run proprietary shells that are deeply integrated into the system. These modifications often change the standard behavior of the API, which leads to bugs that cannot be reproduced on an emulator or a “pure” Pixel.
The battery management policy of Chinese vendors is a particular problem. Brands like Xiaomi, Huawei and Oppo are known for their aggressive “task killer” algorithms. An app may not receive push notifications or stop downloading files unless the user manually whitelists it.
⚠️ Note: Huawei and Honor devices released after 2020 do not have Google Play Services (GMS). If your application depends on Google Maps, Firebase, or push notifications via FCM, testing on these devices will show key functionality completely inoperable without special adaptation for HMS.
Differences in the implementation of permissions may also come as a surprise. Requesting access to geolocation, camera, or microphone may look and work differently depending on the shell version. For example, in some firmware, access to the file system is limited even if you have permission to read the storage.
It is recommended to have at least one representative from each major manufacturer in your fleet: Samsung, Xiaomi, Realme, Pixel. This will cover about 80% of all possible scenarios of system behavior in real conditions.
Specialized scenarios and peripherals
In addition to basic characteristics, the choice of devices should be dictated by the specific functionality of your application. If you're designing a fitness tracker, having accurate motion sensors and a heart rate monitor becomes priority number one. For navigation services, the accuracy of the GPS module and support for dual-frequency navigation are critical.
Testing cameras is a separate big topic. Different camera modules have different image processing, focusing speed and Camera2 API support. An application for scanning QR codes can work perfectly on one model and completely fail to focus on another in low light.
Nuances of working with NFC
NFC modules in different smartphones have different antenna locations. In some models, the reading area is at the top, in others - in the center. This is critical for contactless payment or pass applications, since the user will have to intuitively search for the correct position of the phone.
Don't forget about biometrics. Fingerprint scanners come in capacitive, optical and ultrasonic (in-screen) types. The speed and reliability of unlocking through your app will depend on the type of sensor. Facial unlocking also varies from simple 2D to secure 3D (Face ID analogues on Android are few, but they exist).
For applications that work with sound, it is important to check the presence of a 3.5 mm jack or the quality of Bluetooth codecs. Some budget devices may have noticeable audio latency or recording noise, making it impossible to use audio features.
Budget solutions and cloud farms
Purchasing a large fleet of physical devices can be financially burdensome, especially for startups. In such cases, cloud device farms come to the rescue. Services like BrowserStack, Sauce Labs or Firebase Test Lab provide remote access to hundreds of real devices.
The use of cloud solutions is ideal for regression testing and compatibility testing on rare models that there is no point in buying for the office. However, for debugging complex bugs related to the network or specific behavior of hardware, the physical presence of the device often remains indispensable.
- 🌩️ Cloud farms - great for automated test runs on multiple configurations.
- 🏢 Local park - necessary for manual exploratory testing and debugging of hardware problems.
- 🔄 Hybrid approach - using your main devices plus renting rare models in the cloud as needed.
When choosing a cloud provider, pay attention to the ability to install your own APK file and access to device logs in real time. Without these functions, the process of finding the reasons for an application crash will turn into guessing from tea leaves.
The optimal strategy is to have 5-7 key devices locally (different vendors, OS versions, screens), and use cloud subscription services for mass testing of rare configurations.
Frequently asked questions (FAQ)
How many minimum devices do you need to have on staff for quality testing?
The minimum viable set consists of 3-5 devices: one fresh flagship with the latest version of Android, one popular mid-price device (2-3 years ago) with the current OS, one budget device with Android Go or an old version of the system, and one tablet. This will cover about 70% of the user base.
Is it possible to completely replace physical devices with emulators?
No, emulators cannot simulate the real behavior of radio modules, the precise operation of sensors, switching between Wi-Fi and a cellular network, as well as low-memory or overheating scenarios. They are suitable for unit tests and quick layout checks, but not for final QA.
Is it worth buying devices with an unlocked bootloader?
For most testing tasks this is not required and even undesirable, since unlocking the bootloader often entails a loss of warranty and the inability to use protected functions (for example, Google Pay or banking applications). The exception is deep system testing or the development of custom firmware.
How often should the fleet of test devices be updated?
It is recommended to review the composition of the fleet once a year. Devices older than 3-4 years are losing relevance, as they no longer receive security updates, and their usage rate is falling. New models should be added immediately after the release of major versions of Android.
Is it important to have 5G in test smartphones?
It depends on the geography of your product. If the application is aimed at markets where 5G is already widespread (USA, China, Europe), then having such a device is mandatory to test operation with high speeds and network switching. For local projects in regions with developed 4G, this is still secondary.