Develop Reference

Crashlytics and AsyncTask

I'm adding Crashlytics into an app and I ran a couple tests. When I throw an exception within an async task the report didn't appear in the console. Is this a known issue or should it be coming through?
AsyncTask.execute(new Runnable()) {
#Override public void run() {
throw new RuntimeException("THIS IS A TEST");
}
}
I know that Crashlytics is set up correctly because an exception thrown from the same function but outside the AsyncTask wrapper shows up just fine.
Can anyone else share their experience with crashes that occur asynchronously?
UPDATE
I ran more tests and I found that part of my issue was that I had a handler for uncaught exceptions. I had this in place so testers would get a dialog box and they could just tap OK to get a logcat attached to an email. (Thanks to need-to-handle-uncaught-exception-and-send-log-file) I tried a number of things and I in my case I just need to pick one or the other, the uncaught exception handler or the crashlytics. It works for me this way since I only really want the crashlytics in place for the production+release variant.
I tried including Crashlytics.logException(e) in the body of the exception handler but that didn't work. Possibly because the function calls System.exit(1) right after. Anyway... this is what I have now that does the job.
To use a custom application class, update the manifest
<application
android:name=".util.App"
In the App class I either set up the uncaught exception handler or the crashlytics.
public class App extends Application {
public void onCreate() {
super.onCreate();
Constants.IS_DEV = BuildConfig.FLAVOR.equals("dev");
if (Constants.IS_DEV || BuildConfig.DEBUG) {
setupUncaughtExceptionHandler();
} else {
Fabric.with(this, new Crashlytics());
}
[SNIP]
}
private void setupUncaughtExceptionHandler() {
// Setup handler for uncaught exceptions.
Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() {
#Override
public void uncaughtException(Thread thread, Throwable e) {
handleUncaughtException(thread, e);
}
});
}
public void handleUncaughtException(Thread thread, Throwable e) {
// Crashlytics.logException(e); did not work here
// create intent to launch new instance and show 'send_log' dialog
Intent intent = new Intent();
intent.setAction(BuildConfig.APPLICATION_ID + ".SEND_LOG");
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
System.exit(1); // kill this instance
}
[SNIP]
}
My tests were just functions I grabbed in the settings page. They're just text items with onClick method set to 'onClick' (how original :)
public class SettingsActivity extends DataSourcedActivity {
[SNIP]
public void onClick(View view) {
if (view == findViewById(R.id.txtSettingsRemove)) {
launchRemoveItemsPage();
} else if (view == findViewById(R.id.txtSettingsRestorePurch)) {
launchRestorePurchases();
} else if (view == findViewById(R.id.txtContactSupport)) {
launchContactSupport();
} else if (view == findViewById(R.id.txtGetUpdates)) {
launchGetUpdates();
} else {
throw new DevException(Constants.UNKNOWN_SETTINGS_OPTION);
}
}
private void launchRemoveCollectionsPage() {
AsyncTask.execute(new Runnable()) {
#Override
public void run() {
throw new RuntimeException("THIS IS AN ASYNCHRONOUS TEST");
}
}
[SNIPPED ORIGINAL CONTENTS OF FUNCTION]
}
private void launchRestorePurchases() {
throw new RuntimeException("THIS IS A TEST");
[SNIPPED ORIGINAL CONTENTS OF FUNCTION]
}
[SNIP]
}
When I tried to use both the Crashlytics and the uncaughtException handler I got different results depending on which I set up first. If I setup Crashlytics first and then my uncaughtExceptionHandler then it appeared that mine overrode Crashlytics, no crash report made it to the console. If I setup my uncaughtExceptionHandler first then I do get the crash report on the console.
So I'm leaving this here just in case it might be helpful to others who run into this.
Mike

The crash comes on the next subsequent launch. The crash gets logged locally, then the next time you launch the 'same build or app' it sends the report up on startup.
Please ensure that you are starting crashlytics properly, and make sure you are launching the app a second time from the same app on your device to ensure it gets sent. Hitting play again and again from your debugger may have undesired results of sending the issue to the dashboard.
Also, in debug you may find slightly delayed posting, I've seen it take as much as 5 minutes before.

