Doorman Privacy Policy

Notification access, and why Doorman needs it

Doorman registers an Android NotificationListenerService. Android only grants that service access after you explicitly enable Doorman under Settings → Notifications → Notification access (the exact path varies by manufacturer). You can revoke it at the same screen at any time, and Doorman stops receiving anything the moment you do.

Notification access is core functionality: without it there is no notification log, so there is no signal rate and no digest. Doorman does not use this access for any purpose unrelated to those features.

Doorman does not use Android's accessibility services. It never requests BIND_ACCESSIBILITY_SERVICE, and that permission is explicitly blocked in the app's build configuration.

What Doorman stores on your device

For each notification that interrupts you, Doorman writes a single row to a local database (doorman_notifications.db) in the app's private storage. Each row contains:

• the notification's Android key (an identifier Android assigns, used to match a removal to the post it belongs to)
• the package name of the app that posted it — for example com.whatsapp
• the time it was posted
• the Android category, if the app set one — for example msg, call, alarm
• the Android priority the app gave it
• whether the notification was ongoing (a persistent status such as a download in progress)
• whether Doorman itself held the notification back for a digest
• the time it was removed, and Android's numeric reason for the removal (tapped, swiped, cleared by the app, and so on)
• when the notification belonged to a group of notifications from one app, Android's numeric reason for that group's header disappearing — this is what lets Doorman tell your dismissing a whole stack apart from the app withdrawing it

That is the complete list of what is recorded about a notification you were shown. There are no other columns.

The one other thing this database can contain is the queue of notifications Doorman is currently holding back for a digest, which exists only if you switch batching on for an app. It is described under Batched apps and the digest below, and it is the only place notification text is ever written down.

Doorman also stores, in the app's private preferences, the set of app package names you have chosen to batch, and your own settings.

What Doorman does not store

• Notification titles and message text. These are read in memory for a fraction of a second so that the safety checks below can run, and are then discarded. They are not written to the database — with the single exception of apps you have switched batching on for, described below, where the text has to be kept until the digest carrying it has been delivered.
• Names, phone numbers, email addresses, or contacts.
• Photos, files, location, or device identifiers used for tracking.
• Your notification history from before you installed Doorman — Android does not make it available, and Doorman only ever sees notifications posted while it is running and permitted.

Doorman resolves an app's display name and icon only for packages that have actually posted a notification to it. It does not request QUERY_ALL_PACKAGES and therefore cannot enumerate the apps installed on your phone. That permission is explicitly blocked in the app's build configuration.

Reading notification text for safety checks

Before Doorman decides whether a notification may be held back for a digest, it inspects the notification in memory to make sure it is not something urgent. This check looks at the notification's text for patterns such as a 4–8 digit verification code next to words like "code" or "OTP", and at the notification's category, its priority, whether it is ongoing, and the role of the app that posted it — your default phone app and your default SMS app, resolved by role rather than by name, so the check follows whatever you actually have installed. Clock, calendar and banking apps are covered through what they post rather than through any list of apps: an alarm, a calendar event or a reminder is exempt by its category, and a bank's message is exempt when it carries a verification code. Doorman cannot hold a list of banking apps, because reading the list of apps on your phone would need a permission it does not request.

Anything matching is delivered to you immediately and is never held, regardless of your settings. The text examined during this check is held only in memory for the duration of the check and is never stored or transmitted.

Batched apps and the digest

If you switch batching on for a specific app, Doorman holds that app's notifications and delivers them together as a scheduled digest. To be able to show you a useful digest, Doorman must keep the notification's title and text for those held notifications, along with the action that reopens the original notification in its own app.

This applies only to apps you have explicitly enabled batching for. Held content stays on the device, is used only to render your digest, and is deleted no later than 24 hours after the digest containing it has been delivered. Opening a held notification deletes it immediately. Turning batching off for an app stops any further content from being kept.

The queue is stored in the same private database as the metadata above, in a separate table holding the notification's key, the app that posted it, when it was posted, when Doorman held it, its title and text, and when the digest carrying it went out. When the 24 hours are up the whole entry is deleted, text included; the record that the app interrupted you at that time survives in the metadata table, because that is what your statistics are counted from.

What leaves your device

No notification data. Ever.

Your notifications, the statistics computed from them, and anything Doorman is holding for a digest stay in the app's private database on this phone. Nothing reads them out, and there is no Doorman account, no login and no server of ours for them to be sent to.

There is no analytics SDK, no advertising SDK and no crash reporter in the build. There is a push SDK, and it is switched off until you ask for it — see Push notifications below, which describes exactly what happens if you do. Doorman does not sell or share personal information, and does not transfer your data to third parties for advertising or profiling.

