Memory leak detected

[YuriyVelichkoPI]

Description

From the slack :

Hi, team. we just received a memory leak trace from "LeakCanary" in our Android app, which looks related to prebid Mobile SDK Android & appsflyer:

R.id.web_view_banner is used in PrebidWebViewBanner class:

https://github.com/prebid/prebid-mobile-android/blob/79985c5b49bc4490ea3b17aba2ba1[…]/prebid/mobile/rendering/views/webview/PrebidWebViewBanner.java
┬───
│ 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[1]
│ ~~~
├─ android.os.Message instance
│ Leaking: UNKNOWN
│ Retaining 224.9 kB in 919 objects
│ Message.what = 0
│ Message.when = 7913094 (20 ms after heap dump)
│ Message.obj = null
│ Message.callback = instance @341272040 of com.appsflyer.internal.f
│ Message.target = instance @341272056 of android.os.Handler
│ ↓ Message.callback
│ ~~~~~~~~
├─ com.appsflyer.internal.f instance
│ Leaking: UNKNOWN
│ Retaining 224.8 kB in 917 objects
│ ↓ f.c
│ ~
├─ p30.e instance
│ Leaking: UNKNOWN
│ Retaining 224.8 kB in 916 objects
│ ↓ e.g
│ ~
├─ x.f0 instance
│ Leaking: UNKNOWN
│ Retaining 224.5 kB in 903 objects
│ ↓ f0.c
│ ~
├─ p30.f instance
│ Leaking: UNKNOWN
│ Retaining 224.5 kB in 902 objects
│ ↓ a.h
│ ~
├─ c50.d instance
│ Leaking: UNKNOWN
│ Retaining 1.8 kB in 34 objects
│ View not part of a window view hierarchy
│ View.mAttachInfo is null (view detached)
│ View.mID = R.id.web_view_banner
│ View.mWindowAttachCount = 9
│ c instance of com.particlemedia.ParticleApplication
│ mContext instance of com.particlemedia.ParticleApplication
│ ↓ e.o
│ ~
├─ android.view.animation.AlphaAnimation instance
│ Leaking: UNKNOWN
│ Retaining 364 B in 14 objects
│ ↓ Animation.mListenerHandler
│ ~~~~~~~~~~~~~~~~
├─ android.view.ViewRootImpl$ViewRootHandler instance
│ Leaking: UNKNOWN
│ Retaining 1.8 MB in 22838 objects
│ ↓ ViewRootImpl$ViewRootHandler.this$0
│ ~~~~~~
├─ android.view.ViewRootImpl instance
│ Leaking: YES (ViewRootImpl#mView is null)
│ Retaining 1.8 MB in 22837 objects
│ mContext instance of com.android.internal.policy.DecorContext, wrapping
│ activity com.particlemedia.ui.home.HomeActivity with mDestroyed = true
│ mWindowAttributes.mTitle = "com.particlenews.newsbreak/com.particlemedia.
│ ui.home.HomeActivity"
│ mWindowAttributes.type = 1
│ ↓ ViewRootImpl.mParentDecorView
╰→ com.android.internal.policy.DecorView instance
Leaking: YES (ObjectWatcher was watching this because com.android.
internal.policy.DecorView received View#onDetachedFromWindow() callback
and View.mContext references a destroyed activity)
Retaining 5.2 kB in 95 objects
key = 117bd875-25d8-42b3-abeb-195251635554
watchDurationMillis = 13106
retainedDurationMillis = 8102
View not part of a window view hierarchy
View.mAttachInfo is null (view detached)
View.mWindowAttachCount = 1
mContext instance of com.android.internal.policy.DecorContext, wrapping
activity com.particlemedia.ui.home.HomeActivity with mDestroyed = true

[jsligh]

I believe I have found 2 places where the reference was being held after a destroy() call. These are occurring in MraidExpand.java and PrebidWebViewBase.java.