MediaLibraryService enters tight create/destroy loop when Android Auto binds while no playback is ongoing

[JaCobbMedia]

Version

Media3 1.7.1 (same as 1.6.1)

More version details

This started happening recently 2-3 weeks ago and was only noticed because some of our users were rate limited due to excessive api calls which are being done when service is created to generate a queue from last listening session.

Devices that reproduce the issue

• Tested on Samsung Galaxy Z Flip5 (Android 16) and Pixel 5 (Android 14)
• Android Auto connected via Desktop Head Unit (DHU)
• Also reproducible with a simple instrumentation test using bindService/unbindService

Devices that do not reproduce the issue

No response

Reproducible in the demo app?

Not tested

Reproduction steps

When Android Auto connects to a phone, it discovers media apps by binding to their MediaLibraryService using the legacy android.media.browse.MediaBrowserService action. If no playback is ongoing, the following loop occurs at ~30-35ms per cycle:

onCreate → onBind → onGetSession → onConnect → onPostConnect → onUnbind → onDestroy → (repeat)

No onStartCommand is ever called — the service is started purely by binding (BIND_AUTO_CREATE). When the external client unbinds, the service has zero remaining clients and isPlaybackOngoing is false, so Android destroys it. The external client (Android Auto) detects the service disappeared and rebinds immediately, restarting the cycle.

This loop runs indefinitely at ~28 cycles/second. Each cycle allocates a new ExoPlayer, MediaSession, and runs the full onCreate initialization. In production, this leads to:

• Resource exhaustion: leaked BroadcastReceivers/ContentObservers crash the app with "too many broadcast receivers registered"
• Backend overload: any network calls triggered during onCreate/initializeBoundServices fire every ~35ms, overwhelming APIs with HTTP 429 responses

Minimal reproduction (no car needed)

The following instrumentation test simulates exactly what Android Auto does — bind via the legacy action, then unbind:

@HiltAndroidTest // or however your service DI is set up
@RunWith(AndroidJUnit4::class)
class MediaServiceBindLoopTest {

    @get:Rule
    var hiltRule = HiltAndroidRule(this)

    @Before
    fun setup() { hiltRule.inject() }

    @Test
    fun reproduceBindUnbindLoop() {
        val context = InstrumentationRegistry.getInstrumentation().targetContext
        val bindIntent = Intent("android.media.browse.MediaBrowserService").apply {
            component = ComponentName(context, YourMediaLibraryService::class.java)
        }

        for (i in 1..300) {
            val connection = object : ServiceConnection {
                override fun onServiceConnected(name: ComponentName?, service: IBinder?) {}
                override fun onServiceDisconnected(name: ComponentName?) {}
            }

            if (context.bindService(bindIntent, connection, Context.BIND_AUTO_CREATE)) {
                Thread.sleep(40) // Simulates AA's quick probe timing
                context.unbindService(connection)
            }
            Thread.sleep(10)
        }
    }
}

Sadly I couldn't reproduce this loop with Desktop Head unit or physical AA device

Logs from production crash (sanitized)

From a Crashlytics session showing the loop. All timestamps are within the same second — 28 full cycles captured in the ring buffer:

13:33:27  MEDIA_SERVICE | onCreate
13:33:27  MEDIA_SERVICE | onBind | intent = Intent { act=android.media.browse.MediaBrowserService }
13:33:27  MEDIA_SERVICE | onGetSession | package = android.media.session.MediaController, uid = -1
13:33:27  MEDIA_SERVICE | onConnect | sessionPlayer = ForwardingPlayer@49f1214, controller = ControllerInfo {pkg=com.example.app, uid=10411}
13:33:27  MEDIA_SERVICE | onPostConnect
13:33:27  MEDIA_SERVICE | onUnbind | intent = Intent { act=android.media.browse.MediaBrowserService }
13:33:27  MEDIA_SERVICE | onDestroy
13:33:27  PlayerQueueController | unbind player: ForwardingPlayer@49f1214
13:33:27  -- cycle repeats immediately --
13:33:27  MEDIA_SERVICE | onCreate
13:33:27  MEDIA_SERVICE | onBind | intent = Intent { act=android.media.browse.MediaBrowserService }
13:33:27  MEDIA_SERVICE | onGetSession | package = android.media.session.MediaController, uid = -1
13:33:27  MEDIA_SERVICE | onConnect | sessionPlayer = ForwardingPlayer@8081986, controller = ControllerInfo {pkg=com.example.app, uid=10411}
13:33:27  MEDIA_SERVICE | onPostConnect
13:33:27  MEDIA_SERVICE | onUnbind | intent = Intent { act=android.media.browse.MediaBrowserService }
13:33:27  MEDIA_SERVICE | onDestroy
13:33:27  PlayerQueueController | unbind player: ForwardingPlayer@8081986
13:33:27  -- cycle repeats immediately --
13:33:27  MEDIA_SERVICE | onCreate
13:33:27  MEDIA_SERVICE | onBind | intent = Intent { act=android.media.browse.MediaBrowserService }
13:33:27  MEDIA_SERVICE | onGetSession | package = android.media.session.MediaController, uid = -1
13:33:27  MEDIA_SERVICE | onConnect | sessionPlayer = ForwardingPlayer@a52d2e6, controller = ControllerInfo {pkg=com.example.app, uid=10411}
13:33:27  MEDIA_SERVICE | onPostConnect
13:33:27  MEDIA_SERVICE | onUnbind | intent = Intent { act=android.media.browse.MediaBrowserService }
13:33:27  MEDIA_SERVICE | onDestroy
13:33:27  PlayerQueueController | unbind player: ForwardingPlayer@a52d2e6

