4.1.1 NullPointerException

[Markus Wiederkehr]

java.lang.NullPointerException
at android.webkit.WebView.stopLoading(WebView.java:1673)
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:123)
at android.app.ActivityThread.main(ActivityThread.java:4636)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:521)
at com.android.internal.os.ZygoteInit
$MethodAndArgsCaller.run(ZygoteInit.java:913)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:671)
at dalvik.system.NativeStart.main(Native Method)

This is now the #1 crash error in my app. Anything I can do other than
downgrade to 4.1.0?

[Eric Leichtenschlag]

Hey Markus,

I would recommend you follow the steps suggested here, mainly calling adView.stopLoading() and adView.destroy() in a try/catch.

Cheers,

Eric

[Markus Wiederkehr]

Thanks for replying, Eric.

The problem is that this particular invocation of stopLoading is not
triggered by my app at all. It must happen somewhere in the SDK
internally. My guess is that it happens during an automatic refresh.
One user left this message that would fit into this theory:
"unexpectedly quit in the middle of the game".

Please correct me if I miss something but since I do not call this
method directly I cannot surround this particular call with a try/
catch, can I?

Cheers,
Markus


On Aug 11, 1:51 am, Eric Leichtenschlag <eleichtens...@google.com>
wrote:
> Hey Markus,
>
> I would recommend you follow the steps suggested here<https://groups.google.com/forum/#!searchin/google-admob-ads-sdk/webvi...>,

[Eric Leichtenschlag]

Hey Markus,

Are you overriding the onDestroy method in your activity?  Something like:

@Override

public void onDestroy() {

    adView.destroy();

    super.onDestroy();

}

This should destroy the adView dispose of itself properly.  adView.destroy() takes care of the stopLoading() call, so you are correct in that you do not need to call it yourself.  Let me know if this works for you.

Cheers,
Eric

[Markus Wiederkehr]

Hi Eric,

Yes, I already do that. But as you can see from the stack trace
neither Activity.onDestroy() nor AdView.destroy() are directly
involved in the call that causes the NPE. In fact none of my app's
classes or methods are.

Instead the method gets called by a Handler. So my guess is that at
some point the SDK internally calls Handler.postDelayed passing a
Runnable that invokes stopLoading or something like that.

Cheers,
Markus


On Aug 11, 9:42 pm, Eric Leichtenschlag <eleichtens...@google.com>
wrote:

[Eric Leichtenschlag]

Hey Markus,

I spoke with the SDK developers, and unfortunately there is no workaround for publishers.  This is a known issue that will be addressed in the next release.

Thanks,

Eric

[dm1973]

Any chance we can get a quick SDK release with just the fix for this?
I am getting a lot of these (close to a thousand a day) and it is by
far the biggest crasher in my apps. I understand it is hard to find
these type of issues that only occur sporadically. But it is really
painful to have been waiting 3+ weeks now for a fix while my users
send me hate mail. I would have reverted to 4.1 except that had even
worse bugs.

On Aug 11, 5:22 pm, Eric Leichtenschlag <eleichtens...@google.com>
wrote:

[William Ferguson]

Eric, any idea when that update will be?

On Aug 12, 7:22 am, Eric Leichtenschlag <eleichtens...@google.com>
wrote:

[Eric Leichtenschlag]

There is no official release date, but we hope to push out an update by the end of next week.

Cheers,

Eric

[William Ferguson]

I hope so. This is affected 2% of my users and I have no way of
mitigating it.

On Aug 17, 11:21 am, Eric Leichtenschlag <eleichtens...@google.com>
wrote:

[Emanuel Moecklin]

Hi Eric

End of next week is tomorrow.
Any chance we'll indeed see a new release by then?

We'd very much appreciate it.

Thanks

Emanuel

[Eric Leichtenschlag]

Unfortunately the next version has been pushed back to sometime next week.

- Eric

[I.D.E.]

On my Android Market Developer Console, I've received my first "app
freeze" report.... caused by AdMob:

DALVIK THREADS:
(mutexes: tll=0 tsl=0 tscl=0 ghl=0 hwl=0 hwll=0)
"main" prio=5 tid=1 NATIVE
| group="main" sCount=1 dsCount=0 obj=0x40037180 self=0xd148
| sysTid=12150 nice=0 sched=0/0 cgrp=default handle=-1345004864
at android.database.sqlite.SQLiteStatement.native_1x1_long(Native
Method)
at
android.database.sqlite.SQLiteStatement.simpleQueryForLong(SQLiteStatement.java:
115)
at
android.database.sqlite.SQLiteDatabase.getVersion(SQLiteDatabase.java:
928)
at android.webkit.WebViewDatabase.getInstance(WebViewDatabase.java:
225)
at android.webkit.WebView.<init>(WebView.java:1071)
at android.webkit.WebView.<init>(WebView.java:1044)
at android.webkit.WebView.<init>(WebView.java:1034)
at android.webkit.WebView.<init>(WebView.java:1025)
at g.<init>((null):-1)
at d.a((null):-1)
at d.<init>((null):-1)
at com.google.ads.AdView.a((null):-1)
at com.google.ads.AdView.a((null):-1)
at com.google.ads.AdView.<init>((null):-1)
at java.lang.reflect.Constructor.constructNative(Native Method)
at java.lang.reflect.Constructor.newInstance(Constructor.java:415)
at android.view.LayoutInflater.createView(LayoutInflater.java:505)
at android.view.LayoutInflater.createViewFromTag(LayoutInflater.java:
570)
at android.view.LayoutInflater.rInflate(LayoutInflater.java:623)
at android.view.LayoutInflater.inflate(LayoutInflater.java:408)
at android.view.LayoutInflater.inflate(LayoutInflater.java:320)
at android.view.LayoutInflater.inflate(LayoutInflater.java:276)
at
com.android.internal.policy.impl.PhoneWindow.setContentView(PhoneWindow.java:
218)
at android.app.Activity.setContentView(Activity.java:1657)
at -------> My Activity: constructUi() : 259
at -------> My Activity: onCreate() :161
at
android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:
1047)
at
android.app.ActivityThread.performLaunchActivity(ActivityThread.java:
1650)
at
android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:
1702)
at android.app.ActivityThread.access$1500(ActivityThread.java:117)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:
949)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:123)
at android.app.ActivityThread.main(ActivityThread.java:3728)
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:864)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:622)
at dalvik.system.NativeStart.main(Native Method)

"WebViewCoreThread" prio=5 tid=10 MONITOR
| group="main" sCount=1 dsCount=0 obj=0x40536150 self=0x1984d0
| sysTid=12190 nice=0 sched=0/0 cgrp=default handle=1686504
at
android.webkit.WebViewDatabase.getInstance(WebViewDatabase.java:~181)
- waiting to lock <0x4052b980> (a java.lang.Class) held by
threadid=1 (main)
at android.webkit.CacheManager.init(CacheManager.java:178)
at android.webkit.BrowserFrame.<init>(BrowserFrame.java:250)
at android.webkit.WebViewCore.initialize(WebViewCore.java:226)
at android.webkit.WebViewCore.access$500(WebViewCore.java:63)
at android.webkit.WebViewCore$WebCoreThread
$1.handleMessage(WebViewCore.java:701)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:123)
at android.webkit.WebViewCore$WebCoreThread.run(WebViewCore.java:
720)
at java.lang.Thread.run(Thread.java:1019)

"RefQueu...@org.apache.http.impl.conn.tsccm.ConnPoolByRoute@40533b08"
daemon prio=5 tid=9 WAIT
| group="main" sCount=1 dsCount=0 obj=0x40536a58 self=0x1662e8
| sysTid=12158 nice=0 sched=0/0 cgrp=default handle=1467424
at java.lang.Object.wait(Native Method)
- waiting on <0x40535a50> (a java.lang.ref.ReferenceQueue)
at java.lang.Object.wait(Object.java:395)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:107)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:80)
at
org.apache.http.impl.conn.tsccm.RefQueueWorker.run(RefQueueWorker.java:
102)
at java.lang.Thread.run(Thread.java:1019)

"Binder Thread #3" prio=5 tid=8 NATIVE
| group="main" sCount=1 dsCount=0 obj=0x4052c298 self=0x77198
| sysTid=12157 nice=0 sched=0/0 cgrp=default handle=1631824
at dalvik.system.NativeStart.run(Native Method)

"Binder Thread #2" prio=5 tid=7 NATIVE
| group="main" sCount=1 dsCount=0 obj=0x4052a6c8 self=0x18a5a8
| sysTid=12156 nice=0 sched=0/0 cgrp=default handle=1726504
at dalvik.system.NativeStart.run(Native Method)

