Phase 0: Repo-Gerüst, Dokumentation und Machbarkeits-Spike

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>
This commit is contained in:
Stefan
2026-08-09 17:25:36 +02:00
co-authored by Claude Opus 5
commit ad2c98443b
21 changed files with 2818 additions and 0 deletions
+148
View File
@@ -0,0 +1,148 @@
# 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](https://github.com/waydroid/waydroid/discussions/1301) ·
[ArchWiki: Waydroid](https://wiki.archlinux.org/title/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](https://source.android.com/docs/core/virtualization/usecases) ·
[Run-Linux-on-Android-Guide: AVF](https://github.com/lfdevs/run-linux-on-android-guide/blob/main/docs/en-US/avf-linux.md)
---
## 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 515 % 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](machbarkeit.md#warum-app-daten-nicht-sicherbar-sind):
1. Es gibt kein Verzeichnis, das App und Termux beide beschreiben können.
`/sdcard/Android/data` ist seit Android 11 auch mit `MANAGE_EXTERNAL_STORAGE` gesperrt,
`/data/data/<pkg>` gehört einer fremden UID mit Modus 0700.
2. 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](https://github.com/Genymobile/scrcpy/blob/master/doc/virtual_display.md)
**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](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.