VC LABKnowledge baseTesting on budget Android

Budget Android: the devices where half the audience lives

In Uzbekistan, Kyrgyzstan and the regions of Kazakhstan and Russia the typical phone is an inexpensive Android with limited memory, unstable mobile internet and a system version two or three years behind the latest. The dev team sees the product on flagships, users see it on these devices. The difference between them is the subject of testing.

What breaks specifically on budget devices

  • Memory: the system kills the app in the background when switching to the camera or a messenger — and the user returns to an empty screen instead of a half-completed order.
  • Network: requests that take a second on Wi-Fi time out on weak mobile internet; repeated taps create duplicates.
  • System versions: features available only in recent Android versions silently fail or crash the app on old ones.
  • Screens: narrow and short displays clip strings, hide buttons under the keyboard, break card grids.
  • Performance: animations and heavy screens lag, image lists scroll in jerks, cold start takes tens of seconds.
  • Missing services: some devices have no Google services, so pushes, maps and Google sign-in do not work without alternatives.
  • Fonts and languages: system fonts of budget firmware lack some characters — the apostrophes of Uzbek Latin, the additional letters of Kazakh and Kyrgyz.

What to test on

The rule is simple: the test device set must mirror the audience's device set, not the developers' fleet. For the region's markets that means at least three budget models of popular brands with different Android versions, including one on the minimum supported version and one without Google services, plus one flagship for comparison. An emulator does not replace a real device: it reproduces neither memory eviction, nor network behaviour, nor the manufacturer's firmware.

Real audience data lives in the app analytics: models, versions, screen sizes. The device set is built from them, not from assumptions.

How to test

  1. Interruption scenarios: background the app at every step of payment and checkout, return after a minute, after ten minutes, after a call.
  2. Network throttling: emulating a slow and intermittent connection through device settings or a proxy; checking timeouts, retries and error messages.
  3. Low memory: launching with heavy apps open, checking state recovery after eviction.
  4. Minimum system version: a full pass of the main flows on the oldest supported version.
  5. Narrow screens: checking every screen with the keyboard open and with an enlarged system font.
  6. Cold start and first screen: time to interactivity on a budget device with a slow network.

Typical findings

A cart that empties after returning from a messenger. A "Pay" button hidden under the keyboard on a low-resolution screen. A double order after two taps on a slow network. A crash on an old system version because of a component added "for looks". Boxes instead of letters in the Uzbek and Kazakh versions. None of these findings reproduces on a flagship in the office with fast Wi-Fi.

FAQ

Are cloud device farms like BrowserStack enough?
For breadth of coverage across models and versions — yes. For network behaviour and missing services — not always: some scenarios have to run on physical devices with SIM cards of the target country. We combine both approaches.
Which minimum Android version to support?
The one your audience analytics shows, not the one convenient for development. In the region the share of devices on three- or four-year-old versions remains noticeable, and dropping them is a loss of users, not a technical decision.
Should we test on devices without Google services?
If they are in the audience — yes. Pushes, maps, Google sign-in and in-app purchases need alternatives, and without a check the app simply does not work in key places on such devices.
How often to repeat these checks?
A full pass — before releases that touch checkout, payment or heavy screens; a short set on one budget device — before every release as part of regression.

Tell us about your task

We reply within one business day and send an estimate in 1–2 days. Free of charge.

Updated: 2026-10-02