MediaNotificationManager retains service after onDestroy is called

[derat]

Leak Canary reports that my service is still retained by MediaNotificationManager after the service's onDestroy method has been called:

┬───
│ GC Root: System class
│
├─ android.app.ActivityThread class
│    Leaking: NO (MessageQueue↓ is not leaking and a class is never leaking)
│    ↓ static ActivityThread.sMainThreadHandler
├─ android.app.ActivityThread$H instance
│    Leaking: NO (MessageQueue↓ is not leaking)
│    ↓ Handler.mQueue
├─ android.os.MessageQueue instance
│    Leaking: NO (MessageQueue#mQuitting is false)
│    HandlerThread: "main"
│    ↓ MessageQueue[6]
│                  ~~~
├─ android.os.Message instance
│    Leaking: UNKNOWN
│    Retaining 15.2 MB in 69260 objects
│    Message.what = 1
│    Message.when = 1391158535 (577265 ms after heap dump)
│    Message.obj = null
│    Message.callback = null
│    Message.target = instance @337816704 of android.os.Handler
│    ↓ Message.target
│              ~~~~~~
├─ android.os.Handler instance
│    Leaking: UNKNOWN
│    Retaining 15.2 MB in 69259 objects
│    ↓ Handler.mCallback
│              ~~~~~~~~~
├─ androidx.media3.session.MediaNotificationManager instance
│    Leaking: UNKNOWN
│    Retaining 15.2 MB in 69258 objects
│    mediaSessionService instance of org.erat.nup.NupService
│    ↓ MediaNotificationManager.mediaSessionService
│                               ~~~~~~~~~~~~~~~~~~~
╰→ org.erat.nup.NupService instance
​     Leaking: YES (ObjectWatcher was watching this because org.erat.nup.
​     NupService received Service#onDestroy() callback and Service not held by
​     ActivityThread)
​     Retaining 1.8 MB in 54083 objects
​     key = 116a380f-a4a8-4ca4-a8d1-8784a085613c
​     watchDurationMillis = 14100
​     retainedDurationMillis = 9092
​     windowContext instance of android.window.WindowContext
​     mApplication instance of org.erat.nup.NupApplication
​     mBase instance of android.app.ContextImpl

My service is derived from MediaLibraryService. I create a MediaLibrarySession in my service's onCreate method:

mediaSession = MediaLibrarySession.Builder(this, core.playerImpl, mediaHelper)
    .setSessionActivity(
         PendingIntent.getActivity(
            this,
            0,
            Intent(this, NupActivity::class.java),
            PendingIntent.FLAG_IMMUTABLE,
        ),
    ).build()

I call the session's release method in onDestroy:

mediaSession.release()

In my activity, I'm explicitly stopping my service in response to a user action:

stopService(Intent(this, NupService::class.java))
finishAndRemoveTask()

Is it expected that MediaNotificationManager will remain active and retain my service in this case?

[marcbaechinger]

stopService(Intent(this, NupService::class.java))
finishAndRemoveTask()

Roughly, the service should either be stopped on the service side by calling stopSelf(), stopping the player and by releasing the session or timeout. There isn't a good way to stop the service from an activivty (aka. controller) side.

Few things come to mind. Can you explain your use case and why you want to stop the service from the activity? What would work is stopping/pausing playback and then calling stopSelf() on the service side. There is no API to initiate such a behavior. You could do a custom command for that but I see that's not a solution.

Can you please add an EventLogger to the player and run through your scenario again, then after having stopped the service in your way, create a bug report and upload it here. If you're unable to share bug reports publicly, please send them to android-media-github@google.com using a subject in the format "Issue #2692". Please also update this issue to indicate you’ve done this.

[derat]

Thanks for the reply!

My use case is wanting a way to quickly stop playback and dismiss both the activity and media notification.

To clarify, I'm not using ExoPlayer -- I have my own SimpleBasePlayer implementation that uses MediaPlayer internally.

I'm using custom commands for a bunch of other things, so it'd likely be straightforward for me to have the activity ask the service to call stopSelf(). Is that expected to produce a different result? https://developer.android.com/reference/kotlin/android/app/Service#stopself says

This is the same as calling android.content.Context#stopService for this particular service.

[marcbaechinger]

Is that expected to produce a different result?
https://developer.android.com/reference/kotlin/android/app/Service#stopself says

This is the same as calling android.content.Context#stopService
for this particular service.

I think a bug report would be a good source of information to answer these questions.
I can try and experiment myself, but I'm not sure then whether I do what you do. So having that bug report would be helpful.

[derat]

Thanks, I've generated a bug report after exiting via my current stopService approach and sent it to android-media-github@google.com with the subject Issue #2692. I had to use a Drive link since the attachment appears to be slightly too large for Google Groups.

No EventLogger since it's my understanding that it's only applicable to (and usable with) ExoPlayer, but please let me know if I'm mistaken on that front.

LeakCanary looks like it reported the same leak as given above again. Here are relevant-seeming entries from my process's logs:

...
08-04 08:07:44.008 17917 17917 D NupActivity: Destroying activity
...
08-04 08:07:44.010 17917 17917 I MediaController: Release 97c84af [AndroidXMedia3/1.8.0] [lynx, Pixel 7a, Google, 36] [media3.common, media3.session, media3.datasource]
...
08-04 08:07:44.022 17917 17917 D NupService: Destroying service
08-04 08:07:44.022 17917 17917 I MediaSessionImpl: Release 983e282 [AndroidXMedia3/1.8.0] [lynx, Pixel 7a, Google, 36] [media3.common, media3.session, media3.datasource]
08-04 08:07:44.025 17917 17917 I MediaController: Release d83f424 [AndroidXMedia3/1.8.0] [lynx, Pixel 7a, Google, 36] [media3.common, media3.session, media3.datasource]
...
08-04 08:07:49.234 17917 17932 W org.erat.nup: Cleared Reference was only reachable from finalizer (only reported once)
08-04 08:07:49.285 17917 17932 I org.erat.nup: Explicit concurrent mark compact GC freed 2271KB AllocSpace bytes, 2(104KB) LOS objects, 57% free, 6111KB/13MB, paused 1.016ms,3.881ms total 215.541ms
08-04 08:07:49.514 17917 17932 I org.erat.nup: hprof: heap dump "/storage/emulated/0/Download/leakcanary-org.erat.nup/2025-08-04_08-07-49_492.hprof" starting...
08-04 08:08:04.296 17917 17932 I org.erat.nup: hprof: heap dump completed (49MB) in 14.782s objects 849302 objects with stack traces 0
08-04 08:08:04.631 17917 17922 I org.erat.nup: WaitForGcToComplete blocked HeapTrim on Hprof for 10.344s
08-04 08:08:41.740 17917 17997 I org.erat.nup: Explicit concurrent mark compact GC freed 35MB AllocSpace bytes, 3(60KB) LOS objects, 40% free, 46MB/78MB, paused 4.800ms,6.874ms total 604.239ms
08-04 08:08:41.740 17917 17922 I org.erat.nup: WaitForGcToComplete blocked Background on Explicit for 313.476ms

It's unclear to me whether the second (?) GC at 08:08:41 freed the service.

I'll probably try to experiment with using a custom command and stopSelf to see if that changes things.

[marcbaechinger]

Ah, yeah, you are not using ExoPlayer, sorry. The reason I asked for \EventLogger\ is that the state of the player is a factor that can make the service not properly being stopped like with stopSelf. The steps required for stopping the service are:

1 - stop/pause playback (aka. take the service off the foreground which is related to whether the player is not playing. This is true for your player as well. The player must not be playing when you attempt to stop the service)
2 - call stopSelf(): this wil make the system start to stop the service which results in onDestroy() being called.
3 - release the session in onDestroy()

If in 1 there is the possibility that there is a controller still bound to the service, then you may want to release the session in 1) to make sure there is no controller bound to the service.

