Android Emulator vs Genymotion: which virtual device to use

The Android Emulator is Google’s own virtual device. It ships through the Android SDK and Android Studio, and it is free. Genymotion is a commercial emulator from a separate company. It comes as a desktop app, a command line tool and a cloud service, and it has a long history with QA teams that want fast x86 devices and a lot of sensor controls.

I run Android automation from Singapore, and most of my work touches both. This isn’t a benchmark post: I haven’t run new speed tests and won’t invent numbers. It compares how the two products are built and licensed and where each one fits. Check version-specific details against the docs before you commit a team to either.

My short verdicts:

• general app development, free CI, and anything tied to Google’s tooling: Android Emulator
• QA teams that want a managed device catalogue, sensor widgets and a cloud option with a CLI: Genymotion
• anything that depends on a real carrier, real hardware or real-world network behaviour: neither, and that matters more than the rest of this post

TL;DR comparison table

	Android Emulator	Genymotion
Pricing	Free, bundled with the Android SDK and Android Studio	Free tier for personal use with limits, paid licences for business use, and per-minute cloud billing for the SaaS product. Check the vendor pricing page, since fees change
Install	Android Studio, or sdkmanager plus avdmanager from the command line tools	Separate installer for Desktop, and a Python CLI (gmsaas) for the cloud
Images	Official Google images: Google APIs, Google Play and AOSP variants, x86_64 and arm64-v8a	Genymotion’s own device templates and Android images, plus cloud images
Apple Silicon	Native arm64 images through Apple’s Hypervisor framework	Supported in recent Desktop releases per vendor docs, check the current notes
CLI	emulator, avdmanager, sdkmanager, adb	gmtool for Desktop and gmsaas for cloud
Cloud option	None from Google for the emulator itself	Genymotion SaaS and images for cloud marketplaces
Support	Documentation, issue tracker and community	Commercial support on paid plans, vendor docs
Target user	Developers, open source projects, CI on a budget	QA teams, agencies and companies that pay for tooling

Android Emulator at a glance

The Android Emulator is built on QEMU. Google maintains it and releases it through the SDK manager as a separate package, so you update it independently of Android Studio. You can get it without the IDE too. Install the command line tools, then run sdkmanager "emulator" "platform-tools" "system-images;android-35;google_apis;x86_64". On an Apple Silicon Mac you pick the arm64-v8a image instead. Run sdkmanager --list to see current API levels; Android 16 (API 36) images exist, and the string above is only an example of the format.

You create a virtual device with avdmanager create avd -n test35 -k "system-images;android-35;google_apis;x86_64" and start it with emulator -avd test35. The official command line reference documents the flags I use most:

• -no-window: run headless, which is what CI wants
• -no-audio and -no-boot-anim: trim startup work you don’t need
• -gpu swiftshader_indirect: software rendering for hosts with no usable GPU
• -no-snapshot and -wipe-data: start clean, which matters for repeatable tests
• -accel-check: report whether hardware acceleration is available on the host

The image variants matter more than people expect. Google APIs images include Google’s services but no Play Store. Google Play images include the Play Store and are the closest to a retail device, but they are production-signed, so you don’t get the same debugging access. AOSP images carry no Google apps at all. You pick the variant based on what your app needs.

Acceleration depends on the host. Linux uses KVM, Windows uses the Windows Hypervisor Platform (or Hyper-V), and macOS uses Apple’s Hypervisor framework. Intel retired HAXM, so older guides that tell you to install it are stale. Google’s emulator overview covers the acceleration requirements per platform.

It also has an extended controls panel with location, cellular and battery settings, virtual sensors, snapshots, a camera scene and foldable and wear device profiles. Some of that is reachable from the command line. adb emu geo fix <longitude> <latitude> sets a location, and the -netspeed and -netdelay flags emulate network profiles.

Genymotion at a glance

Genymotion is a product family, so it helps to split it up:

• Genymotion Desktop: the app you install on a workstation, with a catalogue of device templates
• gmtool: the command line interface for Desktop, which creates, starts, stops and drives devices
• Genymotion SaaS: virtual devices in the vendor’s cloud, driven from a browser or the gmsaas CLI
• Genymotion device images for cloud marketplaces: you run the virtual device inside your own cloud account

Desktop is the part most people mean. Historically it ran Android x86 images on top of VirtualBox on Windows and Linux. The Genymotion Desktop documentation is the place to confirm hypervisor requirements for your host before you install.

What Genymotion is known for is the control surface. The Desktop app has widgets for battery, GPS, camera, network conditions, rotation, multitouch, and device identifiers. For QA people who want to flip conditions in a few clicks without writing adb commands, that is a real advantage. Images are, as I understand it, rooted by default on Desktop, which suits debugging and doesn’t match how a retail phone behaves. Confirm that in the docs, and keep it in mind when judging whether a result will hold on a customer’s phone.

