AndroidRuntimeException: Calling startActivity() from outside of an Activity context requires the FLAG_ACTIVITY_NEW_TASK flag.

[William Ferguson]

I've had one instance of this error show up in the wild in crash logs

android.util.AndroidRuntimeException: Calling startActivity() from
outside of an Activity context requires the FLAG_ACTIVITY_NEW_TASK
flag. Is this really what you want?
at android.app.ContextImpl.startActivity(ContextImpl.java:617)
at android.content.ContextWrapper.startActivity(ContextWrapper.java:
258)
at
android.webkit.CallbackProxy.uiOverrideUrlLoading(CallbackProxy.java:
228)
at android.webkit.CallbackProxy.handleMessage(CallbackProxy.java:323)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:123)
at android.app.ActivityThread.main(ActivityThread.java:4669)
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:876)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:634)
at dalvik.system.NativeStart.main(Native Method)

It would seem to be directly related to the AdMob component because I
don't make any use of webkit,
Has anyone else seen this occur?

[Emanuel Moecklin]

I got 10 of these error reports so far.
I'm using WebViews and I'm launching activities from the
shouldOverrideUrlLoading() method but I'm pretty sure it's not my code
causing the crashes because the startActivity() calls are in try catch
clauses.
I decompiled the admob lib 4.1.0 and found a launchAdActivity() method
in AdActivity that is called from a shouldOverrideUrlLoading() method
in a WebViewClient (class h.java).
The startActivity is not within a try catch clause, so I guess it is
indeed the Admob lib causing the trouble (especially knowing that
there are other people out there getting the exact same exception/
stack trace).
I'm gonna submit a ticket to admob, there's not much else to do here.

Emanuel Moecklin
1gravity LLC

On May 20, 12:35 pm, William Ferguson <william.ferguson...@gmail.com>
wrote:

[Gino]

I just posted the following on a slightly different thread, but I
think it's relevant here as well:

Guys, you know what ? Admob SDK 4.1.0 seems to work fairly well, at
least for me. One of my apps has over a million ad hit requests so far
this month and no issues that I can discern.
I checked my Developer Console crash logs and searched for
AndroidRuntimeException and found no occurrences..

I'm pretty happy with Admob SDK 4.1.0. In terms of the bugfixes
incorporated into 4.1.1, I don't recollect seeing anything that was
compelling enough to upgrade the SDK at this point.

Also, if the AdMob SDK works fine 99.99% or 99.999% of the time, that
may be as high as you can go. I've got about a couple dozen weird
crash errors that I'm never going to look into because I think they're
just sporadic glitches that have nothing to do with my code. The
danger with trying to go from 99.99%/99.999% to 99.9999% is that you
may actually introduce a new issue(s) and start breaking things that
worked fine before. In other words, if you fix something that ain't
broken, you're liable to break it..

Gino.

[Jim]

We've got about 5 of this type of error this week (it seems to be
new). We do not use webkit for anything (except ads). AdMob, please
look into it (or maybe the new SDK solves the problem - we will be
testing this week).

Gino - while you run the risk of introducing new bugs when you fix an
old one, we get a few million requests per day, and an acceptable
error rate for us is less than one in a million, or better than
99.999%. Even with a one-in-a-million error rate, we get a few errors
per day (currently about 20 per day - too high; most due to AdMob
specific errors). At your suggested tolerance, we would get 30-300 per
day. That is a lot of irritated users, and it would also make finding
"real" problems excessively difficult.

Furthermore, our best estimate is that for each reported error there
are 10-100 occurrences that go unreported. So really, AdMob (and us,
as developers also) should aim for a reported error rate of less than
1 in 10,000,000. It is advisable that you attempt to eliminate every
error that you get - a user that took the time to report it means it's
a problem.

To complicate matters further, the non-technical, everyday app user
will blame you for errors that are not your fault (and may not be
reported to you under any circumstance), which means you really need
to eliminate the ones you are aware of and are your responsibility. To
support this, we have a feature in some of our apps that is unreliable
when other apps are poorly written in very specific ways. Our users do
not care that another app is the cause of the problem, because it
isn't clear to the user that the other app is the source of the
problem. It is very difficult to convince a user that our app is not
the problem (especially with very popular apps that cause it), even
when we have proof because the proof is very technical. Those app
developers don't see it as a "big" problem, so many of them ignore our
requests to have it fixed (some don't even understand the problem, and
also ignore it).

