Help needed:AdMob continues to run after app screen is destroyed!?

[3c]

Once my app activity is destroyed (onDestroy()), it seems that the
adMob sdk continues to run and eat CPU time on its own...

I can see those type of messages every 10 seconds in the app! Didn't
see this issue until I download my app from the Market! The APK
installed by Eclipse never showed this!?

NEW_PICTURE_MSG_ID
webkitDraw NEW_PICTURE_MSG_ID
webkitDraw start
WEBKIT_DRAW arg1...

and those lines repeat 3 or 4 times per seconds in the worse case!!!

Can anyone tell me how to stop AdMob when all my app activities are
closed!!!!

Thanks in advance for any hint/help/response

[Adrien Béraud]

I have this problem too, in different conditions.

I develop a game, and the ad shows up when the game is paused or at the end of a level, and is hidden with View.GONE during the game itself.
This is done so we can show the ad faster, since the player probably won't stay more than a few seconds in those situations.

I also call ad_view.stopLoading() when the game starts so the ad won't continue to refresh in the background (when the ad is shown, I call ad_view.loadAd(new AdRequest()) if ad_view.isReady() is false).

But apparently, in some cases (when the ad is a text ad ?), the WebKit thread continues to eat CPU every few seconds, and causes the game to lag, which is annoying.

[3c]

In version 4.0.4, it was mandatory to use code so I did use loadAd()
in oncreate() and stopLoading() in ondestroy()...
Well this bug occurred all the time. Now in 4.1.0 it can be added in
Xml, and it seems less frequent, but still occurs!

That's a real problem, no other way than revert back to the old AdMob
SDK which has no issue whatsoever, but doesn't offer support for
tablets, which I just implemented!

If I find anything useful, I'll post here!

[3c]

I'm currently testing this in every activity of my app:

@Override
protected void onDestroy()
{
AdView av = (AdView)findViewById(R.id.adView);
if (av != null)
av.destroy();
super.onDestroy();
}

Seems ok so far.

[Damjan]

Yup, calling adview.destroy(); solves at least two issues with this
sdk.

[3c]

Well, just found out it's not enough to do that in onDestroy(), it
must be done in onPause(), and for Android 1.5, the view must also be
removed from its parent otherwise the app crashes on exit! Testing the
following:

@Override
protected void onPause()

{
AdView av = (AdView)findViewById(R.id.adView);
if (av != null)

{
Log.w(bmw_data.TAG, "bmw_full_graph destroying ad view");
((ViewGroup)av.getParent()).removeView(av);
av.destroy();
}
super.onPause();
}

[wes]

Are you destroying your adView in the activity's onDestroy?  What about in onPause?  Finally, what make/model phone, version of Android, and version of our SDK are you using?

Cheers,

Wes

[3c]

Hello and sorry for the late reply... didn't see it.

I'm using v4.1.0, the latest and I'm checking regularly for new
updates! I'm now destroying the AdView in onPause, and creating it
manually in onResume for all my screens... Seems ok now. But I'm very
worried about the revenue being cut'off because of that?

I have a Galaxy S, Optimus 2X and a Iconia A500. Saw this issue on all
3!

Since I switched to the v4.x, I seem to have more and more issues
being reported in the dev console! I'm seriously thinking about moving
back to the original AdMob SDK, but it lacks the banner ads for
tablets!

Should I post those here or create a new message?

For example the last crash I received is this (I'm sure it's AdMob as
I don't have any WebView in my app):

android.database.sqlite.SQLiteException: error code 14: unable to open
database file
at android.database.sqlite.SQLiteStatement.native_execute(Native
Method)
at
android.database.sqlite.SQLiteStatement.execute(SQLiteStatement.java:
55)
at android.database.sqlite.SQLiteDatabase.execSQL(SQLiteDatabase.java:
1772)
at android.webkit.WebViewDatabase.removeCache(WebViewDatabase.java:
670)
at android.webkit.CacheManager.getCacheFile(CacheManager.java:342)
at android.webkit.LoadListener.checkCache(LoadListener.java:739)
at android.webkit.FrameLoader.handleCache(FrameLoader.java:344)
at android.webkit.FrameLoader.handleHTTPLoad(FrameLoader.java:227)
at android.webkit.WebViewWorker.handleMessage(WebViewWorker.java:124)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:123)
at android.os.HandlerThread.run(HandlerThread.java:60)

