24

I'm using AlarmManager to schedule anywhere between 1 and 35 alarms (depending on user input). When the user requests to schedule new alarms, I need to cancel the current alarms, so I create all of my alarms with the same requestCode, defined in a final variable.

// clear remaining alarms
Intent intentstop = new Intent(this, NDService.class);
PendingIntent senderstop = PendingIntent.getService(this,
            NODIR_REQUESTCODE, intentstop, 0);
am.cancel(senderstop);

// loop through days
if (sched_slider.getBooleanValue())
for (int day = 1; day < 8; day++) {

    if (day == 1 && sun.isChecked())
                scheduleDay(day);
    if (day == 2 && mon.isChecked())
                scheduleDay(day);
    if (day == 3 && tue.isChecked())
                scheduleDay(day);
    if (day == 4 && wed.isChecked())
                scheduleDay(day);
    if (day == 5 && thu.isChecked())
                scheduleDay(day);
    if (day == 6 && fri.isChecked())
                scheduleDay(day);
    if (day == 7 && sat.isChecked())
                scheduleDay(day);
}

...

public void scheduleDay(int dayofweek) {
    Intent toolintent = new Intent(this, NDService.class);
    toolintent.putExtra("TOOL", "this value changes occasionally");
    PendingIntent pi = PendingIntent.getService(this,
                NODIR_REQUESTCODE, toolintent, 0);
    calendar.set(Calendar.DAY_OF_WEEK, dayofweek);
    calendar.set(Calendar.HOUR_OF_DAY, hour);
    calendar.set(Calendar.MINUTE, minute);
    calendar.set(Calendar.SECOND, 0);
    am.setRepeating(AlarmManager.RTC, calendar.getTimeInMillis(),
                AlarmManager.INTERVAL_DAY * 7, pi);
}

Here, if the user has sun (which is a CheckBox) checked, it will schedule an alarm to run every Sunday at hour and minute. You can see that every alarm created this way has the same requestCode, but the TOOL extra changes sometimes for each alarm.

However, in my testing, when the alarm goes off and my Service runs, the extras from the Intent are now null. This question suggests that using PendingIntent.FLAG_CANCEL_CURRENT will solve this, but wouldn't that cancel the other PendingIntents?

In short:

Can someone explain how PendingIntents work, in reference to creating multiple ones with the same requestCode and different extras? What flags (if any) should I be using?

Community
  • 1
  • 1
Snailer
  • 3,777
  • 3
  • 35
  • 46

2 Answers2

88

Actually, you don't "create" PendingIntents. You request them from the Android framework. When you request a PendingIntent from the Android framework, it checks to see if there is already a PendingIntent that matches the criteria you pass as arguments. If so, it does not create a new PendingIntent, it just gives you back a "token" that points to the existing PendingIntent. If it doesn't find a matching PendingIntent, it will create one and then give you back a "token" that points to the one it just created. There are some flags that you can set to modify this behaviour, but not that much. The most important thing to understand here is the way the Android framework does the matching.

To do this it checks if the following parameters match (comparing the existing PendingIntent with the parameters you have passed):

  • Request codes must be the same. Otherwise they do not match.
  • The "action" in the Intent must be the same (or both null). Otherwise they do not match.
  • The "data" in the Intent must be the same (or both null). Otherwise they do not match.
  • The "type" (of the data) in the Intent must be the same (or both null). Otherwise they do not match.
  • The "package" and/or "component" in the Intent must be the same (or both null). Otherwise they do not match. "package" and "component" fields are set for "explicit" Intents.
  • The list of "categories" in the Intent must be the same. Otherwise they do not match.

You should notice that "extras" is not in the list above. That means that if you request a PendingIntent the "extras" are not taken into consideration when the Android framework tries to find a matching PendingIntent. This is a common mistake that developers make.

We can now address the additional flags that you can add to modify the behaviour of a PendingIntent request:

FLAG_CANCEL_CURRENT - When you specify this flag, if a matching PendingIntent is found, that PendingIntent is cancelled (removed, deleted, invalidated) and a new one is created. This means that any applications that are holding a "token" pointing to the old PendingIntent will not be able to use it, because it is no longer valid.

FLAG_NO_CREATE - When you specify this flag, if a matching PendingIntent is found, a "token" pointing to the existing PendingIntent is returned (this is the usual behaviour). However, if no matching PendingIntent is found, a new one is not created and the call just returns null. This can be used to determine if there is an active PendingIntent for a specific set of parameters.

FLAG_ONE_SHOT - When you specify this flag, the PendingIntent that is created can only be used once. That means that if you give the "token" for this PendingIntent to multiple applications, after the first use of the PendingIntent it will be canceled (removed, deleted, invalidated) so that any future attempt to use it will fail.

FLAG_UPDATE_CURRENT - When you specify this flag, if a matching PendingIntent is found, the "extras" in that PendingIntent will be replaced by the "extras" in the Intent that you pass as a parameter to the getxxx() method. If no matching PendingIntent is found, a new one is created (this is the normal behaviour). This can be used to change the "extras" on an existing PendingIntent where you have already given the "token" to other applications and don't want to invalidate the existing PendingIntent.

Let me try to address your specific problem:

You cannot have more than one active PendingIntent in the system if the request code, action, data, type and package/component parameters are the same. So your requirement to be able to have up to 35 active PendingIntents all with the same request code, action, data, type and package/component parameters, but with different "extras", is not possible.

I would suggest that you either use 35 different request codes, or create 35 different unique "action" parameters for your Intent.

David Wasser
  • 93,459
  • 16
  • 209
  • 274
  • 1
    Thank you for your help! My Intents don't have data or actions, so you're saying I could potentially randomize one of those fields? And if I do this, I wouldn't really need to worry about the flags at all? – Snailer Nov 26 '13 at 00:17
  • Oh I just thought of something as well.. If I randomized, say, the Action, then the "clear alarm" section of my code wouldn't work. I'd have to keep a record of the randomized Actions and set the Intents Action in a loop to clear all the alarms, correct? – Snailer Nov 26 '13 at 00:30
  • Yes, you would. That's exactly what you need to do. – David Wasser Nov 26 '13 at 10:16
  • 5
    Thanks for this. The Android documentation is not that great regarding this...This is the only explanation that made sense for me. – MinaHany Nov 22 '16 at 07:57
  • I think you missed the Uri. – Muhammad Babar Dec 23 '16 at 13:18
  • @MuhammadBabar No. The "Uri" is part of the **data** (which I mentioned). If you look at the `` documentation, you will see a `` specifier, not a `` specifier. – David Wasser Dec 23 '16 at 13:44
  • 1
    Thank you so much for such a detailed answer – Sohail Saha Apr 25 '20 at 08:47
5

Yes it is possible just put unique intent action for each alarm

intent.setAction("uniqueCode");

Intent intent = new Intent(context, MyAlarmReciver.class);
intent.setAction("uniqueCode");
PendingIntent pendingIntent = PendingIntent.getBroadcast(activity, 0,   intent, 0);
AlarmManager alarmManager = (AlarmManager)       context.getSystemService(activity.ALARM_SERVICE);
Calendar c = Calendar.getInstance();
c.add(Calendar.MINUTE, 1);
alarmManager.set(AlarmManager.RTC_WAKEUP, c.getTimeInMillis(),   pendingIntent);
Dayanand Waghmare
  • 2,979
  • 1
  • 22
  • 27