Skip to content
sandboxer
Start free trial
Guides · Use cases

How to Run the Android Emulator in a Cloud VM and Watch It

Updated October 27, 2026 .md

Short answer: Create a large Sandboxer sandbox, which has /dev/kvm, install the Android command-line tools and an x86_64 system image, and start the emulator with -accel on. It cold-boots Android 15 in about 30 seconds. Run it headless and drive it with adb, or put its window on the sandbox's desktop and watch it in your browser.

What we measured#

We ran every command below on two large sandboxes on 2026-10-27.

Step Result
Size large: 8 vCPU, 16 GB RAM, 125 GB disk, $0.072/hour, billed per second
/dev/kvm crw-rw---- root kvm; user is in the kvm group
Java, SDK tools, emulator, Android 15 image About 1 minute to download and install; 4.6 GB on disk
Cold boot to sys.boot_completed=1 30–36 seconds (four runs)
Quick boot from the emulator's own snapshot 6–19 seconds
adb install of a 263 KB APK Success in under half a second

The emulator's x86_64 guest runs on the sandbox's KVM, so it is a VM inside a VM. Use large or xlarge: the emulator's RAM comes out of the sandbox's. During the trial only small and default are available, so this guide needs a paid plan. We didn't test smaller sizes.

1. Create the sandbox and check KVM#

sbx new --type large --name android
sbx exec sb_2l9kjerkuc "ls -l /dev/kvm; id -nG"
crw-rw---- 1 root kvm 10, 232 Oct 27 02:39 /dev/kvm
user sudo docker kvm

The examples use the id sb_2l9kjerkuc; use the one sbx new printed.

2. Install Java and the Android command-line tools#

The SDK tools need a Java runtime. Download the command-line tools from Google and put the SDK directories on your PATH in ~/.profile, which sbx exec reads.

sbx exec sb_2l9kjerkuc --timeout 600 "sudo apt-get update -qq && sudo apt-get install -y -qq openjdk-17-jre-headless"
sbx exec sb_2l9kjerkuc --timeout 600 'set -e
mkdir -p ~/android/cmdline-tools && cd /tmp
curl -fsSLo tools.zip https://dl.google.com/android/repository/commandlinetools-linux-16111833_latest.zip
unzip -q tools.zip && mv cmdline-tools ~/android/cmdline-tools/latest
cat >> ~/.profile <<"EOF"
export ANDROID_HOME=$HOME/android
export PATH=$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools:$ANDROID_HOME/emulator:$PATH
EOF'

The zip name changes with each release. Get the current one from the Android Studio download page.

3. Install the emulator and a system image, then create a device#

sbx exec sb_2l9kjerkuc --timeout 600 'sdkmanager "platform-tools" "emulator" "system-images;android-35;google_apis;x86_64"
echo no | avdmanager create avd -n pixel -k "system-images;android-35;google_apis;x86_64" -d pixel_7
emulator -accel-check'
…
Unzipping emulator......
Unzipping system-images/android-35/google_apis/x86_64......
…
KVM (version 12) is installed and usable.

emulator -accel-check is the test that matters. If it doesn't say KVM is usable, the emulator falls back to software emulation, which is too slow to use.

The current command-line tools print a notice that sdkmanager is deprecated in favor of the new android sdk command. sdkmanager still installed everything; see Google's Android CLI docs if you want the new syntax.

4. Boot it headless and wait for Android#

Start the adb server first, then the emulator as a background process:

sbx exec sb_2l9kjerkuc "adb start-server"
sbx exec sb_2l9kjerkuc --detach "emulator -avd pixel -no-window -no-audio -no-boot-anim -accel on -gpu swiftshader_indirect > ~/emulator.log 2>&1"

-gpu swiftshader_indirect renders in software, since the sandbox has no GPU. Then wait until Android reports that it finished booting:

sbx exec sb_2l9kjerkuc --timeout 300 'adb wait-for-device
until [ "$(adb shell getprop sys.boot_completed)" = 1 ]; do sleep 2; done
grep "Boot completed" ~/emulator.log'
INFO         | Boot completed in 30068 ms

5. Drive it with adb#

sbx exec sb_2l9kjerkuc 'adb devices; adb shell getprop ro.build.version.release; adb shell getprop ro.product.model'
List of devices attached
emulator-5554	device

15
sdk_gphone64_x86_64

Install an APK, launch it and take a screenshot. This uses a small open-source text editor from F-Droid:

sbx exec sb_2l9kjerkuc --timeout 120 'curl -fsSLo /tmp/editor.apk https://f-droid.org/repo/org.billthefarmer.editor_198.apk
adb install /tmp/editor.apk
adb shell monkey -p org.billthefarmer.editor -c android.intent.category.LAUNCHER 1 >/dev/null 2>&1
sleep 3; adb shell dumpsys activity activities | grep -m1 topResumedActivity
adb exec-out screencap -p > ~/screen.png && file ~/screen.png'
sbx scp sb_2l9kjerkuc:/home/user/screen.png .
Performing Streamed Install
Success
    topResumedActivity=ActivityRecord{4cd5e13 u0 org.billthefarmer.editor/.Editor t8}
