AVD Android: vad är det, Android Virtual Device och hur man ställer in emulatorn

Vad är AVD

AVD (Android Virtual Device) — är en mjukvarukonfiguration som beskriver en virtuell Android-enhet. Till skillnad från en fysisk telefon kräver AVD ingen hårdvara — den startas på datorn via Android-emulatorn baserad på QEMU. Utvecklaren skapar så många AVD som behövs för testning: för olika Android-versioner, skärmstorlekar, minnesmängder och pixeltätheter.

Varje AVD är bunden till en specifik SDK-plattform. Detta innebär att för att skapa en AVD med Android 14 (API Level 34) måste du först installera System Image för denna version via SDK Manager. System Image är en avbildning av operativsystemet som innehåller alla systemapplikationer, Google-tjänster (om Google APIs-avbildningen är vald) och runtime-komponenter. Google rekommenderar att använda Google APIs-avbildningar med Google Play-tjänster för maximal kompatibilitet med verkliga enheter.

AVD är oumbärlig inom utveckling av flera skäl. För det första möjliggör den testning av applikationen på olika Android-versioner utan att köpa dussintals enheter. För det andra stöder AVD Snapshots — sparande av systemtillstånd, vilket påskyndar starten. För det tredje är emulatorn integrerad med Android Studio: APK-installation, felsökning och loggning fungerar precis som på en fysisk enhet.

Typer av virtuella enheter

AVD stöder olika enhetstyper: telefoner (Phone), surfplattor (Tablet), klockor (Wear OS), TV-apparater (Android TV) och bilsystem (Android Automotive). För varje typ erbjuder AVD Manager färdiga profiler från Google: Pixel 8, Pixel 9 Pro, Nexus 7, Samsung Galaxy Tab och andra. Enhetsprofilen bestämmer skärmstorlek, upplösning, pixeltäthet (dpi) och navigering (gester eller knappar).

Vad består AVD av

Varje AVD är en uppsättning konfigurationsfiler och avbildningar. Huvudkonfigurationsfilen — config.ini, som lagrar parametrarna för den virtuella enheten: namn, typ, API-nivå, skärmstorlek, mängd RAM och VM heap. Filen finns i katalogen $HOME/.android/avd/NamnAVD.avd/ och kan ändras manuellt, även om den vanligtvis redigeras via AVD Manager.

Förutom config.ini lagras i AVD-katalogen: userdata.img (avbildning av användardata — applikationer, inställningar, filer), system.img (referens till System Image för den installerade SDK-plattformen), cache.img (cache) och sdcard.img (avbildning av SD-kort). Vid Wipe Data raderas userdata.img och en ny tom avbildning skapas. Snapshots sparas i en separat mapp snapshots/ i AVD-katalogen.

System Image laddas ner separat från AVD — en avbildning kan användas av flera virtuella enheter. Systemavbildningar lagras i Android SDK-katalogen: $ANDROID_SDK/system-images/android-{API}/{type}/{arch}/. Avbildningstyper: google_apis (med Google-tjänster), google_apis_playstore (med Google Play Store) och default (ren AOSP utan Google-tjänster).

Typer av System Images

Skapa AVD via AVD Manager

AVD Manager — är ett grafiskt verktyg i Android Studio för att skapa och hantera virtuella enheter. Det kan öppnas via menyn Tools → Device Manager eller via ikonen i verktygsfältet. AVD Manager visar en lista över skapade enheter, deras status (startad/stoppad), Android-version och tillgängliga åtgärder (starta, stoppa, wipe data, redigera).

För att skapa en ny AVD, klicka på Create device-knappen. Välj en enhetsprofil från listan över färdiga profiler — Google erbjuder profiler för alla populära enheter. Efter att ha valt profil, ange System Image: Android-version och avbildningstyp. För nya projekt, välj den senaste stabila versionen med Google APIs-avbildningen. Konfigurera sedan AVD-namnet, skärmorienteringen, mängden RAM och VM heap. Efter skapandet är AVD redo att startas.

Steg-för-steg skapande av AVD från kommandoraden

# Lista över tillgängliga System Images
sdkmanager --list | grep system-images

# Installera System Image för API 35 med Google APIs
sdkmanager "system-images;android-35;google_apis;x86_64"

# Skapa AVD med namnet pixel8_api35
avdmanager create avd -n pixel8_api35 \
    -k "system-images;android-35;google_apis;x86_64" \
    -d pixel_8

# Starta den skapade AVD
emulator -avd pixel8_api35 -gpu host -memory 2048

# Lista över alla AVD
avdmanager list avd

Konfigurera AVD:s hårdvaruegenskaper

AVD Manager möjliggör detaljerad konfiguration av den virtuella enhetens hårdvaruegenskaper. Huvudparametrar: RAM (arbetsminne, rekommenderat värde 2048–4096 MB), VM heap (heap-storlek för den virtuella maskinen, 256–512 MB), Internal Storage (internt lagringsutrymme, 2–8 GB) och SD Card (virtuellt SD-kort). Dessa parametrar påverkar applikationens prestanda och dess beteende vid minnesbrist.