"Binder Thread #1" prio=5 tid=6 NATIVE
| group="main" sCount=1 dsCount=0 obj=0x40529308 self=0x12a5b8
| sysTid=12155 nice=0 sched=0/0 cgrp=default handle=1779472
at dalvik.system.NativeStart.run(Native Method)

"Compiler" daemon prio=5 tid=5 VMWAIT
| group="system" sCount=1 dsCount=0 obj=0x405253b0 self=0x1b18a8
| sysTid=12154 nice=0 sched=0/0 cgrp=default handle=1777376
at dalvik.system.NativeStart.run(Native Method)

"Signal Catcher" daemon prio=5 tid=4 RUNNABLE
| group="system" sCount=0 dsCount=0 obj=0x405252f0 self=0x162b08
| sysTid=12153 nice=0 sched=0/0 cgrp=default handle=1764528
at dalvik.system.NativeStart.run(Native Method)

"GC" daemon prio=5 tid=3 VMWAIT
| group="system" sCount=1 dsCount=0 obj=0x40525248 self=0x1b1da8
| sysTid=12152 nice=0 sched=0/0 cgrp=default handle=1533616
at dalvik.system.NativeStart.run(Native Method)

"HeapWorker" daemon prio=5 tid=2 VMWAIT
| group="system" sCount=1 dsCount=0 obj=0x40525190 self=0x1615b0
| sysTid=12151 nice=0 sched=0/0 cgrp=default handle=1651896
at dalvik.system.NativeStart.run(Native Method)


************************
Anyone else seen this?

[William Ferguson]

Eric, it's now the end of that week.
Any guidance of when this release will be ready?

I'm asking because by my calculations it's already pissed off about
30% of my users at least once.


On Aug 26, 10:00 am, Eric Leichtenschlag <eleichtens...@google.com>
wrote:

[Emanuel Moecklin]

I'm with Will.
Fortunately I didn't upgrade from 4.1.0 to 4.1.1 but I would still
like to get a fix for the ViewRoot$CalledFromWrongThreadException that
was supposedly fixed with 4.1.1 and which is my #1 cause for crashes
(several hundred crash reports).

Thanks
Emanuel

[3c]

+1, same here numerous crash reports (not to mentioned those crashes
not sent by users)... Getting a few very negative comments as well.

Anyway a date would be nice or at least let us know here when it's
available so we can download the update immediately. Tired of
downloading the SDK to check its version!


On 2 sep, 13:53, William Ferguson <william.ferguson...@gmail.com>
wrote:

[Eric Leichtenschlag]

I hate to be the bearer of bad news, but the new version will not be ready this week either.

We will definitely announce when the next version is released.  Also, the download page has version number next to the link that gets updated with the new version, so you shouldn't have to keep downloading the SDK to check the version.

- Eric, AdMob SDK Support

[SPA Support]

Eric,

Thanks for the update. We know you guys have been working on the
Adsense reporting issue. I think the messages here are to
re-iterate/re-emphasize our interest in this problem as well. I am
very eager for the update, as I have stated before. As much as you
guys have accomplished, it seems your work is never "done" - right?
The next question will be, "When will it be ready?" If only all
development were predictable enough to establish and meet deadlines...

