Develop Reference

How do I check if AlarmManager has an alarm set with FLAG_ONE_SHOT

If I create a PendingIntent with FLAG_ONE_SHOT, a subsequent PendingIntent with FLAG_NO_CREATE returns null.
AlarmManager am = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
Intent intent = new Intent(context,AlarmService.class);
PendingIntent pi = PendingIntent.getService(context,this.getId(),intent,PendingIntent.FLAG_ON_SHOT);
GregorianCalendar alarmtime = new GregorianCalendar(now.get(GregorianCalendar.YEAR),now.get(GregorianCalendar.MONTH),now.get(GregorianCalendar.DAY_OF_MONTH),0,0);
//Set the alarm
if (Build.VERSION.SDK_INT<Build.VERSION_CODES.KITKAT) {
am.set(AlarmManager.RTC_WAKEUP,alarmtime.getTimeInMillis(), pi);
} else {
am.setExact(AlarmManager.RTC_WAKEUP, alarmtime.getTimeInMillis(), pi);
}
//Now check if the alarm was set, if it was set, the following PendingIntent should return not null but it doesn't
PendingIntent piCheck = PendingIntent.getService(context,this.getId(),intent,PendingIntent.FLAG_NO_CREATE);
if (piCheck!=null) {
Log.d(TAG,"piCheck returned NOT NULL and probably returned pi");
} else if (piCheck==null) {
Log.d(TAG,"piCheck returned NULL pi does not exist");
However if I change the first pending intent to:
PendingIntent pi = PendingIntent.getService(context,this.getId(),intent,PendingIntent.FLAG_CANCEL_CURRENT);
Then my second PendingIntent returns not null as expected.
Both PendingIntents set an alarm properly, but I cannot "check" the FLAG_ONE_SHOT PendingIntent. What is the reason for this behaviour? What is the purpose of it?

I created a small test program to verify this behaviour. If you create a PendingIntent using FLAG_ONE_SHOT and then pass this to the AlarmManager, it looks like Android "consumes" the PendingIntent immediately so that it no longer exists (because it is a "one-shot", it can only be used once). I would have thought this would happen when the alarm actually triggers, but it looks like that isn't the case.
You learn something new every day :-)
To solve your problem, I would just remove the FLAG_ONE_SHOT as you probably don't need it (just pass 0 as the "flags" argument). If you set the alarm more than once, you can use FLAG_UPDATE_CURRENT if you set the alarm with different extras each time (but it looks like you aren't using any extras, so you probably don't need this). I don't think that you need FLAG_ONE_SHOT for what you are trying to do.

The problem here arises because FLAG_ONE_SHOT describes the PendingIntent and so will be needed to identify it.
You can check for its existence by using FLAG_ONE_SHOT | FLAG_NO_CREATE.
Your code snippet is essentially checking for a different PendingIntent (one without FLAG_ONE_SHOT) which doesn't exist and hence you get null.
You can also try this out with FLAG_IMMUTABLE which is another flag that describes the requested PendingIntent.
I don't think that alarms are involved.

What's "requestCode" used for on PendingIntent?

Background:
I'm using PendingIntent for alarms via AlarmManager.
The problem:
At first I thought that in order to cancel previous ones, I must provide the exact requestCode that I've used before to start the alarm.
But then I've found out I was wrong, as the cancellation API says:
Remove any alarms with a matching Intent. Any alarm, of any type,
whose Intent matches this one (as defined by filterEquals(Intent)),
will be canceled.
looking at "filterEquals", the documentation says:
Determine if two intents are the same for the purposes of intent
resolution (filtering). That is, if their action, data, type, class,
and categories are the same. This does not compare any extra data
included in the intents.
so I don't get what the "requestCode" is for...
The question:
What is "requestCode" used for?
What if I create multiple alarms with the same "requestCode" ? do they override each other?

