Memory Leak: AdMob webviews cause activities to leak

[Rico Yao]

After implementing the latest 4.0.4 SDK, I noticed that I started
leaking activities. I took HPROF dumps and analyzed with Eclipse
Memory Analyzer and found that the offending reference is the AdMob
weview.

My implementation is fairly straightforward, following the developer's
guide. I load an ad in onCreate() and I call
admobAdView.stopLoading() in onDestroy().

I thought maybe I had an implementation bug, so I took the demo app
from the docs (http://dl.google.com/googleadmobadssdk/examples/android-
banner-details.zip) and I found the same leak there. All I had to do
was load up the demo app with my adUnitId and then rotate the device a
bunch of times after each banner advert is loaded. Trigger a GC
through DDMS, take an HPROF dump and you will find that an instance of
the com.google.ads.example.BannerDetails activity has leaked for every
single rotation. Once again, it's the webview that causes it.

Appreciate any advice. Thanks!

[Tim]

Rico,

I only notice this on Android 2.2 and below, and I've only seen it
leak at most one WebView. I believe this is related to a bug in
Android that appears to be fixed in 2.3. Basically, it seems like
Android is holding on to references to WebViews longer than it should.
In the next release, we will have an AdView.destroy() method that you
can call in Activity.onDestroy(). I believe should fix the leak.

Thanks,
-Tim

[Rico Yao]

Tim,

Thanks for the response. I did some additional testing based on your info and I've discovered some interesting things.

1. I can indeed confirm that this leak is capped at one webview on Froyo. 

2. On Gingerbread, the leak is in fact WORSE, and not fixed.  It is on Gingerbread where a WebView will leak for every single device rotation.  It's reproducible 100% on a Nexus S and a couple other Gingerbread devices I have.

I'm doing these tests on the AdMob demo app so you should be able to reproduce quite easily if you're interested.  

So for now, it sounds like we'll have to turn off AdMob for our Gingerbread users.  Looking forward to Adview.destroy().  Hope it fixes this on all platforms.

Thanks,

Rico

[Tim]

Rico,

I downloaded the demo app you linked to, rotated it back and forth,
and analyzed the memory dump. I tried this on Gingerbread emulators
(2.3.1 and 2.3.3), and also tried it on a Nexus S (running 2.3), but
was unable to see any memory leaking going on. Is there any additional
information that might be helpful? What version of Gingerbread are you
running?

Thanks,
-Tim

[Rico Yao]

Hi Tim,

Thanks for your help looking into this.  After some more testing on my end:

- I also see that the leak doesn't happen on 2.3.x emulators.  

- I was getting the leaks on a Nexus S running 2.3.3.  It was stock 2.3.3 but it was rooted so I did a factory reset just to be sure.  The leak is GONE.  I can only assume something got messed up on the handset.  I've re-rooted and the leak is still gone.

- My other device is an HTC Ace running 2.3.3.  This is not stock Android and has HTC's Sense UI on it.  On this, the leak persists (one for every rotation) even after a factory reset.  I guess that's an OS level bug introduced/retained during their customizations.

Thanks,

Rico

[Kevin Cha]

I am noticing this issue in stock Honeycomb 3.0.1 as well. Are there
any known workarounds available for this? If not, when can we exact a
fix (when is your next release)?

Thanks,

- Kevin Cha

[Victor]

Just wanted to chime in and say that I am also experiencing this
problem on my Thunderbolt running Android 2.2 with HTC Sense. I'm
using the 4.1.0 SDK and I am calling destroy() on the AdView in my
Activity's onDestroy method but the issue persists.

Is there any workaround or fix for this?

[Muzikant]

I see the same issue...

Sample code and HPROF screenshot are at
http://stackoverflow.com/questions/6148812/android-admob-causes-memory-leak

Did anyone get a response from AdMob ?

[Emanuel Moecklin]

Same here but in my case it's a live application.
If I rotate the device (Nexus One 2.34 or Atrix 2.22) the allocated
memory goes up from less than 4 MB to more than 6 MB with every
rotation till it crashes.
If I remove the following line: adView.loadAd(adRequest); from my
code, the memory allocation always stays below 4 MB.

Emanuel Moecklin
1gravity LLC

[wes]

Emanuel,

I'm not seeing this on my Nexus S running 2.3.4.  What I did see what that an extra WebViewCore can hang around, but it only ever seems to be one extra.  What's the name of your application, I'd be happy to look for it in the Market to see if I can reproduce.

Muzikant,

I've responded to your StackOverflow post, but basically, it's not really an issue.  Eventually that spare activity you're seeing gets GC'd.

Cheers,

Wes

[Emanuel Moecklin]

Hi Wes

It's "Sudoku 10'000 Free".
I just downloaded the app through the market onto my Nexus One (free
and also paid version "Sudoku 10'000 Plus") and could crash the free
version (with ads) but not the paid version (no ads).
In order to reproduce the issue it's best to go to the play screen
(click Play Sudoku, then pick one puzzle to play from the list) and
rotate it several times and in fast succession (20-30 times or even
more).
What happens is that the Admob code somehow leaks memory (that's my
guess at least) and at some point the setContentView of my activity
that restarts with each orientation change fails with an
OutOfMemoryError that crashes the app.
I'm working on a workaround to at least prevent the crash but of
course it would be preferable if the leak could be fixed.

Best Regards
Emanuel Moecklin
1gravity LLC

On Jun 2, 7:17 pm, wes <wesgood...@google.com> wrote:
> Emanuel,
>
> I'm not seeing this on my Nexus S running 2.3.4.  What I did see what that
> an extra WebViewCore can hang around, but it only ever seems to be one
> extra.  What's the name of your application, I'd be happy to look for it in
> the Market to see if I can reproduce.
>
> Muzikant,
>
> I've responded to your StackOverflow post, but basically, it's not really an
> issue.  Eventually that spare activity you're seeing gets GC'd.
>
> Cheers,
> Wes
>

[Emanuel Moecklin]

BTW I'm getting at least 20 crash reports each day because of this
issue, so it's no small thing for me even if it's hard to reproduce.

On Jun 2, 7:17 pm, wes <wesgood...@google.com> wrote:

> Emanuel,
>
> I'm not seeing this on my Nexus S running 2.3.4.  What I did see what that
> an extra WebViewCore can hang around, but it only ever seems to be one
> extra.  What's the name of your application, I'd be happy to look for it in
> the Market to see if I can reproduce.
>
> Muzikant,
>
> I've responded to your StackOverflow post, but basically, it's not really an
> issue.  Eventually that spare activity you're seeing gets GC'd.
>
> Cheers,
> Wes
>

[wes]

Emanuel,

Are you calling AdView.destroy() in your activity's onDestroy?  If so, my only guess is that this represents some kind of WebView bug, and that you might try doing something like System.gc() to make sure things are getting cleaned up in time.

FWIW, I can only reproduce your issue if I rotate the device so quickly that no ad has a chance to load.

Cheers,

Wes

[Emanuel Moecklin]

Hi Wes

I do call AdView.destroy() in the activity's onDestroy() method.
I don't think it's a WebView bug because I cannot reproduce the
problem with the paid version even if a WebView is open.
I'm not just calling System.gc() when memory is getting low, I'm also
doing a LOT of cleanup when the activity terminates (onDestroy):

/**
* Removes the reference to the activity to every background image
used in a view.
* This method should be called in the onDestroy() method of each
activity
* @param viewID normally the id of the root layout
*
* see http://code.google.com/p/android/issues/detail?id=8488
*/
public static void unbindDrawables(Activity activity, int viewID) {
try {
View view = activity.findViewById(viewID);
if (view!=null) {
View adView = view.findViewById(R.id.ad);
if (adView!=null && adView instanceof AdView) {
unbindDrawables(adView);
((AdView) adView).destroy();
}
unbindDrawables(view);
if (view instanceof ViewGroup) unbindDrawables((ViewGroup)
view);
}
System.gc();
}
catch (Throwable e) {
// whatever exception is thrown just ignore it because a crash is
always worse than this method not doing what it's supposed to do
}
}

