Notification Guard

Notification Guard filtert eingehende Android-Benachrichtigungen anhand vordefinierter Ruhe-Profile (Nachtruhe, Mittagsruhe, Arbeitszeit, Wochenende) und optional eigener Regeln pro App. Sensible Apps werden durch einen Privacy-Filter immer durchgelassen.

Eigenschaft	Wert
Plattform	Android 7+ (API 24)
Stack	Tauri v2 · Rust · Svelte 5
Sprachen	7
Repository	git.pronix.org/oiv1Ni3o/notification-guard

  flowchart LR
    A[App-Benachrichtigungen] --> B[Lokale Erfassung<br/>nur on-device]
    B --> C[(Verschlüsselter lokaler Speicher)]
    C --> D[Nutzer-Ansicht]
    D --> E[Manueller Export]
    B -.->|niemals| F[("Cloud / Server")]
    style F stroke-dasharray: 5 5,stroke:#c00,color:#c00

Was die App tut

🕒 Ruhe-Profile — Vier eingebaute Zeit-Profile. App-Kategorien werden in Profilen gebündelt — kein Regel-Bau für jede App.
📦 Top-Apps katalogisiert — 77 kuratierte App-Voreinstellungen in 5 Kategorien (Social, Games, News, Shopping, Streaming). Filterbar nach installierten Apps.
🧠 Regel-Engine — Rust-basierte Auswertung in unter 10 ms pro Notification. User-Rules haben Vorrang vor Profilen. Ausnahmen pro Regel (Kontakt, Stichwort).
🗑️ TTL-Bereinigung — Blockierte Notifications werden nach konfigurierbarer Retention (Standard 24 h) automatisch gelöscht. „Alles löschen" per Tap.

Datenschutz

Lokal-only-Architektur. Kein Server, kein Account, kein Tracking, kein Analytics. Keine Internet-Berechtigung im Android-Manifest.

Was du erwarten kannst

Vollständig lokal — alle Daten bleiben auf dem Gerät
Keine Server, keine Cloud, keine Drittanbieter-SDKs
Kein Internet-Zugriff (Manifest enthält kein android.permission.INTERNET)
Keine Crash-Reporter, keine Analytics, kein Telemetry
SQLite-Datenbank im app-privaten Speicher
Automatische Bereinigung blockierter Notifications nach TTL
Manuelles „Alles löschen" jederzeit möglich

Privacy-Filter — sensible Apps werden nie blockiert

Der NotificationListenerService sieht zwangsläufig alle Benachrichtigungen. Ein Vorfilter sortiert sensible App-Kategorien aus BEVOR die Regel-Engine sie sieht — diese Notifications landen niemals im Bunker, der Inhalt wird nie gespeichert.

Geschützte Kategorien: Banking (DKB, PayPal, Sparkasse, …), 2FA/Authenticator, Krankenkassen (TK, AOK, Barmer), Behörden (Bund, Elster).

Google-Play-Compliance

Sechs verbindliche Architektur-Constraints aus den aktuellen Google-Play-Policies (Data Safety, Permissions Declaration, Notification Listener). Jeder ist als Gitea-Issue verfolgt.

ID	Anforderung	Status & Umsetzung
C1	Prominent Disclosure & Consent	✓ Erfüllt — 4-Schritt-Wizard mit Disclosure, Profil-Auswahl, Kategorien-Auswahl, Permission-Aktivierung. Klare Hinweise: lokal, kein Server, kein Netzwerk.
C2	Kein `SYSTEM_ALERT_WINDOW`	✓ Erfüllt — Manifest enthält die Permission nicht. Re-Notifications laufen über `NotificationManager`.
C3	Data Retention TTL	✓ Erfüllt — Konfigurierbare Retention (Default 24 h). Periodischer Cleanup-Task (Tokio-Interval, 60 min). „Alles löschen"-Button mit Bestätigungs-Dialog.
C4	Kontakt-Picker statt `READ_CONTACTS`	○ Geplant — Wird als optionales Opt-in-Modul mit Android Contact Picker nachgerüstet — kein `READ_CONTACTS`.
C5	Privacy-Filter (Blocklist sensibler App-Kategorien)	✓ Erfüllt — Hardcoded Default-Blocklist als Vorfilter direkt in der Regel-Engine. Erste Logik in `evaluate()` — Match → sofort `Pass`, keine Auswertung, keine Speicherung.
C6	Kein Netzwerk-Layer	✓ Erfüllt — Manifest verifiziert (`aapt dump badging`). Keine HTTP-Client-Dependencies in den Cargo.toml-Files. App läuft vollständig im Flugmodus.

Verwendete Berechtigungen

Vier Manifest-Permissions, jede mit konkretem Funktions-Bezug. Keine Runtime-Permissions, keine restricted Special-Access außer dem Kern-Listener.

android.permission.BIND_NOTIFICATION_LISTENER_SERVICE — Kern-Funktion. Ohne diese Permission kann die App keine Benachrichtigungen lesen oder filtern. Wird vom Nutzer explizit über die System-Einstellungen aktiviert.
android.permission.RECEIVE_BOOT_COMPLETED — Listener-Service nach Geräte-Neustart wieder verbinden. Ohne wäre die App nach jedem Reboot bis zum manuellen App-Start blind.
android.permission.WAKE_LOCK — Snooze-Timer für Notifications aus dem Doze-Modus zuverlässig auslösen (geplant in Phase 2).
android.permission.POST_NOTIFICATIONS — Eigene Re-Notifications (released oder snoozed) anzeigen — anstelle eines Overlay-Fensters (siehe C2).

Technologie

Frontend — Svelte 5 (Runes) im Tauri-WebView, responsiv ab 360 px, Bottom-Tab-Layout auf Mobile.
Mehrsprachigkeit — svelte-i18n mit OS-Locale-Erkennung über tauri-plugin-os. Verfügbare Sprachen: English, Deutsch, Français, Español, 中文, 日本語, 한국어.
Backend — Rust + Tauri v2 Host. Drei eigene Plugins (Listener, Rules-Engine, Store) plus offizielles Notification- und OS-Plugin.
Mobile-Layer — Android Kotlin: NotificationListenerService bridged Events über die Tauri-Plugin-API an die Rust-Pipeline.
Datenbank — SQLite via rusqlite (WAL, Foreign-Keys on). 5 Migrationen. App-private Datei, kein externer Zugriff.
Build & Signing — Universal-APK und AAB (Google Play AAB-Pflicht). Dev-Builds signiert mit lokalem Keystore. APK aktuell ~14 MB.

Architektur-Highlights

Plugin-Isolation — Die drei eigenen Plugins (notif-listener, rules-engine, notif-store) haben keine Cross-Dependencies untereinander. Kommunikation läuft ausschließlich über den Tauri-Host als Mediator.
Privacy-Filter im Pipeline-Eingang — Sensible Apps werden ausgefiltert, bevor die Regel-Engine sie sieht — Inhalte sensibler Notifications werden niemals geloggt oder gespeichert.
Profile vs. Rules — Anfänger-UX über vordefinierte Profile + App-Kategorien; Power-User-UX über individuelle Regeln in einer „Erweitert"-Sicht. Beide Pfade nutzen dieselbe Engine.
Mobile-Spezifika — Eigene Plugin-Android-Module mit AndroidManifest-Merge. Permission-Onboarding fängt Android-13-Restricted-Settings-Lockout für Sideload-APKs ab.

Notification Guard — Repository: git.pronix.org/oiv1Ni3o/notification-guard

Pronix Information Technologies

Title here