# Consuming App Notes — Android Daily Notifications

Brief notes for apps that integrate the daily notification plugin on Android.

---

## Double schedule (rapid successive calls)

If your app calls `scheduleDailyNotification` twice in quick succession (e.g. within a few hundred ms) for the same reminder, the second call cancels the alarm just set and reschedules. On some devices or OEMs this can contribute to the alarm not firing.

**Recommendation:** Debounce or guard in the edit-reminder success path so you only call `scheduleDailyNotification` once per user action (e.g. wait for the first call to resolve before allowing another, or coalesce rapid calls).

---

## Alarm scheduled but not firing (e.g. 6:04)

When logs show "Scheduling OS alarm" and "Updated schedule in database" but the notification never appears:

1. **Confirm the broadcast is delivered**  
   Run logcat including the receiver:
   ```bash
   adb logcat -v time -s DNP-SCHEDULE:V DailyNotificationWorker:V DailyNotificationReceiver:V
   ```
   At the scheduled time, check whether `DailyNotificationReceiver` logs anything. If the Receiver runs, the issue is downstream (WorkManager / display). If it does not run, the OS did not deliver the alarm (Doze, OEM, or alarm replacement).

2. **Avoid double schedule**  
   Ensure the app is not calling `scheduleDailyNotification` twice in quick succession for the same reminder (see above).

3. **Plugin fix (v1.1.6+)**  
   The plugin no longer overwrites the app’s schedule row when handling rollover work that uses a `daily_rollover_*` id, so the app’s `nextRunAt` stays correct after a notification fires.

---

## References

- [ACTION_PLAN_INTEGRATION_FIXES.md](../integration/ACTION_PLAN_INTEGRATION_FIXES.md) — plugin and app integration checklist
- [CONSUMING_APP_OPTIONAL_ANDROID_ID_CLEANUP.md](./CONSUMING_APP_OPTIONAL_ANDROID_ID_CLEANUP.md) — optional cleanup of stale schedule rows
