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>
52 lines
2.4 KiB
Markdown
52 lines
2.4 KiB
Markdown
# 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.
|