Memory leak in Native Unified Ads

[Ricardo Belchior]

Hi,

I'm integrating Google DFP (now AdManager) into our app and we recently moved to native ads, using the UnifiedNativeAd API (https://developers.google.com/ad-manager/mobile-ads-sdk/android/native-unified). 

Unfortunately there seems to be quite a lot of work happening on the main thread, therefore I was trying to reuse (cache) some ads, instead of loading them all the time, which causing jank in our UI. 

Is there any limitation to do that? That is, reuse the same "UnifiedNativeAd" across different View's without causing a memory leak. I've noticed that once we call "destroy", the main image (MediaView) does not load anymore.

Regardless, I noticed a memory leak that seems to happen all the time -- even without caching the ads. I could be missing something..l anyway, here's a sample demonstrating the issue: 

https://github.com/RicardoBelchior/ReuseAdvertsSample

Cheers,

Ricardo Belchior

Ps (1): PlayServices Ads: "com.google.android.gms:play-services-ads:17.0.0"

Ps (2): I also posted this in the Google Issue Tracker (https://issuetracker.google.com/issues/118564459) but got no response. I don't know exactly where's the place to report issues for the play-services-ads library.

[mobileadssdk-a...@google.com]

Hi Ricardo,

Thanks for reaching out to us. We are looking into this issue and we will get back to you with our findings as soon as possible.

Regards,

Deepika Uragayala

Mobile Ads SDK Team

=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

Also find us on our blog and Google+ page:
    http://googleadsdeveloper.blogspot.com
    https://plus.google.com/115658573333388777174/
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

--

---
You received this message because you are subscribed to the Google Groups "Google Mobile Ads SDK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-admob-ads-sdk+unsub...@googlegroups.com.
To post to this group, send email to google-admob-ads-sdk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-admob-ads-sdk/dd957c78-78dc-417c-89a2-96187a2c4f13%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mobileadssdk-a...@google.com]

Hey Ricardo,

Can you confirm whether you were able to build and load the AdvertFragment from the MainActivity? Somehow this is not showing up and the app is crashing. Is this what you are saying as the issue? Can you also send us profiler data for the memory leak that you have noticed? This would help us with our investigation.

Regards,

Deepika Uragayala

Mobile Ads SDK Team

=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Also find us on our blog and Google+ page:
    http://googleadsdeveloper.blogspot.com
    https://plus.google.com/115658573333388777174/
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

On 10/31/18 05:03:14 ricard...@gmail.com wrote:

--

[Ricardo Belchior]

Hi,

Yes I can use the app. Crashing is a bit strange.. I just cloned my own repo and built/installed the app and it loads the test ads. I'm testing on an emulator w/ API 27 (Android 8.1 Google APIs). Perhaps you can test on another device or show me the stacktrace... But the issue is the memory leak, not the crash ^^

I recorded two sessions:

>> memory-20181101T093819_activity_leaked: https://drive.google.com/open?id=1NOXCY7pdFl3n10gWw9GAYLMlJaY7ZbTx

Steps to reproduce: Open the app, click the "Open native ads" button, open a few fragments on the bottom navigation and press back. Both AdvertFragment and AdvertsContainerActivity are in memory, but they should not be.

>> memory-20181101T094024_fragment_leaked: https://drive.google.com/open?id=13G64zsHamCOOJc8mga8yrCjEzIlQoxVp

Steps to reproduce: Open the app, click the "Open native ads" button, open a few fragments (on the bottom navigation) and then open the last one: OtherFragment . The last one does not load any adverts, I included it there to test the memory leak. And in this case, AdvertFragment is still in memory but it should not be.

Hope this helps!

Cheers,

Ricardo

[mobileadssdk-a...@google.com]

Hi Ricardo,

Thanks for sharing the details. Let me take a look and debug this further. I'll get back to you with my findings as soon as possible.

Regards,

Deepika Uragayala

Mobile Ads SDK Team

=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Also find us on our blog and Google+ page:
    http://googleadsdeveloper.blogspot.com
    https://plus.google.com/115658573333388777174/
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

