docker-android: KVM-beschleunigte Android-Emulatoren im Container, jetzt mit MCP und lokalen LLM-Agenten
budtmo/docker-android bündelt einen Android-Emulator, einen noVNC-Webdesktop, Log-Freigabe und adb-Zugriff in einem einzigen Docker-Image. Es deckt Android 9 bis 14 ab und eignet sich für App-Builds, Appium- oder Espresso-Tests und Cloud-Einsätze. Neuere Versionen bringen ein MCP-Server-Image und einen KI-Agenten, beide in der Beta-Phase, die lokale LLM-Server wie Ollama und vLLM ansprechen können. Der Nutzen liegt darin, ein anfälliges mobiles Testsetup auf einen docker-run-Befehl zu reduzieren. Der Preis: Ein Linux-Host mit KVM ist zwingend nötig.
Überblick
budtmo/docker-android ist eine Sammlung von Docker-Images für alles rund um Android. Das Projekt versteht sich als Container für Entwicklung und Test von nativen, Web- und Hybrid-Apps. Ein einziger Container enthält einen Android-Emulator mit gewähltem Geräteprofil, einen VNC-Dienst, den man im Browser ansehen kann, eine Weboberfläche für Logs und einen adb-Zugang. Zum Start genügt ein docker-run-Befehl.
Die Image-Liste deckt Android 9 bis 14 ab, also die API-Level 28 bis 34. Jede Version hat ein Tag für das neueste Release und eines für ein bestimmtes Release. Zwei weitere Images fallen auf. Das Image genymotion verbindet sich mit Genymotion Cloud. Das Image mcp ist die neue Richtung, die besondere Aufmerksamkeit verdient. Die README nennt Geräteprofile wie die Samsung-Galaxy-Reihe S6 bis S10, Nexus 4, Nexus 5, Nexus One und Nexus S sowie die Tablets Nexus 7 und Pixel C.
Kernarchitektur
Der Aufbau lässt sich in drei Schichten lesen. Die unterste Schicht ist KVM auf dem Host. Die mittlere Schicht ist das Android-SDK samt Emulator-Prozess im Container, der das Systemabbild des gewählten API-Levels und die Gerätekonfiguration lädt. Die oberste Schicht besteht aus den Zugängen für Nutzer: ein noVNC-Webdesktop, standardmäßig auf Port 6080 abgebildet, eine Webseite zur Log-Freigabe und ein Debug-Port, den der Host mit adb connect erreicht.
Der Vorteil ist der einheitliche Zugang. Entwickler sehen den Emulator direkt im Browser. Ein Testframework wie Appium oder Espresso steuert das Gerät über adb oder dessen Dienstport. Build, Unit-Tests und UI-Tests teilen sich dasselbe Image, sodass niemand SDK, Systemabbilder und Abhängigkeiten auf jedem Rechner neu installieren muss.
Funktionsweise
Ein Android-Emulator ist ein auf QEMU beruhender Virtualisierer für die ganze Maschine. Damit er im Container brauchbar schnell läuft, muss das x86-Systemabbild über KVM die Hardware-Virtualisierungsbefehle der CPU nutzen. Ein Container bringt keine eigene Virtualisierung mit, er teilt nur den Kernel des Hosts. Deshalb verlangt das Projekt den Start mit --device /dev/kvm, das den Geräteknoten an den Container reicht. Auch der Schnellstart beginnt mit kvm-ok, um zu prüfen, ob der Host Virtualisierung unterstützt.
Das erklärt, warum das Image nur unter Ubuntu läuft. Die README sagt, dass Nutzer von macOS und Windows zuerst eine Ubuntu-VM mit Virtualisierungsunterstützung brauchen. Für WSL2 unter Windows 11 gibt es ein eigenes Rezept: den Benutzer der Gruppe kvm hinzufügen, Besitzer und Rechte von /dev/kvm im Boot-Befehl der Datei /etc/wsl.conf setzen und in .wslconfig die Option nestedVirtualization aktivieren.
Umgebungsvariablen steuern das Laufzeitverhalten. EMULATOR_DEVICE wählt das Geräteprofil, WEB_VNC=true schaltet den Webdesktop ein. Standardmäßig wird das emulierte Gerät beim Neustart des Containers zerstört. Hängt man ein Volume unter /home/androidusr ein, bleiben Apps und Einstellungen erhalten. Dieses Muster, standardmäßig verwerfbar und auf Wunsch dauerhaft, entspricht dem, was Continuous Integration von einer sauberen Umgebung erwartet.
MCP und der KI-Agent
Die jüngste Neuerung sind der MCP-Server und der KI-Agent. Die README stuft beide als Beta ein und enthält ein Diagramm. MCP ist ein Protokoll, mit dem ein KI-Client externe Werkzeuge auf standardisierte Weise aufruft. Wird ein Android-Emulator als MCP-Server bereitgestellt, kann ein Coding-Assistent ein Gerät starten, den Bildschirm lesen, tippen, Text eingeben und das Ergebnis auslesen, ohne dass für jeden Assistenten ein eigener Adapter nötig wäre.
Der KI-Agent geht einen Schritt weiter. Laut README unterstützt er zwei lokale Modellserver, Ollama und vLLM. Ein lokales Modell hat einen klaren Sinn: Screenshots und Daten der getesteten App bleiben im eigenen Netz, und es fallen keine Gebühren pro Aufruf bei einer Cloud-API an. Dafür braucht man GPU-Speicher und Inferenzdurchsatz, und kleine Modelle beurteilen komplexe Oberflächen schlechter.
Kosten und Abwägungen
Die README nennt keine Benchmark-Zahlen zu Startzeit, Speicherbedarf oder Testdurchsatz. Man sollte deshalb keine solchen Zahlen zitieren. Mehrere strukturelle Abwägungen stehen dagegen fest. Erstens macht die Hardwarebeschleunigung den Emulator nutzbar, doch jeder Container belegt weiterhin viel Speicher und CPU, und die parallele Skalierung ist durch die Host-Ressourcen begrenzt.
Zweitens sind die Images nach Android-Version getrennt, jedes ist groß, und Pulls und Caches müssen vorab geplant werden. Drittens ist ein Emulator kein echtes Telefon. Sensoren, herstellerspezifische Systeme und hardwareabhängiges Verhalten brauchen echte oder Cloud-Geräte. Deshalb bietet das Projekt die Anbindung an Genymotion Cloud.
Auswirkungen auf Entwickler und Unternehmen
Für Einzelentwickler liegt der Wert in einer wegwerfbaren Umgebung: Der Rechner bleibt sauber, und SDK-Versionskonflikte entfallen. Für Teams fixieren Image-Tags die Version, sodass lokale Läufe, Continuous Integration und Cloud dieselbe Umgebung nutzen. Viele Diskussionen nach dem Muster bei mir läuft es entfallen. Das Projekt liefert außerdem Anwendungsdokumente für Jenkins, Cloud-Betrieb auf Azure, AWS und GCP, SMS-Simulation und Appium.
Die größere Bedeutung betrifft KI-Werkzeugketten. Bisher musste ein Mensch ein Gerät vorbereiten, wenn ein KI-Coding-Assistent eine mobile Änderung prüfen sollte. Erscheint der Emulator als MCP-Dienst, erhält der Assistent eine echte Laufzeit, die er aufrufen kann, und schließt den Kreis aus Code ändern, bauen, ausführen, beobachten und erneut ändern.
Grenzen und Ausblick
Es gibt vier Hauptgrenzen. Erstens ist KVM Pflicht; auf gewöhnlichen Cloud-Hosts ohne verschachtelte Virtualisierung oder in Container-Setups auf Apple-Silizium läuft das Image nicht direkt. Zweitens sind MCP und der Agent noch Beta, Schnittstellen und Verhalten können sich ändern, und die Nichtdeterminiertheit der Modelle macht sie vorerst ungeeignet als einziges Regressionskriterium. Drittens spiegelt die Geräteliste ältere Profile wider, neuere Bildschirmformate müssen von Hand konfiguriert werden. Viertens kann ein Emulator ein echtes Telefon nicht vollständig ersetzen.
Für die Zukunft sind mehr Android-Versionen und Geräte, stabilere MCP-Werkzeugdefinitionen, bessere Unterstützung multimodaler lokaler Modelle und engere Verbindungen zu Cloud-Gerätefarmen zu erwarten. Teams, die mobile Automatisierung prüfen, fahren realistisch so: zuerst Builds und routinemäßige UI-Tests damit abwickeln, den KI-Agenten getrennt erproben und deterministische Prüfungen in klassischen Skripten behalten.