AVD Android: was ist das, Android Virtual Device und wie man den Emulator einrichtet

Was ist AVD

AVD (Android Virtual Device) ist eine Softwarekonfiguration, die ein virtuelles Android-Gerät beschreibt. Im Gegensatz zu einem physischen Telefon benötigt ein AVD keine Hardware — er läuft auf einem Computer über den auf QEMU basierenden Android-Emulator. Ein Entwickler erstellt so viele AVDs wie für Tests benötigt: für verschiedene Android-Versionen, Bildschirmgrößen, Speicherkapazitäten und Pixeldichten.

Jeder AVD ist an eine bestimmte SDK-Plattform gebunden. Das bedeutet, dass zum Erstellen eines AVD mit Android 14 (API-Level 34) zunächst das System Image dieser Version über den SDK Manager installiert werden muss. Das System Image ist ein Betriebssystem-Image, das alle Systemanwendungen, Google-Dienste (falls das Google APIs-Image ausgewählt ist) und Laufzeitkomponenten enthält. Google empfiehlt die Verwendung von Google APIs-Images mit Google Play-Diensten für maximale Kompatibilität mit echten Geräten.

AVD ist aus mehreren Gründen in der Entwicklung unverzichtbar. Erstens ermöglicht es das Testen der Anwendung auf verschiedenen Android-Versionen ohne den Kauf Dutzender Geräte. Zweitens unterstützt AVD Snapshots — das Speichern des Systemzustands, was den Start beschleunigt. Drittens ist der Emulator in Android Studio integriert: APK-Installation, Debugging und Protokollierung funktionieren genauso wie auf einem physischen Gerät.

Arten virtueller Geräte

AVD unterstützt verschiedene Gerätetypen: Telefone, Tablets, Wear OS-Uhren, Android TV und Android Automotive. Für jeden Typ stellt der AVD Manager vorgefertigte Profile von Google bereit: Pixel 8, Pixel 9 Pro, Nexus 7, Samsung Galaxy Tab und andere. Das Geräteprofil definiert Bildschirmgröße, Auflösung, Pixeldichte (dpi) und Navigation (Gesten oder Tasten).

Woraus besteht ein AVD

Jeder AVD ist eine Sammlung von Konfigurationsdateien und Images. Die Hauptkonfigurationsdatei ist config.ini, die die Parameter des virtuellen Geräts speichert: Name, Typ, API-Level, Bildschirmgröße, RAM und VM-Heap-Größe. Die Datei befindet sich im Verzeichnis $HOME/.android/avd/AVDName.avd/ und kann manuell geändert werden, wird aber normalerweise über den AVD Manager bearbeitet.

Neben config.ini werden im AVD-Verzeichnis gespeichert: userdata.img (Benutzerdaten-Image — Apps, Einstellungen, Dateien), system.img (Link zum System Image der installierten SDK-Plattform), cache.img (Cache) und sdcard.img (SD-Karten-Image). Bei der Durchführung von Wipe Data wird userdata.img gelöscht und ein neues leeres Image erstellt. Snapshots werden in einem separaten Ordner snapshots/ im AVD-Verzeichnis gespeichert.

Das System Image wird getrennt vom AVD heruntergeladen — ein Image kann von mehreren virtuellen Geräten verwendet werden. System-Images werden im Android SDK-Verzeichnis gespeichert: $ANDROID_SDK/system-images/android-{API}/{type}/{arch}/. Image-Typen: google_apis (mit Google-Diensten), google_apis_playstore (mit Google Play Store) und default (reines AOSP ohne Google-Dienste).

Arten von System Images

Erstellen eines AVD über den AVD Manager

AVD Manager ist ein grafisches Tool in Android Studio zum Erstellen und Verwalten virtueller Geräte. Es kann über das Menü Tools → Device Manager oder über das Symbol in der Symbolleiste geöffnet werden. Der AVD Manager zeigt die Liste der erstellten Geräte, ihren Status (läuft/gestoppt), die Android-Version und verfügbare Aktionen (starten, stoppen, Daten löschen, bearbeiten) an.