private static void unbindDrawables(ViewGroup viewGroup) {
int nrOfChildren = viewGroup.getChildCount();
for (int i=0; i<nrOfChildren; i++) {
unbindDrawables(viewGroup.getChildAt(i));
}
try {
viewGroup.removeAllViews();
}
catch (UnsupportedOperationException mayHappen) {
// AdapterViews, ListViews and potentially other ViewGroups don't
support the removeAllViews operation
}
}

private static void unbindDrawables(View view) {
Drawable d = view.getBackground();
if (d!=null) d.setCallback(null);
if (view instanceof ImageView) {
ImageView imageView = (ImageView) view;
d = imageView.getDrawable();
if (d!=null) d.setCallback(null);
imageView.setImageDrawable(null);
imageView.setBackgroundDrawable(null);
}
}


Yes you need to rotate the device quickly to reproduce the issue but I
get many crash reports with OutOfMemoryErrors and I'm quite sure most
of them are due to the issue at hand.
Maybe you should do a cleanup similar to what I'm doing (check out
http://code.google.com/p/android/issues/detail?id=8488 and also
http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks.html).

Emanuel

On Jun 3, 7:34 pm, wes <wesgood...@google.com> wrote:
> Emanuel,
>

> Are you calling AdView.destroy() in your activity's onDestroy?  If so, my
> only guess is that this represents some kind of WebView bug, and that you
> might try doing something like System.gc() to make sure things are getting
> cleaned up in time.
>
> FWIW, I can only reproduce your issue if I rotate the device so quickly that
> no ad has a chance to load.
>
> Cheers,
> Wes
>

[Emanuel Moecklin]

Hi Wes

Please check my posting at https://groups.google.com/d/topic/google-admob-ads-sdk/XnU2K2Q18aA/discussion.

I hope that will convince you that Admob should do something about this.

Best Regards

Emanuel Moecklin

[wes]

Emanuel,

Thanks so much for your investigation.  I've forwarded your concerns on to the eng team, who are going to take a crack at rewriting our AsyncTask system.

Cheers,
Wes

[Emanuel Moecklin]

Hi Wes 

The best way to solve this issue is not to keep a reference to the 
context in any AsyncTask at all. 
There are alternative ways to access the resources provided by an 
activity's context, e.g. using the Application context or use 
view.getContext(). 
Of course properly cancelling the AsyncTask will help additionally. 

Cheers 
Emanuel 

[Adam Zehavi]

Solution:

http://stackoverflow.com/questions/6148812/android-admob-causes-memory-leak

[anurag jain]

I can't believe even after 2 years this issue is not fixed by admob team.

This is so frustrating, had to remove ads from the app because of this.

On Tuesday, December 6, 2011 2:05:18 PM UTC+5:30, Adam Zehavi wrote:

Solution:

http://stackoverflow.com/questions/6148812/android-admob-causes-memory-leak

[Steven Kwan]

It looks like it may have been addressed. I have my AdView created programmatically, but the context that is passed is that of the Activity.  I saw this leak with the WebKitCore in the AdView, but what I did was I called destroy() on the AdView in my Activity's onDestroy.  I am using the 6.1.0 SDK, but I tried this solution with both it and 6.4.1.

[anurag jain]

Hi Steven,

For me, it doesn't work.

I tried creating adview both programmatically as well as in xml, but same results same in both the cases.

If I add adview, my app usage grows by atleast 15mb and keep on growing if I rotate my device.

I am using 6.4.1 sdk. I am not sure what am I missing.

--
 
---
You received this message because you are subscribed to a topic in the Google Groups "Google AdMob Ads Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-admob-ads-sdk/9IyjqdmeumM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-admob-ads...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Anurag Jain

BTECH, Electrical Engineering 

Indian Institute of Technology Delhi

[Pablo Alfonso]

Though this issue has been reported 9 years ago, AdView is still generating memory leaks everytime I use it.

I can see it even in the most simplest activities (after executing adview.destroy() in Activity OnDestroy()).

My last testcase was performed in a BluView1 with Android 9 (Pie).

