Google Play service ads library 19.x leaking PublisherAdView/AdManagerAdView

[Stanislovas Mickus]

Hello,

I have been using Google Play services  ad version 19.2.0 library and noticed that it was leaking PublisherAdView class. Our Android application has main feed with two types of ads in RecyclerView. So as expected I see to ad view holder instances in heap but PublisherAdView just keeps growing with some internal lib reference to it.
Also, in our app these manually created PublisherAdView classes in ad view holder are removed from parent and destroyed on in RecyclerView adapter onViewDetachedFromWindow method.

Tried newest com.google.android.gms:play-services-ads:19.8.0 library version same results. Tried update to new AdManagerAdView class also nothing changes. Attaching screenshots with heap of AdManagerAdView class (v19.8.0) reference info.

Best regards,
Stanislovas Mickus

[Mobile Ads SDK Forum Advisor Prod]

Hi Stanislovas,

Thank you for bringing this issue to our attention. I saw the screenshoit and would ask if you also have any other traces or samples showing the CPU usage and memory. At the same time can you share via "Reply to author" with a simple sample app showing your implementation as well as any steps that display this issue.

Regards,

William Pescherine Mobile Ads SDK Team

ref:_00D1U1174p._5004Q2Dx3Yq:ref

[Stanislovas Mickus]

Hi,

I have created sample app based on google RecyclerViewSimple widget app example. It adds mobile ads sdk and ad view holder and cleaning it in onViewDetachedFromWindow adapter. Scrolling back and forth it shows AdManagerAdView instances are leaking and being held by SDKs inter ViewGroup reference.

Public git repo is at address:

https://github.com/stasmanas/google-mobile-ads-leak-sample.git

Best regards,

Stanislovas Mickus

[Mobile Ads SDK Forum Advisor Prod]

Hi Stanislovas,

Thank you for the link, I was able to download the sample and run some test against it to see what could be happening. Just to make sure that we are seeing or doing the same things. I loaded the about and just was sxrolling through the screen to get new ads to appear. I was running it in Android Studio on a simulator. From what I could see, I was getting a the following error.
 

I/.recyclersampl: The stack is not large enough for a start_depth of 0.
E/StudioTransport: JVMTI error: 103(JVMTI_ERROR_ILLEGAL_ARGUMENT) 

Which would usually lead to the app crashing.
 

D/eglCodecCommon: setVertexArrayObject: set vao to 7 (7) 1 51
D/eglCodecCommon: setVertexArrayObject: set vao to 0 (0) 1 2

This was also building up as I was scrolling through ads. I did not see any increase in memopry or CPU outside of the normal within the profiler. But if you have anything else you would like to add to this please do. Once we hear back, I will bring this to my team to look further into.

[Stanislovas Mickus]

Hello, William,

Spinned some tests with provided sample and on my Pixel 4 XL I am seeing quite high memory usage. Initial after settling memory is ~250MB and with some intense scrolling I can easilly reach over 600MB. Which is not garbage collected after some idle time too. CPU gets quite high too. Attaching both overall and memory profiling graphs. This is close to behaviour I see on our shopping app.

Also on I can quite easily hit those errors about low memory on my device (JVMTI_ERROR_ILLEGAL_ARGUMENT) after some scroll though no crashes.

Also, tested on emulator Pixel 2 API25 and initially memory settles around ~30MB and with some intense scrolling I have easily reached over 90MB which is not garbage collected after some idle time. Not reached JVMTI_ERROR_ILLEGAL_ARGUMENT error here.

From what I see AdManagerAdView and some other classes are still referenced from lib and remain in memory. Things really get bad if AdManagerAdView is not manually destroyed so sample leak app on my device Pixel 4 XL easily reach over 1GB.

Regards,

Stanislovas

[Mobile Ads SDK Forum Advisor Prod]

Hi Stanislovas,

Thank you for bringing this to us.

I work with William and will be assisting you today. I already raised this issue to the team for further investigation. We will update you as soon as we got an update from the team.

Regards,

Princess Pamela Pineda Mobile Ads SDK Team

ref:_00D1U1174p._5004Q2Dx3Yq:ref

[Stanislovas Mickus]

Hello,

Great, looking forward to hearing from you!

Best regards,

Stanislovas

[Stanislovas Mickus]

Hi,

Maybe, you have any news regarding this issue? Checked version "com.google.android.gms:play-services-ads:20.2.0" and it's still has same issue.

[Mobile Ads SDK Forum Advisor]

Hello Stanislovas,

I hope you're doing well.

Upon checking, the team are still investigating this. But I will follow up this to them and provide them that this is also happening on v20.2.0. We will update you once we have more information.

[Mobile Ads SDK Forum Advisor]

Hello Stanislovas,

I hope you're doing well.

I just want to circle back on this. The team mentioned that the screenshots look like organic memory increases, and ~90MB is pretty typical when loading multiple ads. Even if has only 1 banner view, the SDK needs have 2 ads in memory. At refresh time, we load the second ad into a second WebView and make sure it loads before we replace the AdView on screen with the second WebView. Additionally, different ads may be of slightly different sizes with perceived memory increase depending on the ad. Finally, we rely on WebView, which may be caching some things for performance improvements that keeps some memory over time. With a memory leak, I would expect to continue to see upward trend linearly upon each ad request. But on all 3 screenshots, the curve flattens after 2-3 requests. I hope this clarify your concern for the leaking.