AVD Android: какво е, Android Virtual Device и как да настроите емулатора

Какво е AVD

AVD (Android Virtual Device) — софтуерна конфигурация, която описва виртуално Android устройство. За разлика от физическия телефон, AVD не изисква хардуер — стартира се на компютъра чрез емулатора на Android, базиран на QEMU. Разработчикът създава толкова AVD, колкото са необходими за тестване: за различни версии на Android, размери на екрана, количества памет и плътности на пикселите.

Всеки AVD е обвързан с конкретна SDK Platform. Това означава, че за създаване на AVD с Android 14 (API Level 34) първо трябва да инсталирате System Image на тази версия чрез SDK Manager. System Image е образ на операционната система, който включва всички системни приложения, услуги на Google (ако е избран образът Google APIs) и компоненти за изпълнение. Google препоръчва използването на образи Google APIs с услуги на Google Play за максимална съвместимост с реални устройства.

AVD е незаменим в разработката по няколко причини. Първо, позволява тестване на приложението на различни версии на Android без закупуване на десетки устройства. Второ, AVD поддържа Snapshots — запазване на състоянието на системата, което ускорява стартирането. Трето, емулаторът е интегриран с Android Studio: инсталирането на APK, отстраняването на грешки и регистрирането работят както на физическо устройство.

Типове виртуални устройства

AVD поддържа различни типове устройства: телефони (Phone), таблети (Tablet), часовници (Wear OS), телевизори (Android TV) и автомобилни системи (Android Automotive). За всеки тип AVD Manager предоставя готови профили от Google: Pixel 8, Pixel 9 Pro, Nexus 7, Samsung Galaxy Tab и други. Профилът на устройството определя размера на екрана, резолюцията, плътността на пикселите (dpi) и навигацията (жестове или бутони).

От какво се състои AVD

Всеки AVD е набор от конфигурационни файлове и образи. Основният конфигурационен файл — config.ini, който съхранява параметрите на виртуалното устройство: име, тип, API Level, размер на екрана, количество RAM и VM heap. Файлът се намира в директорията $HOME/.android/avd/ИмеAVD.avd/ и може да бъде променян ръчно, въпреки че обикновено се редактира чрез AVD Manager.

Освен config.ini, в директорията на AVD се съхраняват: userdata.img (образ на потребителските данни — приложения, настройки, файлове), system.img (препратка към System Image на инсталираната SDK Platform), cache.img (кеш) и sdcard.img (образ на SD карта). При изпълнение на Wipe Data, userdata.img се изтрива и се създава нов празен образ. Snapshots се записват в отделна папка snapshots/ в директорията на AVD.

System Image се изтегля отделно от AVD — един образ може да се използва от няколко виртуални устройства. Системните образи се съхраняват в директорията на Android SDK: $ANDROID_SDK/system-images/android-{API}/{type}/{arch}/. Типове образи: google_apis (с услуги на Google), google_apis_playstore (с Google Play Store) и default (чист AOSP без услуги на Google).

Типове System Images

Създаване на AVD чрез AVD Manager

AVD Manager — графичен инструмент в Android Studio за създаване и управление на виртуални устройства. Може да бъде отворен чрез меню Tools → Device Manager или чрез иконата в лентата с инструменти. AVD Manager показва списък на създадените устройства, техния статус (стартирано/спряно), версия на Android и наличните действия (стартиране, спиране, wipe data, редактиране).

За създаване на нов AVD кликнете върху бутона Create device. Изберете профил на устройство от списъка с готови профили — Google предоставя профили за всички популярни устройства. След избор на профил, посочете System Image: версия на Android и тип образ. За нови проекти изберете най-новата стабилна версия с образ Google APIs. След това конфигурирайте името на AVD, ориентацията на екрана, количеството RAM и VM heap. След създаването AVD е готов за стартиране.

Постепенно създаване на AVD от команден ред

# Списък на наличните System Images
sdkmanager --list | grep system-images

# Инсталиране на System Image за API 35 с Google APIs
sdkmanager "system-images;android-35;google_apis;x86_64"

# Създаване на AVD с име pixel8_api35
avdmanager create avd -n pixel8_api35 \
    -k "system-images;android-35;google_apis;x86_64" \
    -d pixel_8

# Стартиране на създадения AVD
emulator -avd pixel8_api35 -gpu host -memory 2048

# Списък на всички AVD
avdmanager list avd

Конфигуриране на хардуерните характеристики на AVD

AVD Manager позволява детайлно конфигуриране на хардуерните характеристики на виртуалното устройство. Основни параметри: RAM (оперативна памет, препоръчителна стойност 2048–4096 MB), VM heap (размер на купчината на виртуалната машина, 256–512 MB), Internal Storage (вътрешна памет, 2–8 GB) и SD Card (виртуална SD карта). Тези параметри влияят на производителността на приложението и поведението му при липса на памет.

Допълнителни настройки включват: камера (емулирана или свързване на уеб камера на хоста), сензори (акселерометър, жироскоп), NFC, Bluetooth и батерия. Например, за тестване на приложения за определяне на местоположение, завъртането на устройството може да бъде емулирано чрез бутоните за управление на емулатора или чрез ADB. Емулацията на сензори позволява тестване на сценарии, които са трудни за възпроизвеждане на физическо устройство.

Ключови параметри на config.ini

