Leak canary has reported a leak in our app with the following stack trace:
06-20 18:40:32.018916 13804 30781 D LeakCanary: HeapAnalysisSuccess(heapDumpFile=/data/user/0/<>./files/leakcanary/2020-06-20_18-11-16_713.hprof, createdAtTimeMillis=1592703632012, analysisDurationMillis=130036, applicationLeaks=[], libraryLeaks=[LibraryLeak(className=<>.MediaControlActivity, leakTrace=
06-20 18:40:32.018916 13804 30781 D LeakCanary: ┬
06-20 18:40:32.018916 13804 30781 D LeakCanary: ├─ android.os.MessageQueue
06-20 18:40:32.018916 13804 30781 D LeakCanary: │ Leaking: NO (MessageQueue#mQuitting is false)
06-20 18:40:32.018916 13804 30781 D LeakCanary: │ GC Root: Input or output parameters in native code
06-20 18:40:32.018916 13804 30781 D LeakCanary: │ ↓ MessageQueue.mMessages
06-20 18:40:32.018916 13804 30781 D LeakCanary: │ ~~~~~~~~~
06-20 18:40:32.018916 13804 30781 D LeakCanary: ├─ android.os.Message
06-20 18:40:32.018916 13804 30781 D LeakCanary: │ Leaking: UNKNOWN
06-20 18:40:32.018916 13804 30781 D LeakCanary: │ ↓ Message.next
06-20 18:40:32.018916 13804 30781 D LeakCanary: │ ~~~~
06-20 18:40:32.018916 13804 30781 D LeakCanary: ├─ android.os.Message
06-20 18:40:32.018916 13804 30781 D LeakCanary: │ Leaking: UNKNOWN
06-20 18:40:32.018916 13804 30781 D LeakCanary: │ ↓ Message.callback
06-20 18:40:32.018916 13804 30781 D LeakCanary: │ ~~~~~~~~
06-20 18:40:32.018916 13804 30781 D LeakCanary: ├─ android.view.ViewRootImpl$1
06-20 18:40:32.018916 13804 30781 D LeakCanary: │ Leaking: UNKNOWN
06-20 18:40:32.018916 13804 30781 D LeakCanary: │ Anonymous class implementing java.lang.Runnable
06-20 18:40:32.018916 13804 30781 D LeakCanary: │ ↓ ViewRootImpl$1.this$0
06-20 18:40:32.018916 13804 30781 D LeakCanary: │ ~~~~~~
06-20 18:40:32.018916 13804 30781 D LeakCanary: ├─ android.view.ViewRootImpl
06-20 18:40:32.018916 13804 30781 D LeakCanary: │ Leaking: YES (ViewRootImpl#mView is null)
06-20 18:40:32.018916 13804 30781 D LeakCanary: │ ↓ ViewRootImpl.mActivityConfigCallback
06-20 18:40:32.018916 13804 30781 D LeakCanary: ├─ android.app.-$$Lambda$ActivityThread$ActivityClientRecord$HOrG1qglSjSUHSjKBn2rXtX0gGg
06-20 18:40:32.018916 13804 30781 D LeakCanary: │ Leaking: YES (ViewRootImpl↑ is leaking)
06-20 18:40:32.018916 13804 30781 D LeakCanary: │ ↓ -$$Lambda$ActivityThread$ActivityClientRecord$HOrG1qglSjSUHSjKBn2rXtX0gGg.f$0
06-20 18:40:32.018916 13804 30781 D LeakCanary: ├─ android.app.ActivityThread$ActivityClientRecord
06-20 18:40:32.018916 13804 30781 D LeakCanary: │ Leaking: YES (-$$Lambda$ActivityThread$ActivityClientRecord$HOrG1qglSjSUHSjKBn2rXtX0gGg↑ is leaking)
06-20 18:40:32.018916 13804 30781 D LeakCanary: │ ↓ ActivityThread$ActivityClientRecord.activity
06-20 18:40:32.018916 13804 30781 D LeakCanary: ╰→ <>.MediaControlActivity
06-20 18:40:32.018916 13804 30781 D LeakCanary: Leaking: YES (ActivityThread$ActivityClientRecord↑ is leaking and Activity#mDestroyed is true and ObjectWatcher was watching this)
06-20 18:40:32.018916 13804 30781 D LeakCanary: key = c398c4b4-d254-4d0f-aaf7-c2d22687d27a
06-20 18:40:32.018916 13804 30781 D LeakCanary: watchDurationMillis = 100672
06-20 18:40:32.018916 13804 30781 D LeakCanary: retainedDurationMillis = 95672
06-20 18:40:32.018916 13804 30781 D LeakCanary: , retainedHeapByteSize=179995, pattern=instance field android.os.Message#next, description=A thread waiting on a blocking queue will leak the last dequeued object as a stack local reference. So when a HandlerThread becomes idle, it keeps a local reference to the last message it received. That message then gets recycled and can be used again. As long as all messages are recycled after being used, this won't be a problem, because these references are cleared when being recycled. However, dialogs create template Message instances to be copied when a message needs to be sent. These Message templates holds references to the dialog listeners, which most likely leads to holding a reference onto the activity in some way. Dialogs never recycle their template Message, assuming these Message instances will get GCed when the dialog is GCed. The combination of these two things creates a high potential for memory leaks as soon as you use dialogs. These memory leaks might be temporary, but some handler threads sleep for a long time. To fix this, you could post empty messages to the idle handler threads from time to time. This won't be easy because you cannot access all handler threads, but a library that is widely used should consider doing this for its own handler threads. This leaks has been shown to happen in both Dalvik and ART.)])
I am not able to exact cause for this.
One possibility from the stack trace seems that one of the views has a runnable scheduled to run and the view eventually holds the reference to the activity. But I don't see any runnable being posted to a view. Specifically, I don't really understand the last 4 lines of the leak trace.
This was a bug in the framework code.