/home/user/screen.png: PNG image data, 1080 x 2400, 8-bit/color RGBA, non-interlaced

Your own test APKs install the same way, and an agent can run all of this through sbx exec or the exec API.

6. Watch it on the sandbox's desktop#

Every sandbox has a streamed Linux desktop. Open it once so it starts, quit the headless emulator, and start it again with a window on the desktop's X display, :1:

sbx desktop sb_2l9kjerkuc
sbx exec sb_2l9kjerkuc "adb emu kill"
sbx exec sb_2l9kjerkuc --detach "DISPLAY=:1 emulator -avd pixel -no-audio -accel on -gpu swiftshader_indirect > ~/emulator.log 2>&1"

The emulator window opens on the desktop next to Chrome, and you can click and type in it from your browser tab. The emulator also opens a dialog saying it is running under nested virtualization and that this is not recommended. Close it; in our tests the emulator booted and ran with the dialog open. Check the window from the command line with DISPLAY=:1 xdotool search --name "Android Emulator" getwindowname, which printed Android Emulator - pixel:5554.

The desktop URL carries a secret token and works for ten minutes. See Desktop for how sharing and embedding work.

7. Stop and resume: quit the emulator first#

adb emu kill quits the emulator and saves a quick-boot snapshot of the device. Do that before you stop the sandbox, then start the emulator again after you resume:

sbx exec sb_2l9kjerkuc --timeout 120 'adb emu kill; while pgrep qemu-system-x86 >/dev/null; do sleep 1; done; echo emulator exited'
sbx stop sb_2l9kjerkuc --wait
sbx resume sb_2l9kjerkuc
sbx exec sb_2l9kjerkuc "adb start-server"
sbx exec sb_2l9kjerkuc --detach "emulator -avd pixel -no-window -no-audio -no-boot-anim -accel on -gpu swiftshader_indirect > ~/emulator.log 2>&1"
INFO         | Successfully loaded snapshot 'default_boot' using 4534 ms

Android was booted again, with the installed app, 6 seconds after the emulator started (19 seconds the first time we tried it). In our test, an emulator left running through a stop did not respond after resume, so don't skip adb emu kill. The SDK, the device and its data are on the sandbox's disk, so they are kept either way.

To skip the install on every new sandbox, save a prepared one as a named snapshot and start new sandboxes from it. See snapshots.

FAQ#

Can I run Android Studio in the cloud?#

You can install it on a sandbox and use it on the streamed desktop, because the sandbox is a full Ubuntu VM with /dev/kvm. We tested the emulator and command-line tools, not the Android Studio IDE.

Does the Android emulator need KVM?#

For usable speed, yes. Without hardware acceleration, an x86_64 image runs in software emulation. Run emulator -accel-check: on a Sandboxer sandbox it prints KVM (version 12) is installed and usable.

Can I use ARM system images?#

We used an x86_64 image, which runs with KVM acceleration on the sandbox's x86 CPU. We didn't test ARM images.

How long does the emulator take to boot?#

In our tests on large, a cold boot to sys.boot_completed=1 took 30 to 36 seconds. A quick boot from the emulator's saved snapshot took 6 to 19 seconds.

Can I run more than one emulator?#

We tested one per sandbox. For parallel tests, the simplest path is one sandbox per emulator, all started from the same named snapshot.

More guides

Top AI sandbox platforms for code execution in 2026, ranked

For running AI-written code we rank Sandboxer, Freestyle and E2B first: each gives code its own VM with an API or SDK and can pause with memory. Pick Daytona for Windows or GPUs, Modal or Northflank for GPUs at scale, E2B or Northflank to run in your own cloud, and Vercel Sandbox if your app lives on Vercel.

Read the guide
Best sandboxes for running coding agents (Claude Code, Codex, Gemini CLI) in 2026, ranked

For coding agents we rank Sandboxer first: a full Ubuntu VM with Claude Code and Codex preinstalled, Docker, and stop-and-resume that keeps the agent's session in memory. Freestyle and Amp Orbs also keep memory across pauses. Pick E2B for prebuilt agent templates on open source, Docker Sandboxes for free local runs, and Codespaces if you live in GitHub.

Read the guide
Best Daytona sandbox alternatives in 2026, ranked

The best Daytona alternatives depend on why you're switching. For a full Linux microVM on every sandbox with memory-saving stop and Docker, we rank Sandboxer first. E2B suits open source and self-hosting, Modal massive short-job fleets, Northflank bring-your-own-cloud with GPUs, and Vercel Sandbox apps on Vercel.

Read the guide
Best E2B alternatives in 2026, ranked

If you're leaving E2B for longer sessions or a fuller machine, we rank Sandboxer first, then Freestyle: both give each sandbox a full Linux VM that keeps memory across pauses, with Docker and no short session cap. Pick Daytona for Windows or GPUs, Northflank for bring-your-own-cloud, and stay on E2B if you need open source.

Read the guide