Reminder subsystem: exact alarms, escalation, boot re-arm — verified on emulator
Milestone 4. AlarmScheduler is the only AlarmManager writer; one stable PendingIntent requestCode per dose-time means re-arming replaces and can never stack (the no-drift invariant is OS-enforced). DoseAlarmReceiver handles both occurrence and escalation alarms idempotently and always re-arms the next occurrence before anything else so the chain can't break. nagCount lives in dose_log so the ~6-nag cap survives reboot. SCHEDULE_EXACT_ALARM added maxSdk 32 (USE_EXACT_ALARM is 33+ only). Emulator-verified (API 35): exact alarm armed (window=0, policy_permission), fired on time, HIGH notification with Tatt/Utsett, escalation armed +10 min, next day re-armed, Tatt → TAKEN + inventory 10→9 + escalation cancelled, reboot → BootReceiver re-armed everything. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
parent
63f1ecd9fd
commit
46a5d7e98e
16 changed files with 714 additions and 14 deletions
|
|
@ -54,4 +54,9 @@ data class DoseLog(
|
|||
val status: DoseStatus = DoseStatus.PENDING,
|
||||
/** When the user last acted on it (Taken/Skipped/Snoozed), null while untouched. */
|
||||
val actionedAtMillis: Long? = null,
|
||||
/**
|
||||
* Escalation nags already sent for this occurrence. Lives in the DB, not in
|
||||
* alarm extras, so the ~6-nag cap survives a reboot mid-escalation.
|
||||
*/
|
||||
val nagCount: Int = 0,
|
||||
)
|
||||
|
|
|
|||
|
|
@ -43,4 +43,7 @@ interface DoseLogDao {
|
|||
|
||||
@Query("UPDATE dose_log SET status = :status, actionedAtMillis = :actionedAtMillis WHERE id = :id")
|
||||
suspend fun setStatus(id: Long, status: DoseStatus, actionedAtMillis: Long?)
|
||||
|
||||
@Query("UPDATE dose_log SET nagCount = :nagCount WHERE id = :id")
|
||||
suspend fun setNagCount(id: Long, nagCount: Int)
|
||||
}
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue