Genymotion Cloud alternative with real phone models

If you are looking for a Genymotion Cloud alternative, you most likely run Android virtual devices in the cloud today, for CI or for manual testing, and want something that behaves more like the phones your users own. Genymotion is a mature, well-documented product, and for some jobs it remains the best choice. This article helps you decide which jobs those are.

It covers what Genymotion's cloud products are, where a virtual device stops being enough, what a cloud phone built from a real model changes, and how to move in five steps. It does not quote Genymotion prices, which change; its pricing page has the current figures.

What Genymotion Cloud is and who it fits

Genymotion sells Android virtual devices in several forms. The cloud ones are:

• Genymotion SaaS: virtual devices hosted by Genymotion, opened in a web browser and controlled from the command line with its gmsaas tool, over ADB or through an HTTP API.
• Genymotion Device Image (PaaS): the same virtual devices as images on the AWS, Google Cloud, Azure and Alibaba Cloud marketplaces, running inside your own cloud account.

The desktop edition is a separate product that runs on your own computer.

Devices are created from "recipes", templates of an Android version and a screen. The official list is mostly a generic Genymotion Phone image for each Android version from 8.0 to 16, with Android 16 marked beta, plus a few recipes named after phone models such as the Samsung Galaxy S24, Google Pixel 9 and Xiaomi 15. All current official recipes use arm64 images, so arm apps run without translation.

Genymotion's strength is control over conditions. Its widgets set GPS position, battery state, network quality and disk speed, simulate biometrics and phone calls, and feed a webcam or a media file into the camera. Root can be switched on. For CI it documents integrations with GitHub Actions, CircleCI, Bitrise, Jenkins and Detox, and the same script can run on many devices in parallel.

The pricing model, in words: SaaS is sold pay as you go, per minute for each running virtual device, or as a flat monthly fee per device, with a custom premium tier on dedicated servers. A default plan caps how many devices run at once, and raising the cap goes through sales. Device Image is billed by the hour per instance on each marketplace, plus that cloud's own fees.

If your team runs instrumented tests at scale, needs Android 8 to 11, simulates sensors and network conditions, or has to keep everything inside its own cloud account, Genymotion fits that work well.

Where it stops being the right tool

Teams usually start looking at a Genymotion SaaS alternative for one of these reasons.

A generic device is not your users' phone

A virtual device built from a generic image presents itself as a generic device. That is fine for testing your own logic. It hides problems that depend on the device class: layouts at a specific panel's size and density, feature checks through hasSystemFeature, and code paths that branch on the manufacturer or model. When a bug report says "crashes on a Galaxy A35 with Android 15", you want that model on that version. The few model-named recipes help, but ask what a model name sets on a virtual device before you rely on it.

Google Play is an extra step

Google Play Store and Play services are not preinstalled on Genymotion virtual devices. You install them with a built-in Open GApps widget, then restart the device. Reviewers on PeerSpot call the lack of Play services out of the box a real drawback. If your app depends on Play services, budget that step for every fresh device, or check how any alternative you consider handles it.

Android 17

Genymotion's official recipe list stops at Android 16, marked beta at the time of writing. If your test plan already includes Android 17, you need another source for it.

Agents need more than ADB

gmsaas, the HTTP API and ADB are good tools for scripts. AI agents work best with a way to see the screen and act on it that their framework already understands, such as an MCP server, plus a person able to watch the same screen. If you are building agents, check what you would have to write to connect them.

Location is more than a GPS fix

The GPS widget moves the device on a map, which covers apps that read location. A localized test usually needs more: the phone should connect from the market you test, with that country's time zone and language, so store pages, prices and content match what local users see.

Always-on phones and cost

Per-minute billing suits CI jobs that start and stop. For a phone that stays on all day, such as an agent's device or a phone signed in to a test account, the choice is between the meter and a flat monthly fee per device. Reviewers on PeerSpot also mention the price point of cloud instances as something they would like improved.

What Clousd does differently

Clousd is a cloud phone service: Android running in a data center, set up as a specific phone model and kept for you like a device. It is built for app testing, developers and AI agents.

• Phones built from real models. 150+ models from Samsung, Pixel, Motorola, OnePlus, Xiaomi and others, so you can pick the phones your users own.
• Android 12 to 17, chosen per phone.
• Browser and code. A live screen in the browser, a REST API, an MCP server, a Python SDK and ADB over a relay.
• Clean state on demand. A new phone is ready in about a minute, and any phone can be reset to a fresh state between runs. Until then it keeps its apps and data.
• Tasks. Give a phone a goal in plain words, such as "install the build, open settings and report the version shown", and Clousd's agent does it.
• Country, time zone and language. A phone connects from the country you choose, such as the US, the UK, Germany, Brazil or Indonesia, out of 45 in total, with the matching time zone and language.
• Per-minute pricing with a daily cap. $0.004 a minute while a phone runs, never more than $0.80 a phone a day, or plans from $20 a month. A phone left on all month costs at most about $24. The first 30 minutes are free, no card. See pricing.
• Servers in the EU, in Frankfurt and Helsinki.

To be fair about the other side: Clousd does not offer Android versions below 12, sensor and phone call simulation widgets, or images to run inside your own cloud account. If you depend on those, keep Genymotion for that work.

Genymotion Cloud and Clousd side by side

How to move: a 5-step switch

1. Map recipes to models. For each recipe in your CI config, write down the Android version and pick two or three models your users own on that version. Your analytics will tell you which.
2. Create the phones. The first one takes about a minute; your first device walks through it. Name them after model and version, such as qa-a35-15.
3. Connect over ADB. Connect through the relay as described in the ADB docs. Scripts that pick a device by its ADB serial need only the new serial, and instrumented tests run as before:

adb devices
./gradlew connectedDebugAndroidTest

1. Replace the device lifecycle calls. Where your pipeline starts and stops instances with gmsaas, call the REST API to create, start, stop or reset phones. Point your AI assistant at the MCP server.
2. Run both for one release. Keep Genymotion for older versions and simulated conditions, run the real-model checks on Clousd, and compare results and cost after a full cycle. The app testing workflow shows how phones, builds and CI fit together.

For the difference between an emulator on a server and a phone built from a real model in more depth, see cloud Android emulator vs cloud phone.