P[lease keep the updates coming.

Also, for all the international developers out there - this is Labor
Day weekend in the US (Labor Day is Monday); expect your numbers to
look weird (maybe up, maybe down - or maybe the same... we are already
seeing the effect with lower requests than usual).

-Jim

--
Thanks,
SPA Support

[3c]

Hello Eric and thanks for the info... too bad, wouldn't like to have
to send such news myself!

I hope the update comes soon as I just realized the SDK not only
causes those crashes but:
1- leaks around 512Kbytes each time an activity is started!
2- consumes CPU even after all activities have been terminated!

Really very bad for business! To be truthful I don't understand why
you guys didn't release an intermediate update to fix the most urgent
issues?

Just want to emphasizes the urgency of an update! So, any estimated
date? A week would be ok, but a month might require removing AdMob
entirely!

On 2 sep, 22:58, Eric Leichtenschlag <eleichtens...@google.com> wrote:
> I hate to be the bearer of bad news, but the new version will not be ready
> this week either.
>
> We will definitely announce when the next version is released.  Also, the

> download <http://code.google.com/mobile/ads/download.html> page has version

[3c]

Hello guys, any news on the fix, this starts to look very very bad,
FYI, here are the crash reports about this on a single app, and
obviously that's only from users caring to report!

Please give some news on this!? Do you know how to fix this, or we're
on our own and should go back to an older version? If so, please
advise which one?

OTHER
22 rapports par semaine
92 rapports
Nexus One
1 rapports par semaine
2 rapports
Droid
1 rapports par semaine


2 sept. 2011 21:34:571.8.1R
28 août 2011 08:42:251.7.7poor
24 août 2011 11:58:321.7.7i switched off the phone while charging. At
next day I unplugged the cable and switched on the mobile, I pressed
on the widget and error shows up.
24 août 2011 11:57:151.7.7Crashed when receiving a call.
21 août 2011 18:41:551.7.6Crashed
18 août 2011 19:32:271.7.7Crashed loading estimates view
13 août 2011 18:10:171.7.6Started application 1 to 2 seconds after the
home screen appeared (after restarting the phone which had exhausted
battery charge)
10 août 2011 18:58:541.7.5why he crash every time

[Eric Leichtenschlag]

The next version will have this fixed, but there will be more updates going into the new release that is going to push a new version back until the week beginning the 19th.  I don't think older versions fix this problem either.

I understand your frustration that you've been waiting on a fix for this issue for a while now.  We are having discussions with the engineering team to figure out a plan for more frequent releases in the future when issues like these come up.

Eric, AdMob SDK Support

[William Ferguson]

Thanks Eric, appreciate the update.

For what it's worth, for issues like this where there is a large
ongoing impact, I for one would prefer a patch to an existing release
than waiting for a new one. I say this because it sounds like this new
release has been packaged up to contain some new/other functionality
and that means there is a reasonable chance that some of this new func
is broken is some way or another. So we might end up trading one bug
for another.

I just want a targeted fix for the pain my users are feeling.

I'm all for moving to newer releases / newer functionality, but I want
to make that choice, not be forced into it by the current bug.

William


On Sep 10, 6:31 am, Eric Leichtenschlag <eleichtens...@google.com>
wrote:

[William Ferguson]

Eric, can you provide any more info on when this will be released?

On Sep 10, 6:31 am, Eric Leichtenschlag <eleichtens...@google.com>
wrote:

[Eric Leichtenschlag]

The latest news is that the target release date is now next Monday, 9/26.

I'm pushing for more reliable release dates going forward because it just isn't right to lead you guys on like this.

Eric, AdMob SDK Support

[Emanuel Moecklin]

Hi Eric

I'm tired of waiting for the overdue fixes.
I'm lucky I didn't upgrade from 4.1.0 to 4.1.1 as the NPE was
introduced with 4.1.1, but I'm still stuck with all the "ViewRoot
$CalledFromWrongThreadException" and also the
"AndroidRuntimeException: Calling startActivity() from outside of an
Activity context requires the FLAG_ACTIVITY_NEW_TASK" crashes.

And yes I'm 99% positive that both crashes are caused by the Admob
4.1.0 code (with some underlying WebView issues):
1. I decompiled the Admob code and could point out the lines of code
causing the troubles (see my posts in other threads of this forum).
2. My paid versions show not a single one of these crashes. The only
difference between free and paid versions is the presence or absence
of ads. The number of installs for the paid versions is obviously
smaller than those for the free versions and you could argue that they
don't show because the number of installs is too small. But listen to
my next argument.
3. I moved one of my apps to a competing ad network a couple of month
back. So far I didn't get a single one of these crash reports even if
it's configured to backfill from the Admob network (no ads available -
> pull ad from Admob transparently). In fact I didn't get a single
crash report caused by this ad network's library! BTW the app I'm
talking about has more than 300'000 downloads so if there were an
issue it would certainly show up.
4. Many other developers using the Admob library are complaining about
the same crashes as well.

I have pushed back new releases because I was waiting for the new
Admob library but I won't wait longer than till next Monday.
I'm not afraid of moving to the other ad network because I'll get at
least the same revenue or even slightly more than with an Admob only
solution.
The reason for this is not that the other ad network has a much higher
CPC or CTR as some people claim (there are several articles claiming
to make much more with them than with Admob, but in my opinion these
are faked articles).
The real reasons are:
1. They allow backfilling from another ad network (like Admob).
2. They have a function called eCPMcontrol which allows setting a
minimum amount for CPC and CPM. This is a very useful function because
I can switch between two ad networks depending on the eCPM they
currently offer. If the revenue through Admob drops like it did the
last couple of days I configure the eCPMcontrol to show ads
independent of CPC or CPM. This way I get more ads from the competing
ad network and less of Admob's ads. If Admob's eCPM goes up I
configure the eCPMcontrol to show only expensive ads (like >=$0.10 or
>=$0.15). This way I get only the good paying ads from the competing
ad network and many Admob ads through the backfill option.

