Flutter Exact Alarms on Android 14+: SCHEDULE_EXACT_ALARM, USE_EXACT_ALARM and Play Policy (2026)

By giosaia (GSPTeck) · Published 2026-10-29 · Last verified 2026-10-29

Do Flutter apps still get exact alarms on Android 14 and later?

Only if the user grants them, or if your app is a genuine alarm clock or calendar app. Since Android 14, the SCHEDULE_EXACT_ALARM permission is no longer pre-granted to most newly installed apps that target Android 13 (API level 33) or higher; it's denied by default. The alternative, USE_EXACT_ALARM, is granted on install, but Google says apps can't publish a version with it in the manifest unless they qualify under Play policy. For most indie Flutter apps, that means: use inexact scheduling where you can, ask for exact alarms only for a real user-facing need, and check the permission at runtime. This is the routine I use for GSPTeck's apps, with the official rules behind each step.

Based on Android Developers documentation and the flutter_local_notifications package page, checked 2026-10-29. Play policy wording can change; read the current policy before you submit.

What changed, in one table

Android's docs add two edge cases. If a user moves app data to an Android 14 device through backup and restore, SCHEDULE_EXACT_ALARM is still denied on the new device. If an existing install already had the permission, it's pre-granted when the device upgrades to Android 14.

Step 1: decide whether you need exact alarms at all

Android's guide says most apps can schedule tasks and events with inexact alarms, and exact alarms are for core features such as an alarm clock or a calendar. It lists common cases that don't need them:

• Timing while the app is running: use a Handler with postAtTime() or postDelayed(); in Flutter, a Timer is the everyday equivalent.
• Background work such as syncing or uploading logs: use WorkManager, whose periodic work has a 15-minute minimum interval.
• "Remind me after a certain time": an inexact alarm with set(), or setAndAllowWhileIdle() if it must fire during idle.
• "Within this window": setWindow(). For apps targeting Android 12 or higher, the smallest allowed window is 10 minutes.

Know what "inexact" means in practice: on Android 12 and higher, an inexact alarm never fires before its trigger time and is delivered within one hour of it, unless battery-saving restrictions such as Doze or battery saver apply. If your reminder can be up to an hour late, you don't need exact alarms.

Step 2: if you do need them, pick the right permission

If your app is an alarm clock or calendar that must alert the user when the app isn't running, USE_EXACT_ALARM is designed for you, and users won't see a prompt. For everything else, declare SCHEDULE_EXACT_ALARM and ask the user. Don't declare USE_EXACT_ALARM "just in case": Android's docs say you can't publish a version with it in the manifest unless you qualify under the policy, and the flutter_local_notifications documentation warns it may be subject to approval and auditing by the app store.

The methods that require the permission are setExact(), setExactAndAllowWhileIdle() and setAlarmClock(); calling them without it throws a SecurityException. One exception: an exact alarm set with an OnAlarmListener doesn't need the permission.

Step 3: wire it up in Flutter

Most Flutter apps schedule reminders with flutter_local_notifications. Its zonedSchedule() takes an androidScheduleMode. AndroidScheduleMode.exactAllowWhileIdle asks for exact delivery even in idle mode and needs the exact alarm permission; the package docs say that if the permission has been revoked, the plugin logs an error and doesn't schedule it, and that's where you can fall back to an inexact mode.

1. Declare SCHEDULE_EXACT_ALARM in AndroidManifest.xml.
2. Explain in your UI why the reminder must be on time.
3. Call the plugin's requestExactAlarmsPermission(), which takes the user to the "Alarms & reminders" setting. On the native side this is the ACTION_REQUEST_SCHEDULE_EXACT_ALARM intent.
4. Before each exact schedule, check the permission (native: canScheduleExactAlarms()). If it's not granted, schedule inexact instead and tell the user.

Step 4: handle grants, revokes and reboots

Android's docs say that when the permission is revoked, your app stops and all future exact alarms are cancelled. When it's granted, the system sends ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED; your receiver should confirm the permission with canScheduleExactAlarms() and reschedule the alarms you need. Alarms are also cleared on reboot, which is why flutter_local_notifications asks for the RECEIVE_BOOT_COMPLETED permission so it can reschedule. In practice: keep your schedule in storage, and rebuild it on app start, on boot and on permission grant.

Step 5: test like a new user

• Fresh install on Android 14 or later. Confirm the permission starts denied and your fallback works.
• Grant, then revoke in system settings. Confirm alarms are rebuilt after granting and the app degrades gracefully after revoking.
• Reboot and check pending notifications.
• Doze. Leave the device idle and check that inexact reminders still arrive within your tolerance.

Then update the Play Console declarations that relate to the change; my Data safety and SDK refresh routine covers that pass. If you're also moving to API 36, pair this with the predictive back migration and the target API 36 deadline notes, and ship through a staged rollout.

Two examples of how I'd decide

A daily "drink water" nudge can arrive up to an hour late without anyone noticing, so it gets an inexact schedule and no extra permission. A reminder the user set for a specific time, such as "call the dentist at 15:00", is a user-facing feature that needs precise timing, so it gets SCHEDULE_EXACT_ALARM, a short explanation, a request and an inexact fallback if the user says no. Neither is an alarm clock or a calendar app, so neither declares USE_EXACT_ALARM.

Write that reasoning down. If a reviewer or a user asks why your app wants "Alarms & reminders", a one-line answer tied to a visible feature is much easier to give than a vague one.

FAQ

Why don't my Flutter scheduled notifications fire on time on Android 14?

SCHEDULE_EXACT_ALARM is denied by default for most new installs of apps targeting Android 13 or higher. Without it, exact schedules fail, and inexact alarms can arrive up to an hour late.

Should I just declare USE_EXACT_ALARM?

Only if your app is an alarm clock or calendar app. Android's docs say you can't publish with it unless you qualify under Google Play policy.

Can users revoke exact alarm access?

Yes, SCHEDULE_EXACT_ALARM can be revoked by the user or the system. When that happens, the app stops and all future exact alarms are cancelled.

Do I need exact alarms for a daily reminder?

Usually not. An inexact alarm, or a scheduled notification in an inexact mode, is enough if a delay of up to an hour is acceptable.

Sources

• Android Developers: Schedule alarms (checked 2026-10-29)
• Android Developers: Schedule exact alarms are denied by default (Android 14) (checked 2026-10-29)
• pub.dev: flutter_local_notifications (checked 2026-10-29)