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 підтримує різні типи пристроїв: телефони, планшети, годинники 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 з командного рядка

# 1. Список доступних System Images
sdkmanager --list | grep system-images

# 2. Встановлення System Image для API 35 з Google APIs
sdkmanager "system-images;android-35;google_apis;x86_64"

# 3. Створення AVD з іменем pixel8_api35
avdmanager create avd -n pixel8_api35 \
    -k "system-images;android-35;google_apis;x86_64" \
    -d pixel_8

# 4. Запуск створеного AVD
emulator -avd pixel8_api35 -gpu host -memory 2048

# 5. Список всіх AVD
avdmanager list avd

Налаштування апаратних характеристик AVD

AVD Manager дозволяє детально налаштувати апаратні характеристики віртуального пристрою. Основні параметри: RAM (оперативна пам'ять, рекомендоване значення 2048–4096 МБ), VM heap (розмір купи віртуальної машини, 256–512 МБ), Internal Storage (внутрішня пам'ять, 2–8 ГБ) та 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 ГБ RAM, увімкніть GPU Host (використовує відеокарту комп'ютера для рендерингу), вимкніть звук (флаг -no-audio), якщо він не потрібний, та використовуйте Snapshots для швидкого повернення до чистого стану. Snapshots зберігають повний стан системи — запуск зі знімка займає 2–5 секунд замість 30–60 секунд повного завантаження.

Також рекомендується зберігати AVD на SSD-диску — операції введення-виведення під час завантаження системи та встановлення 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 дозволяє встановлювати додатки, запускати intents, емулювати події (дзвінки, 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
    }
}