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>

docs/architektur.md

@@ -0,0 +1,109 @@
+# Architektur
+
+## Überblick
+
+```
+┌─ Telefon (Stock-Android, unrooted) ────────────────────────────────┐
+│                                                                    │
+│  ┌────────────────────────┐   ┌────────────────────────────────┐  │
+│  │  HPOS Bridge (APK)     │   │ Termux (+:API, :X11, :Boot)    │  │
+│  │  ZUSTANDSLOS           │   │  proot → Debian 13 Trixie      │  │
+│  │  · Default-SMS-App     │◄──┤    Plasma Mobile (KWin nested) │  │
+│  │  · Default-Dialer      │ws │    PipeWire  ← virt. Kamera    │  │
+│  │  · Kamera-Server       │   │    plasma-dialer + spacebar    │  │
+│  │  · NFC-Reader, Sensoren│   │    hpos-daemon (Backup/Web-UI) │  │
+│  │  · Installer + Updater │   │    appmanager (Intent-Handoff) │  │
+│  └────────────────────────┘   └────────────────────────────────┘  │
+│         localhost:8474                                             │
+│  /sdcard/hpos-backup/  ← restic-Repo, überlebt Termux-Deinstall   │
+└──────────────────────────────┬─────────────────────────────────────┘
+                               │ optional
+                    ┌──────────┴───────────────────────┐
+                    │ Backup-Ziel außer Haus           │
+                    │ SFTP oder rest-server            │
+                    │ reines restic-Backend, kein Code │
+                    └──────────────────────────────────┘
+```
+
+Das Telefon ist vollständig eigenständig. Das externe Backup-Ziel ist die **einzige**
+optionale Außenanbindung — kein Dienst, von dem der Betrieb abhängt.
+
+## Die zwei tragenden Regeln
+
+### 1. Der Bridge-Layer ist zustandslos
+
+Die Android-Seite speichert keine Nutzdaten. SMS, Anrufliste, Kontakte, Fotos — alles
+wird sofort ins Linux durchgereicht und *nur dort* persistiert.
+
+Der Grund ist nicht Eleganz, sondern Notwendigkeit: App-private Daten auf Android sind
+ohne Root **nicht sicherbar**. Gäbe es zwei Orte, an denen Daten liegen, wäre das Backup
+strukturell unvollständig. Es gibt deshalb genau einen Ort.
+
+Praktische Folge: Die Android-Seite darf jederzeit plattgemacht werden, ohne dass ein
+Byte Nutzdaten verloren geht. Das ist zugleich der Abschlusstest des ganzen Projekts.
+
+### 2. Keine Serverabhängigkeit
+
+Kein Produktbestandteil darf fremde Infrastruktur voraussetzen. Ein Projekt, das ein
+Rechenzentrum braucht, benutzt außer dem Autor niemand.
+
+## Warum D-Bus-Shims statt eigener Anwendungen
+
+Der Linux-Teil der Bridge schreibt **keine** eigenen Anwendungen für Telefonie, SMS,
+Akku, Standort oder Sensoren. Stattdessen implementiert er die Standard-D-Bus-Schnittstellen,
+die der Linux-Desktop ohnehin erwartet:
+
+| Shim | Ersetzt | Damit läuft unverändert |
+|---|---|---|
+| ModemManager | echtes Modem | `plasma-dialer`, `spacebar` |
+| UPower | Akku-Subsystem | Akkuanzeige, Energieverwaltung |
+| GeoClue | GPS | Karten, Zeitzone, Wetter |
+| iio-sensor-proxy | Sensoren | Rotation, Helligkeitsautomatik |
+
+Das spart nicht nur Arbeit — es bedeutet auch, dass jede Verbesserung upstream geschenkt
+ankommt und dass ein Gerätewechsel nur die Bridge berührt, nie die Anwendungsschicht.
+
+## Datenfluss: eingehende SMS
+
+```
+Mobilfunk → Android-Framework
+          → Bridge-APK (Default-SMS-Rolle, persistiert NICHTS)
+          → WebSocket 127.0.0.1:8474
+          → ModemManager-Shim
+          → spacebar  → Nachricht landet in der Linux-Datenbank
+                      → restic-Backup
+```
+
+## Datenfluss: Navigation aus dem Adressbuch
+
+```
+KAddressBook → xdg-open "geo:0,0?q=<adresse>"
+             → hpos-open (Handler)
+             → Bridge  → startet Begleit-App (Overlay)
+                       → am start VIEW google.navigation:q=<adresse>
+             → Google Maps im Vollbild auf dem Host
+```
+
+Bewusst **kein Streaming**: volles GPU, volles GPS, kein Akkuverbrauch fürs Encodieren,
+und Overlay-Apps funktionieren wie vorgesehen. Zurück ins Linux über den Task-Manager.
+
+## Speicherorte
+
+| Was | Wo | Warum |
+|---|---|---|
+| Debian-Rootfs, `$HOME`, alle Nutzdaten | `/data/data/com.termux/files/…` | Echtes ext4 mit Rechten und Symlinks. **Kein Image** — ein normaler Verzeichnisbaum |
+| restic-Repo | `/sdcard/hpos-backup/` | Überlebt eine Deinstallation von Termux, per USB/MTP erreichbar |
+| Zweitziel (optional) | SFTP / rest-server | Schützt gegen Verlust oder Diebstahl des Geräts |
+
+⚠️ Das Rootfs liegt in Termux' App-privatem Verzeichnis. **Termux zu deinstallieren
+löscht alles.** Deshalb liegt das Backup zwingend außerhalb.
+
+## Bekannte Grenzen
+
+Vollständig mit Belegen in [machbarkeit.md](machbarkeit.md), in Kürze:
+
+- **Anruf-Audio** bleibt auf dem Android-Pfad. Bedienung und Daten liegen im Linux,
+  der Ton kommt aus derselben Hörmuschel wie immer.
+- **Daten von Host-Apps** sind nicht sicherbar. Deshalb gehören dort nur konto-gebundene
+  Apps hin, bei denen "APK zurück plus anmelden" ein vollständiger Restore ist.
+- **Kontaktloses Bezahlen** bleibt Sache des Host-Android.