[3c]

Hello again,

I'm actually very worried because since I've updated my app to work-
around this issue (3 days ago), there is no more AdSense revenue being
added to my AdMob revenue as it used to be the previous days... This
account for 25% of my revenue!

Is there any new update planned to fix those issues?

Also note that my 2 apps using adMob both have services running in the
background, so it's unacceptable for my users that those apps starts
consuming the CPU/battery like that!

Could this be a reason for the issue, having services in the
background?

[3c]

I've upgraded to the SDK 4.1.1 and the reports are getting worse!

Just got 2 comments about the app continuing to run and dramatically
using the CPU (80%)!

Also noticed a huge amount of crash reports in the WebView classes. As
I'm not using any web views whatsoever, it's obviously coming from the
SDK!!!

Are you planning an urgent fix for all those new issues? Or should I
move back to the old AdMob SDK which was working flawlessly!

I need an answer urgently, please.

[SPA Support]

Have you tried adView.stopLoading() in the onPause() or onStop()
method of your activity? You will need to restart the AdView once the
activity starts or resumes. You should surround it with a try/catch in
case it has an error

Then call adView.destroy() and set adView = null in the activity's
onDestroy(). Again, use try/catch... just in case. You do not need to
do any error processing, but you don't want the app to crash just
because the AdView has a cleanup problem.

Although the SDK should probably handle this (and a few other things),
since it's your app, doing the cleanup is a good idea regardless of
who "should" do it.

Also, unless you leak the adView to your service, it should not end up
anywhere outside of your activity/activities. Since your service
should not load an XML file or inflate views (there is no UI), that
should not be a problem. It should be easy to check (in most cases,
service level communication is through Intents, but using
startService() with a service object that, for some reason, has your
activity (or specifically the AdView) would cause a leak - most
likely, though, you would see a different error because it would try
to modify the UI from a non-UI thread).

4.1.0 works pretty well. We're still trying to get comfortable with
4.1.1 (which, like most code, fixes some issues but introduces new
ones, as discussed in other threads).

Good luck!

-Jim

[3c]

Thanks a lot for your response!

I've just added the stopLoading() before the destroy(), so that should
remove the NullPointerException I received a few times.

The only thing I pass to my service is the context, which can be an
activity (as it is a context in the first place). Never used to have
any issues, but here is how it is used:

static public void StartService(Context context)
{
if (service_intent == null)
service_intent = new Intent(context, bmw_service.class);

context.startService(service_intent);
}

Tried service_intent = new Intent(); but then the service does not
start.

Could this be causing AdMob to continue running in the background?
With the newly added stopLoading(), that should prevent any further
problems and CPU consumption, right?

[Cedric Counotte]

Thanks a lot for your response!

I've just added the stopLoading() before the destroy(), so that should
remove the NullPointerException I received a few times.

As I'm about to release an update with this fix, may I ask you one more
question before I do:

The only thing I pass to my service is the context, which can be an activity

(as it is a context in the first place). Didn't used to have any issues, but

here is how it is used:

static public void StartService(Context context)
{
if (service_intent == null)
service_intent = new Intent(context, bmw_service.class);
context.startService(service_intent);
}

Tried service_intent = new Intent(); but then the service does not start.

Could this be causing AdMob to continue running in the background?

With the newly added stopLoading(), that should prevent any further problems
and CPU consumption, right?

Thanks for your support, much appreciated!
Cedric.

-----Message d'origine-----
De : google-adm...@googlegroups.com
[mailto:google-adm...@googlegroups.com] De la part de SPA Support
Envoyé : vendredi 5 août 2011 19:34
À : google-adm...@googlegroups.com
Objet : Re: Help needed:AdMob continues to run after app screen is
destroyed!?

Good luck!

-Jim

-----
Aucun virus trouvé dans ce message.
Analyse effectuée par AVG - www.avg.fr
Version: 10.0.1391 / Base de données virale: 1518/3812 - Date: 05/08/2011

[SPA Support]

The stopLoading() should stop the background process and the
CPU/battery problems. However, just because you hit "home" or leave
the screen, that does not mean onDestroy() is called - you should
probably put it in onPause() or onStop(). Check the logcat - but
depending on your emulator settings, it may call onDestroy() faster
than a real device. (And don't put adView.onDestroy() in onPause() or
onStop() unless you plan to re-create it when the activity starts
again.)

Passing the activity context will not leak the AdView. We do that in
some places and don't have a problem.

-Jim

[Cedric Counotte]

Thanks a lot!

I do all the clean-up in onPause, and recreate each time, less nice but when
I was doing the clean-up in onStop() I could see the SDK continuing to run
(hitting home or not) when switching between multiple screens. As if the
onResume() was creating a new view without the previous one being cleaned
during onPause().

I haven't been able to reproduce the CPU/battery issue within the emulator
or my devices for a while, though I just received reports of the issue
occurring again.

Hopefully the stopLoading() will fix it for good!

Thanks for your time,
Cedric.

-----Message d'origine-----
De : google-adm...@googlegroups.com
[mailto:google-adm...@googlegroups.com] De la part de SPA Support

Envoyé : vendredi 5 août 2011 20:53

[Cedric Counotte]

Hello again, hope you receive my mail, because I still need your assistance
solving the many issues being reported with stopLoading() crashing
frequently!

The crash report is below. Here is the code I use to do the manual clean-up
during onPause() of any of my activities, following your previous
suggestions:

public static void detachAdView(Activity parent)
{
AdView av = (AdView)parent.findViewById(R.id.adView);
if (av != null)
{
ViewGroup parentView = (ViewGroup)av.getParent();

try
{
av.stopLoading();
}
catch(Exception e)
{
}

parentView.removeView(av);

try
{
av.destroy();
}
catch(Exception e)
{
}
}
}

Here is the crash report:

java.lang.NullPointerException
at android.webkit.WebView.stopLoading(WebView.java:2026)
at c$a.run(Unknown Source)
at android.os.Handler.handleCallback(Handler.java:587)
at android.os.Handler.dispatchMessage(Handler.java:92)
at android.os.Looper.loop(Looper.java:143)
at android.app.ActivityThread.main(ActivityThread.java:4196)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:507)
at
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:8
39)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)
at dalvik.system.NativeStart.main(Native Method)

Thanks for any advice you may provide, as this is becoming an issue, users
complaining about the stability of the app!

Regards,
Cedric.

[Jim]

I don't think your code is the offending code. It is probably related
to this:

http://groups.google.com/group/google-admob-ads-sdk/browse_thread/thread/1f79640c499bbabc

It's in the SDK.

In another thread, AdMob said they hoped to have an SDK fix out last
week, then this week. I think they're working on the Adsense revenue
reporting "bug" so maybe it will be next week. This is our biggest
error right now (more than all our native app code errors combined; we
have a Google Analytics "out of memory" error that is about the same
as this one, in terms of reports).

-Jim

[Cedric Counotte]

Thanks for your reply! Much appreciated, will wait for the update.

When you mention the 'Adsense reporting bug', is it affecting this 4.1.1
release? I seem to have lost Adsense revenue since the 14/08.

Anyway, shit happens I'm the first to know that...

[ Unfortunately the Android one-way comment system is not helping dev, but
frustrated users release their anger. I'm not sure a 2-way communication
will help but increase the angry exchanges between users-devs. A
limited-1-time-2-way communication might help though. ]

[Jim]

Yes, the Aug 14 date seems to be the same for everyone. Read this
thread:

http://groups.google.com/group/google-admob-ads-sdk/browse_thread/thread/7cc1c1beef0d7dc5

it links to another thread of the same sort. I believe the reporting
error is independent of the SDK (4.x.x or prior). Essentially, they
are working on the problem (and we have seen some corrections as of
yesterday, with more this morning). They are devoting their time to
that, apparently. That seems like a good use of time to me.

I like to think about them like a mechanic - do I want to lean over
and ask the mechanic lots of questions, or just let him finish the
job? Of course, AdMob's job is more complex in many ways than engine
repair, but regardless, the more questions I ask, the less money I
have (mechanics bill by the hour) and I'm not going to start
maintaining either system any time soon, so I really don't need to
know all the details... so it helps with my patience. I guess the
appropriate analogy would be something like "I'm a car mechanic and
they are plane mechanics" because we all work on engines, and even
though some of the parts are similar, they aren't the same engines and
they don't work the same way.

-Jim

On Sep 1, 8:33 am, "Cedric Counotte" <ccouno...@gmail.com> wrote:
> Thanks for your reply! Much appreciated, will wait for the update.
>
> When you mention the 'Adsense reporting bug', is it affecting this 4.1.1
> release? I seem to have lost Adsense revenue since the 14/08.
>
> Anyway, shit happens I'm the first to know that...
>
> [ Unfortunately the Android one-way comment system is not helping dev, but
> frustrated users release their anger. I'm not sure a 2-way communication
> will help but increase the angry exchanges between users-devs. A
> limited-1-time-2-way communication might help though. ]
>
> Regards,
> Cedric.
>
>
>
>
>
>
>
> -----Original Message-----
> From: google-adm...@googlegroups.com
>
> [mailto:google-adm...@googlegroups.com] On Behalf Of Jim
> Sent: jeudi 1 septembre 2011 15:28
> To: Google AdMob Ads Developers
> Subject: Re: Help needed:AdMob continues to run after app screen is
> destroyed!?
>
> I don't think your code is the offending code. It is probably related to
> this:
>

> http://groups.google.com/group/google-admob-ads-sdk/browse_thread/thr...

[Cedric Counotte]

Good to know I'm not the only one. Just saw many adjustments this morning...
Doesn't look complete, but that'll do anyway.

Thanks again for patiently explaining the situation.

[3c]

Hello,

After more investigation, it appears the stopLoading() doesn't prevent
AdMob from registering to some specific system events, even after the
app activity has been destroyed!!!

I still see those messages in logcat:

13:33:20.750 <<my_activity_class_here>>@xxx onDestroy, 0ms

13.33.32.470 >>com.google.ads.util.AdUtil
$UserActivityReceiver@40581ce8 onReceive:Intent
{ act=android.intent.action.SCREEN_OFF flg=0x40... }, tid=20940
13.33.32.470 >>com.google.ads.util.AdUtil
$UserActivityReceiver@40581ce8 onReceive, 1ms

13.33.33.770 >>com.google.ads.util.AdUtil
$UserActivityReceiver@40581ce8 onReceive:Intent
{ act=android.intent.action.USER_PRESENT flg=0x20... }, tid=20940
13.33.33.770 >>com.google.ads.util.AdUtil
$UserActivityReceiver@40581ce8 onReceive, 11ms

So every time I switch off the screen and back on, it wastes a minimum
of 12ms! even when my activities are not in the foreground!!!
My app is a monitoring app and wasting 12ms is quite unacceptable!

Here is the last comment found on Market today:

<< Constantly turning itself on in the background. System tuner?
Or system detuner? Uninstalled. 1* >>


How can I fix this or work-around this? In this scenario the app is
not running any service or anything whatsoever!
After install, just opening the main activity and then closing it is
enough to start getting these messages!


Please tell me you can help!

[staycee xtacy]

Hi!
Maybe you cant't stop admob since it never was instantiated or was already removed. Ive encountered the same problem but admob's doc says you should use only its destroy method. Just dont use stopLoading they have error there (unchecked NPE).

