自定义系统Anr/Crash弹框（基于google源码分析）

春节最后一天上班，总结下自定义系统Anr/Crash弹框的流程

• 本篇文章从系统层面基于google源码分析，并在应用异常退出、无响应必经之路根据需要弹出d自定义dialog

  1、首先应用无论是报错了，还是被系统kill了必经过

 services/core/java/com/android/server/am/ActivityManagerService.java
  @GuardedBy("this")
  final void appDiedLocked(ProcessRecord app, int pid, IApplicationThread thread,
   boolean fromBinderDied) {
   //TODO
   }

2、就是我们经常看到了XXX应用报错了、XXX应用无响应了 弹出的地方
有两个方法，分别弹出无响应和报错框，这些方法内部都有判断应用是不是crash、anr 是不是Silenced，就是说有报错也不会通知用户，可能表现为闪退。

services/core/java/com/android/server/am/AppErrors.java
   //应用anr弹出的地方
   (1)void handleShowAnrUi(Message msg) {
    synchronized (mService) {
    AppNotRespondingDialog.Data data =   (AppNotRespondingDialog.Data) msg.obj;
    final ProcessRecord proc = data.proc;
   }
   //应用crash弹出的地方
    (2)void handleShowAppErrorUi(Message msg) {
    AppErrorDialog.Data data = (AppErrorDialog.Data) msg.obj;
    boolean showBackground = Settings.Secure.getInt(mContext.getContentResolver(),
    Settings.Secure.ANR_SHOW_BACKGROUND, 0) != 0;
    }

• 我们以应用ANR的dialog为例，AppNotRespondingDialog为例

  services/core/java/com/android/server/am/AppNotRespondingDialog.java 继承了 BaseErrorDialog ， 构造方法里接收AMS 和 应用进程信息
  final class AppNotRespondingDialog extends BaseErrorDialog implements View.OnClickListener

• 所以我们自定义的dialog就可以在AppErrors 里替换我们自定义的系统dialog ：TYPE_SYSTEM_ALERT

• 以Anr为例我们往前推下流程：

  以绑定一个服务为起点，最后如果服务超时启动，会走到mAppErrors.handleShowAnrUi(msg)，就是我们上面的代码

image-20220126162633971.png

• 我们经常看到的Anr in XXX 就是在ProcessRecord.java 的appNotResponding 方法中打印出来的

04-0113:12:15.872 E/ActivityManager(  220): ANR in com.android.email(com.android.email/.activity.SplitScreenActivity)
   
   04-0113:12:15.872 E/ActivityManager(  220): Reason:keyDispatchingTimedOut
   
   04-0113:12:15.872 E/ActivityManager(  220): Load: 8.68 / 8.37 / 8.53
   
   04-0113:12:15.872 E/ActivityManager(  220): CPUusage from 4361ms to 699ms ago
   
   04-0113:12:15.872 E/ActivityManager(  220):   5.5%21404/com.android.email: 1.3% user + 4.1% kernel / faults: 10 minor
   04-0113:12:15.872 E/ActivityManager(  220):   4.3%220/system_server: 2.7% user + 1.5% kernel / faults: 11 minor 2 major
   04-0113:12:15.872 E/ActivityManager(  220):   0.9%52/spi_qsd.0: 0% user + 0.9% kernel</pre>

这个方法里除了打印这个还会调用ActivityManagerService 的dumpStackTraces ->dumpJavaTracesTombstoned 保存trace log到anr 目录和 tombstones 目录

• 再深入一点就是应用进程内部的trace是如何打印的
  art\runtime\signal_catcher.cc 这里对于每个应用进程都会启动一个SignalCatcher 接收signal信号的，收到后会去dump其他线程信息

void* SignalCatcher::Run(void* arg) {
        SignalCatcher* signal_catcher = reinterpret_cast<SignalCatcher*>(arg);
        CHECK(signal_catcher != nullptr);
       
        Runtime* runtime = Runtime::Current();
        CHECK(runtime->AttachCurrentThread("Signal Catcher", true, runtime->GetSystemThreadGroup(),
        !runtime->IsAotCompiler()));
       
        Thread* self = Thread::Current();
        DCHECK_NE(self->GetState(), kRunnable);
        {
        MutexLock mu(self, signal_catcher->lock_);
        signal_catcher->thread_ = self;
        signal_catcher->cond_.Broadcast(self);
        }
       
        // Set up mask with signals we want to handle.
        SignalSet signals;
        signals.Add(SIGQUIT);
        signals.Add(SIGUSR1);
       
        while (true) {
        int signal_number = signal_catcher->WaitForSignal(self, signals);
        if (signal_catcher->ShouldHalt()) {
        runtime->DetachCurrentThread();
        return nullptr;
        }
       
        switch (signal_number) {
        case SIGQUIT:
        signal_catcher->HandleSigQuit();
        break;
        case SIGUSR1:
        signal_catcher->HandleSigUsr1();
        break;
        default:
        LOG(ERROR) << "Unexpected signal %d" << signal_number;
        break;
        }
        }</pre>