DEV Community: Growth Marketing

I ranked 7 Android cloud services by one question: will the device still be the same device in three months?

Growth Marketing — Fri, 13 Nov 2026 06:44:10 +0000

Disclosure first: I work with DuoPlus, on the growth side. So yes, it's on this list, and yes, it's near the top. I'll tell you where it falls short too, and I checked every other product's claims against its own website this week instead of going from memory.

Why this list exists: most cloud phone and device cloud roundups rank by "how many devices" or "how cheap." That's not what breaks for the teams I talk to. They're small QA shops, two-person dev teams, agencies looking after a dozen client apps. The question that actually costs them time is boring: when I open this Android environment next month, is it still logged in, still configured, still mine? Or am I starting from zero again?

So that's the ranking criterion. Fit for small dev/QA teams and agencies that need stable, isolated Android environments that last. Not gaming, and not one-off test runs (though some tools below are great at those).

1. DuoPlus

https://www.duoplus.net/share/market

DuoPlus gives you real ARM Android cloud phones, on Android 10, 11, 12 and 15. Each one is an isolated, independent device environment with its own data and login state, and it stays a fixed, long-term environment, so the phone you set up for a client in March is the same phone in June.

The part agencies care about is handover. You can share a device with a teammate in one click and they pick it up already logged in. When someone goes on leave, nobody spends an afternoon re-entering passwords and waiting on 2FA codes from the client.

Other things I actually use: per-device proxy and region settings, local environments in 150+ countries/regions, bulk install/uninstall/launch of apps across a batch of devices, root, and an API. Billing is per-minute. There are browser, desktop and mobile clients. There are also cloud numbers, which I use for testing our own app's signup and OTP flows without passing someone's personal SIM around the office.

Fits: agencies holding client app accounts long-term, small QA teams that want persistent devices they can hand to each other, anyone doing regional checks.

Drawbacks, honestly: it's Android only, so if your release checklist includes iOS you need a second tool. And it's not a test-automation grid with built-in reporting. If what you want is "upload APK, run Espresso suite on 40 device models, get a video per failure," the next three entries do that better.

2. Genymotion SaaS

https://www.genymotion.com/

Genymotion is the one I'd point a pure dev team at. Their site lists Genymotion SaaS ("optimized for team work, CI/CD and agentic AI"), a PaaS version on AWS, Alibaba, GCP and Azure, and Genymotion Desktop for PC and Mac. Integrations they name: Detox, GitHub Actions, CircleCI, Bitrise, Jenkins.

These are Android virtual devices built to be spun up from a pipeline, and they also pitch browser-based support and demo use.

Fits: dev teams that want Android devices wired into CI, plus support teams that need to reproduce a customer's bug from a browser tab.

Less ideal when: you need one specific device to hold a client's logged-in state for months and get passed between people. That's not what a CI emulator is shaped for.

3. AWS Device Farm

https://aws.amazon.com/device-farm/

Real physical phones and tablets hosted by AWS. You can run automated tests (Appium, Espresso, Calabash, or their built-in suite with no scripting), do manual remote sessions, and get videos, logs and performance data back. You can set location, language and network conditions.

The interesting bit for this list: their private device lab option gives you iOS and Android devices for your exclusive use and, per their page, lets you persist settings between sessions. That gets much closer to "my device stays my device."

Fits: teams already on AWS who need real hardware coverage, including iOS, hooked into Jenkins or Android Studio.

Less ideal when: you're a five-person agency without anyone who wants to own AWS config. And the shared pool is built for test runs, not long-lived logged-in accounts.

4. BrowserStack App Live

https://www.browserstack.com/app-live

BrowserStack says 30,000+ real iOS and Android devices. You can upload dev APK/AAB/IPA builds or install production apps from the stores, debug with logs and crash reports, and test on up to four devices at once. Their Custom Device Lab adds exclusive device access with options like app persistence and SIM binding.

Fits: QA teams who need wide model coverage across iOS and Android, fast.

Less ideal when: the job is keeping a handful of long-term environments for ongoing client work. You'd be paying for breadth you don't use, and persistence lives in the custom lab tier, not the default.

5. GeeLark

https://www.geelark.com/

GeeLark offers ARM-based cloud phones for Android apps plus multi-account browser profiles for web, both in one workspace. Team features are solid on paper: team members can be added free, roles and permissions, operation logs, groups/tags/notes for organising profiles. They also mention MCP so you can connect an AI agent to manage the phones and profiles, and they list GPS/SIM simulation across 150+ countries.

Fits: social and marketing teams who want phones and browser profiles managed side by side, with scheduling and AI content tools on top.

Less ideal when: you're a dev/QA team. A big chunk of the product is about posting, content generation and engagement automation, which you'll pay attention to (and maybe pay for) without needing.

6. VMOSCloud

https://www.vmoscloud.com/