RevenueCat

Doorman's paid tier is a subscription, and a subscription has to be verified against the store that sold it. Doorman uses RevenueCat (RevenueCat, Inc.) to do that, together with Google Play Billing. It is one of the two third-party services in the app, and unless you switch push on it is the only reason the app makes a network request at all.

What RevenueCat receives is the purchase and the device it has to be checked on: the Google Play purchase token and product identifier for your subscription, an anonymous identifier RevenueCat generates for this installation, and ordinary technical details of the request such as your app version, device model, operating system version and country. It does not receive your name, your email address or your Google account.

What it never receives is anything this policy is otherwise about. No notification is sent to RevenueCat — not which apps notify you, not how many, not when, not your signal rates, not the title or text of anything Doorman holds. The two halves of the app do not meet: nothing from the notification database is passed to the purchase code, and the identifier RevenueCat uses is generated by RevenueCat rather than derived from anything on your device.

Two collection settings that RevenueCat offers are switched off in Doorman's configuration rather than left at their defaults — its diagnostics upload, and the device-identifier collection used for advertising attribution, which Doorman has no attribution network to report to in the first place.

RevenueCat's own privacy policy is at https://www.revenuecat.com/privacy.

Push notifications

Doorman's build includes the OneSignal SDK (OneSignal, Inc.), which is how an app receives a notification sent from outside it. It starts switched off, and "off" here means more than unsubscribed: the SDK is initialised with its consent requirement turned on and consent withheld, so it does not register this device, does not create a push token, and sends OneSignal nothing at all about your installation.

That only changes if you switch Let Doorman notify you on, on the Doorman screen. From that point OneSignal receives what a push service needs in order to reach a device: a push token issued by Google's messaging service for this installation, identifiers OneSignal generates for the device and the subscription, and ordinary technical details such as your app version, device model, Android version, language and country. While push is on, the SDK also tells OneSignal when the app is opened, whether you opened a notification OneSignal delivered, and, because Doorman's subscription is sold through Google Play, any purchase made in the app. Switching it off again unsubscribes the device, and no further notification can be sent to it.

What OneSignal never receives is everything this policy is otherwise about. No notification is sent to OneSignal — not which apps notify you, not how many, not when, not your signal rates, not the title or text of anything Doorman holds. Nothing from the notification database is passed to the push code, and the identifiers OneSignal uses are generated by OneSignal rather than derived from anything on your phone. There is no Doorman account or server, so there is nothing for a push to be personalised from.

Three things Doorman does not use push for, whether or not you switch it on:

• Your digest is never a push. It is assembled on this phone from notifications already held here and posted by Doorman itself. It works with no network and reaches no server.
• No reminders to come back. Doorman does not send scheduled notifications to re-engage you.
• No selling by interruption. The paid tier is offered on a screen you have to open. OneSignal's in-app messages are switched off in the app's configuration for the same reason.

OneSignal's privacy policy is at https://onesignal.com/privacy_policy.

If a future version adds any further service outside the app, this section will name it, say exactly what it receives, and the effective date above will change before that version ships.

Permissions Doorman requests

• Notification access (BIND_NOTIFICATION_LISTENER_SERVICE) — to read notification metadata, and to hold and re-post batched notifications. Granted by you in system settings; revocable there at any time.
• Post notifications (POST_NOTIFICATIONS) — to deliver your digest and Doorman's own alerts, including any push you have switched on.

Your choices

• Revoke notification access in Android settings. Doorman immediately stops receiving anything. Statistics already collected remain on the device until you delete them.
• Turn batching off for any app, at any time, from within Doorman.
• Delete your data from within the app, from Your data on the Doorman screen. It removes every recorded notification and everything currently being held, at once, and cannot be undone.
• Doorman also applies a 90-day retention window and deletes events older than that automatically, without being asked.
• Uninstall Doorman. Android deletes the app's private storage, including the notification database, when the app is uninstalled. Nothing survives on any server, because nothing was sent to one.

Security

Notification data is held in the app's private storage, which Android isolates from other apps. Because the data is neither transmitted nor backed up to a Doorman server, there is no server-side copy to be exposed. No method of storage is perfectly secure, but keeping the data on one device under Android's app sandbox is a deliberate choice to keep the exposure as small as the product allows.

Children

Doorman is not directed at children and is not intended for users under 13. Doorman does not knowingly collect personal information from children.

Changes to this policy

If this policy changes in a way that affects what Doorman collects or where it sends it, the updated policy will be published at this address and the effective date above will change. Material changes will also be surfaced in the app.

Contact

Questions about this policy or about your data: kodebloc.apps@gmail.com