docs/machbarkeit.md

@@ -0,0 +1,112 @@
+# Machbarkeit ohne Root
+
+Was auf ungerootetem Stock-Android geht und was nicht — mit Belegen, damit niemand
+gegen eine Wand plant.
+
+Legende: ✅ bewiesen möglich · 🔬 im Spike zu beweisen · ❌ nachweislich unmöglich ·
+➖ bewusst außerhalb des Projekts
+
+## Basis
+
+| Funktion | | Weg |
+|---|---|---|
+| `$HOME` im echten Telefonspeicher, kein Image | ✅ | proot-distro legt einen normalen Verzeichnisbaum an |
+| Debian + Desktop mit GPU-Beschleunigung | 🔬 | Termux-X11 + Turnip/Zink (Adreno) bzw. virgl/ANGLE (Mali) |
+| Plasma Mobile in proot | 🔬 | **S1** — `kwin_wayland --x11-display` genestet; braucht dort weder DRM noch logind |
+| Backup, Snapshots, Einzeldatei-Restore, Web-UI | ✅ | restic + rclone + eigener Daemon |
+| Klonen auf neues Telefon per WLAN | ✅ | mDNS + restic-REST |
+
+## Telefonie und Nachrichten
+
+| Funktion | | Weg |
+|---|---|---|
+| SMS empfangen und senden | ✅ | Bridge als Default-SMS-App. Sideloaded → Play-Policy greift nicht |
+| Anrufe steuern: wählen, annehmen, auflegen, DTMF, Anrufliste | ✅ | Bridge als Default-Dialer (`InCallService`) |
+| **Anruf-Audio in die Linux-Umgebung leiten** | ❌ | `VOICE_CALL` erfordert `CAPTURE_AUDIO_OUTPUT` — System-App-Permission, seit Android 6 gesperrt; der Accessibility-Umweg wurde 2022 geschlossen |
+
+**Beleg:** [issuetracker 236553834](https://issuetracker.google.com/issues/236553834)
+
+Konsequenz: Audio bleibt auf dem Android-Pfad, dieselbe Hörmuschel wie immer. Bedienung
+und alle Daten liegen im Linux. Ein SIP-Aufbau als Umgehung wurde geprüft und verworfen
+(siehe [verworfene-entscheidungen.md](verworfene-entscheidungen.md)).
+
+## Medien
+
+| Funktion | | Weg |
+|---|---|---|
+| Mikrofon im Linux | 🔬 | **S2** — PulseAudio mit OpenSL-Source in Termux, `PULSE_SERVER` in den proot |
+| Kamera in Browser und Element (Videocall) | 🔬 | **S3** — virtuelle PipeWire-Kamera, reiner Userspace |
+| Kamera als `/dev/videoX` | ❌ | `v4l2loopback` ist ein Kernel-Modul → Root. Kein Userspace-Ersatz |
+
+**Beleg für den Kamera-Weg:** [PipeWire is the new v4l2loopback](https://www.ideasonboard.com/news/pipewire-is-the-new-v4l2loopback/) ·
+[PipeWire-Kamera in Firefox](https://jgrulich.cz/2024/01/30/how-to-use-pipewire-camera-in-firefox/)
+
+Ein GStreamer-`pipewiresink` mit `media.class=Video/Source` erzeugt einen Kamera-Node
+ohne Kernel-Modul. Firefox ab 122 nimmt ihn über `media.webrtc.camera.allow-pipewire`
+und `xdg-desktop-portal-kde` an.
+
+**Mikrofon-Konflikt:** Android vergibt das Mikro exklusiv an die Vordergrund-App.
+Solange Termux-X11 vorn ist, hat der Linux-Stack es. Bei einem Mobilfunk-Anruf hat die
+Telefonie Vorrang. Da es keine nativen Nutzer-Apps im Vordergrund gibt, tritt der
+Konflikt praktisch kaum auf.
+
+## Android-Apps auf dem Host
+
+| Funktion | | Weg |
+|---|---|---|
+| Host-App aus dem Linux mit Daten aufrufen | 🔬 | **S4** — `xdg-open`-Handler für `geo:`/`tel:`/`sms:` → Bridge → Intent |
+| Installierte Apps sichern und wiederherstellen | ✅ | `QUERY_ALL_PACKAGES` + `ApplicationInfo.sourceDir`; APKs unter `/data/app/…/base.apk` sind weltlesbar |
+| Banking- und TAN-Apps | ✅ | Nativ auf dem Host, Play Integrity ist dort intakt |
+| **App-Daten sichern** | ❌ | Siehe unten — zwei unabhängige K.-o.-Gründe |
+| Host-App als Fenster im Linux-Desktop | ➖ | Technisch möglich, bewusst verworfen |
+
+### Warum App-Daten nicht sicherbar sind
+
+Zwei Gründe, jeder für sich schon ausreichend:
+
+1. **Es gibt kein gemeinsames Verzeichnis.** Seit Android 11 ist `/sdcard/Android/data`
+   auch für Inhaber von `MANAGE_EXTERNAL_STORAGE` gesperrt; `/data/data/<pkg>` gehört
+   einer fremden UID mit Modus 0700. App und Termux haben keinen Ort, den beide
+   beschreiben können.
+   **Beleg:** [Storage updates in Android 11](https://developer.android.com/about/versions/11/privacy/storage)
+2. **APK-Patchen skaliert nicht.** Selbst mit einem solchen Verzeichnis müsste man in
+   beliebigen, obfuszierten APKs jeden I/O-Pfad umschreiben — `getFilesDir`,
+   `SharedPreferences`, `SQLiteOpenHelper`, dazu native Bibliotheken. Bei jedem
+   App-Update von vorn.
+
+**Konsequenz als Nutzungsregel:** Auf dem Host laufen nur konto-gebundene Apps, bei
+denen "APK zurück plus einmal anmelden" ein vollständiger Restore ist. Alles mit rein
+lokalen Daten bekommt eine Linux-Anwendung — TOTP etwa über KeePassXC statt einer
+Authenticator-App.
+
+## Hardware-Zugriff
+
+| Funktion | | Weg |
+|---|---|---|
+| Sensoren, Taschenlampe, Akku, GPS, Vibration | ✅ | Termux:API + Bridge |
+| NFC-Tags lesen und schreiben | ✅ | Bridge-APK |
+| Kontaktloses Bezahlen (HCE) | ➖ | Framework-only und Play-Integrity-gebunden. Bleibt Sache des Host-Android via Google Pay |
+
+## Hintergrundbetrieb
+
+Der Punkt, an dem das Konzept in der Praxis scheitern könnte. Zwei Ebenen:
+
+**Android-Standardebene** — vollständig per ADB abschaltbar und neustartfest:
+
+```bash
+adb shell dumpsys deviceidle whitelist +com.termux
+adb shell cmd appops set com.termux RUN_IN_BACKGROUND allow
+adb shell cmd appops set com.termux RUN_ANY_IN_BACKGROUND allow
+adb shell am set-standby-bucket com.termux never
+adb shell settings put global adaptive_battery_management_enabled 0
+```
+
+Entwickleroptionen helfen hier **nicht** — sie betreffen nur gecachte Prozesse.
+
+**Herstellerebene** — nicht per ADB erreichbar, muss manuell erledigt werden. OxygenOS 12
+basiert auf ColorOS, dessen App-Einfrierung liegt unterhalb der Android-Mechanismen:
+Akku-Optimierung für Termux auf "Nicht optimieren", "Sleep Standby Optimization" aus,
+adaptive Akkunutzung aus, App im Task-Manager anpinnen.
+
+**Nachweis statt Annahme:** Der Stack muss eine Nacht überleben. Scheitert das, ist es
+ein früher Warnschuss für das Gesamtkonzept, kein Detail.

docs/redroid-anhang.md

@@ -0,0 +1,51 @@
+# Anhang: Android-Server mit redroid
+
+> **Nicht Teil des Produkts.** Verworfen als [V7](verworfene-entscheidungen.md#v7--android-server-im-rechenzentrum-redroid),
+> weil sein Zweck sich im Lauf der Planung aufgelöst hat. Hier dokumentiert für den Fall,
+> dass sich in der Praxis doch eine echte Lücke zeigt.
+
+## Wann das relevant wird
+
+Nur für Apps, die **beide** Bedingungen erfüllen:
+
+1. Ihre Daten liegen rein lokal, nicht bei einem Konto — ein Restore per "APK zurück plus
+   anmelden" würde also Daten verlieren.
+2. Es gibt keine brauchbare Linux-Anwendung als Ersatz.
+
+Vor dem Aufbau eines Servers erst prüfen, ob Bedingung 2 wirklich zutrifft. Der
+häufigste Kandidat, Authenticator-Apps, fällt weg: **KeePassXC** kann TOTP, liegt im
+Linux und ist damit vollständig im Backup.
+
+## Warum redroid und nicht Waydroid
+
+redroid ist explizit als *"Android in Cloud"* entwickelt: läuft in Docker, GPU-beschleunigt,
+remote-fähig, mehrere Instanzen parallel. Waydroid ist für den lokalen Desktop gedacht und
+kann kein Remote.
+
+Zitat aus der Projektdokumentation: *"It is more suitable than Waydroid as a cloud phone."*
+
+**Quelle:** [remote-android/redroid-doc](https://github.com/remote-android/redroid-doc)
+
+## Aufbau in Kürze
+
+- **Host:** x86_64 mit KVM, ~4 GB RAM je Instanz. Auf ARM-Hardware laufen Android-Apps
+  nativ ohne Übersetzung und damit schneller — aber dort fehlt die Werkzeugreife.
+- **ARM-Apps auf x86:** `libndk_translation` ist in den offiziellen redroid-Images
+  enthalten. Kostet Leistung, einzelne Apps vertragen es nicht.
+- **Play Services:** nachrüstbar, nötig für Push-Nachrichten.
+- **Streaming aufs Telefon:** scrcpy über `adb connect`, oder Moonlight/Sunshine für
+  geringere Latenz.
+- **Kamera und Mikrofon durchreichen:** Stream vom Telefon über einen Tunnel zum Server,
+  dort in `v4l2loopback` bzw. ein virtuelles Audio-Device — auf dem Server ist Root
+  verfügbar, dort ist das unproblematisch.
+- **Backup:** Container-Daten liegen im Server-Dateisystem, restic sichert sie wie jedes
+  andere Verzeichnis.
+
+## Was es kostet
+
+Ein Server, ein Tunnel, ein Streaming-Frontend, ein zweiter Zweig im Backup-System —
+und Mobilfunkvolumen plus Akku im laufenden Betrieb. Dazu die Abhängigkeit von fremder
+Infrastruktur, die dem Projekt sonst überall erspart bleibt.
+
+**Play Integrity** schlägt in Containern in der Regel fehl. Banking-Apps gehören deshalb
+auf den Host, nicht hierher.

docs/spike-protokoll.md

@@ -0,0 +1,146 @@
+# Spike-Protokoll — Phase 0
+
+Ergebnisse der vier Machbarkeitsbeweise. **Dies ist das wichtigste Dokument des
+Projekts**, solange Phase 0 läuft: alle folgenden Entscheidungen bauen darauf auf.
+
+Ehrlich ausfüllen, auch und gerade bei Fehlschlägen. Ein sauber dokumentierter
+Fehlschlag ist wertvoller als ein geschöntes Ergebnis.
+
+## Gerät
+
+| | |
+|---|---|
+| Modell | OnePlus 7 Pro (`guacamole`) |
+| SoC / GPU | Snapdragon 855 / Adreno 640 |
+| RAM / Speicher | _(ausfüllen)_ |
+| ROM | Stock OxygenOS 12 (Android 12) |
+| Display | 3120 × 1440, virtuelle Auflösung im Test: _(ausfüllen)_ |
+| Akku | 4000 mAh, Baujahr 2019 — getauscht? _(ausfüllen)_ |
+| Datum des Tests | _(ausfüllen)_ |
+
+## Zusammenfassung
+
+| Beweis | Ergebnis | Konsequenz |
+|---|---|---|
+| **S1** Plasma Mobile in proot | ⬜ offen | |
+| **S2** Mikrofon im Linux | ⬜ offen | |
+| **S3** Virtuelle PipeWire-Kamera | ⬜ offen | |
+| **S4** Intent-Handoff | ⬜ offen | |
+| **Übernacht-Test** Hintergrundbetrieb | ⬜ offen | |
+
+---
+
+## S1 — Plasma Mobile in proot
+
+**Beweisziel:** `kwin_wayland --x11-display` genestet in Termux-X11, darauf
+`plasma-mobile`. Startet, reagiert auf Touch, Maliit-Tastatur erscheint.
+
+**Wenn es scheitert:** XFCE-Profil wird Hauptweg. Dann braucht die Kamera
+`xdg-desktop-portal-gtk` statt `-kde`, die Tastatur wird `onboard`, und Telefonie
+braucht eine eigene Oberfläche statt `plasma-dialer`.
+
+| | |
+|---|---|
+| Ergebnis | _(offen)_ |
+| Startzeit bis Bedienoberfläche | |
+| Touch funktioniert | |
+| Maliit-Tastatur erscheint | |
+| Rotation | |
+| Fehlermeldungen | |
+
+---
+
+## S2 — Mikrofon im Linux
+
+**Beweisziel:** PulseAudio in Termux mit OpenSL-Source, `PULSE_SERVER` in den proot,
+`parecord` nimmt hörbar auf.
+
+**Wenn es scheitert:** keine Videocalls in Element und im Browser, keine Sprachaufnahme,
+keine Spracheingabe. Videotelefonie nur noch nativ auf dem Host per Intent-Handoff.
+Deutliche Abwertung des Produkts.
+
+| | |
+|---|---|
+| Ergebnis | _(offen)_ |
+| Verwendetes PulseAudio-Modul | |
+| Aufnahme hörbar | |
+| Latenz / Aussetzer | |
+| Verhalten bei gesperrtem Bildschirm | |
+
+---
+
+## S3 — Virtuelle PipeWire-Kamera
+
+**Beweisziel:** GStreamer-`pipewiresink` mit `media.class=Video/Source` erzeugt einen
+Kamera-Node; Firefox mit `media.webrtc.camera.allow-pipewire` sieht ihn auf
+`webcamtests.com` und zeigt Bild.
+
+**Wenn es scheitert:** keine Videocalls im Linux, Kamera nur über eine eigenständige App.
+
+| | |
+|---|---|
+| Ergebnis | _(offen)_ |
+| Node erscheint in `wpctl status` | |
+| Firefox sieht die Kamera | |
+| Bild kommt an | |
+| Bildrate / Auflösung | |
+
+⚠️ **Pop-up-Kamera:** Die Frontkamera des OnePlus 7 Pro fährt motorisiert aus. Prüfen,
+dass der Node nicht spekulativ die Frontkamera öffnet — das ist Mechanik und Verschleiß.
+
+---
+
+## S4 — Intent-Handoff
+
+**Beweisziel:** Eine Adresse aus dem Linux startet per `geo:`-Intent die Navigation auf
+dem Host, mit vorher gestarteter Overlay-Begleit-App.
+
+**Wenn es scheitert:** keine Navigation aus dem Linux-Adressbuch; Host-Apps müssen
+manuell über den Task-Manager gestartet werden.
+
+| | |
+|---|---|
+| Ergebnis | _(offen)_ |
+| `geo:`-URI startet Maps | |
+| `google.navigation:` startet Turn-by-Turn direkt | |
+| Overlay der Begleit-App liegt über Maps | |
+| `SYSTEM_ALERT_WINDOW` erteilt | |
+| Rückweg ins Linux über Task-Manager | |
+
+---
+
+## Übernacht-Test — Hintergrundbetrieb
+
+**Beweisziel:** Der komplette Stack überlebt eine Nacht mit gesperrtem Bildschirm.
+
+**Wenn es scheitert:** früher Warnschuss für das Gesamtkonzept, kein Detail. OxygenOS 12
+basiert auf ColorOS mit aggressiver App-Einfrierung unterhalb der Android-Mechanismen.
+
+| | |
+|---|---|
+| ADB-Maßnahmen gesetzt (`provision.sh`) | |
+| Herstellerseitige Handgriffe erledigt | |
+| Prozesse nach 8 h noch da | |
+| Akkuverbrauch über Nacht | |
+| Was wurde beendet | |
+
+---
+
+## Leistungsmessungen
+
+| Messung | Wert |
+|---|---|
+| `vkcube` läuft | |
+| `glmark2` Score | |
+| GPU-Treiberpfad (Turnip / Zink / virgl / Software) | |
+| Virtuelle Auflösung | |
+| Akku: Leerlauf mit laufendem Stack | |
+| Akku: Desktop aktiv | |
+| Thermik / Throttling | |
+
+---
+
+## Fazit und Entscheidungen
+
+_(Nach Abschluss ausfüllen: welches Desktop-Profil wird gebaut, welche Fallbacks greifen,
+was ändert sich am Plan.)_

docs/verworfene-entscheidungen.md

@@ -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 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.