Um einen neuen AVD zu erstellen, klicken Sie auf die Schaltfläche Create device. Wählen Sie ein Geräteprofil aus der vorgefertigten Liste — Google stellt Profile für alle gängigen Geräte bereit. Nach der Auswahl eines Profils geben Sie das System Image an: Android-Version und Image-Typ. Wählen Sie für neue Projekte die neueste stabile Version mit dem Google APIs-Image. Konfigurieren Sie dann den AVD-Namen, die Bildschirmausrichtung, den RAM und die VM-Heap-Größe. Nach der Erstellung ist der AVD startbereit.

Schritt-für-Schritt-Erstellung eines AVD über die Befehlszeile

# 1. Verfügbare System Images auflisten
sdkmanager --list | grep system-images

# 2. System Image für API 35 mit Google APIs installieren
sdkmanager "system-images;android-35;google_apis;x86_64"

# 3. AVD mit Namen pixel8_api35 erstellen
avdmanager create avd -n pixel8_api35 \
    -k "system-images;android-35;google_apis;x86_64" \
    -d pixel_8

# 4. Erstellten AVD starten
emulator -avd pixel8_api35 -gpu host -memory 2048

# 5. Alle AVDs auflisten
avdmanager list avd

Konfiguration der Hardware-Eigenschaften eines AVD

Der AVD Manager ermöglicht eine detaillierte Konfiguration der Hardware-Eigenschaften des virtuellen Geräts. Hauptparameter: RAM (Arbeitsspeicher, empfohlener Wert 2048–4096 MB), VM-Heap (Heap-Größe der virtuellen Maschine, 256–512 MB), interner Speicher (2–8 GB) und SD-Karte (virtuelle SD-Karte). Diese Parameter beeinflussen die Anwendungsleistung und das Verhalten bei Speichermangel.

Zusätzliche Einstellungen umfassen: Kamera (emuliert oder Host-Webcam-Anschluss), Sensoren (Beschleunigungsmesser, Gyroskop), NFC, Bluetooth und Akku. Zum Testen von Anwendungen mit Standortermittlung kann beispielsweise die Gerätedrehung über die Steuertasten des Emulators oder über ADB emuliert werden. Die Sensoremuation ermöglicht das Testen von Szenarien, die auf einem physischen Gerät nur schwer reproduzierbar sind.

Wichtige config.ini-Parameter

Optimierung der Emulatorleistung

Die Geschwindigkeit des AVD hängt direkt von der Hardware-Virtualisierung ab. Unter Windows wird Windows Hypervisor Platform (WHPX) verwendet, unter macOS — Hypervisor.Framework, unter Linux — KVM. Wenn die Virtualisierung deaktiviert ist, arbeitet der AVD im reinen Software-Emulationsmodus, der 10–20 Mal langsamer ist. Um zu überprüfen, ob die Virtualisierung aktiviert ist, starten Sie den Emulator mit dem Flag -accel-check.

Der zweite Schlüsselfaktor ist die Wahl der System Image-Architektur. x86_64-Images arbeiten auf Computern mit Intel- und AMD-Prozessoren deutlich schneller als arm64-v8a, da sie keine dynamische Übersetzung von ARM-Befehlen benötigen. Verwenden Sie für die Entwicklung unter Windows und macOS mit Intel-Prozessoren immer x86_64-Images. Verwenden Sie auf Mac-ARM-Prozessoren (Apple Silicon) native arm64-v8a-Images.

Befehlszeilen-Flags für Beschleunigung

# Mit Hardware-Virtualisierung und GPU-Beschleunigung starten
emulator -avd pixel8_api35 -gpu host -memory 4096 -cores 4

# Virtualisierungsunterstützung prüfen
emulator -accel-check

# Ohne grafische Oberfläche ausführen (für CI)
emulator -avd pixel8_api35 -no-window -no-audio -gpu off

# Snapshots für schnellen Start verwenden
emulator -avd pixel8_api35 -snapshot mysnapshot -no-snapshot-save

Tipps zur Emulatorleistung

Für maximale AVD-Leistung: Weisen Sie dem Emulator mindestens 2–4 GB RAM zu, aktivieren Sie GPU Host (verwendet die Grafikkarte des Computers für die Darstellung), deaktivieren Sie den Ton (Flag -no-audio), falls nicht benötigt, und verwenden Sie Snapshots für die schnelle Rückkehr zu einem sauberen Zustand. Snapshots speichern den vollständigen Systemzustand — der Start aus einem Snapshot dauert 2–5 Sekunden statt 30–60 Sekunden für einen vollständigen Bootvorgang.

