74bfbe9437
Investigación sobre granjas de dispositivos y automatización completa para levantar un laboratorio Android sobre un chasis de blades Debian. Conclusión que ordena el repositorio: el cuello de botella nunca fue el cómputo sino la identidad. Desde que la atestación de dispositivo pasó de estadística a criptográfica, un servidor no puede hacerse pasar por un teléfono — le falta una clave grabada en fábrica que ningún software produce. Contenido: - 01_investigacion/ — capa de identidad (verificación telefónica, eSIM, reputación de IP, atestación por hardware, correlación entre cuentas), mercado y players, stack técnico, marco legal en la UE - 02_device_lab/ansible/ — Ansible para 16 blades: preflight de solo lectura que identifica el hardware por DMI, despliegue de redroid en Docker y control de flota por adb. Solo ansible.builtin, sin colecciones externas - docs/ — requisitos, costes y repaso de seguridad con 11 hallazgos - 03_charla/ — guion para HackMadrid / Hackmeeting València Estado: la automatización está escrita pero SIN ejecutar contra hardware. YAML validado, plantillas renderizadas en ambos modos de red y fleet.sh comprobado con bash -n. El modelo de blade sigue sin confirmar.
3.5 KiB
Device lab con redroid
La vía 1: laboratorio de dispositivos Android propio sobre el rack. Legal, reutilizable, y el
primer uso real es probar oasis_mobile a escala — incluido el escenario de dos APKs que se tienen
que ver entre sí (el bloqueo de capa 1).
No hay móviles físicos. Cada "dispositivo" es un contenedor redroid: Android real sobre el kernel de una máquina Debian.
Dos caminos
| Para qué | |
|---|---|
| ansible/ | La granja de verdad: los 16 blades del M1000e, provisionados y controlados desde un sitio. Es lo que hay que usar. |
| Este documento | Un solo nodo, a mano. Sirve para entender las piezas y para trastear en el sobremesa. |
El hardware está descrito en hardware_m1000e.md.
Host
Comprobado el 2026-08-08 sobre esta máquina:
| CPU | 16 cores |
| RAM | 62 GB |
| SO | Debian 12 bookworm, kernel 6.1.0-51-amd64 |
| Docker | no instalado |
| binder | binder_linux.ko presente, pero CONFIG_ANDROID_BINDERFS no está activado |
Con 2 GB por instancia y dejando margen al host, 12–20 instancias redroid simultáneas es el rango realista aquí. No son las 30–60 de un nodo de 32c/128 GB.
Prerrequisitos
1. binder — el punto donde esto se atasca
El kernel de Debian trae binder_linux como módulo pero sin binderfs, así que redroid no puede
crear los devices por sí mismo. Hay que cargarlos a mano con los tres nombres que Android espera:
sudo modprobe binder_linux devices=binder,hwbinder,vndbinder
ls -l /dev/binder /dev/hwbinder /dev/vndbinder # deben existir
Para que persista entre reinicios:
echo binder_linux | sudo tee /etc/modules-load.d/redroid.conf
echo "options binder_linux devices=binder,hwbinder,vndbinder" | sudo tee /etc/modprobe.d/redroid.conf
Si modprobe falla, la alternativa es el módulo DKMS de Waydroid
(binder_linux-dkms), que sí aporta binderfs.
2. Docker
sudo apt install docker.io docker-compose-v2
sudo usermod -aG docker $USER # requiere volver a entrar en sesión
3. adb
sudo apt install adb
Arrancar
docker compose up -d
./connect.sh # conecta adb a las instancias levantadas
adb devices # deben salir 127.0.0.1:5555 .. 5558
Instalar un APK en todas:
./install-apk.sh ~/COFRE/CODERS/OASIS_APK/<algo>.apk
Ver una instancia:
sudo apt install scrcpy
scrcpy -s 127.0.0.1:5555
Escalar
docker-compose.yml trae 4 instancias como punto de partida. Para más, replicar el bloque
cambiando nombre y puerto. A partir de ~8 conviene generar el compose con un script en vez de
mantenerlo a mano, o pasar a GADS.
Para la flota entera
Todo lo de arriba, pero en 16 blades y sin hacerlo a mano: ansible/.
Ahí está el preflight que identifica el modelo de blade solo, el despliegue completo, y fleet
para hablar con todos los Android desde un único sitio.
Siguiente capa: GADS
GADS da UI web, gestión de dispositivos y Appium integrado encima de esto. Merece la pena cuando el número de instancias pase de una decena o cuando haga falta lanzar tests automatizados en vez de trastear a mano.
Limitación que hay que tener presente
Estas instancias son detectables como emulador. Sirven para probar tu propia app, no para interactuar con plataformas que hacen atestación de dispositivo (ver ../01_investigacion/stack_tecnico.md).