StefanandClaude Opus 5
ad2c98443b
Vier Beweise, die das Projekt tragen, als eigenständig lauffähige Skripte:
S1 Plasma Mobile in proot über genestetes kwin_wayland im X11-Backend.
Fällt selbsttätig auf startplasmamobile und dann auf XFCE zurück, damit
ein Fehlschlag eindeutig Plasma zuzuordnen ist und nicht der Umgebung.
S2 Mikrofon über PulseAudio mit OpenSL-Quelle. Misst den Pegel statt nur die
Dateigröße — der typische Fehlschlag ist eine formal korrekte WAV-Datei
voller Stille.
S3 Virtuelle PipeWire-Kamera per GStreamer-pipewiresink, ohne Kernel-Modul.
Setzt die Firefox-Einstellung vorab, damit der Test nicht an einem
vergessenen Häkchen scheitert.
S4 Intent-Handoff mit lauffähiger Mini-Bridge: xdg-open-Handler für geo:,
tel: und sms:, Token-Authentifizierung, feste Liste erlaubter Schemata.
provision/provision.sh setzt die Hintergrundbeschränkungen per ADB und benennt,
was ADB nicht kann und von Hand erledigt werden muss.
Dokumentiert sind auch die sieben verworfenen Wege — Waydroid, AVF, QEMU, SIP,
APK-Daten-Redirect, Fenster-Durchreichung und der Android-Server — mit Belegen,
damit sie nicht erneut durchdacht werden müssen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
3.7 KiB
Phase 0 — Machbarkeits-Spike
Vier Annahmen tragen das gesamte Projekt. Scheitert eine, sieht alles Weitere anders aus — und das will man vor dem Bau der Infrastruktur wissen, nicht danach.
Der Code hier ist bewusst Wegwerf-Code. Was zählt, sind die Protokolle: sie werden
später zur Grundlage der Setup-Skripte in rootfs/.
| Beweis | Wenn er scheitert | |
|---|---|---|
| S1 | Plasma Mobile läuft in proot (genestetes KWin) | XFCE-Profil wird Hauptweg; Kamera-Portal, Bildschirmtastatur und Telefonie-Oberfläche ändern sich mit |
| S2 | Mikrofon-Eingang erreicht die Linux-Seite | Keine Videocalls, keine Sprachaufnahme, keine Spracheingabe |
| S3 | Virtuelle PipeWire-Kamera ohne Kernel-Modul | Kamera nur in einer eigenständigen App, keine Browser-Videocalls |
| S4 | Intent-Handoff Linux → Android-App | Keine Navigation aus dem Linux-Adressbuch |
Dazu der Übernacht-Test: überlebt der Stack eine Nacht mit gesperrtem Bildschirm? Scheitert er, ist das ein früher Warnschuss fürs Gesamtkonzept, kein Detail.
Voraussetzungen
- Android-Telefon, Adreno 6xx/7xx bevorzugt (Turnip-Pfad)
- Termux von F-Droid oder GitHub — nicht aus dem Play Store, die Fassung dort ist veraltet und unbrauchbar
- Einmalig
provision/provision.shvom PC, plus die dort genannten Handgriffe von Hand - Etwa 6 GB freier Speicher (Debian-Rootfs, Plasma Mobile, Firefox)
- Geduld beim ersten Lauf: rund 1 GB Pakete
Ablauf
# Einmalig, vom PC mit angeschlossenem Telefon
./provision/provision.sh
# Auf dem Telefon in Termux
bash spike/00-bootstrap-termux.sh
# Beweise in dieser Reihenfolge — S1 zuerst, weil er der wackligste ist
bash spike/01-s1-plasma-mobile.sh
bash spike/02-s2-mikrofon.sh
bash spike/03-s3-pipewire-kamera.sh
bash spike/04-s4-intent-handoff.sh
Jedes Skript fragt am Ende nach deiner Beurteilung und schreibt sie nach
spike/out/ergebnisse.tsv. Rohprotokolle liegen daneben in spike/out/*.log.
Übertrage die Ergebnisse anschließend nach docs/spike-protokoll.md.
spike/out/ ist absichtlich nicht im Repo — die Auswertung gehört dorthin, nicht die Rohdaten.
Stellschrauben
| Variable | Vorgabe | Wofür |
|---|---|---|
HPOS_BREITE / HPOS_HOEHE |
1080 / 2340 |
Virtuelle Auflösung. Volle Panel-Auflösung ist für einen Telefon-Desktop zu viel Fläche |
HPOS_DAUER |
6 |
Sekunden Aufnahme in S2 |
HPOS_ZIEL |
Brandenburger Tor, Berlin | Navigationsziel in S4 |
HPOS_BEGLEIT_APP |
leer | Paketname einer Overlay-App, die in S4 vor der Navigation startet |
Beispiel:
HPOS_BEGLEIT_APP=de.blitzer HPOS_ZIEL="Kölner Dom" bash spike/04-s4-intent-handoff.sh
Wenn etwas schiefgeht
S1 startet nicht. Das Skript probiert von selbst zwei Wege und fällt am Ende auf XFCE zurück. Läuft XFCE, dann tragen X-Server und GPU-Pfad — der Fehlschlag liegt dann eindeutig bei Plasma. Läuft auch XFCE nicht, liegt es an X-Server oder GPU.
S2 erzeugt eine Datei ohne Ton. Der häufigste und tückischste Fehlschlag. Das Skript
misst deshalb den Pegel. Ursache ist meist eine fehlende Mikrofonberechtigung für
Termux:API oder ein Termux-Build ohne module-sles-source.
S3: Firefox sieht die Kamera nicht. Prüfen, ob xdg-desktop-portal-kde läuft — die
GTK- und wlr-Portale können das Kamera-Portal nicht bedienen. In about:config muss
media.webrtc.camera.allow-pipewire auf true stehen; das Skript setzt es vorab.
S4: kein Empfänger für den Intent. Ohne installierte Navigations-App gibt es nichts,
was den geo:-Intent annehmen könnte. Das ist kein Fehler der Brücke.
Aufräumen
pkill -f 'termux-x11|virgl_test_server|kwin_wayland|pipewire|bridge-mini.py'
pulseaudio --kill