Key observations:

• No onStartCommand in any cycle — this is a bind-only start
• onGetSession uid = -1 — the platform probe, not a real client
• onConnect controller is the app's own compat controller (created internally by Media3 when a legacy MediaBrowserService bind arrives) — not an external MediaController
• New player instance every cycle (different object hashes: @49f1214, @8081986, @a52d2e6)
• All within the same second — ~35ms per full cycle

Expected result

When an external client binds and quickly unbinds while no playback is ongoing, the service should not enter a tight create/destroy loop

Actual result

Service ends in tight create/destroy loop when connecting with AA which leads to crash due to too many broadcast receivers

Fatal Exception: java.lang.IllegalStateException: Too many receivers, total of 1000, registered for pid: 3226, callerPackage: com.example.app
Top 10 actions:
  android.media.AUDIO_BECOMING_NOISY: 990 receivers

Media

Not applicable

Bug Report

• You will email the zip file produced by adb bugreport to android-media-github@google.com after filing this issue.

[JaCobbMedia]

Not sure if helpful but managed to reproduce kinda similar scenario with DHU by removing COMMAND_CODE_LIBRARY_GET_LIBRARY_ROOT in onConnect. The only difference is that that this way AA retried connection 6 times with increased delay between each attempt but then fully stopped retrying. So not sure if this is the same case.

Let me know if you need more details for this issue

[JaCobbMedia]

Small update. We managed to solve out some memory leaks (probably by properly releasing player instances from session) which completely got rid of java.lang.IllegalStateException: Too many receivers crash but sadly loop is still present. We already added preventions to not reach rate-limiting, but original issue is still there.

From latest logs I see that COMMAND_CODE_LIBRARY_GET_LIBRARY_ROOT is available for these users, so my previous comment is probably invalid. Also I see that mostly all of the onConnect calls happen from notificationController

MEDIA3_SERVICE onConnect | pkg=com.example.app, uid=10308,
isLibrarySession=true, isNotificationController=true, isAutoCompanion=false, isAutomotiveController=false,
sessionCommands=[0, 50000, 50001, 50002, 0, 50003, 50004, 50005, 50006, 0, 40010]
playerCommands=Bundle[{0=[1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35]}]

[JaCobbMedia]

With various prevention layers and improvements to our MediaService implementation we managed to at least control the issue but it's still out there and it's appearing in new forms. New crash appeared with identical logs - same tight connect / disconnect loop to our MediaService, just new spot now is throwing the exception.

We're hitting a fatal crash on Android 16 (Samsung Galaxy S24 FE so far) where MediaLibrarySession.Builder(...).build() raises SecurityException: Caller uid <X> cannot set freezer state and aborts service creation.

Media3: 1.7.1
OS: Android 16, Samsung One UI
Surface: background process, custom MediaNotification.Provider

Stack (relevant frames):

java.lang.SecurityException: Caller uid 10397 cannot set freezer state
  at android.app.IActivityManager$Stub$Proxy.enableAppFreezer (IActivityManager.java:10598)
  at android.app.IActivityManager$Stub$Proxy.getIntentSenderWithFeature (IActivityManager.java:7335)
  at android.app.PendingIntent.getBroadcastAsUser (PendingIntent.java:782)
  at android.app.PendingIntent.getBroadcast (PendingIntent.java:765)
  at androidx.media3.session.MediaSessionLegacyStub.<init> (MediaSessionLegacyStub.java:193)
  at androidx.media3.session.MediaSessionImpl.<init> (MediaSessionImpl.java:225)
  at androidx.media3.session.MediaLibrarySessionImpl.<init>
  at androidx.media3.session.MediaLibraryService$MediaLibrarySession.createImpl (MediaLibraryService.java:758)

Android 16 appears to have tightened the ACL on ActivityManagerService.enableAppFreezer. Whatever the legacy stub's PendingIntent.getBroadcast() is triggering on the binder transaction now requires a privileged caller, and a non-privileged app UID gets the SecurityException back from the system server.

Context that makes it fire: breadcrumbs show ~7 full MediaService onCreate → onConnect → onBind → onUnbind → onDestroy cycles in ~900 ms (driven by an in-process MediaController flagged isNotificationController=true repeatedly reconnecting). Each cycle rebuilds the session and re-runs the legacy stub constructor; one of them eventually loses the ACL race.

Would love to get some help on this @marcbaechinger because I'm no longer sure what else to do to prevent such cases. I'm not sure if this issue is due to our incorrect media3 integration or there are some issues on OS / media3 level. Happy to share anonymised implementation of our MediaService if that would help.