To unsubscribe from this group and stop receiving emails from it, send an email to google-admob-ads-sdk+unsubscrib...@googlegroups.com.

To post to this group, send email to google-admob-ads-sdk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-admob-ads-sdk/dd957c78-78dc-417c-89a2-96187a2c4f13%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "Google Mobile Ads SDK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-admob-ads-sdk+unsub...@googlegroups.com.
To post to this group, send email to google-admob-ads-sdk@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-admob-ads-sdk/c6053793-ac6c-4d17-8736-c22e27df7afc%40googlegroups.com.

[mobileadssdk-a...@google.com]

Hi Ricardo,

Sorry for the delay. I have been trying to debug this further with the sample app that you have provided and with our own sample app and have been unable to reproduce any memory leaks. All of the Activities are being deallocated and the Fragments as well without any issues when the I navigate back to the MainFragment. Attached two screenshots that show the moment when the back navigation event is fired and the Activity being destroyed.

Regards,
Deepika Uragayala
Mobile Ads SDK Team

=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Also find us on our blog and Google+ page:
    http://googleadsdeveloper.blogspot.com
    https://plus.google.com/115658573333388777174/
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

[Ricardo Belchior]

Dear Deepika,

Thank you for taking the time to reply. I tried this time on different devices and here is what I've found:

Pixel API 28 => No memory leak 

Nexus 5X API 27 => No memory leak

Emulator API 27 => Memory leak detected

Samsung API 26 => Memory leak detected

So, it seems to be device/API specific...that may help. In order to reproduce I do the following steps:

1) Open app

2) Click "open native ads"

3) Wait for adverts to load and open all fragments (using the bottom navigation buttons)

4) Press back

5) In Android Studio, open the memory profiler

6) Trigger Garbage Collector

7) Dump java heap (the icon next to garbage collector)

8) Search in the heap for AdvertFragment or AdvertsContainerActivity

When the leak happens, both the fragment and activity are found.

Cheers,

Ricardo

PS: I noticed the crash now, sorry about that, it's not unrelated... just pushed the fix to GitHub.

[mobileadssdk-a...@google.com]

Hi Ricardo,

It might be a device specific issue as you are able to reproduce the issue only on specific devices. Anyhow, I'll try to get hold of one of those devices to retest this again and I will get back to once I have more information.

Regards,

Deepika Uragayala

Mobile Ads SDK Team

=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Also find us on our blog and Google+ page:
    http://googleadsdeveloper.blogspot.com
    https://plus.google.com/115658573333388777174/
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

To unsubscribe from this group and stop receiving emails from it, send an email to google-admob-ads-sdk+unsub...@googlegroups.com.

To post to this group, send email to google-admob-ads-sdk@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-admob-ads-sdk/c22b733e-d625-4d8a-a437-d547c0564c0e%40googlegroups.com.

[Raunak Yadav]

Hi Deepika,

I am also facing the same problem. Memory leak, whenever we leave the activity with ads. Even after calling destroy on the ad, triggering GC and waiting for some time, the activity remains in memory. Testing on a Samsung device (Android 7.0).  (PFA snapshot from LeakCanary)

Please help with a fix as we have a large base of Samsung users as well.

Thanks,

[mobileadssdk-a...@google.com]

Hi Raunak,

Can you send us a sample app that reproduces this issue since we have tested the previous user's flow and have unable to reproduce any memory leaks. Are you on the latest version of the SDK?

Regards,
Deepika Uragayala
Mobile Ads SDK Team

=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Also find us on our blog and Google+ page:
    http://googleadsdeveloper.blogspot.com
    https://plus.google.com/115658573333388777174/
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

To view this discussion on the web visit https://groups.google.com/d/msgid/google-admob-ads-sdk/c22b733e-d625-4d8a-a437-d547c0564c0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "Google Mobile Ads SDK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-admob-ads-sdk+unsub...@googlegroups.com.
To post to this group, send email to google-admob-ads-sdk@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-admob-ads-sdk/a99d2724-e672-41a3-8480-18c1ecb3d57b%40googlegroups.com.

[Raunak Yadav]

Hi Deepika,

Please find Sample project at : https://drive.google.com/open?id=1LfDbK2FPsiZCkJWhzXUVQdOjqdVTjUFU

This is the sample project of google ads hosted here with minor changes :

 - Added 'FirstActivity' as home screen which leads to MainActivity.

 - Added ad destroy call in MainActivity's onDestroy

 - Added a back button to MainActivity.
 - Added LeakCanary

Steps :

Launch app -> FirstActivity -> Click button -> MainActivity -> See a video Ad -> Press back on ad completion -> Trigger GC -> Take heap dump

----> MainActivity still exists.

I have uploaded the hprof file as well. Let me know if anything else is required.

Thanks

[mobileadssdk-a...@google.com]

Hi Raunak,

Thanks for sharing the sample app. I have shared this with the team. We will keep you posted on any updates that I might receive from the team.

Regards,

Deepika Uragayala

Mobile Ads SDK Team

~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

Also find us on our blog and Google+ page:
    http://googleadsdeveloper.blogspot.com
    https://plus.google.com/115658573333388777174/
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

To view this discussion on the web visit https://groups.google.com/d/msgid/google-admob-ads-sdk/a99d2724-e672-41a3-8480-18c1ecb3d57b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "Google Mobile Ads SDK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-admob-ads-sdk+unsub...@googlegroups.com.
To post to this group, send email to google-admob-ads-sdk@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-admob-ads-sdk/8aa84c96-091e-4047-8172-668b2f11cd94%40googlegroups.com.

[Ricardo Belchior]

Guys , any update here? 

This is still occurring on com.google.android.gms:play-services-ads:17.1.3 and it's causing a big hit on our OutOfMemory crashes count =(

[mobileadssdk...@google.com]

Hello Ricardo,

I've checked this with our team and it is still under investigation. But, I will make sure that this gets resolved as soon as possible and will provide you an update when I get any new information from the team.

Regards,

Deepika Uragayala

Mobile Ads SDK Team

=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Also find us on our blog and Google+ page:
    http://googleadsdeveloper.blogspot.com
    https://plus.google.com/115658573333388777174/
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

[Ricardo Belchior]

Hi Deepika,

I'm sorry to insist but it's been 3 months since I last checked here and this problem seems to still be affecting play-services-ads:17.2.0   

Any news about this ticket? 

(if this sdk is open source I can give a helping hand...)

[Mobile Ads SDK Forum Advisor Prod]

Hello Ricardo,

Apologies for keeping you on hold and I appreciate your patience. Our team has taken a look into this issue and it looks like the issue is not related with the Mobile Ads SDK and you can test this with an empty sample app without any reference to the AdView. Also note that the AdView references might be present even if the destroy() is called if the Activity/ParentView is still present in memory. If you still think that this is due to the AdView, then send us a heap dump that is shown when the Activity is destroyed that shows AdView being the cause of the leak and we will share it with the team to further investigate this again.

Regards,
Deepika Uragayala
Mobile Ads SDK Team
 

 

ref:_00D1U1174p._5001UAq88P:ref

[Ricardo Belchior]

Hi Deepika,

Thank you very much for getting back to me. It looks like you're correct, there is an improvement in play-services-ads:17.2.0 , but not quite there yet. Just to recap, when I created this ticket I was reporting two things:

1) Reusing adverts between Views is not possible after NativeAd#destroy. And not calling "#destroy" causes a memory leak.

2) A memory leak happening all the time, even without reusing (caching) adverts.

>> From what I understand, issue (2) is fixed. I updated all libraries to most recent versions and I cannot reproduce the memory leak anymore*. Case closed.

>> Issue (1) is still there. Is that something you're able to support? My case is simple: loading adverts takes a lot of work on main thread (causes jank on lower-end devices). Our UI (not the sample app) is a ViewPager where users frequently swipe back and forth and we are unable to reuse adverts on previously visited fragments (because they are recycled and recreated again) without causing a memory leak. 

The consequence is that we're constantly making ad requests, which looks ok-ish on good devices and very janky on "bad" devices. We want to provide our users with the best experience on Android and follow the best practices recommended by the Android team, please help us get there =) 

