Decide how exact the task must be
| Task | Starting API choice |
|---|---|
| Periodic background synchronization | WorkManager or another appropriate scheduled-work API |
| Reminder with flexible timing | Inexact alarm where suitable |
| User-configured alarm clock | Exact-alarm APIs and applicable access |
| Ongoing visible operation | The appropriate foreground or specialized API |
The alarm documentation explains API behavior and permission differences. SCHEDULE_EXACT_ALARM and USE_EXACT_ALARM are not interchangeable declarations with identical eligibility.
Check access instead of assuming it
For the relevant API/version path, use AlarmManager.canScheduleExactAlarms() before scheduling operations that require special access. If the feature needs a settings flow, explain why and recheck when the user returns.
An app installed through an upgrade path can have a different initial state from a clean installation. Test both rather than relying on a development device's historical grant.
Make denial a supported state
Offer an inexact reminder or clearly describe the unavailable timing guarantee when access is missing. Do not report an exact alarm as scheduled if the call failed, and do not loop through settings without a fresh user action.
Persist the user's intended reminder independently from the platform scheduling state so you can show an accurate status after restart or access changes.
Review Google Play eligibility
Play's permission policy can restrict use of exact-alarm declarations based on the app's core function. Technical success on a phone is not evidence that a distribution use case qualifies.
Keep a feature rationale and review the current policy before choosing the declaration for a release.
Test the complete reminder lifecycle
Test schedule, cancel, edit, device restart, time-zone change and permission revocation. Confirm that duplicate reminders are not created after a retry. APKLint's Manifest Checker can identify the declarations, but it cannot verify timing behavior or store eligibility. The release needs device evidence and a deliberate fallback strategy.
Sources and further reading
- Android Developers: Schedule alarms
- Google Play: Permissions and APIs that access sensitive information
Reference review: 22 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