So before you call stopSelf make sure to stop playback and disconnect controllers (or rlease the session to disconnect before calling stopSelf).

Sorry, for the rough edges. We are aware that stopping the service would deserve a better API or at least proper documentation.

[marcbaechinger]

Thanks. I checked the logs. Your app is fine. The logs show that the service is terminated as expected (see at the end if interested). Thanks for your report and the additional information.

Hence, there is a memory leak produced by Media3 because the message of your leak report shouldn't be there in the message queue after the session was released.

MediaNotificationManager is a Handler.Callback that gets delayed messages posted in to keep the service in the foreground for a given grace period of time. MediaNotifcationManager sends a message that is delayed for userEngagegementTImeoutMs like here.

Given your your app has properly released the session when stopping the service, the message from the leakage report shouldn't be there at this point. Whether your app is still alive or not, after releasing the session this handler message must be removed by the library. When the app continues for a long enough duration this message is not detected, if the app goes away soon enough, which is the normal case, we leak the handler referenced from the message queue as reported by canary leak.

We will investigate this some further and provide a fix for this.

// controller (probably in your activity) released that was bound to the service
08-04 08:07:44.010 10305 17917 17917 I MediaController: Release 97c84af [AndroidXMedia3/1.8.0] [lynx, Pixel 7a, Google, 36] [media3.common, media3.session, media3.datasource]

// destroy called. Your app releases the session
08-04 08:07:44.022 10305 17917 17917 D NupService: Destroying service
08-04 08:07:44.022 10305 17917 17917 I MediaSessionImpl: Release 983e282 [AndroidXMedia3/1.8.0] [lynx, Pixel 7a, Google, 36] [media3.common, media3.session, media3.datasource]

// the system sees the platform session go
08-04 08:07:44.023  1000  1478  2660 I MediaSessionStack: removeSession | record: app.package.foo.bar/androidx.media3.session.id./239 (userId=0)
08-04 08:07:44.023  1000  1478  2660 D MediaSessionService: Media button session is changed to null
08-04 08:07:44.024  1000  1478  2660 D MediaSessionService: destroySessionLocked: record=app.package.foo.bar/androidx.media3.session.id./239 (userId=0)

08-04 08:07:44.025 10305 17917 17917 I MediaController: Release d83f424 [AndroidXMedia3/1.8.0] [lynx, Pixel 7a, Google, 36] [media3.common, media3.session, media3.datasource]

// more ssytem compoents see tha app go away
08-04 08:07:44.027  1002  2645  2645 I MediaPlayerList: onMediaKeyEventSessionChanged: packageName=app.package.foo.bar
08-04 08:07:44.027  1002  2645  2645 W MediaPlayerList: app.package.foo.bar is already the active player
08-04 08:07:44.027  1002  2645  2645 W MediaPlayerWrapper: The session was destroyed app.package.foo.bar
08-04 08:07:44.030 10203 15853 15853 I NotificationListener: received notification removed event - app.package.foo.bar#UserHandle{0},category=-1
08-04 08:07:44.037 10221  2479  2479 D NotificationMediaManager: Not dismissing 0|app.package.foo.bar|1001|null|10305 because it was removed by the system
08-04 08:07:44.037  1000  1478  4591 I MediaFocusControl: abandonAudioFocus() from uid/pid 10305/17917 clientId=android.media.AudioManager@564b8a7app.package.foo.bar.Core$$ExternalSyntheticLambda0@44fb154 callingPack=app.package.foo.bar

// media player goes away
08-04 08:07:44.050 10305 17917 17954 D Player$FilePlayer: Closing android.media.MediaPlayer@e13fa8 (5675267779461120.mp3)
08-04 08:07:44.231 10305 17917 17954 V MediaPlayer: resetDrmState:  mDrmInfo=null mDrmProvisioningThread=null mPrepareDrmInProgress=false mActiveDrmScheme=false
08-04 08:07:44.231 10305 17917 17954 V MediaPlayer: cleanDrmObj: mDrmObj=null mDrmSessionId=null
08-04 08:07:44.231 10305 17917 17954 V MediaPlayer: resetDrmState:  mDrmInfo=null mDrmProvisioningThread=null mPrepareDrmInProgress=false mActiveDrmScheme=false
...

[derat]

Great, thanks for digging into this! I'd started experimenting with using a custom command so I could experiment with different orderings of calling stopSelf(), release(), and pausing or stopping playback. I hadn't found anything promising, so I'm glad that you spotted the issue around the stale message. :-)

[marcbaechinger]

I just noticed that you can call MediaSessionService.pauseAllPlayersAndStopSelf() and then you should be good. Calling this method does remove that message from the message queue. However, we need to make sure this happens even when apps do not call this method.