ADB a gran escala: controlar muchos dispositivos a la vez

Controlar un teléfono desde un ordenador es una parte rutinaria del desarrollo de apps. Controlar mil teléfonos desde un ordenador es un problema de ingeniería distinto, y es el que hace que las granjas de teléfonos funcionen como infraestructura utilizable en lugar de una sala llena de dispositivos operados individualmente. La herramienta central detrás de la mayor parte de esto en Android es el Android Debug Bridge, más conocido como ADB.

Qué hace realmente ADB

ADB es una herramienta de línea de comandos, incluida con el SDK estándar de Android, que permite a un ordenador host comunicarse con un dispositivo Android conectado por USB o por una conexión de red. Puede instalar y desinstalar aplicaciones, subir y descargar archivos, emitir eventos de entrada simulados como toques y deslizamientos, capturar capturas de pantalla y transmitir los logs del dispositivo de vuelta al host. Cada una de estas operaciones se dirige a un único dispositivo por invocación: la unidad básica de control de ADB es un dispositivo, identificado por un número de serie o una dirección de red.

De un dispositivo a muchos

Como ADB se dirige a los dispositivos individualmente, controlar una flota significa ejecutar muchas sesiones de ADB en paralelo en lugar de inventar un nuevo protocolo. El software de orquestación se sitúa por encima de ADB (o de una API de automatización de proveedor equivalente para plataformas que no son Android) y se encarga de lo que ADB no hace: mantener una lista de dispositivos conectados, encolar tareas, distribuirlas entre los dispositivos que estén disponibles en cada momento, reintentar fallos y agregar los resultados en un único informe. Esta capa —una primitiva de control simple por dispositivo más una capa de programación por encima— es el mismo patrón básico descrito en cómo funcionan las granjas de teléfonos.

Direccionar y seleccionar dispositivos

A escala de flota, una tarea rara vez necesita ejecutarse literalmente en todos los dispositivos sin distinción. Las capas de orquestación suelen admitir la selección de dispositivos por atributo —versión del sistema operativo, modelo, región o estado de salud actual—, de modo que un conjunto de pruebas de QA pueda dirigirse solo a dispositivos con una versión concreta de Android, o un trabajo de monitorización pueda ejecutarse solo contra dispositivos de un pool geográfico determinado. Este direccionamiento selectivo es parte de lo que separa el uso básico de ADB mediante scripts de una auténtica orquestación de flotas.

Paralelismo y sus límites

Ejecutar comandos en muchos dispositivos a la vez no es infinitamente paralelo en la práctica. Las máquinas host tienen un ancho de banda USB o de red finito, y un único proceso de servidor ADB que maneje demasiadas conexiones de dispositivo concurrentes puede convertirse en un cuello de botella en sí mismo. Las flotas más grandes suelen repartir los dispositivos entre varias máquinas host, cada una ejecutando su propio servidor ADB y un subconjunto de la flota, con el software de orquestación coordinando entre hosts en lugar de asumir que un único ordenador puede dirigirse a todos los dispositivos directamente.

Fiabilidad a escala

Los dispositivos individuales se desconectan, dejan de responder o devuelven errores con la frecuencia suficiente como para que la automatización de flotas tenga que esperarlo y gestionarlo, en lugar de tratarlo como algo excepcional. Una orquestación robusta reintenta los comandos fallidos, marca los dispositivos persistentemente sin respuesta para una revisión de salud, y sigue operando el resto de la flota en lugar de detenerse por un dispositivo problemático. Esto conecta directamente con el trabajo sobre el ciclo de vida del dispositivo cubierto en ciclo de vida del dispositivo: un dispositivo que falla repetidamente en los comandos ADB suele ser candidato a mantenimiento o sustitución, no solo un fallo transitorio que reintentar indefinidamente.

Dónde encaja esto en los casos de uso de la flota

La automatización basada en ADB sustenta la mayoría de los casos de uso comunes de las granjas de teléfonos: las pruebas de QA instalan builds y leen los resultados a través de él, los trabajos de monitorización programan interacciones repetidas a través de él, y cualquier flujo de trabajo que necesite manejar hardware Android real de forma programática acaba pasando por la misma primitiva de control básica. El mismo desafío de coordinación se aplica tanto si la flota ejecuta dispositivos físicos como emulados, una distinción cubierta en emuladores frente a dispositivos reales: ADB trata a ambos de forma idéntica, ya que para el protocolo un emulador y un dispositivo real se ven prácticamente iguales.

Más allá de Android

Las flotas que incluyen hardware iOS dependen de una pila distinta en lugar de ADB, ya que ADB no tiene contrapartida en iOS. El control de la interfaz en el propio dispositivo proviene de XCUITest, manejado a través de una instancia de WebDriverAgent que se ejecuta en el teléfono; la gestión de dispositivos del lado del host (instalar apps, leer el estado del dispositivo, gestionar el aprovisionamiento) suele pasar por libimobiledevice o go-ios. Todo ello requiere un host macOS: no hay forma de ejecutar el equivalente iOS de un servidor ADB en Linux o Windows.

La forma del problema es la misma que en Android: una primitiva de control por dispositivo, con orquestación por encima para encolar tareas, distribuirlas entre los dispositivos disponibles y gestionar los fallos con elegancia. Lo que cambia es la profundidad y la apertura: ADB es una herramienta única y bien documentada que cubre de fábrica la mayor parte de lo que necesita el control de flotas; la pila de iOS son varias herramientas que salvan la plataforma más cerrada de Apple, y exige la capa de host macOS que Android no necesita. Consulta flotas iOS vs Android para una comparación más completa de ambas pilas de automatización y de lo que cuesta operarlas.