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>
6.8 KiB
Verworfene Entscheidungen
Sieben naheliegende Wege wurden geprüft und begründet verworfen. Sie stehen hier, damit niemand — auch nicht der Autor in einem halben Jahr — von vorn anfängt zu überlegen.
Wer einen davon wiederbeleben will: gern, aber mit einem Argument, das hier noch nicht widerlegt ist.
V1 — Waydroid auf dem Gerät
Idee: Android-Apps in einem Container innerhalb der Linux-Umgebung, damit ihre Daten im Linux-Dateisystem liegen und ins Backup wandern.
Warum es nicht geht: Waydroid braucht binder und ashmem als Kernel-Module sowie
Root für die LXC-Container-Steuerung. proot ist reine Userspace-Emulation von chroot
und hat prinzipiell keinen Kernel-Zugriff.
Beleg: waydroid#1301 · ArchWiki: Waydroid
V2 — Waydroid in einer VM über AVF
Idee: Wenn proot keinen Kernel hat, dann eben eine echte VM. Die Android
Virtualization Framework gibt ungerooteten Apps Zugang zu KVM; in einer eigenen VM
liefert man den Gast-Kernel selbst, also mit binderfs — und bekäme Waydroid,
v4l2loopback, systemd und Root in der VM, bei intaktem Host.
Der Ansatz funktioniert tatsächlich: android.permission.MANAGE_VIRTUAL_MACHINE ist
seit Android 15 per adb shell pm grant erteilbar, was gut zum Provisioning-Schritt passt.
Warum es trotzdem verworfen wurde — der Preis:
| Qualcomm fällt raus | Snapdragon 8 Elite lässt nur signierte VMs zu. Custom-Linux-VMs gibt es nur auf Tensor, Dimensity 9400, Exynos 2500 |
| GPU nur auf Pixel 10 | Gfxstream ist per Overlay-Flag Pixel-10-exklusiv, 47 von 142 Vulkan-Extensions, noch instabil. Auf Pixel 8/9 nur Software-Rendering |
| Disk-Image | AVF erzwingt ein Image — im Widerspruch zum Ziel "echter Speicher, kein Image" |
Das Projekt wäre damit auf ein einziges, teures Gerät festgenagelt worden. Nachdem die Android-Apps ohnehin auf den Host gewandert sind (siehe V7), entfiel auch der Zweck.
Beleg: AOSP: AVF-Anwendungsfälle · Run-Linux-on-Android-Guide: AVF
V3 — QEMU ohne Beschleunigung
Idee: Android in QEMU emulieren, wenn schon keine Virtualisierung verfügbar ist.
Warum es nicht geht: TCG-Emulation läuft bei etwa 5–15 % der nativen Geschwindigkeit.
Ein Android-Gast bräuchte Minuten zum Booten und liefe mit wenigen Bildern pro Sekunde.
/dev/kvm steht gewöhnlichen Apps nicht zur Verfügung — der einzige unrooted Zugang zu
KVM ist AVF, also V2.
V4 — SIP-Telefonie im Linux
Idee: Da Anruf-Audio nicht abgreifbar ist, die Rufnummer vom Telefon lösen — Portierung zu einem VoIP-Provider, Asterisk als Registrar, Linphone im Linux. Dann telefoniert man tatsächlich im Linux statt nur die Oberfläche dort zu haben.
Warum es verworfen wurde: Der einzige echte Zugewinn wäre das Audio im Linux gewesen. Der Preis stand in keinem Verhältnis.
| Ohne SIP gewonnen | Ohne SIP verloren |
|---|---|
| Anrufe ohne Datenverbindung, ohne Tunnel, ohne Server | Gesprächsaufzeichnung im Linux |
| Keine dauerhafte Registrierung → deutlich weniger Akkuverbrauch | Eigenes Audio-Routing |
| Keine Portierung, kein Wochen-Vorlauf, keine laufenden Kosten | "Desktop klingelt mit" |
| Notrufe trivial korrekt statt Sonderfall | |
| Gesprächsqualität über Mobilfunk statt VoIP über mobile Daten | |
| Eine Anruf-UI statt zwei Ebenen |
Alles Verlorene ist Komfort, nichts davon strukturell.
Nachrüstbar: ja, rein additiv und serverseitig, keine Architekturkopplung.
V5 — APK patchen, damit Daten ins Linux-$HOME wandern
Idee: APKs beim Installieren umschreiben, sodass ihr Datenverzeichnis im Linux liegt und mitgesichert wird.
Warum es nicht geht — zwei unabhängige K.-o.-Gründe, siehe machbarkeit.md:
- Es gibt kein Verzeichnis, das App und Termux beide beschreiben können.
/sdcard/Android/dataist seit Android 11 auch mitMANAGE_EXTERNAL_STORAGEgesperrt,/data/data/<pkg>gehört einer fremden UID mit Modus 0700. - Man müsste in beliebigen, obfuszierten APKs jeden I/O-Pfad umschreiben — inklusive nativer Bibliotheken, und bei jedem App-Update erneut.
Was von der Idee überlebt hat: der Installationsstand. Paketliste und APK-Archiv lassen sich sichern und beim Restore nachinstallieren. Für konto-gebundene Apps ist das ein vollständiger Restore.
V6 — Host-Apps als Fenster im Linux-Desktop
Idee: scrcpy --new-display=<auflösung> --start-app=<paket> legt ein virtuelles
Display an, startet die App dorthin und streamt nur diese. Jede App bekäme ihr eigenes
Fenster im Plasma-Desktop, ohne Vollbild-Umschalten.
Es funktioniert. Ohne Root, ab Android 11. Beleg: scrcpy: virtual_display
Warum es trotzdem verworfen wurde: Es braucht dauerhaft Shell-Rechte über einen Shizuku-artigen Kanal — und der überlebt ohne Root keinen Neustart. Damit wäre ein permanent bröckelnder Privilegienkanal das Fundament eines Alltagsgeräts geworden.
Der Verzicht hat mehr eingebracht als gekostet: das gesamte Produkt kommt jetzt ohne Privilegienkanal im Dauerbetrieb aus. ADB wird nur noch für die einmalige Ersteinrichtung gebraucht. Für Navigation, Teilen und Scannen ist der Intent-Handoff ohnehin die bessere Lösung — volles GPU, volles GPS, und Overlay-Apps funktionieren, was über einem gestreamten Fenster gar nicht ginge.
V7 — Android-Server im Rechenzentrum (redroid)
Idee: Android-Apps in einem redroid-Container auf einem eigenen Server, aufs Telefon gestreamt. Container-Daten liegen serverseitig und sind damit vollständig sicherbar.
Warum es verworfen wurde: Der Zweck hat sich im Lauf der Planung selbst aufgelöst.
| Ursprünglicher Zweck | Wo es tatsächlich gelandet ist |
|---|---|
| Banking- und TAN-Apps | Host — dort ist Play Integrity intakt, in einem Container scheitern sie ohnehin |
| WhatsApp, Teams, Signal | Host bzw. Matrix/Element nativ im Linux |
| Navigation | Host per Intent-Handoff |
| Apps mit rein lokalen Daten | Letzter verbleibender Fall — und auch der schrumpft: TOTP deckt KeePassXC im Linux besser ab. Übrig bleiben Offline-Notizen und Spielstände |
Dafür lohnen ein Server, ein Tunnel, ein Streaming-Frontend und ein eigener Zweig im Backup-System nicht.
Bleibt dokumentiert: redroid-anhang.md — falls sich in der Praxis doch eine echte Lücke zeigt, ist es ein Nachtrag, kein Umbau.
Daraus wurde eine Regel: Kein Produktbestandteil darf eine Serverabhängigkeit einführen. Einzige Ausnahme ist das optionale Backup-Ziel außer Haus.