requestCode is used to retrieve the same pending intent instance later on (for cancelling, etc).
Yes, my guess is the alarms will override each other. I would keep the request codes unique.

I just want to add to #Minhaj Arfin answer
1- requestCode is used to get the same pending intent later on (for cancelling etc)
2- Yes, they will get override as long as your specify the same Receiver to your Intent that you specify on your PendingIntent
example:
Intent startIntent1 = new Intent(context, AlarmReceiverFirst.class);
PendingIntent pendingIntent1 = PendingIntent.getBroadcast(context, 0, startIntent1, 0);
Intent startIntent2 = new Intent(context, AlarmReceiverSecond.class);
PendingIntent pendingIntent2 = PendingIntent.getBroadcast(context, 0, startIntent2, 0);
From above example, they will not override each other because the receiver is different(AlarmReceiverFirst and AlarmReceiverSecond)
Intent startIntent2 = new Intent(context, AlarmReceiverSecond.class);
PendingIntent pendingIntent2 = PendingIntent.getBroadcast(context, 0, startIntent2, 0);
Intent startIntent3 = new Intent(context, AlarmReceiverSecond.class);
PendingIntent pendingIntent3 = PendingIntent.getBroadcast(context, 0, startIntent3, 0);
From above example, they will override each other, because the receiver is same(AlarmReceiverSecond)

Actually, the documentation clearly states what the request code is used for:
If you truly need multiple distinct PendingIntent objects active at
the same time (such as to use as two notifications that are both shown
at the same time), then you will need to ensure there is something
that is different about them to associate them with different
PendingIntents. This may be any of the Intent attributes considered by
Intent#filterEquals(Intent), or different request code integers
supplied to getActivity(Context, int, Intent, int),
getActivities(Context, int, Intent[], int), getBroadcast(Context, int,
Intent, int), or getService(Context, int, Intent, int).
Since it seems that it still isn't that clear, let me try to explain:
When you want to use a PendingIntent object, you don't just instantiate one. Rather, you obtain one from the system using the PendingIntent static methods (getActivity, getBroadcast, getService etc). The system keeps a bunch of PendingIntent instances and gives you one. Which one it gives you, it depends on the input parameters you pass to these getter methods. Those input parameters are: Context, i.e. the target receiver of the intent, the Intent to use, requestCode and flags. When you pass the same Context, the same requestCode and the same Intent (meaning an intent that filterEquals with another intent), you get the same PendingIntent object. The point is that the system wants to have as few PendingIntent objects as possible, so it tends to reuse the existing ones, as much as possible.
For example, you have two calendar notifications, for two different dates. When you click on one of them, you want your app to open to the corresponding date of that notification. In that scenario, you have the same Context target, and the Intent object you are passing differ only in the EXTRA_DATA (which specifies the date that should be open). If you provide the same requestCode when obtaining the PendingIntent object, then you will end up with the same PendingIntent object. So, when creating the second notification, you will replace the old Intent object with the new EXTRA_DATA, and end up with two notifications pointing to the same date.
If you want to have two different PendingIntent objects, as you should in this scenario, you should specify a different requestCode when obtaining the PendingIntent object.

in my case i want to open the same activity with two different intents so if two or more FCMS are there in the tray, any one of them will only open other will not, so i changed the requests codes of pending intent then it worked.
PendingIntent pendingIntent =
PendingIntent.getActivity(this, **Some unique id for all GCMS** /* Request code */, intent,
PendingIntent.FLAG_ONE_SHOT);

one important thing about requestCode that will seriously trouble your app is when using widgets.
widgets will not work after phone reboot if their requestCode are the same.
that means the pendingIndent you set on the remoteViews of your widget must be set unique requestCode, usually the widgetId accompanying a number.

How do I cancel Pending Intents in a Android Widget?

