Why DeviceRent runs on real phones, not emulators

Most "cloud Android" platforms run emulators. The math is obvious — emulators spin up in seconds, cost almost nothing per hour, and scale by adding more EC2 instances. We looked at that model and walked away from it on purpose. This is a note on why.

What emulators are good at

We are not anti-emulator. For unit tests, layout previews, and most of an Android Studio loop, the emulator is the right tool. It boots fast, it integrates with your IDE, and it is free. If your code path is pure JVM and a few Compose surfaces, you do not need us.

What emulators are quietly bad at

The cracks show the moment your app touches the parts of Android that are not pure Java.

• Cellular radio. The emulator has a "modem" that is a Python script. It does not handover between cells, it does not drop to 2G when your customer walks into a tunnel, and it does not care about carrier-specific quirks. If your app does anything around eSIM, VoLTE, or low-bandwidth fallback, you are testing fiction.
• GPU and display pipeline. Emulators render through SwiftShader or your host's GPU translated through a guest driver. That is not what a Mali or Adreno chip does. Frame pacing, vsync, HDR, and any custom shader behave differently. We have seen real bugs (a janky scroll on Pixel 7a, a black flash on the Galaxy S23 OLED transition) that simply do not reproduce in any emulator we tried.
• Camera ISP. The "front camera" in an emulator is a webcam if you are lucky and a static PNG if you are not. Your ML pipeline, your auto-focus heuristics, your exposure compensation — none of it gets exercised.
• Sensors. Real accelerometers have noise. Real gyroscopes drift. The emulator gives you clean synthetic signals.
• Vendor skins. Samsung's One UI patches dozens of framework calls. Xiaomi's MIUI does the same. An emulator runs AOSP. If your app crashes only on a Samsung A14, no number of AVDs will save you.

Why "cloud farms" did not solve it for us either

The big device clouds (Firebase Test Lab, BrowserStack, Sauce Labs) do run real hardware. We tried them. The problem is they are batch-execution platforms — you upload an APK, they run a script, they hand you back a video. That is fine for CI. It is awful for what we actually wanted: poking around in a shell, trying things, repro-ing a customer report, attaching to logcat while you change a setting, plugging in a USB debugger at the firmware level.

DeviceRent is built for the second workflow. You get a live ADB shell on a real phone, in under a second, billed by the minute. Same machine, same hardware ID, same logcat across your whole session. You can install your APK, kill it, reinstall a different build, and watch the entire process from the shell. It is the workflow you have on your desk, except the phone is in our rack.

The trade-off we accept

Real phones are not free. Each device sits in a rack, draws a couple of watts at idle, needs a USB hub that does not brown out when ten phones are charging, and occasionally needs a human to walk into the room and replace a flaky cable. We spend more on hardware per session than a cloud emulator service does. Our prices reflect it — minutes, not hours.

The bet is that for the work where emulators fall down, paying a few cents a minute for a real Pixel is the smallest line item in your engineering budget. So far the bet has held.

Where we go from here

The current fleet is small and the waitlist is honest about it. We are scaling devices in lockstep with demand, not ahead of it, because every phone we add comes with a real cabling and thermal budget. The next phases — automated wipe between sessions, screen mirroring in the browser, snapshotting installed APKs — all assume the hardware stays real. We will write more about each of those as they ship.

If your bug only shows up on a real device and you do not want to wait three weeks for shipping, that is what we built this for.