DEV Community

Cover image for Run Android Emulator (AVD) Without Installing Android Studio — Updated Guide (Android CLI Edition)
Shivam Sharma
Shivam Sharma

Posted on • Edited on

Run Android Emulator (AVD) Without Installing Android Studio — Updated Guide (Android CLI Edition)

#android #tutorial #productivity #learning

Android Studio bundles the AVD (Android Virtual Device) Emulator, but if all you need is an emulator — for React Native, Flutter, CI pipelines, or plain APK testing — installing the full IDE is overkill. Google officially supports a command-line-only workflow, and with the release of Android 17 (June 2026) they've shipped a new unified Android CLI (android binary) that makes this even cleaner.

This guide works on macOS (Intel & Apple Silicon) and Linux, and reflects Google's current recommendations:

  • The new android CLI is now the primary tool — sdkmanager is officially deprecated (android sdk replaces it). Legacy commands still work, but new setups should use the new CLI.
  • New package syntax uses / separators (platforms/android-36) instead of the old ; — no more quoting gymnastics in your shell.
  • ANDROID_HOME is the recommended SDK variable; ANDROID_SDK_ROOT is deprecated (this reversed from a few years ago — many old guides get this backwards).
  • Command line tools must live under cmdline-tools/latest/ — officially documented layout.
  • JDK 17+ is the baseline. You don't need Oracle JDK — any OpenJDK build works.
  • Pick your system image ABI by CPU: arm64-v8a for Apple Silicon, x86_64 for Intel Macs and most Linux machines. A mismatched ABI runs painfully slow or not at all.

1. Install Java (JDK 17 or newer)

The SDK tooling is Java-based. Install any OpenJDK 17+ build:

macOS (Homebrew, recommended):

brew install --cask temurin@21
Enter fullscreen mode Exit fullscreen mode

Ubuntu/Debian:

sudo apt-get install openjdk-21-jdk
Enter fullscreen mode Exit fullscreen mode

Verify:

java -version
Enter fullscreen mode Exit fullscreen mode

Prefer Homebrew/apt over the Oracle installer — easier upgrades, no license prompts, and JAVA_HOME tooling (/usr/libexec/java_home on macOS) picks it up automatically.

2. Download the Command Line Tools

  1. Go to the Android Studio download page → scroll to "Command line tools only".
  2. Download the zip for your OS (commandlinetools-mac-*_latest.zip or commandlinetools-linux-*_latest.zip).
  3. Create your SDK directory and extract there: 
# macOS convention (same location Android Studio would use):
mkdir -p ~/Library/Android/sdk
# Linux convention:
# mkdir -p ~/Android/sdk

unzip commandlinetools-*_latest.zip -d ~/Library/Android/sdk
Enter fullscreen mode Exit fullscreen mode
  1. Restructure into latest/ — this exact layout is required by Google's docs, otherwise you'll hit the infamous "Could not determine SDK root" error: 
cd ~/Library/Android/sdk/cmdline-tools
mkdir latest
mv bin lib NOTICE.txt source.properties latest/
Enter fullscreen mode Exit fullscreen mode

Final path check — both of these must exist:

~/Library/Android/sdk/cmdline-tools/latest/bin/android      # new CLI
~/Library/Android/sdk/cmdline-tools/latest/bin/sdkmanager   # legacy (deprecated)
Enter fullscreen mode Exit fullscreen mode

3. Set Environment Variables

Add to ~/.zshrc (or ~/.bashrc):

######## Android ########
export ANDROID_HOME="$HOME/Library/Android/sdk"   # Linux: $HOME/Android/sdk
export PATH="$ANDROID_HOME/cmdline-tools/latest/bin:$PATH"
export PATH="$ANDROID_HOME/platform-tools:$PATH"
export PATH="$ANDROID_HOME/emulator:$PATH"
Enter fullscreen mode Exit fullscreen mode

Do NOT set ANDROID_SDK_ROOT anymore. It's deprecated, and if both variables are set and ever disagree, Gradle/Android tooling will warn or fail. ANDROID_HOME alone is correct today.

Reload and verify:

source ~/.zshrc
android --version        # new CLI
android info             # shows which SDK path is in use
Enter fullscreen mode Exit fullscreen mode

Keep the CLI itself current with:

android update
Enter fullscreen mode Exit fullscreen mode

4. Install Emulator, Platform Tools & a System Image

platform-tools gives you adb; emulator is the emulator engine itself. Note the new / package syntax — no quotes needed:

android sdk install platform-tools emulator
Enter fullscreen mode Exit fullscreen mode

Now install a system image for Android 16 (API 36 — the latest stable-channel SDK level). Pick the ABI matching your CPU:

# Apple Silicon (M-series):
android sdk install system-images/android-36/google_apis_playstore/arm64-v8a platforms/android-36

# Intel Mac / Linux x86_64:
android sdk install system-images/android-36/google_apis_playstore/x86_64 platforms/android-36
Enter fullscreen mode Exit fullscreen mode

Which image variant?

Variant Use when
google_apis_playstore You need Play Store apps. adb root is disabled on these images.
google_apis You need Google APIs + root access for debugging. Best for most dev work.
default (AOSP) Lightest, no Google services.

Explore what's available (supports regex patterns):

android sdk list system-images         # filter by pattern
android sdk list --all                 # everything
android sdk update                     # update all installed packages
android sdk remove <package-name>      # uninstall a package
Enter fullscreen mode Exit fullscreen mode

android-36 = Android 16, the latest API level with stable-channel SDK packages as of this writing. Android 17 (API 37) has shipped as an OS, but its SDK platform/system images may still be in pre-release channels — verify with android sdk list before defaulting to it (see next section).

Testing newer releases (API 37 / 37.1)

Android now ships a major SDK release in Q2 and a minor one in Q4 (API 37 = Android 17; API 37.1 expected ~December 2026 with Android 17 QPR2). Until a level's packages reach the stable channel, they only exist under --beta/--canary — the new CLI makes opting in trivial:

# Check which channel a given API level is actually in:
android sdk list --beta --canary system-images

# Install a pre-release image (drop --beta once it reaches stable):
android sdk install --beta system-images/android-37/google_apis_playstore/arm64-v8a platforms/android-37
# fall back to --canary if it's not in beta yet
Enter fullscreen mode Exit fullscreen mode

Then create a separate AVD against it — keep your stable API 36 device untouched so you always have a known-good baseline:

avdmanager create avd \
  --name "Pixel9_API37_preview" \
  --package "system-images;android-37;google_apis_playstore;arm64-v8a" \
  --device "pixel_9"
Enter fullscreen mode Exit fullscreen mode

Once API 37 packages reach stable, just swap android-36 → android-37 everywhere in this guide.

Legacy equivalents (sdkmanager — deprecated but still functional)

sdkmanager "platform-tools" "emulator"
sdkmanager "system-images;android-36;google_apis_playstore;arm64-v8a" "platforms;android-36"
sdkmanager --licenses
Enter fullscreen mode Exit fullscreen mode

5. Create the AVD

Option A — New CLI (quick, profile-based):

android emulator create --list-profiles          # see available device profiles
android emulator create --profile=medium_phone   # creates the device
android emulator list                            # verify
Enter fullscreen mode Exit fullscreen mode

Option B — avdmanager (fine-grained control over device + system image pairing):

Still fully supported, and useful when you need a specific Pixel profile matched to a specific system image:

avdmanager list device

avdmanager create avd \
  --name "Pixel9_API36" \
  --package "system-images;android-36;google_apis_playstore;arm64-v8a" \
  --device "pixel_9"
Enter fullscreen mode Exit fullscreen mode

When asked "Do you wish to create a custom hardware profile?" — say no. Tweak later in ~/.android/avd/<name>.avd/config.ini:

hw.ramSize=4096
hw.keyboard=yes
hw.gpu.enabled=yes
hw.gpu.mode=auto
disk.dataPartition.size=8G
Enter fullscreen mode Exit fullscreen mode

6. Run the Emulator

New CLI:

android emulator start medium_phone       # or your AVD name
android emulator stop emulator-5554       # stop by serial number
Enter fullscreen mode Exit fullscreen mode

