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>
149 lines
6.8 KiB
Markdown
149 lines
6.8 KiB
Markdown
# 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/<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.
|