The following is the stack from LeakCanary:

    1 APPLICATION LEAKS

    

    References underlined with "~~~" are likely causes.

    Learn more at https://squ.re/leaks.

    

    1017679 bytes retained by leaking objects

    Signature: xxxxxxxxxxxxxxxx

    ┬───

    │ GC Root: Global variable in native code

    │

    ├─ android.database.ContentObserver$Transport instance

    │    Leaking: UNKNOWN

    │    ↓ ContentObserver$Transport.mContentObserver

    │                                ~~~~~~~~~~~~~~~~

    ├─ com.google.android.gms.ads.omid.library.devicevolume.a instance

    │    Leaking: UNKNOWN

    │    ↓ a.d

    │        ~

    ├─ com.google.android.gms.ads.omid.library.internal.h instance

    │    Leaking: UNKNOWN

    │    ↓ h.c

    │        ~

    ├─ com.google.android.gms.ads.omid.library.internal.a instance

    │    Leaking: UNKNOWN

    │    ↓ a.b

    │        ~

    ├─ java.util.ArrayList instance

    │    Leaking: UNKNOWN

    │    ↓ ArrayList.elementData

    │                ~~~~~~~~~~~

    ├─ java.lang.Object[] array

    │    Leaking: UNKNOWN

    │    ↓ Object[].[1]

    │               ~~~

    ├─ com.google.android.gms.ads.omid.library.adsession.a instance

    │    Leaking: UNKNOWN

    │    ↓ a.a

    │        ~

    ├─ com.google.android.gms.ads.omid.library.adsession.c instance

    │    Leaking: UNKNOWN

    │    ↓ c.b

    │        ~

    ├─ com.google.android.gms.ads.internal.webview.ab instance

    │    Leaking: UNKNOWN

    │    mContext instance of com.google.android.gms.ads.internal.webview.ax, not wrapping activity

    │    View#mParent is set

    │    View#mAttachInfo is null (view detached)

    │    View.mWindowAttachCount = 0

    │    ↓ ab.N

    │         ~

    ├─ com.google.android.gms.ads.internal.util.bt instance

    │    Leaking: UNKNOWN

    │    ↓ bt.a

    │         ~

    ╰→ com.xxxx.yyyy.PlayModeSelectionActivity instance

    ​     Leaking: YES (ObjectWatcher was watching this because com.xxxx.yyyy.PlayModeSelectionActivity received Activity#onDestroy() callback and Activity#mDestroyed is true)

    ​     key = xxxxxxxxxxxxxxxxx

    ​     watchDurationMillis = 31264

    ​     retainedDurationMillis = 25940

[Mobile Ads SDK Forum Advisor Prod]

Hi Pablo,

Thank you for opening an old case. I tested our sample banner app on a Xiaomi M1 A2 running Android 10 and every turn averages 1 mb extra in native in Android Profiler. The memory didn't go down after garbage collection. I turned the app 30 times and got almost 30 megabytes of memory added to Native. This is the extreme torture test I subjected the app to. As a side note, the device wouldn't change configurations automatically and I was prompted if I wanted to, which is a feature that I like. Could you elaborate on your use case?

Kind regards,
Aryeh Baker
Mobile Ads SDK Team

ref:_00D1U1174p._5004Q20ZPJU:ref

[Pablo Alfonso]

Hi Aryeh,

Not sure what you mean by "the memory didn't go down after garbage collection". Maybe AdView is a lightweight object, not consuming too much memory on its own and if you are running a "Sample" app, probably you will not notice any move in the memory "level". However, the problem appears when you cannot destroy a heavy activity because this adView is leaking.  When using Memory Profiler, did you check the "Activity/Fragment Leaks" checkbox? This checkbox should appear right below your memory graph. Also, did you run it with "LeakCanary"?

Just add this line to the build.gradle to test with LeakCanary:

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

Anyways, I tried all solutions discussed in stackoverflow forums and all other Google forums. The memory leaks appear to be erratic (one day works, another day does not work, one activity is fine, other activity produces memory leaks, etc.).  The only thing I know is that if I remove this line from the code, the memory leak disappears:

mAdView = findViewById(R.id.adView);

Believe me on this. I have been chasing memory leaks in my app for over a month now and I'm completely sure of this. Remove the adview and there is no memory leak. Add the ads, and there is memory leak.

Most probable cause: Is AdView defining an internal variable with STRONG reference holding onto the contexts (i.e. the Activity) causing a leak on the Activity instance??? <<<   I strongly recommend to your team to review this possible cause.  The line in the LeakCanary report seems to be pointing to this cause:  " mContext instance of com.google.android.gms.ads.internal.webview.ax, not wrapping activity"

Remember that we are also working in a similar memory leak issue for RewardedAd in this other thread:

https://groups.google.com/forum/#!category-topic/google-admob-ads-sdk/android/lPGZq54z53g

The only thing (WORKAROUND, no SOLUTION) that is working for me is to contain the memory leak in one single activity (and I applied a similar workaround to contain memory leaks for RewardedAd) as described in the following steps:

First recommendation: Do NOT add the adview directly to the XML layout file. If you follow the instructions from the official documentation (https://developers.google.com/admob/android/banner) that will lead to memory leak FOR SURE. Instead, add the adview programatically:

1. Remove the adview from the XML file:

   <RelativeLayout
       xmlns:ads="http://schemas.android.com/apk/res-auto"
       android:id="@+id/RLadViewContainer"
       android:layout_width="match_parent"
       android:layout_height="50dp"
       >
   
   
        <com.google.android.gms.ads.AdView  <<< REMOVE IT
            android:id="@+id/adView"   <<< REMOVE IT
            android:layout_width="wrap_content"    <<< REMOVE IT
            android:layout_height="wrap_content"    <<< REMOVE IT
            android:layout_centerHorizontal="true"   <<< REMOVE IT
            android:layout_alignParentBottom="true"    <<< REMOVE IT
            ads:adSize="BANNER"                     <<< REMOVE IT
            ads:adUnitId="@string/banner_ad_unit_id">    <<< REMOVE IT
         </com.google.android.gms.ads.AdView>     <<< REMOVE IT
   
    </RelativeLayout>

2. Then define a RelativeLayout variable (adscontainer) in your activity next to the mAdView:

     private AdView mAdView;
     private RelativeLayout adscontainer; 

3. In OnCreate, remove your old mAdView assignment and replace it with the following:

       adscontainer = findViewById(R.id.RLadViewContainer);
       mAdView = new AdView(MainActivity.MemoryLeakContainerActivity);//THIS IS THE TRICK ;)
       mAdView.setAdSize(AdSize.BANNER);
       mAdView.setAdUnitId(getResources().getString(R.string.banner_ad_unit_id));
       adscontainer.addView(mAdView);
       RelativeLayout.LayoutParams lp = (RelativeLayout.LayoutParams) mAdView.getLayoutParams();
       lp.addRule(RelativeLayout.CENTER_HORIZONTAL);
       lp.addRule(RelativeLayout.ALIGN_PARENT_BOTTOM);
       mAdView.setLayoutParams(lp);
       RequestConfiguration requestConfiguration = new RequestConfiguration.Builder()
               .setTestDeviceIds(Constants.testDevices)
               .build();
       MobileAds.setRequestConfiguration(requestConfiguration);
       AdRequest adRequest = new AdRequest.Builder().build();
       mAdView.loadAd(adRequest); //Move this line to the right place, wherever you need.

   Note: This will display the banner at the bottom with CENTER_HORIZONTAL and ALIGN_PARENT_BOTTOM options.

4. In onDestroy(), add the following:

     if (mAdView != null){
          mAdView.setAdListener(null);
          adscontainer.removeAllViews();
          adscontainer = null;
          mAdView.destroy(); 
          mAdView = null;               
         }

5. Now, lets talk about this "MainActivity.MemoryLeakContainerActivity": YES, you have to sacrifice one of your activities to contain the memory leak. I did not find any other way. I tried "getApplicationContext()" here and it did not work. So I have chosen my MainActivity for two reasons:

   a- In my app (match4app) the MainActivity works as a simple menu with three buttons ("Play", "Review Decks" and "Create Decks"). It is not consuming too much memory, there is no need to destroy it as most of the onBackPressed() tasks in my app lead the flow to the menu and it will be in the memory forever anyways.

   b- It is the very first Activity to be loaded. Hence, the adview will be always ready and available for the other activities.

6. In the MainActivity (or the activity that you choose to contain the memory leak), add the following at the bottom:

   public static MainActivity MemoryLeakContainerActivity;
   public MainActivity() {
       super();
       if (MemoryLeakContainerActivity != null) {
       throw new IllegalStateException("MemoryLeakContainerActivity is already created");
       }
       MemoryLeakContainerActivity = this;
   }

7. Thats it! No more memory leaks in my app! LeakCanary reports are clean.

I have posted this workaround in the stackoverflow forum: https://stackoverflow.com/a/62431520/5394986

Important: This is a WORKAROUND, not a SOLUTION. The SOLUTION should come from GOOGLE only. If we have to redefine the issues with the ads in two words, the following would be the sentence:

          

                  The"mAdView.destroy()" is not doing its job and for RewardedAd there is not even a "Destroy" method.







Regards,

-Pablo.


[Mobile Ads SDK Forum Advisor Prod]

Hi Pablo,

Thank you for offering a solution to leaking AdViews, your description of heavy activities that when leaked cause crashes and your recommendation that we look into Adview having a possible strong reference to the activity it's attached to. I tested the sample banner example with leak canary as you suggested and found leaks after a few orientation changes. When I created what you suggested - a second activity to have ads and the main activity to be static with 2 additional important things:

• adding in the manifest for main activity "android:configChanges="orientation"" so that main activity survives configuration changes - otherwise when there is a configuration change while in main activity the app will crash because Android will attempt to make a new instance of static main activity
• when returning to main activity from ads activity kill the ads activity with finish() because you cannot create a new main activity with an intent because it still exists hence causing a crash

After all those modifications no matter how many times I went from portrait mode to landscape mode there were no leaks recorded by Leak Canary. I hope that your solution is a robust one for your use case and for anyone else who implements it.

Regarding Activity/Fragment Leaks in profiler, I had tried it many times without success, while Leak canary showed me the leaks on the first try.

When I had mentioned that Native memory didn't go down I meant that Native memory usage went up in size without going down and continued to climb the more I changed device orientation.

I will be bringing your findings to the rest of the team. We will get back to you when we have more information.

[Pablo Alfonso]

Hi Aryeh, 

Thanks. In my case, working with one single instance with MainActivity works like a charm for three reasons:

1. In my MainActivity I'm not allowing Landscape orientation, so I set this in the manifest file:   android:screenOrientation="portrait"

2. I never execute finish() on the MainActivity.

3. For all activities returning to the MainActivity, for example in onBackPressed(), I execute this method:

     private void finishMyActivity(){

        Intent intent = new Intent(this, MainActivity.class);

        intent.addFlags(Intent.FLAG_ACTIVITY_REORDER_TO_FRONT); 

        startActivity(intent);

        finish();

      }

NOTE: There is another alternative suggested by other user (with a lot of upvotes) in StackOverflow. Instead of using an existing Activity as the container of the memory leaks generated by Google, this user suggested to create an "empty" activity as the container. Please check the details here:

https://stackoverflow.com/questions/9558708/admob-memory-leak-avoiding-by-using-empty-activity   (Check the "Update 2 3/6").

Regards,

-Pablo.

[Mobile Ads SDK Forum Advisor Prod]

Hi Pablo,

I work along with Aryeh. Thank you for the additional context. I could see that this has been raise to the team. We'll update this thread the soonest we have our findings.

Regards,
Teejay Pimentel

[omkar pawar]

Please consider this issue for all Ad Types, 

Banner

Interstitial

Interstitial Video

Rewarded Video

Native Advanced

Native Advanced Video

I have been trying to solve this issue , and recently came across this thread, I am testing with Interstitial and Adaptive Banners , memory leak happens in both of them as well 

regards

[Mobile Ads SDK Forum Advisor Prod]

Hi Omkar,

Thank you for providing your input on this issue. Could you describe in business terms and in technical terms how this affects you so that my team can get a better picture of your concerns?

Kind regards,
Aryeh Baker

[omkar pawar]

I am trying the code provided in the sample app for Adaptive banners

this is the heap dump , from leak cannery

┬───
│ GC Root: System class
│
├─ com.google.android.gms.ads.nonagon.a class
│    Leaking: NO (a class is never leaking)
│    ↓ static a.T
│               ~
├─ com.google.android.gms.ads.nonagon. a instance
│    Leaking: UNKNOWN
│    ↓ a.M
│        ~
├─ anl instance
│    Leaking: UNKNOWN
│    ↓ anl.c
│          ~
├─ com.google.android.gms.ads.internal.js.function.j instance
│    Leaking: UNKNOWN
│    ↓ j.c
│        ~
├─ com.google.android.gms.ads.internal.js.au instance
│    Leaking: UNKNOWN
│    ↓ au.f
│         ~
├─ com.google.android.gms.ads.internal.js.at instance
│    Leaking: UNKNOWN
│    ↓ at.a
│         ~
├─ com.google.android.gms.ads.internal.util.future.i instance
│    Leaking: UNKNOWN
│    ↓ i.a
│        ~
├─ aaq instance
│    Leaking: UNKNOWN
│    ↓ aaq.value
│          ~~~~~
├─ com.google.android.gms.ads.internal.js.w instance
│    Leaking: UNKNOWN
│    ↓ w.a
│        ~
├─ com.google.android.gms.ads.internal.webview.x instance
│    Leaking: UNKNOWN
│    mContext instance of com.google.android.gms.ads.internal.webview.ax, not wrapping activity
│    View#mParent is null
│    View#mAttachInfo is null (view detached)
│    View.mWindowAttachCount = 0
│    ↓ x.a
│        ~
├─ com.google.android.gms.ads.internal.webview.ab instance
│    Leaking: UNKNOWN
│    mContext instance of com.google.android.gms.ads.internal.webview.ax, not wrapping activity
│    View#mParent is set
│    View#mAttachInfo is null (view detached)
│    View.mWindowAttachCount = 0
│    ↓ ab.n
│         ~
├─ com.google.android.gms.ads.internal.webview.am instance
│    Leaking: UNKNOWN
│    ↓ am.b
│         ~
├─ java.util.HashMap instance
│    Leaking: UNKNOWN
│    ↓ HashMap.table
│              ~~~~~
├─ java.util.HashMap$HashMapEntry[] array
│    Leaking: UNKNOWN
│    ↓ HashMap$HashMapEntry[].[0]
│                             ~~~
├─ java.util.HashMap$HashMapEntry instance
│    Leaking: UNKNOWN
│    ↓ HashMap$HashMapEntry.value
│                           ~~~~~
├─ java.util.concurrent.CopyOnWriteArrayList instance
│    Leaking: UNKNOWN
│    ↓ CopyOnWriteArrayList.elements
│                           ~~~~~~~~
├─ java.lang.Object[] array
│    Leaking: UNKNOWN
│    ↓ Object[].[0]
│               ~~~
├─ com.google.android.gms.ads.internal.js.v instance
│    Leaking: UNKNOWN
│    ↓ v.a
│        ~
├─ com.google.android.gms.ads.nonagon.ad.activeview.b instance
│    Leaking: UNKNOWN
│    ↓ b.a
│        ~
├─ com.google.android.gms.ads.nonagon.ad.activeview.e instance
│    Leaking: UNKNOWN
│    ↓ e.c
│        ~
├─ com.google.android.gms.ads.nonagon.ad.activeview.j instance
│    Leaking: UNKNOWN
│    ↓ j.c
│        ~
├─ java.util.HashSet instance
│    Leaking: UNKNOWN
│    ↓ HashSet.backingMap
│              ~~~~~~~~~~
├─ java.util.HashMap instance
│    Leaking: UNKNOWN
│    ↓ HashMap.table
│              ~~~~~
├─ java.util.HashMap$HashMapEntry[] array
│    Leaking: UNKNOWN
│    ↓ HashMap$HashMapEntry[].[0]
│                             ~~~
├─ java.util.HashMap$HashMapEntry instance
│    Leaking: UNKNOWN
│    ↓ HashMap$HashMapEntry.key
│                           ~~~
├─ com.google.android.gms.ads.internal.webview.x instance
│    Leaking: UNKNOWN
│    mContext instance of com.google.android.gms.ads.internal.webview.ax, not wrapping activity
│    View#mParent is set
│    View#mAttachInfo is null (view detached)
│    View.mWindowAttachCount = 0
│    ↓ x.mContext
│        ~~~~~~~~
├─ com.google.android.gms.ads.internal.webview.ax instance
│    Leaking: UNKNOWN
│    ax does not wrap an activity context
│    ↓ ax.a
│         ~
╰→  
com.sample.testapp.mainactivity instance
​     Leaking: YES (ObjectWatcher was watching this because com.sample.testapp.mainactivity received Activity#onDestroy() callback and Activity#mDestroyed is true)
​     key = d72b533a-f164-4087-a878-68613e9eeada
​     watchDurationMillis = 5624
​     retainedDurationMillis = 595

METADATA

Build.VERSION.SDK_INT: 23
Build.MANUFACTURER: Micromax
LeakCanary version: 2.3
App process name: com.sample.testapp
Analysis duration: 160420 ms

The way to reproduce the code is to rotate the activity a few times or , open the activity from the previous activity a few times

[Mobile Ads SDK Forum Advisor Prod]

Hi Omkar,

I work along with Aryeh. Thank you for the additional context. I've relayed the information to the team for further investigation. I'll get back to you the soonest we have our findings.

Regards,
Teejay Pimentel

[Mobile Ads SDK Forum Advisor Prod]

Hi Pablo and Omkar,

Could you confirm if you get a leak when only rotating the device after the ad shows?

Kind regards,
Aryeh Baker

[Pablo Alfonso]

Hi Aryeh, 

I do not know. I just received an email from Google AdMob with the following message: 

"Google AdMob ad serving has been restricted to your app".

The only changes I'm doing in the app is just to solve this SPECIFIC Memory Leak issue and to assist you to solve this critical GOOGLE bug with the ads.

Can you please assist to remove this restriction in Match4app so I can continue with the testing that you are asking me to do?

Thanks,

-Pablo.

[Mobile Ads SDK Forum Advisor Prod]

Hi Pablo,

As a general rule, you will want to use test ad units (or enable a test device) when testing ads during development or debugging. Since limited ad serving is more of an account-related concern than a technical one, I would advise that you forward that particular concern to the AdMob Help Center for further assistance.

As for the original issue at hand, could you check if you would be able to continue investigating via enabling a test device or using our test ad unit ids?

Regards,
Teejay Pimentel

[omkar pawar]

It happens both times even before ad loads and after, 

Just a thought though There is some issue with context 

I have referred to this (I think Admob requires getApplicationContext() for both 

new AdView(getApplicationContext()); 

new InterstitialAd(getApplicationContext())); 

and MobileAds.initialize(getApplicationContext()),"ca-app-pub-3940256099942544~3347511713");)

 the leaks reduce but do happens some times

https://stackoverflow.com/questions/33509371/adview-causes-memory-leak/35121180#35121180

The issue seems to exist if we have both Adaptive ads and Interstitial ads in same activity

(I Am using Google Mobile Ads SDK: 19.2.0) 

[Mobile Ads SDK Forum Advisor Prod]

Hi Omkaw,

Thank you for the additional context. Could you please give more details on what you meant by the issue happens some times? Is the issue triggers on a specific creative?

Regards,
Teejay Pimentel

[omkar pawar]

To reproduce the error , Create a first activity(with a button, to open  secondactivity,(which contains interstitial ad and Adaptive banner) ), once we open the second activity , 3/4 times it causes memory leak

[Pablo Alfonso]

Hi Teejay, 

Thank you. My ads have been restored and I can continue with testings.

I agree with the steps suggested by Omkar. You have to create two activities to reproduce the memory leak. In my case it is happening with AdView (com.google.android.gms.ads.AdView).

Navigate back and forth between the two activities several times and you will see the increase in the number of instances. 

Note: For your testcase remember to finish the activity every time you invoke the other activity with "finish()".

I also agree with the intermittency of the issue: It is not happening in 100% of the cases. For example, if you access 10 times to the second activity, you won't see exactly 10 instances. Probably, you will see 4 or 5 instances.

What I know for sure is that after using the app for one week, there will be a lot of instances consuming a lot of memory.

Thanks,

-Pablo.

[omkar pawar]

 this is the code I am trying

For First Activity

import android.content.Intent;
import android.os.Bundle;
import android.view.View;
import android.widget.Button;

import androidx.annotation.Nullable;
import androidx.appcompat.app.AppCompatActivity;

public class FirstActivity extends AppCompatActivity {
 @Override
 public void onCreate(@Nullable Bundle savedInstanceState) {
 super.onCreate(savedInstanceState);
 setContentView(R.layout.firstact);
 Button clickButton = (Button) findViewById(R.id.clickButton);
 clickButton.setOnClickListener( new View.OnClickListener() {

 @Override
 public void onClick(View v) {
 Intent myIntent = new Intent(FirstActivity.this, MyActivity.class);

 FirstActivity.this.startActivity(myIntent);
 }
 });
 }
}

[omkar pawar]

 and for Second Activity

public class MyActivity extends AppCompatActivity {

 private static final String AD_UNIT_ID = "ca-app-pub-3940256099942544/9214589741";
 private FrameLayout adContainerView;
 private AdView adView;
 private static final long GAME_LENGTH_MILLISECONDS = 3000;
 private static final String AD_UNIT_ID1 = "ca-app-pub-3940256099942544/1033173712";

 private InterstitialAd interstitialAd;
 private CountDownTimer countDownTimer;
 private Button retryButton;
 private boolean gameIsInProgress;
 private long timerMilliseconds;

 @Override
 protected void onCreate(Bundle savedInstanceState) {
 super.onCreate(savedInstanceState);
 setContentView(R.layout.activity_my);


 // Initialize the Mobile Ads SDK.
 // Set your test devices. Check your logcat output for the hashed device ID to
 // get test ads on a physical device. e.g.
 // "Use RequestConfiguration.Builder().setTestDeviceIds(Arrays.asList("ABCDEF012345"))
 // to get test ads on this device."
 MobileAds.initialize(this, new OnInitializationCompleteListener() {
 @Override
 public void onInitializationComplete(InitializationStatus initializationStatus) {}
 });

 MobileAds.setRequestConfiguration(
 new RequestConfiguration.Builder().setTestDeviceIds(Arrays.asList("ABCDEF012345")).build());
 adContainerView = findViewById(R.id.ad_view_container);
 // Since we're loading the banner based on the adContainerView size, we need to wait until this
 // view is laid out before we can get the width.
 adContainerView.post(new Runnable() {
 @Override
 public void run() {
 loadBanner();
 }
 });
 interstitialAd = new InterstitialAd(getApplicationContext());
 // Defined in res/values/strings.xml
 interstitialAd.setAdUnitId(AD_UNIT_ID1);
 interstitialAd.setAdListener(new AdListener() {
 @Override
 public void onAdLoaded() {
 Toast.makeText(MyActivity.this, "onAdLoaded()", Toast.LENGTH_SHORT).show();
 }

 @Override
 public void onAdFailedToLoad(int errorCode) {
 Toast.makeText(MyActivity.this,
 "onAdFailedToLoad() with error code: " + errorCode,
 Toast.LENGTH_SHORT).show();
 }

 @Override
 public void onAdClosed() {
 startGame();
 }
 });
 // Create the "retry" button, which tries to show an interstitial between game plays.
 retryButton = findViewById(R.id.retry_button);
 retryButton.setVisibility(View.INVISIBLE);
 retryButton.setOnClickListener(new View.OnClickListener() {
 @Override
 public void onClick(View view) {
 showInterstitial();
 }
 });
 startGame();
 }

 /**
 * Called when leaving the activity
 */


 private void loadBanner() {
 // Create an ad request.
 adView = new AdView(getApplicationContext());
 adView.setAdUnitId(AD_UNIT_ID);
 adContainerView.removeAllViews();
 adContainerView.addView(adView);
 AdSize adSize = getAdSize();
 adView.setAdSize(adSize);

 AdRequest adRequest = new AdRequest.Builder().build();

 // Start loading the ad in the background.
 adView.loadAd(adRequest);
 }

 private AdSize getAdSize() {
 // Determine the screen width (less decorations) to use for the ad width.
 Display display = getWindowManager().getDefaultDisplay();
 DisplayMetrics outMetrics = new DisplayMetrics();
 display.getMetrics(outMetrics);
 float density = outMetrics.density;
 float adWidthPixels = adContainerView.getWidth();
 // If the ad hasn't been laid out, default to the full screen width.
 if (adWidthPixels == 0) {
 adWidthPixels = outMetrics.widthPixels;
 }
 int adWidth = (int) (adWidthPixels / density);
 return AdSize.getCurrentOrientationAnchoredAdaptiveBannerAdSize(this, adWidth);
 }
 // Create the InterstitialAd and set the adUnitId.


 private void createTimer(final long milliseconds) {
 // Create the game timer, which counts down to the end of the level
 // and shows the "retry" button.
 if (countDownTimer != null) {
 countDownTimer.cancel();
 }
 final TextView textView = findViewById(R.id.timer);
 countDownTimer = new CountDownTimer(milliseconds, 50) {
 @Override
 public void onTick(long millisUnitFinished) {
 timerMilliseconds = millisUnitFinished;
 textView.setText("seconds remaining: " + ((millisUnitFinished / 1000) + 1));
 }

 @Override
 public void onFinish() {
 gameIsInProgress = false;
 textView.setText("done!");
 retryButton.setVisibility(View.VISIBLE);
 }
 };
 }

 private void showInterstitial() {
 // Show the ad if it's ready. Otherwise toast and restart the game.
 if (interstitialAd != null && interstitialAd.isLoaded()) {
 interstitialAd.show();
 } else {
 Toast.makeText(this, "Ad did not load", Toast.LENGTH_SHORT).show();
 startGame();
 }
 }

 private void startGame() {
 // Request a new ad if one isn't already loaded, hide the button, and kick off the timer.
 if (!interstitialAd.isLoading() && !interstitialAd.isLoaded()) {

 AdRequest adRequest = new AdRequest.Builder().build();

 interstitialAd.loadAd(adRequest);
 }
 retryButton.setVisibility(View.INVISIBLE);
 resumeGame(GAME_LENGTH_MILLISECONDS);
 }

 private void resumeGame(long milliseconds) {
 // Create a new timer for the correct length and start it.
 gameIsInProgress = true;
 timerMilliseconds = milliseconds;
 createTimer(milliseconds);
 countDownTimer.start();
 }

 @Override
 public void onPause() {
 if (adView != null) {
 adView.pause();
 }
 countDownTimer.cancel();
 super.onPause();
 }

 /**
 * Called when returning to the activity
 */
 @Override
 public void onResume() {
 super.onResume();
 if (adView != null) {
 adView.resume();
 }
 if (gameIsInProgress) {
 resumeGame(timerMilliseconds);
 }
 }

 /**
 * Called before the activity is destroyed
 */
 @Override
 public void onDestroy() {
 if (adView != null) {
 adView.destroy();
 }
 super.onDestroy();
 }
}


Note For Adaptive banners I have used test ad units ca-app-pub-3940256099942544/9214589741 provided in sample app

https://github.com/googleads/googleads-mobile-android-examples/blob/master/java/admob/AdaptiveBannerExample/app/src/main/java/com/google/android/gms/example/adaptivebannerexample/MyActivity.java

and for Interstitial I have used  ca-app-pub-3940256099942544/1033173712

I have used the same code provided in sample apps except that I have merged both the Interstitial and Adaptive Activity 

[Mobile Ads SDK Forum Advisor Prod]

Hi Omkar,

I looked over your code and it looks like a you are going from one activity to another to create the leak. In my testing Pablo's suggestion earlier in the thread I created an app that does just that but with a banner ad. I found that if I wait for the ad to appear before destroying the activity then there's no leak. When I destroy the activity before the ad shows then I can get a leak. Can you confirm this with your testing?

Kind regards,
Aryeh Baker

[Mobile Ads SDK Forum Advisor Prod]

Hi Pablo,

Thank you for the testing. What I have seen in my testing is that when I wait for ad to appear before destroying the activity then no leak occurs but if I destroy the activity before the ad appears there's a high likelihood that there will be a leak. Can you try this on your end too?

Kind regards,
Aryeh Baker
Mobille Ads SDK Team

ref:_00D1U1174p._5004Q20ZPJU:ref

[omkar pawar]

We tested as you said with the code from 

https://github.com/googleads/googleads-mobile-android-examples/blob/master/java/admob/AdaptiveBannerExample/app/src/main/java/com/google/android/gms/example/adaptivebannerexample/MyActivity.java

with just the adaptive banners, we noticed, if the Ad is not loaded there is a memory leak, less chance of a memory leak if Ad is Loaded, As you Said 

However there should be no Memory leak even if Ad is loaded or not, (Please check Interstitial Ads also, as they require larger memory compared to other ad formats)

Regards

Omkar

[Mobile Ads SDK Forum Advisor Prod]

Hi Omkar,

Thank you for sharing your findings. It's odd that you're also getting a memory leak using our sample apps. Could you share what device are you using? Also, would it be possible for you to provide a memory profiler capturing the behavior?

Regards,
Teejay Pimentel

[omkar pawar]

I have tested it on a micromax tablet 

this is the result

PS  there were issues for Aryeh Baker 

check this

https://groups.google.com/d/msg/google-admob-ads-sdk/9IyjqdmeumM/stFWyoXpAgAJ

[Mobile Ads SDK Forum Advisor Prod]

Hi Omkar,

Could you share the Android version  of the Micromax tablet that you mentioned as well? Once sent, I will raise this information (including all reports and discussion thus far) to the team for further investigation.

[omkar pawar]

Build.VERSION.SDK_INT: 23
Build.MANUFACTURER: Micromax
LeakCanary version: 2.3
App process name: com.sample.testapp

[Mobile Ads SDK Forum Advisor Prod]

Hi Omkar,

Thank you for the testing and for showing us your environment and your results. I will be sharing them with the rest of my team and I will bring up the ads that take a while to load as being more of an issue. One thing I would like clarification on is you mentioned that if the ad shows first then there are less leaks. Do you have a way of reliably reproducing the leak after the ad shows?

Kind regards,
Aryeh Baker

[omkar pawar]

unfortunately no, I tried again, seems like if the ad loads, there are no leaks, However, If there are no ads, there is a memory leak. 

At least that is confirmed (from your side as well?) hope that issue is resolved,unfortunately I am the single developer(with other development work pending for me), may be a test (on your side with a larger group of testers may give better results)

few scenarios I have thought which might be useful for testing

1) check for leaks when phone is rotated(ad not loaded)

2) check for leaks when phone is rotated(ad loaded)

3) check for leaks (current scenario activity is destroyed before ad loads)(ad not loaded)

4) check for leaks (current scenario activity is destroyed but ad loads)

5) check for leaks when for larger ad formats (Interstitial ads)phone is rotated(ad not loaded)

6) check for leaks when for larger ad formats (Interstitial ads)phone is rotated(ad loaded)

7) check for leaks larger ad formats (Interstitial ads) (current scenario activity is destroyed before ad loads)(ad not loaded)

8) check for leaks larger ad formats (Interstitial ads) (current scenario activity is destroyed but ad loads)

9) check for leaks when for larger ad formats (Interstitial ads)and other ad format (banner ads) phone is rotated( either or both ad not loaded)

10) check for leaks when for larger ad formats (Interstitial ads)and other ad format (banner ads) phone is rotated(ad loaded)

11) check for leaks larger ad formats (Interstitial ads) and other ad format (banner ads)  (current scenario activity is destroyed before ad loads)(either or both ad not loaded)

12) check for leaks larger ad formats (Interstitial ads) and other ad format (banner ads) (current scenario activity is destroyed but ad loads)

these might help your team. also try other scenarios that you can think of 

Regards

Omkar

[Mobile Ads SDK Forum Advisor Prod]

Hi Omkar,

Once again thank you for your efforts - especially because you are a one man team. I personally tested Pablo Alfonso's unsupported workaround that was described in this thread and couldn't find any leaks and I understand you want a supported, less prone to leaking ad. I have also tested our sample banner ad and found that if I destroy the activity before the ad shows then there's a high possibility of a leak. I will bring the weight of your concern and the limited resources you have to deal with it to the rest of my team and we will get back to you the soonest we have more actionable information.

[Pablo Alfonso]

Hi Aryeh, 

Thank you. I noted that you have reproduced the issue internally and this is good progress!!

Unfortunately, I'm a single developer too and as I noted before I had to deal with Policy team to restore my ads just after implementing my workaround and moving it to Production.

I'm not longer experiencing memory leaks after implementing the workaround and after getting the approval from policy team. 

So I hope you will understand that with this situation, I'm not willing to proceed with further testings here. I was just trying to help Google here without any other interest.

But I agree that the "intermittency" of the issue is most likely related to the event that you noted before: If you leave the activity BEFORE showing the ad, chances of memory leaks are higher.

Another comment about the workaround:  Though this is working perfectly for me, I don't think this is a realistic approach for anyone, due to the number of required changes and level of expertise required to implement it.

Indeed, if you check the thread in StackOverflow, you will note that it is not getting good acceptance from the community:

https://stackoverflow.com/questions/33509371/adview-causes-memory-leak/62431520#62431520

Hope you can provide the fix soon and if this bug is solved by Google, I hope this will qualify, at least, for the Bug Bounty Reward program.

Regards,

-Pablo.

[Mobile Ads SDK Forum Advisor Prod]

Hi Pablo,

Thank you for the effort you put in until now and for your feedback on your workaround and for more context on how this affects developers. I passed this information on to the rest of my team and will get back to you the soonest we have more actionable information.

[omkar pawar]

Any udapte guys whats the status, how soon can this issue be resolved 

On Saturday, April 30, 2011 at 7:08:48 AM UTC+5:30, Rico Yao wrote:

After implementing the latest 4.0.4 SDK, I noticed that I started
leaking activities.  I took HPROF dumps and analyzed with Eclipse
Memory Analyzer and found that the offending reference is the AdMob
weview.

My implementation is fairly straightforward, following the developer's
guide.  I load an ad in onCreate() and I call
admobAdView.stopLoading() in onDestroy().

I thought maybe I had an implementation bug, so I took the demo app
from the docs (http://dl.google.com/googleadmobadssdk/examples/android-
banner-details.zip) and I found the same leak there.  All I had to do
was load up the demo app with my adUnitId and then rotate the device a
bunch of times after each banner advert is loaded.  Trigger a GC
through DDMS, take an HPROF dump and you will find that an instance of
the com.google.ads.example.BannerDetails activity has leaked for every
single rotation.  Once again, it's the webview that causes it.

Appreciate any advice.  Thanks!

[Mobile Ads SDK Forum Advisor Prod]

Hi Omkar,

We are still looking into the issue and will get back to you the soonest we have actionable information.

[Nghĩa Nguyễn]

I had the same problem, tried many ways but could not solve it.