[Cedric Counotte]

Well I know that, see posts above to actually use stopLoading()! I did receive some NPE on stopLoading(), but none comes from the call I added! 

If I don't start any activity, there is no AdMob activity: as expected.

But when all activities have ceased (onDestroy() called on all of them), there should not be anything left, not considering I called both stopLoading() and destroy()! 

But AdMob seems to register to USER_PRESENT and SCREEN_OFF, ok it helps load/unload ads depending on whether the app screen will be visible! But this should be unregistered once the activity is gone! It's not! 

Just another bug... hope it gets fixed in next update along the NPE fix!

2011/9/6 staycee xtacy <xtac...@gmail.com>

[staycee xtacy]

Im using System.exit(0). ive found that my app could be stopped only this way due to admob's bugs. Im in the same situation admob hangs in RAM and not allowing my app to finish properly (maybe you already had read my topic about it).

[SPA Support]

It looks like that might be a standard onReceive for an ad that was in
process before onDestroy was called. Does it happen repeatedly?

It looks like they missed an explicit call to unregister the receiver
during stopLoading or onDestroy. Is that what you are saying is the
bug? I would think that Android GC would stop leaks, so it's really a
hit miss type situation, right?

Try adding this to your code above, after av.destroy()

av = null;

Also, make sure you do that to all references to the AdView you might
have elsewhere in the Activity. I have seen an explicit null reduce GC
time, if that is the problem here.

-Jim

--
Thanks,
SPA Support

[staycee xtacy]

i did null it with no result. please take a look at my topic

[staycee xtacy]

Also I suggest you to try rotating ur dev (to make layout to change/reload/rebuild) with admob running app and trace how ur app grows up in RAM...

[Cedric Counotte]

Already implemented that way:

stopLoading() in a try/catch

destroy() in a try/catch

= null

In every activity's onPause()! Used to be in onDestroy() and things were even worse, AdMob was sometimes continuing to load Ads!

Now this is what I'm calling this a bug: no call to unregister()...

There's no leaking error message...

And the only way to solve this is to call System.exit() as pointed out by staycee xtacy.

I don't like this solution, because if users start the app later, it take much more time, it's no better performance wise.

Still the bug is reproduced consistently while the app doesn't have any service running nor any widget nor any notification!

And it seems the app is never terminated, nor is said to be 'empty' in the app importance flag!?

I will continue to search for some reference left over somewhere... But I'm 99% sure I don't have any reference to any AdMob objects!

I've attached my AdMob loader code, 2 static methods in a separate class I call from onResume(), onPause() of every activities with ads. Maybe you can spot something I didn't?

Note that on that particular line I once received a NPE: View already has a parent!!!

    flayout.addView(iv, new LayoutParams(LayoutParams.FILL_PARENT, px));

whereas iv is created a few lines above!?

2011/9/6 SPA Support <secondp...@gmail.com>

[Cedric Counotte]

Good idea, will do that now.

Already noted that every time the USER_PRESENT message is processed, used memory grows a little! Even though no activities are running!

2011/9/6 staycee xtacy <xtac...@gmail.com>

[Cedric Counotte]

Wow, thanks for the tip, just discovered the leak!

I have an activity that only have onCreate() to initialize it's stuff, then onPause() and onResume() are just there to add/remove the AdMob view itself!

So I used a monitoring app to watch memory consumption, open that particular activity, then long-press home to get back to monitoring app, then long-press again to go back to activity... Each time the app consumes around 512Kbytes more!!! I'm just talking about dirty/private memory here! Not RSS!!!

Will this be fixed in next update? Or did I put a bug in my app?

No wonder now why I received complaints about memory consumption (only with ads-based version!)

2011/9/6 staycee xtacy <xtac...@gmail.com>

[3c]

Not the problem, i do have the av = null in the code, this AdView is
only referenced in that piece of code anyway.

By the way, I know an update is coming (this week supposedly), do you
know if this issue will be resolved?