Оптимизиране на производителността на емулатора

Скоростта на работа на AVD зависи пряко от хардуерната виртуализация. На Windows се използва Windows Hypervisor Platform (WHPX), на macOS — Hypervisor.Framework, на Linux — KVM. Ако виртуализацията е изключена, AVD работи в режим на чисто софтуерна емулация, което е 10–20 пъти по-бавно. За да проверите дали виртуализацията е включена, стартирайте емулатора с флаг -accel-check.

Вторият ключов фактор е изборът на архитектура на System Image. Образите x86_64 работят значително по-бързо от arm64-v8a на компютри с процесори Intel и AMD, тъй като не изискват динамичен превод на ARM инструкции. Винаги използвайте x86_64 образи за разработка на Windows и macOS с процесори Intel. На ARM процесори на Mac (Apple Silicon) използвайте родни arm64-v8a образи.

Флагове от команден ред за ускорение

# Стартиране с хардуерна виртуализация и GPU ускорение
emulator -avd pixel8_api35 -gpu host -memory 4096 -cores 4

# Проверка на поддръжката на виртуализация
emulator -accel-check

# Стартиране без графичен интерфейс (за CI)
emulator -avd pixel8_api35 -no-window -no-audio -gpu off

# Използване на snapshot-и за бързо стартиране
emulator -avd pixel8_api35 -snapshot mysnapshot -no-snapshot-save

Съвети за производителност на емулатора

За максимална производителност на AVD: отделете на емулатора поне 2–4 GB RAM, включете GPU Host (използва видеокартата на компютъра за рендиране), изключете звука (флаг -no-audio), ако не е необходим, и използвайте Snapshots за бързо връщане към чисто състояние. Snapshots запазват пълното състояние на системата — стартирането от моментен снимка отнема 2–5 секунди вместо 30–60 секунди пълно зареждане.

Също така се препоръчва съхранение на AVD на SSD диск — I/O операциите при зареждане на системата и инсталиране на APK значително се ускоряват. За работа с няколко AVD едновременно, увеличете общото количество RAM на компютъра и използвайте флаг -read-only за неизменяеми емулатори.

Управление на AVD от команден ред

Пълен контрол над AVD е възможен от команден ред без Android Studio. Инструментите avdmanager и emulator са част от Android SDK и извършват всички операции: създаване, изтриване, стартиране и конфигуриране на AVD. Командният ред е особено полезен в CI/CD тръбопроводи, където няма графичен интерфейс, и за автоматизиране на тестването.

Основни команди за управление на AVD

# Създаване на AVD с персонализирани параметри
avdmanager create avd -n test_device \
    -k "system-images;android-34;google_apis;x86_64" \
    --device "pixel_8" \
    --force

# Изтриване на AVD
avdmanager delete avd -n test_device

# Клониране на AVD (чрез копиране на файлове)
cp -r ~/.android/avd/pixel8_api35.avd ~/.android/avd/pixel8_clone.avd

# Нулиране на данните на AVD
emulator -avd test_device -wipe-data

# Инсталиране на APK на работещ AVD
adb -s emulator-5554 install app-release.apk

ADB и AVD: ключови команди

След стартиране на AVD може да работите с него чрез ADB (Android Debug Bridge) като с физическо устройство. ADB позволява инсталиране на приложения, стартиране на intent, емулиране на събития (обаждания, SMS, GPS), правене на екранни снимки и записване на видео на екрана. Това прави AVD пълноценна среда за автоматизирано тестване.

# Списък на свързани устройства (включително AVD)
adb devices

# Емулация на входящо повикване
adb emu gsm call +15551234567

# Емулация на GPS координати
adb emu geo fix -122.084 37.422

# Направете екранна снимка
adb exec-out screencap -p > screenshot.png

# Изпращане на SMS
adb emu sms send +15551234567 "Hello from AVD"

Проверка на емулатора в кода на приложението

Понякога разработчикът трябва да определи в кода дали приложението работи на емулатор или на физическо устройство. Това може да е необходимо за изключване на аналитика (за да не замърсява продукционните данни), включване на разширено регистриране или изключване на хардуерно зависими функции, които не работят на емулатора. Google предоставя стандартни методи за проверка чрез класа Build и системни свойства.

Метод за проверка чрез свойство на Build

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")
    }
}

// Използване
if (EmulatorDetector.isEmulator()) {
    Log.d("App", "Running on emulator — enable debug mode")
}

Проверка чрез системни свойства

Допълнителен метод — четене на системни свойства чрез Build.getRadioVersion() и проверка на ro.kernel.qemu. На емулатора radio version връща null, а свойството qemu е зададено на 1. Този метод е по-надежден на по-стари версии на Android, където Build.FINGERPRINT може да бъде променен от производителя на устройството.

fun isRunningOnEmulator(): Boolean {
    // Проверка чрез radio version — на емулатора винаги null
    val radioVersion = try {
        Build.getRadioVersion()
    } catch (e: Exception) {
        null
    }
    if (radioVersion.isNullOrBlank()) return true

    // Проверка чрез системни свойства
    return try {
        val props = ProcessBuilder()
            .command("getprop", "ro.kernel.qemu")
            .start()
            .inputStream.bufferedReader().readText().trim()
        props == "1"
    } catch (e: Exception) {
        false
    }
}