[omkar pawar]

Is there any work around that we can use(acceptable to admob policies) , until a proper solution is found, 

[Mobile Ads SDK Forum Advisor Prod]

Hi Omkar,

I've asked the team for their insight and a workaround to this. I'll let you know once they provide their feedback.

Regards,
Teejay Pimentel

[Mobile Ads SDK Forum Advisor Prod]

Hi there,

Please be informed that the team is aware of this, and the issue is currently under investigation. We'll update this thread the soonest we have our findings.

[omkar pawar]

Please update example for Adaptive banner For Android 11 (SDK Version 30) 

getwindowmanager().getdefaultdisplay() and display.getMetrics are deprecated 

[Mobile Ads SDK Forum Advisor Prod]

Hi Omkar,

Thank you for bringing this deprecation to our attention. I changed the getAdSize function like this:

 private AdSize getAdSize() {
   // Determine the screen width (less decorations) to use for the ad width.
  // Display display = getWindowManager().getDefaultDisplay();
   DisplayMetrics outMetrics = this.getResources().getDisplayMetrics();
//   display.getMetrics(outMetrics);

and it seems to work if compiled and run on an

targetSdkVersion 29

machine. The ad gets slightly cut off on the right side though. When the targetSdkVersion is 30, ads failed to load with error code 0. 

Since these beta errors are a different issue from the original issue in this thread I am creating a new thread in the forum here - https://groups.google.com/forum/#!searchin/google-admob-ads-sdk/api$2030%7Csort:date/google-admob-ads-sdk/dDZ8tNmyClc/TPvuSoatAwAJ. If you want to pursue this issue further please continue on that thread so that we can focus on the original concern in this thread.

Thanks,
Aryeh Baker
Mobile Ads SDK Team

ref:_00D1U1174p._5004Q20ZPJU:ref

[omkar pawar]

any update guys

[Mobile Ads SDK Forum Advisor Prod]

Hi there,

 

Thank you for following-up on this thread.

 

My colleague (Aryeh) created a separate thread for this issue and I can also see that you've made a follow-up on that thread. Let's continue the discussion on that thread instead to better track this issue.

 

Regards,

Mark Albios

Mobile Ads SDK Team

ref:_00D1U1174p._5004Q22aE7q:ref

[omkar pawar]

I know about the other thread , I am asking about the original issue  the title of this this thread "Memory Leak: AdMob webviews cause activities to leak", has there been any update about that issue.

I have checked stackoverflow , it seems to be an issue for a long time(8-10years), 

I came across this , https://groups.google.com/d/msg/google-admob-ads-sdk/9IyjqdmeumM/x1cqPeuDAAAJ

In this particular thread itself, can we use this as a workaround

If not what is the possible solution , I am waiting for this to launch a new app

 regards

[Mobile Ads SDK Forum Advisor Prod]

Hi Omkar,

There was confusion about your last post because the post right before your last post was talking about the issue that a new thread was made for. I looked in the trailing part of your email and found where you were continuing from. I will ask again where this issue is holding with the rest of my team and we will get back to you as soon as we have more information.

Kind regards,
Aryeh Baker

[omkar pawar]

I have tested the new Admob using  "Latest version of the Google Mobile Ads SDK: 19.3.0"

https://developers.google.com/admob/android/sdk

I have also used the new 

• Added getDomain() and getCause() methods to AdError.
• Added new load failure callbacks to all ad formats that return a LoadAdError. E.g., onAdFailedToLoad(LoadAdError).

the memory leak still occurs, the error is not caught at all, (getDomain and getCause dont catch the error in onAdFailedToLoad)

 In order to replicate the error,  Create a first activity(with a button, to open  secondactivity,(which contains interstitial ad and Adaptive banner) ), once we open the second activity,by going from the first activity , 3/4 times it causes memory leak, the memory leak only happens if no ad is loaded in the second activity and we go back the first activity , (try this 3/4 times and the memory leak occurs).

I think it s an issue related to webview , something discussed here

https://stackoverflow.com/questions/9558708/admob-memory-leak-avoiding-by-using-empty-activity

https://android.developreference.com/article/25081688/Admob+Memory+Leak+-+avoiding+by+using+empty+activity

https://www.reddit.com/r/androiddev/comments/cj8ip9/googleandroidgmsads_causing_memory_leaks/

 

https://groups.google.com/forum/#!topic/google-admob-ads-sdk/Oxt2fpxVmwk/discussion

This memory leak causes ANR and shows the dialog of app not responding, do you want to wait or close the app

the using empty activity solution seems to work, though I have not tested It.as discussed here 

https://groups.google.com/d/msg/google-admob-ads-sdk/9IyjqdmeumM/x1cqPeuDAAAJ

and 

https://android.developreference.com/article/25081688/Admob+Memory+Leak+-+avoiding+by+using+empty+activity

Can we use it in our app, 

Can this be part of the SDK provided by Google itself,

I have noticed the same error in various apps available on Google play store

the same error memory leak , to  replicate the error, open an activity 3/4 times without allowing the ad to load, casuing ANR and dialog asking to close the app

Please find a solution soon,

Its affecting a lot of apps and I also want to implement Admob in my app(hopefully without errors)

 regards

[Mobile Ads SDK Forum Advisor Prod]

Hi Omkar,

 

Thank you for providing an update on your concern.

 

I will be adding your comments to the bug report that we currently are monitoring regarding this issue, in order to help with the investigation. It would also be helpful if you could kindly provide an actual sample project (via Reply privately to author), replicating this issue, in order to further help on this.

 

With that said, you may adopt the "empty activity" workaround at your own risk if you wish to, as this is a community-contributed workaround that we will not be able to officially endorse at the moment. Rest assured that I've added that particular topic to the bug report as well, so that we may be able to glean new insights from it.

 

Regards,

Ziv Yves Sanchez

[omkar pawar]

Hi, @Ziv Yves Sanchez, This issues was discussed earlier, with Aryeh Baker and Teejay Pimentel from the Admobs Sdk team

If you go through this thread I had shared the code, device info, memory leak heap dump earlier, 

these are the links

code

for first activity

https://groups.google.com/d/msg/google-admob-ads-sdk/9IyjqdmeumM/keu7rxV5AgAJ

and

https://groups.google.com/d/msg/google-admob-ads-sdk/9IyjqdmeumM/glGDtoGqAgAJ

and for Second activity

https://groups.google.com/d/msg/google-admob-ads-sdk/9IyjqdmeumM/ysJ4dYB5AgAJ

the Device Info

https://groups.google.com/d/msg/google-admob-ads-sdk/9IyjqdmeumM/kl6TRYPAAgAJ

Leak canary heap dump

https://groups.google.com/d/msg/google-admob-ads-sdk/9IyjqdmeumM/tjHMgAwcAgAJ

Aryeh Baker from your team was able to reproduce the error

https://groups.google.com/d/msg/google-admob-ads-sdk/9IyjqdmeumM/stFWyoXpAgAJ

I had confirmed it, with Aryeh Baker, if the ad is not loaded and the activity is destroyed, it causes memory leak

I know this is an old issues with various developers mentioning it in this and various other forums 

https://groups.google.com/d/msg/google-admob-ads-sdk/9IyjqdmeumM/lLNUuvsoAgAJ

I came across this and have been waiting for past 2 months for it be resolved soon, 

@Ziv Yves Sanchez , you can confirm with Aryeh Baker and Teejay Pimentel  , about the code that I have shared earlier and the leak canary heap dump. hope that might help.

I still think its an webview related issue as mentioned here

https://groups.google.com/d/msg/google-admob-ads-sdk/Oxt2fpxVmwk/gPuAuPh6EQAJ 

PS: please go through this whole thread and have a look at the complete thread that I have shared just above. 

regards

[Mobile Ads SDK Forum Advisor Prod]

Hi Omkar,

I reviewed your list of discussions about this memory leak and none of your links show a link to a full blown project sample that you want to present, just code. While I created a project internally to demonstrate when a leak occurs, we would like to see how this issue affects your use case in real world terms, wether business wise or programming effort wise combined with a sample project. It is almost always advisable when presenting an issue to present a sample project that reflects your use case preferably built on our sample apps with minimum extra code necessary combined with steps to reproduce the concern that reflects what is going on with your users. The only difference in this case is we in general know the steps to reproduce a leak and what the outcome in Leak Canary looks like. Note that I never succeeded in crashing the app that I made.

Kind regards,
Aryeh Baker

[omkar pawar]

Thanks for the reply, I will share the app code, apk and the Video of the crash , as soon as possible

[omkar pawar]

I had privately messaged the code, crash video heap dump and logs, can you please confirm you have received it , is it being tested 

also I am testing on a low end device,1 gb RAM, which is normal for my country, please test it on such devices, most often we get a crash on them 

On Monday, August 3, 2020 at 8:03:02 PM UTC+5:30, mobileadssdkforumadvisor wrote:

[Mobile Ads SDK Forum Advisor Prod]

Hi Omkar,

We wasn't able to received your message privately. Could you kindly upload the files on your Google Drive, then share an access to mobileads...@gmail.com instead? Kindly let us know here once this is done.

Regards,
Teejay Pimentel

[omkar pawar]

Hi, Teejay Pimentel, 

I had PM the code, crash video, Heap dump to Aryeh Baker, I have done it to you As well, can you please confirm 

 

Regards, Omkar 

[Mobile Ads SDK Forum Advisor Prod]

Hi Omkar,

I received the video, memory leak dump and the modified Adaptive Banner sample. I ran your app and was able to make a memory leak with unnatural use of the app. I didn't succeed in crashing your app. Could you elaborate on how this affects your users during normal use of your app? Do you have any statistics from Crashlytics or any other source of data on this?

Kind regards,
Aryeh baker

[omkar pawar]

Hi, Aryeh baker 

Thanks for the Reply, and thanks for testing the code.

Unfortunately you were not able to crash the app, that seems to be a specific problem for low end devices (about which I had mentioned  earlier).

I had mentioned earlier I am not using it in any of my apps currently, so I cannot present you with any crashlytics data, however I had shared with you the crash log of this app 

In case you have not received it I will PM it to you again. I dont really know what is the issue, that causes the app to have a ANR error and then it stops working..

hope you can have a  look at it and get some insight. 

Can you specify , if you tested it on a low end device (1 GB RAM etc)  (may be a real device with other apps installed and working and all, not an emulator)

we may generally assume normal usage of the app, but in certain cases (as is common in my country) , it takes time to load an Ad, due to poor internet connectivity also most users have low end devices, so often we end up getting those ANR errors,making it difficult for developers to come up with a proper solution. 

Regards

Omkar

[Mobile Ads SDK Forum Advisor Prod]

Hi Omkar,

Thank you for presenting the need for a fix. I didn't test on a low powered device. I relayed your presentation of low connectivity and low powered devices combining to make ad loading times long, thus creating the bigger probability of a user causing leaks that end up in crashes, and the crash log, to the rest of my team. We will get back to you when we have more information.

Kind regards,
Aryeh Baker

[omkar pawar]

hi, Aryeh Baker

Thanks, for the update, hope you guys find a solution soon,

Regards

Omkar

[omkar pawar]

Hi, Aryeh Baker

I have used ANR-WatchDog to log the errors that cause ANR for the apps

https://github.com/SalomonBrys/ANR-WatchDog

I have PM  2 log files to you with the errors.Please have a look, hope it will help you please confirm you have received the files 

(I noticed one thing, when we first clean install the app(i.e. it was not previously installed and then we install it for the first time) the ANR watchdog generated the error not on subsequent installations from Android Studio, however there was a memory leak on each occasion and it was recorded by Leak canary)

Regards

Omkar

On Wednesday, August 5, 2020 at 11:34:10 PM UTC+5:30, mobileadssdkforumadvisor wrote:

[Mobile Ads SDK Forum Advisor Prod]

Hi Omkar,

This is to confirm that we received your message privately. Thank you for this. Let me relay this to the team for further investigation. We'll let you know once they provide their feedback.

Regards,
TeejayPimentel
DCM API Team

ref:_00D1U1174p._5004Q22aE7q:ref

[omkar pawar]

While using Interstitial ads I got this error, using ANR-WatchDog to log the errors that cause ANR for the apps

https://github.com/SalomonBrys/ANR-WatchDog

Caused by com.github.anrwatchdog.ANRError$$$_Thread: main (state = RUNNABLE)

       at com.google.android.gms.dynamic.RemoteCreator.getRemoteCreatorInstance(:4)
       at com.google.android.gms.internal.ads.zzva.zza(com.google.android.gms:play-services-ads-lite@@19.3.0:5)
       at com.google.android.gms.internal.ads.zzvz.zzpo(com.google.android.gms:play-services-ads-lite@@19.3.0:7)
       at com.google.android.gms.internal.ads.zzwf.zzqb(com.google.android.gms:play-services-ads-lite@@19.3.0:29)
       at com.google.android.gms.internal.ads.zzwf.zzd(com.google.android.gms:play-services-ads-lite@@19.3.0:52)
       at com.google.android.gms.internal.ads.zzys.zza(com.google.android.gms:play-services-ads-lite@@19.3.0:40)
       at com.google.android.gms.ads.InterstitialAd.loadAd(com.google.android.gms:play-services-ads-lite@@19.3.0:9)
       at com.sample.testapp.onCreate(MyActivity.java:89)
       at android.app.Activity.performCreate(Activity.java:6309)
       at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1113)
       at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2519)
       at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2654)
       at android.app.ActivityThread.-wrap11(ActivityThread.java)
       at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1488)
       at android.os.Handler.dispatchMessage(Handler.java:111)
       at android.os.Looper.loop(Looper.java:207)
       at android.app.ActivityThread.main(ActivityThread.java:5728)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:789)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:679)

It is the same code used in the Admob Interstitial Example 

I am not using "com.google.android.gms:play-services-ads-lite" still it shows an error 

I am using

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

[omkar pawar]

A Important issue is, Suppose we have, an app with 4-5 activities, ie say a mainactivity has 3  buttons each open 3 different activities, now each activity has an Ad, and suppose every time the ad doesnot load, then each activity has a memory leak, all this adds up and then there is a ANR.   

[omkar pawar]

Please read my previous 3 Comments also

also when we test the apps 

use

if (BuildConfig.DEBUG) {
    StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
            .detectDiskReads()
            .detectDiskWrites()
            .detectNetwork()
            .detectAll() //for all detectable problems
            .penaltyLog()
            .build());
    StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
            .detectLeakedSqlLiteObjects()
            .detectLeakedClosableObjects()
            .detectActivityLeaks()
            .detectAll()
            .penaltyLog()
            .penaltyDeath()
            .build());
}

[Mobile Ads SDK Forum Advisor Prod]

Hi Omkar,

Thank you for sharing your investigation findings. I've relayed this information to the team as well. We'll update this thread the soonest I have any information regarding to investigation.

Regards,
Teejay Pimentel
Mobile Ads SDK Team

ref:_00D1U1174p._5004Q22aE7q:ref

[p_al...@yahoo.com]

Any solution for the main issue discussed in this thread?

[Mobile Ads SDK Forum Advisor Prod]

Hi there,

Thank you for your patience on this. Our team is currently investigating this issue. I've also made a follow up for this.

We'll be updating this thread for any updates from the team.

Regards,

Mark Kevin Albios Mobile Ads SDK Team

ref:_00D1U1174p._5004Q22aE7q:ref

[Mobile Ads SDK Forum Advisor]

Hi All,

I hope you're doing well.

I just want to circle back on this. Can you privately provide the below information?

• Complete stack trace when ANR/memory issues happen on rotation
• Screenshots of Memory Profiler that show memory usage for the activities/fragments that cause potential leaks

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=5004Q000022aE7qQAE&entry.80707362=00042710
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._5004Q22aE7q:ref