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.
112 lines
3.5 KiB
Markdown
112 lines
3.5 KiB
Markdown
# 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/](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](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:
|
||
|
||
```bash
|
||
sudo modprobe binder_linux devices=binder,hwbinder,vndbinder
|
||
ls -l /dev/binder /dev/hwbinder /dev/vndbinder # deben existir
|
||
```
|
||
|
||
Para que persista entre reinicios:
|
||
|
||
```bash
|
||
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
|
||
|
||
```bash
|
||
sudo apt install docker.io docker-compose-v2
|
||
sudo usermod -aG docker $USER # requiere volver a entrar en sesión
|
||
```
|
||
|
||
### 3. adb
|
||
|
||
```bash
|
||
sudo apt install adb
|
||
```
|
||
|
||
## Arrancar
|
||
|
||
```bash
|
||
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:
|
||
|
||
```bash
|
||
./install-apk.sh ~/COFRE/CODERS/OASIS_APK/<algo>.apk
|
||
```
|
||
|
||
Ver una instancia:
|
||
|
||
```bash
|
||
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/](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](https://github.com/shamanec/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](../01_investigacion/stack_tecnico.md)).
|