Bug: memory leaks on native ads

[Liran Barsisa]

Detected by both Android-Studio and LeakCanary,   tested on Android 13 on Pixel 6. TP1A.220905.004

This can be reproduced even when trying out the sample:
https://github.com/googleads/googleads-mobile-android-examples/releases

https://github.com/googleads/googleads-mobile-android-examples

Please update all samples. It was terrible to update.

Possible causes : ConnectivityManager, WindowManager, MediaView

If the ad is cached and not released (which should be fine), it's even worse.

To reproduce, just have another Activity waiting after closing the one that has ads.

[Liran Barsisa]

For some reason the website here doesn't let me upload anything. Not even a tiny sample project.

So I've prepared a repository on Github:

https://github.com/AndroidDeveloperLB/AdmobSample

And a video there of the issue, too:
https://github.com/AndroidDeveloperLB/AdmobSample/blob/main/memoryLeakVideo.mp4

[Liran Barsisa]

Dependencies versions:

implementation 'com.google.android.gms:play-services-ads:21.2.0'

debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.9.1'

I believe one of the reasons for the memory leaks is this one:
https://issuetracker.google.com/issues/245521182

Sadly Admob SDK isn't open sourced, so I can't test whether I'm right or wrong here. 

It could be that it's only one of the reasons and there are more reasons, too.

[Liran Barsisa]

It seems it's not just for native ads:

Exact same issue can be detected for both RewardedVideoExample and RewardedInterstitialExample, if you do the same thing, meaning add an Activity that will start the one of the sample, show the ad, and go back to the Activity that you've created.

On both cases, it talks about ConnectivityManager, but I'm sure there could be even more reasons.

Here are these samples after doing the sample thing:
https://github.com/AndroidDeveloperLB/AdmobSample/blob/main/RewardedVideoExample.zip

https://github.com/AndroidDeveloperLB/AdmobSample/blob/main/RewardedInterstitialExample.zip

[Hermawan Winata]

For native ad, based on https://groups.google.com/g/google-admob-ads-sdk/c/T0vsrDhgSa0/m/NLrZvIeuAAAJ, it seems we need to call `nativeAdView.destroy()` as well.

Perhaps the sample code and https://developers.google.com/admob/android/native/advanced is outdated?

[Liran Barsisa]

@Hermawan First of all, on Android, Views that don't belong to the Activity/Fragment anymore should be auto-GC-ed, so I find it weird that this function even exists, just as NativeAd has such a function instead of just handle it on GC.

In any case, I've already tested what you wrote on other projects, and you are wrong. I've tested it here as well.

What you are right is that the examples are very outdated. Especially the ones that link to ZIP files, like here:
https://github.com/googleads/googleads-mobile-android-examples/releases

To test using the sample I've prepared, just add this after the call to populateUnifiedNativeAdView:

```

lifecycle.addObserver(object:DefaultLifecycleObserver {
override fun onDestroy(owner: LifecycleOwner) {
super.onDestroy(owner)
adView.root.destroy()
}
})

```

[Liran Barsisa]

@Hermawan  Such a thing reminds me back in the time that Bitmaps were stored in a the global RAM (not in the heap), so it was up to the developer to release them (using "recycle()").

After some time, Google said that it shouldn't be encouraged anymore to use such functions:

"

We're finding recycling to be less and less important as the system's memory management improves, so we're looking to phase out this guidance entirely rather than supporting recycling more naturally 

"

 
https://issuetracker.google.com/issues/187333146

On Sunday, September 11, 2022 at 6:49:08 AM UTC+3 Hermawan Winata wrote:

[Liran Barsisa]

@Hermawan  A workaround that is not quite good, but at least seems to avoid leaking the Activity (might still leak the various ad-related objects, including the ad-related Views) :

1. Using MobileAds.initialize(applicationContext) instead of MobileAds.initialize(this) . I think this solves the ConnectivityManager leak.

2. Setting currentNativeAd=null , and not just currentNativeAd?.destroy() . It seems that this object somehow has a reference to the Activity that holds it, even if I've inflated it using applicationContext.

Again, this is not even a good workaround, because I think the objects still leak, but at least it doesn't seem like they leak Activities/Fragments.

Also, getting rid of the ad shouldn't be required (both using "destroy" and having no reference to it anymore), because we should be able to cache it for next time we want to show the ad. It's even documented that it should be fine, including recommendation of how often we should refresh it.

I wonder if this "solves" the case that I've seen, that MediaView also seemed to cause leaks, as well as WindowManager.

On Sunday, September 11, 2022 at 6:49:08 AM UTC+3 Hermawan Winata wrote:

[Hermawan Winata]

@Liran No need to set `currentNativeAd = null` if it's moved as an `AdActivity`'s property.

Each Ad object might be using Timers and/or WebViews that we would still need to call `destroy`.

[Liran Barsisa]

@Hermawan   

If you look at the sample of Google/Admob , you can see that currentNativeAd is stored outside of the AdActivity (there it's called "MainActivity", I changed it), meaning it's not a field/property of it :

https://github.com/googleads/googleads-mobile-android-examples/blob/main/kotlin/admob/NativeAdvancedExample/app/src/main/java/com/google/android/gms/example/nativeadvancedexample/MainActivity.kt

And, as the docs say and as I've mentioned, you should be able to cache the ad for later use (in other Activity/Fragment, or even again on the current one or new instance of it), so this is not a good solution (in addition to the possibility that it still leaks).

Meaning to call "destroy()" and setting to null should be fine to be done much later, even after the Fragment/Activity is destroyed.

[Liran Barsisa]

@Hermawan   Seems I forgot that caching is only till it's time to show the ad, not after it was already used:

https://developers.google.com/admob/android/native/start?hl=en-US#cleaning_up

Still, this is a bad API, and I think Admob team should remove this function ("destroy") completely, and the one of the View itself.

On Sunday, September 11, 2022 at 12:15:07 PM UTC+3 Hermawan Winata wrote:

[Mobile Ads SDK Forum Advisor]

Hi Hermawan,

Thank you for raising this to us. I went ahead and test your sample app provided on my end. Upon testing, I wasn't able to trigger the LeakCanary memory leak even requesting ads many times (please see attached screenshot). Could you please provide more details on how you trigger the said issue? Is the issue occurs on a specific device? If so, please provide us the details.

Regards,

Teejay Wennie Mobile Ads SDK Team

ref:_00D1U1174p._5004Q2eMnTy:ref

[Liran Barsisa]

Have you done exactly as I've shown on the video and explained to do?

Meaning show video, press back key, and then take heap dump and analyze it?

[Liran Barsisa]

BTW, it's my sample. Not his.

And, for some reason on my app (here: https://play.google.com/store/apps/details?id=com.lb.app_manager ) the situation is much weirder, and I couldn't reproduce it on POC:

1. I have  a Fragment with a ViewModel of its own, both are responsible for ads.

2. The ViewModel decides at some point to load ads, but even if I just create the builder alone (without building it), and finish the Activity that has the fragment, it causes a memory leak.

This is all that was needed to cause it, and it occurs even on a static function (I pass to it applicationContext) : 

```
companion object {
    fun test(context: Context, adUnit: String) {
        val adLoader = AdLoader.Builder(context, adUnit)
    }
}

```

The memory leak mention these (tested on Android 13, on Pixel 6):

1. KeyGuardManager,

2. mLoaded APK in App ("App" is the name of the class that extends Application in my app)

3. mOnWindowDismissedCallback, 

On Monday, September 12, 2022 at 9:24:25 PM UTC+3 mobileadssdk wrote:

[Mobile Ads SDK Forum Advisor]

Hi Liran,

Thank you for getting back to us and providing more context of the reported issue

I've conducted a retest on my end and was now able to trigger the memory leak reported by LeakCanary. With that all said, I'll be raising to to a wider team for further investigation and to get their insight as well. I'll update this thread the soonest the team share their feedback.

[Liran Barsisa]

Thank you.

Please don't dismiss this as just the "fixes" I've found (setting null to the variable, and using applicationContext).

I think there is definitely more into it.

I think it would just leak outside of Activity/Fragment, instead, and also in the weird case that I've found a comment above:

https://groups.google.com/g/google-admob-ads-sdk/c/DPG1ej52N3A/m/frpPrfEnAwAJ

[Liran Barsisa]

About the weird case of the leak via the Fragment, I've made a small test in the Activity that contains it (create the builder there), and it doesn't seem to leak there. 
So it's probably some bug that's related to the supportFragmentManager, or something.
I will try to move all the important code from the Fragment to the Activity. 
Too bad. I was hoping this Fragment could be on its own, be able to be used in multiple places, or at least be nicely separated from other things.

[Mobile Ads SDK Forum Advisor]

Hi Liran,

Thank you for sharing your further findings. The team is still looking on this. I'll let you know the soonest their share their feedback.

[Liran Barsisa]

After I tried to move all the ad-loading logic into the Activity instead of Fragment, I can see that it's not because I used a Fragment (or maybe Fragment just made it worse).

The leak still exists even there.

So, I went back to using a Fragment, and what I changed is that inflating its layout isn't done by the normal way of :

val binding = FragmentAdBinding.inflate(layoutInflater,container,false)

Instead, what I used is to avoid anything related to the Activity that contains the Fragment, meaning I "cheated" and used the application instead:

val contextThemeWrapper = ContextThemeWrapper(activity!!.applicationContext, ...))
val binding = FragmentAdBinding.inflate(LayoutInflater.from(contextThemeWrapper), container, false)

The leak probably still exists, just that Admob's view/s probably have a reference to Application, and not to the Activity.

Using the profiler, it failed to detect memory leaks, and I don't know how to check my theory because I don't know which classes in Admob could cause the leak.

So I consider this a weak workaround, as it is unknown if it fixes the issue in general, but at least it won't leak the Activity/Fragment that holds the ads.

I've uploaded a video showing this issue and the weak workaround, that it "solves", right here on the same Github repository:
https://github.com/AndroidDeveloperLB/AdmobSample/blob/main/leaking%20of%20Activity%20and%20workaround%20for%20the%20inflater.mp4

On the video, I've added code to start a new Activity after 5 seconds (enough for showing an ad), and used the profiler to show the leaks, and again when I used the workaround.

This was tested on emulator with API 33, but also occurs on Pixel 6 with API 33.

[Mobile Ads SDK Forum Advisor]

Hi Liran,

Thank you for your response.

Can you confirm if you're able to resolve this behavior in your end? Upon checking, our team is still in progress investigating this. We will provide the additional information that you've shared to us. We will update you once we have more information on this that came from our team.

Regards,

Princess Pamela Mobile Ads SDK Team

ref:_00D1U1174p._5004Q2eMnTy:ref

[Liran Barsisa]

As I've written in the comments above yours, basically I've at least handled the leak of Activity/Fragment, but there could still be leaks of the SDK classes themselves.

I wanted to extend NativeAdView and add some log in case it gets GC, but it's marked as final, so I can't do this.

Now I've tried to use a wrapper class for the binding of the Fragment that has the NativeAdView. The Fragment is GC, and the binding reference there is set to null, too, so on my side all references to the Views and the NativeAdView are gone, and it should be GC together with the NativeAdView. 

The class is:

class GcTester(val obj: Any) {
@Suppress("unused", "ProtectedInFinal")
protected fun finalize() {
Log.d("AppLog", "GcTester GC. Had this object: $obj")
}
}

I've used it as such, without any usage of it further:

GcTester(binding)

The result is that it got GC too, so at least the Views are gone fine.

However, there could be other leaks of internal classes of the SDK , starting from whats' used to have the ad and initialize everything.

Also I failed to find out the reason of why there was a weird leak just for creating the builder class. 

[Mobile Ads SDK Forum Advisor]

Hi Liran,

Thank you for sharing your investigation on this.

Currently, our team is still working on investigating this. We will update you once we have more information on this.

[Mobile Ads SDK Forum Advisor]

Hi Liran,

The team provided their feedback with regard to the reported behavior here with the following verbatim:

"The user is correct in that if they provide the SDK an application context, the SDK has no choice but to initialize it's AdView/WebView views with an application context. Android recommends always initializing views with the Activity context, which is why we generally recommend using an Activity Context to load ads.

However, when using an activity context, they would need to load/show ads within the same activity and not use a static variable to store the AdLoader or the NativeAd object."

Regards,

Teejay Wennie Mobile Ads SDK Team

ref:_00D1U1174p._5004Q2eMnTy:ref

[Liran Barsisa]

1. The sample itself has the static reference. You should set it up better, and show to everyone what should be done. Check your own sample please:
https://github.com/googleads/googleads-mobile-android-examples/blob/main/kotlin/admob/NativeAdvancedExample/app/src/main/java/com/google/android/gms/example/nativeadvancedexample/MainActivity.kt#L39

As I wrote, if I had used this same code in a real app, there would be a memory leak. 

2. Using an Activity/Fragment is what's causing it to have memory leaks in some cases that I couldn't show on POC, but saw it on my own app (by using just the builder itself, alone). Too bad I didn't get it on video, like the rest of the issues.

I can send you my own code of the app, if you promise to keep it a secret and use it only for this purpose of fixing this issue, and then delete it when done with fixing it.

3. As I've shown, some components actually leak when using Activity/Fragment, which is probably what the SDK uses behind the scenes. The SDK isn't open sourced, so I can't know if using ApplicationContext solves it or not (the IDE's memory leak detection is similar to LeakCanary - based on specific classes). 

Here's the request on the issue tracker to have the IDE warn about using other types of Contexts:
https://issuetracker.google.com/issues/245521182

And as I wrote, this doesn't mean that if the SDK is fixed to use these, there won't be memory leaks on a larger scope.

4. Inflating the SDK's view themselves can cause a leak:
https://github.com/AndroidDeveloperLB/AdmobSample/blob/main/leaking%20of%20Activity%20and%20workaround%20for%20the%20inflater.mp4

I had to use a workaround of inflating on ApplicationContext.

5. The SDK doesn't have auto-release mechanisms, which is something that Google tried to avoid in the past (see the case of Bitmap, which has "recycle", but is said that we don't need it anymore). You should change the SDK to clean after itself, and check carefully if all objects that should be removed from memory are indeed released.

Maybe also offer a better API to manage the ads, based on lifecycle, timeouts, refresh time, etc... 

6. The SDK documentation says it's OK to cache the ads:

https://developers.google.com/admob/android/native/start#when_to_request_ads
"Any ad objects that have been held for longer than an hour without being displayed should be discarded and replaced with new ads from a new request."

https://support.google.com/admob/answer/2936217
"We recommend that you have ads persist for 60 seconds or longer"

Also don't forget that Activity can re-create itself on various cases.

So it doesn't make sense that ads stay only on Activity level (and ). 

What you wrote is what I thought that I should use the SDK (of providing Activity as Context parameter), but as I've noticed and shown, this is the opposite. 

Please fix this.

[Mobile Ads SDK Forum Advisor]

Hi Liran,

Thank you for your response.

You can provide your project file and we will share it to the wider team once provided, and so we could have full visibility in your implementation as well. Rest assured that the shared project file will not be shared externally and will be used for investigation purposes only. You can provide the following details via Reply privately to author option or directly provide it to the link below.

If the file(s) you are looking to share are less than 25mb in total you can attach them to this case on your next reply. If you are having trouble attaching your file to this case or if your file(s) are larger than 25mb, you can share your files with me by performing the following steps:

1. Navigate to

https://docs.google.com/forms/d/e/1FAIpQLSfkAiXMeYP-fw1W3Z-tT9uwmATEKO5X6S-th0gR2ezdKaaqfg/viewform?usp=pp_url&entry.400550049=Mobile+Ads+SDK&entry.460850823=5004Q00002eMnTyQAK&entry.80707362=00122929

2. Fill out all fields, and attach your file(s).

3. Please reply back on this thread when you have uploaded your file(s). Please do not share this link.

Regards,

Princess Pamela Mobile Ads SDK Team

ref:_00D1U1174p._5004Q2eMnTy:ref

[Liran Barsisa]

Any news about it? Have you tested the samples I've provided and the repository?
Have you fixed the memory leak ?
Do you plan on offering true preloading of ads, with actual Context as a parameter and not some hidden instruction to use only Activity which doesn't make any sense and isn't documented anywhere?

[Mobile Ads SDK Forum Advisor]

Hi Liran,

The Engineering has resolved this memory leak in native ads as fixed. The resolution was to updated nativeAd from top-level variable to class variable in our sample application. See this github change .

Hope this helps,
Nick

ref:_00D1U1174p._5004Q2eMnTy:ref

[Liran Barsisa]

I see you've indeed updated the sample of native ads alone, and I've tried to reproduce it on the sample and couldn't anymore.

However, all the 3 other memory leaks I've presented still occur which are on the Github repository:

1. On the real app I can still reproduce the memory leak, and the same weird workaround of it. The scenario of the app:

MainActivity has a fragment called "AdFragment" that deals with all the ads in it. 

The AdFragment uses this to inflate its Views:

override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View {

val binding = FragmentAdBinding.inflate(layoutInflater, container, false)
this.binding = binding
return binding.root
}

Even though MainActivity shouldn't be easily destroyed, I've added a simple code to make it as such, together with logs to show that it was GC and logs for when the native-ad was destroyed.

The starting and finishing of the MainActivity is simply as such:

uiHandler.postDelayed({
startActivity<SettingsActivity>()
finish()
}, 25000L)

If I let it occur, and I can see that the native ad was destroyed, and I call GC on the profiler, I can see in the logs that the MainActivity doesn't get GC-ed, as well as the AdFragment.

The MainAcitity was supposed to be destroyed and so the AdFragment, but they still have a reference because of the ads.

And, indeed, when I have the heap dump, I can see a memory leak.

And, the bizarre workaround is to use a different inflation of the AdFragment:

override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View {
val contextThemeWrapper =
ContextThemeWrapper(activity!!.applicationContext, ThemeUtil.getThemeStyle(activity!!, AppSettings.StyleType.Activity))

val binding =
FragmentAdBinding.inflate(LayoutInflater.from(contextThemeWrapper), container, false)

this.binding = binding
return binding.root
}

I've already shown it on the video:
https://github.com/AndroidDeveloperLB/AdmobSample/blob/main/leaking%20of%20Activity%20and%20workaround%20for%20the%20inflater.mp4

2. Rewarded video sample :

https://github.com/AndroidDeveloperLB/AdmobSample/blob/main/RewardedVideoExample.zip

3. Rewarded interstitial sample:

https://github.com/AndroidDeveloperLB/AdmobSample/blob/main/RewardedInterstitialExample.zip

[Mobile Ads SDK Forum Advisor]

Hi Liran,

Thank you for the update. I will take a look at the memory leak and let you know when we have next steps.

[Mobile Ads SDK Forum Advisor]

Hi Liran,

Can you provide more details on what you mean by "If I let it occur, and I can see that the native ad was destroyed, and I call GC on the profiler, I can see in the logs that the MainActivity doesn't get GC-ed, as well as the AdFragment. The MainAcitity was supposed to be destroyed and so the AdFragment, but they still have a reference because of the ads".

We are confused as to what you mean by the native ad is destroyed, but is it GC-ed? 

ref:_00D1U1174p._5004Q2eMnTy:ref

[Liran Barsisa]

There is an API to call to destroy the native ad:
https://developers.google.com/android/reference/com/google/android/gms/ads/nativead/NativeAdView#destroy()

It was called, and I wrote on logs that it was called.

I also added logs for when the MainActivity and AdFragment got GC-ed (in the "finalize()" function).

The profiler showed it too, that there is a memory leak as they still exist. 

Watch the video I've posted. 

Please also check the other memory leaks I've presented.

All types of ads should be immune to memory leaks when used properly in a basic manner, of just preloading, showing, and destroying the ad.

[123.r...@gmail.com]

Hi Google Team,

I am facing a similar leak.
Scenario :
-> A google ad is pre-requested and can be displayed in any activity of my app.
-> After one activity shows it, it is removed and not used anymore.
-> Leak happens when one activity inserted the ad but was not able to show it (below the fold) and then activity was destroyed.
-> Leak shows that the NativeAd instance references NativeAdView which in turn references some custom listeners set to its viewBinding.
-> Earlier calling NativeAdView.setNativeAd(null) in the activity's onDestroy used to handle this case. Now the arg is marked NonNull.

Basically how do we unregister the view from nativeAd object now?

[Mobile Ads SDK Forum Advisor]

Hi Raunak,

Thanks for the information. Can you provide any additional details for your specific leak such as sample code or a log showing the memory leak ?

ref:_00D1U1174p._5004Q2eMnTy:ref

[123.r...@gmail.com]

This is a stack from LeakCanary. This happened when the fragment where the ad was inserted was destroyed before the ad could be shown. We can see that the NativeAd instance holds reference to the viewBinding (due to NativeAdView.setNativeAd(nativeAd) call). 
Now, I cannot destroy the ad, as it would appear blank if I use it in next fragment. How can I disassociate it from the view?