Known issue: android emulator commands are currently disabled on Windows — Windows users should use the legacy emulator command below.

Legacy launcher (still needed for advanced flags):

emulator -avd Pixel9_API36 -no-snapshot-load
Enter fullscreen mode Exit fullscreen mode

Handy flags for the legacy launcher:

Flag What it does
-no-snapshot-load Cold boot (fresh state) instead of resuming a snapshot
-no-snapshot Don't load or save snapshots at all
-gpu host Force host GPU acceleration (default auto is usually fine)
-netdelay none -netspeed full No simulated network throttling
-wipe-data Factory reset the AVD on boot
-no-window Headless mode — perfect for CI

Verify adb sees the running device:

adb devices
Enter fullscreen mode Exit fullscreen mode

Troubleshooting

Error: Could not load devices from .../devices.xml

You may hit this when creating an AVD:

Error: Could not load devices from <sdk>/system-images/android-36/google_apis_playstore/arm64-v8a/devices.xml
Enter fullscreen mode Exit fullscreen mode

Cause: avdmanager scans every installed system-image directory for an optional devices.xml (extra device definitions), but some cmdline-tools builds treat the missing file as fatal instead of skipping it. Google ships this file in some image zips and not others (the android-36 playstore arm64 r07 image, for example, doesn't include it) — so a perfectly good download still fails.

Fix: drop an empty-but-valid stub into the image directory — avdmanager just needs parseable XML, and device profiles like pixel_9 come from its built-in list anyway:

cat > $ANDROID_HOME/system-images/android-36/google_apis_playstore/arm64-v8a/devices.xml << 'EOF'
<?xml version="1.0" encoding="UTF-8"?>
<d:devices xmlns:d="http://schemas.android.com/sdk/devices/7"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
</d:devices>
EOF
Enter fullscreen mode Exit fullscreen mode

(Adjust the path if your image variant/ABI differs. If you get a schema/namespace error after this, change devices/7 to devices/8 in the stub.)

Then clean up any half-created AVD from the failed attempts and recreate — don't just re-run with --force, as that can carry the broken state forward:

avdmanager delete avd --name "Pixel9_API36" 2>/dev/null
rm -rf ~/.android/avd/Pixel9_API36.avd ~/.android/avd/Pixel9_API36.ini

avdmanager create avd \
  --name "Pixel9_API36" \
  --package "system-images;android-36;google_apis_playstore;arm64-v8a" \
  --device "pixel_9"
Enter fullscreen mode Exit fullscreen mode

Still stuck? Two escape hatches: use the new CLI's own creation path, which doesn't trip on this (android emulator create --profile=medium_phone), or install the google_apis (non-playstore) image variant, which is a different zip and often ships the file.

Error: Could not determine SDK root

Your cmdline-tools aren't in the latest/ sub-directory. Revisit step 2.4 — the binaries must live at cmdline-tools/latest/bin/, not cmdline-tools/bin/.

AVD created but emulator -list-avds shows nothing

Some environments split AVD storage between ~/.android/avd and ~/.config/.android/avd. Check both, and if needed pin the location explicitly by exporting ANDROID_AVD_HOME="$HOME/.android/avd" in your shell profile.

Hardware Acceleration Note

  • Apple Silicon Macs: acceleration works out of the box via the Hypervisor framework — use arm64-v8a images.
  • Intel Macs: use x86_64 images; Hypervisor.framework is used automatically (HAXM is dead/deprecated).
  • Linux: ensure KVM is enabled: sudo apt install qemu-kvm and add yourself to the kvm group (sudo adduser $USER kvm), then re-login.

Without acceleration the emulator is unusably slow, so don't skip this if things feel sluggish.

Bonus: What Else the New CLI Does

The android CLI goes beyond SDK/AVD management — worth knowing even for emulator-only setups:

android run --apks=app-debug.apk          # deploy an APK to a device/emulator
android screen capture --output=ui.png    # screenshot a connected device
android docs search 'emulator performance' # search official Android docs from terminal
android create --output=./my-app          # scaffold a new project from a template
Enter fullscreen mode Exit fullscreen mode

Set persistent defaults in ~/.androidrc (one flag per line), e.g. --sdk=<path> to pin an SDK.

Steps Summary (TL;DR)

  1. Install JDK 17+ — brew install --cask temurin@21 / apt install openjdk-21-jdk
  2. Download Command line tools only, extract to ~/Library/Android/sdk (Linux: ~/Android/sdk)
  3. Restructure: contents of cmdline-tools/ → cmdline-tools/latest/
  4. In ~/.zshrc, set only ANDROID_HOME (not ANDROID_SDK_ROOT) and add cmdline-tools/latest/bin, platform-tools, emulator to PATH
  5. source ~/.zshrc → verify with android --version → android update
  6. android sdk install platform-tools emulator
  7. android sdk install system-images/android-36/google_apis_playstore/arm64-v8a platforms/android-36 (use x86_64 on Intel/Linux)
  8. Create AVD: android emulator create --profile=medium_phone — or avdmanager create avd --name "Pixel9_API36" --package "system-images;android-36;google_apis_playstore;arm64-v8a" --device "pixel_9" for full control
  9. Run: android emulator start medium_phone — or emulator -avd Pixel9_API36 -no-snapshot-load

That's it — a full Android emulator setup in under ~2 GB of downloads instead of the multi-gigabyte Android Studio install, now with Google's modern unified CLI.

Top comments (2)

Collapse
 
alphonso06 profile image
Al Javier •

When finally trying to launch the emulator:

emulator -avd 'StudyFone' -no-snapshot-load
Enter fullscreen mode Exit fullscreen mode

I receive the error:

emulator: WARN: Cannot find valid sdk root from environment variable ANDROID_HOME nor ANDROID_SDK_ROOT,Try to infer from emulator's path
INFO         | guessed sdk root is /home/alphonso/Library/Android/sdk
Enter fullscreen mode Exit fullscreen mode

Little confused because the command line tools are functioning properly.

Collapse
 
ja_arina profile image
arina •

شارژ کپسول آتش‌نشانی فرآیندی است که طی آن کپسول خاموش‌کننده پس از استفاده یا پس از گذشت مدت زمان مشخصی مجدداً پر و آماده‌ی استفاده می‌شود. این کار برای اطمینان از عملکرد صحیح و ایمن کپسول در مواقع اضطراری ضروری است.

مراحل شارژ کپسول آتش‌نشانی:
بررسی اولیه: بررسی ظاهری کپسول برای تشخیص آسیب‌های فیزیکی مانند زنگ‌زدگی، ترک، یا نشتی.
تخلیه ماده خاموش‌کننده: خارج کردن محتوای کپسول برای بررسی و تعویض در صورت نیاز.
بازرسی داخلی: بررسی سیلندر از داخل جهت اطمینان از عدم وجود خوردگی یا آسیب داخلی.
شارژ مجدد با ماده مناسب: پر کردن کپسول با ماده خاموش‌کننده مطابق با استانداردهای مربوطه (پودر خشک، دی‌اکسید کربن، فوم و غیره).
بررسی فشار و وزن: اطمینان از میزان صحیح فشار گاز و وزن ماده خاموش‌کننده.
تعویض قطعات در صورت لزوم: بررسی و تعویض قطعاتی مانند نازل، شلنگ، شیر و سوپاپ در صورت فرسودگی.
پلمپ و برچسب‌گذاری: درج تاریخ شارژ، نام شرکت تأمین‌کننده خدمات و مهر تأییدیه ایمنی.
تست نهایی: بررسی عملکرد کپسول با آزمایش‌های استاندارد قبل از تحویل.
زمان‌بندی شارژ کپسول آتش‌نشانی
شارژ کپسول آتش نشانی سالانه: برای اطمینان از عملکرد صحیح، بررسی و در صورت نیاز شارژ مجدد انجام شود.
پس از استفاده: هر بار که کپسول استفاده شد، حتی به مقدار کم، باید مجدداً شارژ گردد.
طبق توصیه تولیدکننده: برخی کپسول‌ها دوره‌های شارژ خاصی دارند که باید رعایت شوند.

Some comments may only be visible to logged-in visitors. Sign in to view all comments.