AVD Android: wat is het, Android Virtual Device en hoe de emulator in te stellen

Wat is AVD

AVD (Android Virtual Device) — is een softwareconfiguratie die een virtueel Android-apparaat beschrijft. In tegenstelling tot een fysieke telefoon heeft AVD geen hardware nodig — het wordt gestart op de computer via de Android-emulator op basis van QEMU. De ontwikkelaar maakt zoveel AVD's als nodig voor het testen: voor verschillende Android-versies, schermformaten, geheugenhoeveelheden en pixeldichtheden.

Elke AVD is gekoppeld aan een specifiek SDK Platform. Dit betekent dat om een AVD met Android 14 (API Level 34) te maken, u eerst de System Image van deze versie moet installeren via SDK Manager. System Image is een besturingssysteemimage dat alle systeemapplicaties, Google-services (als de Google APIs-image is geselecteerd) en runtime-componenten bevat. Google raadt aan om Google APIs-images met Google Play-services te gebruiken voor maximale compatibiliteit met echte apparaten.

AVD is onmisbaar bij ontwikkeling om verschillende redenen. Ten eerste kunt u de applicatie testen op verschillende Android-versies zonder tientallen apparaten te kopen. Ten tweede ondersteunt AVD Snapshots — het opslaan van de systeemstatus, wat het opstarten versnelt. Ten derde is de emulator geïntegreerd met Android Studio: APK-installatie, debuggen en loggen werken hetzelfde als op een fysiek apparaat.

Soorten virtuele apparaten

AVD ondersteunt verschillende apparaattypen: telefoons (Phone), tablets (Tablet), horloges (Wear OS), televisies (Android TV) en autosystemen (Android Automotive). Voor elk type biedt AVD Manager kant-en-klare profielen van Google: Pixel 8, Pixel 9 Pro, Nexus 7, Samsung Galaxy Tab en andere. Het apparaatprofiel bepaalt de schermgrootte, resolutie, pixeldichtheid (dpi) en navigatie (gebaren of knoppen).

Waaruit bestaat AVD

Elke AVD is een set configuratiebestanden en images. Het belangrijkste configuratiebestand — config.ini, dat de parameters van het virtuele apparaat opslaat: naam, type, API Level, schermgrootte, hoeveelheid RAM en VM heap. Het bestand bevindt zich in de map $HOME/.android/avd/NaamAVD.avd/ en kan handmatig worden gewijzigd, hoewel het meestal via AVD Manager wordt bewerkt.

Naast config.ini worden in de AVD-map opgeslagen: userdata.img (image van gebruikersgegevens — applicaties, instellingen, bestanden), system.img (verwijzing naar de System Image van het geïnstalleerde SDK Platform), cache.img (cache) en sdcard.img (image van de SD-kaart). Bij het uitvoeren van Wipe Data wordt userdata.img verwijderd en wordt een nieuwe lege image gemaakt. Snapshots worden opgeslagen in een aparte map snapshots/ in de AVD-map.

System Image wordt apart van de AVD gedownload — één image kan door meerdere virtuele apparaten worden gebruikt. Systeemimages worden opgeslagen in de Android SDK-map: $ANDROID_SDK/system-images/android-{API}/{type}/{arch}/. Imagetypen: google_apis (met Google-services), google_apis_playstore (met Google Play Store) en default (schone AOSP zonder Google-services).

Soorten System Images

AVD maken via AVD Manager

AVD Manager — is een grafische tool in Android Studio voor het maken en beheren van virtuele apparaten. U kunt het openen via het menu Tools → Device Manager of via het pictogram op de werkbalk. AVD Manager toont een lijst van gemaakte apparaten, hun status (gestart/gestopt), Android-versie en beschikbare acties (starten, stoppen, wipe data, bewerken).

Klik op Create device om een nieuwe AVD te maken. Selecteer een apparaatprofiel uit de lijst met kant-en-klare profielen — Google biedt profielen voor alle populaire apparaten. Na het selecteren van het profiel geeft u de System Image op: Android-versie en imagetype. Kies voor nieuwe projecten de nieuwste stabiele versie met de Google APIs-image. Configureer vervolgens de AVD-naam, schermoriëntatie, hoeveelheid RAM en VM heap. Na het maken is de AVD klaar om te starten.

Stap voor stap AVD maken vanaf de opdrachtregel

# Lijst van beschikbare System Images
sdkmanager --list | grep system-images

# System Image installeren voor API 35 met Google APIs
sdkmanager "system-images;android-35;google_apis;x86_64"

# AVD aanmaken met naam pixel8_api35
avdmanager create avd -n pixel8_api35 \
    -k "system-images;android-35;google_apis;x86_64" \
    -d pixel_8

# Aangemaakte AVD starten
emulator -avd pixel8_api35 -gpu host -memory 2048

# Lijst van alle AVD's
avdmanager list avd

Hardware-eigenschappen van AVD configureren

AVD Manager maakt het mogelijk de hardware-eigenschappen van het virtuele apparaat gedetailleerd te configureren. De belangrijkste parameters: RAM (werkgeheugen, aanbevolen waarde 2048–4096 MB), VM heap (heapgrootte van de virtuele machine, 256–512 MB), Internal Storage (intern geheugen, 2–8 GB) en SD Card (virtuele SD-kaart). Deze parameters beïnvloeden de prestaties van de applicatie en het gedrag bij geheugentekort.

