Emulator vs real device: the bugs only a real phone shows
Emulators are great for layout, logic and quick checks. These bug classes only show on a real phone: battery savers, low RAM, dual SIM, OTP autofill, carrier networks and app switching.
In this article
- What an emulator does well
- 1. The maker's battery saver kills your app
- 2. Low memory closes your app mid-flow
- 3. Dual SIM and real SMS
- 4. Real carrier networks
- 5. Switching between real apps
- 6. The hardware and the maker's tweaks
- How to split the work
- Which real phones?
- Run your cases on real phones
Emulators are good. They boot in seconds, you can script them, and they catch most layout, logic and validation bugs before a person ever touches the build. If your team doesn't run one, start there.
The question is what they can't show. An emulator is a clean, stock Android with a perfect network connection and plenty of memory. Most of your users in India are on something else: a budget phone from Xiaomi, Samsung, Realme, Vivo or Oppo, each running the maker's own Android skin, with two SIMs, a daily data pack and dozens of apps competing for 4 GB of RAM.
Here are the bug classes that live in that gap.
What an emulator does well
Use an emulator, or an AI agent driving one, for:
- Layout and navigation: screens render, buttons are reachable, flows connect
- Validation: formats, limits, empty fields, error messages
- Business logic: prices, totals, rules, state changes
- Crashes on obvious paths: the app opening, the main flows completing
- Quick regression on every build
For these, an emulator gives the same answer as a real phone, faster and cheaper.
1. The maker's battery saver kills your app
Stock Android, which emulators run, is relatively gentle with background apps. MIUI and HyperOS on Xiaomi, Funtouch on Vivo, ColorOS on Oppo and Realme UI all add their own battery and memory managers. They can stop background work, block auto-start and delay notifications.
What breaks: push notifications that never arrive, OTP auto-read that misses the SMS, uploads that stop when the screen locks, and sync that only happens when the app is opened.
What to test: lock the phone for half an hour with default battery settings, then check notifications, OTP and uploads. Repeat with the app's auto-start turned off.
2. Low memory closes your app mid-flow
On 3–4 GB phones, the system closes background apps much sooner than on an emulator with generous memory.
What breaks: the user switches to their UPI app, camera or messages, comes back, and your app has restarted, so the form is empty, the cart is gone, or the order shows unpaid even though money left the account.
What to test: mid-flow, switch to two or three heavy apps, then return. Anything typed and any pending payment should still be there.
The sample 99tests report has exactly this: the cart empties when the user returns from the UPI app, on a Galaxy A15. The same flow passed on a Redmi 12.
3. Dual SIM and real SMS
Emulators fake SMS and have no second SIM slot. Real phones in India very often run two SIMs: one for calls and banking, one for data.
What breaks: UPI device binding sends the verification SMS from the wrong slot; the OTP lands on the SIM the app isn't reading; the SMS never leaves a SIM without an SMS pack; the OTP is filed as spam by the maker's messages app.
What to test: onboarding and OTP login with the bank-registered number in slot 2 and data on slot 1, and again with the slots swapped.
4. Real carrier networks
An emulator's network is either up or down, and when you cut it, it cuts cleanly. Real Jio, Airtel and Vi connections drop packets, slow down unevenly, fall back from 4G to 2G in lifts and basements, and get throttled when a daily data pack runs out.
What breaks: requests that hang without a timeout, so the user taps again and creates a duplicate order; payments shown as Failed while the bank is still processing; screens stuck on an offline banner after Wi-Fi hands over to mobile data.
What to test: submit a payment and walk into a lift; switch from Wi-Fi to 4G mid-request; use the app after the daily data pack runs out. Our network testing checklist has 39 cases.
5. Switching between real apps
UPI intent payments, sign-in with another app, sharing to WhatsApp and opening the camera all hand control to another installed app and expect it back. On an emulator, the other app often isn't installed, or behaves like a simplified test version.
What breaks: the return trip. The merchant app doesn't notice the payment finished, a back gesture cancels an order that was actually paid, or the app reloads from scratch on return.
6. The hardware and the maker's tweaks
- Fingerprint and face unlock: a failed scan, the fallback to PIN, and a new fingerprint added in Settings
- Screenshot blocking: the maker's screenshot gestures and screen recorders should respect your secure screens
- Lock-screen notifications: what they show depends on the maker's privacy settings
- Budget chipsets: heavy JavaScript, large images and long lists stutter first on a ₹10,000 phone
How to split the work
| Use an emulator or agent for | Use a real phone for |
|---|---|
| Layout, navigation, validation | Battery savers and background limits |
| Business logic and totals | Low memory and app switching |
| Obvious crashes, on every build | Dual SIM, real SMS and OTP autofill |
| Fast regression | Real carrier networks and handovers |
| Biometrics and the maker's security tweaks |
Run the emulator pass on every change. Run the real-phone pass on release candidates, especially for anything touching login, payments, onboarding or a store build.
Which real phones?
The ones your users carry. Sort your installs by device model and take the top five. If you don't have them, the 58 phones our testers own are listed with their specs and where apps break on each.
Run your cases on real phones
99tests testers run your test cases on their own phones, on their own SIMs and networks, and send back a verified report in 3 business days. Packages start at ₹9,999 + GST for up to ~25 cases on 2 phones.
