25 de septiembre de 2026
ES
05 de septiembre de 2026 · Por YasKad
HQarroum/docker-android

HQarroum/docker-android: el emulador de Android como servicio en Docker

HQarroum/docker-android · 7.285★ · 562 forks

Una imagen minimalista y personalizable que ejecuta el emulador oficial de Android dentro de un contenedor, controlable desde la red mediante ADB, pensada para granjas de pruebas en entornos de integración continua. A 4 de septiembre de 2026 lleva 7.260 estrellas.

Qué es docker-android

docker-android, de Halim Qarroum (HQarroum), es una imagen de Docker que convierte el emulador oficial de Android en un servicio de red. No es un emulador nuevo ni una reimplementación de QEMU: empaqueta el emulador de Google (Ranchu) con su SDK, un servidor ADB y el soporte de aceleración KVM en una imagen mínima que arranca sin ventana, sin audio y sin snapshots, y expone el emulador por los puertos 5555 (ADB) y 5554 (consola del emulador, reenviada con socat).

El objetivo declarado en el README es la optimización de tamaño: la imagen contiene únicamente lo necesario para exponer un emulador plenamente funcional y controlable a distancia. El README documenta variantes de compilación sin SDK ni emulador (414 MB sin comprimir) hasta la configuración completa API 33 con emulador (5,84 GB sin comprimir, 1,97 GB comprimido). El emulador se ejecuta en modo headless, es compatible con scrcpy para controlar la pantalla a distancia y, según el propio README, las imágenes del emulador se borran en cada reinicio, un comportamiento pensado para granjas de CI donde cada ejecución parte de un estado limpio.

Conviene desambiguar desde el principio: el nombre coincide con budtmo/docker-android (2016, 15.810 estrellas), un proyecto anterior y más popular que ofrece interfaz WebRTC/noVNC, grabación de vídeo y servidor MCP. Son dos proyectos independientes sin relación entre sí; este informe trata exclusivamente de HQarroum/docker-android, que el propio README cita en su sección «See also».

El origen

El repositorio fue creado el 8 de febrero de 2023 por Halim Qarroum, cuyo perfil de GitHub indica que dirige el área de prototipado e ingeniería de nube en AWS («Leading Prototyping and Cloud Engineering @aws») y cuyo blog personal (halim.qarroum.com, perfil de Medium) publica sobre AWS IoT, SSM e infraestructura, sin un anuncio de lanzamiento específico de este proyecto que haya sido posible recuperar en esta investigación.

La cronología situó el lanzamiento en plena maduración del ecosistema de emuladores en contenedor: ya existían budtmo/docker-android (2016), thyrlian/AndroidSDK (2016), alvr/alpine-android (2017) y los scripts oficiales de Google android-emulator-container-scripts (2019). La apuesta de Qarroum fue diferenciarse por la minimalidad, la personalización en tiempo de compilación y la distribución de imágenes precompiladas, en lugar de por la interfaz visual.

La actividad del repositorio muestra un mantenimiento sostenido a paso irregular: la última empujada de código es del 7 de mayo de 2026 y corrigió precisamente los problemas más citados de la comunidad —el fallo del script de instalación del SDK (incidencia #10, a través de la solicitud de cambios #31 de italks) y el mensaje de error cuando KVM no está disponible. No se encontraron hilos de lanzamiento en Hacker News ni en Twitter/X atribuidos al autor; su crecimiento se apoya en GitHub, Docker Hub y la cobertura de vídeo de terceros.

Filosofía y principios

El README y el código verifican cuatro principios:

  • Minimalismo y tamaño: la imagen solo incluye el emulador, el servidor ADB y QEMU con soporte de libvirt/KVM. El argumento INSTALL_ANDROID_SDK=0 permite montar el SDK desde un sistema de ficheros compartido (por ejemplo NFS) y reducir la imagen a 138 MB comprimidos.
  • Emulador como servicio: el valor es el acceso remoto. ADB escucha en todas las interfaces del contenedor, socat reenvía los puertos 5554 y 5555 desde la interfaz de red del contenedor hacia localhost, y el estado se comunica al inicio mediante líneas JSON (ANDROID_BOOTING, ANDROID_READY, ANDROID_STOPPED).
  • Personalización en tiempo de compilación: nivel de API, tipo de imagen (Google APIs o Play Store), arquitectura y versión de las herramientas de línea de comando se fijan con argumentos de compilación, pensado explícitamente para «integrar varias imágenes como parte de un pipeline de CI donde una aplicación necesita probarse contra diferentes versiones de Android».
  • Reproducibilidad y estado limpio: imágenes precompiladas etiquetadas por variante en Docker Hub y borrado de los datos del emulador en cada reinicio, salvo que se monte un volumen persistente en /data.

Una visualización isométrica detallada de una imagen mínima de Docker para emulación Android, mostrada como un cubo brillante flotando sobre una superficie oscura reflectante, en capas translúcidas: una capa base delgada etiquetada con Java runtime, una capa de servidor ADB, un núcleo de emulador compacto y un pequeño módulo de aceleración KVM, con anillos de medición flotantes mostrando conceptos de tamaño como 138 MB, 414 MB y 5,84 GB

Cómo funciona

La imagen actual se basa en eclipse-temurin:25 (la variante GPU en nvidia/cuda:12.3.1-base-ubuntu22.04 con openjdk-18-jre-headless). Nota: el README afirma que la imagen es «basada en Alpine» e incluye «Java Runtime Environment 11»; esa descripción no corresponde al Dockerfile actual, que se cambió a Temurin JDK 25 en el commit del 6 de mayo de 2026 («move from openjdk to eclipse-temurin image»). El README está desactualizado en ese punto.

El flujo de arranque documentado en scripts/start-emulator.sh:

  1. Arranca el servidor ADB en el puerto 5037 escuchando en todas las interfaces (adb -a -P 5037 server nodaemon).
  2. Detecta la IP de la interfaz eth0 y levanta dos socat que reenvían los puertos 5554 (consola) y 5555 (ADB) desde la IP del contenedor a localhost.
  3. Crea el AVD android con avdmanager si no existe, usando el paquete system-images;android-<API_LEVEL>;<IMG_TYPE>;<ARCHITECTURE> y el dispositivo pixel (preset 1080x1920).
  4. Si GPU_ACCELERATED=true, levanta Xvfb en :0.0 (1920x1080x16) y fija GPU_MODE=host; en caso contrario usa swiftshader_indirect (renderizado por software).
  5. Lanza el emulador con -no-window -no-snapshot -no-boot-anim -ranchu y, opcionalmente, -skip-adb-auth; la memoria, los núcleos y flags extra se toman de las variables MEMORY, CORES y EXTRA_FLAGS.
  6. En paralelo, emulator-monitoring.sh espera a que sys.boot_completed valga 1 (con un límite de 300 segundos), aplica opcionalmente el desbloqueo de animaciones y de la política de API ocultas, y emite el estado ANDROID_READY.

Una escena de sala de control oscura enfocada en el control remoto ADB de un contenedor de emulador Android headless, en primer plano un terminal futurista muestra una secuencia de comandos brillante para adb connect, con finas líneas neón de reenvío de puertos pasando por un relé socat desde eth0 a localhost, dos puertos de red brillantes resaltados: 5555 para ADB y 5554 para la consola del emulador, un pequeño feed de estado JSON flotando junto al terminal mostrando actualizaciones de estado como ANDROID_BOOTING, ANDROID_READY y ANDROID_STOPPED

El directorio del AVD es /data (ANDROID_AVD_HOME), por lo que montar un volumen ahí preserva los datos entre reinicios, comportamiento que el README documenta en la sección «Save data/storage after restart (wipe)».

Un mecanismo de reinicio a estado limpio para un contenedor de emulador Android, visualizado como una cámara circular de borrado de datos, una silueta de dispositivo Android headless se sitúa en el centro, rodeada por un anillo brillante de borrado que elimina estado temporal, cachés y snapshots en cada reinicio, a un lado un volumen persistente opcional etiquetado /data se extiende hacia afuera como una cápsula de almacenamiento oscura y segura, mientras la ruta por defecto permanece limpia y reproducible, pequeñas banderas flotantes muestran no-window, no-snapshot y no-boot-anim como chips neón minimalistas

Estado oficial y semioficial

docker-android es un proyecto personal publicado bajo licencia MIT; no existe certificación de ningún vendor ni aceptación en un marketplace oficial, y no debe confundirse con google/android-emulator-container-scripts (2.077 estrellas), que sí es el set de scripts de Google para ejecutar el emulador en contenedor.

Su estatus semioficial se apoya en tres pilares verificables: la distribución oficial de imágenes precompiladas en Docker Hub (halimqarroum/docker-android, con etiquetas por nivel de API y variante) y el CI público (GitHub Actions con los flujos docker-image.yml y docker-feature.yml, más análisis estático de DeepSource). En la práctica funciona como una de las referencias de facto del nicho «emulador Android en Docker» para automatización headless, aunque el proyecto con más adopción del mismo nombre (budtmo/docker-android) lo supera en estrellas y en funciones de interfaz.

El ecosistema

Repositorios del autor

El perfil de HQarroum (385 seguidores de GitHub al consultar) muestra un catálogo donde docker-android es el proyecto más destacado por estrellas:

  • HQarroum/awesome-iot: lista curada de proyectos y recursos de Internet de las Cosas; 4.496 estrellas.
  • HQarroum/microbox: «sandboxes» ligeros y efímeros para Linux; 47 estrellas (publicado también como Show HN con 3 puntos en 2025).
  • HQarroum/android-mdns: protocolo mDNS de Apple en Android; 46 estrellas.
  • HQarroum/timed-cache: sistema de caché por tiempo; 45 estrellas.
  • HQarroum/ultimate-aws-workspace: escritorio en la nube de baja latencia en AWS EC2; 27 estrellas.
  • HQarroum/writing-typescript: guía de código TypeScript empaquetada como habilidad de agente; 1 estrella.

Complementos y proyectos relacionados

  • Genymobile/scrcpy (148.844 estrellas): el complemento natural documentado en el README para ver y controlar la pantalla del emulador a distancia una vez conectado ADB.
  • budtmo/docker-android (15.810 estrellas): el homónimo anterior; noVNC, grabación de vídeo y servidor MCP. Mencionado repetidamente en la comunidad (ver más abajo) y citado en el «See also» de este repositorio.
  • alvr/alpine-android (460 estrellas): imagen mínima para compilar y probar aplicaciones Android, también citada en el «See also».
  • Shmayro/dockerify-android (625 estrellas, creado en octubre de 2024): emulador en Docker con soporte para x86 y arm64, Magisk y acceso Web a scrcpy; su etiqueta docker-android lo sitúa en el mismo nicho y cubre justo la carencia de arquitectura ARM de este repositorio.
  • hoangnd24/docker-android-emulator-cluster (121 estrellas, 2026): clúster de contenedores Android con noVNC y grabación de vídeo; proyecto relacionado reciente del mismo nicho.
  • agoda-com/docker-emulator-android (257) y agoda-com/android-farm (176): infraestructura de granjas de dispositivos de Agoda, referencias de adopción empresarial del patrón.

En cuanto a forks y extensiones de la comunidad de este repositorio, la actividad visible al consultar son la solicitud de cambios abierta #32 («Add noVNC browser access and update documentation») y las peticiones de funciones en incidencias (WebRTC #13, soporte Magisk #11, Android TV #27, combinación con Appium #16), sin forks destacados por estrellas que hayan sido posibles verificar individualmente en esta investigación.

Una visualización futurista de pipeline de CI para construir y probar imágenes de emulador Android en varios niveles de API, un pipeline central de construcción se ramifica en una matriz de tarjetas de contenedor brillantes, cada una representando un nivel de API, tipo de imagen y arquitectura diferentes, con etiquetas sutiles para API_LEVEL, IMG_TYPE, ARCHITECTURE y tags precompilados, algunas tarjetas muestran variantes de Google APIs, otras variantes de Play Store, y cada una se conecta a una instancia de emulador headless separada, renderizado como una red neuronal oscura de rutas neón con pulsos de éxito verdes

Guía rápida de uso

Instalación y primer arranque

Prerequisitos: un host Linux con el dispositivo KVM disponible (/dev/kvm, virtualización VT-x/AMD-V activada en la BIOS y módulo del kernel cargado), Docker instalado y, según el README, 4 GB de memoria y al menos 8 GB de disco para la variante API 33. No hay soporte para Apple Silicon: el README advierte que solo x86_64 y x86 están «activamente soportados».

Un entorno de servidor host Linux requerido para ejecutar un emulador Android en contenedor con aceleración KVM, la escena muestra un rack de servidor oscuro con un módulo de dispositivo /dev/kvm brillante, un chip de BIOS de virtualización etiquetado VT-x/AMD-V, y un núcleo de motor Docker conectado a un runtime de contenedor, indicadores de sistema flotantes muestran soporte x86_64, 4 GB de memoria, 8 GB de disco, y un contenedor Android headless arrancando desde el host, una silueta de advertencia sutil sugiere arquitectura Apple Silicon no soportada, renderizada como un chip atenuado fuera del límite principal del sistema

Opción A, con la imagen precompilada de Docker Hub:

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

Opción B, con docker-compose (el archivo del repositorio usa API 34, google_apis, montaje de las llaves ADB y de /data):

docker compose up android-emulator
# variante con GPU: docker compose up android-emulator-cuda
# variante con GPU y Google Play Store: docker compose up android-emulator-cuda-store

Opción C, construyendo la imagen (la primera vez descarga el SDK, lo que tarda bastante):

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 .

En el primer arranque el log muestra la creación del AVD y el arranque del emulador; cuando el kernel de Android termina de arrancar, la salida emite la línea JSON {"type": "state-update", "value": "ANDROID_READY"}. A partir de ese momento, desde el host:

adb connect 127.0.0.1:5555

Flujos de trabajo habituales

  • Probar una app contra varias versiones de Android en CI: compilar una imagen por versión (--build-arg API_LEVEL=28/29/30/31/32/33) o tirar de las etiquetas precompiladas (api-28, api-33, etc.); en cada paso del pipeline arrancar el contenedor, esperar a ANDROID_READY, ejecutar adb connect 127.0.0.1:5555 y lanzar las pruebas instrumentadas. El borrado del emulador en cada reinicio garantiza que cada versión arranca limpia.
  • Ver y controlar la pantalla con scrcpy: adb connect 127.0.0.1:5555 y, en local, scrcpy; el preset por defecto es un Pixel de 1080x1920.
  • Usar la variante con Google Play Store: construir o tirar de la etiqueta api-33-playstore y compartir la misma llave ADB entre cliente y emulador: generarla con adb keygen adbkey (produce adbkey y adbkey.pub) y copiar esos dos archivos al directorio ./keys del proyecto antes de compilar.
  • Preservar los datos entre reinicios: docker run -it --rm --device /dev/kvm -p 5555:5555 -v ~/android_avd:/data android-emulator; el AVD (nombre android) vive en /data y sin el volumen se pierde al reiniciar.
  • SDK externo compartido (NFS): docker build -t android-emulator --build-arg INSTALL_ANDROID_SDK=0 . y, al arrancar, -v /shared/android/sdk:/opt/android/.

Un concepto de espejado de pantalla remoto para controlar un emulador Android headless con scrcpy, un panel de pantalla Android brillante flota en un estudio oscuro, reflejado a través de un enlace de datos de baja latencia hacia un terminal de operador remoto, finos flujos neón de entrada táctil y de teclado entran al panel desde el lateral, mostrando control en tiempo real sin dispositivo físico, la ruta de conexión incluye un nodo de handshake ADB, un relé del puerto 5555 y un icono de proceso scrcpy compacto renderizado como un chip futurista

Configuración esencial

  • API_LEVEL (argumento de compilación, por defecto 33 en el Dockerfile y 34 en docker-compose): nivel de API de Android a instalar.
  • IMG_TYPE (argumento de compilación, por defecto google_apis): tipo de imagen de sistema; google_apis_playstore para incluir la tienda.
  • MEMORY y CORES (variables de entorno, por defecto 8192 y 4): memoria y núcleos del emulador; el docker-compose del repositorio las sube a 16384 y 16.
  • SKIP_AUTH (variable de entorno, por defecto true): añade -skip-adb-auth al emulador; desactivarla implica gestionar las llaves ADB.
  • keys/adbkey y keys/adbkey.pub: montadas en /root/.android/; obligatorias en la práctica para la variante con Play Store.

Trampas frecuentes y soluciones

  • «x86_64 emulation currently requires hardware acceleration! /dev/kvm is not found»: virtualización desactivada en la BIOS o módulo KVM no cargado; el commit del 7 de mayo de 2026 (fc1d197d) mejoró este mensaje de error. En máquinas Apple Silicon no hay solución: la emulación exige KVM con CPU x86 (incidencias #21 y #29; el usuario ansidev recuerda que «solo x86_64 y x86 están activamente soportados»).
  • «Device Unauthorized» con la variante Play Store (incidencia #2, abierta desde noviembre de 2023, 7 comentarios): ADB y scrcpy rechazan la conexión porque la llave del cliente no coincide con la del emulador. La solución documentada en el hilo por Anyeos (mayo de 2026) es copiar adbkey y adbkey.pub del directorio keys/ del repositorio a ~/.android del cliente y ejecutar adb kill-server para reiniciar el servidor ADB.
  • «failed to solve: openjdk:18-jdk-slim: not found» (incidencia #21): la imagen base de Java ya no existe en el registro; el proyecto se migró a eclipse-temurin:25 en mayo de 2026, así que actualizar el repositorio antes de compilar lo resuelve.
  • README parcialmente desactualizado: afirma que la imagen es «Alpine» con JRE 11, pero el Dockerfile actual se basa en eclipse-temurin:25 (JDK 25) y en CUDA con openjdk-18 en la variante GPU; además indica «Current version: 1.1.0» mientras las etiquetas del Dockerfile dicen 1.0.0 (CPU) y 1.2.0 (GPU) y no existen releases formales en GitHub. Tomar el Dockerfile como fuente de verdad.
  • Compilación larga sin indicador claro de fin (incidencia #12): la instalación del SDK y de la imagen de sistema puede tardar mucho; el usuario miamimanni aportó capturas de las fases esperadas en el hilo.
  • Rendimiento con renderizado por software: swiftshader_indirect es fiable pero lento para apps con mucho canvas; en la incidencia #28 el usuario luoshixin93-sudo sugiere virglrenderer montando --device /dev/dri:/dev/dri (sugerencia de la comunidad, no documentación oficial), y estima el arranque en frío de un AVD en Docker entre 30 y 60 segundos.
  • Variantes GPU: requieren el runtime de contenedor de NVIDIA (el servicio android-emulator-cuda reserva driver: nvidia en deploy.resources); sin GPU, la variante CPU es la vía correcta.

Una cámara de renderizado oscura acelerada por GPU dentro de un contenedor de emulador Android headless, a la izquierda una ruta de renderizado por software se muestra como un circuito azul apagado etiquetado swiftshader_indirect, mientras a la derecha una ruta GPU brillante resplandece con aceleración CUDA y GPU del host, un panel de framebuffer virtual aparece como una pantalla holográfica transparente 1920x1080 con un indicador de profundidad de 16 bits, conectado a un nodo de pantalla virtual Xvfb

Integraciones y migración

  • ADB es el punto de integración universal: cualquier herramienta que hable ADB funciona —pruebas instrumentadas, Appium (hay una incidencia #16 pidiendo un ejemplo de Appium junto al emulador en Docker), scrcpy, o scripts propios que espien la línea ANDROID_READY del log como señal de listo.
  • CI/CD: los propios temas del repositorio incluyen ci-pipeline; el patrón documentado es una imagen por nivel de API y esperar al estado JSON antes de ejecutar tests.
  • Interfaz web: no viene incluida; la solicitud de cambios #32 (no fusionada) añade acceso noVNC. Quien necesite ver el emulador sin scrcpy en local puede orientarse a budtmo/docker-android (noVNC y vídeo).
  • Migración desde el emulador local de Android Studio: el equivalente es docker compose up android-emulator y adb connect 127.0.0.1:5555 en lugar del dispositivo local; el AVD pasa a vivir en el volumen /data.
  • Migración hacia proyectos vecinos: hacia budtmo/docker-android si se necesita interfaz web, grabación de vídeo o servidor MCP; hacia Shmayro/dockerify-android si se requiere ARM/arm64 o root con Magisk; hacia google/android-emulator-container-scripts si se prefiere el script mínimo oficial de Google.

Números del repo

Medición: 4 de septiembre de 2026, API de GitHub.

MétricaValor
Estrellas7.260
Bifurcaciones558
Suscriptores36
Commits59
Incidencias abiertas indicadas por la API15
Lenguaje principalShell
LicenciaMIT
Creación8 de febrero de 2023
Última empujada de código7 de mayo de 2026
Versión indicada en el README1.1.0 (sin releases formales en GitHub)
Descargas en Docker Hub45.939 (pulls acumulados)

Los principales contribuidores que devolvió la API, por número de contribuciones: HQarroum (45), twocolors (5) y, con una contribución cada uno, heralight, individual-it, KhaiTrang1995, miamimanni y saksham-45. El conteo de 59 se obtuvo de la página final de la paginación de la API de commits. Caveats: la API usa open_issues_count, que incluye solicitudes de cambios abiertas (hay al menos una PR abierta, #32), por lo que no es un conteo exclusivo de incidencias; y watchers_count replica las estrellas, de ahí el uso de subscribers_count. Las 45.939 descargas de Docker Hub son acumuladas desde la creación del registro, no un periodo concreto.

Cómo lo recibió la comunidad

No se encontró un hilo de Hacker News dedicado a este repositorio (las búsquedas por nombre de proyecto y de autor devolvieron solo menciones a otros proyectos); la recepción verificable vive en GitHub, Docker Hub, YouTube y en comentarios de terceros hilos de HN:

  • En el hilo 48556561 («How we run Firecracker VMs inside EC2 and start browsers in less than 1s», artículo de browser-use, 322 puntos, 16 de junio de 2026), el usuario sandGorgon (comentario 48576076) contó que ejecutan cargas de trabajo de refuerzo (RL) con navegadores Android y que «se han visto obligados a mantener un fork» de budtmo/docker-android con Chrome encima —una señal de demanda real por esta clase de infraestructura, aunque dirigida al homónimo.
  • En el hilo 42057903 («All the data can be yours: reverse engineering APIs», 595 puntos, noviembre de 2024), SeriousStorm (comentario 42111402) recomendó el emulador en Docker como herramienta de ingeniería inversa, citando budtmo/docker-android.
  • En 30810410 («Running GUI apps within Docker containers», 330 puntos, 2022), 999900000999 (comentario 30810620) criticó una cláusula de la licencia de budtmo/docker-android que recolectaba datos anonimizados de IP de los usuarios —una objeción de confianza sobre el proyecto homónimo, no sobre este.
  • En GitHub, la incidencia #2 (7 comentarios, abierta desde noviembre de 2023) es el hilo técnico más activo: el error «Device Unauthorized» con Play Store, con la solución de las llaves ADB documentada por Anyeos en mayo de 2026. La incidencia #21 (4 comentarios) documenta el fallo de la imagen base Java y la incompatibilidad con Apple Silicon. En #28, luoshixin93-sudo escribió «Solid Docker Android setup» y aportó consejos de rendimiento (virglrenderer, arranque en frío de 30-60 segundos, pool de AVD precalentados). Las peticiones de la comunidad apuntan a ARM (#35), Android TV (#27), noVNC (#32), WebRTC (#13), Magisk (#11) y Appium (#16).
  • En YouTube, el canal LaurieWired publicó «Easy Android Emulator in Docker» (vídeo SWin67TZ4AY) y «Choosing an Android Emulator for Malware Reversing, Development, and More!» (jjf96PuCONA); Tech on Fire publicó «Run Android in a Docker Container!» (a1M40roHuRg) y Novaspirit Tech «Run Android In Docker with this Container!» (GTtdTksS6L0). El canal «GitHub Daily Trend AI Podcast» tiene un episodio dedicado a este repositorio (0VNwEKacAIU). No fue posible verificar las vistas desde este entorno.
  • El acceso a Reddit fue bloqueado desde este entorno, por lo que no hay datos verificables de ese canal.

No hay un proceso de contribución documentado (no existe CONTRIBUTING.md); el desarrollo lo lidera el autor (45 de 59 commits) y la comunidad ha aportado parches puntuales, como la solicitud de cambios #31 de italks (fusionada el 7 de mayo de 2026, corrigiendo la incidencia #10) o la #32 (noVNC, pendiente).

docker-android frente a otras propuestas

ProyectoCoincidencia verificableDiferencia verificable
budtmo/docker-android (15.810 estrellas)Emulador Android en Docker, ADB, tema docker-android compartidoAñade interfaz noVNC/WebRTC, grabación de vídeo y servidor MCP; más antiguo (2016) y con una licencia que varios usuarios de HN criticaron por recolectar datos.
google/android-emulator-container-scripts (2.077 estrellas)Scripts mínimos oficiales de Google para correr el emulador en contenedorEs un conjunto de scripts genéricos para distintos sistemas, no una imagen precompilada ni un servicio con ADB expuesto.
aind-containers/aind (1.488 estrellas)«Android in Docker»Se autodescribe como «Ain’t an emulator»; enfoque distinto de empaquetado.
thyrlian/AndroidSDK (1.385 estrellas)Imagen Docker con el SDK de Android completoCentrada en el SDK para desarrollo y pruebas de compilación, no en un emulador headless expuesto por la red.
sickcodes/dock-droid (1.376 estrellas)Android en Docker para CIUsa QEMU en lugar del emulador oficial, con reenvío X11 (2021).
Shmayro/dockerify-android (625 estrellas)Emulador en Docker, ADB, scrcpy, tema docker-androidSoporta x86 y arm64, Magisk y Play Store con acceso web a scrcpy (2024); cubre la carencia ARM de este repositorio.
alvr/alpine-android (460 estrellas)Imagen mínima para compilar y probar apps AndroidOrientada a build/test de aplicaciones, no a un emulador remoto.
Genymobile/scrcpy (148.844 estrellas)Controla Android a distanciaComplemento y no competidor: es la herramienta que el README recomienda para ver la pantalla.

La comparación más útil es por perfil de necesidad: docker-android (HQarroum) destaca por la minimalidad, las imágenes precompiladas por nivel de API y el borrado por defecto; budtmo cuando se necesita interfaz web, vídeo o MCP; dockerify-android cuando se requiere ARM; y los scripts de Google cuando se quiere algo del propio vendor.

Casos de uso y a quién puede ayudar este repositorio

  • Equipos de QA y automatización de apps Android: la combinación de imágenes precompiladas por nivel de API (etiquetas api-28 a api-33, con y sin Play Store, con y sin CUDA), el estado JSON de arranque (ANDROID_READY) y el borrado por defecto encajan en un pipeline que debe ejecutar el mismo emulador limpio contra varias versiones de Android, con ADB como único contrato con el exterior.
  • Analistas de malware e ingeniería inversa: la cobertura de vídeo de LaurieWired sobre elegir un emulador Android para «Malware Reversing, Development, and More!» y la recomendación de un emulador en Docker en el hilo de HN sobre ingeniería inversa de APIs (595 puntos) señalan este tipo de contenedor como un sandbox reproducible para analizar apps de dudosa procedencia sin tocar el equipo propio.
  • Investigadores que entrenan o evalúan agentes y cargas de RL sobre Android: el comentario de sandGorgon en el hilo de browser-use (322 puntos) describe exactamente este caso —mantener infraestructura de emuladores Android en contenedor para cargas de trabajo de RL que manejan navegadores —y este repositorio, o su homónimo, es la base de esa infraestructura.
  • Desarrolladores sin acceso a Android Studio o a dispositivos físicos: docker pull + adb connect 127.0.0.1:5555 + scrcpy dan una máquina Android completa con pantalla controlable en un par de comandos, siempre que el host sea x86 con KVM.
  • Equipos con el SDK en almacenamiento compartido: el argumento INSTALL_ANDROID_SDK=0 con montaje del SDK en /opt/android (por ejemplo, NFS) reduce el tamaño de la imagen a 138 MB comprimidos y acorta el tiempo de compilación, un caso de uso documentado explícitamente en el README.
  • Quienes necesitan Android TV, ARM, Magisk o noVNC: este repositorio no lo cubre (incidencias #27, #29, #11, #32 abiertas); la alternativa verificable dentro del mismo nicho es Shmayro/dockerify-android (arm64 y Magisk) o budtmo/docker-android (noVNC y vídeo).

Un mapa de ecosistema estilo constelación de proyectos de contenedores de emuladores Android, con un nodo central representando un servicio Docker minimalista de emulador Android, nodos conectados irradian hacia herramientas y conceptos relacionados: un nodo de control remoto de pantalla, un nodo de imagen Android ligera, una granja de emuladores basada en clúster, un nodo de granja de dispositivos empresarial, y un clúster más amplio de IoT/automatización, cada nodo renderizado como un chip de vidrio oscuro brillante con enlaces neón finos e iconos arquitectónicos pequeños

Recursos

Nota: este artículo combina el README, los Dockerfiles y scripts del repositorio, la API de GitHub, Docker Hub, el perfil del autor y búsquedas en Hacker News, YouTube y GitHub consultadas el 4 de septiembre de 2026. Las cifras cambian con el tiempo; las menciones de Hacker News referidas a «docker-android» citan en su mayoría al proyecto homónimo budtmo/docker-android y se han etiquetado como tales.

Artículos relacionados
lissy93/web-check
14 de septiembre de 2026

Web-Check: un solo panel de inteligencia de código abierto para cualquier sitio web

34.802★
Fission-AI/OpenSpec
14 de septiembre de 2026

OpenSpec: la capa de especificaciones ligera que obliga a acordar qué construir antes de escribir código

68.216★
ChromeDevTools/chrome-devtools-mcp
13 de septiembre de 2026

chrome-devtools-mcp: el servidor oficial que le da ojos de navegador a los agentes de IA

51.654★

Comentarios