Android: BackgroundServiceStartNotAllowedException when RNTP emits PlaybackStateChanged / PlaybackProgressUpdated events while app is backgrounded

[jessemezini]

Environment

• RNTP: 5.6.0
• Expo SDK: 54
• React Native: 0.81.5
• React: 19.1.0
• Android targetSdkVersion: 36
• Android versions affected: Android 12+ (reported through Crashlytics)

---

Description

We're seeing recurring crashes in production caused by:

android.app.BackgroundServiceStartNotAllowedException

The exception is thrown while RNTP emits playback-related events from native code.

The crash does not occur during player setup or when explicitly calling play(), pause(), stop() or clear() from our application code.

Instead, it occurs while RNTP internally emits playback events after the application has already been backgrounded.

---

Crash paths

We've observed two different native paths leading to the exact same exception.

Path 1

TrackPlayerModule.onPlaybackStateChanged()
↓
ReactApplicationContextExtKt.emitEvent()
↓
Context.startService()
↓
TrackPlayerTaskService
↓
BackgroundServiceStartNotAllowedException

Path 2

TrackPlayerPlaybackService.onProgressSyncTick()
↓
ReactApplicationContextExtKt.emitEvent()
↓
Context.startService()
↓
TrackPlayerTaskService
↓
BackgroundServiceStartNotAllowedException

The second path suggests the crash can also occur during RNTP's progress synchronization.

---

What we've already investigated

We spent several days investigating this before opening this issue.

Things we've already ruled out:

• component lifecycle
• duplicate player initialization
• explicit calls to TrackPlayer.clear()
• explicit calls to TrackPlayer.stop()
• player setup timing
• JS handling mode (handling: 'js' was removed)

The application now uses:

TrackPlayer.setCommands({
    capabilities: [PlayerCommand.PlayPause],
});

instead of

TrackPlayer.setCommands({
    capabilities: [PlayerCommand.PlayPause],
    handling: "js",
});

The crashes continue to occur after this change.

---

Playback configuration

Player setup:

TrackPlayer.setupPlayer({
    contentType: "speech",
    progressSync: {
        intervalSeconds: 5,
    },
    android: {
        wakeMode: "network",
        taskRemovedBehavior: "stop",
    },
});

We also register:

• PlaybackStateChanged
• PlaybackProgressUpdated
• IsPlayingChanged

to keep an application timer synchronized.

However, according to the stack traces, the crash happens before our application handlers execute, while RNTP is still inside:

ReactApplicationContextExtKt.emitEvent()

---

Production behavior

The issue is difficult to reproduce manually.

Crashlytics shows users experiencing this while the application is already in the background.

Many affected users listen to long sleep music sessions, so the application often remains backgrounded for several hours.

However, one captured crash occurred after only about one minute in the background, so the issue does not appear to depend exclusively on long playback sessions.

We also received at least one user report of playback stopping unexpectedly during a meditation.

Unfortunately we cannot directly correlate that report with one of the Crashlytics sessions.

---

Stack traces

We'll attach four sanitized Crashlytics reports.

Three reports originate from:

TrackPlayerModule.onPlaybackStateChanged()

One originates from:

TrackPlayerPlaybackService.onProgressSyncTick()

Both end with the same:

BackgroundServiceStartNotAllowedException

---

Question

Is this a known issue on Android 12+ / Android 13+ / Android 14+?

Specifically:

• Is ReactApplicationContextExtKt.emitEvent() expected to start TrackPlayerTaskService while the app is already backgrounded?

• Is there a recommended configuration that avoids this?

• Has this already been fixed in a newer version?

• Should applications avoid using PlaybackProgressUpdated together with progressSync on Android?

We're happy to test patches or provide additional information if needed.

Thanks!

crash_1_sanitized.txt
crash_2_sanitized.txt
crash_3_sanitized.txt
crash_4_sanitized.txt

[dcvz]

Following up here @jessemezini 👋 We're working on solutions here. We now understand the issue. We'll likely first make a short term fix, but we're working hard on the "proper" fix.

[dcvz]

Hey @jessemezini, sorry for the delay in the end short term fix wasn't the way to go. Fixed in 5.9.2. The crash came from how we delivered events to JS while the app was backgrounded. Event delivery was rebuilt and should work as expected.

The crash reports were very valuable, I'd appreciate if you can see how the changes affect your deployments. The exception should disappear completely. I will close the issue, but please feel free to reopen if you still see issues.

[jessemezini]

Thanks a lot for the update and for fixing this.

I really appreciate you taking the time to investigate it, and I'm glad the crash reports were useful.

I haven't upgraded to 5.9.2 yet, but I'll do that shortly and keep a close eye on Crashlytics after deployment and report back if I still see anything related.

[louwjlabuschagne]

We hit this exact exception in production — plus a sibling crash from the same code path that I don't see reported anywhere else, so documenting both here for searchability since 5.9.2's event-delivery rebuild addresses the pair.

Environment: @rntp/player 5.8.0, RN 0.86.2 (New Architecture), Expo SDK 57, Android targetSdk 36. Audio app with progressSync: { intervalSeconds: 1 } and a registerBackgroundEventHandler that persists listen position.

Variant 1 — this issue's exception. BackgroundServiceStartNotAllowedException via emitEvent → startService(TrackPlayerTaskService) with the uid just past the Android 12+ grace window (bg:+1m0s420ms in the crash record). Low volume for us (1 user, 28d).

Variant 2 — the foreground sibling (our #1 production crash, 83% of crash volume, 7 users / 10 events in 28d on a staged rollout):

java.lang.IllegalStateException: Tried to start task TrackPlayerServiceBridge while in foreground, but this is not allowed.
	at com.facebook.react.jstasks.HeadlessJsTaskContext.startTask(HeadlessJsTaskContext.kt:77)
	at com.facebook.react.HeadlessJsTaskService.invokeStartTask$lambda$0(HeadlessJsTaskService.kt:83)

Mechanism in 5.8.0: isAppOnForeground() (based on ActivityManager.runningAppProcesses importance, which lags real visibility) routes an event to the task service while the user is foregrounding the app; by the time the posted startTask runnable runs, RN's own lifecycleState says RESUMED, and TrackPlayerTaskService passed allowedInForeground = false — so RN throws. With 1s progress events during background playback, every background→foreground transition mid-playback rolls these dice.

Repro (reliable): start playback, then loop KEYCODE_HOME → 3s → am start → 2s via adb. Crashed with the exact production stack after 26 cycles on a Galaxy A36 (Android 16) running our production build.

On 5.9.2: reading the new EventBroker, both variants look structurally closed — no Service start at all, routing decided on lifecycleState == RESUMED, and HeadlessJsTaskConfig(..., allowedInForeground = true) tolerating resume-during-start. We upgraded today; I'll run the same repro loop against the 5.9.2 build and report back.

[louwjlabuschagne]

Following up as promised: 5.9.2 verified on-device.

Same harness as before (backgrounding/foregrounding every few seconds during active playback with 1s progressSync, on the same Android 16 device):

• 5.8.0: crashed with the foreground IllegalStateException (TrackPlayerServiceBridge) after 26 cycles (~2.5 min).
• 5.9.2: 300 cycles clean (~27 min), playback uninterrupted, no exceptions of either variant in the crash buffer.

The EventBroker rebuild holds up under deliberate abuse of exactly the transition race that used to fire. Thanks for the quick and thorough fix.