android - callback function for handling crashes

I need to handle crashes in android application,Is there any callback function or overridden method in activity class which will be called when the app crashes?
Guide me in solving this...

You can set an uncaught exception handler which will be called every time. Like this
final Thread.UncaughtExceptionHandler defaultHandler = Thread.getDefaultUncaughtExceptionHandler();
Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() {
#Override
public void uncaughtException(Thread thread, Throwable throwable) {
// do your magic
defaultHandler.uncaughtException(thread, throwable);
}
});
You should probably subclass the Application class and run this code as the first thing in the OnCreate method. Getting the default handler and passing the exception along is to ensure proper handling after you are done performing magic.
What are you trying to achieve?

android: how to quit the app properly on error

I added an exceptionhandler for unhandled exceptions, to know that the app has crashed on the next app start:
#Override
public void uncaughtException(Thread thread, Throwable ex) {
SharedPreferences preferences = PreferenceManager.getDefaultSharedPreferences(getBaseContext());
SharedPreferences.Editor editor = preferences.edit();
editor.putString("crashed", "yes");
editor.commit();
}
I added the handler via:
Thread.setDefaultUncaughtExceptionHandler(this);
Now the thing is: since I added the handler, the app behaves differently on error:
Before I added the handler I got a popup telling me that the app has crashed.
Now, after adding the handler the app just freezes, and after a while android shows me a popup telling me that the app does not respond anymore and whether I want to wait any longer. This is not good IMO. Any hints, how to properly exit after an application crash?

you can save the original exception handler , so that you can call it after you are done with doing your own custom operations on the unhandled exception . something like this:
//Inside UncaughtExceptionHandler.java:
…
private UncaughtExceptionHandler defaultUEH;
public DefaultExceptionHandler()
{
this.defaultUEH = Thread.getDefaultUncaughtExceptionHandler();
}
#Override
public void uncaughtException(Thread t, Throwable e)
{
//do anything you wish about the Throwable e :getStackTrace(),getCause(),getClass()...
//call the original uncaught exception handler:
defaultUEH.uncaughtException(t, e);
}

I suggest that you integrate your logic with ACRA, so that it can handle the issues of crash reporting and cleanup.

Android: got CalledFromWrongThreadException in onPostExecute() - How could it be?

I have an app in production for a few weeks, using ACRA, and I had zero errors until one strange error reported today.
I've got:
android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.
coming from this method in the stack trace (retraced):
at my.app.CountdownFragment$1.void onPostExecute(java.lang.Object)(SourceFile:1)
And this is the relevant source snippet:
private void addInstructionsIfNeeded() {
if (S.sDisplayAssist) {
new AsyncTask<String, Void, String>() {
#Override
protected String doInBackground(String... params) {
return null;
}
/*
* runs on the ui thread
*/
protected void onPostExecute(String result) {
Activity a = getActivity();
if (S.sHelpEnabled && a != null) {
in = new InstructionsView(a.getApplicationContext());
RelativeLayout mv = (RelativeLayout) a
.findViewById(R.id.main_place);
mv.addView(in.prepareView());
}
};
}.execute("");
}
}
Where addInstructionsIfNeeded() is called from a handler dispatched message (the UI thead).
onPostExecute() runs on the UI thread, so why I've got "wrong thread"?
This code ran already on more than 150 devices, and more than 100000 times (according to Flurry), and never had this error.
The originating device is Samsung SGH-I997 running SDK 4.0.4
My question is: How could it be?
EDIT:
This all happens in a fragment

