PhoneFleet

Real phone vs cloud phone: what's actually different

A cloud phone is Android running virtually on a server; a real phone is the hardware itself. Both can live in a datacentre and answer to your browser, an API or an AI agent, but apps don't always behave the same on them.

Updated 6 October 2026 · About Android devices you control remotely, not cloud phone systems for business calls · Sources

Which do you need?

Six questions. Answer the ones that apply; the recommendation updates as you go.

  1. Do you need dozens of devices for a short burst, then none?
  2. Is the lowest price per device the deciding factor?
  3. Do you need many Android versions, including very old ones?
  4. Does it matter how your app behaves on real hardware: graphics, video, performance?
  5. Are you testing a release before it reaches users?
  6. Should one device stay the same for weeks, logged in and running unattended?
Recommendation

Answer a question to start

    Rule of thumb: speed, price and many Android versions point to a cloud phone; real hardware behaviour, release testing and long-running dedicated devices point to a real phone.

    What each one is

    "Real" gets stretched in this market. Some providers call Android running on ARM servers a real device, and some list "real device parameters" that are values assigned to a virtual phone. Here's what the words mean underneath.

    Emulator
    A virtual Android device on your own computer or CI server. On a typical x86 machine it translates ARM code, which Google supports for development only.
    Cloud phone
    A virtual Android instance on a provider's server, usually a container that shares the server's kernel or a virtual machine with its own. Many instances share one machine.
    Real phone, hosted
    A physical Android phone in a rack, controlled over the network. It has its own processor, GPU and the manufacturer's Android build. Google runs the same idea for developers as Android Device Streaming.

    How they're built

    The app sits on top of every stack. What changes is everything underneath it, and how much of it is shared with other people's devices.

    Emulator

    1. Your app
    2. Google system image
    3. Guest kernel
    4. Emulated hardware, ARM translated on x86
    5. Your computer

    Cloud phone

    1. Your app
    2. Provider's Android build
    3. Server kernel, shared by containers
    4. Shared GPU or software rendering
    5. A server running many instances

    Real phone, hosted

    1. Your app
    2. Manufacturer's Android build
    3. The phone's own kernel
    4. The phone's own GPU and video decoders
    5. One physical phone, yours alone
    Shared with other instances Emulated or translatedSimplified; virtual machines give each instance its own kernel.

    Real phone vs cloud phone, side by side

    AspectEmulatorCloud phoneReal phone, hosted
    What it isVirtual device on your computerVirtual Android on a provider's serverA physical Android phone in a rack
    ProcessorYour computer's, often translating ARMServer CPU, shared by many instancesThe phone's own chip
    GraphicsHost GPU or software renderingShared GPU or software renderingThe phone's mobile GPU and drivers
    Video decodingMostly softwareUsually software or host-sideThe phone's hardware decoders
    Android buildGoogle system imageProvider's build, based on open-source AndroidThe manufacturer's own build
    Shared with othersNo (your machine)Usually, on the same serverNever: one customer per phone
    Snapshots and instant resetYesYesNo; the phone keeps its state
    Scale upLimited by your hardwareInstantAs many phones as you reserve
    Android versionsAlmost anyMany, by planWhat the hardware runs
    Price per deviceFree on your hardwareLowestHigher, with nothing to buy or maintain
    ControlLocal toolsBrowser or app; API and ADB on some plansBrowser, REST API, ADB, MCP
    Best forDaily development, CI, early testsCheap scale, throwaway sessions, light 24/7 workRelease testing, AI agents on real apps, long-running dedicated devices

    Cloud phone rows describe common setups (containers and virtual machines); individual providers differ.

    Where apps behave differently

    None of this matters for an app that shows a form and calls an API. It matters a lot for anything that leans on the hardware.

    Graphics
    Virtual devices render through a shared server GPU or in software. Games, maps, video editors and anything with heavy animation can run slower, look different or hit driver bugs your users never see, and miss the ones they do.
    Video
    Phones decode and encode video in dedicated hardware. Virtual devices usually fall back to software codecs, which changes playback smoothness, CPU load and even which formats work at all.
    The Android build
    Manufacturers ship their own Android, with their own power management, background limits and quirks. A cloud phone runs a build based on open-source Android, so behaviour that depends on the manufacturer's build won't show up.
    Native code
    Apps with ARM native libraries run as-is on a phone. On an x86 emulator they're translated, which is slower and supported only for development.
    Performance
    A cloud phone shares CPU, memory and graphics with its neighbours, so timing varies with their load. A dedicated phone gives the same performance every run.

    When a cloud phone is the better choice

    Google calls the emulator the best option for most testing, and cloud phones extend that to the server. Pick virtual when:

    • You need dozens or hundreds of devices in minutes, for a short burst
    • The lowest price per device matters more than hardware accuracy
    • You want a clean snapshot every run, or throwaway sessions
    • You need many Android versions, including very old or brand-new ones
    • You're running unit and pre-merge tests in CI
    • You're prototyping an agent and only need an Android screen and ADB for now
    • You need simulated location, sensors or network conditions on demand

    When a real phone is worth it

    • Release testing. Google's own testing guidance moves from emulators before merging to a spread of real phones before release.
    • Apps that lean on the hardware. Graphics, video, maps, games and anything performance-sensitive.
    • AI agents working real apps. When the agent's results need to hold on the phones people actually use.
    • Long-running, dedicated devices. One phone that keeps its apps, logins and setup for weeks, on hardware nobody else touches.

    Rent real Android phonesCompare with building your own

    What a phone in a rack can't do

    A hosted phone is real hardware, but it lives on a shelf. Nobody carries it, points its camera or taps a card on it, and cameras, GPS, SIMs and batteries aren't promised. You get the versions of Android the hardware supports, not every version ever made, and it costs more per device than a virtual one. If your work needs something specific, tell us when you reserve.

    Real phones on real networks are only useful if they're used honestly, so our Acceptable Use Policy bans fraud, spam and fake engagement.

    Real phone vs cloud phone: questions

    What is a cloud phone?

    A cloud phone is a virtual Android device running on a server that you control remotely, usually as an emulator, a container (Android sharing the server's kernel) or a virtual machine. "Cloud phone system" also means a business phone line over the internet, which is a different product.

    Is a cloud phone a real phone?

    No. A cloud phone is software running on server hardware, even when that server uses ARM chips like phones do. Some providers call ARM servers "real devices", but a real phone is a physical handset with its own processor, GPU and Android build.

    Is a cloud phone the same as an emulator?

    They're close relatives. An emulator usually runs on your own computer, often on an x86 processor that translates ARM code. A cloud phone usually runs as a container or virtual machine on a provider's servers. Both are virtual devices.

    What are the downsides of cloud phones?

    Cloud phones share server resources with other instances, often render graphics in software or on a shared GPU, simulate sensors, and run builds based on open-source Android rather than the manufacturer builds real users have. Apps that depend on graphics, video or performance can behave differently than on a phone.

    When is a cloud phone the better choice?

    When you need many devices quickly, the lowest price per device, clean snapshots, many Android versions, or early tests in CI. Google calls the Android emulator the best option for most testing.

    Why do apps behave differently on a real phone?

    A real phone has its own GPU and graphics drivers, hardware video codecs, the manufacturer's Android build, native ARM execution and performance nobody else shares. A virtual device approximates or replaces some of these.

    Do real phones in a rack have cameras, GPS and SIM cards?

    Don't assume so. Rack-hosted phones are there to run apps; nobody moves them or points their cameras at anything. If your work needs a SIM, mobile data or specific hardware, ask when you reserve and we'll tell you what we can provide.

    Is a PhoneFleet phone shared with anyone, and is it wiped afterwards?

    Each phone is dedicated to one customer for as long as they rent it. When a customer releases a device, we wipe it and set it up fresh before anyone else can rent it.

    Can an AI agent control a real phone the way it controls a cloud phone?

    Yes. PhoneFleet phones are reachable through a REST API, ADB over a secure tunnel and an MCP server, as well as a live screen in the browser.

    What does Google recommend: emulators or real devices?

    Both, at different stages: emulators for tests before merging, a real phone or two after merging, and a spread of real phones before a release. Google's example release plan uses 8 phones, a foldable and a tablet.

    Sources