Short answer
Remove USE_EXACT_ALARM from the manifest unless the app is an alarm, timer or calendar app. If a feature still needs exact timing, request SCHEDULE_EXACT_ALARM, check canScheduleExactAlarms() before you schedule, and send the user to the settings screen when it is off. Most reminders work with inexact alarms. Then upload a new release.
Rather not fix it yourself? App Fix Ticket starts with a fixed-price diagnosis, then a fixed price for the fix before any fix work.
Why Play flags it, and the fix
01
The app isn’t an alarm, timer or calendar app
“USE_EXACT_ALARM is a restricted permission and apps must only declare this permission if their core functionality supports the need for an exact alarm.” Google Play Help, Exact Alarm Permission policy
Android grants USE_EXACT_ALARM without asking the user, so Play restricts it and reviews apps that declare it. A to-do list, a habit tracker or a reminder inside another app doesn’t qualify, even when its reminders are time based.
02
A plugin’s setup told you to add it
Notification and reminder plugins for Flutter and React Native may list USE_EXACT_ALARM in their setup steps, or ship it in their own manifest. Check the Merged Manifest tab in Android Studio, then remove it so it doesn’t come back.
<manifest xmlns:android="http://schemas.android.com/apk/res/android" xmlns:tools="http://schemas.android.com/tools"> <uses-permission android:name="android.permission.USE_EXACT_ALARM" tools:node="remove" /> <uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM" /> </manifest>03
Use SCHEDULE_EXACT_ALARM and ask the user
“If your app does not have this specific core need, consider using SCHEDULE_EXACT_ALARM permission instead. It provides the same functionality but access must be granted by the user.” Google Play Help, Exact Alarm Permission policy
SCHEDULE_EXACT_ALARM does the same job, but the user has to turn it on. Check for it before each exact alarm, and fall back to an inexact alarm or open the settings screen when it is off. canScheduleExactAlarms() and that settings screen need Android 12 (API 31) or higher; on older versions, skip the check.
val am = context.getSystemService(AlarmManager::class.java) if (Build.VERSION.SDK_INT < Build.VERSION_CODES.S || am.canScheduleExactAlarms()) { am.setExactAndAllowWhileIdle(AlarmManager.RTC_WAKEUP, timeMs, pendingIntent) } else { // from an Activity; from other contexts add FLAG_ACTIVITY_NEW_TASK startActivity(Intent(Settings.ACTION_REQUEST_SCHEDULE_EXACT_ALARM, Uri.parse("package:$packageName"))) }04
The permission is off on Android 14 installs
“Check the permission with canScheduleExactAlarms() before scheduling exact alarms.” Android Developers, Schedule exact alarms are denied by default
On Android 14, SCHEDULE_EXACT_ALARM starts as denied for most new installs of apps that target Android 13 or higher. An app that assumes it can set exact alarms crashes or misses them, so always check first.
05
Most reminders don’t need an exact alarm
“Note: Most apps can schedule tasks and events using inexact alarms.” Android Developers, Schedule alarms
A reminder that fires a minute late is fine for most apps. Inexact alarms or WorkManager need no special permission and respect battery saving.
Checked against the vendor’s docs on : Google Play Help: Permissions and APIs that Access Sensitive Information (Exact Alarm Permission); Android Developers: Schedule exact alarms are denied by default; Android Developers: Schedule alarms.
Rather hand it over?
Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.
“Very responsive, attentive to fixing bugs, and completed the project as needed! Thank you!”
Related: Google Play QUERY_ALL_PACKAGES rejection · Google Play foreground service declaration · Google Play target API level 35 · Google Play invalid privacy policy