Status Update
Comments
bo...@gmail.com <bo...@gmail.com> #3
hello?
iv...@mixhalo.com <iv...@mixhalo.com> #4
I have the exact same leak in my MediaBrowserServiceCompat
implementation. Any progress on a solution?
vi...@google.com <vi...@google.com> #5
an...@arctouch.com <an...@arctouch.com> #6
Is the fix going to be released in a new version of androidx.media
library which contains the MediaBrowserServiceCompat
class or is it i the OS level and depend on an OS release?
[Deleted User] <[Deleted User]> #7
It will be available with next Android OS
release.
iv...@mixhalo.com <iv...@mixhalo.com> #8
Can we know if this bug will be fixed in Android 13, specifically?
Because a
ub...@gmail.com <ub...@gmail.com> #9
Issue still present even in Android 14 DP2.
ub...@gmail.com <ub...@gmail.com> #10
ub...@gmail.com <ub...@gmail.com> #11
Just want to summarize some hopefully helpful information for affected app devs:
According to a Github comment from a Googler, this specific issue here should be fixed on API 33, but not earlier versions :
MediaBrowserServiceCompat still leaks for me, because of this other issue, which was just reopened:
There is an effort underway to get Media3's MediaSessionService to stop leaking:
Description
Leak Canary detects a memory leak in the implementation of MediaBrowserService within our MusicService just by launching, starting a playback and quitting the app.
When we look at heap dumps, Leak Canary discovers a leak where a MediaBrowserService stays in memory when you open and exit the app. The following is the Leak Canary report:
┬───
│ GC Root: Global variable in native code
│
├─ android.service.media.MediaBrowserService$ServiceBinder instance
│ Leaking: UNKNOWN
│ Retaining 266.7 kB in 824 objects
│ this$0 instance of androidx.media.
│ MediaBrowserServiceCompat$MediaBrowserServiceImplApi26$MediaBrowserServiceA
│ pi26
│ ↓ MediaBrowserService$ServiceBinder.this$0
│ ~~~~~~
├─ androidx.media.
│ MediaBrowserServiceCompat$MediaBrowserServiceImplApi26$MediaBrowserServiceApi
│ 26 instance
│ Leaking: YES (Service not held by ActivityThread)
│ Retaining 266.2 kB in 823 objects
│ mBase instance of com.audiomack.playback.MusicService
│ ↓ ContextWrapper.mBase
╰→ com.audiomack.playback.MusicService instance
Leaking: YES (ObjectWatcher was watching this because com.audiomack.
playback.MusicService received Service#onDestroy() callback and Service
not held by ActivityThread)
Retaining 264.9 kB in 811 objects
key = efafad84-39d3-43fd-b6a8-d2c75c00b36b
watchDurationMillis = 4948
retainedDurationMillis = -84
mApplication instance of com.audiomack.MainApplication
mBase instance of android.app.ContextImpl
METADATA
Build.VERSION.SDK_INT: 30
Build.MANUFACTURER: Google
LeakCanary version: 2.7
App process name: com.audiomack
Count of retained yet cleared: 18 KeyedWeakReference instances
Stats: LruCache[maxSize=3000,hits=11503,misses=247414,hitRate=4%]
RandomAccess[bytes=19500730,reads=247414,travel=236375246960,range=59839840,size
=69944156]
Heap dump reason: 32 retained objects, app is not visible
Analysis duration: 18391 ms