Extra instellingen omvatten: camera (geëmuleerd of aansluiten van de host-webcam), sensoren (versnellingsmeter, gyroscoop), NFC, Bluetooth en batterij. Bijvoorbeeld, voor het testen van positiebepalingsapplicaties kan de rotatie van het apparaat worden geëmuleerd via de bedieningsknoppen van de emulator of via ADB. Emulatie van sensoren maakt het testen mogelijk van scenario's die moeilijk te reproduceren zijn op een fysiek apparaat.

Belangrijkste parameters van config.ini

Prestaties van de emulator optimaliseren

De snelheid van AVD hangt direct af van hardwarevirtualisatie. Op Windows wordt Windows Hypervisor Platform (WHPX) gebruikt, op macOS — Hypervisor.Framework, op Linux — KVM. Als virtualisatie is uitgeschakeld, werkt AVD in zuiver software-emulatiemodus, wat 10–20 keer langzamer is. Om te controleren of virtualisatie is ingeschakeld, start u de emulator met de vlag -accel-check.

De tweede belangrijke factor is de keuze van de System Image-architectuur. x86_64-images werken aanzienlijk sneller dan arm64-v8a op computers met Intel- en AMD-processors, omdat ze geen dynamische vertaling van ARM-instructies nodig hebben. Gebruik altijd x86_64-images voor ontwikkeling op Windows en macOS met Intel-processors. Gebruik op ARM-processors van Mac (Apple Silicon) native arm64-v8a-images.

Opdrachtregelvlaggen voor versnelling

# Starten met hardwarevirtualisatie en GPU-versnelling
emulator -avd pixel8_api35 -gpu host -memory 4096 -cores 4

# Virtualisatieondersteuning controleren
emulator -accel-check

# Starten zonder grafische interface (voor CI)
emulator -avd pixel8_api35 -no-window -no-audio -gpu off

# Snapshots gebruiken voor snel opstarten
emulator -avd pixel8_api35 -snapshot mysnapshot -no-snapshot-save

Prestatietips voor de emulator

Voor maximale AVD-prestaties: wijs de emulator ten minste 2–4 GB RAM toe, schakel GPU Host in (gebruikt de videokaart van de computer voor rendering), schakel geluid uit (vlag -no-audio), indien niet nodig, en gebruik Snapshots voor snel terugkeren naar een schone staat. Snapshots slaan de volledige systeemstatus op — opstarten vanuit een momentopname duurt 2–5 seconden in plaats van 30–60 seconden volledig laden.

Het wordt ook aanbevolen om AVD op een SSD-schijf op te slaan — I/O-bewerkingen bij het laden van het systeem en installeren van APK worden aanzienlijk versneld. Voor het gelijktijdig werken met meerdere AVD's, verhoogt u de totale hoeveelheid RAM op de computer en gebruikt u de vlag -read-only voor onveranderlijke emulators.

AVD beheren vanaf de opdrachtregel

Volledige controle over AVD is mogelijk vanaf de opdrachtregel zonder Android Studio. De tools avdmanager en emulator maken deel uit van de Android SDK en voeren alle bewerkingen uit: AVD maken, verwijderen, starten en configureren. De opdrachtregel is vooral nuttig in CI/CD-pijplijnen waar geen grafische interface is, en voor het automatiseren van testen.

Belangrijkste AVD-beheeropdrachten

# AVD met aangepaste parameters maken
avdmanager create avd -n test_device \
    -k "system-images;android-34;google_apis;x86_64" \
    --device "pixel_8" \
    --force

# AVD verwijderen
avdmanager delete avd -n test_device

# AVD klonen (via bestandskopiëren)
cp -r ~/.android/avd/pixel8_api35.avd ~/.android/avd/pixel8_clone.avd

# AVD-gegevens resetten
emulator -avd test_device -wipe-data

# APK installeren op actieve AVD
adb -s emulator-5554 install app-release.apk

ADB en AVD: belangrijkste opdrachten

Na het starten van AVD kunt u ermee werken via ADB (Android Debug Bridge) zoals met een fysiek apparaat. ADB maakt het mogelijk applicaties te installeren, intents uit te voeren, gebeurtenissen te emuleren (oproepen, SMS, GPS), schermafbeeldingen te maken en schermvideo op te nemen. Dit maakt AVD een complete omgeving voor geautomatiseerd testen.

# Lijst van aangesloten apparaten (inclusief AVD)
adb devices

# Emulatie van inkomende oproep
adb emu gsm call +15551234567

# Emulatie van GPS-coördinaten
adb emu geo fix -122.084 37.422

# Schermafbeelding maken
adb exec-out screencap -p > screenshot.png

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

Emulator controleren in de applicatiecode

Soms moet de ontwikkelaar in de code bepalen of de applicatie op een emulator of op een fysiek apparaat draait. Dit kan nodig zijn om analytics uit te schakelen (om productiegegevens niet te vervuilen), uitgebreide logging in te schakelen of hardware-afhankelijke functies uit te schakelen die niet werken op de emulator. Google biedt standaard controlemethoden via de Build-klasse en systeemeigenschappen.

Controlemethode via Build-eigenschap

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

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

Controleren via systeemeigenschappen

Extra methode — het lezen van systeemeigenschappen via Build.getRadioVersion() en het controleren van ro.kernel.qemu. Op de emulator retourneert radio version null, en de qemu-eigenschap is ingesteld op 1. Deze methode is betrouwbaarder op oudere Android-versies waar Build.FINGERPRINT kan worden gewijzigd door de apparaatfabrikant.

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

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