Rebelión en la granja — investigación y laboratorio de dispositivos

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.

01_investigacion/stack_tecnico.md

@@ -0,0 +1,45 @@
+# 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.