I only write this to help emphasize to AdMob (and other readers of
this thread) that there are other opinions on error rates, and as your
usage goes up (that's is the goal, right?) you might change your mind
about acceptable error rates and become less tolerant. Then again,
maybe not...

-Jim

[Gino]

Something's a bit weird here. With over a million hits so far this
month, I should be seeing at least a few cases of
AndroidRuntimeException.
But I'm not.

Is it possible that maybe the calling code is faulty ?

I do remember, I ended up having to run the loadAd() request from
inside the ui thread..
Something like this:

runOnUiThread(new Runnable() {
public void run() {
adView.loadAd(new AdRequest());
}
});

Of course, within onCreate(), the call to loadAd() doesn't need to be
wrapped in this manner..


But again, if other people are seeing a problem with
AndroidRuntimeException being caused by the Admob SDK, After over a
million admob requsts, I should be seeing at least a couple
AndroidRuntimeException's
in my Developer Console crash logs.

I'm mystified..

Gino.

[Gino]

My bad -- I only have the 1 main activity -- I'm not invoking other
activities.. So maybe this is a critical difference ?

Gino.

[Jim]

Calling the AdView from outside the UI thread causes a different
error. And you're right, there could be something in how the code is
called that is the root of the problem.

With 5 reports this week, and we've had 22,000,000 impressions, that's
about 1 report in 4 million. Looks like you have about a 25% chance of
seeing it for the month (that's not quite right on how to calculate
the statistic, but good enough...).

If it is the calling code, it would involve constructing an intent to
start a new activity. That would probably be obvious, but it could be
another factor in the calling code that results in the WebView object
calling the new activity. Most likely, since WebViews re-draw on the
screen and must run in the UI thread, there is a part of the WebView
that starts a new activity (like a click on an ad) where the flags are
not properly set before broadcasting the intent.

Just a hunch because I haven't looked at the WebView code for this
issue.

-Jim

[dm1973]

I log my own errors (and get about 10x what is reported in the market)
and I saw ~15 yesterday in about 750k requests. All of my interactions
with admob are from the UI thread. I am more than willing to believe
this (or pretty much any bug I see) is something I am doing wrong but
it isn't clear what that could be.

Personally my impression is that using Webkit in an app is almost
impossible to get right and if you do webkit is likely to crash on
you. Ideally libraries like admob would publish source (doesn't have
to be open source. I don't need any redistribution rights). I would
take 10 mins to add some logging code to assure that admob is the one
causing this crash. I am not going to hold my breath though.

[Tim]

I assure you we are looking into this issue. Any further information
you guys could provide us to help diagnose the issue (or even better,
reproduce it) would be helpful :).

Thanks,
-Tim

[Jim]

Here is sample code for an intent that sets the flag which would "fix"
the error:

Intent mIntent = new Intent(context, my.class);
mIntent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);

This flag is required when a non-activity sends an intent to start an
application/activity which require a task stack. For example, a
background service wants to launch an application (like a music
player) to communicate with the user. A non-UI thread in an
application will succeed without the flag, so this is not the result
of a call from a non-UI thread.

So, unless you are attempting to background launch an activity from
outside of a task stack (all activities are created within tasks, and
threads spawned by them are also), then this is not happening from
your code. If you use components (like webkit), then a component you
use may be causing this error, but you won't know where/how unless you
can modify the component to figure out what service or receiver is
active and broadcasting the intent.

It is probably not AdMob that is "causing" the problem, but the webkit
(as you stated). According to the source code, webkit checks the
context for a WebView in uiOverrideUrlLoading in an attempt to reuse
the activity task. Somewhere in there, the WebView context is not
valid (it is not created inside of a context with a task and the
webkit doesn't check that the WebView context is within a task - it
would be reasonable to assume that it was). However, this is probably
because of AdMob's use of the webkit - they make reference to an
unusable WebView for the purpose intended. Or, the WebView created by
AdMob has an error that needs to be fixed in the webkit. We just don't
know.

Because it doesn't happen often, it is probably very hard for them to
identify like it would be for any of us.

-Jim

[William Ferguson]

Tim, that's great to hear, but I'm not sure what further info we can
possibly provide that we haven't already.
What is it you guys would like from us?

