How we approach Android 14 background restrictions for reliable alarms
Android’s background limits exist for good reasons: battery, privacy, and predictability. For a product like WakeQuest, those same limits collide with a simple promise—the alarm must fire when the user asked for it. This post explains how we think about compliance and reliability without treating them as opposites.
Foreground work is not a hack—it is the contract
When user-visible work must run on a schedule (or immediately after a schedule), we design around foreground services where appropriate. That means proper notification channels, clear user communication, and types that match what the OS expects. Foreground is the platform’s way of saying: “this work is important enough to bypass aggressive idle policies.”
Exact alarms are a privilege—earn them in UX and policy
From Android 12 onward, SCHEDULE_EXACT_ALARM and related changes mean exact timing is gated. We request capabilities only when the product truly needs wall-clock fidelity, and we degrade gracefully when the user or OEM denies them—while still surfacing clear settings paths to restore reliability.
Full-screen intents and lock-screen presentation
Where policy allows, presenting the alarm across the lock screen reduces “swipe away half asleep” failures. We treat USE_FULL_SCREEN_INTENT as a serious permission: used for time-critical flows, documented for store review, and never for ads or unrelated surfaces.
Checklist we use before every major Android release
- Re-read behaviour changes for target SDK and test on low-RAM devices.
- Validate OEM-specific battery savers (manufacturers still matter).
- Confirm notification channels, categories, and user-dismiss paths.
- Measure cold start and service bring-up latency after force-stop.
If you are building habit or safety-critical mobile software and want a UK-based engineering partner, talk to us.