Android en la nube para desarrolladores y testers: Redroid con renderizado por GPU
Un dispositivo Android siempre encendido, accesible por ADB desde tu portátil o tu CI, y que puedes reiniciar en segundos: eso es lo que te da Redroid en un servidor Linux. Redroid («remote Android») ejecuta un sistema Android completo en un contenedor Docker, sin máquina virtual dentro del servidor. Sirve para probar tu app en un Android limpio, para ejecutar pruebas de interfaz automatizadas (Appium, uiautomator, Espresso) o para mantener una app exclusiva de Android funcionando 24/7.
La pregunta de este artículo es sencilla: ¿qué cambia la GPU? Redroid puede dibujar la pantalla con la GPU del servidor (a través de Mesa) o solo con la CPU (renderizado por software). Ejecutamos las mismas pruebas en el mismo servidor en los dos modos.
Resultados de un vistazo
- Las apps sencillas van fluidas en ambos modos: el desplazamiento en los Ajustes de Android fue a 60 fps con 1 fotograma lento de unos 1.045 en los dos modos. Pero el renderizado por software usó 4 veces más CPU (el 17,3 % del servidor en lugar del 4,2 %).
- Todo lo que es 3D necesita la GPU: un shader de raymarching fue a 58,4 fps en la GPU frente a 7,2 fps por software, y el juego SuperTuxKart a 60 fps frente a 19 fps.
- La GPU libera la CPU: con la GPU, Android usó menos del 5 % de la CPU del servidor en todas las pruebas. En modo software, el trabajo 3D ocupó del 95 al 98 % de las 4 vCPU, sin dejar nada para tus pruebas.
- El arranque no es más rápido con la GPU: Android estuvo listo en unos 13 s en modo GPU y 7 s en modo software.
- iGPU Start basta para una instancia de Android; elige iGPU Power para ejecutar varias en paralelo o para probar apps y juegos 3D.
Configuración de la prueba
| Elemento | Valor |
|---|---|
| Servidor | Debian 13, Linux 7.3, Intel UHD 770 (GPU compartida), 4 vCPU, 10 GB de RAM |
| Android | Redroid, imagen oficial redroid/redroid:14.0.0-latest (Android 14, x86_64), Docker 29.9 |
| Pantalla | 1080×1920 a 420 dpi, 60 Hz (los juegos pasan a 1920×1080 en horizontal) |
| Renderizado por GPU | redroid_gpu_mode=host: Mesa 24.0.8, «Mesa Intel UHD Graphics 770», OpenGL ES 3.2 |
| Renderizado por software | redroid_gpu_mode=guest: ANGLE sobre SwiftShader (CPU), OpenGL ES 3.1 |
| Apps | Ajustes de Android, Shader Editor 2.36.3 y SuperTuxKart 1.4 (ambos de código abierto, de F-Droid) |
| Mediciones | tasa de fotogramas por capa según SurfaceFlinger (dumpsys SurfaceFlinger --timestats), jank según dumpsys gfxinfo, CPU de todo el servidor según /proc/stat |
| Visualización | scrcpy 5.0.1 (release oficial), adb exec-out screencap para las capturas |
Cada medición duró de 10 a 20 segundos. Las cifras de CPU son una parte de todo el servidor (4 vCPU = 100 %).
1. Interfaz del día a día: fluida en ambos modos, pero no al mismo coste
Abrimos los Ajustes de Android y nos desplazamos arriba y abajo 20 veces con adb shell input swipe, y
después leímos el propio informe de fotogramas de Android con adb shell dumpsys gfxinfo com.android.settings:
| Ajustes, 20 deslizamientos | GPU | Software |
|---|---|---|
| Fotogramas dibujados | 1.045 | 1.047 |
| Fotogramas con jank | 1 (0,10 %) | 1 (0,10 %) |
| Tiempo por fotograma, percentil 50 / 90 / 99 | 17 / 18 / 18 ms | 17 / 17 / 18 ms |
| CPU del servidor | 4,2 % | 17,3 % |
Para una app normal con listas, botones y texto, la CPU de un servidor moderno es lo bastante rápida para dibujar la pantalla por sí sola. La diferencia está en el precio: el renderizado por software hizo que todo el servidor estuviera unas cuatro veces más ocupado. Cuando tus pruebas ejecutan varias instancias o graban la pantalla, esa CPU falta en otra parte.
2. 3D: donde la GPU marca la diferencia
Usamos dos apps de código abierto de F-Droid: Shader Editor, que dibuja un shader GLSL a pantalla completa y muestra su tasa de fotogramas, y SuperTuxKart, un juego 3D de carreras de karts. En Shader Editor ejecutamos el shader por defecto (muy ligero) y una escena de raymarching (esferas, sombras suaves, niebla) que escribimos para esta prueba.
| Fotogramas por segundo (CPU del servidor) | GPU | Software |
|---|---|---|
| Shader Editor, shader por defecto | 60,0 fps (4,0 %) | 60,1 fps (64,4 %) |
| Shader Editor, shader de raymarching | 58,4 fps (1,8 %) | 7,2 fps (98,1 %) |
| Tutorial de SuperTuxKart, 1920×1080 | 60,0 fps (4,7 %) | 19,2 fps (95,2 %) |
| SuperTuxKart en carrera, grabado por scrcpy | 59,2 fps | 16,1 fps |
Con la GPU, las escenas 3D se mantienen a los 60 fps de la pantalla y la CPU está casi inactiva. En modo software las cuatro vCPU están llenas y la tasa de fotogramas cae a entre 7 y 19 fps: un juego deja de ser jugable, y una prueba de interfaz que se ejecutara al mismo tiempo también se ralentizaría. Mientras se ejecutaba un juego, el contenedor de Redroid usaba unos 1,4 GB de RAM en los dos modos, y Docker contaba el 10 % de un núcleo con la GPU frente al 381 % (casi cuatro núcleos) en modo software.
adb exec-out screencap: GPU a la izquierda (la app muestra 56 fps), software a la derecha (7 fps). La imagen es idéntica, solo cambia la velocidad.3. Tiempo de arranque
Cronometramos desde docker run hasta que Android indicó sys.boot_completed=1, tres veces por modo, con
una carpeta de datos vacía cada vez:
| Arranque hasta «listo» | Ejecución 1 | Ejecución 2 | Ejecución 3 |
|---|---|---|---|
| GPU | 12,7 s | 13,3 s | 12,8 s |
| Software | 7,0 s | 6,5 s | 7,0 s |
El modo GPU arranca unos 6 segundos más lento, porque el driver gráfico se carga y se configura durante el
arranque. Para un job de CI que inicia un Android nuevo en cada ejecución, cuenta unos 13 segundos antes de
que adb pueda instalar tu app.
4. Ver y controlar Android desde tu ordenador
Redroid no tiene pantalla propia: lo usas como un móvil conectado por cable USB, a través de ADB.
- Capturas de pantalla:
adb exec-out screencap -p > screen.png, el método que usamos para las imágenes de arriba. - Pantalla en directo, ratón y teclado: scrcpy (de código abierto, de Genymobile) muestra la pantalla
de Android en una ventana y envía tus clics y teclas. Funciona a través de ADB, así que funciona con Redroid.
En el servidor lo usamos sin ventana para grabar los vídeos de este artículo:
scrcpy -s 127.0.0.1:5555 --no-window --no-audio --record=run.mp4 --time-limit=7. - Automatización de la interfaz:
adb shell input(toques, deslizamientos, texto) controló todas las pruebas de este artículo, yadb shell uiautomator dumpdevuelve el árbol de vistas de la pantalla. Appium (driver UiAutomator2), Espresso y Maestro se conectan a un dispositivo ADB de la misma manera; no los ejecutamos en esta prueba.
No abras nunca el puerto ADB a Internet: el ADB de Redroid no tiene contraseña y da control total del
sistema Android. Lo publicamos solo en la dirección local del servidor (-p 127.0.0.1:5555:5555) y
accedemos a él a través de un túnel SSH:
# en tu ordenador
ssh -N -L 5555:127.0.0.1:5555 you@<server> &
adb connect 127.0.0.1:5555
scrcpy -s 127.0.0.1:5555
5. Lo que debes saber antes de empezar
- Es Android x86_64. Las apps escritas en Java o Kotlin funcionan tal cual. Las apps y juegos con código
nativo compilado solo para ARM (muchos juegos) necesitan una capa de traducción: la imagen de Redroid anuncia
compatibilidad con ARM (
arm64-v8a) a través de una capa así, pero no probamos apps solo para ARM, y serán más lentas y pueden fallar. - Sin Google Play Store. La imagen oficial no tiene servicios de Google. Instala tus propios APK con
adb install, o apps de código abierto de F-Droid como hicimos nosotros. Las apps que necesitan los servicios de Google Play no funcionarán tal cual. - Para pruebas y automatización, no para simular teléfonos. Redroid indica a las apps que es un dispositivo virtual. Está pensado para desarrollo, pruebas y para ejecutar tus propias herramientas, no para ejecutar muchos «teléfonos» para múltiples cuentas, algo que prohíben los términos de la mayoría de las apps.
- Sin cámara, GPS ni SIM. Los sensores faltan o están simulados; pruébalos en un dispositivo real.
6. ¿Qué plan elegir?
Con la GPU, una instancia de Android usó menos del 5 % de nuestras 4 vCPU y unos 1,4 GB de RAM, incluso en un juego 3D. iGPU Start (2 vCPU, 8 GB de RAM, 14,99 € al mes sin IVA) basta para una instancia de Android con tus herramientas de prueba al lado. iGPU Power (4 vCPU, 14 GB de RAM, el doble de cuota de GPU que Start, 29,99 € al mes sin IVA) es la mejor opción para ejecutar varias instancias de Android en paralelo (una por job de prueba), para probar apps y juegos 3D o para grabar la pantalla durante las pruebas. iGPU Pro (6 vCPU, 14 GB, Perf 3, 44,99 €) añade más GPU y CPU para granjas de pruebas más grandes.
Sin GPU, el mismo servidor tendría que dedicar toda su CPU a dibujar en cuanto una app usa 3D.
7. Ponerlo en marcha en un servidor Linux GPU
¿Lo quieres listo para usar? Pídelo por correo al hacer el pedido (contact@linuxgpu.eu): podemos entregarte el servidor con Redroid ya instalado y configurado para el renderizado por GPU. Solo tienes que conectarte con ADB a través de SSH e instalar tu app.
Para hacerlo tú mismo en Debian 13:
-
Carga el driver binder de Android (incluido en el kernel de Debian) y mantenlo al arrancar:
echo "options binder_linux devices=binder,hwbinder,vndbinder" > /etc/modprobe.d/binder.conf echo binder_linux > /etc/modules-load.d/binder.conf modprobe binder_linux -
Instala Docker y ADB (
apt install docker.io adb), y después inicia Redroid con renderizado por GPU:docker run -d --name redroid --privileged \ -v ~/redroid-data:/data -p 127.0.0.1:5555:5555 \ redroid/redroid:14.0.0-latest \ androidboot.redroid_gpu_mode=host \ androidboot.redroid_gpu_node=/dev/dri/renderD128 \ androidboot.redroid_width=1080 androidboot.redroid_height=1920 \ androidboot.redroid_dpi=420 androidboot.redroid_fps=60 -
Comprueba que Android usa la GPU:
adb connect 127.0.0.1:5555 && adb shell dumpsys SurfaceFlinger | grep GLESdebería mostrar «Mesa Intel(R) UHD Graphics 770». «SwiftShader» significa renderizado por software. -
Conéctate desde tu ordenador a través del túnel SSH de arriba, instala tu APK con
adb installe inicia tus pruebas.
Para devolver Android a un estado limpio, elimina el contenedor y su carpeta de datos y vuelve a iniciarlo.
Para pruebas de navegador en el mismo tipo de servidor, lee Selenium y Playwright acelerados por GPU: no necesitas una GPU de 500 €/mes y Ejecutar Chrome con GPU en un servidor Linux (headless, Playwright, Puppeteer). Para entender cómo usa un contenedor la GPU de una máquina virtual, consulta Nube GPU: ¿VM o contenedor, GPU dedicada o compartida?.
Pruébalo
Ver los planes: iGPU Start cuesta 14,99 € e iGPU Power 29,99 € al mes sin IVA.