i was suffering from the same problem, this is another android framework bug...
what is happening:
in certain circumstances an application can have more than one "looper" and therefore more than one "UI thread"
--side note-- i am using the term "UI thread" in the loosest of senses in this answer, since when people say "UI thread" they usually mean main or entry thread, Android like many of other OS before it, allow for for multiple message pumps (called a Looper in Android, see: http://en.wikipedia.org/wiki/Event_loop) for different UI trees, as such android for all intents and purposes is capable of running more than one "UI thread" in certain circumstances and using that term leads to rampant ambiguities... --end side note--
this means:
since an application can have more than one "UI thread" and an AsyncTask always "Runs on the UI thread" [ref], someone decided [poorly] that instead of the AsyncTask always running on its creation thread (which in 99.999999% of cases would be the correct "UI thread") they decided to use hocus pocus (or a poorly crafted shortcut, you decide) to execute on the "main looper"..
example:
Log.i("AsyncTask / Handler created ON: " + Thread.currentThread().getId());
Log.i("Main Looper: " + Looper.getMainLooper().getThread().getId() + " myLooper: "+ Looper.myLooper().getThread().getId());
new AsyncTask<Void, Void, Void>() {
#Override
protected Void doInBackground(Void... params) {
Log.i("doInBackground ran ON: " + Thread.currentThread().getId());
// I'm in the background, all is normal
handler.post(new Runnable() {
#Override
public void run() {
Log.i("Handler posted runnable ON: " + Thread.currentThread().getId());
// this is the correct thread, that onPostExecute should be on
}
});
return null;
}
#Override
protected void onPostExecute(Void result) {
Log.i("onPostExecute ran ON: " + Thread.currentThread().getId());
// this CAN be the wrong thread in certain situations
}
}.execute();
if called from the bad situation described above the output will look something like this:
AsyncTask / Handler created ON: 16
Main Looper: 1 myLooper: 16
doInBackground ran ON: 12
onPostExecute ran ON: 1
Handler posted runnable ON: 16
that's a huge FAIL for AsyncTask
as shown this can be mitigated using a Handler.post(Runnable) in my specific case the duality of my "UI thread" situation was caused by the fact that I was creating a dialog in response to a JavaScript interface method called from a WebView, basically: the WebView had its own "UI thread" and that was the one that i was currently running on..
from what i can tell (without really caring about or reading into it too much) it seems that the AsyncTask class' callback methods in general run off a single statically instantiated handler (see: http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.0.3_r1/android/os/AsyncTask.java#AsyncTask.0sHandler), which means that it is always going to execute on the "main thread" or "entry thread" which they incorrectly refer to as the "UI thread" (which is presumed as any thread where UI interactions take place, eg. multiple threads in this case) this is both shoddy craftsmanship and shoddy documentation from the android team... weak sauce, the sauce is weak
hope this helps you -ck

Had the same issue. Solved in my case
Briefly explanation:
Running AsynckTask for the very first time on non UI thread with looper leads to loading AsyncTask.class and initialization sHandler to handler constructed on that non UI looper.
Now sHandler is connected to that non UI thread for ANY instance of AsyncTask subclasses and onPreExecute, onProgressUpdate and onPostExecute methods will be invoked on that non UI thread (unless AsyncTask.class will be unloaded)
Any attempt to deal with UI inside any of the above methods will lead to crash with android.view.ViewRootImpl$CalledFromWrongThreadException
To avoid such situation one should always run (at least for the very first time) AsyncTask on UI thread in order to let AsyncTask's sHandler-field be initialized with UI's looper
The story:
There were two production apps: A - main android app and B - some utilty app.
After integration app B ito app A we received a lot of crashes:
android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.
for method running from AsynckTask.onPostExecute()
After some investigation it appeared that utility app B used AsyncTask within its HandlerThread
The traces was found in AsyncTask's source code:
private static final InternalHandler sHandler = new InternalHandler();
This is the handler which is used to send onPostExecute() to UI thread.
This handler is static and it will be initialized during class loading i.e. first new AsyncTask() appearance
It means that onPostExecute will always be posted to that thread where new AsyncTask() was called for the first time (unless AsyncTask.class will be unloaded and loaded again)
In my case the flow was something like this:
1 - starting app A
2 - initializing B form A
3 - B creates its own HandlerThread and launches AsyncTask <- now onPostExecute wil be posted to this HandlerThread no matter where from an instance of AsyncTask will be launched in future
4 - create AsyncTask in the app A for a long operation and update UI in its onPostExecute
5 - when executing onPostExecute() the CalledFromWrongThreadException is thrown
Then a friend of mine showed me related documentation from android.developers (Threading rules section):
The AsyncTask class must be loaded on the UI thread. This is done
automatically as of JELLY_BEAN. The task instance must be created on
the UI thread. execute(Params...) must be invoked on the UI thread.
Hope it can help to make clear the situation)

