Der Videostream vom Handy wurde bisher komplett von der CPU entpackt. Mit scrcpy 5.0 übernimmt das die Grafikeinheit, unter Linux per VA-API. Die Neuerung betrifft nur die Seite des Computers, nicht das Handy. Die Release-Notes von scrcpy 5.0 versprechen eine um den Faktor zehn geringere CPU-Last. Auch OMG! Ubuntu berichtet über das Release, und auf Reddit läuft im Subreddit r/Android ein Thread dazu.

Die Hardware-Dekodierung ist ab Werk aktiv, ein zusätzlicher Schalter ist nicht nötig. scrcpy sucht sich den ersten passenden Decoder selbst und fällt andernfalls auf Software zurück. Wer eingreifen möchte, nutzt laut Dokumentation --hwdec, etwa mit auto, vaapi oder disabled. Daneben gibt es Kleinkram: Der Audio-Capture-Modus greift nun alle Quellen ab, ANDROID_SERIAL funktioniert im OTG-Modus, und Shift sowie AltGr verschwinden im UHID-Modus nicht mehr.

Windows-User bekommen erstmals native ARM64-Builds. Für Linux ist das nicht relevant, hier zählt die Grafik. Bei mir ist scrcpy 5.0 gerade per Update auf dem Arch-Notebook gelandet, ein sudo pacman -Syu genügt. Wer das Programm noch nicht installiert hat, holt sich das scrcpy-Paket von Arch Linux mit sudo pacman -S scrcpy. Der Quelltext liegt im GitHub-Repository von scrcpy.

Läuft die Hardware-Dekodierung wirklich?

Damit VA-API etwas zu tun hat, braucht ihr auf dem Rechner einen passenden Treiber. Bei Intel ist das intel-media-driver, bei AMD reicht Mesa. Was die ArchWiki zur Hardware-Videobeschleunigung schreibt, gilt hier eins zu eins, Details zu den Treibern stehen dort. Bei mir arbeitet eine Intel Iris Xe, und scrcpy meldet beim Start brav, dass es VA-API nutzt:

INFO: Interop: vaapi
INFO: Video decoding: vaapi
INFO: Texture (VA-API): 1080x2424

Ich wollte es genauer wissen und habe das Pixel 10 per USB verbunden. Während scrcpy lief, habe ich den Bildschirm sechsmal rauf und runter gescrollt und die verbrauchte CPU-Zeit des scrcpy-Prozesses gemessen. Mit --hwdec=disabled waren es rund 2,9 Sekunden, mit --hwdec=auto nur 0,37 Sekunden. Das ist etwa Faktor acht. Der Test lief zweimal mit gleichem Ergebnis, der Stream war auf 60 FPS begrenzt.

Aurynk: scrcpy mit grafischer Oberfläche

Wer nicht gern Kommandozeilen-Parameter tippt, findet in Aurynk eine hübsche Oberfläche. Die GTK4-App mit Libadwaita-Optik (Quelltext auf GitHub) koppelt Android-Geräte per drahtlosem Debugging, zeigt technische Daten an und startet scrcpy auf Knopfdruck. Sie steht auf Flathub, die Installation läuft wie gewohnt:

$ flatpak install flathub io.github.IshuSinghSE.aurynk

Zum Koppeln öffnet ihr auf dem Handy die Entwickleroptionen und aktiviert das Debugging über WLAN. Aurynk bietet zwei Wege an: einen QR-Code, den ihr mit dem Handy scannt, oder die manuelle Eingabe von IP-Adresse, Port und sechsstelligem Kopplungscode. Ich habe die manuelle Variante genommen. Anschließend zeigt Aurynk Name, Android-Version, RAM, Speicher und Akkustand des Geräts an.

Ganz glatt lief es bei mir allerdings nicht. Aurynk meldete nach dem Koppeln, dass es den Verbindungsport nicht automatisch findet, und zeigte das Gerät nicht an. Geholfen hat ein Workaround: Zuerst habe ich mit adb connect die Verbindung zum Handy aufgebaut und danach in Aurynk noch einmal mit einem frischen Code gekoppelt. Dann tauchte das Pixel in der Liste auf.

Ein Haken bleibt: Das Flatpak bringt sein eigenes scrcpy mit, und das ist Version 3.3.3. Von der neuen Hardware-Dekodierung profitiert Aurynk daher vorerst nicht. Das ändert sich, sobald der Entwickler sein Paket aktualisiert. Wer die 5.0 jetzt schon nutzen möchte, startet scrcpy aus dem Arch-Paket direkt im Terminal. Das Spiegeln selbst funktioniert in Aurynk trotzdem tadellos.

Desktop-Modus: Multitasking auf dem Pixel

Mit --new-display legt scrcpy auf dem Handy ein virtuelles Display an und zeigt es als eigenes Fenster. Ich habe scrcpy --new-display=1920x1080/160 auf dem Pixel 10 mit Android 17 probiert. Heraus kommt ein Desktop mit Taskleiste. Apps öffnen dort erst als Fenster, wenn ihr sie per adb shell am start --display 37 --windowingMode 5 startet. Die 37 ist die ID, die scrcpy beim Start meldet.

Im Fenster laufen nun Browser, Taschenrechner und Stoppuhr nebeneinander, frei verschiebbar wie auf einem normalen Desktop. Auch mehrere Bildschirme gehen: Eine zweite scrcpy-Instanz bekam ein eigenes virtuelles Display, und beide liefen parallel. Die Fenster starteten allerdings im Handy-Hochformat, die gewünschte Größe habe ich per am task resize nachgezogen. Ganz ohne Gefrickel geht es also nicht.

Ein paar Tipps aus der Reddit-Diskussion lohnen sich ebenfalls: --turn-screen-off schaltet das Handy-Display aus, --stay-awake hält es wach, damit sich das Handy nicht sperrt und die Verbindung kappt, und --video-codec=h265 nutzt den sparsameren Codec. Bei mir lag der CPU-Bedarf mit H.265 und Hardware-Dekodierung bei 0,39 Sekunden, ohne bei 3,5 Sekunden. Kommentatoren nutzen scrcpy sogar zur Datenrettung bei kaputtem Touchscreen.

Ein Haken kam in der Diskussion mehrfach zur Sprache: Mit aktivierten Entwickleroptionen verweigern manche Banking-Apps den Dienst. Ein Kommentator schreibt, Android 17 QPR1 verhindere diese Prüfung auf Pixel-Geräten. Ich habe das nicht getestet. Andere nutzen die App Geto, die Entwickleroptionen pro App abschaltet, dabei bricht aber die ADB-Verbindung ab. Wer es braucht, sollte also vorher mit der eigenen Bank-App testen.

Dass sich ein Smartphone vom Desktop aus bedienen lässt, ist übrigens kein neuer Trick. Schon 2010 habe ich dafür ein Java-Programm aus dem xda-Forum bemüht, und Screenshots per adb vom Terminal schoss 2014 android-scrot. Wer sein Android-Gerät ohnehin als halben Linux-Rechner nutzt, dem sei außerdem der Überblick zur neuen Linux-VM für Android ans Herz gelegt.

Mein Fazit: Wer scrcpy unter Arch nutzt, sollte nach dem Update einmal in die Startmeldung schauen. Steht dort „Video decoding: vaapi“, sinkt die CPU-Last spürbar, was gerade bei Notebooks dem Akku guttut. Aurynk ist eine nette Hilfe für alle, die ungern im Terminal tippen. Spiegelt ihr euer Handy per scrcpy oder lieber mit einer anderen Lösung?

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.