How to Fix Google Play USE_EXACT_ALARM Rejection
Remove an ineligible USE_EXACT_ALARM permission or prove that precise timing is indispensable to the app's core alarm, timer, or calendar experience.
Direct answer
First decide whether the app qualifies for USE_EXACT_ALARM, not merely whether its code uses exact alarms. Google restricts this automatically granted permission to apps whose core, user-facing functionality genuinely requires precise timing, listing alarm or timer apps and calendar apps with event notifications as acceptable use cases. If that is not the app's main purpose, remove USE_EXACT_ALARM from the final merged manifest. Use an inexact alarm or WorkManager when precision is unnecessary; if a legitimate secondary feature still needs exact timing, evaluate the user-granted SCHEDULE_EXACT_ALARM permission and implement its denial and revocation flow. Keep USE_EXACT_ALARM only when the signed release, store listing, declaration, and reviewer-visible core experience all prove eligibility.
Match the wording in your rejection
Google says the app is not eligible to use USE_EXACT_ALARM
The reviewer could not verify that an alarm, timer, or calendar experience requiring precise timing is the app's core purpose. A useful reminder or notification feature alone does not establish eligibility for the automatically granted permission.
The permission remains after you removed exact-alarm code
Inspect the final merged manifest and every relevant release artifact. A library, product flavor, manifest overlay, or older active version can still contribute USE_EXACT_ALARM.
The core functionality declaration does not match the app
Reconcile the Play Console answer, store listing, signed version, and first-run reviewer path. Describing the app as an alarm or calendar tool in the declaration is not enough when the shipped experience shows a different primary purpose.
The replacement with SCHEDULE_EXACT_ALARM does not work on a fresh install
This permission is user-granted and is not pre-granted to many fresh installs targeting Android 13 or higher. Check access before scheduling and provide a usable denial, revocation, and rescheduling flow.
What this rejection usually means
A USE_EXACT_ALARM rejection is usually an eligibility mismatch rather than an AlarmManager implementation bug. On Android 13 and later, USE_EXACT_ALARM provides exact-alarm access automatically and cannot be revoked by the user, so Google Play restricts it to core, user-facing experiences that genuinely require precise timing. The common failure modes are a secondary reminder feature presented as core functionality, a stale permission contributed to the merged manifest, a Play Console declaration that does not match the signed release, or an unnecessary exact alarm where system-batched work would meet the product promise.
Likely rejection signals
- The app is not principally an alarm, timer, or calendar product
- A notification, medication reminder, booking reminder, sync, refresh, or analytics task could tolerate a timing window
- USE_EXACT_ALARM appears only after manifest merging or dependency updates
- The store listing does not prominently describe the precisely timed feature as the app's main purpose
- The declaration, demonstration, and reviewed version code show different flows
- The app replaced the permission but does not handle SCHEDULE_EXACT_ALARM denial or revocation
Recovery plan
- Preserve the full policy notice and record the package name, affected version code, target SDK, release track, cited permission, declaration status, and review date. Do not resubmit an unchanged bundle.
- Inspect the signed Android App Bundle and merged manifest for every relevant variant. Trace USE_EXACT_ALARM to the app module, library, SDK, plugin, or overlay that contributes it, and inventory every exact and inexact AlarmManager call.
- Write the user promise for each alarm in one sentence and classify the required precision. If a delay within a reasonable window does not break that promise, replace the exact alarm with an inexact alarm, WorkManager, or JobScheduler rather than changing only the declaration.
- Apply Google's eligibility test to USE_EXACT_ALARM. Verify that precise timing is essential to the app's core, user-facing purpose and that the shipped product is genuinely an alarm or timer app, or a calendar app that shows event notifications. A secondary reminder feature should not be relabeled as the app's core purpose.
- If the app does not qualify, remove USE_EXACT_ALARM from the source and final merged manifest. For a legitimate secondary exact-timing use case, evaluate SCHEDULE_EXACT_ALARM instead; explain the need before opening system settings, call canScheduleExactAlarms() before scheduling, handle denial and revocation, and reschedule only after access is confirmed.
- If the app qualifies, keep only USE_EXACT_ALARM rather than declaring both permissions for the same device. Verify the exact alarm creates the promised user-visible result and that the store title, description, screenshots, and Play Console declaration consistently present the eligible core experience.
- Audit every release track and version code included in the submission. Replace or deactivate obsolete artifacts that still request USE_EXACT_ALARM when the current compliant release no longer needs it.
- Test the signed release on clean installs and upgrades across supported Android versions. Cover device restart, permission state, app force-stop, time-zone and clock changes where relevant, alarm delivery, cancellation, and the fallback experience when exact-alarm access is unavailable.
- Submit one corrected release or one evidence-based appeal. State the exact version code and whether USE_EXACT_ALARM was removed, replaced with SCHEDULE_EXACT_ALARM, or retained under an eligible core use case. Give the reviewer the shortest path to verify the result.
Evidence to prepare
- Complete policy notice, package name, target SDK, release track, and affected version code
- Merged-manifest report showing whether USE_EXACT_ALARM or SCHEDULE_EXACT_ALARM is present and which module contributed it
- Inventory of AlarmManager calls with the product requirement and acceptable timing tolerance for each
- Signed-release recording showing the core precisely timed user journey or the corrected fallback
- Play Console declaration and store-listing screenshots that match the reviewed release
- Clean-install and upgrade test results covering grant, denial, revocation, restart, cancellation, and alarm delivery
- Artifact inventory confirming that obsolete production and testing versions no longer carry an ineligible permission
Appeal or fix first?
Clarify or appeal when the exact signed version under review is genuinely an eligible alarm, timer, or calendar product, its core result requires precise timing, and the manifest, declaration, listing, and reviewer path already prove those facts. Also appeal when version-specific evidence shows Google evaluated an older artifact that still contained the permission.
Fix and resubmit when exact timing is secondary or unnecessary, USE_EXACT_ALARM remains through a dependency or older artifact, the declaration overstates the app's core purpose, or the replacement does not correctly handle user-granted SCHEDULE_EXACT_ALARM access.
Reviewer response framework
Your response should be factual, short, and limited to the submitted build. Cover these points:
- Identify the package, target SDK, release track, version code, and exact permission cited.
- State whether USE_EXACT_ALARM was removed, replaced, or retained, and why that completed choice matches the policy.
- Name the specific user-facing alarm, timer, or calendar flow and explain why precise timing is or is not indispensable.
- Confirm the final merged manifest and all relevant release artifacts were checked.
- Provide exact reviewer navigation, an accessible recording, and only facts present in the signed release.
Frequently asked questions
What is the difference between USE_EXACT_ALARM and SCHEDULE_EXACT_ALARM?
Both enable exact-alarm capabilities, but USE_EXACT_ALARM is automatically granted, cannot be revoked by the user, and is tightly restricted by Google Play. SCHEDULE_EXACT_ALARM is user-granted, supports broader use cases, and requires the app to check and handle the current access state.
Can a reminder app use USE_EXACT_ALARM?
Only if the app satisfies Google's restricted core-functionality policy. A reminder feature inside a broader product is not automatically eligible; Google directs other exact-timing use cases to evaluate SCHEDULE_EXACT_ALARM.
Can I replace exact alarms with WorkManager?
Yes when the work can be deferred or run within a timing window. WorkManager is not a substitute when the user-facing promise truly depends on delivery at an exact moment.
Why does Play still detect USE_EXACT_ALARM after I removed it?
A dependency, plugin, product flavor, manifest overlay, or older release artifact may still contribute the permission. Inspect the signed bundle's merged manifest and every relevant track, not only the main source manifest.
Should I appeal after changing to SCHEDULE_EXACT_ALARM?
Usually submit the corrected release when the rejected bundle was ineligible. Appeal only when the reviewed artifact already complied or Google evaluated the wrong version, and support that claim with version-specific evidence.
Need a rejection-specific plan?
Start with the free diagnosis. The $29 Fix Pack adds the prioritized remediation plan, evidence checklist, reviewer-ready reply, and preflight.
Source: Google Play — Exact Alarm Permission policy. Platform policies change. Verify the official rule before submitting. Resubmit AI provides technical and editorial decision support, not an approval guarantee or legal advice.