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>
5.5 KiB
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, 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.