IssueTracker

Can you please confirm whether this is still reproducible on API 33?

And if you happen to have access, also on the Developer Preview of API 34?

Final thing, is this a dup of https://issuetracker.google.com/220795151?

Thanks, I believe it's a dup at this point.

The other issue was marked as fixed a year ago, but is still as reproducible as ever, I had just tested it on API 33 and UpsideDownCake DP2.

I suppose I cannot say for sure that the two issues have the same root cause, there may be more than one cause for MediaBrowserService(Compat) leaks.

I just tested this issue here once more on my production app, on API 33 (emulator), and got a leak trace (with current LeakCanary) that closely resembles the original one I posted years ago. I let the app sit idle for another half hour, occasionally forcing a garbage collection via Android Studio Profiler, but my destroyed MediaBrowserServiceCompat (CW) instance just would not release. (I validated non-release by logging from finalize() method, which looks very reliable.)

====================================
HEAP ANALYSIS RESULT
====================================
1 APPLICATION LEAKS

References underlined with "~~~" are likely causes.
Learn more at https://squ.re/leaks.

Signature: 881c4404fc048402f456764f134ed07390863849
┬───
│ GC Root: Global variable in native code
│
├─ android.os.Handler$MessengerImpl instance
│    Leaking: UNKNOWN
│    ↓ Handler$MessengerImpl.this$0
│                            ~~~~~~
├─ androidx.media.MediaBrowserServiceCompat$ServiceHandler instance
│    Leaking: UNKNOWN
│    this$0 instance of com.bubenheimer.rucksack.d.CW
│    ↓ MediaBrowserServiceCompat$ServiceHandler.this$0
│                                               ~~~~~~
╰→ com.bubenheimer.rucksack.d.CW instance
​     Leaking: YES (ObjectWatcher was watching this because com.bubenheimer.rucksack.d.CW received Service#onDestroy()
​     callback and Service not held by ActivityThread)
​     key = 0cda35fa-fa79-4035-89ca-6ab496bd1ddc
​     watchDurationMillis = 5400
​     retainedDurationMillis = 392
​     mApplication instance of com.bubenheimer.rucksack.d.D
​     mBase instance of android.app.ContextImpl
====================================
0 LIBRARY LEAKS

A Library Leak is a leak caused by a known bug in 3rd party code that you do not have control over.
See https://square.github.io/leakcanary/fundamentals-how-leakcanary-works/#4-categorizing-leaks
====================================
0 UNREACHABLE OBJECTS

An unreachable object is still in memory but LeakCanary could not find a strong reference path
from GC roots.
====================================
METADATA

Please include this in bug reports and Stack Overflow questions.

Build.VERSION.SDK_INT: 33
Build.MANUFACTURER: Google
LeakCanary version: 2.10
App process name: com.bubenheimer.rucksack
Class count: 28324
Instance count: 179717
Primitive array count: 132390
Object array count: 25025
Thread count: 39
Heap total bytes: 27055417
Bitmap count: 0
Bitmap total bytes: 0
Large bitmap count: 0
Large bitmap total bytes: 0
Db 1: open /data/user/0/com.bubenheimer.rucksack/databases/com.google.android.datatransport.events
Db 2: open /data/user/0/com.bubenheimer.rucksack/databases/rucksack-5031356898991293088.db
Stats: LruCache[maxSize=3000,hits=32348,misses=41728,hitRate=43%]
RandomAccess[bytes=1991236,reads=41728,travel=35597905162,range=32212305,size=40115227]
Heap dump reason: 1 retained objects, app is visible
Analysis duration: 16991 ms
Heap dump file path: /storage/emulated/0/Download/leakcanary-com.bubenheimer.rucksack/2023-04-25_11-53-35_598.hprof
Heap dump timestamp: 1682438042701
Heap dump duration: 4546 ms
====================================

I ended up letting the app sit idle for an hour, but the service still would not finalize.

I also tried this, but still no finalization:

adb shell am send-trim-memory com.bubenheimer.rucksack:appexternal RUNNING_CRITICAL

I've dug into this further, and identified a leak in AndroidX code that I was using (https://issuetracker.google.com/issues/279625765).

Eliminating this leak lets the MediaBrowserService(Compat) call its finalizer eventually. I assume that the leak-related fixes in API 33 are also essential for reaching this stage.

However, there is still some unidentified holdup between onDestroy() and finalize() in my production app triggering various LeakCanary traces, before finalization after about 30 seconds. (LeakCanary triggers garbage collections, but those do not force finalization in this case.)

I assume the holdup is related to more general problems with service/binder/messenger cleanup. It's an issue, because it makes it very difficult to spot more real problems.

Can anything be done to eliminate these delays?

I am attaching the various leak traces I got from excluding each, one at a time (this is how I eventually found the AndroidX leak).

