Hacker-Software/linux-on-android-without-root

Files

T

StefanandClaude Opus 5 ad2c98443b 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>

2026-08-09 17:25:36 +02:00

2.4 KiB

Raw Permalink Blame History

Anhang: Android-Server mit redroid

Nicht Teil des Produkts. Verworfen als V7, 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:

Ihre Daten liegen rein lokal, nicht bei einem Konto — ein Restore per "APK zurück plus anmelden" würde also Daten verlieren.
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

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.

2.4 KiB Raw Permalink Blame History