AMS handleApplicationCrash函數的代碼如下： **ActivityManagerService.java::handleApplicationCrash** ~~~ public void handleApplicationCrash(IBinder app, ApplicationErrorReport.CrashInfocrashInfo) { //找到對應的ProcessRecord信息，后面那個字符串“Crash”用于打印輸出 ProcessRecord r = findAppProcess(app, "Crash"); finalString processName = app == null ? "system_server" : (r == null ? "unknown": r.processName); //添加crash信息到dropbox中 ddErrorToDropBox("crash", r, processName, null, null, null,null, null, crashInfo); //調用crashApplication函數 crashApplication(r, crashInfo); } ~~~ 上述代碼中的crashApplication 函數的代碼如下： **ActivityManagerService.java::crashApplication** ~~~ private void crashApplication(ProcessRecord r, ApplicationErrorReport.CrashInfocrashInfo) { longtimeMillis = System.currentTimeMillis(); //從應用進程傳遞過來的crashInfo中獲取相關信息 StringshortMsg = crashInfo.exceptionClassName; StringlongMsg = crashInfo.exceptionMessage; StringstackTrace = crashInfo.stackTrace; if(shortMsg != null && longMsg != null) { longMsg = shortMsg + ": " + longMsg; } elseif (shortMsg != null) { longMsg = shortMsg; } AppErrorResult result = new AppErrorResult(); synchronized (this) { if(mController != null) { //通知監視者。目前僅MonkeyTest中會為AMS設置監聽者。測試過程中可設定是否一檢測 //到App Crash即停止測試。另外，Monkey測試也會將App Crash信息保存起來 //供開發人員分析 } final long origId =Binder.clearCallingIdentity(); if (r!= null && r.instrumentationClass != null) { ......// instrumentationClass不為空的情況 } //①調用makeAppCrashingLocked處理，如果返回false，則整個處理流程完畢 if (r == null || !makeAppCrashingLocked(r,shortMsg, longMsg, stackTrace)) { ...... return; } Message msg = Message.obtain(); msg.what = SHOW_ERROR_MSG; HashMap data = new HashMap(); data.put("result", result); data.put("app", r); msg.obj = data; //發送SHOW_ERROR_MSG消息給mHandler，默認處理是彈出一個對話框，提示用戶某進程 //崩潰（Crash），用戶可以選擇“退出”或 “退出并報告” mHandler.sendMessage(msg); ...... }//synchronized(this)結束 //下面這個get函數是阻塞的，直到用戶處理了對話框為止。注意，此處涉及兩個線程： //handleApplicationCrash函數是在Binder調用線程中處理的，而對話框則是在mHandler所 //在線程中處理的 int res =result.get(); IntentappErrorIntent = null; synchronized (this) { if (r!= null) mProcessCrashTimes.put(r.info.processName, r.info.uid, SystemClock.uptimeMillis()); if (res== AppErrorDialog.FORCE_QUIT_AND_REPORT) //createAppErrorIntentLocked返回一個Intent，該Intent的Action是 //"android.intent.action.APP_ERROR"，指定接收者是app. errorReportReceiver //成員，該成員變量在關鍵點makeAppCrashingLocked中被設置 appErrorIntent =createAppErrorIntentLocked(r, timeMillis, crashInfo); }//synchronized(this)結束 if(appErrorIntent != null) { try {//啟動能處理APP_ERROR的應用進程，目前的源碼中還沒有地方處理它 mContext.startActivity(appErrorIntent); } ...... } } ~~~ 以上代碼中還有一個關鍵函數makeAppCrashingLocked，其代碼如下： **ActivityManagerService.java::makeAppCrashingLocked** ~~~ private booleanmakeAppCrashingLocked(ProcessRecord app, String shortMsg, String longMsg, String stackTrace) { app.crashing = true; //生成一個錯誤報告，存放在crashingReport變量中 app.crashingReport = generateProcessError(app, ActivityManager.ProcessErrorStateInfo.CRASHED, null, shortMsg, longMsg, stackTrace); /* 在上邊代碼中，我們知道系統會通過APP_ERROR Intent啟動一個Activity去處理錯誤報告， 實際上在此之前，系統需要為它找到指定的接收者（如果有）。代碼在startAppProblemLocked 中，此處簡單描述該函數的處理過程如下： 1 先查詢Settings Secure表中“send_action_app_error”是否使能，如果沒有使能，則 不能設置指定接收者 2 通過PKMS查詢安裝此Crash應用的應用是否能接收APP_ERROR Intent。必須注意 安裝此應用的應用（例如通過“安卓市場”安裝了該Crash應用）。如果沒有，則轉下一步處理 3 查詢系統屬性“ro.error.receiver.system.apps”是否指定了APP_ERROR處理者，如果 沒有，則轉下一步處理 4 查詢系統屬性“ro.error.receiver.default”是否指定了默認的處理者 5 處理者的信息保存在app的errorReportReceiver變量中 另外，如果該Crash應用正好是串行廣播發送處理中的一員，則需要結束它的處理流程以 保證后續廣播處理能正常執行。讀者可參考skipCurrentReceiverLocked函數 */ startAppProblemLocked(app); app.stopFreezingAllLocked(); //調用handleAppCrashLocked做進一步處理。讀者可自行閱讀 returnhandleAppCrashLocked(app); } ~~~ 當App的Crash處理完后，事情并未就此結束，因為該應用進程退出后，之前AMS為它設置的訃告接收對象將被喚醒。接下來介紹AppDeathRecipientbinderDied的處理流程。