75 lines
5.6 KiB
Markdown
75 lines
5.6 KiB
Markdown
# 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.
|