Explanation of how Crash reports are provided based on Android applications

Why do we need feedback on the Crash report?

For Android applications, we should try to avoid Crash. Although zero-Crash is the ultimate goal pursued by programmers, the reality is that programmers can only minimize the occurrence of Crash, and it is almost impossible to completely eliminate it. Maybe you think that your application is almost perfect and can easily withstand the devil's test in the testing department. But when your application is released to the market, it may not be so lucky to face millions or even tens of millions of users.

For the above reasons, a Crash feedback mechanism is required for general applications. Programmers can improve the code of the current version based on the feedback to make the next version more stable.

How to provide feedback?

First, let's take a look at how to capture the occurrence of Crash.

There is an interface in Java, UncaughtExceptionHandler. first look at the description.

static interface

Thread. UncaughtExceptionHandler WhenThreadWhen an uncaptured exception is suddenly terminated, the handler interface is called.

Let's take a look at a method in the Thread class.

static void

SetDefaultUncaughtExceptionHandler(Thread. UncaughtExceptionHandler eh) Sets the default handler that is called when the thread is suddenly terminated because no exception is caught and no other handler is defined for the thread.

After reading these APIs, we can see that we need to implement such an interface and then set the handler in the main thread of the program.

See the following interface implementation.

Copy codeThe Code is as follows: package com. arui. framework. android. exception;
Import java. lang. Thread. UncaughtExceptionHandler;
Import android. content. Context;
/**

* Default exception handler for all activities.
*
* @ Author http://blog.csdn.net/arui319

* @ Version 2011/12/01
*
*/
Public class DefaultExceptionHandler implements UncaughtExceptionHandler {
Private Context act = null;
Public DefaultExceptionHandler (Context act ){
This. act = act;
}
@ Override
Public void uncaughtException (Thread thread, Throwable ex ){

// Collect exception information and send it to the server

SendCrashReport (ex );

// Wait for half a second

Try {

Thread. sleep (500 );

} Catch (InterruptedException e ){

//
}
// Handle exceptions
HandleException ();
}
Private void sendCrashReport (Throwable ex ){

StringBuffer exceptionStr = new StringBuffer ();

Predictionstr. append (ex. getMessage ());

StackTraceElement [] elements = ex. getStackTrace ();

For (int I = 0; I <elements. length; I ++ ){

Predictionstr. append (elements [I]. toString ());
}

// TODO

// Send the collected Crash information to the server

}
Private void handleException (){

// TODO

// Handle exceptions here.

// For example, the user program crashes.

// For example, record important information and try to restore the site.

// Or simply record important information and then directly kill the program.
}
}

Add the following code to the onCreate (Bundle savedInstanceState) method of the main Activity.Copy codeThe Code is as follows: Thread. setDefaultUncaughtExceptionHandler (new DefaultExceptionHandler (

This. getApplicationContext ()));

How to send to the server?

Different project teams may have different approaches, which are not discussed here. It should be noted that in addition to sending the specific exception information to the server, at least the version information should be sent so that the programmer can determine the version of the exception information on the server. In addition to the version information, you may also need the mobile phone SDK version, screen resolution, mobile phone model, and other information. With this information, you can have a more comprehensive understanding of the exception information.

For more information, see.

You only need to set an exception handling class in the main Activity, and do not need to set it in all the acitifiers.

I personally feel that it is of little significance to resume the on-site operation after a Crash occurs. After the Crash, the running status of the program is unpredictable. Using One error to make up for another error will lead to more errors. It is recommended to avoid Crash occurrence as much as possible.