AVD Android: what is it, Android Virtual Device and how to configure the emulator

What is AVD

AVD (Android Virtual Device) is a software configuration that describes a virtual Android device. Unlike a physical phone, an AVD does not require hardware — it runs on a computer through the Android emulator based on QEMU. A developer creates as many AVDs as needed for testing: for different Android versions, screen sizes, memory capacities, and pixel densities.

Each AVD is tied to a specific SDK Platform. This means that to create an AVD with Android 14 (API Level 34), you must first install the System Image of that version through SDK Manager. The System Image is an operating system image that includes all system applications, Google services (if the Google APIs image is selected), and runtime components. Google recommends using Google APIs images with Google Play services for maximum compatibility with real devices.

AVD is indispensable in development for several reasons. First, it allows testing the application on different Android versions without purchasing dozens of devices. Second, AVD supports Snapshots — saving the system state, which speeds up startup. Third, the emulator is integrated with Android Studio: APK installation, debugging, and logging work just like on a physical device.

Types of virtual devices

AVD supports various device types: phones, tablets, Wear OS watches, Android TV, and Android Automotive. For each type, AVD Manager provides ready-made profiles from Google: Pixel 8, Pixel 9 Pro, Nexus 7, Samsung Galaxy Tab, and others. The device profile defines the screen size, resolution, pixel density (dpi), and navigation (gestures or buttons).

What does AVD consist of

Each AVD is a set of configuration files and images. The main configuration file is config.ini, which stores the virtual device parameters: name, type, API Level, screen size, RAM and VM heap size. The file is located in the $HOME/.android/avd/AVDName.avd/ directory and can be modified manually, although it is usually edited through AVD Manager.

In addition to config.ini, the AVD directory stores: userdata.img (user data image — applications, settings, files), system.img (link to the System Image of the installed SDK Platform), cache.img (cache), and sdcard.img (SD card image). When performing Wipe Data, userdata.img is deleted and a new empty image is created. Snapshots are saved in a separate snapshots/ folder inside the AVD directory.

The System Image is downloaded separately from the AVD — one image can be used by multiple virtual devices. System images are stored in the Android SDK directory: $ANDROID_SDK/system-images/android-{API}/{type}/{arch}/. Image types: google_apis (with Google services), google_apis_playstore (with Google Play Store), and default (pure AOSP without Google services).

Types of System Images

Creating an AVD through AVD Manager

AVD Manager is a graphical tool in Android Studio for creating and managing virtual devices. You can open it through the Tools → Device Manager menu or via the toolbar icon. AVD Manager shows the list of created devices, their status (running/stopped), Android version, and available actions (start, stop, wipe data, edit).

To create a new AVD, click the Create device button. Select a device profile from the ready-made list — Google provides profiles for all popular devices. After selecting a profile, specify the System Image: Android version and image type. For new projects, choose the latest stable version with the Google APIs image. Then configure the AVD name, screen orientation, RAM and VM heap size. After creation, the AVD is ready to launch.

Step-by-step AVD creation from command line

# 1. List available System Images
sdkmanager --list | grep system-images

# 2. Install System Image for API 35 with Google APIs
sdkmanager "system-images;android-35;google_apis;x86_64"

# 3. Create AVD named pixel8_api35
avdmanager create avd -n pixel8_api35 \
    -k "system-images;android-35;google_apis;x86_64" \
    -d pixel_8

# 4. Start the created AVD
emulator -avd pixel8_api35 -gpu host -memory 2048

# 5. List all AVDs
avdmanager list avd

Configuring AVD hardware characteristics

AVD Manager allows detailed configuration of the virtual device's hardware characteristics. Main parameters: RAM (random access memory, recommended value 2048–4096 MB), VM heap (virtual machine heap size, 256–512 MB), Internal Storage (2–8 GB) and SD Card (virtual SD card). These parameters affect application performance and its behavior under low memory conditions.

Additional settings include: camera (emulated or host webcam connection), sensors (accelerometer, gyroscope), NFC, Bluetooth, and battery. For example, to test applications with location detection, you can emulate device rotation through the emulator control buttons or via ADB. Sensor emulation allows testing scenarios that are difficult to reproduce on a physical device.

Key config.ini parameters

Optimizing emulator performance

AVD speed directly depends on hardware virtualization. On Windows, Windows Hypervisor Platform (WHPX) is used, on macOS — Hypervisor.Framework, on Linux — KVM. If virtualization is disabled, AVD operates in pure software emulation mode, which is 10–20 times slower. To check if virtualization is enabled, run the emulator with the -accel-check flag.

