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
Intentmust be the same (or both null). Otherwise they do not match. - The “data” in the
Intentmust be the same (or both null). Otherwise they do not match. - The “type” (of the data) in the
Intentmust be the same (or both null). Otherwise they do not match. - The “package” and/or “component” in the
Intentmust 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
Intentmust 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.