VMOSCloud runs Android cloud phones with a strong lean toward social media automation: an AI workflow feature that turns text prompts into actions, a Synchronizer that mirrors one device's actions across many, and a Team Hub with roles and permissions. Their homepage lists Google Play Integrity, SafetyNet and Widevine L1. "App Test" appears in their industry list, though most of the page is about growing social accounts.

Fits: operators running many social accounts who want synchronized control.

Less ideal when: you want a dev-first tool. I'd also read their data policy closely if you plan long-term use: their FAQ says data is automatically deleted once the subscription ends, which is fine, just plan exports around it.

7. Redfinger

https://www.cloudemulator.net/

One of the older names. Redfinger has Android, Windows, web and iOS access, a Redfinger for Business line, and servers in the US, Taiwan and Singapore. Their site mentions device simulation for testing alongside gaming and cross-border marketing.

Fits: individuals and small teams who want a simple cloud Android device on several platforms.

Less ideal when: you need team handover and region coverage beyond those three server locations.

Honourable mentions: LDCloud and UgPhone

Both are positioned mainly for gaming. LDCloud (https://www.ldcloud.net/) leads with 24/7 AFK play, multi-instance and sync operation. UgPhone (https://www.ugphone.com/) lists tiers on Android 10, 12 and 13 with servers in places like Hong Kong, Germany, Japan, the USA and Singapore. For client QA work, I wouldn't start here.

How I'd actually choose

If I'm honest, the decision usually comes down to one question. Is the device disposable (run tests, throw away) or durable (holds state, gets handed between people for months)?

Disposable: Genymotion, AWS Device Farm, BrowserStack. Pick by whether you need iOS and how much CI you already have.

Durable: that's where DuoPlus, GeeLark, VMOSCloud and Redfinger sit, and I'd rank them by how painless handover and regional setup are for a non-engineer on your team. That's why DuoPlus is first on my list.

Plenty of teams end up with one of each. What hurts is using a disposable tool for durable work and wondering why everyone keeps logging in again.

If you've ranked these differently for your own team, I'd like to hear why in the comments, especially if you run client work on BrowserStack's custom lab.

Unpopular opinion: most "device management" problems are really bulk-ops problems

Growth Marketing — Fri, 13 Nov 2026 00:16:27 +0000

I work with DuoPlus, so take this with whatever grain of salt you like. But I've been the person doing the tapping long before I was the person writing about it, and I've changed my mind about where the real time goes.

For a while I thought our pain was the phones themselves. Old handsets, dead batteries, the one Pixel that only charges if the cable sits at a certain angle. So we moved to cloud phones, real ARM Android devices we open in the browser, and yes, that fixed the drawer. It did not fix my Tuesdays.

My Tuesdays were the problem.

The boring part nobody budgets for

Here's what a normal week looked like for our small team. A client ships a new build. Someone has to put it on every device that client's people use. Then the old build has to come off the test devices so nobody files a bug against last week's version. Then each app gets launched once so the first-run screens are out of the way before a teammate sits down.

Multiply that by a handful of clients and maybe twenty devices, and you've eaten a morning. Not because any one step is hard. Because it's the same three taps, twenty times, and you lose count around device eleven.

I used to call this "device management." It isn't. It's bulk operations, and I think a lot of teams misdiagnose it the same way we did.

What actually changed for us

The thing that made the difference was boring too: doing the install, the uninstall and the launch across a selected group of cloud phones in one action instead of one device at a time. DuoPlus has bulk install, bulk uninstall and bulk launch, and once I named every device by client, the Tuesday job shrank to selecting that client's devices, picking the APK, and checking the results.

A few things I didn't expect:

Naming is the real work. If you can't tell at a glance which devices belong to which client or test, bulk actions just let you make the same mistake twenty times faster. I spent an afternoon renaming things before any of this paid off.
You still need to look. I open three or four devices at random after a bulk install, every time. It's quick. It has caught a bad build exactly once, which was enough.
Sharing matters more after the batch. When something looks off on one device, I share that exact cloud phone with a teammate in one click instead of describing it in chat. They see the same state I see.

Where the API comes in (and where it doesn't)

People ask if they should script everything. My honest answer: not on day one. There is an API, and our developer uses it to drive repeatable test runs from a script. That's great for QA that happens the same way every week. But for a small agency doing client handovers, the buttons were enough for months. Automate the thing you've done by hand ten times and are sure about. Not before.

The part about billing, briefly

We pay per minute, which suits batch work. A lot of my sessions are short: run the batch, spot-check, close. I won't quote rates here because they change; the official site has current pricing.

So, the opinion

If your team is drowning in phones, check whether it's really the phones. For us the hardware was maybe a third of it. The rest was repetition. Real isolated devices fixed the first part, bulk actions fixed the second, and getting organised fixed the bit in between that no tool will do for you.

If you want to poke at it yourself, this is the link I share with people: https://www.duoplus.net/share/market

It's Android only, and it's not going to make your Tuesdays exciting. Mine are just shorter now.

Before I file for Play closed testing, I run the APK on more than one Android version

Growth Marketing — Thu, 12 Nov 2026 07:36:25 +0000

I used to treat closed testing like the first real look at a build. That was a bad habit. You spend days rounding up testers, you wait on the clock, and then someone on Android 12 hits a crash you never saw because the only phone on your desk was already on 15.

These days I do a pre-flight pass first. Nothing fancy. I just want the APK to stand up on more than one OS version before I bother anyone else.

I work in growth marketing, close enough to the Android work that a build often lands in my chat before it lands in Play Console. Someone drops an APK and a short note about what changed. I used to install that file on whatever handset I could borrow. The borrowed phone was almost always the newest one in the office, so of course it looked fine. A local emulator missed a crash that only showed up on real ARM. I stopped treating either as the last stop before testers.

The pass I do now looks like this.

I open DuoPlus in the browser. There's a desktop client and a mobile client if I want a native window, but for a morning walkthrough I don't bother installing anything. Each cloud phone is a real ARM Android device, and each one is its own isolated environment. Nicer than a shared lab handset with someone else's test account still signed in.

Android 15 is there, which matters when a targetSdk bump is in the build. Older versions are there too. I usually start an Android 15 phone and at least one older one, often 12, sometimes 11 or 10 if a crash report already pointed at it. I don't spin up a full matrix every time. Two or three versions already catch the stupid stuff.

If the build is meant for a market I'm not sitting in, I pick a local environment from the 150+ country options before I install anything. I got burned once by a paywall that only appeared in a region we hadn't checked. I'm not going to pretend this covers every store quirk. It's still better than testing only on a Singapore handset and hoping.

Then I install the APK. When I've got more than one cloud phone running, I use the bulk install so I'm not doing the same upload three times. Same for launching the app after. Bulk uninstall is what I reach for on the next build, when I want the old package gone.

The pass itself is boring, which is the point. I walk the first-run screens, try a login, background the app and come back. If the changelog mentions a deep link, I hit that too. Purchase screens I take slowly. I keep a notes file open and write the OS version next to whatever I hit. Last week the Android 11 phone stalled on a permission dialog that Android 15 just skipped. Took maybe twenty minutes to notice. That's the kind of thing I want to find before a closed tester files it as a one-off.

If something only happens on one device, I don't try to describe the state in a long message. I use the one-click share and send that same cloud phone to whoever needs to see it. They can open it in a browser even if they haven't installed a client. We've wasted more time rebuilding a state than I want to admit.

A few of our test cases need root. DuoPlus supports that, so I don't keep a separately rooted personal phone around just for those. I only turn it on when the case actually asks for it. There's an API if you want to start devices from a script. I don't do that every morning, but on weeks where the same version matrix keeps coming back, I wish I'd set it up sooner.

Billing is per minute, which I care about because these sessions are often short. A pre-flight pass might be twenty minutes, not a whole afternoon. I'm not going to paste a rate here; look at the official site. I just like not leaving a physical lab powered all day for a walkthrough I could have finished before lunch.

After the pass, I still have to do Play closed testing the normal way. This doesn't replace testers, and it doesn't shorten Google's clock. It just means I stop handing people a build I haven't even opened on Android 12.

If you want to try the same setup I use, it's here:

https://www.duoplus.net/share/market

I still keep one physical phone in a drawer. I just don't let it stand in for every version we claim to support.

Running regional mobile tests without a pile of physical phones

Growth Marketing — Wed, 11 Nov 2026 13:54:41 +0000

When a product, ad, or storefront has to work in more than one country, testing it only on your own phone usually isn't enough. Local apps, payment flows, and carrier conditions are often different. Buying a handset for every market, or shipping one around the team, gets expensive and slow.

I've been using cloud phones for this: real ARM Android devices that run in the cloud and can be opened from a browser on a computer or a phone. No extra client to install. The team can share access to a device instead of passing hardware around.

The product I work with is DuoPlus. I'll be upfront about that. A DuoPlus cloud phone is a real ARM Android device, including Android 15, with local environment options in 150+ countries, so you can test how something behaves in a given region. You can install, uninstall, and launch apps in bulk, and teammates can join and share a device with one click. You also don't have to buy and maintain a drawer full of physical phones if you just need more environments for regional testing, or separate work accounts on the same team.

This is most useful when you need to:

Check a mobile flow in another region before you ship or spend on ads
Let more than one teammate use the same pool of devices
Keep work environments separate for different markets or accounts, without mixing them on one personal phone

If you want to try it, here's the link I use:
https://www.duoplus.net/share/market

I'm happy to answer practical questions about the setup. I work with DuoPlus, so I'll say so plainly: this is a product I help with, not an unrelated review.