Es wird auch empfohlen, den AVD auf einem SSD-Laufwerk zu speichern — E/A-Operationen während des Systemstarts und der APK-Installation werden erheblich beschleunigt. Für den gleichzeitigen Betrieb mehrerer AVDs erhöhen Sie die Gesamt-RAM-Menge auf dem Computer und verwenden Sie das Flag -read-only für unveränderliche Emulatoren.

AVD-Verwaltung über die Befehlszeile

Die vollständige Kontrolle über AVDs ist über die Befehlszeile ohne Android Studio möglich. Die Tools avdmanager und emulator sind Teil des Android SDK und führen alle Operationen aus: Erstellen, Löschen, Starten und Konfigurieren von AVDs. Die Befehlszeile ist besonders nützlich in CI/CD-Pipelines, in denen es keine grafische Oberfläche gibt, und für die Testautomatisierung.

Grundlegende AVD-Verwaltungsbefehle

# AVD mit benutzerdefinierten Parametern erstellen
avdmanager create avd -n test_device \
    -k "system-images;android-34;google_apis;x86_64" \
    --device "pixel_8" \
    --force

# AVD löschen
avdmanager delete avd -n test_device

# AVD klonen (durch Kopieren von Dateien)
cp -r ~/.android/avd/pixel8_api35.avd ~/.android/avd/pixel8_clone.avd

# AVD-Daten zurücksetzen
emulator -avd test_device -wipe-data

# APK auf laufendem AVD installieren
adb -s emulator-5554 install app-release.apk

ADB und AVD: wichtige Befehle

Nach dem Starten eines AVD kann man darüber über ADB (Android Debug Bridge) genauso wie mit einem physischen Gerät arbeiten. ADB ermöglicht das Installieren von Anwendungen, das Starten von Intents, das Emulieren von Ereignissen (Anrufe, SMS, GPS), das Erstellen von Screenshots und die Aufnahme von Bildschirmvideos. Dies macht den AVD zu einer vollwertigen Umgebung für automatisierte Tests.

# Verbundene Geräte auflisten (einschließlich AVD)
adb devices

# Eingehenden Anruf simulieren
adb emu gsm call +15551234567

# GPS-Koordinaten simulieren
adb emu geo fix -122.084 37.422

# Screenshot machen
adb exec-out screencap -p > screenshot.png

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

Überprüfung des Emulators im Anwendungscode

Manchmal muss der Entwickler im Code feststellen, ob die Anwendung auf einem Emulator oder auf einem physischen Gerät ausgeführt wird. Dies kann erforderlich sein, um Analysen zu deaktivieren (um Produktionsdaten nicht zu verunreinigen), erweiterte Protokollierung zu aktivieren oder hardwareabhängige Funktionen zu deaktivieren, die auf dem Emulator nicht funktionieren. Google stellt Standardmethoden zur Überprüfung über die Build-Klasse und Systemeigenschaften bereit.

Überprüfungsmethode über Build-Eigenschaften

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

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

Überprüfung über Systemeigenschaften

Eine zusätzliche Methode ist das Lesen von Systemeigenschaften über Build.getRadioVersion() und die Überprüfung von ro.kernel.qemu. Auf dem Emulator gibt radio version null zurück und die qemu-Eigenschaft ist auf 1 gesetzt. Diese Methode ist auf älteren Android-Versionen zuverlässiger, bei denen Build.FINGERPRINT vom Gerätehersteller gefälscht sein kann.

fun isRunningOnEmulator(): Boolean {
    // Überprüfung über radio version — auf Emulator immer null
    val radioVersion = try {
        Build.getRadioVersion()
    } catch (e: Exception) {
        null
    }
    if (radioVersion.isNullOrBlank()) return true

    // Überprüfung über Systemeigenschaften
    return try {
        val props = ProcessBuilder()
            .command("getprop", "ro.kernel.qemu")
            .start()
            .inputStream.bufferedReader().readText().trim()
        props == "1"
    } catch (e: Exception) {
        false
    }
}