For automation, the gmtool commands I’d look at first are gmtool admin list, gmtool admin create, gmtool admin start, gmtool admin stop and gmtool device install. Whether gmtool is available on a given licence tier is something to check before you build a pipeline around it. On the cloud side, the flow is gmsaas auth login, then gmsaas instances start, then gmsaas instances adbconnect <instance-uuid>, which gives you a normal adb connection to the cloud device. The gmsaas tool is installed with pip and documented by the vendor.

head-to-head

Setup and install

The Android Emulator wins on reach. If you have Android Studio, you have it. If you don’t, the command line tools are a zip file and four sdkmanager commands. Everything is scriptable, and a fresh CI runner can go from nothing to a booted device without any account or licence key.

Genymotion needs an installer, an account and a licence decision. That is not a flaw, but it is friction.

Device and API coverage

Google ships its own system images for each Android release, usually earliest for new previews. If you need to test on a new API level in the first week it exists, the official emulator is where it appears. It also covers form factors that Genymotion’s catalogue may lag on, such as foldables, tablets, Wear OS, Android TV and Automotive.

Genymotion’s catalogue is organised by named device templates and Android versions, which is nicer to browse. It is a curated list, though, and curated lists trail Google on new releases. For old Android versions the picture reverses a little. Genymotion has historically been convenient for spinning up an old API level quickly, but I’d check the catalogue for the exact version you need.

Performance on Apple Silicon and x86

I haven’t benchmarked these side by side, and anyone quoting a precise percentage without a method deserves suspicion.

What I can say from how they work:

• on x86 hosts with hardware acceleration on, both run x86 guests with hypervisor support, and both are usable for daily development. Without acceleration, both are painful, and emulator -accel-check will tell you which situation you’re in
• on Apple Silicon, the Android Emulator runs arm64 guests natively through Apple’s framework. That avoids instruction translation for the guest and is the supported route on those Macs
• Genymotion’s Apple Silicon support is more recent than its x86 history. The vendor documents it, so read the current release notes for which images and features are available
• apps that ship only x86 or only arm native code can behave differently depending on the guest architecture. Recent Google x86 images include ARM translation, which helps but is not identical to running on an arm64 device

If your app contains native libraries, test on the architecture your users have, which for most phones is arm64. On an Apple Silicon Mac an arm64 guest is closer to that than an x86 guest ever is.

Sensors and testing features

Genymotion’s widgets are quicker to use. If someone on your QA team doesn’t live in a terminal, they can set battery level, GPS and network conditions without any commands.

The Android Emulator covers most of the same ground, but spread across the extended controls window, the emulator console and adb commands. It is just as capable once you know where things are. It’s a bit slower to learn and much easier to script, and snapshots are built in.

For anything where I need to read system state, the usual adb tooling applies to both. If you work with battery data, my notes on dumpsys batteryinfo vs batterystats apply, with one caveat: a virtual battery is a number somebody typed in. It tells you how your app reacts to a value, not how a phone drains.

Automation and CLI

Both talk adb, so Appium, UI Automator, Espresso and your own shell scripts work against either. If you want to know what is actually going over the wire when your tooling connects, my adb protocol deep dive explains it.

The Android Emulator’s CLI is lower level and very flexible. A standard headless CI boot looks like this:

emulator -avd test35 -no-window -no-audio -no-boot-anim -gpu swiftshader_indirect &
adb wait-for-device
adb shell getprop sys.boot_completed

You poll sys.boot_completed until it returns 1, since wait-for-device returns before Android has finished booting.

Genymotion’s gmtool is more opinionated. It has fewer knobs, but its commands map neatly onto “make me a device and install this APK”. The cloud CLI, gmsaas, gives you something Google doesn’t offer for the emulator: a remote instance you attach to with adbconnect, so a CI job needs no local virtualization at all.

Cloud options

This is where the products split. Google doesn’t sell the emulator as a hosted service. You can run it on your own cloud VMs if the instance type supports nested virtualization or you accept software rendering, and many teams do. You carry the setup and the cost.

Genymotion sells the hosted version directly. SaaS is billed by usage (check the current rates on the vendor’s pricing page, since I won’t quote numbers that change). They also publish images for the big cloud marketplaces, so you can run Genymotion inside your own account. If your CI runners lack virtualization support, that is a real reason to pick it.

For when virtual devices stop being enough and you need many real ones, see what an Android device farm is, which is the same trade-off at larger scale.

Licensing and cost

