NetMonitor ist eine Android-App, die den gesamten Netzwerkverkehr eines Geräts lokal abfängt, protokolliert, analysiert und gezielt blockiert — ganz ohne Root-Rechte. Die technische Grundlage bildet Androids offizielle VpnService-API: NetMonitor meldet sich beim System als lokales VPN an, wodurch jedes IP-Paket, das eine App senden oder empfangen will, zunächst durch die eigene Verarbeitungslogik läuft, bevor es (falls erlaubt) den Weg ins echte Internet nimmt.

Diese Dokumentation beschreibt die Architektur auf Systemebene — nicht Zeile für Zeile, sondern als Landkarte der Bausteine und ihres Zusammenspiels. Zwei Bereiche werden dabei besonders vertieft, wie gewünscht: das VPN-Core-System (Kapitel 3–7) und das modulare Tools-System (Kapitel 8–9), da beide den technisch anspruchsvollsten und zugleich am stärksten erweiterbaren Teil der App darstellen.

Codebasis in Zahlen

Kernmerkmale

Die App gliedert sich in vier gleichberechtigte UI-Tabs, verwaltet von MainPagerAdapter, sowie einen davon unabhängigen Hintergrunddienst, der die eigentliche Paketverarbeitung übernimmt. Die Tabs sind reine Ansichten — sie starten oder stoppen nichts Kritisches selbst, sondern lesen und schreiben Zustand, der zentral in NetVpnService, BlockManager und der Room-Datenbank gehalten wird.

Paketstruktur

Der Code ist strikt nach fachlicher Verantwortung in Pakete unterteilt, nicht nach technischer Schicht allein:

Alles beginnt mit einem virtuellen Netzwerk-Interface, dem sogenannten TUN-Device. Man kann es sich wie eine Poststelle mitten in einem Bürogebäude vorstellen: Statt dass jede Abteilung (jede installierte App) ihre Post direkt zum Briefkasten an der Straße trägt, muss zwingend jeder Brief zuerst durch diese zentrale Poststelle. Dort wird er geöffnet, registriert, bei Bedarf zurückgehalten — und nur wenn er durchgelassen wird, geht er tatsächlich auf die Reise ins Internet.

Technisch richtet NetVpnService beim Start dieses Interface über einen VpnService.Builder ein:

Die IPv6-Prüfung ist bewusst konservativ: NetVpnService durchsucht alle aktiven Netzwerk-Interfaces nach einer nicht-linklokalen, nicht-Loopback-IPv6-Adresse. Findet sich keine, bleibt der Tunnel reines IPv4 — ein Gerät ohne echte IPv6-Anbindung bekäme sonst einen funktionslosen IPv6-Stack aufgezwungen, der nur Fehler produzieren würde.

Zwei Kategorien von Apps werden von vornherein aus dem Tunnel ausgeschlossen (addDisallowedApplication):

Alle übrigen Apps senden ihre Pakete unbemerkt in dieses TUN-Interface. Von dort liest eine der beiden VPN-Engines (Kapitel 5 und 6) die Rohdaten, entscheidet über Weiterleitung oder Blockierung, und schreibt erlaubte Antwortpakete zurück ins Interface — für die ursprüngliche App sieht das wie eine ganz normale Netzwerkantwort aus.

Das Herzstück der Architektur ist eine bewusst schmal gehaltene Schnittstelle: VpnCore. Sie beschreibt nur fünf Operationen — starten, stoppen, laufend prüfen, Block-Modus live umschalten, Name der Engine — und lässt offen, wie die Paketverarbeitung tatsächlich passiert. Dieses Prinzip heißt in der Softwarearchitektur Strategy Pattern: Der aufrufende Code (NetVpnService) kennt nur den Vertrag, nicht die Implementierung.

Erzeugt wird die aktive Engine über VpnCoreFactory, die die Nutzerpräferenz aus VpnCorePrefs ausliest:

JavaVpnCore ist die historisch erste und am längsten erprobte Implementierung. Sie liest Rohpakete in einem eigenen Thread mit maximaler Thread-Priorität (Thread.MAX_PRIORITY) direkt aus dem Dateideskriptor des TUN-Interfaces — Android behandelt das Interface wie eine ganz normale Datei, aus der gelesen und in die geschrieben wird.

Pro gelesenem Paket durchläuft die Schleife vier Schritte:

Wichtig für das Zusammenspiel mit NetVpnService: JavaVpnCore arbeitet nicht mit dem TUN-Deskriptor allein, sondern mit einem Session-Objekt, das alle vom Dienst verwalteten Abhängigkeiten bündelt (TUN-Interface, Laufzustand, beide Forwarder, der Tracker). Dieses Bündeln verhindert, dass Zustand doppelt gehalten oder bei einem Neustart der Engine vergessen wird.

