Granja de dispositivos Android: montar la tuya o usar la nube

Una granja de dispositivos Android es un conjunto de teléfonos de prueba conectados a máquinas host, para que las pruebas automatizadas y las personas puedan usarlos sin tenerlos en la mano. El término viene de QA y así lo usa este artículo: un pool compartido de dispositivos para ejecutar y reproducir pruebas. Los racks de teléfonos que se usan para operar cuentas de redes sociales a escala son otra cosa, violan los términos de todas las plataformas grandes y no se tratan aquí.

Todo equipo de desarrollo móvil llega al punto en que un cajón con teléfonos deja de funcionar. Alguien se llevó el Pixel a casa, nadie sabe qué build tiene cada teléfono y el CI corre en un único emulador. Esta guía explica para qué sirve una granja, qué implica y cuánto cuesta un rack propio, y cuándo los teléfonos en la nube hacen el mismo trabajo.

Para qué sirve una granja de dispositivos

• Pruebas de UI automatizadas sobre una matriz. Suites de Espresso, UI Automator o Appium en varias versiones de Android y tamaños de pantalla a la vez, para que una release candidate reciba una respuesta clara.
• Reproducir el bug de un usuario. El reporte indica un modelo y una versión de Android, y la granja tiene ese teléfono o uno parecido.
• Sesiones manuales y exploratorias. Un tester abre un modelo concreto en remoto en lugar de pedírselo prestado a un colega.
• Ejecuciones largas. Sincronización en segundo plano, entrega de notificaciones y memoria a lo largo de horas, algo que no puede mostrar un emulador que se descarta tras cada job de CI.
• Prueba de humo de la release. La misma pasada rápida en diez teléfonos en paralelo antes de un despliegue.

Anatomía de un rack propio

Montar un rack no es difícil. Lo que da trabajo es mantenerlo sano. Un rack típico tiene cinco partes.

Teléfonos. Elígelos según tus analíticas, no según lo que esté en oferta: los modelos con más cuota de sesiones, la versión de Android más antigua que soportas y la más nueva. Compra dos unidades del modelo más común, para que una pueda estar en uso mientras la otra corre el CI.

Energía y USB. Hubs con alimentación y suficiente corriente por puerto, cables cortos de buena calidad y presupuesto para controladores USB del host. Como regla general, adb empieza a fallar en algún punto por encima de diez a quince teléfonos por host, según el controlador y los hubs.

Hosts. Máquinas Linux pequeñas o Macs, cada una con el servidor adb de su estante. Identifica los dispositivos por número de serie y lleva un mapa de qué teléfono está en qué puerto, porque lo vas a necesitar en el peor momento.

Software. adb, un gestor de dispositivos como DeviceFarmer (el sucesor comunitario de OpenSTF) para pantallas remotas y reservas, Appium con un grid si pruebas a través de WebDriver, y tu CI para programar las ejecuciones.

Mantenimiento. Es la parte que nadie presupuesta. Las baterías se hinchan cuando los teléfonos pasan meses en el cargador, así que conviene usar el límite de carga que ofrecen algunos fabricantes o enchufes inteligentes que corten la corriente por ciclos. Los avisos de actualización del sistema aparecen a mitad de una ejecución. Las pantallas se bloquean, las notificaciones se acumulan, el almacenamiento se llena de archivos de prueba, y un teléfono que falló de noche arranca con un diálogo que nadie está ahí para tocar.

Cuánto cuesta realmente un rack

Para un rack de 20 teléfonos, una estimación aproximada de 2026 queda así. Los teléfonos cuestan de $3,000 a $12,000, según cuántos modelos de gama alta necesites. Hubs, cables, estanterías y dos hosts suman de $1,500 a $4,000. Después hay que reservar cada año del 20 al 30 % de lo invertido en teléfonos para baterías hinchadas, puertos rotos y los modelos nuevos que compran tus usuarios.

La partida que sorprende a los equipos es el tiempo: de tres a ocho horas por semana de alguien que destraba teléfonos, aplica actualizaciones y reinicia hosts. Tus números serán otros, pero la forma no cambia. El hardware es la parte menor de la cuenta.

Los teléfonos en la nube convierten esto en un costo corriente sin mantenimiento. En Clousd, el pago por minuto cuesta $0.004 por minuto mientras un teléfono está encendido y nunca más de $0.80 por teléfono al día, y los planes empiezan en $20 al mes; la página de precios tiene los detalles. Dos ejemplos con los mismos 20 teléfonos:

• Dos horas cada día hábil: 20 teléfonos × 120 minutos × $0.004 = $9.60 al día, unos $211 en 22 días hábiles.
• Las 24 horas: se aplica el tope diario, así que 20 × $0.80 × 30 días = $480 al mes como máximo.

Con el pago por minuto, los minutos se detienen cuando se detiene el teléfono. Un modelo que necesitas para un solo reporte de bug es un teléfono que creas, usas y borras.

Rack propio, nube de dispositivos reales o teléfonos en la nube

Qué cambia con la nube

• Arranques limpios. Un teléfono se crea en cerca de un minuto y se puede restablecer a un estado limpio antes de cada suite, así que cada ejecución empieza desde el mismo punto.
• Modelos como parámetro. Android 12 a 17 en más de 150 modelos reales, elegidos en cada ejecución de la lista de modelos y no según lo que haya en el estante.
• Remoto por defecto. Pantalla en vivo en el navegador para las sesiones manuales, API REST y ADB para el CI, y un servidor MCP cuando la prueba la hace un agente de IA.
• Sin tareas de hardware. Nada se hincha, nada necesita un cable, nada necesita un reinicio a las 2 de la madrugada.

Qué no cambia

Los teléfonos en la nube no son teléfonos físicos. El procesamiento de la cámara, la precisión de los sensores, el rendimiento de la GPU, el consumo de batería, el throttling térmico, NFC, Bluetooth y los gestores de procesos en segundo plano de cada fabricante siguen necesitando hardware real. La mayoría de los equipos termina con un modelo híbrido: de tres a cinco teléfonos físicos en un escritorio para esas pruebas y la matriz amplia de modelos y versiones en la nube. Probar una app en distintas versiones de Android detalla qué debe cubrir esa matriz.

Correr pruebas en la granja, esté donde esté

Los runners de pruebas identifican los teléfonos por su serial de adb, así que la misma suite corre en un rack USB y en teléfonos remotos. AndroidJUnitRunner puede repartir una suite entre dispositivos por shards:

R=com.example.app.test/androidx.test.runner.AndroidJUnitRunner
adb -s "$P12" shell am instrument -w -e numShards 3 -e shardIndex 0 $R
adb -s "$P14" shell am instrument -w -e numShards 3 -e shardIndex 1 $R
adb -s "$P16" shell am instrument -w -e numShards 3 -e shardIndex 2 $R

Ejecuta las tres líneas en paralelo y cada teléfono se encarga de un tercio de las pruebas. Appium elige un dispositivo con la capability appium:udid, que recibe el mismo serial. Los teléfonos remotos se suman al pool con adb connect; la documentación de ADB muestra cómo funciona a través de un relé, y la página de pruebas de apps muestra la ruta por API para el CI.

Cuenta con que cada acción remota tarde un poco más que por USB y ajusta los tiempos de espera de tus pruebas de UI en consecuencia. Las pruebas que pasan en un emulador local y se agotan en remoto suelen tener una pausa fija en el código o una espera demasiado ajustada.

Granja de dispositivos móviles y granja de teléfonos en la nube

Una granja de dispositivos móviles es la misma idea, con iPhones y iPads en el estante junto a los teléfonos Android. En QA, una granja de teléfonos en la nube es simplemente el pool de teléfonos en la nube en el que corre tu suite. La palabra “granja” tiene otros significados fuera de las pruebas; el artículo sobre las granjas de teléfonos los explica.