The Android Emulator costs nothing, and you never negotiate for it. Genymotion has a free personal tier with restrictions, and business use needs a paid licence, as of October 2026 per the vendor’s published terms. Get a quote or read the pricing page rather than trusting a blog for prices. This is not legal advice. If you use Genymotion at work on a personal licence, read the licence terms first, because commercial use rules are the thing people get wrong.

The honest cost comparison isn’t licence against no licence. It is the licence fee against the hours your team loses to setup, flaky CI boots and missing sensor tooling. For a one-person project the free tool wins. For a QA team of ten, a paid tool can pay for itself. Measure on your own pipeline.

Support and ecosystem

Google’s emulator has first-party documentation, an issue tracker, and the biggest community by a wide margin. Android Studio integrates it directly.

Genymotion has vendor documentation and commercial support on paid plans, and it offers plugins for Android Studio. If you want a contact who answers, that exists on one side only.

What neither replaces

A virtual device is not a phone.

• no real radio: both emulate a cellular connection with a profile. Neither carries real carrier traffic, so carrier-specific behaviour, such as how an app reacts to a mobile IP change or a carrier’s network filtering, isn’t tested. I wrote about this in testing apps on real carrier networks
• no real thermals, battery chemistry or vendor skins: Samsung, Xiaomi and others modify Android in ways that break apps, and an emulator running stock Android won’t show it
• no real sensors, camera pipelines or vendor GPU drivers
• some apps check the environment they run in and behave differently inside a virtual device. If you own the app or are authorised to test it, that is something to plan for with your own build flags and test accounts. I’m not going to explain how to get around another company’s checks

If you need a real Android phone with a Singapore mobile IP that you control from a browser, cloudf.one rents real phones on dedicated hardware, each with a persistent Singapore mobile IP. It is Singapore only. One thing to know about workflow: there is no self-service adb. adb and Appium reach a rented phone only through a WireGuard tunnel that we set up on request by email to [email protected]. If your whole test plan is scripted over adb with no setup step, a virtual device fits better.

use-case verdicts

Daily app development

Winner: Android Emulator. It is already in Android Studio, new API levels land there first, and it costs nothing. Genymotion’s plugin works, but you add a vendor to your toolchain for little gain.

CI pipeline on a budget

Winner: Android Emulator. Headless boot, snapshots and free licensing make it easy to put in a container or a runner. The catch is that you own the virtualization setup, and without nested virtualization you’ll fight slow software rendering.

QA team with mixed technical skills

Winner: Genymotion. The widgets for GPS, battery and network make condition testing accessible to people who don’t script. Commercial support helps when something breaks, and a licence fee is easier to justify with a team behind it.

Remote or cloud-hosted virtual devices

Winner: Genymotion. SaaS and the gmsaas CLI give you remote adb instances without managing hosts. Google doesn’t offer an equivalent hosted emulator, so you build it yourself on the other side.

Testing real-world network and carrier behaviour

Winner: neither. Use real hardware. Everything else in this article is a trade-off between two virtual devices, and this is the case where the category itself runs out.

who should pick Android Emulator

• developers building and debugging apps day to day, because it ships with the toolchain
• open source projects and individuals who can’t or won’t pay for a licence
• teams that need the newest Android releases and unusual form factors the day Google ships them
• Apple Silicon Mac users who want native arm64 guests under a supported setup
• CI users happy to manage their own runners and virtualization
• anyone who wants one fewer vendor and one fewer licence to track

who should pick Genymotion

• QA teams that want point-and-click sensor and network controls
• companies that want a vendor contract, support and a clear licence
• teams that need hosted virtual devices through SaaS, or want images inside their own cloud account
• people on CI hosts without nested virtualization who would rather pay than debug it
• anyone who values a curated device catalogue over the official image list

If you pick Genymotion, read the licence terms for your tier and confirm that the features you need (the CLI in particular) are included. That is the most common surprise.

verdict overall

If you made me choose one for a new team with no constraints, I’d start with the Android Emulator. It is free, it is the reference implementation, it is where the documentation and community live, and the CLI scripts into CI well. The cost is that you learn the flags and own the infrastructure.

Genymotion earns its fee in specific situations: a QA team that wants less scripting, a need for hosted virtual devices, or a CI environment where virtualization is a problem. In those cases it is a sensible purchase and not a gimmick. Outside them, I’d want a concrete reason before paying.

The winner is “it depends”, and the dependency is the use case. Whichever you pick, keep a few real phones in the loop. Virtual devices catch logic bugs and layout problems. They don’t catch carrier, vendor and hardware problems, and those are the ones that tend to reach customers. For more on this kind of tooling, the blog index has the rest of my adb and automation notes.

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-10-24.