I think the issue can be closed, I am no longer able to reproduce the delayed finalization issue, and I am hoping to switch to media3 MediaSessionService anyway. I have not tried the minimal repro again, though. Ultimately I think the API 33 fixes took care of what was broken here, in addition to avoiding the referenced AndroidX leak.

Thank you for your effort to reopen this.

PY Ricau, the guy behind LeakCanary, suggested that there is more to this, and that there are several actual leaks here. I will update this issue with more info as soon as I find some time, I'm in a bit of a crunch right now.

The 3 LeakCanary leak reports that I attached above point at 2 distinct leaks that are still real, according to PY's analysis from the Github issue here: https://github.com/square/leakcanary/issues/2502#issuecomment-1550455263

Can these leaks be addressed, please?

MediaBrowserServiceCompat$ServiceHandler is an inner class of MediaBrowserServiceCompat (super class of CW) and it's there so that your service can respond to IPC callbacks. It extends Handler and is passed to a Messenger instance created by MediaBrowserServiceCompat in onCreate(), and that Messenger essentially pulls a Binder out of the Handler and passes that binder back to anything calling your service. In other words, every time something binds to your service, the thing that binds to your service is getting an indirect reference to the ServiceHandler which allows it to post messages to that handler which the service will eventually process. However, for this to work, the native framework code keeps a strong native reference locally to the binder until the calling service finalizes the ownership of the binder on its side.

This is actually a common leak pattern in the Android framework: binders are held until the other side runs garbage collection and finalizes the binder on its end, no matter what we're doing with service lifecycle (that's because binders are used beyond services, the only way to be certain the other side won't call is when it doesn't have that pointer). The proper way to handler this is for the service code to finish its handler in onDestroy, or set the reference from the handler to the service to null in onDestroy.

The first and second leak traces are identical, the problem is that MediaBrowserServiceCompat$ServiceHandler has several direct and indirect references to the service.

The last leak is the exact same issue elsewhere, ExtraSession is a stub that won't be GCed until the other side has run its own GC https://github.com/aosp-mirror/platform_frameworks_support/blob/a9ac247af2afd4115c3eb6d16c05bc92737d6305/media/src/main/java/android/support/v4/media/session/MediaSessionCompat.java#L3413

So these 2 leaks are binder related leaks, and the leaks stay in place until a GC runs in the calling process, and you have no control over that. They really should be fixed.

I've not been able to reproduce the leak on a device running Android 14 (UDC / API 34).