Maybe the reason is Flurry?
I had this exception when I used Flurry 3.2.1. But when I went back to Flurry 3.2.0 I didn't have this exception
Use Flurry 3.2.2 and above.

Placing the following line of code in the Application onCreate should solve the problem:
/**
* Fixing AsyncTask Issue not called on main thread
*/
try {
Class.forName("android.os.AsyncTask");
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
It seems the issue is created when the AsyncTask class is first initiated on a different main Thread which is not our main Thread, I checked it by adding the code in the bottom, to my Application onCreate
new Thread(new Runnable() {
#Override
public void run() {
Log.i("tag","1.3onPostExecute ran ON: " + Thread.currentThread().getId());
Looper.prepare();
new AsyncTask<Void,Void,Void>(){
#Override
protected Void doInBackground(Void... params) {
Log.i("tag","2onPostExecute ran ON: " + Thread.currentThread().getId());
return null;
}
#Override
protected void onPostExecute(Void aVoid) {
Log.i("tag","1.2onPostExecute ran ON: " + Thread.currentThread().getId());
super.onPostExecute(aVoid);
}
}.execute();
Looper.loop();
Looper.myLooper().quit();
}
}).start();
This code will init the AsynTask in a main Thread which is not the application main, and will cause the application to crash in any other AsyncTask which will do any UI on the post-execute. crashing with the CalledFromWrongThreadException
Hope it cleared things a little bit more.
Thanks all for the great help on this.

Where is
runOnUiThread(new Runnable() {
public void run() { /*code*/ } );
in your code
/*
* runs on the ui thread
*/
protected void onPostExecute(String result) {
Activity a = getActivity();
if (S.sHelpEnabled && a != null) {
in = new InstructionsView(a.getApplicationContext());
runOnUiThread(new Runnable() {
public void run() {
RelativeLayout mv = (RelativeLayout) a
.findViewById(R.id.main_place);
mv.addView(in.prepareView());
}
}
};
Try this code. I think this would fix the problem

I think the problem lies in the line Activity a = getActivity(); I think you should do that before going into the AsyncTask

how do you read text files off the internet in Android 4.0.3

I am a relatively new Android programmer and I was wondering how you could get read text off the internet in 4.0.3. I keep finding code that gives me a Network on Main exception: http://developer.android.com/reference/android/os/NetworkOnMainThreadException.html and was wondering if anyone could provide me some sample code to get around this, for reference I got the code I tried to use here: http://android-er.blogspot.com/2011/04/read-text-file-from-internet-using-java.html. Thanks a lot.

In Honeycomb and Ice Cream Sandwich (i.e. Android 3.0+) , you cannot connect to the internet in the main thread (onCreate(), onPause(), onResume() etc.), and you have to instead start a new thread. The reason why this has changed is because network operations can make the app wait for a long time, and if you're running them in the main thread, the whole application becomes unresponsive. If you try to connect from the main thread, Android will throw a NetworkOnMainThreadException.
To bypass this, you can run networking code from a new thread, and use runOnUiThread() to do things in the main thread, such as update the user interface. Generally, you can do something like:
class MyActivity extends Activity {
public onCreate(Bundle savedInstanceState) {
super.onCreate();
// Create thread
Thread networkThread = new Thread() {
#Override
public void run() {
try {
// this is where your networking code goes
// I'm declaring the variable final to be accessible from runOnUiThread
final String result = someFunctionThatUsesNetwork();
runOnUiThread(new Runnable() {
#Override
public void run() {
// this is where you can update your interface with your results
TextView myLabel = (TextView) findViewById(R.id.myLabel);
myLabel.setText(result);
}
}
} catch (IOException e) {
Log.e("App", "IOException thrown", e);
}
}
}
}
}

You need to complete an HTTP Request. There are a lot of examples available on line. Try here for starts.