Rooted Android in the cloud: why no device farm will give you su

Every major cloud device platform will give you a real Android phone. None of them will give you root on it.

This is not an oversight, and it is not something that gets fixed in a future release. It falls out of how those platforms have to be built. Understanding why is useful, because it tells you exactly which problems a device cloud can solve for you and which ones it structurally cannot.

Why no device cloud offers you root

A cloud device farm's entire value proposition rests on one promise: the device you get is clean, and what you do on it cannot affect the next tenant. Everything else — the pricing, the parallelism, the certifications — is built on top of that guarantee.

Root breaks it. Not "makes it risky" — breaks it, in a way no policy can patch:

A root shell can defeat the reset. These platforms clean devices between sessions by uninstalling apps, clearing app data, and resetting settings through the framework. That works because a normal app cannot write outside the space the framework manages. With su, a tenant can write to system partitions, install a persistent module, modify the boot image, or leave something running that survives exactly the cleanup that was supposed to remove it.

Root defeats attestation. Play Integrity and SafetyNet exist to tell an app whether the device it is running on is trustworthy. A platform that hands out rooted devices is handing out devices that fail attestation — and, worse, devices that could be used to forge passing attestation for fraud. For a platform serving banks and payment apps, that is an unacceptable liability.

It contaminates the compliance story. SOC 2 and ISO 27001 attestations that these vendors sell to enterprise buyers rest on demonstrable tenant isolation. "Any customer may obtain kernel-level control of shared hardware" does not survive that audit.

So the answer is no, everywhere, permanently. BrowserStack, Sauce Labs, AWS Device Farm, Firebase Test Lab, LambdaTest, Kobiton — all no. Samsung's Remote Test Lab is free and gives you real hardware, but it is Samsung devices only and also does not offer root.

Who actually needs it

This is a smaller group than the internet suggests, and it is worth being honest that a lot of people asking for root do not need it.

You probably do not need root if you are running UI tests, checking layouts across screen sizes, reproducing a crash in your own app, or driving Appium against a normal app. Everything there works through standard ADB, and a normal cloud device serves it fine.

You do need root if:

• You are testing a Magisk module or an Xposed/LSPosed hook. The thing under test is the root-level modification. There is no non-rooted version of this test.
• You are doing mobile security work. Runtime instrumentation with Frida, unpacking obfuscated apps, hooking crypto calls to inspect key material, testing whether your own app's root detection actually works. Nearly all of this needs elevated privileges.
• You need to inspect another app's private storage. /data/data/<pkg>/ is unreadable without root. If your job is to verify that an app is not leaking credentials to disk, you need to read that directory.
• You are testing against a custom ROM or kernel. OEM firmware work, AOSP builds, kernel patches. The device has to be in a state a stock device is not.
• You need to intercept TLS system-wide. Since Android 7, user-installed CA certificates are not trusted by app traffic by default. Getting a certificate into the system store — the reliable way to proxy an app you did not build — requires root.
• You need deterministic system state. Freezing time, forcing a specific locale at the system level, controlling battery reporting, simulating conditions the framework does not expose.

If you are in that list, the entire commercial device-cloud category is closed to you, and has been the whole time.

The three ways people solve it

Buy the phone

Still the most common answer, and often correct. A used Pixel is cheap, unlocking the bootloader is documented, and Magisk installs in an afternoon.

What it costs you is everything that comes after: the device lives at somebody's desk, CI cannot reach it, it needs charging and babysitting, and when you need a second Android version you buy a second phone. It also means someone owns the treadmill of keeping root working across OS updates.

Root an emulator

An AVD with a writable system gives you root for free, and for a lot of Frida and hooking work it genuinely is enough. Start here if you can.

Where it stops: the emulator is x86, so ARM-native libraries need translation and sometimes just do not run — which matters, because obfuscated and packed apps are exactly the ones shipping ARM natives. There is no real TEE or StrongBox, so anything touching hardware-backed keys behaves differently. Play Integrity fails for reasons unrelated to your test. And the sensors, radio and camera are simulated, so anything reading real hardware gets fiction.

For security research specifically, the emulator's biggest problem is that malware and protected apps often detect it and change behaviour. You end up testing the anti-analysis path rather than the thing you meant to test.

Rent a rooted physical device

Real hardware, real TEE, real ARM, a root shell, and no phone on your desk. A handful of small operators are in this space, and it is the only category that gives you all four.

We should be straight about where we sit: we do not offer this today. Our rack is six Pixel 7a and every one of them has a locked bootloader, Verified Boot green, dm-verity enforcing and no su binary anywhere on the filesystem. If you came to this page looking to rent a rooted device this afternoon, we cannot serve you, and we would rather say so than let you find out after signing up.

What we do offer today is a real physical phone with a raw ADB shell — which is already more than the large platforms will give you, and is enough for a lot of the work on this page that does not strictly need su. Root is the single most-requested thing on our early-access list, and it is the next capability we intend to add.

Why the Pixel 7a is the right device to add it on: it is one of the few modern phones where bootloader unlocking is officially supported by the manufacturer, AOSP support is first-class, and Magisk works without vendor-specific hacks. Rooting is a supported path rather than an exploit chain, which matters when the device has to return to a known state afterwards.

The isolation problem, and why root makes it harder

The reason nobody offers root is real, and we do not get to hand-wave it — it is also most of why we have not shipped it yet. Root and "guaranteed clean between renters" pull against each other, and the second one is not negotiable.

Our current answer is that we never share a device between tenants concurrently, and we do not trust the framework to clean it.

Between renters, the device is wiped by an agent on the controller that owns it over USB — packages cleared, storage removed, and the result verified before the phone can be rented again. The gate is fail-closed: a device that cannot prove it was cleaned does not go back into the pool, it goes into maintenance. We built that verification after discovering our own storage check had a bug that made it pass without inspecting anything, which is a good argument for the fail-closed default.

The device is also not a network pivot. Phones reach the internet through the controller, which is an enforced chokepoint with an egress filter, rather than sitting on a network with anything else that matters.

That is the machinery root would have to survive. The large platforms achieve isolation by never granting privilege at all; the trade we would be making is to grant it and lean entirely on the wipe and the network boundary instead. That is a genuinely weaker guarantee against a determined attacker, and getting it right — not getting it shipped — is what stands between us and offering root. It is also the reason a bank is going to buy BrowserStack and not us, and that is fine.

The short version

If you need root on Android in the cloud, the large platforms are not a fallback option — they are closed to you by design, and no roadmap changes that.

Your real choices are: own the phone, accept the emulator's limits, or rent from one of the small operators willing to make the opposite trade. Pick based on whether what you are testing needs real ARM and a real TEE, because that is the line the emulator cannot cross.

And if you want root on a rented device specifically, tell us. We are not shipping it today, but demand is what decides which capability we build next, and this one is currently at the top of the list.