[Gino]

Guys,

I just had an idea: Is it possible that the problem occurs when the
user physical rotates the device, switching from portrait mode to
landscape mode, or vice versa ?

If I remember correctly, this causes the current Activity to be both
destroyed, then recreated. Which might explain why the top line of
the stack trace refers to a
startActivity().

So one thing to try, which might cause the issue to be more easily
reproducible is to keep switching from portrait mode to landscape mode
for a little while to see if the problem manifests itself.

Personally, I didn't like the idea of the activity being destroyed and
recreated each time the user rotated the screen -- this seemed a bit
goofy to me and a potential source of esoteric problems, so I just set
all apps to use portrait mode.

Kim


On Jul 22, 6:30 am, William Ferguson <william.ferguson...@gmail.com>
wrote:

[Jim]

That actually causes a different problem, as discussed here:

http://groups.google.com/group/google-admob-ads-sdk/browse_thread/thread/5e75362b6435f1a0/5db25162a2c9a7a9

I don't think the configuration change life cycle is popular, but it
does seem to be necessary. Regardless, "startActivity(intent)" is not
in that life cycle (onCreate, onStart, onResume). But keep trying!

@Tim - I did not see your message when I posted my last one. Don't
know why... Anyway, I was trying to elaborate on the problem, because
it seems to stem from an invalid URL ad response. We don't have access
to that data, which makes replication of the error nearly impossible.
How can we send ad responses to the emulator to see what data errors
might create the problem? The data support that there are lots of ads
served without the error, but it seems like it also requires a click -
the worst possible moment for all of us for an app to crash...

Maybe you could provide a test ad URL (which I believe we could
capture right now) and a test method on the AdRequest so we can spoof
the ad server (set the ad server to 127.0.0.1 or something) and setup
an ad request response with errors (run an Apache web server, grab the
request and send a bad response), send that bogus ad response to the
app and see how gracefully our apps (and your SDK) handle the fall? I
can probably get this working now (setup the hosts file so the AdMob
server is re-routed, like an Ad Blocker would), but having a true test
setup would be very helpful (it would give all of us more info).

Sounds like a lot of work, but we've all worked hard to get this
far...

-Jim

[William Ferguson]

Tim, I don't know how hopefully this is going to be but I can provide
a little more info.

I've managed to capture one of the URLs that it is attempting to load
(see below). I don't know if that is useful.

I have also determined that it is attempting to start the activity
using the ApplicationContext instead of the Activity context which is
why it is failing. I can tell that because line 426 of GameActivity is
in #getApplicationContext which I overrode so that I could put a
wrapper around the context to trap these Exceptions.

It occurred on Android 2.2

au.com.xandar.jumblee.common.JumbleeHandledException: Application
could not start Activity with
Intent:Intent{action=android.intent.action.VIEW uri=@gmsg://
mobileads.google.com/loadAdURL?type=admob&url=http%3A%2F%2Fr.admob.com
%3A80%2Fad_source.php%3Fkw%3Dword%252520game%25252Cword%252520puzzle
%26preqs%3D21%26u_sd%3D1.5%26slotname%3Da14ccc2511575b1%26u_w
%3D320%26msid%3Dau.com.xandar.jumblee%26js%3Dafma-sdk-a-v4.1.1%26isu
%3D51F1331056F9D96698B8A3C1F5FE566E%26format%3D320x50_mb%26net%3Ded
%26app_name%3D1043.android.au.com.xandar.jumblee%26hl%3Den%26u_h
%3D569%26u_audio%3D1%26u_so%3Dp%26output%3Dhtml%26region%3Dmobile_app
%26u_tz%3D240%26ex%3D1%26client_sdk%3D1%26kw_type%3Dbroad%26askip
%3D1&google.afma.Notify_dt=1314093857347 flags=0}
at au.com.xandar.jumblee.game.GameActivity
$8.startActivity(GameActivity.java:426)
at
android.webkit.CallbackProxy.uiOverrideUrlLoading(CallbackProxy.java:
235)
at android.webkit.CallbackProxy.handleMessage(CallbackProxy.java:
330)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:143)

On Jul 22, 7:47 am, Tim <timzwie...@google.com> wrote:

> > > > > > > > It would seem to be directly related to the AdMob component because I...
>
> read more »