─── │ GC Root: Thread object │ ├─ abl instance │ Leaking: NO (PathClassLoader↓ is not leaking) │ Thread name: 'Thread-79' │ ↓ Thread.contextClassLoader ├─ dalvik.system.PathClassLoader instance │ Leaking: NO (PgiAdHandler↓ is not leaking and A ClassLoader is never │ leaking) │ ↓ ClassLoader.runtimeInternalObjects ├─ java.lang.Object[] array │ Leaking: NO (PgiAdHandler↓ is not leaking) │ ↓ Object[18027] ├─ com.example.adengine.helper.PgiAdHandler class │ Leaking: NO (a class is never leaking) │ ↓ static PgiAdHandler.adEntity │ ~~~~ ├─ com.example.adengine.model.entity.ExternalSdkAd instance │ Leaking: UNKNOWN │ Retaining 13.1 kB in 201 objects │ ↓ ExternalSdkAd.nativeAdObject │ ~~~~~~ ├─ com.google.android.gms.internal.ads.zzbyq instance │ Leaking: UNKNOWN │ Retaining 1.5 kB in 14 objects │ ↓ zzbyq.zza │ ~ ├─ com.google.android.gms.internal.ads.zzbod instance │ Leaking: UNKNOWN │ Retaining 564 B in 2 objects │ ↓ zzasd.zza │ ~ ├─ com.google.android.gms.ads.internal.formats.client.ar instance │ Leaking: UNKNOWN │ Retaining 548 B in 1 objects │ ↓ ar.b │ ~ ├─ com.google.android.gms.ads.nonagon.ad.nativead.an instance │ Leaking: UNKNOWN │ Retaining 74.8 kB in 1232 objects │ B instance of com.example.AppController │ ↓ an.p │ ~ ├─ com.google.android.gms.ads.nonagon.ad.nativead.bn instance │ Leaking: UNKNOWN │ Retaining 1.0 kB in 19 objects │ ↓ bn.b │ ~ ├─ com.google.android.gms.ads.nativead.NativeAdView instance │ Leaking: UNKNOWN │ Retaining 1.9 kB in 37 objects │ View not part of a window view hierarchy │ View.mAttachInfo is null (view detached) │ View.mID = R.id.sdk_custom_root │ View.mWindowAttachCount = 1 │ mContext instance of com.example.appview.common.ui.activity.HomeActivity │ with mDestroyed = false │ ↓ View.mKeyedTags │ ~~~~ ├─ android.util.SparseArray instance │ Leaking: UNKNOWN │ Retaining 97 B in 4 objects │ ↓ SparseArray.mValues │ ~~~ ├─ java.lang.Object[] array │ Leaking: UNKNOWN │ Retaining 64 B in 2 objects │ ↓ Object[0] │ ~ ├─ com.example.adengine.databinding.DfpPgiNativeAdBindingImpl instance │ Leaking: UNKNOWN │ Retaining 40.2 kB in 812 objects │ ↓ DfpPgiNativeAdBinding.mAdReportListener │ ~~~~~~~ ├─ com.example.appview.common.helper.ReportAdsMenuFeedbackHelper instance │ Leaking: UNKNOWN │ Retaining 20 B in 1 objects │ ↓ ReportAdsMenuFeedbackHelper.fragment │ ~~~~ ╰→ com.example.view.fragment.PgiNativeAdFragment instance ​ Leaking: YES (ObjectWatcher was watching this because com.example. ​ view.fragment.PgiNativeAdFragment received Fragment#onDestroy() callback ​ and ObjectWatcher was watching this and Fragment#mFragmentManager is null) ​ Retaining 40.0 kB in 806 objects ​ key = a3b195c4-7d4d-4105-a6f3-3bf831bd0d5d ​ watchDurationMillis = 6148 ​ retainedDurationMillis = 1120 ​ key = 91e2d8f6-d4fd-4117-9815-3f03a5c75999 ​ key = 407fb0ff-f85c-4acf-b59c-b29004253147

[Mobile Ads SDK Forum Advisor]

Thanks Raunak,

We I will add this stack trace to our notes for considering how to resolve this bug.

[Mobile Ads SDK Forum Advisor]

Hi Raunak,

Can you provide a sample application which demonstrates the leak? I ran the github sample mentioned and was unable to generate a leak.
 

--------- beginning of main
--------- beginning of system
---------------------------- PROCESS STARTED (8383) for package com.google.android.gms.example.nativeadvancedexample ----------------------------
LeakCanary is running and ready to detect memory leaks.
Setting up flushing for Thread[LeakCanary-Heap-Dump,5,main]
Setting up flushing for Thread[queued-work-looper,5,main]
Setting up flushing for Thread[ConnectivityThread,5,main]
Setting up flushing for Thread[GoogleApiHandler,5,main]
Setting up flushing for Thread[Chrome_ProcessLauncherThread,5,main]
Setting up flushing for Thread[GoogleApiHandler,5,main]
Setting up flushing for Thread[PlatformServiceBridgeHandlerThread,5,main]
Setting up flushing for Thread[LooperProvider,5,main]
Setting up flushing for Thread[JavaBridge,7,main]

[Liran Barsisa]

You are confusing between reports. Please have a new report with what he wrote.

As for reproducing the issues I've presented, please show me a video just as I've shown you.

[Mobile Ads SDK Forum Advisor]

Hi Liran,

I will need to be able to demonstrate tis leak in a sample application. Using Leak Canary I am unable to replicate this leak using the sample app provided. Can you please inform me on the steps I need to take to replicate this leak?

[Ron K]

I'm experiencing the same issue - the fragment & activity are leaking due to native ad using the latest ads sdk ( com.google.android.gms:play-services-ads:22.6.0 ).

So nothing changed in these 9 months since the last message on this thread?!

[Mobile Ads SDK Forum Advisor]

Hi Ron,

I noticed you have a top level native ad variable. This may cause memory leaks, See this github change for an example fix.

Thanks,
Nick

ref:!00D1U01174p.!5004Q02eMnTy:ref