diff --git a/host-agent/android/README.md b/host-agent/android/README.md
index a2d5e68..b8b0a9b 100644
--- a/host-agent/android/README.md
+++ b/host-agent/android/README.md
@@ -61,30 +61,35 @@ Zwei Wege, deine WhatsApp-Intuition trifft ins Schwarze:
 - **Reutzt unser bestehendes `host_hello`/`host_command`/`host_result` 1:1.**
 - Nachteil: etwas Akku; manche OEMs killen trotzdem → „Autostart" manuell erlauben.
 
-**B) Push (Firebase Cloud Messaging)** — genau wie WhatsApp/Telegram:
-- Kein 24/7-Socket. Die App registriert sich bei FCM; will ARIA etwas, schickt
-  der **Server einen Push** → Android weckt die App (auch aus Doze) → sie holt
-  den Befehl vom RVS, führt ihn aus, antwortet. Da der Agent primär **empfängt**,
-  passt das perfekt und ist akkuschonend/zuverlässig.
-- Nachteil: braucht **Firebase-Projekt** + **Google Play Services** aufm Gerät +
-  einen **Push-Auslöser serverseitig** (RVS/Bridge feuert bei `host_command` einen
-  FCM-Push an das Ziel-Gerät). Mehr Plumbing.
+**B) Self-hosted Push (KEIN Google!)** — genau wie WhatsApp, aber auf eigenem Server:
+- **UnifiedPush + self-hosted ntfy**: Auf dem ARIA-Server läuft **ntfy** (freier,
+  self-hostbarer Push-Server). Der Agent nutzt **UnifiedPush** (offener Standard,
+  de-Google-Welt/F-Droid) mit dem ntfy-Distributor auf dem Handy. Will ARIA etwas,
+  POSTet die Bridge/RVS an ntfy → weckt die App → sie holt den Befehl vom RVS,
+  arbeitet, antwortet. **Läuft auch auf Custom-ROMs OHNE Google Play Services.**
+- Akkuschonend wie FCM, aber ohne jede Google-Abhängigkeit. Nur ein Dienst mehr
+  (ntfy) im Stack + der Push-Auslöser serverseitig.
 
-**C) Hybrid (ideal, End-Ausbau):** Im Leerlauf nur Push (max. Akku). Ein Push
-weckt die App → sie öffnet die RVS-Verbindung, hält sich per Wakelock für die
-Interaktion wach (mehrere Befehle flüssig, z.B. E-Mail-Setup durchklicken) →
-schläft nach ein paar Sekunden Ruhe wieder ein. So WhatsApp-Akku UND schnelle
-Multi-Befehl-Sessions.
+**C) FCM (Google) — optional:** Wer ein Stock-Android mit Play Services hat und
+Googles Push-Kanal will, kann FCM statt ntfy nehmen (bester Akku auf GMS-Geräten).
+Braucht Firebase-Projekt + Play Services. **Nur eine Option, keine Pflicht.**
 
-FCM braucht: **Firebase-Projekt**, **Google Play Services** aufm Gerät (nicht auf
-de-googelten ROMs / manchen Huawei), und einen **Push-Auslöser serverseitig**
-(Bridge/RVS ruft FCM, wenn ein `host_command` fürs Gerät ansteht). Erste Push-
-Latenz aus tiefem Doze: ~1–3 s; danach bleibt der Socket während der Session offen.
+**Custom-ROM ohne Google:** → Weg **A** (eigener Socket) oder **B** (self-hosted
+ntfy). Beide brauchen KEIN Google. Für Stefans dediziertes Ziel-Handy ist **A**
+sogar oft die einfachste Dauerlösung (unser eigener „Push" über den RVS-Socket).
+
+**Hybrid (ideal, End-Ausbau):** Im Leerlauf nur Push (max. Akku). Ein Push weckt
+die App → sie öffnet die RVS-Verbindung, hält sich per Wakelock für die Interaktion
+wach (mehrere Befehle flüssig, z.B. E-Mail-Setup durchklicken) → schläft nach ein
+paar Sekunden Ruhe wieder ein. So WhatsApp-Akku UND schnelle Multi-Befehl-Sessions.
+Der Push kommt dabei von **B (self-hosted ntfy)** oder C (FCM) — freie Wahl.
+Erste Push-Latenz aus tiefem Doze ~1–3 s; danach bleibt der Socket die Session offen.
 
 **Empfehlung:** Meilenstein 1–3 mit **A (Foreground-Service)** — läuft sofort und
-nutzt alles Vorhandene, damit wir schnell einen funktionierenden Agenten haben.
-Dann **C (Push-Hybrid)** als Akku-Ausbau. Action-Set/Protokoll bleiben identisch,
-nur der Wecker (Dauer-Socket → Push+Session-Socket) ändert sich.
+nutzt alles Vorhandene, damit wir schnell einen funktionierenden Agenten haben, ganz
+ohne externe Dienste. Dann **Push-Hybrid mit self-hosted ntfy (B)** als Akku-Ausbau —
+KEIN Google. FCM (C) nur optional für Stock-Android. Action-Set/Protokoll bleiben
+identisch, nur der Wecker ändert sich.
 
 ## Sicherheit