Run an Android app online without installing anything

People look for a way to run an Android app online for very different reasons. A Mac or iPhone user needs one Android-only app for an hour. A reviewer received an APK and does not want it anywhere near a personal phone. A developer wants to show a build on Android 12 and Android 17 without carrying two devices. A product manager wants to see a competitor's app on a phone model nobody in the office owns.

"Without installing" means nothing lands on your computer or your own phone. The app still installs somewhere: on a phone that runs elsewhere and streams its screen to your browser. This guide compares the ways to do that and walks through the quickest one.

Four ways compared

An emulator on your own computer is the classic developer answer and costs nothing but time. It is a poor fit for anyone who is not a developer, and it is not online at all. Browser previews built for app demos are fast, but they are made for developers showing their own builds. A spare phone works until you need a second Android version.

A cloud phone sits between these: a full Android phone that runs in a data center, streams its screen to your browser and takes input from your mouse and keyboard. For the difference from an emulator in more detail, see the Android emulator online page.

How to run an app on a cloud phone

1. Create a phone. Sign up, pick an Android version from 12 to 17 and a country. The phone is ready in about a minute, built from one of 150+ real phone models.
2. Open its screen in the browser. Clicks are taps, the scroll wheel scrolls, your keyboard types.
3. Install the app. Drag an APK file onto the phone in the dashboard, upload it through the API, or run adb install app.apk over the ADB relay. The apps docs cover each way.
4. Use the app. Sign in, try the flows, take screenshots.
5. Stop or reset the phone. A stopped phone costs nothing. A reset returns it to a fresh state, which removes the app and its data.

On Clousd the first 30 minutes are free and need no card, which is usually enough to try one app. After that, pay as you go costs $0.004 a minute while the phone runs, and never more than $0.80 a phone a day.

Which Android version to choose

Most apps run on any current version, but two cases need a deliberate choice. Apps that have not been updated in years can misbehave on the newest Android, and new apps can refuse to install on older ones. The APK itself tells you its range:

aapt2 dump badging app.apk | grep -E "sdkVersion|targetSdkVersion"

sdkVersion is the lowest API level the app accepts, and targetSdkVersion is the one it was built and tested for. The mapping to Android versions: API 31 and 32 are Android 12, 33 is Android 13, 34 is Android 14, 35 is Android 15, 36 is Android 16 and 37 is Android 17.

A practical default is the version closest to the app's target. If the question is how the app behaves for a typical user rather than on the latest release, a version from the middle of the range, such as 14 or 15, is a reasonable choice. When in doubt, create two phones and compare: the second one takes another minute.

APK, XAPK and split APKs

Not every download is a single APK. Apps published as bundles come as a base APK plus split files for screen density, language and processor. Download sites package them as .xapk or .apks, which are zip archives.

• A plain .apk installs directly.
• For a bundle, unzip it and install the parts together:

adb install-multiple base.apk split_config.arm64_v8a.apk split_config.en.apk split_config.xxhdpi.apk

• If the bundle has several processor splits, install the one that matches the phone. adb shell getprop ro.product.cpu.abi tells you which.

The error INSTALL_FAILED_NO_MATCHING_ABIS means the files you installed have no code for the phone's processor, and INSTALL_FAILED_MISSING_SPLIT means a part of the bundle is missing.

Before you trust an APK

Running an app on a phone that is not yours already keeps it away from your files, photos and accounts. A few checks still pay off:

• Source. Prefer the developer's own site or a store. Mirror sites repackage files.
• Hash. If the developer publishes a SHA-256, compare it: sha256sum app.apk on Linux or macOS, certutil -hashfile app.apk SHA256 on Windows.
• Signature. apksigner verify --print-certs app.apk from the Android build tools shows who signed it. A certificate that differs from the official version is a red flag.
• Permissions. aapt2 dump permissions app.apk lists what the app asks for. A flashlight that wants your contacts does not need them.
• Accounts. Do not sign in to your main accounts inside an app you do not trust. Use the phone to see what it does, then reset it.

For developers: show a build without shipping it

A cloud phone is a quick way to put a build in front of someone who does not have Android Studio. Install the debug build, open the phone, and walk the reviewer through it on a call. For a version check, create two phones, one on Android 12 and one on Android 17, install the same APK and compare.

Logs come over the same ADB connection:

adb logcat --pid=$(adb shell pidof -s com.example.app)

For a fuller workflow with test runs on several versions and reading crash logs, see how to test an Android app online.

What this does not cover

• iOS apps. These are Android phones only.
• SMS. The phone does not receive text messages, so an app that insists on an SMS code at sign-up will not get one there.
• Things in the physical world. A camera pointed at your desk or a contactless card tap are not part of a phone that runs in a data center.