Android Remove annoying default flashback Dialog

  • 2021-07-03 00:50:01
  • OfStack

After Android application flashes back, there will always be a pop-up window with "Sorry, App has stopped running", which is not a good user experience. This pop-up window has been removed from App of many large factories, so this article mainly introduces how to remove the default flashback pop-up window and do some necessary aftercare work during flashback.

UnCaughtExceptionHandler
UnCaughtExceptionHandler can do some aftercare work before Thread meets Exception without catch. However, it can't prevent the thread from stopping running, and the thread will eventually exit.


 Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() {
   @Override
   public void uncaughtException(Thread thread, Throwable ex) {
    System.exit(1);
   }
  });

Removal of Dialog
The Android system is set with an UnCaughtExceptionHandler by default, and the pop-up flashback pop-up window is done in this handler. Therefore, if you want to remove the pop-up window, you only need to realize an UnCaughtExceptionHandler and replace the default system. The code is as follows.


public class App extends Application {


 @Override
 public void onCreate() {
  super.onCreate();
  Thread.setDefaultUncaughtExceptionHandler(new MyUnCaughtExceptionHandler());
 }



 class MyUnCaughtExceptionHandler implements Thread.UncaughtExceptionHandler{

  @Override
  public void uncaughtException(Thread thread, Throwable ex) {
   ex.printStackTrace();
   // do some work here

  android.os.Process.killProcess(android.os.Process.myPid());
   System.exit(1);
  }
 }
}

The above replacement of UnCaughtExceptionHandler is done in Application, but you can also do it in every Activity. It is good for a single Activity. When there are many Activity, it is necessary to implement an BaseActivity and replace it in BaseActivity. Other Activity should integrate BaseActivity.

Necessary aftercare work
In order to deal with flashbacks and improve the user experience, it is necessary to do some aftercare work, mainly listed as follows:

Exception reporting
It can be uploaded by mail or through the server interface. Both of them have their own advantages and disadvantages. E-mail is simple to develop, but it needs extra operation from users, and the user experience is poor. If you use the upload server mode, because you can't open a new thread in UnCaughtExceptionHandler, you can only synchronize the request, which will take a long time and block the operation when the network situation is bad. It may also fail to report due to network reasons. Of course, overall, it is better to upload the server by 1 point. The concrete implementation is left to readers.

Record a log
Stores flashback information to the file system. Cannot save to SharedPreferences because opening SP requires a new thread (Android internal implementation), which is not allowed in UnCaughtExceptionHandler.

Flash back 3 times to clear data
In many cases, the flashback is caused by the error of data returned from the background. If these data are cached, flashback will occur even if the user opens it again. At this time, the flashback problem can only be solved by reloading or clearing the data, and the user experience is not good at 10 points. Therefore, it is necessary to automatically clear cached data 10 points after multiple flashbacks. Specific implementation can refer to my other blog Android to achieve multiple flashback clearing data. However, this blog uses ACRA, an open source project that re-encapsulates UnCaughtExceptionHandler. Readers can replace UnCaughtExceptionHandler with ACRA.

Reopen App
You can reopen App in UnCaughtExceptionHandler or pop up a custom pop-up window.


 class MyUnCaughtExceptionHandler implements Thread.UncaughtExceptionHandler{

  @Override
  public void uncaughtException(Thread thread, Throwable ex) {
   ex.printStackTrace();
   
   Intent intent = new Intent(App.this, MainActivity.class);
   intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
   App.this.startActivity(intent);

   android.os.Process.killProcess(android.os.Process.myPid());
   System.exit(1);
  }
 }

Note that this step of setFlags is necessary, because the Context used is Context of App, so a new task queue must be opened, otherwise opening Activity will not take effect. If you replace Handler in Activity and get Context of Activity, this step is not needed.

Matters needing attention
The main note I mentioned earlier is not to throw an exception by opening a new thread in UnCaughtExceptionHandler.

The above is the whole content of this paper, hoping to help everyone's study.


Related articles: