# 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 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](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/` 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= --start-app=` 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.