The five-minute warning did not arrive in the one case it exists for.
The deadline is enforced by two things - a main-looper Handler and an
alarm - while the warning had only the alarm, and that alarm is inexact
on purpose so the app can stay off SCHEDULE_EXACT_ALARM. Doze defers an
inexact alarm freely, and with the app closed it deferred this one past
the end of the session it was warning about.
Measured on an emulator, app swiped from recents and its process killed,
screen off, deviceidle forced to IDLE, 7-minute session:
before warning never fired; request code 1002 never delivered and
handleSessionWarningAlarm never ran. Expiry was still punctual
(16:00:55 against a 16:00:54 deadline) because the deadline has
its Handler.
after warning posted as the session crossed 300 s remaining, app
still closed and device still IDLE; expiry unchanged.
So give the warning the same backstop that already makes the deadline
reliable. postDelayed runs on uptimeMillis, so a genuinely suspended
device still fires it late - handleSessionWarningAlarm then drops it on
the existing window check instead of claiming "5 minutes" with seconds
left. The alarm stays for the case where the process was restarted and
no Handler callback survives.
Note this does not make the warning punctual under true suspend; only
SCHEDULE_EXACT_ALARM would, and that permission is deliberately not
declared.
Co-Authored-By: Claude Opus 5 <[email protected]>
