Fix PendingIntent FLAG_IMMUTABLE or FLAG_MUTABLE Error in MediaSessionCompat on Android 12+

By the end of this page, you will understand why Android 12+ requires explicit PendingIntent mutability flags, why older MediaSessionCompat versions can still crash even if they appear to support Android S, and how to fix the issue by updating dependencies or creating PendingIntents correctly in Android apps.

Android 12 (API 31, also called Android S) introduced a stricter rule for PendingIntent: you must explicitly declare whether it is mutable or immutable.

A PendingIntent is a token that lets another part of Android, or another app, perform an action later on your app's behalf. Because this can affect security, Android now requires developers and libraries to state whether that token can be modified.

The two important flags are:

• PendingIntent.FLAG_IMMUTABLE — the wrapped intent cannot be changed later.
• PendingIntent.FLAG_MUTABLE — the wrapped intent can be modified later if required.

In most cases, FLAG_IMMUTABLE is the safer choice.

The problem in this question is slightly tricky because the crash is not coming from your own code directly. It is happening inside MediaSessionCompat, which internally creates a PendingIntent for media button handling.

Why this happens:

• Your app targets API 31 or above.
• Android enforces explicit mutability flags.
• An older library version may try to work around Android S using preview-only checks such as Build.VERSION.CODENAME.equals("S").
• Once Android 12 became final, that logic became unreliable because production devices report Build.VERSION.SDK_INT >= 31, not preview codename logic in the same way the library expected.

So even though the library source seems to mention Android S support, that specific version may still not be fully compatible for released Android 12 behavior.

Think of a PendingIntent like a sealed or unsealed envelope that you hand to the Android system.

• Immutable means the envelope is sealed. The system can deliver it, but cannot change what is inside.
• Mutable means the envelope is openable. The system or another component may add or modify details before using it.

Android 12 now says: you must label the envelope clearly.

If you do not say whether it is sealed or unsealed, Android rejects it with an exception.

In this case, MediaSessionCompat is creating the envelope for you. If the library forgets to label it properly, your app still crashes even though your own service code looks correct.

When creating a PendingIntent on Android 12+, always include either FLAG_IMMUTABLE or FLAG_MUTABLE.

Basic syntax

val pendingIntent = PendingIntent.getActivity(
    context,
    0,
    intent,
    PendingIntent.FLAG_IMMUTABLE
)

Or, if mutability is required:

val pendingIntent = PendingIntent.getBroadcast(
    context,
    0,
    intent,
    PendingIntent.FLAG_MUTABLE
)

Safer cross-version pattern

If your code must support older Android versions too, combine flags carefully:

val flags = if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
    PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE
} else {
    PendingIntent.FLAG_UPDATE_CURRENT
}

val pendingIntent = PendingIntent.getActivity(
    context,
    0,
    intent,
    flags
)

Example in a notification

val openAppIntent = Intent(this, MainActivity::class.java)
val openAppPendingIntent = PendingIntent.getActivity(
    ,
    ,
    openAppIntent,
    PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE
)

Consider this example:

val intent = Intent(this, MainActivity::class.java)

val pendingIntent = PendingIntent.getActivity(
    this,
    100,
    intent,
    PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE
)

Here is what happens step by step:

1. Intent(this, MainActivity::class.java) creates an intent describing the action: open MainActivity.
2. PendingIntent.getActivity(...) asks Android to create a reusable token for launching that activity later.
3. Request code 100 helps Android identify this pending intent.
4. FLAG_UPDATE_CURRENT tells Android to update the existing matching pending intent if one already exists.
5. FLAG_IMMUTABLE tells Android that the intent contents must not be modified later.
6. On Android 12+, the system accepts this because mutability has been explicitly declared.

Now compare that with broken code:

val pendingIntent = PendingIntent.getActivity(
    this,
    100,
    intent,
    PendingIntent.FLAG_UPDATE_CURRENT
)

On Android 12+:

1. Android sees that a is being created.

PendingIntent mutability matters in many common Android features:

• Notifications

  • Opening an activity when a notification is tapped
  • Triggering action buttons like Reply, Pause, or Dismiss

• Media playback

  • Media session controls
  • Media button events from headphones, car systems, or lock screen controls

• Alarms and scheduled work

  • AlarmManager callbacks
  • Deferred actions triggered by the system

• Broadcast receivers

  • Delivering future intents to a receiver
  • Background event handling

• Foreground services

  • Notification actions tied to service behavior

In media apps specifically, the support library may create internal PendingIntents for transport controls and media button integration. That is why dependency compatibility is so important when upgrading target SDK versions.

In real Android projects, developers usually handle this concept in a few practical ways.

1. Prefer immutable by default

Most app-generated PendingIntents do not need to be changed later.

val flags = PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE

This is the most common pattern for notifications and launch intents.

2. Use mutable only when required

Use FLAG_MUTABLE only for cases where Android or another component must modify the intent.

Examples include:

• inline replies in notifications
• bubbles
• some remote input flows
• framework features that explicitly require mutable intents

3. Centralize flag logic

Many codebases create helper functions so all PendingIntents follow the same rules.

fun defaultPendingIntentFlags(): Int {
    return PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE
}

This avoids repeated mistakes.

4. Update dependencies when platform rules change

If a crash comes from AndroidX or another library, application code may not be enough. Real projects often fix this by:

1. Assuming the crash must be in your own code

In this question, your service code is simple and looks valid:

mediaSession = MediaSessionCompat(this, TAG)

But the real failure happens inside the library when it creates a PendingIntent.

How to avoid it

• Read the stack trace carefully.
• Look at the deepest library call before the exception.
• Check dependency versions.

2. Using no mutability flag on Android 12+

Broken example:

PendingIntent.getBroadcast(this, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT)

Fix

PendingIntent.getBroadcast(
    this,
    0,
    intent,
    PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE
)

3. Using FLAG_MUTABLE everywhere

Some developers fix the crash by always using mutable.

PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_MUTABLE

This may work, but it is not the safest default.

Better approach

PendingIntent rules on Android 12+

• Always specify one of:
  • PendingIntent.FLAG_IMMUTABLE
  • PendingIntent.FLAG_MUTABLE
• Prefer FLAG_IMMUTABLE by default.
• Use FLAG_MUTABLE only when required.

Common patterns

PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE

PendingIntent.FLAG_CANCEL_CURRENT or PendingIntent.FLAG_IMMUTABLE

PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_MUTABLE

Choose the right flag

• Use immutable for:

  • opening an activity
  • standard notification taps
  • most broadcasts
  • fixed service intents

• Use mutable for:

  • inline reply actions
  • bubbles
  • cases where Android must fill in or modify extras later

For MediaSessionCompat crashes

• Check the stack trace.
• If the crash is inside MediaSessionCompat, update the media library.

Why does this error appear only after targeting SDK 31?

Because Android 12 enforces explicit PendingIntent mutability when your app targets API 31 or higher.

Should I use FLAG_IMMUTABLE or FLAG_MUTABLE?

Use FLAG_IMMUTABLE in most cases. Use FLAG_MUTABLE only when the PendingIntent must be modified later.

Can MediaSessionCompat create a PendingIntent internally?

Yes. That is why the crash can happen even if you did not manually create a PendingIntent in your own service code.

Why didn't androidx.media:media:1.4.0 fix it?

Some earlier support logic relied on preview Android S checks and was not sufficient for final Android 12 behavior. A newer compatible version is needed.

How do I know whether the crash comes from my code or a library?

Read the stack trace carefully. If the exception originates inside android.support.v4.media.session.MediaSessionCompat or androidx classes, the library is involved.

Can I work around this by lowering target SDK?

You could temporarily avoid the enforcement, but this is not a proper fix. The correct solution is to update code and dependencies.

• PendingIntent — the central Android concept behind this crash.
• MediaSessionCompat — the class creating media-related session behavior and internal pending intents.
• MediaBrowserServiceCompat — the service base class commonly used with media playback apps.
• Android 12 behavior changes — explains why target SDK upgrades can break existing code.
• Notification actions — another common place where pending intent mutability matters.
• BroadcastReceiver — often receives intents delivered through PendingIntent.getBroadcast().
• Foreground service — media apps often combine media sessions with foreground notifications.
• Gradle dependency resolution — useful for debugging whether the correct AndroidX version is being used.