Android平臺智能終端開機定屏問題研究與分析

王余雷 童向杰

（中興通訊股份有限公司 江蘇省南京市 210012）

1 引言

隨著智能終端和移動互聯網絡的技術發展,智能終端得到越來越廣泛的使用，且其功能變得越來越復雜。對于智能終端開發人員來說，智能終端的穩定性是衡量產品質量的一個重要指標:在產品開發、測試和生產等過程中，開發人員需要進行單元測試、MTBF、老化測試、模糊測試、系統測試、模擬用戶測試等；在產品售后維修等過程中，開發人員需要進行客退故障樣機進行剖析和質量回溯，并且將相應的成果及時地應用到后續產品的版本演進和流程優化等。基于此，本文提出了從軟件和硬件(含部件)兩大維度進行穩定性問題分析的策略，側重于以Android平臺智能終端的開機定屏問題為對象進行了深入地研究和剖析，以及進行了方案驗證，從而給開發人員呈現一個較為全面的參考。

2 研究方案

Android平臺智能終端的穩定性問題有多種多樣，比如:無法開機、開機黑屏、開機定屏、反復重啟，等等。本文提出了從軟件和硬件(含部件)兩大維度進行穩定性問題分析的策略，并且此策略可能不局限于Android 平臺；本文側重于以Android平臺智能終端的開機定屏問題為對象進行了深入地研究和剖析，對某項目的小概率開機定屏問題和某項目的PMIC 受損問題進行實例分析和驗證，從而給開發人員呈現一個較為全面的參考。

一般來說，開發人員分析解決智能終端穩定性問題，可從軟件和硬件兩個維度進行分析和方案檢驗（參見圖1）。

從軟件方面進行著手分析，首先，盡可能地第一時間獲取到發生故障時更為全面的日志信息，如Android 系統和內核打印信息，ramdump，coredump，串口打印信息，發生段錯誤時backtrace 信息，等等；在獲取日志信息后，根據時間戳或關鍵字符串可能會快速定位到故障現場，再結合異常打印信息和模塊設計邏輯進行分析和推測等，這就是所謂的日志分析法。通常來講，大部分問題都能從日志信息中發現蛛絲馬跡，尤其是軟件原因所導致的問題。若開發人員可從日志文件中分析出指向性的結論，則接下來就可對相應模塊的程序設計進行原因分析與方案求證。其次，若開發人員較難地從日志文件中得出指向性的結論，則盡可能地獲取到故障樣機，然后進行現場診斷：為了快速定位問題，通常開發人員會在版本中集成一些的工具，如:應用鏡像文件完整性檢查、刷機版本有效性檢查、內存模型測試、部件功能自檢等；還可考慮從故障樣機中導出userdata 鏡像文件后再燒錄至另外一臺樣機，檢查是否可再現故障；還可考慮插入USB 數據線或按鍵，觀察故障現象是否有變化，等等。這就是所謂的現場診斷法。接著，開發人員需要厘清一下該故障是單機問題還是多臺樣機共性問題，嘗試去探索出故障復現規律或評估粗略的復現概率。對于可復現的故障，開發人員可考慮恢復至默認的出廠版本，觀察故障現象是否存在；或者燒錄不同版本進行對比分析與回溯，觀察故障現象是否存在。這就是所謂的版本對比法；為了提升復現概率，開發人員可考慮進行MTBF、Monkey、常溫環境下eMMC 和DDR 壓力測試、高溫低壓環境下eMMC 和DDR測試、定制化的自動化測試等，觀察在哪些場景下或哪條操作路徑下可更高概率地復現故障。這就是所謂的壓力測試法；為了求證所推測的異常點，開發人員還可考慮在源代碼中增加打印語句或統計信息進行打點分析。這就是所謂的打點分析法。而對于推測求證法，通常是憑借開發人員的經驗進行大膽推測，然后進行邏輯嚴謹的求證，其分析方法貫穿于問題分析的核心過程。最后，開發人員可考慮組織關聯的領域專家進行集中討論和診斷，再針對每項可能的原因或舉措進行求證。這就是所謂的專家會診法。

圖1

若從軟件方面較難地得出具有指向性的結論，開發人員則可考慮從硬件方面進行著手分析，首先，通過假電池連接安捷倫直流電源進行開機過程中不同階段的電流測量，分析其電流值是否異常，若存在明顯的異常，則可能存在硬件受損而導致漏電等問題。這就是所謂的電流分析法。接著，對于可復現的故障，開發人員可分兩個階段進行硬件最小系統的構建：第一階段，拆除部件外設和拔掉SIM 卡、SD 卡等，觀察故障現象是否存在；第二階段，針對某一塊故障單板進行在板器件的拆除，僅僅保留CPU、內存和PMIC 等硬件最小系統，再觀察故障現象是否存在。這就是所謂的最小系統法。再者，開發人員可對發生故障時單板的器件或部件的管腳進行信號測量與記錄，同時對正常工作時單板的器件或部件的管腳進行信號測量與記錄，兩者進行對比分析；為了求證最小系統的eMMC 和DDR 功能性，開發人員可采用燒錄版本至故障樣機，確認其下載或開機等功能是否正常；為了求證最小系統的可見的器件焊接等問題，開發人員可使用風槍進行短暫加熱，觀察故障現象是否存在；為了求證最小系統的供電問題，開發人員可考慮采用外供電源的方法，觀察故障現象是否存在；等等。然后，若硬件最小系統仍然存在相應的故障現象，則需要產線人員參與分析是否與主板或最小系統的CPU/eMMC+DDR/PMIC 等有關，可考慮采用交叉驗證法、X-Ray 檢查法、切片分析法、紅墨水實驗法等。最后，開發人員可考慮聯絡平臺廠家或者eMMC+DDR 的原廠，對于可能與eMMC+DDR 有關的問題，則可考慮讓原廠安排技術人員現場支持，并且安排故障樣機的單體功能測試和單板的DDR 夾具測試，確認單體功能是否正常和DDR 的時序及眼圖等是否正常。

