Introduction

When an Android notification opens an activity with stale extras, the usual culprit is not the notification UI itself. It is PendingIntent reuse: Android may treat two intents as the same PendingIntent even when their extras differ, so an old PendingIntent gets reused and delivers outdated data.

Why the Old Extras Show Up

The important detail is that extras are not the main thing Android uses when deciding whether an existing PendingIntent matches a new one. If you create multiple notification intents with the same request code and otherwise equivalent intent identity, Android may hand back the old PendingIntent.

That means your new extras never really replace the old delivery object unless you:

• update the existing PendingIntent
• use a different request code
• change the underlying intent identity in a meaningful way

This is why the bug often looks mysterious. The notification content looks new, but tapping it still opens the activity with old data.

The Common Broken Pattern

1Intent intent = new Intent(context, DetailActivity.class);
2intent.putExtra("message_id", newMessageId);
3
4PendingIntent pendingIntent = PendingIntent.getActivity(
5    context,
6    0,
7    intent,
8    PendingIntent.FLAG_IMMUTABLE
9);

If you reuse request code 0 for many notifications and do not request an update, Android can keep returning the old PendingIntent.

The Standard Fix: FLAG_UPDATE_CURRENT

Use FLAG_UPDATE_CURRENT when you want new extras to replace the old extras for an equivalent PendingIntent.

1Intent intent = new Intent(context, DetailActivity.class);
2intent.putExtra("message_id", newMessageId);
3
4PendingIntent pendingIntent = PendingIntent.getActivity(
5    context,
6    0,
7    intent,
8    PendingIntent.FLAG_UPDATE_CURRENT | PendingIntent.FLAG_IMMUTABLE
9);

Now, if Android matches an existing PendingIntent, it updates its extras with the new intent data.

For many notification flows, this is the correct fix.

Another Fix: Unique Request Codes

If every notification should remain distinct, use a unique request code per notification.

1int requestCode = (int) System.currentTimeMillis();
2
3PendingIntent pendingIntent = PendingIntent.getActivity(
4    context,
5    requestCode,
6    intent,
7    PendingIntent.FLAG_IMMUTABLE
8);

This prevents collisions between otherwise similar notification intents.

Use this when tapping each notification should open a different logical payload rather than replacing one shared destination state.

Distinct Notifications vs Updated Notifications

You should decide which behavior you actually want:

• one logical notification that gets updated over time
• many independent notifications, each with its own payload

If the notification is conceptually “the latest status,” then reusing the request code plus FLAG_UPDATE_CURRENT is often right.

If each notification represents a unique event, then a unique request code is usually better.

The technical fix depends on the product behavior you want.

Intent Identity Nuance

Changing extras alone is often not enough to make the PendingIntent distinct. If needed, you can also differentiate the intent by changing its action or data URI.

intent.setAction("open_message_" + newMessageId);

That can help when request-code strategies are awkward, but in most apps FLAG_UPDATE_CURRENT or unique request codes are the clearer fixes.

Modern Flag Requirements

On newer Android versions, you must also choose whether the PendingIntent is mutable or immutable. If you do not need external mutation, FLAG_IMMUTABLE is the safer default. That security choice is separate from the stale-extras bug, but both flags often appear in the same line of code.

Common Pitfalls

• Reusing the same request code for many notifications while assuming different extras automatically create a new PendingIntent.
• Omitting FLAG_UPDATE_CURRENT when the intent should update an existing notification action with fresh extras.
• Using unique notifications conceptually but still creating all of them with the same PendingIntent identity.
• Debugging only the receiving activity instead of checking how the PendingIntent was created.
• Confusing immutable-versus-mutable PendingIntent behavior with the separate issue of whether old extras are being reused.

Summary

• Old notification extras are usually caused by PendingIntent reuse, not by the notification view.
• Extras alone do not reliably make one PendingIntent distinct from another.
• Use FLAG_UPDATE_CURRENT when the latest payload should replace the old one.
• Use unique request codes when each notification should remain independent.
• Fix the PendingIntent creation logic first; the receiving activity is usually not the root cause.