Android expanded notification controls do not emit events because MEDIA_BUTTON intents are not handled

[k-ljung]

Summary

On Android with react-native-audio-api@0.13.3, playback controls behave differently depending on which notification UI is used:

• Compact notification widget controls work.
• Scrubbing works.
• Expanded notification / lock-screen play, pause, next, and previous controls do not emit the expected playbackNotification* events.
• In a high-frequency update path, we also observed a java.util.ConcurrentModificationException from NotificationCompatBuilder while the notification was being updated.

I searched existing issues/PRs for MEDIA_BUTTON, PlaybackNotificationReceiver, expanded notification controls, and ConcurrentModificationException NotificationCompatBuilder, but did not find an existing report for this exact Android path.

Important MRE note

I know the issue template strongly encourages a minimal reproducible example. This report is currently based on a real app reproduction, not a public MRE yet. I am filing now because the code-level cause appears small and concrete. If needed, I can follow up with a minimal public repro project that exercises only PlaybackNotificationManager.show, enableControl, and event listeners.

Environment

• react-native-audio-api: 0.13.3
• React Native: 0.81.5
• Expo SDK: 54
• Android: reproduced on Android device/build from an Expo React Native app
• New Architecture enabled
• react-native-worklets: 0.6.1

Reproduction observed in app

1. Configure and show playback notification metadata.
2. Enable controls:
   • play
   • pause
   • nextTrack
   • previousTrack
   • skipForward
   • skipBackward
   • seekTo
3. Start playback.
4. Swipe down to show the compact notification widget.
5. Press controls from the compact widget.
6. Expand the notification or use lock-screen media controls.
7. Press play/pause/next/previous.

Expected behavior

Expanded notification and lock-screen play/pause/next/previous should emit the same events as the compact notification widget:

• playbackNotificationPlay
• playbackNotificationPause
• playbackNotificationNextTrack
• playbackNotificationPreviousTrack

Actual behavior

Compact widget controls work, but expanded notification / lock-screen play/pause/next/previous controls do not emit the expected events. Scrubbing still works.

Code-level analysis

The compact controls appear to work through MediaSessionCompat.Callback in PlaybackNotification.kt:

override fun onPlay() {
  audioAPIModule.get()?.invokeHandlerWithEventNameAndEventBody(AudioEvent.PLAYBACK_NOTIFICATION_PLAY.ordinal, mapOf())
}

override fun onPause() {
  audioAPIModule.get()?.invokeHandlerWithEventNameAndEventBody(AudioEvent.PLAYBACK_NOTIFICATION_PAUSE.ordinal, mapOf())
}

override fun onSkipToNext() {
  audioAPIModule.get()?.invokeHandlerWithEventNameAndEventBody(AudioEvent.PLAYBACK_NOTIFICATION_NEXT_TRACK.ordinal, mapOf())
}

override fun onSkipToPrevious() {
  audioAPIModule.get()?.invokeHandlerWithEventNameAndEventBody(AudioEvent.PLAYBACK_NOTIFICATION_PREVIOUS_TRACK.ordinal, mapOf())
}

But expanded notification actions are created as pending intents with action PlaybackNotification.MEDIA_BUTTON:

val intent = Intent(MEDIA_BUTTON)
intent.setPackage(context.packageName)
intent.putExtra(Intent.EXTRA_KEY_EVENT, KeyEvent(KeyEvent.ACTION_DOWN, keyCode))

MediaSessionManager.kt registers that action on PlaybackNotificationReceiver:

playbackFilter.addAction(PlaybackNotification.MEDIA_BUTTON)

However, PlaybackNotificationReceiver.kt handles only:

• ACTION_NOTIFICATION_DISMISSED
• ACTION_SKIP_FORWARD
• ACTION_SKIP_BACKWARD

It does not handle PlaybackNotification.MEDIA_BUTTON or decode Intent.EXTRA_KEY_EVENT.

That seems to explain the split behavior: compact MediaSession callbacks work, while expanded PendingIntent-backed media button actions are dropped.

Local patch that fixed the app behavior

This local patch maps MEDIA_BUTTON key events to the same AudioEvent values as the MediaSession callback path:

