Pronix Information Technologies

Notification Guard

Logo de Notification Guard

Notification Guard filtra las notificaciones entrantes de Android mediante perfiles horarios predefinidos (noche, pausa de mediodía, horas de trabajo, fin de semana) y reglas opcionales por aplicación. Las aplicaciones sensibles siempre se dejan pasar mediante un filtro de privacidad.

PropiedadValor
PlataformaAndroid 7+ (API 24)
StackTauri v2 · Rust · Svelte 5
Idiomas7
Repositoriogit.pronix.org/oiv1Ni3o/notification-guard
  flowchart LR
    A[Notificaciones de app] --> B[Captura local<br/>solo en el dispositivo]
    B --> C[(Almacenamiento local cifrado)]
    C --> D[Vista de usuario]
    D --> E[Exportación manual]
    B -.->|nunca| F[("Nube / Servidor")]
    style F stroke-dasharray: 5 5,stroke:#c00,color:#c00

Qué hace la app

  • 🕒 Perfiles horarios — Cuatro perfiles temporales integrados. Las categorías de apps se agrupan en perfiles — sin necesidad de escribir una regla por app.
  • 📦 Apps populares catalogadas — 77 preajustes de apps curados en 5 categorías (Sociales, Juegos, Noticias, Compras, Streaming). Filtrables por apps instaladas.
  • 🧠 Motor de reglas — Evaluación en Rust en menos de 10 ms por notificación. Las reglas del usuario tienen prioridad sobre los perfiles. Excepciones por regla (contacto, palabra clave).
  • 🗑️ Limpieza por TTL — Las notificaciones bloqueadas se eliminan automáticamente tras una retención configurable (24 h por defecto). «Borrar todo» con un toque.

Privacidad

Arquitectura exclusivamente local. Sin servidor, sin cuenta, sin seguimiento, sin analítica. El manifest de Android no declara permiso de Internet.

Qué puedes esperar

  • Totalmente local — todos los datos permanecen en el dispositivo
  • Sin servidores, sin nube, sin SDK de terceros
  • Sin acceso a Internet (el manifest no contiene android.permission.INTERNET)
  • Sin reporteros de errores, sin analítica, sin telemetría
  • Base de datos SQLite en el almacenamiento privado de la app
  • Limpieza automática de notificaciones bloqueadas mediante TTL
  • Botón «Borrar todo» disponible en cualquier momento

Filtro de privacidad — las apps sensibles nunca se bloquean

El NotificationListenerService ve inevitablemente todas las notificaciones. Un prefiltro descarta las categorías de apps sensibles ANTES de que el motor de reglas las vea — estas notificaciones no entran nunca en el almacén y su contenido jamás se persiste.

Categorías protegidas: banca (DKB, PayPal, cajas de ahorros, …), 2FA/autenticador, sanidad (TK, AOK, Barmer), administración pública (servicios federales, Elster).

Cumplimiento con Google Play

Seis restricciones arquitectónicas obligatorias derivadas de las políticas actuales de Google Play (Data Safety, Permissions Declaration, Notification Listener). Cada una se rastrea como incidencia en Gitea.

IDRequisitoEstado e implementación
C1Divulgación y consentimiento explícitos✓ Cumplido — Asistente de 4 pasos con divulgación, selección de perfil, selección de categorías, activación de permisos. Notas claras: local, sin servidor, sin red.
C2Sin SYSTEM_ALERT_WINDOW✓ Cumplido — El manifest no declara este permiso. Las re-notificaciones pasan por NotificationManager.
C3TTL de retención de datos✓ Cumplido — Retención configurable (24 h por defecto). Tarea periódica de limpieza (intervalo Tokio, 60 min). Botón «Borrar todo» con diálogo de confirmación.
C4Selector de contactos en lugar de READ_CONTACTS○ Planificado — Se añadirá como módulo opt-in opcional usando el Contact Picker de Android — sin READ_CONTACTS.
C5Filtro de privacidad (blocklist de categorías sensibles)✓ Cumplido — Blocklist por defecto codificada en duro como prefiltro dentro del motor de reglas. Primera comprobación en evaluate() — coincidencia → Pass inmediato, sin evaluación, sin almacenamiento.
C6Sin capa de red✓ Cumplido — Manifest verificado (aapt dump badging). Sin dependencias HTTP en ningún Cargo.toml. La app funciona enteramente en modo avión.

Permisos declarados

Cuatro permisos en el manifest, cada uno con un propósito funcional concreto. Sin permisos de ejecución, sin acceso especial restringido más allá del listener principal.

  • android.permission.BIND_NOTIFICATION_LISTENER_SERVICE — Función esencial. Sin este permiso la app no puede leer ni filtrar notificaciones. El usuario lo activa explícitamente en los ajustes del sistema.
  • android.permission.RECEIVE_BOOT_COMPLETED — Reconecta el servicio listener tras reiniciar el dispositivo. Sin él, la app quedaría ciega tras cada reinicio hasta abrirla manualmente.
  • android.permission.WAKE_LOCK — Dispara fiablemente temporizadores de snooze desde el modo Doze (planificado para la fase 2).
  • android.permission.POST_NOTIFICATIONS — Muestra nuestras propias re-notificaciones (liberadas o en snooze) — en lugar de una ventana superpuesta (ver C2).

Tecnología

  • Frontend — Svelte 5 (Runes) dentro del WebView de Tauri, responsive desde 360 px, diseño con pestañas inferiores en móvil.
  • Localización — svelte-i18n con detección de locale del sistema vía tauri-plugin-os. Idiomas disponibles: inglés, alemán, francés, español, chino, japonés, coreano.
  • Backend — Rust + host Tauri v2. Tres plugins propios (Listener, Rules Engine, Store) más los plugins oficiales de Notification y OS.
  • Capa móvil — Android Kotlin: NotificationListenerService reenvía eventos a través de la API de plugins de Tauri al pipeline en Rust.
  • Base de datos — SQLite vía rusqlite (WAL, foreign keys activas). 5 migraciones. Archivo privado de la app, sin acceso externo.
  • Build y firma — APK universal y AAB (requerimiento AAB de Google Play). Builds de desarrollo firmados con un keystore local. APK actualmente ~14 MB.

Aspectos arquitectónicos destacados

  • Aislamiento de plugins — Los tres plugins propios (notif-listener, rules-engine, notif-store) no tienen dependencias cruzadas. La comunicación pasa exclusivamente por el host de Tauri como mediador.
  • Filtro de privacidad en la entrada del pipeline — Las apps sensibles se filtran antes de que el motor de reglas las vea — el contenido de las notificaciones sensibles nunca se registra ni almacena.
  • Perfiles vs. reglas — UX para principiantes mediante perfiles predefinidos + categorías de apps; UX para usuarios avanzados mediante reglas individuales en una vista «avanzada». Ambos caminos comparten el mismo motor.
  • Particularidades móviles — Módulos Android de plugins propios con fusión de AndroidManifest. El onboarding de permisos gestiona el bloqueo «restricted settings» de Android 13 para APK sideload.

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