HQarroum/docker-android: der Android-Emulator als Docker-Dienst

Ein minimalistisches, anpassbares Image, das den offiziellen Android-Emulator in einem Container ausführt, über das Netzwerk per ADB steuerbar, gedacht für Testfarmen in Continuous-Integration-Umgebungen. Stand 4. September 2026 hat das Projekt 7.260 Sterne.

Was docker-android ist

docker-android von Halim Qarroum (HQarroum) ist ein Docker-Image, das den offiziellen Android-Emulator in einen Netzwerkdienst verwandelt. Es ist kein neuer Emulator und keine QEMU-Neuimplementierung: Es verpackt Googles Emulator (Ranchu) mit seinem SDK, einem ADB-Server und KVM-Beschleunigungsunterstützung in einem minimalen Image, das ohne Fenster, ohne Ton und ohne Snapshots startet und den Emulator über die Ports 5555 (ADB) und 5554 (Emulator-Konsole, mit socat weitergeleitet) bereitstellt.

Das im README erklärte Ziel ist die Größenoptimierung: Das Image enthält nur das Nötigste, um einen voll funktionsfähigen, aus der Ferne steuerbaren Emulator bereitzustellen. Das README dokumentiert Build-Varianten ohne SDK und Emulator (414 MB unkomprimiert) bis hin zur vollständigen API-33-Konfiguration mit Emulator (5,84 GB unkomprimiert, 1,97 GB komprimiert). Der Emulator läuft im Headless-Modus, ist mit scrcpy kompatibel, um den Bildschirm aus der Ferne zu steuern, und laut README selbst werden die Emulator-Images bei jedem Neustart gelöscht — ein Verhalten, das für CI-Farmen gedacht ist, in denen jeder Lauf von einem sauberen Zustand ausgeht.

Es lohnt sich, von Anfang an zu unterscheiden: Der Name stimmt mit budtmo/docker-android überein (2016, 15.810 Sterne), einem älteren und populäreren Projekt, das eine WebRTC/noVNC-Oberfläche, Videoaufzeichnung und einen MCP-Server bietet. Das sind zwei unabhängige, nicht verwandte Projekte; dieser Bericht behandelt ausschließlich HQarroum/docker-android, das das README selbst in seinem Abschnitt „See also” zitiert.

Der Ursprung

Das Repository wurde am 8. Februar 2023 von Halim Qarroum erstellt, dessen GitHub-Profil angibt, dass er den Bereich Prototyping und Cloud Engineering bei AWS leitet („Leading Prototyping and Cloud Engineering @aws”) und dessen persönlicher Blog (halim.qarroum.com, ein Medium-Profil) über AWS IoT, SSM und Infrastruktur veröffentlicht, ohne dass in dieser Recherche eine spezifische Launch-Ankündigung für dieses Projekt gefunden werden konnte.

Die Chronologie platziert den Launch mitten in der Reifephase des Ökosystems der Container-Emulatoren: budtmo/docker-android (2016), thyrlian/AndroidSDK (2016), alvr/alpine-android (2017) und die offiziellen Google-Skripte android-emulator-container-scripts (2019) existierten bereits. Qarroums Ansatz war es, sich durch Minimalismus, Build-Zeit-Anpassung und die Verteilung vorkompilierter Images zu differenzieren, statt durch eine visuelle Oberfläche.

Die Aktivität des Repositorys zeigt eine anhaltende, aber unregelmäßige Wartung: Der letzte Code-Push stammt vom 7. Mai 2026 und behob genau die am häufigsten genannten Community-Probleme — den Fehlschlag des SDK-Installationsskripts (Issue #10, über Pull Request #31 von italks) und die Fehlermeldung, wenn KVM nicht verfügbar ist. Es wurden keine Launch-Threads auf Hacker News oder Twitter/X gefunden, die dem Autor zugeschrieben werden; das Wachstum stützt sich auf GitHub, Docker Hub und Video-Berichterstattung Dritter.

Philosophie und Prinzipien

README und Code bestätigen vier Prinzipien:

Minimalismus und Größe: Das Image enthält nur den Emulator, den ADB-Server und QEMU mit libvirt/KVM-Unterstützung. Das Argument INSTALL_ANDROID_SDK=0 erlaubt es, das SDK von einem gemeinsam genutzten Dateisystem (z. B. NFS) einzubinden und das Image auf 138 MB komprimiert zu reduzieren.
Emulator als Dienst: Der Wert liegt im Fernzugriff. ADB lauscht auf allen Schnittstellen des Containers, socat leitet die Ports 5554 und 5555 von der Netzwerkschnittstelle des Containers nach localhost weiter, und der Status wird beim Start über JSON-Zeilen kommuniziert (ANDROID_BOOTING, ANDROID_READY, ANDROID_STOPPED).
Build-Zeit-Anpassung: API-Level, Image-Typ (Google APIs oder Play Store), Architektur und Version der Kommandozeilen-Tools werden mit Build-Argumenten festgelegt, explizit gedacht, um „mehrere Images als Teil einer CI-Pipeline zu integrieren, bei der eine Anwendung gegen verschiedene Android-Versionen getestet werden muss”.
Reproduzierbarkeit und sauberer Zustand: Vorkompilierte, nach Variante getaggte Images auf Docker Hub und Löschung der Emulator-Daten bei jedem Neustart, sofern kein persistentes Volume unter /data gemountet wird.

Wie es funktioniert

Das aktuelle Image basiert auf eclipse-temurin:25 (die GPU-Variante auf nvidia/cuda:12.3.1-base-ubuntu22.04 mit openjdk-18-jre-headless). Hinweis: Das README behauptet, das Image sei „Alpine-basiert” und enthalte „Java Runtime Environment 11”; diese Beschreibung entspricht nicht dem aktuellen Dockerfile, das im Commit vom 6. Mai 2026 auf Temurin JDK 25 umgestellt wurde („move from openjdk to eclipse-temurin image”). Das README ist an dieser Stelle veraltet.

Der in scripts/start-emulator.sh dokumentierte Boot-Ablauf:

Startet den ADB-Server auf Port 5037, lauschend auf allen Schnittstellen (adb -a -P 5037 server nodaemon).
Ermittelt die IP der eth0-Schnittstelle und startet zwei socat-Prozesse, die die Ports 5554 (Konsole) und 5555 (ADB) von der IP des Containers nach localhost weiterleiten.
Erstellt das AVD android mit avdmanager, falls es nicht existiert, unter Verwendung des Pakets system-images;android-<API_LEVEL>;<IMG_TYPE>;<ARCHITECTURE> und des Geräts pixel (Preset 1080x1920).
Falls GPU_ACCELERATED=true, startet es Xvfb unter :0.0 (1920x1080x16) und setzt GPU_MODE=host; andernfalls wird swiftshader_indirect (Software-Rendering) verwendet.
Startet den Emulator mit -no-window -no-snapshot -no-boot-anim -ranchu und optional -skip-adb-auth; Speicher, Kerne und zusätzliche Flags werden aus den Variablen MEMORY, CORES und EXTRA_FLAGS übernommen.
Parallel wartet emulator-monitoring.sh, bis sys.boot_completed den Wert 1 annimmt (mit einem Limit von 300 Sekunden), wendet optional die Entsperrung von Animationen und der Hidden-API-Richtlinie an und gibt den Status ANDROID_READY aus.

Das AVD-Verzeichnis ist /data (ANDROID_AVD_HOME), daher bewahrt das Mounten eines Volumes dort die Daten über Neustarts hinweg — ein Verhalten, das das README im Abschnitt „Save data/storage after restart (wipe)” dokumentiert.

Offizieller und halboffizieller Status

docker-android ist ein persönliches Projekt, veröffentlicht unter der MIT-Lizenz; es gibt keine Zertifizierung durch einen Anbieter und keine Aufnahme in einen offiziellen Marktplatz, und es sollte nicht mit google/android-emulator-container-scripts (2.077 Sterne) verwechselt werden, das tatsächlich Googles eigenes Skript-Set zum Ausführen des Emulators im Container ist.

Sein halboffizieller Status stützt sich auf drei verifizierbare Säulen: die offizielle Verteilung vorkompilierter Images auf Docker Hub (halimqarroum/docker-android, mit Tags nach API-Level und Variante) und öffentliche CI (GitHub Actions mit den Workflows docker-image.yml und docker-feature.yml, plus statischer Analyse von DeepSource). In der Praxis fungiert es als eine der De-facto-Referenzen der Nische „Android-Emulator in Docker” für Headless-Automatisierung, auch wenn das gleichnamige Projekt mit mehr Adoption (budtmo/docker-android) es bei Sternen und Oberflächenfunktionen übertrifft.

Das Ökosystem

Repositorys des Autors

Das Profil von HQarroum (385 GitHub-Follower zum Zeitpunkt der Abfrage) zeigt einen Katalog, in dem docker-android das nach Sternen herausragendste Projekt ist:

HQarroum/awesome-iot: eine kuratierte Liste von Internet-der-Dinge-Projekten und -Ressourcen; 4.496 Sterne.
HQarroum/microbox: leichtgewichtige, kurzlebige Sandboxes für Linux; 47 Sterne (2025 auch als Show HN mit 3 Punkten veröffentlicht).
HQarroum/android-mdns: Apples mDNS-Protokoll auf Android; 46 Sterne.
HQarroum/timed-cache: ein zeitbasiertes Caching-System; 45 Sterne.
HQarroum/ultimate-aws-workspace: ein latenzarmer Cloud-Desktop auf AWS EC2; 27 Sterne.
HQarroum/writing-typescript: ein TypeScript-Code-Leitfaden, verpackt als Agenten-Skill; 1 Stern.

Ergänzungen und verwandte Projekte

Genymobile/scrcpy (148.844 Sterne): die im README dokumentierte natürliche Ergänzung, um den Bildschirm des Emulators aus der Ferne anzuzeigen und zu steuern, sobald ADB verbunden ist.
budtmo/docker-android (15.810 Sterne): das ältere gleichnamige Projekt; noVNC, Videoaufzeichnung und ein MCP-Server. In der Community wiederholt erwähnt (siehe unten) und im „See also” dieses Repositorys zitiert.
alvr/alpine-android (460 Sterne): ein minimales Image zum Kompilieren und Testen von Android-Anwendungen, ebenfalls im „See also” zitiert.
Shmayro/dockerify-android (625 Sterne, erstellt im Oktober 2024): ein Emulator in Docker mit Unterstützung für x86 und arm64, Magisk und Web-Zugriff auf scrcpy; sein Tag docker-android platziert es in derselben Nische und deckt genau die ARM-Architektur-Lücke dieses Repositorys ab.
hoangnd24/docker-android-emulator-cluster (121 Sterne, 2026): ein Cluster von Android-Containern mit noVNC und Videoaufzeichnung; ein aktuelles verwandtes Projekt derselben Nische.
agoda-com/docker-emulator-android (257) und agoda-com/android-farm (176): Agodas Geräte-Farm-Infrastruktur, Referenzen für die Unternehmensadoption des Musters.

Was Forks und Community-Erweiterungen dieses Repositorys angeht, ist die sichtbare Aktivität zum Zeitpunkt der Abfrage der offene Pull Request #32 („Add noVNC browser access and update documentation”) und Feature-Anfragen in Issues (WebRTC #13, Magisk-Unterstützung #11, Android TV #27, Kombination mit Appium #16), ohne nach Sternen herausragende Forks, die in dieser Recherche einzeln verifiziert werden konnten.

Schnellstart-Anleitung

Installation und erster Start

Voraussetzungen: ein Linux-Host mit verfügbarem KVM-Gerät (/dev/kvm, VT-x/AMD-V-Virtualisierung im BIOS aktiviert und Kernel-Modul geladen), Docker installiert und, laut README, 4 GB Speicher und mindestens 8 GB Festplatte für die API-33-Variante. Es gibt keine Apple-Silicon-Unterstützung: Das README warnt, dass nur x86_64 und x86 „aktiv unterstützt” werden.

Option A, mit dem vorkompilierten Docker-Hub-Image:

docker pull halimqarroum/docker-android:api-33
docker run -it --rm --device /dev/kvm -p 5555:5555 halimqarroum/docker-android:api-33

Option B, mit docker-compose (die Datei des Repositorys verwendet API 34, google_apis, mit Mount der ADB-Schlüssel und von /data):

docker compose up android-emulator
# GPU-Variante: docker compose up android-emulator-cuda
# GPU- und Google-Play-Store-Variante: docker compose up android-emulator-cuda-store

Option C, das Image selbst bauen (beim ersten Mal wird das SDK heruntergeladen, was eine Weile dauert):

docker build -t android-emulator .
docker build --build-arg API_LEVEL=28 --build-arg IMG_TYPE=google_apis_playstore --build-arg ARCHITECTURE=x86 -t android-emulator .

Beim ersten Start zeigt das Log die Erstellung des AVD und den Start des Emulators; wenn der Android-Kernel fertig gebootet hat, gibt die Ausgabe die JSON-Zeile {"type": "state-update", "value": "ANDROID_READY"} aus. Ab diesem Zeitpunkt, vom Host aus:

adb connect 127.0.0.1:5555

Gängige Workflows

Eine App gegen mehrere Android-Versionen in CI testen: ein Image pro Version bauen (--build-arg API_LEVEL=28/29/30/31/32/33) oder die vorkompilierten Tags ziehen (api-28, api-33 usw.); bei jedem Pipeline-Schritt den Container starten, auf ANDROID_READY warten, adb connect 127.0.0.1:5555 ausführen und die instrumentierten Tests starten. Das Löschen des Emulators bei jedem Neustart garantiert, dass jede Version sauber startet.
Den Bildschirm mit scrcpy anzeigen und steuern: adb connect 127.0.0.1:5555 und lokal scrcpy; das Standard-Preset ist ein Pixel mit 1080x1920.
Die Variante mit Google Play Store verwenden: den Tag api-33-playstore bauen oder ziehen und denselben ADB-Schlüssel zwischen Client und Emulator teilen: mit adb keygen adbkey generieren (erzeugt adbkey und adbkey.pub) und diese beiden Dateien vor dem Build in das Verzeichnis ./keys des Projekts kopieren.
Daten über Neustarts hinweg bewahren: docker run -it --rm --device /dev/kvm -p 5555:5555 -v ~/android_avd:/data android-emulator; das AVD (Name android) lebt in /data, ohne das Volume geht es beim Neustart verloren.
Gemeinsam genutztes externes SDK (NFS): docker build -t android-emulator --build-arg INSTALL_ANDROID_SDK=0 . und beim Start -v /shared/android/sdk:/opt/android/.

Wesentliche Konfiguration

API_LEVEL (Build-Argument, Standard 33 im Dockerfile und 34 in docker-compose): das zu installierende Android-API-Level.
IMG_TYPE (Build-Argument, Standard google_apis): der Typ des Systemimages; google_apis_playstore, um den Store einzuschließen.
MEMORY und CORES (Umgebungsvariablen, Standard 8192 und 4): Speicher und Kerne des Emulators; das docker-compose des Repositorys erhöht sie auf 16384 und 16.
SKIP_AUTH (Umgebungsvariable, Standard true): fügt dem Emulator -skip-adb-auth hinzu; das Deaktivieren bedeutet, ADB-Schlüssel selbst zu verwalten.
keys/adbkey und keys/adbkey.pub: gemountet unter /root/.android/; in der Praxis für die Play-Store-Variante erforderlich.

Häufige Fallstricke und Lösungen

„x86_64 emulation currently requires hardware acceleration! /dev/kvm is not found”: Virtualisierung im BIOS deaktiviert oder KVM-Modul nicht geladen; der Commit vom 7. Mai 2026 (fc1d197d) verbesserte diese Fehlermeldung. Auf Apple-Silicon-Maschinen gibt es keine Lösung: Die Emulation erfordert KVM mit einer x86-CPU (Issues #21 und #29; Nutzer ansidev erinnert daran, dass „nur x86_64 und x86 aktiv unterstützt werden”).
„Device Unauthorized” bei der Play-Store-Variante (Issue #2, offen seit November 2023, 7 Kommentare): ADB und scrcpy lehnen die Verbindung ab, weil der Schlüssel des Clients nicht mit dem des Emulators übereinstimmt. Die im Thread von Anyeos (Mai 2026) dokumentierte Lösung besteht darin, adbkey und adbkey.pub aus dem keys/-Verzeichnis des Repositorys nach ~/.android des Clients zu kopieren und adb kill-server auszuführen, um den ADB-Server neu zu starten.
„failed to solve: openjdk:18-jdk-slim: not found” (Issue #21): Das Basis-Java-Image existiert nicht mehr im Register; das Projekt wurde im Mai 2026 auf eclipse-temurin:25 migriert, daher löst eine Aktualisierung des Repositorys vor dem Build das Problem.
Teilweise veraltetes README: Es behauptet, das Image sei „Alpine” mit JRE 11, aber das aktuelle Dockerfile basiert auf eclipse-temurin:25 (JDK 25) und in der GPU-Variante auf CUDA mit openjdk-18; zudem gibt es „Current version: 1.1.0” an, während die Dockerfile-Tags 1.0.0 (CPU) und 1.2.0 (GPU) angeben und es keine formalen Releases auf GitHub gibt. Das Dockerfile als Quelle der Wahrheit betrachten.
Langer Build ohne klaren Fortschrittsindikator (Issue #12): Die Installation des SDK und des Systemimages kann lange dauern; Nutzer miamimanni steuerte Screenshots der erwarteten Phasen im Thread bei.
Leistung beim Software-Rendering: swiftshader_indirect ist zuverlässig, aber langsam für Canvas-intensive Apps; in Issue #28 schlägt Nutzer luoshixin93-sudo virglrenderer vor, mit Mount von --device /dev/dri:/dev/dri (ein Community-Vorschlag, keine offizielle Dokumentation), und schätzt den Kaltstart eines AVD in Docker auf 30 bis 60 Sekunden.
GPU-Varianten: erfordern die NVIDIA-Container-Laufzeitumgebung (der Dienst android-emulator-cuda reserviert driver: nvidia in deploy.resources); ohne GPU ist die CPU-Variante der richtige Weg.

Integrationen und Migration

ADB ist der universelle Integrationspunkt: Jedes Tool, das ADB spricht, funktioniert — instrumentierte Tests, Appium (es gibt ein Issue #16, das ein Appium-Beispiel neben dem Emulator in Docker anfordert), scrcpy, oder eigene Skripte, die die ANDROID_READY-Log-Zeile als Bereitschaftssignal beobachten.
CI/CD: Die eigenen Themen des Repositorys umfassen ci-pipeline; das dokumentierte Muster ist ein Image pro API-Level und das Warten auf den JSON-Status, bevor Tests ausgeführt werden.
Web-Oberfläche: nicht enthalten; der (nicht gemergte) Pull Request #32 fügt noVNC-Zugriff hinzu. Wer den Emulator lokal ohne scrcpy sehen muss, kann sich an budtmo/docker-android orientieren (noVNC und Video).
Migration vom lokalen Emulator von Android Studio: das Äquivalent ist docker compose up android-emulator und adb connect 127.0.0.1:5555 statt des lokalen Geräts; das AVD lebt fortan im Volume /data.
Migration zu Nachbarprojekten: zu budtmo/docker-android, falls Web-Oberfläche, Videoaufzeichnung oder MCP-Server benötigt werden; zu Shmayro/dockerify-android, falls ARM/arm64 oder Root via Magisk erforderlich ist; zu google/android-emulator-container-scripts, falls das minimale offizielle Skript von Google bevorzugt wird.

Repo-Kennzahlen

Messung: 4. September 2026, GitHub-API.

Kennzahl	Wert
Sterne	7.260
Forks	558
Abonnenten	36
Commits	59
Offene Issues laut API	15
Hauptsprache	Shell
Lizenz	MIT
Erstellt	8. Februar 2023
Letzter Code-Push	7. Mai 2026
Im README angegebene Version	1.1.0 (keine formalen Releases auf GitHub)
Docker-Hub-Downloads	45.939 (kumulierte Pulls)

Top-Contributor laut API, nach Anzahl der Beiträge: HQarroum (45), twocolors (5) und, mit je einem Beitrag, heralight, individual-it, KhaiTrang1995, miamimanni und saksham-45. Der Wert 59 wurde von der letzten Seite der Paginierung der Commits-API ermittelt. Vorbehalte: Die API verwendet open_issues_count, das offene Pull Requests einschließt (es gibt mindestens einen offenen PR, #32), daher ist es kein reiner Issue-Zähler; und watchers_count spiegelt die Sternezahl wider, daher die Verwendung von subscribers_count. Die 45.939 Docker-Hub-Downloads sind kumulativ seit der Erstellung des Registers, nicht für einen bestimmten Zeitraum.

Community-Resonanz

Es wurde kein diesem Repository gewidmeter Hacker-News-Thread gefunden (Suchen nach Projektname und Autor lieferten nur Erwähnungen anderer Projekte); die verifizierbare Resonanz lebt auf GitHub, Docker Hub, YouTube und in Kommentaren Dritter zu HN-Threads:

Im Thread 48556561 („How we run Firecracker VMs inside EC2 and start browsers in less than 1s”, ein Artikel von browser-use, 322 Punkte, 16. Juni 2026) berichtete Nutzer sandGorgon (Kommentar 48576076), dass sie Reinforcement-Learning-(RL)-Workloads mit Android-Browsern betreiben und „gezwungen waren, einen Fork” von budtmo/docker-android mit Chrome darauf zu pflegen — ein Zeichen echter Nachfrage nach dieser Art von Infrastruktur, wenn auch auf das gleichnamige Projekt gerichtet.
Im Thread 42057903 („All the data can be yours: reverse engineering APIs”, 595 Punkte, November 2024) empfahl SeriousStorm (Kommentar 42111402) den Docker-Emulator als Reverse-Engineering-Tool und zitierte dabei budtmo/docker-android.
In 30810410 („Running GUI apps within Docker containers”, 330 Punkte, 2022) kritisierte 999900000999 (Kommentar 30810620) eine Klausel in der Lizenz von budtmo/docker-android, die anonymisierte IP-Daten von Nutzern sammelte — ein Vertrauenseinwand gegen das gleichnamige Projekt, nicht gegen dieses.
Auf GitHub ist Issue #2 (7 Kommentare, offen seit November 2023) der aktivste technische Thread: der Fehler „Device Unauthorized” mit Play Store, mit der von Anyeos im Mai 2026 dokumentierten ADB-Schlüssel-Lösung. Issue #21 (4 Kommentare) dokumentiert den Fehlschlag des Java-Basisimages und die Inkompatibilität mit Apple Silicon. In #28 schrieb luoshixin93-sudo „Solid Docker Android setup” und steuerte Leistungstipps bei (virglrenderer, Kaltstart von 30-60 Sekunden, Pool vorgewärmter AVDs). Die Community-Anfragen zielen auf ARM (#35), Android TV (#27), noVNC (#32), WebRTC (#13), Magisk (#11) und Appium (#16).
Auf YouTube veröffentlichte der Kanal LaurieWired „Easy Android Emulator in Docker” (Video SWin67TZ4AY) und „Choosing an Android Emulator for Malware Reversing, Development, and More!” (jjf96PuCONA); Tech on Fire veröffentlichte „Run Android in a Docker Container!” (a1M40roHuRg) und Novaspirit Tech „Run Android In Docker with this Container!” (GTtdTksS6L0). Der Kanal „GitHub Daily Trend AI Podcast” hat eine diesem Repository gewidmete Folge (0VNwEKacAIU). Aufrufe konnten aus dieser Umgebung nicht verifiziert werden.
Der Zugriff auf Reddit wurde aus dieser Umgebung blockiert, daher gibt es keine verifizierbaren Daten von diesem Kanal.

Es gibt keinen dokumentierten Beitragsprozess (kein CONTRIBUTING.md existiert); die Entwicklung wird vom Autor geführt (45 von 59 Commits), und die Community hat gelegentliche Patches beigesteuert, wie Pull Request #31 von italks (gemergt am 7. Mai 2026, behebt Issue #10) oder #32 (noVNC, ausstehend).

docker-android im Vergleich zu anderen Vorschlägen

Projekt	Verifizierbare Überschneidung	Verifizierbarer Unterschied
`budtmo/docker-android` (15.810 Sterne)	Android-Emulator in Docker, ADB, gemeinsames Thema `docker-android`	Fügt eine noVNC/WebRTC-Oberfläche, Videoaufzeichnung und einen MCP-Server hinzu; älter (2016) und mit einer Lizenz, die mehrere HN-Nutzer wegen Datensammlung kritisierten.
`google/android-emulator-container-scripts` (2.077 Sterne)	Googles offizielle minimale Skripte zum Ausführen des Emulators im Container	Ein generisches Skript-Set für verschiedene Systeme, kein vorkompiliertes Image oder Dienst mit exponiertem ADB.
`aind-containers/aind` (1.488 Sterne)	„Android in Docker”	Beschreibt sich selbst als „Ain’t an emulator”; ein anderer Verpackungsansatz.
`thyrlian/AndroidSDK` (1.385 Sterne)	Ein Docker-Image mit dem vollständigen Android-SDK	Fokussiert auf das SDK für Entwicklung und Build-Tests, nicht auf einen über das Netzwerk exponierten headless Emulator.
`sickcodes/dock-droid` (1.376 Sterne)	Android in Docker für CI	Verwendet QEMU statt des offiziellen Emulators, mit X11-Weiterleitung (2021).
`Shmayro/dockerify-android` (625 Sterne)	Emulator in Docker, ADB, scrcpy, gemeinsames Thema `docker-android`	Unterstützt x86 und arm64, Magisk und Play Store mit Web-Zugriff auf scrcpy (2024); deckt die ARM-Lücke dieses Repositorys ab.
`alvr/alpine-android` (460 Sterne)	Ein minimales Image zum Bauen und Testen von Android-Apps	Ausgerichtet auf Build/Test von Anwendungen, nicht auf einen entfernten Emulator.
`Genymobile/scrcpy` (148.844 Sterne)	Steuert Android aus der Ferne	Eine Ergänzung, kein Konkurrent: das vom README empfohlene Tool zum Anzeigen des Bildschirms.

Der nützlichste Vergleich erfolgt nach Bedarfsprofil: docker-android (HQarroum) sticht hervor durch Minimalismus, vorkompilierte Images nach API-Level und Standardlöschung; budtmo, wenn Web-Oberfläche, Video oder MCP benötigt werden; dockerify-android, wenn ARM erforderlich ist; und die Google-Skripte, wenn man etwas vom Anbieter selbst möchte.

Anwendungsfälle und wem dieses Repository helfen kann

QA-Teams und Automatisierung von Android-Apps: Die Kombination aus vorkompilierten Images nach API-Level (Tags api-28 bis api-33, mit und ohne Play Store, mit und ohne CUDA), dem Boot-JSON-Status (ANDROID_READY) und der Standardlöschung passt zu einer Pipeline, die denselben sauberen Emulator gegen mehrere Android-Versionen ausführen muss, mit ADB als einzigem Vertrag nach außen.
Malware-Analysten und Reverse Engineers: Die Video-Berichterstattung von LaurieWired über die Wahl eines Android-Emulators für „Malware Reversing, Development, and More!” und die Empfehlung eines Docker-Emulators im HN-Thread über Reverse Engineering von APIs (595 Punkte) kennzeichnen diese Art von Container als reproduzierbare Sandbox zur Analyse von Apps fragwürdiger Herkunft, ohne die eigene Ausrüstung anzufassen.
Forschende, die Agenten und RL-Workloads auf Android trainieren oder evaluieren: Der Kommentar von sandGorgon im browser-use-Thread (322 Punkte) beschreibt genau diesen Fall — containerisierte Android-Emulator-Infrastruktur für RL-Workloads pflegen, die Browser steuern — und dieses Repository, oder sein gleichnamiges Gegenstück, ist die Grundlage dieser Infrastruktur.
Entwickler ohne Zugang zu Android Studio oder physischen Geräten: docker pull + adb connect 127.0.0.1:5555 + scrcpy ergeben eine komplette Android-Maschine mit steuerbarem Bildschirm in ein paar Befehlen, solange der Host x86 mit KVM ist.
Teams mit dem SDK auf gemeinsam genutztem Speicher: Das Argument INSTALL_ANDROID_SDK=0 mit Mount des SDK unter /opt/android (z. B. NFS) reduziert die Image-Größe auf 138 MB komprimiert und verkürzt die Build-Zeit — ein im README explizit dokumentierter Anwendungsfall.
Wer Android TV, ARM, Magisk oder noVNC benötigt: Dieses Repository deckt das nicht ab (Issues #27, #29, #11, #32 offen); die verifizierbare Alternative in derselben Nische ist Shmayro/dockerify-android (arm64 und Magisk) oder budtmo/docker-android (noVNC und Video).

Ressourcen

Repository: https://github.com/HQarroum/docker-android
Dokumentation: das README des Repositorys (Abschnitte Usage, Keys, Customize the image, Variables): https://github.com/HQarroum/docker-android#usage
Vorkompilierte Images (Docker Hub): https://hub.docker.com/r/halimqarroum/docker-android
Referenzskripte und Dockerfiles: Dockerfile, Dockerfile.gpu, scripts/start-emulator.sh, scripts/emulator-monitoring.sh, scripts/install-sdk.sh, docker-compose.yml
GitHub-Wiki: https://github.com/HQarroum/docker-android/wiki
Öffentliche CI: https://github.com/HQarroum/docker-android/actions (Workflows docker-image.yml und docker-feature.yml); im README verlinkte DeepSource-Analyse
Empfohlene offizielle Ergänzung: scrcpy — https://github.com/Genymobile/scrcpy
Videos: „Easy Android Emulator in Docker” (LaurieWired) https://www.youtube.com/watch?v=SWin67TZ4AY; „Choosing an Android Emulator for Malware Reversing, Development, and More!” (LaurieWired) https://www.youtube.com/watch?v=jjf96PuCONA; „Run Android in a Docker Container!” (Tech on Fire) https://www.youtube.com/watch?v=a1M40roHuRg; „Run Android In Docker with this Container!” (Novaspirit Tech) https://www.youtube.com/watch?v=GTtdTksS6L0; Folge „GitHub - HQarroum/docker-android” (GitHub Daily Trend AI Podcast) https://www.youtube.com/watch?v=0VNwEKacAIU
HN-Threads mit relevanten Erwähnungen: https://news.ycombinator.com/item?id=48576076 (RL + Android-Browser), https://news.ycombinator.com/item?id=42111402 (Reverse Engineering), https://news.ycombinator.com/item?id=30810620 (Kritik an der Lizenz des gleichnamigen Projekts)
Paketregister: nicht auf npm, PyPI oder crates.io veröffentlicht; die Verteilung erfolgt über Docker Hub (45.939 Pulls zum Messzeitpunkt)
Blog des Autors: https://halim.qarroum.com (ein Medium-Profil; es wurde kein spezifischer Beitrag zu diesem Projekt gefunden)
Community: kein Discord oder dedizierter Kanal; Discussions deaktiviert; der effektive Support-Kanal sind GitHub Issues

Methodischer Hinweis: Dieser Artikel stützt sich auf das README, die Dockerfiles und Skripte des Repositorys, die GitHub-API, Docker Hub, das Profil des Autors und Suchen auf Hacker News, YouTube und GitHub, konsultiert am 4. September 2026. Zahlen ändern sich mit der Zeit; Hacker-News-Erwähnungen zu „docker-android” beziehen sich größtenteils auf das gleichnamige Projekt budtmo/docker-android und wurden entsprechend gekennzeichnet.