crowd-funder-for-time-pwa/doc/plugin-feedback-android-exact-alarm-settings.md

Plugin feedback: Android exact alarm — stop opening Settings automatically

Date: 2026-03-09
Target repo: daily-notification-plugin
Consuming app: crowd-funder-for-time-pwa (TimeSafari)
Platform: Android

Summary

When the consuming app calls scheduleDailyNotification() after the user has granted POST_NOTIFICATIONS, the plugin checks whether exact alarms can be scheduled (Android 12+). If not, it opens the system Settings (exact-alarm or app-details screen) and rejects the call. This is intrusive: the app prefers to schedule without forcing the user into Settings, and to inform the user about exact alarms in its own UI (e.g. a note in the success message).

Requested change: Remove the automatic opening of Settings for exact alarm permission from scheduleDailyNotification(). Either:

• Option A (preferred): Do not open Settings and do not reject when exact alarm is not granted. Proceed with scheduling (using inexact alarms if necessary when exact is unavailable), and let the consuming app handle any UX (e.g. optional hint to enable exact alarms).
• Option B: Do not open Settings, but still reject with a clear error code/message when exact alarm is required and not granted, so the app can show its own message or deep-link to Settings if desired.

---

Where this lives in the plugin

File: android/src/main/java/com/timesafari/dailynotification/DailyNotificationPlugin.kt
Method: scheduleDailyNotification(call: PluginCall)
Lines: ~1057–1109 (exact line numbers may shift with edits)

Current behavior:

1. At the start of scheduleDailyNotification(), the plugin calls canScheduleExactAlarms(context).
2. If false:
   • If Android S+ and canRequestExactAlarmPermission(context) is true: it builds Settings.ACTION_REQUEST_SCHEDULE_EXACT_ALARM, calls context.startActivity(intent), logs "Exact alarm permission required. Opened Settings for user to grant permission." (tag DNP-PLUGIN), and rejects with EXACT_ALARM_PERMISSION_REQUIRED.
   • Else: it opens app details (Settings.ACTION_APPLICATION_DETAILS_SETTINGS), logs "Exact alarm permission denied. Directing user to app settings.", and rejects with PERMISSION_DENIED.
3. Only if exact alarms are allowed does the plugin continue to schedule.

So the exact alarms feature here is: gate scheduling on exact alarm permission and, when not granted, open Settings and reject.

---

Evidence from consumer app (logcat)

Filter: DNP-PLUGIN, DNP-SCHEDULE, DailyNotificationWorker, DailyNotificationReceiver.

Typical sequence when user enables daily notification:

1. DNP-PLUGIN: Created pending permission request: ... type=POST_NOTIFICATIONS
2. User grants notification permission.
3. DNP-PLUGIN: Resolving pending POST_NOTIFICATIONS request on resume: granted=true
4. App calls scheduleDailyNotification(...).
5. DNP-PLUGIN: Exact alarm permission required. Opened Settings for user to grant permission.

The consumer app does not call any plugin API to “request exact alarm” or “open exact alarm settings”; it only calls requestPermissions() (POST_NOTIFICATIONS) and then scheduleDailyNotification(). The plugin’s own guard in scheduleDailyNotification() is what opens Settings.

---

Consumer app context

• Permission flow: The app requests POST_NOTIFICATIONS via the plugin’s requestPermissions(), then calls scheduleDailyNotification(). It does not request exact alarm permission itself.
• UX: The app already shows an optional note when exact alarm is not granted (e.g. “If notifications don’t appear, enable ‘Exact alarms’ in Android Settings → Apps → TimeSafari → App settings”). It does not want the plugin to open Settings automatically.
• Manifest: The app declares SCHEDULE_EXACT_ALARM in its AndroidManifest; the issue is only the automatic redirect to Settings and the reject when exact alarm is not yet granted.

---

Suggested plugin changes

1. In scheduleDailyNotification(): Remove the block that opens Settings and rejects when !canScheduleExactAlarms(context) (the block ~1057–1109). Do not call startActivity for ACTION_REQUEST_SCHEDULE_EXACT_ALARM or ACTION_APPLICATION_DETAILS_SETTINGS from this method.
2. Scheduling when exact alarm is not granted: Prefer Option A: continue and schedule even when exact alarms are not allowed (e.g. use inexact/alarm manager APIs that don’t require exact alarm, or document that timing may be approximate). If the plugin must reject when exact is required, use Option B: reject with a specific error code/message and no startActivity.
3. Leave other APIs unchanged: Methods such as openExactAlarmSettings() or requestExactAlarmPermission() can remain for apps that explicitly want to send the user to Settings; the change is only to stop doing it automatically inside scheduleDailyNotification().

---

Relation to existing docs

• Plugin: doc/daily-notification-plugin-android-receiver-issue.md and doc/daily-notification-plugin-checklist.md describe use of SCHEDULE_EXACT_ALARM (not USE_EXACT_ALARM). This feedback does not change that; it only asks to stop auto-opening Settings in scheduleDailyNotification().
• Consumer app: doc/notification-permissions-and-rollovers.md describes the permission flow; doc/NOTIFICATION_TROUBLESHOOTING.md mentions exact alarms for user guidance.

Use this document when implementing the change in the daily-notification-plugin repo (e.g. with Cursor). After changing the plugin, update the consuming app’s dependency (e.g. npm update @timesafari/daily-notification-plugin), then npx cap sync android and rebuild.