Ytterligare inställningar inkluderar: kamera (emulerad eller anslutning av värdens webbkamera), sensorer (accelerometer, gyroskop), NFC, Bluetooth och batteri. Till exempel, för testning av positionsbestämningsapplikationer kan enhetens rotation emuleras via emulatorns kontrollknappar eller via ADB. Emulering av sensorer gör det möjligt att testa scenarier som är svåra att återskapa på en fysisk enhet.

Nyckelparametrar i config.ini

Optimera emulatorns prestanda

AVD:s hastighet beror direkt på hårdvaruvirtualisering. På Windows används Windows Hypervisor Platform (WHPX), på macOS — Hypervisor.Framework, på Linux — KVM. Om virtualisering är avstängd arbetar AVD i rent mjukvaruemuleringsläge, vilket är 10–20 gånger långsammare. För att kontrollera om virtualisering är påslagen, starta emulatorn med flaggan -accel-check.

Den andra nyckelfaktorn är valet av System Image-arkitektur. x86_64-avbildningar fungerar betydligt snabbare än arm64-v8a på datorer med Intel- och AMD-processorer, eftersom de inte kräver dynamisk översättning av ARM-instruktioner. Använd alltid x86_64-avbildningar för utveckling på Windows och macOS med Intel-processorer. På ARM-processorer för Mac (Apple Silicon) använd inbyggda arm64-v8a-avbildningar.

Kommandoradsflaggor för acceleration

# Starta med hårdvaruvirtualisering och GPU-acceleration
emulator -avd pixel8_api35 -gpu host -memory 4096 -cores 4

# Kontrollera virtualiseringsstöd
emulator -accel-check

# Starta utan grafiskt gränssnitt (för CI)
emulator -avd pixel8_api35 -no-window -no-audio -gpu off

# Använda snapshots för snabb start
emulator -avd pixel8_api35 -snapshot mysnapshot -no-snapshot-save

Prestandatips för emulatorn

För maximal AVD-prestanda: tilldela emulatorn minst 2–4 GB RAM, aktivera GPU Host (använder datorns grafikkort för rendering), stäng av ljud (flagga -no-audio), om det inte behövs, och använd Snapshots för snabb återgång till rent tillstånd. Snapshots sparar hela systemtillståndet — start från en ögonblicksbild tar 2–5 sekunder istället för 30–60 sekunders full laddning.

Det rekommenderas också att lagra AVD på en SSD-disk — I/O-operationer vid systemladdning och APK-installation påskyndas avsevärt. För att arbeta med flera AVD samtidigt, öka den totala mängden RAM på datorn och använd flaggan -read-only för oföränderliga emulatorer.

Hantera AVD från kommandoraden

Full kontroll över AVD är möjlig från kommandoraden utan Android Studio. Verktygen avdmanager och emulator ingår i Android SDK och utför alla operationer: skapa, ta bort, starta och konfigurera AVD. Kommandoraden är särskilt användbar i CI/CD-pipelines, där det inte finns något grafiskt gränssnitt, och för automatisering av testning.

Grundläggande kommandon för AVD-hantering

# Skapa AVD med anpassade parametrar
avdmanager create avd -n test_device \
    -k "system-images;android-34;google_apis;x86_64" \
    --device "pixel_8" \
    --force

# Ta bort AVD
avdmanager delete avd -n test_device

# Klona AVD (genom filkopiering)
cp -r ~/.android/avd/pixel8_api35.avd ~/.android/avd/pixel8_clone.avd

# Återställ AVD-data
emulator -avd test_device -wipe-data

# Installera APK på aktiv AVD
adb -s emulator-5554 install app-release.apk

ADB och AVD: nyckelkommandon

Efter att AVD har startats kan du arbeta med den via ADB (Android Debug Bridge) som med en fysisk enhet. ADB gör det möjligt att installera applikationer, köra intent, emulera händelser (samtal, SMS, GPS), ta skärmbilder och spela in skärmvideo. Detta gör AVD till en komplett miljö för automatiserad testning.

# Lista över anslutna enheter (inklusive AVD)
adb devices

# Emulering av inkommande samtal
adb emu gsm call +15551234567

# Emulering av GPS-koordinater
adb emu geo fix -122.084 37.422

# Ta skärmbild
adb exec-out screencap -p > screenshot.png

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

Kontrollera emulatorn i applikationskoden

Ibland måste utvecklaren i koden avgöra om applikationen körs på en emulator eller på en fysisk enhet. Detta kan behövas för att stänga av analys (för att inte förorena produktionsdata), aktivera utökad loggning eller stänga av hårdvaruberoende funktioner som inte fungerar på emulatorn. Google tillhandahåller standardmetoder för kontroll via klassen Build och systemegenskaper.

Kontrollmetod via Build-egenskap

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

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

Kontroll via systemegenskaper

Ytterligare metod — läsning av systemegenskaper via Build.getRadioVersion() och kontroll av ro.kernel.qemu. På emulatorn returnerar radio version null och qemu-egenskapen är inställd på 1. Denna metod är mer tillförlitlig på äldre Android-versioner där Build.FINGERPRINT kan ändras av enhetstillverkaren.

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

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