I'm not threatening to move away from Admob, I'm just considering my
options and I wanted Admob to understand that if a developer looks at
the facts there are good reasons to move:
1. More stable SDK (not a single crash for me and not a single library
update for month which is a good thing IMO)
2. As a consequence of point 1 you get less user complaints, less 1-
star ratings and you spend less time investigating possible causes for
the crashes (and less time writing posts in this forum)
3. Ability to increase the revenue by showing ads from more than one
ad network

Best Regards
Emanuel Moecklin
1gravity LLC

[Eric Leichtenschlag]

Hi Emanuel,

Thanks for the report.  There are some great datapoints here that I can use as fuel to articulate internally the importance of releasing on time.

I find it interesting but confusing that you are able to backfill AdMob and not receive these crashes.  Are you using some mediation solution where you need to to include the AdMob SDK?  How could the other network prevent our SDK from crashing if the bug is on our end?  Are you sure there are enough backfill requests to AdMob from the other network to statistically conclude that this other network can recover from AdMob crashes?

Also, can anybody using 4.1.1 confirm if the FLAG_ACTIVITY_NEW_TASK is still an issue?  I don't believe I have seen reports of this issue on 4.1.1.

Thanks,

Eric, AdMob SDK Support

[Jim]

Eric,

Thanks for the update. I can confirm the FLAG_ACTIVITY_NEW_TASK is
still an issue. I've had about 10 reports confirmed through Android
Market reporting this week. As discussed elsewhere, I'm sure this
means there are about 10 times that amount or more of actual crashes.
That does seem to be lower, but it definitely is still an active
issue. "stopLoading" is still the big winner at about 3 times that
rate.

I am also curious how any mediator can avoid the crashes. If so, I'd
be happy to sign up just to make them go away (and the guys and AdMob
can grab the code, decompile and copy it - not because they can't
figure it out, but because that's better than drinking 10 Red Bulls
every night for a week while you figure it out).

And thanks for reinforcing the message that timeliness and
communication are key issues with errors and updates. We have been
reluctant to do releases in the hopes of an update also. Many of our
users are exceptionally sensitive to frequent app updates. We'll gear
up for next week...

-Jim

On Sep 22, 1:10 pm, Eric Leichtenschlag <eleichtens...@google.com>
wrote:

[Eric Leichtenschlag]

Thanks Jim for confirming.  The "stopLoading" bug has been tracked and fixed.  I'm having the eng team take another look at FLAG_ACTIVITY_NEW_TASK to get resolved before the next release.

Cheers,

Eric, AdMob SDK Support

[Emanuel Moecklin]

Hi Eric

For whatever reasons my reply this afternoon didn't make it to the
board, so I'm rewriting the post...

I don't know exactly how this backfill works but it's completely
transparent from an app point of view.
They seem to load the Admob ads on server side and transform them into
their own format and send them to the publisher (that's why you have
to provide your Admob publisher id in your profile).
Their client side lib is the only lib you need, no additional Admob
lib.
I noticed that I get the "code update available" notification on the
Admob dashboard only for the Admob only apps but not the ones with
Admob backfill, so they seem to integrate new Admob libs pretty
quickly.

My numbers are conclusive.
Whenever I enable eCPMcontrol the requests on Admob side increase by
around 100'000/day. The increase of impressions is lower especially
this month because the fill rate seems to be worse than in previous
month but still higher than 50'000/day.
The changes in number of impressions are for sure due to the
eCPMcontrol changes. A similar Admob only app (same app category)
doesn't show these drastic changes (increase/decrease) but "only" the
normal fluctuation due to the number and quality of ads on Admob/
Advertiser side.
If the other ad library had the same issues it would certainly have
shown by now but so far I didn't get a single crash report related to
this SDK.

Best Regards
Emanuel Moecklin

[Eric Leichtenschlag]

Hey Emanuel,

You're previous email got sent to only me and not the group.  I was busier earlier and didn't have time to respond.