I've got some weird behavior and I can only assume is because of the Pending intents I am using.
Scenario
I have a widget (4x1) which has 4 buttons. Within onUpdate of the widget, I add an pending intent for each button. My intents fires a Service with a bundeled parameter and depending on this parameter starts something. I attach intents as this:
RemoteViews views = new RemoteViews(context.getPackageName(), R.layout.widget_layout);
Bundle b = new Bundle();
b.putString("myVariable", someVariable);
Intent intent = new Intent(context, AppStarterService.class);
intent.putExtras(b);
PendingIntent pendingIntent = PendingIntent.getService(context, buttopnPosition, intent, 0);
views.setOnClickPendingIntent(R.id.btnOne, pendingIntent);
The problem
The code works just fine, until the user decides to update the content of the button. Then, a new Pending Intent is done. So, when I press again the button, sometimes it still executes the old intent and not the new one. I don't know how to explain this better. Let's say for my first intent the parameter is "TestOne", after my update, the new intent has parameter "TestX". When the user clicks on the button, on my service I get in intent extras still "TestOne" instead "TestX". So, my guess is that somehow, I need to cancel the previous intent, when the widget button content changes.
Is this the issue ? Am I doing something wrong ? How do I cancel the old intent, I need to recreate it and then cancel it ?
Thank you for your time.

I you keep having this problem even with FLAG_UPDATE_CURRENT, try defining a different requestCode each time, with something like this:
private static int request = 0;
...
PendingIntent pendingIntent = PendingIntent.getService(context, request++, intent, 0);
So each time a new PendingIntent is created, a new requestCode is used, at least during class life.
I hope it helps.

I think you want to set the flag http://developer.android.com/reference/android/app/PendingIntent.html#FLAG_UPDATE_CURRENT as the last parameter to PendingIntent.getService

Why the PendingIntent doesn't send back my custom Extras setup for the Intent?

This questions somehow relates to the question when I was looking to get the extras back in startActivityForResult but now I face another challenge.
I have subscribed to receive ProximityAlerts and I have explicitly constructed the Intent to include some Extras. But when I got the service the extras are not there.
After the answers here is the working code:
Intent intent = new Intent(this, PlacesProximityHandlerService.class);
intent.setAction("PlacesProximityHandlerService");
intent.putExtra("lat", objPlace.getLat());
intent.putExtra("lon", objPlace.getLon());
intent.putExtra("error_m", objPlace.getError()+ALERT_RANGE_IN_METERS);
PendingIntent sender=PendingIntent.getService(this, 0, intent, 0);
LocationUtils.addProximity(this, objPlace.getLat(), objPlace.getLon(),objPlace.getError()+ALERT_RANGE_IN_METERS, -1, sender);
The documentation says param PendingIntent to be sent for each location update

For some unspecified reason, extras will be delivered only if you've set some action, for example setAction("foo"). What CommonsWare refers to applies only when obtaining PendingIntent instances, if you haven't set FLAG_ONE_SHOT. That can be fixed by the requestCode argument in PendingIntent.get... factory methods. Although documentation says it's currently not used, it actually takes into count when distinguishing PendingIntents.
In your case, you don't need to set anything else than some dummy action string. LocationManagerService reuses the PendingIntent you have subscribed for proximity alerts, and only adds a flag if phone has entered or exited the alarm range.

If you have multiple outstanding PendingIntents, you need to make sure that the underlying Intents differ on more than their extras. Otherwise, Android will keep reusing the first PendingIntent you created for your first Intent, using that first Intent's extras all of the time.
For example, you could add a unique action via setAction() -- that will not change your Intent routing (since you are specifying the component), but it will make your Intents different.

I had this problem and the solution I found was quite simple, though I can't explain why it worked.
Initially my pending intent looked like this:
notificationIntent = new Intent(ctx, FragmentTabsPager.class);
notificationIntent.setData(Uri.parse("content://com.sbs.mobile.workorder.WorkOrder/notes/"));
notificationIntent.putExtra("NOTIFICATION", true);
notificationIntent.putExtra(WorkOrder.WorkOrderColumns.WORKORDERID, submessage);
When creating the intent like this, no extras would be passed when the notification was clicked, the extras map would be empty in the receiving activity. I made the following change to the line initializing the notificationIntent:
notificationIntent = new Intent().setClass(ctx, FragmentTabsPager.class);
Now the extras are populated in the receiving activity. Again, I can't explain why this works but it fixed my problem.

None of the answers worked for me. Setting action to a specific string works for the first time but if you use the same notification with different extras at a later time, it would not work. I replaced the string for the setAction method with a randomly generated one and it works without any issues:
intent.setAction(new Random().nextInt(50) + "_action");
If you think that you might use the notification a lot (Like for downloading different files) then pass a larger number to nextInt()

The key is to set the extras and the unique action into the intent before calling
PendingIntent sender=PendingIntent.getService(this, 0, intent, 0);
if you set the extras and action into the intent after calling the above, it won't work.
This will not work:
Intent intent;
PendingIntent sender=PendingIntent.getService(this, 0,
intent=new Intent(this, PlacesProximityHandlerService.class), 0);
intent.setAction("PlacesProximityHandlerService");
intent.putExtra("lat", objPlace.getLat());

Passing arguments to a BroadcastReceiver through an Intent in Android

I have an application, which sets an alarm using AlarmManager, which starts another Activity when it goes off. The AlarmManager takes a PendingIntent and spawns a BroadcastReceiver class when the specified time comes. I'm wondering whether there is any way that I can pass arguments to this BroadcastReceiver through the Intent object which goes into PendingIntent?
Basically what I'd like to do is something like this:
Intent my_intent = new Intent(this, BroadcastService.class);
PendingIntent pendingIntent = PendingIntent.getBroadcast(this, 0, my_intent, 0);
my_intent.putExtra("arg1", arg1);
AlarmManager alarmManager = (AlarmManager) getSystemService(ALARM_SERVICE);
alarmManager.set(AlarmManager.RTC_WAKEUP, System.currentTimeMillis() + (1000), pendingIntent);
and I'd like to be able to retrieve arg1 in the BroadcastReceiver's onReceive(Context, Intent) method. I figured that the local variable my_intent would be the second parameter passed on to onReceive by the PendingIntent, but apparently that's not quite right. Is it possible to pass parameters between an Activity and a BroadcastReceiver in this fashion (using Intent.putExtra()) or should I use a ContentProvider instead?
Thanks!
Iva

I had a similar problem, but I was already populating the Intent first before wrapping it in a PendingIntent. But the answer to my problem was, as pointed out above, that I needed to use the PendingIntent.FLAG_UPDATE_CURRENT flag. Once I set the flag, it worked! I hope this helps others.
-Jeff

int code=1;
Intent i2 = new Intent(StartAlarm);
i2.putExtra("_id",code);
class test extends BroadcastReceiver {
#Override
public void onReceive(Context context, Intent arg1) {
int i=arg1.getIntExtra("_id",-1);
}
}

I have an application, which sets an
alarm using AlarmManager, which starts
another Activity when it goes off.
That is bad form. Do not pop up activities unannounced like this without a very good reason (e.g., an incoming phone call). What if the user is in the middle of doing something, like TXTing or playing a game or trying to tap numbers for a phone menu?
Is it possible to pass parameters
between an Activity and a
BroadcastReceiver in this fashion
(using Intent.putExtra())
Yes. However, bear in mind that you will want to use PendingIntent.FLAG_UPDATE_CURRENT when you create your PendingIntent, to ensure that any new extras you supply on the Intent actually get used.

Yes, I think it is possible to pass any data of basic Java type and Serializable/Parceable types in the extras of an Intent wrapped around a PendingIntent and then retrieve them using the Intent instance passed to the onReceive of the Broadcastreceiver. Your approach looks okay to me.
What is the problem/error that you are getting? Is "arg1" instance Serializable?