Android in der Cloud für Entwickler und Tester: Redroid mit GPU-Rendering
Ein Android-Gerät, das immer läuft, per ADB von Ihrem Laptop oder Ihrer CI erreichbar ist und sich in Sekunden zurücksetzen lässt: Das bietet Redroid auf einem Linux-Server. Redroid („remote Android”) betreibt ein vollständiges Android-System in einem Docker-Container, ohne virtuelle Maschine im Server. Das ist nützlich, um Ihre App auf einem sauberen Android zu testen, automatisierte UI-Tests (Appium, uiautomator, Espresso) auszuführen oder eine reine Android-App rund um die Uhr laufen zu lassen.
Die Frage dieses Artikels ist einfach: Was ändert die GPU? Redroid kann den Bildschirm mit der GPU des Servers (über Mesa) oder nur mit der CPU (Software-Rendering) zeichnen. Wir haben dieselben Tests auf demselben Server in beiden Modi ausgeführt.
Die Ergebnisse im Überblick
- Einfache Apps laufen in beiden Modi flüssig: Das Scrollen in den Android-Einstellungen lief mit 60 fps, mit 1 langsamen Bild von etwa 1.045 in beiden Modi. Software-Rendering brauchte aber 4-mal so viel CPU (17,3 % des Servers statt 4,2 %).
- Alles in 3D braucht die GPU: Ein Raymarching-Shader lief mit 58,4 fps auf der GPU gegenüber 7,2 fps in Software, das Spiel SuperTuxKart mit 60 fps gegenüber 19 fps.
- Die GPU entlastet die CPU: Mit der GPU nutzte Android in jedem Test unter 5 % der Server-CPU. Im Software-Modus belegte die 3D-Arbeit 95 bis 98 % der 4 vCPU und ließ nichts für Ihre Tests übrig.
- Mit der GPU startet Android nicht schneller: Android war im GPU-Modus nach etwa 13 s bereit, im Software-Modus nach 7 s.
- iGPU Start reicht für eine Android-Instanz; wählen Sie iGPU Power, um mehrere parallel zu betreiben oder 3D-Apps und Spiele zu testen.
Testaufbau
| Komponente | Wert |
|---|---|
| Server | Debian 13, Linux 7.3, Intel UHD 770 (geteilte GPU), 4 vCPU, 10 GB RAM |
| Android | Redroid, offizielles Image redroid/redroid:14.0.0-latest (Android 14, x86_64), Docker 29.9 |
| Bildschirm | 1080×1920 bei 420 dpi, 60 Hz (Spiele wechseln auf 1920×1080 quer) |
| GPU-Rendering | redroid_gpu_mode=host: Mesa 24.0.8, „Mesa Intel UHD Graphics 770”, OpenGL ES 3.2 |
| Software-Rendering | redroid_gpu_mode=guest: ANGLE auf SwiftShader (CPU), OpenGL ES 3.1 |
| Apps | Android-Einstellungen, Shader Editor 2.36.3 und SuperTuxKart 1.4 (beide Open Source, aus F-Droid) |
| Messungen | Bildrate pro Ebene laut SurfaceFlinger (dumpsys SurfaceFlinger --timestats), Ruckler laut dumpsys gfxinfo, CPU des gesamten Servers laut /proc/stat |
| Anzeige | scrcpy 5.0.1 (offizielles Release), adb exec-out screencap für Screenshots |
Jede Messung dauerte 10 bis 20 Sekunden. CPU-Werte sind ein Anteil am gesamten Server (4 vCPU = 100 %).
1. Alltägliche Oberfläche: in beiden Modi flüssig, aber nicht zum selben Preis
Wir haben die Android-Einstellungen geöffnet und 20-mal mit adb shell input swipe nach oben und unten
gescrollt, dann den eigenen Bildbericht von Android mit adb shell dumpsys gfxinfo com.android.settings gelesen:
| Einstellungen, 20 Wischgesten | GPU | Software |
|---|---|---|
| Gezeichnete Bilder | 1.045 | 1.047 |
| Ruckelnde Bilder | 1 (0,10 %) | 1 (0,10 %) |
| Bildzeit, 50. / 90. / 99. Perzentil | 17 / 18 / 18 ms | 17 / 17 / 18 ms |
| Server-CPU | 4,2 % | 17,3 % |
Für eine normale App mit Listen, Schaltflächen und Text ist die CPU eines modernen Servers schnell genug, um den Bildschirm allein zu zeichnen. Der Unterschied liegt im Preis: Software-Rendering machte den gesamten Server etwa viermal so ausgelastet. Wenn Ihre Tests mehrere Instanzen betreiben oder den Bildschirm aufzeichnen, fehlt diese CPU an anderer Stelle.
2. 3D: wo die GPU den Unterschied macht
Wir haben zwei Open-Source-Apps aus F-Droid verwendet: Shader Editor, der einen GLSL-Shader im Vollbild zeichnet und seine Bildrate anzeigt, und SuperTuxKart, ein 3D-Kartrennspiel. In Shader Editor haben wir den Standard-Shader (sehr leicht) und eine Raymarching-Szene (Kugeln, weiche Schatten, Nebel) ausgeführt, die wir für diesen Test geschrieben haben.
| Bilder pro Sekunde (CPU des Servers) | GPU | Software |
|---|---|---|
| Shader Editor, Standard-Shader | 60,0 fps (4,0 %) | 60,1 fps (64,4 %) |
| Shader Editor, Raymarching-Shader | 58,4 fps (1,8 %) | 7,2 fps (98,1 %) |
| SuperTuxKart-Tutorial, 1920×1080 | 60,0 fps (4,7 %) | 19,2 fps (95,2 %) |
| SuperTuxKart beim Fahren, mit scrcpy aufgezeichnet | 59,2 fps | 16,1 fps |
Mit der GPU bleiben die 3D-Szenen bei den 60 fps des Bildschirms, und die CPU ist fast im Leerlauf. Im Software-Modus sind die vier vCPU voll ausgelastet und die Bildrate fällt auf 7 bis 19 fps: Ein Spiel ist nicht mehr spielbar, und ein gleichzeitig laufender UI-Test würde ebenfalls ausgebremst. Während ein Spiel lief, nutzte der Redroid-Container in beiden Modi etwa 1,4 GB RAM, und Docker zählte 10 % eines Kerns mit der GPU gegenüber 381 % (fast vier Kerne) im Software-Modus.
adb exec-out screencap: GPU links (die App zeigt 56 fps), Software rechts (7 fps). Das Bild ist identisch, nur die Geschwindigkeit ändert sich.3. Startzeit
Wir haben docker run gestoppt, bis Android sys.boot_completed=1 meldete, dreimal pro Modus, jedes Mal mit
einem leeren Datenordner:
| Start bis „bereit” | Lauf 1 | Lauf 2 | Lauf 3 |
|---|---|---|---|
| GPU | 12,7 s | 13,3 s | 12,8 s |
| Software | 7,0 s | 6,5 s | 7,0 s |
Der GPU-Modus startet etwa 6 Sekunden langsamer, weil der Grafiktreiber beim Start geladen und eingerichtet
wird. Für einen CI-Job, der für jeden Lauf ein frisches Android startet, rechnen Sie mit etwa 13 Sekunden,
bevor adb Ihre App installieren kann.
4. Android vom eigenen Computer aus sehen und steuern
Redroid hat keinen eigenen Bildschirm: Sie nutzen es wie ein per USB-Kabel angeschlossenes Smartphone, über ADB.
- Screenshots:
adb exec-out screencap -p > screen.png, die Methode, die wir für die Bilder oben verwendet haben. - Live-Bildschirm, Maus und Tastatur: scrcpy (Open Source, von Genymobile) zeigt den Android-Bildschirm
in einem Fenster an und überträgt Ihre Klicks und Tasten. Es arbeitet über ADB und funktioniert daher mit
Redroid. Auf dem Server haben wir es ohne Fenster genutzt, um die Videos dieses Artikels aufzuzeichnen:
scrcpy -s 127.0.0.1:5555 --no-window --no-audio --record=run.mp4 --time-limit=7. - UI-Automatisierung:
adb shell input(Tippen, Wischen, Text) hat jeden Test dieses Artikels gesteuert, undadb shell uiautomator dumpliefert den View-Baum des Bildschirms. Appium (Treiber UiAutomator2), Espresso und Maestro verbinden sich auf dieselbe Weise mit einem ADB-Gerät; in diesem Test haben wir sie nicht ausgeführt.
Öffnen Sie den ADB-Port niemals zum Internet: Das ADB von Redroid hat kein Passwort und gibt volle
Kontrolle über das Android-System. Wir veröffentlichen es nur auf der lokalen Adresse des Servers
(-p 127.0.0.1:5555:5555) und erreichen es über einen SSH-Tunnel:
# auf Ihrem Computer
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. Was Sie vor dem Start wissen sollten
- Das ist x86_64-Android. In Java oder Kotlin geschriebene Apps laufen unverändert. Apps und Spiele mit
nativem Code, der nur für ARM gebaut ist (viele Spiele), brauchen eine Übersetzungsschicht: Das
Redroid-Image meldet ARM-Unterstützung (
arm64-v8a) über eine solche Schicht, aber wir haben keine reinen ARM-Apps getestet, und sie werden langsamer sein und können fehlschlagen. - Kein Google Play Store. Das offizielle Image enthält keine Google-Dienste. Installieren Sie Ihre eigenen
APKs mit
adb installoder Open-Source-Apps aus F-Droid, so wie wir. Apps, die die Google-Play-Dienste brauchen, funktionieren nicht ohne Weiteres. - Für Tests und Automatisierung, nicht um Smartphones vorzutäuschen. Redroid teilt Apps mit, dass es ein virtuelles Gerät ist. Es ist für Entwicklung, Tests und den Betrieb Ihrer eigenen Werkzeuge gedacht, nicht dafür, viele „Smartphones” für mehrere Konten zu betreiben, was die meisten App-Nutzungsbedingungen verbieten.
- Keine Kamera, kein GPS, keine SIM. Sensoren fehlen oder werden simuliert; testen Sie sie auf einem echten Gerät.
6. Welches Angebot?
Mit der GPU nutzte eine Android-Instanz unter 5 % unserer 4 vCPU und etwa 1,4 GB RAM, selbst in einem 3D-Spiel. iGPU Start (2 vCPU, 8 GB RAM, 14,99 € netto pro Monat) reicht für eine Android-Instanz mit Ihren Testwerkzeugen daneben. iGPU Power (4 vCPU, 14 GB RAM, doppelter GPU-Anteil von Start, 29,99 € netto pro Monat) ist die bessere Wahl, um mehrere Android-Instanzen parallel zu betreiben (eine pro Testjob), 3D-Apps und Spiele zu testen oder während der Tests den Bildschirm aufzuzeichnen. iGPU Pro (6 vCPU, 14 GB, Perf 3, 44,99 €) bringt mehr GPU und CPU für größere Testfarmen.
Ohne GPU müsste derselbe Server seine gesamte CPU für das Zeichnen aufwenden, sobald eine App 3D nutzt.
7. Einrichtung auf einem Linux-GPU-Server
Lieber sofort einsatzbereit? Fragen Sie bei der Bestellung per E-Mail danach (contact@linuxgpu.eu): Wir können Ihnen den Server mit Redroid vorinstalliert und für GPU-Rendering eingerichtet liefern. Sie verbinden sich nur noch per ADB über SSH und installieren Ihre App.
So richten Sie es selbst unter Debian 13 ein:
-
Laden Sie den binder-Treiber von Android (Teil des Debian-Kernels) und behalten Sie ihn beim Start bei:
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 -
Installieren Sie Docker und ADB (
apt install docker.io adb) und starten Sie dann Redroid mit GPU-Rendering: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 -
Prüfen Sie, ob Android die GPU nutzt:
adb connect 127.0.0.1:5555 && adb shell dumpsys SurfaceFlinger | grep GLESsollte „Mesa Intel(R) UHD Graphics 770” anzeigen. „SwiftShader” bedeutet Software-Rendering. -
Verbinden Sie sich von Ihrem Computer über den SSH-Tunnel oben, installieren Sie Ihre APK mit
adb installund starten Sie Ihre Tests.
Um Android in einen sauberen Zustand zurückzusetzen, entfernen Sie den Container und seinen Datenordner und starten Sie ihn neu.
Für Browser-Tests auf derselben Art von Server lesen Sie GPU-beschleunigte Selenium- & Playwright-Tests und Chrome mit GPU auf Linux-Server starten (headless). Wie ein Container die GPU einer virtuellen Maschine nutzt, erklärt GPU-Cloud: VM oder Container, dedizierte oder geteilte GPU?
Ausprobieren
Zu den Angeboten: iGPU Start kostet 14,99 € und iGPU Power 29,99 € netto pro Monat.