Here's the repository with the sample app:

https://github.com/RicardoBelchior/ReuseAdvertsSample

For the code reusing adverts, checkout branch: 

reuse-fragments

Here goes attached the heap dump of the memory leak when reusing adverts:

https://drive.google.com/open?id=1AY199AYx4vvXOGnLn5CFAg_KNbh7iYiq

https://drive.google.com/open?id=13tVlfgWbc4xJfRocbvrAn_ZKCtn49sfn

https://drive.google.com/open?id=1ipkOQYtFHUM1TorIjOe4XyD5Xc_sf5j5

Here's a video of the steps performed in the app before dumping the memory:

https://drive.google.com/open?id=1U40H3-V1onGqMbaWZCJCZhYtSVltCneU

I hope that I'm not missing anything stupid ^^

(*) I would suggest specifying in the documentation that the context should be the application context. Using the Activity as a context still caused me a memory leak when the activity finished before loading the advert.

Best regards,

Ricardo

[Mobile Ads SDK Forum Advisor Prod]

Hello Ricardo,

Thanks for providing all the details. Let me take a look and debug this further. I will get back to you with my findings as soon as possible.

[Ricardo Belchior]

Hi there,

Sorry to insist but it's been two months since I last heard from you. Do you have any update ? 

Cheers,

Ricardo

[Mobile Ads SDK Forum Advisor Prod]

Hello Ricardo,

Sorry for keep you waiting. There has been some confusion with the two different issues mentioned as per our last discussion. Our team will get back to you with more information on this as early as possible.

[Ricardo Belchior]

Hello, is there any update on this?

Today marks one year since I reported this ticket. I understand it might not be easy to fix, but all I'm asking for is to be able to provide a smooth experience for my users. I find it very sad that Android documentation emphasises so much on removing expensive work from the main thread, doing all work in 16ms or delegate to a background thread, etc. And one of Google's own library prevents us from doing that!

And I mean... this is not a novelty...

https://developer.android.com/topic/performance/vitals/render

https://developer.android.com/topic/performance/vitals/frozen

https://developer.android.com/topic/performance/threads

https://developer.android.com/training/testing/performance

https://medium.com/google-developers/developing-for-android-i-understanding-the-mobile-context-fd2351b131f8

Please don't forget about this...

Best regards,

Ricardo Belchior

[Mobile Ads SDK Forum Advisor Prod]

Hi Ricardo,

Thanks for your patience. Our team has looked into this and they say that native ads do hold onto a view context so, reusing adverts between Views is not possible after NativeAd#destroy is kind of working as intended. That said, being able to reuse native ads across views is a feature request, which has been surfaced to engineering team to take a look. 

[xy m]

Is there any progress on this issue？

在 2018年10月31日星期三 UTC+8下午5:03:14，Ricardo Belchior写道：

[Mobile Ads SDK Forum Advisor Prod]

Hi there,

Let me follow up this to the team. I'll get back to you the soonest they provide their feedback.

Regards,
Teejay Pimentel

Mobile Ads SDK Team

ref:_00D1U1174p._5001UZYqSG:ref

[李子]

Hi Ricardo,

I search google ads reuse issue then I find your post. 

My app insert some google-ads into RecyclerView, and I found when I scroll the RV up and down, finally cause crash, and no error call stack.

I reuse google ads in RV.

Have you find some workaround to avoid this issue.Since google ads team not update any thing.

Thank you.

 

在 2018年10月31日星期三 UTC+8下午5:03:14，Ricardo Belchior写道：

Hi,

[Mobile Ads SDK Forum Advisor Prod]

Hi there,

As you are experiencing a crash and we would like to help would you please open a new thread to post your issue?

Concerning the original issue posted on this thread, after the NativeAd moves to the new frame the following code - "oldFrameLayout.removeAllViews();" should be called on the old Framelayout where the NativeAd was, and then the ad should work in the new frame without memory leaks. You can try adding another frame to our latest sample apps here, in the Native Samples and creating your use case. Note that as long as you want to reuse the ad you don't want to destroy it.

