Skip to content

Play Store Policy & Privacy Documentation

1. Core functionality claim

AutoBudget's core function is notification-listener-based transaction capture. It uses the BIND_NOTIFICATION_LISTENER_SERVICE permission to read payment-notification text posted by the bank and e-wallet apps the user has explicitly enabled (Maybank2u, MAE, TNG eWallet, Grab, Boost, BigPay, CIMB, Public Bank, RHB, ShopeePay, Wise, Google Wallet, or any package the user adds via the rules editor).

This must be declared in the Play Console as "Notification listener access" (a sensitive permission). The app also requests location (ACCESS_COARSE_LOCATION, ACCESS_FINE_LOCATION, and — for the optional background capture feature — ACCESS_BACKGROUND_LOCATION; opt-in — because fine location is requested, Play's Data Safety counts this as precise location) and reads user-selected files via the system file picker for transaction attachments. Receipt photos are captured by delegating to the system camera app (TakePicture + FileProvider); the app itself declares no CAMERA permission. It does not use SMS, call logs, contacts, microphone, accessibility services, or any other sensitive permission.

The canonical, user-facing privacy policy lives at docs/privacy.md and is published at https://autobudget.zharif.my/privacy/ (Zensical docs site → Cloudflare Pages; ADR-0035).

  • Paste that URL into the Play Console App content → Privacy Policy field.
  • The in-app link (Settings → About → Privacy policy, BuildConfig.PRIVACY_POLICY_URL) points at the same URL.
  • Keep docs/privacy.md, this workbook, and the Play Console Data Safety form consistent (same data types, storage, and "not shared" claims).

3. Data Safety form answers (Play Console)

Question Answer
Does the app collect data? Yes — notification text, an optional device-location snapshot (declared as precise location), and user-attached files (including receipt photos taken via the system camera). All on-device only; nothing is transmitted.
Data shared? No.
Data deleted? Data is deleted when the user deletes it or uninstalls.
Encryption in transit N/A — no network transmission (no INTERNET permission).
Encryption at rest Yes — SQLCipher for the DB; attachments rely on OS file-based encryption of app-private storage.
Data types collected Notification text (bank payment alerts) — user-provided-by-usage, on-device only. Precise location — optional, on-device only, not shared; background capture uses the "Allow all the time" grant. Files (attachments, incl. receipt photos taken via the system camera app) — user-provided, on-device only.

4. Sensitive permission declaration

In the Play Console's "App content" section, declare:

  • Notification listener access — used for the app's core feature of reading bank notification text to build the spending log.
  • Location (ACCESS_COARSE_LOCATION / ACCESS_FINE_LOCATION / ACCESS_BACKGROUND_LOCATION) — used to attach an optional device-location snapshot to captured transactions. Not required for the core feature; the background grant is requested only after an explicit in-app opt-in and is used solely to fetch a one-shot fix when a payment notification is parsed.

Be ready to answer Play's review questions about why the permission is needed and how data is protected (on-device encryption, no transmission, no sharing).

5. Risk note & alternative distribution

Notification-listener apps can face extra review scrutiny from Google Play because the permission is sensitive. Common reasons for rejection: unclear disclosure, transferring notification data off-device, or exceeding the declared functionality.

Risk-reduction steps taken in v1:

  • No INTERNET permission in the release app (nothing can leave the device).
  • No analytics or crash-reporting SDKs.
  • Account/card numbers masked before storage.
  • Clear in-app consent before any access is requested.

Alternative distribution channels:

  • Side-loading / self-hosted APK — distribute the release APK directly, bypassing Play review entirely. Suitable for personal or internal use.
  • F-Droid-style store — F-Droid and similar repositories accept APKs without Play's sensitive-permission review. A good channel for a v1 whose core feature is notification access.

For v1 the safest path if Play approval stalls is side-loading or an F-Droid style repository; Play distribution is still reasonable given the app is fully offline and discloses its behavior in-app.