# 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/) | Los 16 blades del M1000e, provisionados y controlados desde un sitio. Es la vía principal. |
| 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)).