開機定屏，是指智能終端在開機的過程中，出現長時間停在一個界面上而無法正常進行操作的問題現象。一般來說，在開啟日志打印情況下，開發人員可獲取智能終端開機過程的日志信息，就可定位開機啟動至哪個階段發生故障現象。開機過程可粗略地劃分為四個階段：

（1）BootROM 啟動至Bootloader；

（2）Bootloader 啟動至Kernel；

（3）Kernel 加載文件系統和system_server 主服務等；

（4）system_server 等服務加載運行各個應用等。

當開機啟動至Bootloader 階段，具有開發經驗的人員可推測與硬件相關性更大些；當開機啟動至system_server 主服務階段，表明外設驅動基本功能正常，從而可推測與關鍵文件損壞或版本燒錄異常導致版本不完整等，或者與硬件受損導致漏電有關。

3 實踐分析

MTK 平臺某款智能手機發生小概率的開機定屏問題，其分析思路是: 首先，從軟件維度來看，獲取到故障樣機，采用現場診斷法進行常規的診斷，通過組合按鍵進入Recovery 模式，執行應用鏡像文件完整性檢查、Root 檢查等，其測試結果正常；通過特定的操作進入工程模式，執行memtester 內存模型測試等，其測試結果正常；然后開啟日志打印功能。再次重啟開機，該故障仍然存在，抓取從開機啟動至定屏整個過程完整的日志信息。根據日志信息初步分析的結論是: Kernel 啟動正常，而在系統服務啟動時發現如下的異常打印信息:

從上述的異常日志信息和JAVA Stack 來看，表明系統服務PackageManager 解析xml 文件時發生嚴重的錯誤。因而，將故障樣機中所解析的packages.xml 或packages-backup.xml 文件導出，通過查看和比對相應文件的內容，確認是packages.xml 文件損壞導致xml 解析錯誤，進而導致Android 平臺的系統主進程system_server無法正常啟動，從而表現為開機定屏的問題現象。至此，基本上即可得出了指向性的結論，進而可大膽地推測與eMMC 和DDR 或者文件系統有關。其次，為了排查是否與eMMC 和DDR 電氣特性有關，進行了ETT 高溫低壓等場景下的壓力測試，使用了FlashTool工具的Memory Test 功能測試等；同時組織硬件領域專家進行會診和走查原理圖、布線等，其結論是測試等正常，暫未發現設計問題。接著，為了提升分析效率和快速驗證方案有效性，需要嘗試增加復現概率或找出復現規律，協調測試人員參與安排該項目的MTBF測試、CTS 測試、Monkey 測試和模擬用戶測試等，通過壓力測試發現了發生同類型的故障的樣機，由此，表明該故障是可復現的。同時開發人員對packages.xml 文件生成原理進行了研究:該文件是由PackageManagerService.java 生成，其文件內容記錄了Android 系統中所安裝的APK 應用程序的所有屬性、權限等信息，當Android系統安裝、卸載、更新APK 應用程序時，packages.xml 文件都會被更改。從而，開發人員發現了一個非常有價值的突破口:通過自動化腳本實現反復安裝和卸載APK 應用程序，以達到packages.xml文件被反復更改的目的，進而可能達成增加復現概率。其方案是:利用Android 平臺monkeyrunner 測試框架和Python 語言編寫自動化測試腳本，實現安裝APK 應用程序后重啟智能手機，并且將啟動路徑下不同階段的packages.xml 導出至電腦端；然后選取三部故障樣機進行了壓力測試。其結果是以約2%概率復現了該故障。再者，考慮采用推測求證法，根據以往的故障經驗進行大膽地推測和小心地求證，推測是否可能與內存數據未能完整地同步至eMMC 有關，為此，優化自動化測試腳本在特定階段通過Python 腳本調用sync操作，求證故障現象是否存在；其結果是測試10000 次，未復現故障，至此，問題根因有了更為明確的指向性，其原因大概率的是與軟件（含固件）配置有關。最后，開發人員采用版本對比法進行了不同的版本和不同eMMC+DDR 廠家的對比測試，開發人員求證了某兩個時期版本故障現象存在差異，進一步地了解到MTK 平臺近期文件系統增加了discard 屬性配置，研究了JEDEC 規范中discard 屬性，其要點是執行discard 時要防止意外的數據丟失；同時還求證了采用三星廠家的芯片不存在此問題，開發人員和Hynix 原廠技術支持進行溝通，了解到該款芯片的某固件版本存在設計缺陷，未能正確地處理discard 屬性配置。至此，問題的根因是與Hynix 芯片的某固件版本未能正確地處理discard 屬性有關。考慮升級eMMC 芯片固件的成本，開發人員提出了最終的解決方案是MTK 平臺去掉文件系統的discard 屬性配置，針對此解決方案，進行了累計60000次的自動化測試，未復現故障。

4 結束語

本文提出了從軟件和硬件(含部件)兩大維度進行穩定性問題分析的策略，并且此策略可能不局限于Android 平臺；本文側重于以Android平臺智能終端的開機定屏問題為對象進行了深入地研究和剖析，以及進行了方案驗證，從而給開發人員呈現一個較為全面的參考。