Android-Emulator einrichten: AVDs, System-Images und Geräteprofile

Bevor du deine erste Compose-App auf einem echten Gerät testest, brauchst du eine zuverlässige virtuelle Umgebung. Der Android-Emulator gibt dir genau das: ein Set aus virtuellen Geräten, das den Alltag auf Telefonen, Tablets und Foldables abbildet, ohne dass du Hardware kaufen musst. Damit dieses Setup im Tagesgeschäft hilft statt zu bremsen, lohnt sich ein genauer Blick auf AVDs, System-Images und Geräteprofile.

Was ist das?

Ein AVD (Android Virtual Device) ist die Konfiguration eines simulierten Smartphones oder Tablets. Du legst Bildschirmgröße und Auflösung, RAM, Speicher, Sensoren und das Android-System fest, das gestartet werden soll. In Android Studio findest du dafür den Device Manager, früher AVD Manager genannt. Jedes AVD bekommt einen eigenen Datenordner, sodass du parallel mehrere Geräte mit unterschiedlichen API-Leveln pflegen kannst, ohne dass sie sich gegenseitig stören.

In der Roadmap gehört diese Einrichtung zu den Foundations. Du baust dir damit die Grundlage für manuelle Klick-Tests, automatisierte UI-Tests und das Debuggen, bevor es an Architektur, Coroutines oder Release geht. Ein gepflegtes Emulator-Setup ist der Unterschied zwischen “ich probiere mal etwas aus” und “ich teste meine App reproduzierbar auf den Geräten, die meine Nutzer wirklich haben”.

Wie funktioniert es?

Ein AVD setzt sich aus drei Bausteinen zusammen, die du getrennt verstehen solltest.

Das Geräteprofil

Das Profil legt fest, welche Hardware das virtuelle Gerät imitiert: ein Pixel 7, ein Pixel Tablet, ein generisches Foldable oder ein älteres Pixel mit kleinerem Display. Profile bestimmen Auflösung, Pixeldichte, RAM-Empfehlung, Sensoren und Formfaktor. Sie beantworten also die Frage: Welches Gerät spielen wir hier nach?

Das System-Image

Das System-Image ist die eigentliche Android-Version, die im Emulator startet. Du wählst hier das API-Level (zum Beispiel 34 für Android 14), die ABI (x86_64 oder arm64-v8a) und die Variante: Google Play, Google APIs oder reines AOSP. Für Apps mit Login über Google-Konto, Maps oder Push-Nachrichten brauchst du eine Google-Play-Variante. Für reine UI-Tests reicht oft Google APIs, was schneller startet und sich leichter zurücksetzen lässt.

Die AVD-Konfiguration selbst

Beim Anlegen verbindest du Profil und Image und passt RAM, internen Speicher sowie SD-Karte an. Auf Apple-Silicon-Macs läuft arm64-v8a nativ und ist deutlich schneller als ein x86_64-Image mit Übersetzung. Hardware-Beschleunigung übernimmt unter macOS das Hypervisor.framework, unter Windows Hyper-V oder HAXM, unter Linux KVM. Ohne diese Beschleunigung ist der Emulator quälend langsam — das ist die häufigste Ursache, wenn Lernende meinen, der Emulator sei grundsätzlich unbrauchbar.

In der Praxis

Ein praxisnahes Set aus drei oder vier AVDs reicht für die meisten Projekte und hält dein System schlank. Über die Kommandozeile lässt sich das reproduzierbar einrichten, was besonders im Team nützlich ist.

# Passende System-Images installieren
sdkmanager "system-images;android-34;google_apis_playstore;arm64-v8a"
sdkmanager "system-images;android-26;google_apis;arm64-v8a"

# AVD anlegen
avdmanager create avd \
  -n Pixel_7_API_34 \
  -k "system-images;android-34;google_apis_playstore;arm64-v8a" \
  -d "pixel_7"

# Vorhandene AVDs prüfen
avdmanager list avd

# Emulator headless starten (gut für CI und schnelle Tests)
emulator -avd Pixel_7_API_34 -no-snapshot -no-boot-anim

Eine bewährte Auswahl sieht so aus: ein aktuelles Telefon (zum Beispiel Pixel 7, API 34) mit Google Play für Alltagstests, ein älteres Telefon auf der minSdk deiner App (oft API 24–26) für Kompatibilität, und ein Tablet oder Foldable, um adaptive Layouts zu prüfen. So deckst du die wichtigsten Empfehlungen aus den Adaptive-App-Quality-Guidelines ab, ohne dich in fünfzehn Geräten zu verlieren.

Typische Stolperfalle

Viele richten genau ein AVD mit dem aktuellsten API-Level ein und merken erst beim Hochladen in Google Play, dass die App auf API 24 abstürzt, weil eine neuere API ohne Fallback verwendet wurde. Halte deshalb mindestens ein AVD bereit, das deinem minSdk entspricht. Eine zweite Falle: AVDs, die nie aufgeräumt werden. Jedes Image belegt mehrere Gigabyte. Setze den Zustand regelmäßig per Wipe Data zurück und entferne alte AVDs konsequent über den Device Manager. Wenn der Emulator nicht startet, prüfe als Erstes, ob die ABI zur Host-CPU passt und ob die Hardware-Beschleunigung wirklich aktiv ist (emulator -accel-check).

Fazit

Ein gutes Emulator-Setup ist kein einmaliges Klick-Ritual, sondern ein kleines Werkzeug-Set, das du aktiv pflegst. Lege dir jetzt zwei oder drei AVDs an, decke damit minSdk, aktuelle API und einen größeren Formfaktor ab, und starte deine Compose-App mehrmals hintereinander. Achte dabei auf Bootzeit, Hardware-Beschleunigung und das richtige System-Image. Schreibe als nächste Übung einen einfachen Instrumented-Test und lass ihn auf jedem deiner AVDs laufen — wer sein Setup früh über echte Tests prüft, fängt Layout- und API-Probleme ab, bevor sie auf den Geräten der Nutzer landen.