For unimportant reasons I had to build my own toy app from scratch (using https://github.com/bubenheimer/mediabrowserservicecompatleak as a base). I will now try said app on older Android versions and, if unable to repro, I'll share the app back with you for input on what step I might be missing.

In conclusion, I was able to reproduce on S (Android 12), but unable to reproduce the issue on T (Android 13) or U (Android 14). I'm attaching the project I used for testing in case you find anything wrong.

Can you use that project to reproduce the issue? If yes, we need to figure out what we are doing differently. Also please kindly include a bugreport (running adb bugreport shortly after the leak is detected) if you are able to repro.

Please assign back to me once you've replied (if you are not able to, ignore).

I've beefed up your example to make it repro the leaks that I attached in #12. I'll attach the updated example. The relevant changes were:

1. Run service & receiver in separate process from Activity.
2. Customize LeakCanary to support multiple processes.
3. Add some additional media-related code to trigger a leak.

Even when not running the service in a separate process there is a leak in the Activity. I'll attach that one, too. May be a similar root cause. I have not investigated this one.

I am attaching the bugreport, too. I took it right after LeakCanary GC'ed and detected a leak. (About 5 seconds after onDestroy().) But it looks easy to reproduce now.

(I did the repro on API 33)

Also, I don't think non-Googlers are able to reassign an issue, so please take it from here.

Thanks. Will provide an update in the next few days.

Correct me if I'm wrong but the only issue we are aware that still exists is in MediaBrowserServiceCompat, right? (not in the platform MediaBrowserService)

I've sent https://android-review.googlesource.com/c/platform/frameworks/support/+/2611832 for review. Feel free to leave any comments there, or here if you don't have access to make comments in the patch.

Once merged, you should just need to update your androidx.media dependency to pick up the fix.

Thanks for the fix.

I'd think that MediaSessionCompat needs a similar fix, based on the leak traces (MediaBrowserServiceCompatLeak4.txt & MediaBrowserActivityLeak.txt) and PY's comments. You can repro MediaBrowserActivityLeak.txt by running the service in the same process as the Activity.

I'll ping PY about possibly chiming in on the code review.

The change has now been merged. I'll now look into the media session compat issue, which seems to persist.

Sorry for the late review. Not sure if you get notifications there, I left a comment: https://android-review.googlesource.com/c/platform/frameworks/support/+/2611832

TL;DR is that using weak refs isn't ideal, you could stick to a strong ref set to null from Service.onDestroy()

Ack. Will implement the proposed fix.

Есть ли утечка информации?

Есть ли утечка информации?

According to translate: Is there any information leak?

No. This is a resources leak, no security issues here.

Another fix for MediaSessionCompat...ExtraSession here: https://android-review.googlesource.com/c/platform/frameworks/support/+/2646722

Only one pending fix after this change is MediaSessionCompat...MediaSessionStub, after which I plan to mark this as fixed. Still, people should migrate to media3, but at least you can upgrade your MediaSessionCompat dep to get a quick fix of the leaks. Feel free to leave any comments here or in the patch.

https://android-review.googlesource.com/c/platform/frameworks/support/+/2646824 contains the last change. The leak fixes will be available in the next release of androidx media.

If there are more leaks to fix in androidx, please kindly file a fresh issue.

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.media:media:1.7.0-beta01

Hi im wondering if the leak happening in this issue on media3's issue tracker

https://github.com/androidx/media/issues/1059#issuecomment-2031345189

is related to this.

By taking UAMP and having the MusicServiceConnection be a Dagger @Singleton, the MusicService is leaked with a very similar stack trace that is exposed here, which contains only stacktraces from androidx.media (until the MusicService, that is):

                                                                  ====================================
                                                                  HEAP ANALYSIS RESULT
                                                                  ====================================
                                                                  1 APPLICATION LEAKS
                                                                  
                                                                  References underlined with "~~~" are likely causes.
                                                                  Learn more at https://squ.re/leaks.
                                                                  
                                                                  43381 bytes retained by leaking objects
                                                                  Signature: 80f093d135adc2b278b02ca2f66fbd46aaa36bea
                                                                  ┬───
                                                                  │ GC Root: Global variable in native code
                                                                  │
                                                                  ├─ android.support.v4.media.session.MediaSessionCompat$MediaSessionImplApi21$ExtraSession instance
                                                                  │    Leaking: UNKNOWN
                                                                  │    Retaining 6,7 MB in 1826 objects
                                                                  │    ↓ MediaSessionCompat$MediaSessionImplApi21$ExtraSession.this$0
                                                                  │                                                            ~~~~~~
                                                                  ├─ android.support.v4.media.session.MediaSessionCompat$MediaSessionImplApi29 instance
                                                                  │    Leaking: UNKNOWN
                                                                  │    Retaining 6,7 MB in 1825 objects
                                                                  │    ↓ MediaSessionCompat$MediaSessionImplApi21.mSessionFwk
                                                                  │                                               ~~~~~~~~~~~
                                                                  ├─ android.media.session.MediaSession instance
                                                                  │    Leaking: UNKNOWN
                                                                  │    Retaining 1,8 kB in 12 objects
                                                                  │    mContext instance of com.example.android.uamp.media.MusicService
                                                                  │    ↓ MediaSession.mContext
                                                                  │                   ~~~~~~~~
                                                                  ╰→ com.example.android.uamp.media.MusicService instance
                                                                  ​     Leaking: YES (ObjectWatcher was watching this because com.example.android.uamp.media.MusicService received
                                                                  ​     Service#onDestroy() callback and Service not held by ActivityThread)
                                                                  ​     Retaining 43,4 kB in 896 objects
                                                                  ​     key = 11c50fab-5b0c-4267-8c51-ad235a51d861
                                                                  ​     watchDurationMillis = 5391
                                                                  ​     retainedDurationMillis = 390
                                                                  ​     mApplication instance of com.example.android.uamp.UampApplication
                                                                  ​     mBase instance of android.app.ContextImpl
                                                                  ====================================

`

I really dont see how using @Singleton is any different from the default:

companion object {
    // For Singleton instantiation.
    @Volatile
    private var instance: MusicServiceConnection? = null

    fun getInstance(context: Context, serviceComponent: ComponentName) =
        instance ?: synchronized(this) {
            instance ?: MusicServiceConnection(context, serviceComponent)
                .also { instance = it }
        }
}

The issue can be reproduced on this branch of my fork of UAMP:

https://github.com/kelmer44/uamp/tree/dagger-nocast

Which uses Dagger Hilt and removes Cast for simplification.

To reproduce:

1. Open UAMP
2. Play something
3. Swipe the app away in the task manager
4. Music Service is leaked.

From this point restarting UAMP also reveals the issue because nothing is loaded as there will be two MusicService instances.

Also note that the example uses media 1.7.0 so fixes above should be included already.

@ke...@gmail.com might be an issue with MediaSessionCompat, but we'll need a fresh ticket to look into this.

Should I create that one then?

Io