Notification Guard

Notification Guard filtre les notifications Android entrantes selon des profils horaires prédéfinis (nuit, pause déjeuner, heures de travail, week-end) et des règles personnalisées par application. Les applications sensibles sont toujours laissées passer grâce à un filtre de confidentialité.

  flowchart LR
    A[Notifications app] --> B[Capture locale<br/>on-device uniquement]
    B --> C[(Stockage local chiffré)]
    C --> D[Vue utilisateur]
    D --> E[Export manuel]
    B -.->|jamais| F[("Cloud / Serveur")]
    style F stroke-dasharray: 5 5,stroke:#c00,color:#c00

Fonctionnalités

• 🕒 Profils horaires — Quatre profils intégrés. Les catégories d’applications sont regroupées dans les profils — pas besoin d’écrire une règle par appli.
• 📦 Catalogue d’applis populaires — 77 préréglages curatés dans 5 catégories (Réseaux sociaux, Jeux, Actualités, Shopping, Streaming). Filtrable par applis installées.
• 🧠 Moteur de règles — Évaluation Rust en moins de 10 ms par notification. Les règles utilisateur priment sur les profils. Exceptions par règle (contact, mot-clé).
• 🗑️ Nettoyage TTL — Les notifications bloquées sont supprimées automatiquement après une rétention configurable (24 h par défaut). « Tout effacer » en un toucher.

Confidentialité

Architecture exclusivement locale. Pas de serveur, pas de compte, pas de tracking, pas d’analytics. Aucune permission Internet déclarée dans le manifest Android.

Ce que vous pouvez attendre

• Entièrement local — toutes les données restent sur l’appareil
• Aucun serveur, aucun cloud, aucun SDK tiers
• Aucun accès Internet (le manifest ne contient pas android.permission.INTERNET)
• Aucun rapporteur de crash, aucun analytics, aucune télémétrie
• Base de données SQLite dans le stockage privé de l’application
• Nettoyage automatique des notifications bloquées par TTL
• Bouton « Tout effacer » disponible à tout moment

Filtre de confidentialité — les applications sensibles ne sont jamais bloquées

Le NotificationListenerService voit inévitablement toutes les notifications. Un pré-filtre écarte les catégories d’applications sensibles AVANT que le moteur de règles ne les voie — ces notifications n’entrent jamais dans le stockage, et leur contenu n’est jamais persisté.

Catégories protégées : banque (DKB, PayPal, caisses d’épargne, …), 2FA/authentificateur, assurance maladie (TK, AOK, Barmer), services publics (services fédéraux, Elster).

Conformité Google Play

Six contraintes architecturales strictes issues des politiques Google Play actuelles (Data Safety, Permissions Declaration, Notification Listener). Chaque contrainte est suivie comme un ticket Gitea.

Permissions déclarées

Quatre permissions de manifest, chacune avec un objectif fonctionnel concret. Aucune permission d’exécution, aucun accès spécial restreint au-delà du listener principal.

• android.permission.BIND_NOTIFICATION_LISTENER_SERVICE — Fonction principale. Sans cette permission, l’application ne peut ni lire ni filtrer les notifications. Activée explicitement par l’utilisateur dans les paramètres système.
• android.permission.RECEIVE_BOOT_COMPLETED — Reconnecte le service listener après un redémarrage de l’appareil. Sans elle, l’application serait aveugle après chaque reboot jusqu’au lancement manuel.
• android.permission.WAKE_LOCK — Déclenche de manière fiable les minuteurs de snooze depuis le mode Doze (prévu en phase 2).
• android.permission.POST_NOTIFICATIONS — Affiche nos propres re-notifications (libérées ou en snooze) — à la place d’une fenêtre superposée (voir C2).

Technologie

• Frontend — Svelte 5 (Runes) dans la WebView Tauri, responsive dès 360 px, mise en page avec onglets bas sur mobile.
• Localisation — svelte-i18n avec détection de locale OS via tauri-plugin-os. Langues disponibles : anglais, allemand, français, espagnol, chinois, japonais, coréen.
• Backend — Rust + hôte Tauri v2. Trois plugins maison (Listener, Rules Engine, Store) ainsi que les plugins officiels Notification et OS.
• Couche mobile — Android Kotlin : NotificationListenerService relaie les événements via l’API plugin Tauri vers le pipeline Rust.
• Base de données — SQLite via rusqlite (WAL, clés étrangères activées). 5 migrations. Fichier privé à l’application, sans accès externe.
• Build & signature — APK universel et AAB (exigence AAB de Google Play). Builds dev signés avec un keystore local. APK actuellement ~14 Mo.

Points forts architecturaux

• Isolation des plugins — Les trois plugins maison (notif-listener, rules-engine, notif-store) n’ont aucune dépendance croisée. La communication passe exclusivement par l’hôte Tauri comme médiateur.
• Filtre de confidentialité à l’entrée du pipeline — Les applis sensibles sont filtrées avant que le moteur de règles ne les voie — le contenu des notifications sensibles n’est jamais journalisé ni stocké.
• Profils vs. règles — UX débutant via profils prédéfinis + catégories d’applis ; UX expert via règles individuelles dans une vue « avancée ». Les deux chemins partagent le même moteur.
• Spécificités mobiles — Modules Android plugin personnalisés avec fusion AndroidManifest. L’onboarding des permissions gère le verrouillage Android 13 « restricted settings » pour les APK sideloadées.

Notification Guard — Dépôt : git.pronix.org/oiv1Ni3o/notification-guard