A local-first Android filter takes the long route around system limits
Trinotify is presented as a smart notification and call filter for Android that works without root access and without network requests. The project README says it decides whether each notification or incoming call should sound, remain silent or be blocked. Its design is shaped by a hard Android limitation: a third-party app cannot cancel another app's notification sound before the system plays it. That makes the project less a simple mute switch than an attempt to rebuild notification sound policy around local rules, Do Not Disturb and an on-device classifier.What Trinotify says it can filter
Trinotify's stated function is to intercept notifications and incoming calls in real time, then apply a configured action: allow with sound, show silently or block. The README describes rules at the application level, sender rules based on substrings in a notification title or text, and an option to let a local machine-learning classifier decide.For calls, the project describes number allowlists and blocklists, including international formats such as +375, +998 and local-style number strings, with matching based on meaningful digits rather than exact formatting. Templates such as +7900* and short substrings such as 8800 are also described. One important rule hierarchy is explicit: an allow rule takes priority over a block rule.
The limits matter as much as the features. The README says calls from Android contacts are not passed into the filter and therefore always go through, while emergency calls are not filtered. A blocked call is described as rejected silently. For users considering this type of tool, the practical implication is that Trinotify is designed for nuisance reduction, not for overriding every part of Android's calling stack.
Why it uses Do Not Disturb instead of direct muting
The project documentation states that Android does not allow a third-party app to cancel the sound of another app's notification before it plays. Because the system plays the sound at publication time, a notification listener cannot reliably intervene early enough without root access.Trinotify's workaround is to enable the system Do Not Disturb mode with a policy under which notifications remain visible but silent. Other apps' notifications are muted by the system, and notifications that pass Trinotify's rules are then sounded by Trinotify itself through its own player using the alarm stream. This is presented as a compromise rather than a hidden bypass.
That approach has visible consequences. The README says the permanent Do Not Disturb moon icon in the status bar cannot be removed because SystemUI draws system indicators and there is no third-party API for suppressing them. It also says notifications are blocked after appearing, not before, because Android does not permit earlier removal. The design therefore trades perfect invisibility for a rootless implementation that stays within documented platform constraints.
Local ML and explainable rules, not a cloud classifier
Trinotify's classification feature is described as entirely on-device. The README says the app keeps a local archive of notifications and calls with search and filters, lets the user manually label records, and uses those labels as a training set.The classifier is described as a Naive Bayes model. Its main feature is the source application, with additional signals from words in the notification title and text. The documentation says training is instant and that the confidence threshold is configurable. It does not provide independent accuracy results in the supplied material, so any performance claim should be treated as a project claim rather than a verified benchmark.
Explainability is a useful part of the design. The README says each archive entry can show what caused the decision, such as an application rule, an ML decision with a percentage confidence, or the default action. That is important for a notification tool because incorrect suppression can hide time-sensitive information, and users need a way to understand and correct decisions.
Privacy controls and remaining data exposure
The README openly notes that an app of this type sees sensitive data, including message text, confirmation codes and caller numbers. Its privacy claim is that there are no network requests, analytics or telemetry, and that data does not leave the device through the app's own network behavior.Several local protections are described. The archive is excluded from cloud backup through Android backup settings, database encryption is optional using SQLCipher with a key stored in Android's hardware-backed Keystore, and access to the interface can be protected with biometrics or a PIN. The documentation also says the app can set FLAG_SECURE, preventing screenshots and previews in the recent-apps view.
The project also names residual risks. Exported JSON is not encrypted and can contain notification text, so it must be handled deliberately. If database encryption is enabled, the database is unavailable after a reboot until the first screen unlock; during that window, filtering falls back to the default action and the archive is not written. These are not minor implementation notes - they define when the privacy model is strongest and when it temporarily degrades.
Open-source status and practical constraints
The repository states that Trinotify is distributed under the GNU General Public License v3.0. It also says the main codebase contains about 3,900 lines of Kotlin and 271 lines of tests, with architecture details in a separate document. The supplied evidence is project documentation, not an independent security audit or store review.The stated minimum platform is Android 10, API 29, with about 75 MB of free space because the APK includes built-in sounds and native encryption libraries. Build information in the README mentions Android SDK compileSdk 34, build-tools 34 or later, and Gradle 8.7 or Android Studio. A signed release build depends on local signing files that are excluded from the repository.
The README also highlights device-vendor behavior. Xiaomi and MIUI users are told to enable autostart for Trinotify because the shell may otherwise unload the background service. This underlines a recurring Android reality: notification tools depend not only on Android APIs but also on manufacturer background-process policies.
Conclusion
Trinotify is best read as a local-first Android notification control project with explicit trade-offs. Its strongest documented claims are offline operation, rule-based filtering, optional on-device classification, local archive controls and a rootless workaround based on Do Not Disturb.The same documentation narrows the promise. It cannot remove the Do Not Disturb status icon, cannot preempt notification sounds directly, cannot filter emergency calls, and does not receive Android contact calls for filtering. For users and developers, the news value is in the architecture: the project shows how far a notification filter can go without root, and where Android's platform boundaries still remain.
Sources
Editorial Team - CoinBotLab