The second key factor is the choice of System Image architecture. x86_64 images work significantly faster than arm64-v8a on computers with Intel and AMD processors, as they do not require dynamic translation of ARM instructions. Always use x86_64 images for development on Windows and macOS with Intel processors. On Mac ARM processors (Apple Silicon), use native arm64-v8a images.

Command line flags for acceleration

# Launch with hardware virtualization and GPU acceleration
emulator -avd pixel8_api35 -gpu host -memory 4096 -cores 4

# Check virtualization support
emulator -accel-check

# Run without GUI (for CI)
emulator -avd pixel8_api35 -no-window -no-audio -gpu off

# Use snapshots for fast startup
emulator -avd pixel8_api35 -snapshot mysnapshot -no-snapshot-save

Emulator performance tips

For maximum AVD performance: allocate at least 2–4 GB of RAM to the emulator, enable GPU Host (uses the computer's graphics card for rendering), disable sound (the -no-audio flag) if not needed, and use Snapshots for quick return to a clean state. Snapshots save the complete system state — launching from a snapshot takes 2–5 seconds instead of 30–60 seconds for a full boot.

It is also recommended to store AVD on an SSD drive — I/O operations during system boot and APK installation are significantly faster. For running multiple AVDs simultaneously, increase the total amount of RAM on the computer and use the -read-only flag for immutable emulators.

Managing AVD from the command line

Full control over AVD is possible from the command line without Android Studio. The avdmanager and emulator tools are part of the Android SDK and perform all operations: creating, deleting, launching and configuring AVDs. The command line is especially useful in CI/CD pipelines, where there is no graphical interface, and for test automation.

Basic AVD management commands

# Create AVD with custom parameters
avdmanager create avd -n test_device \
    -k "system-images;android-34;google_apis;x86_64" \
    --device "pixel_8" \
    --force

# Delete AVD
avdmanager delete avd -n test_device

# Clone AVD (by copying files)
cp -r ~/.android/avd/pixel8_api35.avd ~/.android/avd/pixel8_clone.avd

# Wipe AVD data
emulator -avd test_device -wipe-data

# Install APK on running AVD
adb -s emulator-5554 install app-release.apk

ADB and AVD: key commands

After launching an AVD, you can work with it via ADB (Android Debug Bridge) just like with a physical device. ADB allows installing applications, launching intents, emulating events (calls, SMS, GPS), taking screenshots, and recording screen video. This makes AVD a full-fledged environment for automated testing.

# List connected devices (including AVD)
adb devices

# Simulate incoming call
adb emu gsm call +15551234567

# Simulate GPS coordinates
adb emu geo fix -122.084 37.422

# Take screenshot
adb exec-out screencap -p > screenshot.png

# Send SMS
adb emu sms send +15551234567 "Hello from AVD"

Checking the emulator in application code

Sometimes a developer needs to determine in code whether the application is running on an emulator or on a physical device. This may be needed to disable analytics (to avoid polluting production data), enable extended logging, or disable hardware-dependent features that do not work on the emulator. Google provides standard methods for checking through the Build class and system properties.

Check method through Build properties

object EmulatorDetector {
    fun isEmulator(): Boolean {
        return (Build.BRAND.startsWith("generic") &&
                Build.DEVICE.startsWith("generic")) ||
                Build.FINGERPRINT.startsWith("generic") ||
                Build.FINGERPRINT.startsWith("unknown") ||
                Build.HARDWARE.contains("goldfish") ||
                Build.HARDWARE.contains("ranchu") ||
                Build.MODEL.contains("google_sdk") ||
                Build.MODEL.contains("Emulator") ||
                Build.MODEL.contains("Android SDK")
    }
}

// Usage
if (EmulatorDetector.isEmulator()) {
    Log.d("App", "Running on emulator — enable debug mode")
}

Checking through system properties

An additional method is reading system properties through Build.getRadioVersion() and checking ro.kernel.qemu. On the emulator, radio version returns null and the qemu property is set to 1. This method is more reliable on older Android versions where Build.FINGERPRINT may be spoofed by the device manufacturer.

fun isRunningOnEmulator(): Boolean {
    // Check via radio version — on emulator always null
    val radioVersion = try {
        Build.getRadioVersion()
    } catch (e: Exception) {
        null
    }
    if (radioVersion.isNullOrBlank()) return true

    // Check via system properties
    return try {
        val props = ProcessBuilder()
            .command("getprop", "ro.kernel.qemu")
            .start()
            .inputStream.bufferedReader().readText().trim()
        props == "1"
    } catch (e: Exception) {
        false
    }
}