diff --git a/android/src/main/java/com/swmansion/audioapi/system/notification/PlaybackNotificationReceiver.kt b/android/src/main/java/com/swmansion/audioapi/system/notification/PlaybackNotificationReceiver.kt
--- a/android/src/main/java/com/swmansion/audioapi/system/notification/PlaybackNotificationReceiver.kt
+++ b/android/src/main/java/com/swmansion/audioapi/system/notification/PlaybackNotificationReceiver.kt
@@ -3,6 +3,7 @@ package com.swmansion.audioapi.system.notification
 import android.content.BroadcastReceiver
 import android.content.Context
 import android.content.Intent
+import android.view.KeyEvent
 import com.swmansion.audioapi.AudioAPIModule
 import com.swmansion.audioapi.system.AudioEvent
 
@@ -40,6 +41,43 @@ class PlaybackNotificationReceiver : BroadcastReceiver() {
         val body = HashMap<String, Any>().apply { put("value", 15) }
         audioAPIModule?.invokeHandlerWithEventNameAndEventBody(AudioEvent.PLAYBACK_NOTIFICATION_SKIP_BACKWARD.ordinal, body)
       }
+
+      PlaybackNotification.MEDIA_BUTTON -> {
+        val keyEvent = if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.TIRAMISU) {
+          intent.getParcelableExtra(Intent.EXTRA_KEY_EVENT, KeyEvent::class.java)
+        } else {
+          @Suppress("DEPRECATION")
+          intent.getParcelableExtra(Intent.EXTRA_KEY_EVENT)
+        }
+
+        if (keyEvent?.action != KeyEvent.ACTION_DOWN) return
+
+        when (keyEvent.keyCode) {
+          KeyEvent.KEYCODE_MEDIA_PLAY -> {
+            audioAPIModule?.invokeHandlerWithEventNameAndEventBody(AudioEvent.PLAYBACK_NOTIFICATION_PLAY.ordinal, mapOf())
+          }
+          KeyEvent.KEYCODE_MEDIA_PAUSE -> {
+            audioAPIModule?.invokeHandlerWithEventNameAndEventBody(AudioEvent.PLAYBACK_NOTIFICATION_PAUSE.ordinal, mapOf())
+          }
+          KeyEvent.KEYCODE_MEDIA_STOP -> {
+            audioAPIModule?.invokeHandlerWithEventNameAndEventBody(AudioEvent.PLAYBACK_NOTIFICATION_STOP.ordinal, mapOf())
+          }
+          KeyEvent.KEYCODE_MEDIA_NEXT -> {
+            audioAPIModule?.invokeHandlerWithEventNameAndEventBody(AudioEvent.PLAYBACK_NOTIFICATION_NEXT_TRACK.ordinal, mapOf())
+          }
+          KeyEvent.KEYCODE_MEDIA_PREVIOUS -> {
+            audioAPIModule?.invokeHandlerWithEventNameAndEventBody(AudioEvent.PLAYBACK_NOTIFICATION_PREVIOUS_TRACK.ordinal, mapOf())
+          }
+          KeyEvent.KEYCODE_MEDIA_FAST_FORWARD -> {
+            val body = HashMap<String, Any>().apply { put("value", 15) }
+            audioAPIModule?.invokeHandlerWithEventNameAndEventBody(AudioEvent.PLAYBACK_NOTIFICATION_SKIP_FORWARD.ordinal, body)
+          }
+          KeyEvent.KEYCODE_MEDIA_REWIND -> {
+            val body = HashMap<String, Any>().apply { put("value", 15) }
+            audioAPIModule?.invokeHandlerWithEventNameAndEventBody(AudioEvent.PLAYBACK_NOTIFICATION_SKIP_BACKWARD.ordinal, body)
+          }
+        }
+      }
     }
   }
 }

Related crash observed

Before serializing notification updates in app code, we also saw this Android crash while notification controls/metadata were being updated:

java.util.ConcurrentModificationException
  java.util.ArrayList$Itr.checkForComodification(ArrayList.java:1112)
  java.util.ArrayList$Itr.next(ArrayList.java:1065)
  androidx.core.app.NotificationCompatBuilder.<init>(NotificationCompatBuilder.java:127)
  androidx.core.app.NotificationCompat$Builder.build(NotificationCompat.java:2528)
  com.swmansion.audioapi.system.notification.PlaybackNotification.buildNotification(PlaybackNotification.kt:515)
  com.swmansion.audioapi.system.notification.PlaybackNotification.updateInternal$lambda$1$lambda$0(PlaybackNotification.kt:249)

We mitigated that separately in app code by serializing show, hide, and enableControl calls, so the main upstream issue here is the missing MEDIA_BUTTON handling path.

Cache / rebuild status

This was tested after rebuilding the native Android app. The Expo/Metro cache was also reset during upgrade testing. The local patch requires a native rebuild to take effect.

[mdydek]

i've tried reproducing this error, but both expanded or lockscreen notification still emitted all events and they were reaching JS (tried both emulator and real device). If needed, I can follow up with a minimal public repro project that exercises only PlaybackNotificationManager.show, enableControl, and event listeners. Can you provide it and maybe record small video showing that it indeed does not work?

[mdydek]

which android version are you using?

[k-ljung]

I'm using Android 15 on the device.

I'll see if I get some time this week to create a small project to test it again.

[k-ljung]

Follow-up on the ConcurrentModificationException I mentioned under "Related crash observed".

While debugging a separate Android problem (notification/lock-screen title lagging one track behind, now filed as #1280) I found that the crash stack trace in this issue points into the artwork thread callback, not into the JS-side concurrency I originally assumed:

androidx.core.app.NotificationCompat$Builder.build(NotificationCompat.java:2528)
com.swmansion.audioapi.system.notification.PlaybackNotification.buildNotification(PlaybackNotification.kt:515)
com.swmansion.audioapi.system.notification.PlaybackNotification.updateInternal$lambda$1$lambda$0(PlaybackNotification.kt:249)

updateInternal$lambda$1$lambda$0 is the doubly-nested lambda, i.e. the runOnUiQueueThread block inside the artwork Thread started by updateInternal(). That block calls notificationBuilder?.setLargeIcon(...), mediaSession?.setMetadata(...) and buildNotification() while the main update path may concurrently be running updateNotificationsActions(), which does notificationBuilder?.clearActions() followed by addAction(...). NotificationCompatBuilder's constructor iterates mActions, so a build() from the artwork thread racing an action rebuild produces exactly this ConcurrentModificationException.

Relevant detail: updateInternal() does call artworkThread.interrupt() before starting a new one, but the thread is normally blocked in URL.openConnection() / BitmapFactory.decodeStream(). Blocking socket reads are not interruptible, so the previous track's artwork thread keeps running and can complete after a newer track has already updated the builder and the session. That is also the mechanism behind #1280.

So serializing show / hide / enableControl in app code — which is what I did as a mitigation — cannot fully prevent this, because the racing writer is native and internal to the library. In our app the crash only stopped after adding synchronization around show(), hide() and buildNotification() and discarding artwork results from superseded requests.

This does not change the MEDIA_BUTTON analysis in this issue, but it may be worth treating the artwork callback's thread-safety as part of the same cleanup, since it is a second defect in the same file.

Regarding the reproduction request: still on Android 15. I have not managed to build a minimal repro yet — both this and #1280 are timing-dependent and need remote artwork slow enough to overlap rapid control presses / track changes, which is likely why they did not show up on your emulator and device runs. I will follow up if I get a public repro working.

[k-ljung]

Small correction to my previous comment so nobody is left waiting: I do not have bandwidth to put together a public MRE in the near term, so please don't block on one from me.

@mdydek regarding your reproduction attempt — given that the crash originates in the artwork callback (details in my comment above), the MEDIA_BUTTON path may also be worth reviewing on code inspection rather than repro alone, since PlaybackNotificationReceiver demonstrably registers for PlaybackNotification.MEDIA_BUTTON in MediaSessionManager but has no branch handling that action or decoding Intent.EXTRA_KEY_EVENT. That part is independent of device and timing.

If it turns out the expanded/lock-screen controls work for you on some Android versions, that would suggest the system is routing those presses through the MediaSessionCompat.Callback path instead of the notification's PendingIntents, which would make this version- or OEM-dependent rather than universally broken. Either way the unhandled action seems worth closing off.

Happy to re-test any candidate fix on our Android 15 device and report back.