Introduction

AlarmManager does not provide a direct "is this alarm scheduled" query. The usual way to check is to ask Android whether the matching PendingIntent already exists. If it does, you can treat that as evidence that the alarm has been scheduled with that same identity.

The Key Idea: Match the PendingIntent

When you schedule an alarm, you normally pass a PendingIntent created with:

• the same target component
• the same request code
• the same intent action, data, type, class, and categories

To check whether it already exists, recreate that PendingIntent with FLAG_NO_CREATE. Android returns the existing object if one matches, otherwise it returns null.

1val intent = Intent(context, AlarmReceiver::class.java).apply {
2    action = "com.example.SHOW_REMINDER"
3}
4
5val pendingIntent = PendingIntent.getBroadcast(
6    context,
7    1001,
8    intent,
9    PendingIntent.FLAG_NO_CREATE or PendingIntent.FLAG_IMMUTABLE
10)
11
12val isAlarmSet = pendingIntent != null

That is the standard pattern.

Why Matching Matters So Much

The check only works if the identity matches exactly. If you change the request code or use getService instead of getBroadcast, Android treats it as a different PendingIntent.

In practice, this means your "is alarm set" logic must reuse the same construction rules as the scheduling code:

1val intent = Intent(context, AlarmReceiver::class.java).apply {
2    action = "com.example.SHOW_REMINDER"
3}
4
5val pendingIntent = PendingIntent.getBroadcast(
6    context,
7    1001,
8    intent,
9    PendingIntent.FLAG_IMMUTABLE or PendingIntent.FLAG_UPDATE_CURRENT
10)
11
12alarmManager.setExactAndAllowWhileIdle(
13    AlarmManager.RTC_WAKEUP,
14    triggerAtMillis,
15    pendingIntent
16)

If the scheduling code and checking code drift apart, the check becomes unreliable.

Important Detail About Extras

A common trap is assuming extras uniquely identify the PendingIntent. They do not. Extras are not the main identity components used for matching. That is why request code and core intent fields matter more than an extra bundle attached to the intent.

So if you schedule alarms for different records, the safest pattern is often to vary the request code or the intent data URI, not only extras.

Use App State When You Need More Than Presence

This technique answers "does a matching PendingIntent exist." It does not tell you:

• the exact trigger time still registered
• whether the system later deferred delivery
• whether your app logic still considers the alarm valid

If you need stronger guarantees, store alarm metadata in your own persistence layer as well. Many apps keep the intended trigger timestamp in shared preferences or a database and use PendingIntent existence as a secondary check. That extra record is especially useful after app restarts or reminder edits.

Cancel and Replace Predictably

When updating alarms, reuse the same identity and cancel before replacing if needed:

1alarmManager.cancel(pendingIntent)
2alarmManager.setExactAndAllowWhileIdle(
3    AlarmManager.RTC_WAKEUP,
4    newTriggerAtMillis,
5    pendingIntent
6)

Predictable identity management makes both scheduling and checking much easier.

Common Pitfalls

• Expecting AlarmManager to expose a direct query API for scheduled alarms.
• Recreating the PendingIntent with a different request code or target and then trusting the result.
• Assuming intent extras are enough to distinguish alarms.
• Using a different factory method such as getService when the alarm was created with getBroadcast.
• Treating PendingIntent existence as complete proof of timing state instead of only identity presence.

Summary

• There is no direct AlarmManager method to ask whether an alarm already exists.
• The normal solution is to recreate the same PendingIntent with FLAG_NO_CREATE.
• Matching depends on request code and core intent identity, not only extras.
• Keep scheduling and checking logic aligned so the identity stays stable.
• Store your own alarm metadata if you also need exact business-state tracking.