Regards,
Aryeh Baker
Mobile Ads SDK Team 

ref:_00D1U1174p._5001UZYqSG:ref

[Mobile Ads SDK Forum Advisor Prod]

Hi Ricardo,

Concerning your desire to reuse a Native Ad in a new frame could you try after the NativeAd moves to the new frame the following code - "oldFrameLayout.removeAllViews();"? This should be called on the old Framelayout where the NativeAd was, and then the ad should work in the new frame without memory leaks. You can try adding another frame to our latest sample apps here, in the Native Samples and creating your use case. Note that as long as you want to reuse the ad you don't want to destroy it.

Regards,
Aryeh Baker
Mobile Ads SDK Team 

ref:_00D1U1174p._5001UAq88P:ref

[Mobile Ads SDK Forum Advisor Prod]

Hi Ricardo,

I received a part of your email and it says you tried my suggestion and still found a memory leak. Reusing native ads across views is still a feature request and I had come across this suggestion.

[Ricardo Belchior]

Hi Aryeh,

I'm afraid I'm still able to replicate the memory leak. I just had a look at the new sample apps, more precisely at the NativeAdsExample (https://github.com/googleads/googleads-mobile-android-examples/blob/master/kotlin/admanager/NativeAdsExample/app/src/main/java/com/google/android/gms/example/nativeadsexample/MainActivity.kt)

There is only one activity, so it's "impossible" to replicate an activity leak in that situation. Besides, I don't see anything there that I'm not doing in my sample app. I have updated it with the latest versions of all libraries and I've updated it to include your suggestion of "removeAllViews". 

Also, here's the sample app I'm talking about:

https://github.com/RicardoBelchior/ReuseAdvertsSample

It has one initial activity to select the ad unit id, and then it's one activity with 4 fragments. Three of them will attempt to load ads and it's corresponding "UnifiedNativeAd" object is cached on the Application class. The memory leak can be reproduced by opening those fragments a few times and pressing back to the initial activity. 

See here the attached screenshots taken from LeakCanary. They show that "MyApplication" includes a reference to "cachedAdverts" , that is a map of those UnifiedNativeAd objects to be reused. Unfortunately those UnifiedNativeAd save a reference to a context of the UnifiedNativeAdView, which in turns is the context of the Activity (that has been destroyed and should not be in memory anymore).

Hope I'm not missing anything.. Hope that helps....

Kind regards,

Ricardo

PS.: apologies for the earlier email, clicked publish by mistake!!

[Mobile Ads SDK Forum Advisor Prod]

Hi Ricardo,

Thank you for setting up your demonstration. I tested it and found a leak when retaining Native Ads in your application when moving from activity to activity. The suggestion of "removeAllViews" doesn't help in this instance and for your use case is still a feature request.

[Ricardo Belchior]

Great! Thanks for taking the time to test it!

[Ana Ilies]

Any updates on this? I am encountering the same issue. 

Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.

[Mobile Ads SDK Forum Advisor]

Hi Ana,

We do not have a specific time frame for the availability of this feature at the moment. Please be assured that our team is actively working on it and one of my team members will reach out to you once we have an update on this. Meanwhile, your patience is highly appreciated.

This message is in relation to case "ref:!00D1U01174p.!5001U0Aq88P:ref" (ADR-00001705)

Thanks,
 

Mobile Ads SDK Team

[Mobile Ads SDK Forum Advisor]

Hi,

Thank you for getting back to us. 

I have executed our sample project with the provided information and am unable to replicate the issue. Could you confirm whether the mentioned issue is reproducible in our sample project?  If yes, kindly share the below information privately so we can review it and try to replicate the problem. After doing so, we will be better equipped to offer a solution. 

• Sample project reproducing the issue
• The full stack trace
• Memory Profiler report
• Affected devices

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 via reply to author option or by performing the following steps:

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

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

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

Thanks,
 

Mobile Ads SDK Team

Feedback
How was our support today?

               
[2025-02-20 23:16:53Z GMT] This message is in relation to case "ref:!00D1U01174p.!5001U0Aq88P:ref" (ADR-00001705)