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.
45 lines
2.4 KiB
Markdown
45 lines
2.4 KiB
Markdown
# Stack técnico: qué se puede correr en un rack Linux
|
|
|
|
## Opciones de software libre
|
|
|
|
- **[redroid](https://github.com/remote-android/redroid-doc)** — Android real en contenedores
|
|
Docker, GPU acelerada, arm64 y amd64, orquestable con Kubernetes. Es lo mejor para densidad:
|
|
~2 GB RAM por instancia, de 30 a 60 instancias en un nodo de 32 cores/128 GB. No ensucia el host
|
|
y soporta acceso remoto.
|
|
- **[Cuttlefish](https://source.android.com/docs/devices/cuttlefish)** (Google/AOSP) — dispositivo
|
|
virtual configurable sobre KVM, imágenes AOSP oficiales. Más pesado, pero es el estándar si
|
|
importa la fidelidad al SO. Hay
|
|
[patrones de escalado sobre Kubernetes](https://realz.medium.com/running-android-on-kubernetes-be73b940833f)
|
|
publicados.
|
|
- **[Waydroid](https://waydro.id/)** — LXC + binder, rendimiento nativo sin encoding de vídeo, pero
|
|
pensado para una instancia en escritorio, no para densidad.
|
|
|
|
## Orquestación y control
|
|
|
|
- **[GADS](https://github.com/shamanec/GADS)** — activo, iOS + Android, integra Appium.
|
|
- **DeviceFarmer / STF** — fork comunitario de OpenSTF; Google lo abandonó en 2020 y va lento con
|
|
versiones nuevas de Android.
|
|
- Encima: **Appium/UIAutomator2** para conducir, **scrcpy** para ver, **ADB sobre TCP** para todo.
|
|
|
|
## El jarro de agua fría
|
|
|
|
Ese rack **no sirve** para el caso TikTok/Instagram, y esa es exactamente la razón por la que
|
|
GenFarmer vende cajas con teléfonos físicos de $400 en vez de vender software para tu servidor.
|
|
|
|
Play Integrity con atestación por hardware, ausencia de sensores reales, strings de GPU, falta de
|
|
baseband e IMEI legítimo — la detección de emulador es prácticamente determinista desde 2025.
|
|
|
|
> El cuello de botella nunca fue cómputo, fue **identidad y confianza del dispositivo**.
|
|
> Un rack te da CPU infinita y cero confianza.
|
|
|
|
Por eso el mercado real es hardware caro y lento, no servidores.
|
|
|
|
El mecanismo exacto — por qué a un contenedor le falta una clave grabada en fábrica que ningún
|
|
software puede producir — está en **[capa_identidad.md](capa_identidad.md)**.
|
|
|
|
Donde el rack sí es imbatible: **laboratorio de testing de tu propia app**. Con `oasis_mobile` hay
|
|
APK que necesita probarse en matriz de versiones de Android y en escenarios multi-dispositivo —
|
|
dos APKs que se tienen que ver entre sí. redroid + Appium en un rack resuelve eso de verdad,
|
|
incluido el bloqueo de capa 1 anotado.
|
|
|
|
Ver [../02_device_lab/](../02_device_lab/) para el montaje concreto.
|