I suppose there is a possibility that we have an agreement with some other network that lets them pull ads from AdMob in a special way, but I am not familiar with any such agreement.  Clearly if the code update does not take place with this ad network than it is not using our code.  These crashes mentioned in this thread are issues that our SDK needs to clean up, regardless of the bugs being the SDK's fault directly, and thanks to your reports, they will be fixed when the next version comes out.  I'm hoping as much as you are that the release will in fact be on Monday.

[grndvl1]

Seems to me that I went through something similar with this when they
went from 4.0 to 4.1. Admob was crashing my app continuously and I
was getting hate mail for it when it was the internal libs of Admob.
I waited forever for them to come out with a new release but had to
wait with a ton of promise dates on release that went overtime due to
some of the new items added to 4.1. Well guess what when the new 4.1
came out it introduced new bugs ...ugh. I had to go into my code and
write some NDK stuff to override or just fix their horrendous
mistakes. Maybe they should do a little more debugging and test more
phones with these crappy libs before they make a release or do some
bug releases first before adding more garbage to the libs. +1 button
who cares just another thing to crash my app.

[Eric Leichtenschlag]

Just a fair warning that a Monday release will not happen.  The eng team wants to get a few recently reported crashes from the forum and some other small fixes into this next release.  They also want to do some very thorough testing on this release to try to catch any new bugs we may have introduced.

Apologies,

Eric, AdMob SDK Support

[William Ferguson]

Hi Eric, any further update?

On Sep 25, 11:25 am, Eric Leichtenschlag <eleichtens...@google.com>
wrote:

[Cedric Counotte]

I received last Tuesday an email from AdMob team (?) saying the fix should be released within hours!

"
the latest release due on 9/26 should have fixed the
problem. It should be available within hours.

"

That's been days now, asked them back when it will actually be released, no reply!

So, can we get some news?

2011/9/30 William Ferguson <william.f...@gmail.com>

[Eric Leichtenschlag]

The release is scheduled for the middle of next week.  We believe to have addressed the FLAG_ACTIVITY_NEW_TASK error and the IllegalArgumentException that was reported last week, meaning all outstanding bugs reported by you guys in 4.1.1 should be fixed in the next version.

Eric, AdMob SDK Support

[William Ferguson]

Hopefully you have also nailed the main pain too, the
NullPointerException?
Ie the one we have all been complaining about and that is causing 1%
of my users to crash each day

java.lang.NullPointerException
at android.webkit.WebView.stopLoading(WebView.java:1425)
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:123)
at android.app.ActivityThread.main(ActivityThread.java:4364)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:521)
at com.android.internal.os.ZygoteInit
$MethodAndArgsCaller.run(ZygoteInit.java:862)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:620)
at dalvik.system.NativeStart.main(Native Method)


On Oct 1, 1:55 am, Eric Leichtenschlag <eleichtens...@google.com>
wrote:

[Eric Leichtenschlag]

Yes, this issue has been addressed as well.

Eric, AdMob SDK Support

[Jim]

Eric,

That's great news! Please continue to keep us posted...

Thanks,
Jim

On Oct 3, 11:31 am, Eric Leichtenschlag <eleichtens...@google.com>
wrote:

[William Ferguson]

Excellent, looking forward to it.

On Oct 4, 2:31 am, Eric Leichtenschlag <eleichtens...@google.com>
wrote:

[Alexander Ponomarev]

Acra caught about 1000 such exceptions

java.lang.NullPointerException
at android.webkit.WebView.stopLoading(WebView.java:2291)

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:123)

at android.app.ActivityThread.main(ActivityThread.java:3691)
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:847)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:605)
at dalvik.system.NativeStart.main(Native Method)