NativeVpnCore ist seit Version 1.20.0 die Standard-Engine. Sie lädt über JNI eine kompilierte Shared Library (libnetmonitor_native.so, ca. 1.200 Zeilen C++) und übergibt ihr den rohen TUN-Dateideskriptor. Der native Code betreibt eine eigene select()-basierte Ereignisschleife, komplett unabhängig von der Java-VM — das spart den Overhead von Garbage Collection und Objekt-Allokationen auf dem heißesten Pfad der App.

Die Java-Policy-Bridge — der entscheidende Architekturpunkt

Eine naive native Engine würde nur ja/nein auf Paketebene kennen: durchlassen oder verwerfen. Das würde bedeuten, dass die komplette Regel-Logik (Zeitpläne, Quoten, Bypass, Blacklist/Whitelist) in C++ nachgebaut werden müsste — mit doppeltem Pflegeaufwand und Risiko für Inkonsistenzen zwischen beiden Engines. NetMonitor löst das anders:

Damit trifft die native Engine keine eigenständige Entscheidung. Sie transportiert Pakete extrem effizient, überlässt die eigentliche Regel-Logik aber vollständig der immer aktuellen Java-Implementierung. Beide Engines verhalten sich dadurch für Regeln und UI identisch — ein Nutzer bemerkt beim Umschalten keinen funktionalen Unterschied, nur einen Unterschied im Durchsatz.

ConnectionTracker ist das gemeinsame Beobachtungsobjekt, das von beiden Engines gleichermaßen genutzt wird. Für jedes Paket löst er die UID der sendenden App über ConnectivityManager auf, den Paketnamen über PackageManager, und führt Buch über übertragene Bytes getrennt nach IPv4/IPv6 und Richtung. Verbindungen werden in einer LinkedHashMap mit einer festen Obergrenze von 500 Einträgen nach LRU-Prinzip gehalten — die am längsten inaktive Verbindung fällt zuerst heraus, sodass der Speicherbedarf auch bei sehr aktiven Geräten begrenzt bleibt.

Diese Klassen sind bewusst zustandsarm und ohne Android-spezifische Abhängigkeiten geschrieben, wo immer möglich (IpPacket, PacketBuilder) — das macht sie ohne Emulator direkt mit Unit-Tests prüfbar (siehe Kapitel 17).

Der Tools-Tab zeigt 20 unabhängige Diagnose-Werkzeuge in einem Kachel-Raster. Der bemerkenswerte Teil ist nicht die Anzahl, sondern wie leicht sich diese Zahl erhöhen lässt: ein neues Werkzeug erfordert keine einzige Codezeile Änderung an bestehenden Klassen. Das ist kein Zufall, sondern das Ergebnis einer bewussten Entwurfsentscheidung, die seit Version 1.19.0 gilt.

Das Vertrags-Interface

Jedes Werkzeug implementiert die schmale Schnittstelle ToolDefinition mit genau vier Elementen:

Selbstregistrierung statt Eintragsliste

Klassische Plugin-Systeme verlangen oft eine zentrale Liste ("registriere dein Tool hier in dieser Datei"). NetMonitor verzichtet bewusst darauf und nutzt stattdessen Javas eingebauten ServiceLoader-Mechanismus. ToolsFragment fragt beim Öffnen des Tabs schlicht: "Gib mir alle Implementierungen von ToolDefinition, die es gibt" — ohne zu wissen, wie viele das sind oder wie sie heißen:

Die Zuordnung, welche Klassen dabei gefunden werden, geschieht über die Java-Standardkonvention einer Registrierungsdatei unter META-INF/services/, benannt nach dem vollqualifizierten Interface-Namen. Diese Datei ist die einzige Stelle, die beim Hinzufügen eines Tools berührt wird — und selbst das ist laut Projektnotizen als reiner Build-Schritt gedacht, nicht als manuelle Code-Änderung an einer bestehenden Klasse.

Die Schablone: TemplateTool.java

Um die Einstiegshürde für ein neues Werkzeug zu minimieren, liegt im Tools-Paket eine fertige Kopiervorlage, TemplateTool.java. Sie ist keine Dokumentation über den Prozess, sondern lauffähiger (wenn auch funktionsloser) Code mit klar markierten TODO-Kommentaren an jeder Stelle, die angepasst werden muss.

Der Ablauf zum Hinzufügen eines neuen Werkzeugs reduziert sich damit auf sechs mechanische Schritte:

Jedes Werkzeug ist dabei vollständig in sich geschlossen: eigenes UI-Layout, eigene Netzwerklogik, eigener Hintergrund-Thread über Executors.newSingleThreadExecutor(), um die UI während länger laufender Operationen (z. B. Traceroute) nicht zu blockieren. Ergebnisse werden über NetMonitorDialogs (Kapitel 13) in einem einheitlich gestalteten Dialog mit Teilen-Funktion präsentiert — jedes Werkzeug muss dieses Dialog-Grundgerüst nicht selbst nachbauen.

Alle 20 aktuell registrierten Werkzeuge im Überblick, gruppiert nach fachlichem Zweck:

Adressen & Erreichbarkeit

Namensauflösung

Sicherheit & Diagnose

Netzwerk-Umgebung

Leistung & System

BlockManager ist ein zustandshaltendes Singleton, das auf jedes einzelne Paket angewendet wird — der sogenannte Hotpath der App. Aus diesem Grund ist er komplett lock-frei über ConcurrentHashMap implementiert: Ein klassisches synchronized hätte bei hoher Paketrate zum Flaschenhals werden können.

Regel-Modell

Jede App-Regel (AppRule) besteht aus vier unabhängigen booleschen Feldern:

Auswertungsreihenfolge

Die Methode directionBlockedKey() ist die zentrale Entscheidungsfunktion und prüft in einer festen Priorität:

Unbekannte Verbindungen (weder Paketname noch UID auflösbar) werden über den Schlüssel "unknown" behandelt und im Whitelist-Modus sicherheitshalber grundsätzlich blockiert.

Zeitpläne (BlockSchedule)

Ein Zeitplan beschreibt ein Wochentag-Bitmuster (Bit 0 = Montag … Bit 6 = Sonntag) sowie Start- und Endzeit in Minuten seit Mitternacht. Die Prüfung behandelt Fenster, deren Ende rechnerisch vor dem Start liegt, als Übernacht-Fenster (z. B. 22:00–06:00 Uhr) und kehrt die Bedingung dafür logisch um — eine Zeit ist dann aktiv, wenn sie nach dem Start oder vor dem Ende liegt, statt wie im Normalfall beides gleichzeitig verlangen zu müssen.

Oberhalb der reinen Regel-Engine sitzen mehrere Automatisierungsschichten, die seit Version 1.19 sukzessive dazugekommen sind.

Profile (ProfileManager)

Ein Profil bündelt einen Namen, einen Modus (Blacklist/Whitelist) und eine Menge persistenter Regeln. ProfileManager übernimmt Anlegen, Löschen, Zurücksetzen und — entscheidend — das Aktivieren: Beim Wechsel lädt er alle Regeln des Profils aus der Datenbank und schreibt sie geschlossen in den BlockManager. Legacy-Regeln aus einer älteren Datenbankstruktur (vor Einführung der Profile) werden beim ersten Start automatisch einmalig ins Default-Profil migriert.

WLAN-gebundene Profile (SsidProfileStore / SsidProfileWatcher)

Ein Profil lässt sich fest mit dem Namen (SSID) eines WLAN-Netzwerks verknüpfen — eine 1:1-Zuordnung, ein Netzwerk kann jeweils nur an ein Profil gebunden sein. SsidProfileWatcher registriert sich beim Start des VPN-Dienstes als Beobachter für Netzwerkwechsel und prüft bei jedem Wechsel des Standard-Netzwerks, ob die aktuell verbundene SSID an ein Profil gebunden ist. Ist das der Fall und unterscheidet es sich vom aktuell aktiven Profil, wird automatisch umgeschaltet — praktisch für unterschiedliche Regeln zuhause, im Büro oder in öffentlichen Netzen. Das Auslesen der SSID setzt aus Android-Systemgründen die Standort-Berechtigung voraus.

Tages-Datenquota (AppQuotaStore / AppQuotaLedger)

Unabhängig von Out/In-Blockregeln lässt sich pro App ein tägliches Datenlimit in Megabyte setzen. AppQuotaLedger ist dabei bewusst als reine, Android-freie Rechenlogik ausgelagert (kein Zugriff auf Context oder Systemdienste) — das macht sie einfach unit-testbar. Der Tageswechsel wird nicht über einen Alarm oder Hintergrundjob erkannt, sondern beiläufig bei jedem Zugriff: Ein Vergleich des gespeicherten Datums mit dem heutigen Datum (roll()) setzt den Zähler bei Bedarf automatisch zurück, ohne dass ein Wecker die App aufwecken müsste.

Panic-Modus (PanicMode)

Der Panic-Modus ist ein zeitlich begrenztes Overlay über dem globalen Block: Er merkt sich beim Start den bisherigen Block-Zustand, aktiviert den Vollblock für exakt 10 Minuten und stellt danach automatisch den vorherigen Zustand wieder her. Ein Handler-basierter Sekundentakt aktualisiert währenddessen die Restzeit-Anzeige in Konsole, Kachel-Untertitel und Schnelleinstellungen-Panel. Wird der Block-Modus während einer aktiven Panic-Phase manuell deaktiviert (z. B. über das Widget), verwirft onBlockDisabled() den Timer sofort, statt ihn im Hintergrund weiterlaufen zu lassen.

Alles, was einen App-Neustart überdauern muss, liegt in einer Room-Datenbank (AppDatabase), die in sechs Tabellen unterteilt ist:

RuleRepository ist die einzige Klasse, die sowohl auf die Datenbank als auch auf den In-Memory-BlockManager schreibt — sie hält beide synchron, sodass eine Regeländerung sofort im Hotpath wirkt und dauerhaft gespeichert wird. LogWriter arbeitet dagegen bewusst nicht-blockierend: Ereignisse werden in eine Warteschlange gelegt und asynchron auf einem Hintergrund-Thread nach Room geschrieben, damit das Protokollieren niemals die Paketverarbeitung selbst verzögert.

TrafficSampler wird alle 60 Sekunden vom VPN-Dienst getriggert, summiert die aktuellen Byte-Zähler und schreibt einen Schnappschuss — Einträge älter als 24 Stunden werden dabei automatisch entfernt, sodass die Tabelle dauerhaft klein und die Diagramm-Abfrage konstant schnell bleibt. LogExporter liest bei Bedarf das komplette Protokoll asynchron aus und schreibt es als CSV oder JSON in eine temporäre Datei, die über den System-Share-Dialog geteilt wird.

Monitor-Fragment

MonitorFragment ist mit weitem Abstand die umfangreichste UI-Klasse. Sie vereint Terminal-Konsole, App-Kachel-Listen (Outbound/Inbound getrennt), das 24h-Diagramm, eine umschaltbare Log-Ansicht und die komplette Werkzeugleiste (Start, Stopp, Löschen, Aufnahme, Block-Schalter mit Panic-Long-Press). Die Trennung zwischen Kachel- und Datenaufbereitung wurde bewusst ausgelagert:

Dialog-System

Damit nicht jedes der 20 Werkzeuge und jeder Einstellungsdialog sein eigenes Erscheinungsbild erfindet, existiert eine gemeinsame Fabrik: NetMonitorDialogs stellt fertige Bausteine für Bestätigungsdialoge und Formular-Dialoge (Titel, X-Schließen-Symbol, einheitlicher Abstand, optionale Teilen-Funktion) bereit. DialogStyles vereinheitlicht zusätzlich das Erscheinungsbild der Buttons über alle Dialoge hinweg. AppDetailDialog — der komplexeste Einzeldialog der App — nutzt diese Bausteine, um Block-Schalter, Tages-Quota, Zeitpläne (ScheduleAdapter), Nutzungsstatistik und PCAP-Aufnahme für eine einzelne App in einem konsistenten Fenster zu vereinen.

Notes-Fragment

Seit v1.21.0 ein eigener Tab statt eines Werkzeugs. Die Implementierung ist bewusst minimal: ein einzelnes EditText-Feld, dessen Inhalt in SharedPreferences gesichert wird — sowohl explizit über einen Speichern-Button als auch automatisch beim Verlassen des Tabs (onPause).

Sowohl die Java- als auch die native Engine reichen jedes verarbeitete Rohpaket zusätzlich an PcapRecorder weiter, sofern eine Aufnahme läuft — unabhängig von der gewählten Engine entsteht so ein identisches Mitschnitt-Format.

Ist die Zielapp zum Zeitpunkt der Aufnahme eigentlich blockiert, hebt der Recorder die Blockierung für die Dauer der Aufnahme temporär auf und stellt sie danach automatisch wieder her — sonst gäbe es schlicht nichts aufzuzeichnen. Nach Ablauf der Aufnahmedauer öffnet sich automatisch der System-Share-Dialog.

Geiger-Sound (GeigerClick)

Eine bewusst spielerische UX-Funktion: Jedes N-te verarbeitete Paket löst einen kurzen Ton aus — einen hellen Klick für weitergeleiteten, einen dumpfen Ton für blockierten Verkehr. Seit v1.20.1 lassen sich beide Lautstärken getrennt regeln, seit v1.18.11 unterscheiden sich die beiden Klangfarben überhaupt erst. Ein Mindestabstand von 25 ms zwischen zwei Tönen verhindert eine Überlastung des Audiosystems bei hoher Paketrate. Die Dichte ist konfigurierbar: jedes Paket oder nur jedes 20. (Standard).

Weitere Hilfsklassen

Die Testsuite umfasst 123 Testfälle über 10 fachliche Testklassen (plus zwei generierte Beispielklassen aus dem Android-Projekt-Template). Bemerkenswert ist, welche Klassen getestet werden: durchweg jene, die bewusst ohne Android-Abhängigkeiten geschrieben wurden und sich dadurch als reine JVM-Unit-Tests ausführen lassen — schnell, ohne Emulator, ohne Gerät.