AVD Android: co to jest, Android Virtual Device i jak skonfigurować emulator

Co to jest AVD

AVD (Android Virtual Device) — to konfiguracja programowa opisująca wirtualne urządzenie z Androidem. W przeciwieństwie do fizycznego telefonu, AVD nie wymaga sprzętu — uruchamia się na komputerze przez emulator Androida oparty na QEMU. Programista tworzy tyle AVD, ile potrzebuje do testowania: na różne wersje Androida, rozmiary ekranu, ilości pamięci i gęstości pikseli.

Każdy AVD jest powiązany z konkretną SDK Platform. Oznacza to, że aby utworzyć AVD z Androidem 14 (API Level 34), należy najpierw zainstalować System Image tej wersji przez SDK Manager. System Image to obraz systemu operacyjnego, który zawiera wszystkie aplikacje systemowe, usługi Google (jeśli wybrano obraz Google APIs) i komponenty runtime. Google zaleca używanie obrazów Google APIs z usługami Google Play dla maksymalnej zgodności z rzeczywistymi urządzeniami.

AVD jest niezastąpiony przy programowaniu z kilku powodów. Po pierwsze, umożliwia testowanie aplikacji na różnych wersjach Androida bez kupowania dziesiątek urządzeń. Po drugie, AVD obsługuje Snapshots — zapisywanie stanu systemu, co przyspiesza uruchamianie. Po trzecie, emulator jest zintegrowany z Android Studio: instalacja APK, debugowanie i logowanie działają tak samo jak na fizycznym urządzeniu.

Typy wirtualnych urządzeń

AVD obsługuje różne typy urządzeń: telefony (Phone), tablety (Tablet), zegarki (Wear OS), telewizory (Android TV) i systemy samochodowe (Android Automotive). Dla każdego typu AVD Manager udostępnia gotowe profile od Google: Pixel 8, Pixel 9 Pro, Nexus 7, Samsung Galaxy Tab i inne. Profil urządzenia określa rozmiar ekranu, rozdzielczość, gęstość pikseli (dpi) i nawigację (gesty lub przyciski).

Z czego składa się AVD

Każdy AVD to zestaw plików konfiguracyjnych i obrazów. Główny plik konfiguracyjny — config.ini, który przechowuje parametry wirtualnego urządzenia: nazwę, typ, API Level, rozmiar ekranu, ilość RAM i VM heap. Plik znajduje się w katalogu $HOME/.android/avd/NazwaAVD.avd/ i może być edytowany ręcznie, chociaż zwykle modyfikuje się go przez AVD Manager.

Oprócz config.ini, w katalogu AVD przechowywane są: userdata.img (obraz danych użytkownika — aplikacje, ustawienia, pliki), system.img (odnośnik do System Image zainstalowanej SDK Platform), cache.img (pamięć podręczna) i sdcard.img (obraz karty SD). Przy wykonywaniu Wipe Data usuwany jest userdata.img i tworzony jest nowy pusty obraz. Snapshots są zapisywane w osobnym folderze snapshots/ wewnątrz katalogu AVD.

System Image jest pobierana oddzielnie od AVD — jeden obraz może być używany przez kilka wirtualnych urządzeń. Obrazy systemowe są przechowywane w katalogu Android SDK: $ANDROID_SDK/system-images/android-{API}/{type}/{arch}/. Typy obrazów: google_apis (z usługami Google), google_apis_playstore (z Google Play Store) i default (czysty AOSP bez usług Google).

Typy System Images

Tworzenie AVD przez AVD Manager

AVD Manager — to graficzne narzędzie w Android Studio do tworzenia i zarządzania wirtualnymi urządzeniami. Można je otworzyć przez menu Tools → Device Manager lub przez ikonę na pasku narzędzi. AVD Manager wyświetla listę utworzonych urządzeń, ich status (uruchomione/zatrzymane), wersję Androida i dostępne akcje (uruchomienie, zatrzymanie, wipe data, edycja).

Aby utworzyć nowy AVD, kliknij przycisk Create device. Wybierz profil urządzenia z listy gotowych — Google udostępnia profile dla wszystkich popularnych urządzeń. Po wybraniu profilu wskaż System Image: wersję Androida i typ obrazu. Dla nowych projektów wybierz najnowszą stabilną wersję z obrazem Google APIs. Następnie skonfiguruj nazwę AVD, orientację ekranu, ilość RAM i VM heap. Po utworzeniu AVD jest gotowy do uruchomienia.

Tworzenie AVD krok po kroku z wiersza poleceń

# Lista dostępnych System Images
sdkmanager --list | grep system-images

# Instalacja System Image dla API 35 z Google APIs
sdkmanager "system-images;android-35;google_apis;x86_64"

# Tworzenie AVD o nazwie pixel8_api35
avdmanager create avd -n pixel8_api35 \
    -k "system-images;android-35;google_apis;x86_64" \
    -d pixel_8

# Uruchomienie utworzonego AVD
emulator -avd pixel8_api35 -gpu host -memory 2048

# Lista wszystkich AVD
avdmanager list avd

Konfiguracja parametrów sprzętowych AVD

AVD Manager umożliwia szczegółową konfigurację parametrów sprzętowych wirtualnego urządzenia. Główne parametry: RAM (pamięć operacyjna, zalecana wartość 2048–4096 MB), VM heap (rozmiar sterty maszyny wirtualnej, 256–512 MB), Internal Storage (pamięć wewnętrzna, 2–8 GB) i SD Card (wirtualna karta SD). Te parametry wpływają na wydajność aplikacji i jej zachowanie przy braku pamięci.

Dodatkowe ustawienia obejmują: kamerę (emulowaną lub podłączenie kamery internetowej hosta), czujniki (akcelerometr, żyroskop), NFC, Bluetooth i baterię. Na przykład do testowania aplikacji z wykrywaniem położenia można emulować obrót urządzenia za pomocą przycisków sterowania emulatora lub przez ADB. Emulacja czujników umożliwia testowanie scenariuszy, które trudno odtworzyć na fizycznym urządzeniu.

Kluczowe parametry config.ini

Optymalizacja wydajności emulatora

Szybkość działania AVD zależy bezpośrednio od wirtualizacji sprzętowej. W systemie Windows używana jest Windows Hypervisor Platform (WHPX), na macOS — Hypervisor.Framework, na Linux — KVM. Jeśli wirtualizacja jest wyłączona, AVD działa w trybie czysto programowej emulacji, co jest 10–20 razy wolniejsze. Aby sprawdzić, czy wirtualizacja jest włączona, uruchom emulator z flagą -accel-check.

Drugim kluczowym czynnikiem jest wybór architektury System Image. Obrazy x86_64 działają znacznie szybciej niż arm64-v8a na komputerach z procesorami Intel i AMD, ponieważ nie wymagają dynamicznej translacji instrukcji ARM. Zawsze używaj obrazów x86_64 do programowania w systemach Windows i macOS z procesorami Intel. Na procesorach ARM Mac (Apple Silicon) używaj natywnych obrazów arm64-v8a.

Flagi wiersza poleceń do przyspieszenia

# Uruchomienie z wirtualizacją sprzętową i akceleracją GPU
emulator -avd pixel8_api35 -gpu host -memory 4096 -cores 4

# Sprawdzenie obsługi wirtualizacji
emulator -accel-check

# Uruchomienie bez interfejsu graficznego (dla CI)
emulator -avd pixel8_api35 -no-window -no-audio -gpu off

# Używanie snapshotów do szybkiego uruchamiania
emulator -avd pixel8_api35 -snapshot mysnapshot -no-snapshot-save

Wskazówki dotyczące wydajności emulatora

Dla maksymalnej wydajności AVD: przydziel emulatorowi co najmniej 2–4 GB RAM, włącz GPU Host (używa karty graficznej komputera do renderowania), wyłącz dźwięk (flaga -no-audio), jeśli nie jest potrzebny, i używaj Snapshots do szybkiego powrotu do czystego stanu. Snapshots zapisują pełny stan systemu — uruchomienie z migawki zajmuje 2–5 sekund zamiast 30–60 sekund pełnego ładowania.

Zaleca się również przechowywanie AVD na dysku SSD — operacje wejścia-wyjścia przy ładowaniu systemu i instalacji APK znacznie przyspieszają. Do pracy z kilkoma AVD jednocześnie zwiększ całkowitą ilość RAM w komputerze i używaj flagi -read-only dla niezmiennych emulatorów.

Zarządzanie AVD z wiersza poleceń

Pełna kontrola nad AVD jest możliwa z wiersza poleceń bez Android Studio. Narzędzia avdmanager i emulator wchodzą w skład Android SDK i wykonują wszystkie operacje: tworzenie, usuwanie, uruchamianie i konfigurację AVD. Wiersz poleceń jest szczególnie przydatny w pipeline'ach CI/CD, gdzie nie ma interfejsu graficznego, oraz do automatyzacji testowania.

Podstawowe polecenia zarządzania AVD

# Utwórz AVD z niestandardowymi parametrami
avdmanager create avd -n test_device \
    -k "system-images;android-34;google_apis;x86_64" \
    --device "pixel_8" \
    --force

# Usuń AVD
avdmanager delete avd -n test_device

# Klonuj AVD (przez kopiowanie plików)
cp -r ~/.android/avd/pixel8_api35.avd ~/.android/avd/pixel8_clone.avd

# Resetuj dane AVD
emulator -avd test_device -wipe-data

# Zainstaluj APK na uruchomionym AVD
adb -s emulator-5554 install app-release.apk

ADB i AVD: kluczowe polecenia

Po uruchomieniu AVD można z nim pracować przez ADB (Android Debug Bridge), tak jak z fizycznym urządzeniem. ADB umożliwia instalowanie aplikacji, uruchamianie intents, emulowanie zdarzeń (połączenia, SMS, GPS), robienie zrzutów ekranu i nagrywanie wideo ekranu. To czyni AVD pełnoprawnym środowiskiem do zautomatyzowanego testowania.

# Lista podłączonych urządzeń (w tym AVD)
adb devices

# Emulacja połączenia przychodzącego
adb emu gsm call +15551234567

# Emulacja współrzędnych GPS
adb emu geo fix -122.084 37.422

# Zrób zrzut ekranu
adb exec-out screencap -p > screenshot.png

# Wyślij SMS
adb emu sms send +15551234567 "Hello from AVD"

Sprawdzanie emulatora w kodzie aplikacji

Czasami programista musi określić w kodzie, czy aplikacja jest uruchomiona na emulatorze, czy na fizycznym urządzeniu. Może to być potrzebne do wyłączenia analityki (aby nie zanieczyszczać danych produkcyjnych), włączenia rozszerzonego logowania lub wyłączenia funkcji zależnych od sprzętu, które nie działają na emulatorze. Google udostępnia standardowe metody sprawdzania przez klasę Build i właściwości systemu.

Metoda sprawdzania przez właściwość 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")
    }
}

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

Sprawdzanie przez właściwości systemu

Dodatkowy sposób — odczytywanie właściwości systemowych przez Build.getRadioVersion() i sprawdzanie ro.kernel.qemu. Na emulatorze radio version zwraca null, a właściwość qemu jest ustawiona na 1. Ta metoda jest bardziej niezawodna na starszych wersjach Androida, gdzie Build.FINGERPRINT może być podmieniony przez producenta urządzenia.

fun isRunningOnEmulator(): Boolean {
    // Sprawdzenie przez radio version — na emulatorze zawsze null
    val radioVersion = try {
        Build.getRadioVersion()
    } catch (e: Exception) {
        null
    }
    if (radioVersion.isNullOrBlank()) return true

    // Sprawdzenie przez właściwości systemowe
    return try {
        val props = ProcessBuilder()
            .command("getprop", "ro.kernel.qemu")
            .start()
            .inputStream.bufferedReader().readText().trim()
        props == "1"
    } catch (e: Exception) {
        false
    }
}