它來了、它來了，它帶着BUG趕來了，歡迎大家查看本期的安卓源碼避坑指南。本期的問題場景比較特殊，電話SIM卡是無效的（欠費過期了，很是貧窮…）。

開開心心地上着班、摸着魚（笑臉），突然工作郵件提醒，一經查看原來是QA同學甩過來個問題。那咱就話不多說，先簡單介紹下本篇的問題場景。

測試環境：Android 9的車機系統 手機中的SIM卡為無效SIM卡

測試步驟：

1. 車機和手機使用藍牙相互連接成功
2. 車機端主動撥打電話

測試現象：由于手機中SIM卡為無效電話卡所以電話撥打失敗，但是幾秒鐘過後手機與車機間的藍牙連接斷開

當看到這麼個場景 問題現象後，我是懵逼的，打個電話藍牙連接就斷開，這麼牛逼的嗎？經過分析logcat發現藍牙服務進程号有改變，那問題原因指向就很明顯了：

• 用戶主動開關藍牙
• 藍牙服務crash

由于測試步驟中不涉及開關藍牙操作，那肯定就是藍牙服務進程crash。根據這個基本判斷提取相關crash-log做進一步分析。

從以上log明顯看到程序運行過程中遇到空指針調用從而引發 com.android.bluetooth 進程crash，導緻藍牙連接斷開的問題根因crash找到了，那是怎麼觸發這個crash的呢？我們試着從源碼分析下這塊的流程。

首先查看snoop文件，由于問題産生時隻有撥打電話的操作，所以分析下AT命令的交互：

從HCI上可以看出AT交互很簡單，就是一條ATD指令請求撥打電話，由于手機SIM卡無效，10s手機回複了錯誤的AT命令。10s的時間設定是因為手機藍牙服務HeadsetService. dialOutgoingCall( )在收到AT撥打電話指令後會給電話模塊發送對應的廣播并設置定時器：

手機端撥打電話10s超時後發送 AT_RESPONSE_ERROR 回複車機藍牙，那車機收到這條錯誤指令後是怎麼處理才導緻crash了呢？咱就跟着程序分析下去，處理的時序圖如下：

由于這個特殊場景使得HfpClientConnectionService對于這次撥打電話的操作而言第一次接收到的ACTION_CALL_CHANGED中call.state就是CALL_STATE_TERMINATED，從而初始化HfpClientConnection時調用了close()将mCurrentCall又置為空值，這樣才遇到mCurrentCall.getNumber() 對空指針取值引發crash。

分析到這裡我們都知道mCurrentCall的值為空的原因了，那對應的解決方案就請大家集思廣益在評論區一起交流讨論吧！

經過這樣類似問題的回溯，我不禁對QA測試工程師越發佩服，因為使用的手機中SIM卡是無效卡的情況幾乎不可能遇到，那對于本期分析的問題就很難被發現。正是QA們天馬行空的魔鬼操作才讓這些問題提前暴露出來，讓藍牙系統整體上更穩定，給測試大佬們敬茶 -_-。

本期是安卓源碼避坑指南系列的第三篇文章了，想了解更多安卓源碼bug的同學可以翻看以前的文章，也歡迎感興趣的小夥伴私信留言共同學習。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!