for some 8 days :( When are you going to release the fix?

[Emanuel Moecklin]

Middle of next week was today...

[Cedric Counotte]

So what do we do now, Eric?

How can this 4.1.1 buggy version be left available for anyone to use? Never
received so much complaints before I implemented this version!
Will it be next week again, next month maybe? Or even next year to fix
future bugs being reported?

Not funny!

[Markus Wiederkehr]

Hi Eric,

I have just dug up the announcement of AdMob 4.1.1 in this forum. The day following the announce, July 20, user dm1973 reported two problems with the new release. See https://groups.google.com/d/msg/google-admob-ads-sdk/Ys6CsvTez3I/VvbmijrldukJ

The first exception he posted looks exactly like the one I reported in this thread except the first line (WebView.stopLoading) seems to be missing from his stack trace.

Then a Tim@google answered that he "may have found the first issue and corrected it". If I am right this means the bug we are talking about here was fixed over two months ago!

Couldn't you have given us a hotfix release back then?

Instead we have to wait for weeks over weeks for a new release that probably has some new features and the associated risk of trading one bug for another.

Cheers,
Markus

[William Ferguson]

Eric, it's the end of the week.
Have you got an update for us re the release?

I think we've been pretty patient.

William

[b0b]

This bug is really severe, I can't believe it has not been fixed yet.
I just published an app using admob for the first time and get many of these crashes.

Can't wait for the new promised SDK.

[b0b]

Ok this bug is so annoying for users (who won't hesitate to give you bad ratings, especially if the app as stable before), and since a fix could come tomorrow or next year, I decided to remove
Admob ads until this is fixed.
IMHO a hotfix should have been issued within 24h for such a severe bug. Anything else is inexcusable.

[Sven]

Maybe they're holding the release for the bug's three-month
anniversary, in ~10 days from now.

[treimy]

Same annoying NPE here. Unbelievable how long Google needs to solve that issue... such a big, "professional" company

[b0b]

Any news on that mythical new SDK ?

[Eric Leichtenschlag]

The latest update is the new Android SDK is targeted for next week.  We are trying to be extra extra careful to make sure this release is as stable as possible.

Eric, AdMob SDK Support

[paul sohier]

How many times have you said that for this version already? This is seriously getting frustrating.

2011/10/12 Eric Leichtenschlag <eleich...@google.com>

[Xavier]

http://www.youtube.com/watch?v=qLcjUmBncZ8

On Oct 13, 10:29 am, paul sohier <paulsoh...@gmail.com> wrote:
> How many times have you said that for this version already? This is
> seriously getting frustrating.
>

> 2011/10/12 Eric Leichtenschlag <eleichtens...@google.com>

[b0b]

On Wednesday, 12 October 2011 23:41:00 UTC+2, Eric Leichtenschlag wrote:

The latest update is the new Android SDK is targeted for next week.  We are trying to be extra extra careful to make sure this release is as stable as possible.

Eric, AdMob SDK Support

Next week is upon us and the world awaits in awe for the new SDK to rule them all. A new release cannot be worse than the current 4.1.1 so there's no need to delay
it forever...And if something goes horribly wrong you can issue a hotfix (within this year). I don't recall making a significant update of an app and not breaking something
major requiring a hotfix.

[Sven]

This release /is/ a hotfix. ;)

It's 4.1.1's three-month anniversary in a few hours' time... let's see
if my prediction was correct. If not, I guess they could go for
biannual.

[Sven]

(I realise that Eric is just one guy who I'm sure is trying his
hardest, so this is a bit mean on him... but AdMob does sort of have a
multi-billion dollar company behind it. I think it's reasonable to
have /some/ expectations. Apologies for the double-post).

[GDroid]

This thread is a must for the next time a senior executive explains why we shouldn't rely on open-source solutions because these don't guarantee delivery and quality where "multi-million" companies do ;)

[dm1973]

It is funny that you picked Mobclix as an example given their history
(google it) of being really slow (6+ months) with payments.

It is important to remember this is the one time I am aware of Admob
being slow with a fix. I have worked with them for close to 3 years
now and in general when bugs were reported (memory leaks and crashes)
they were fixed promptly. Something definitely went wrong this time in
the process. Hopefully it is fixed and doesn't happen again.

On Oct 18, 8:49 am, Andrew <soundma...@gmail.com> wrote:
> This thread is also invaluable for educating and training future public
> relations staff in some smaller companies such as MobClix. Maybe they are
> already studying it, who knows?

[b0b]

"Next week" ending draws closer...

[Tamás Barta]

How long do we have to wait for fix?

[Eric Leichtenschlag]

Unfortunately the SDK is not going to make it out this week like we hoped.  However, it is coming very soon.  Thank you for your patience.

Eric, AdMob SDK Support

[paul sohier]

You know you have been this saying for months?

Met vriendelijke groet,
Paul Sohier

Verstuurd vanaf mijn iPad

Op 21 okt. 2011 om 19:21 heeft Eric Leichtenschlag
<eleich...@google.com> het volgende geschreven: