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

王余雷 童向杰

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

1 引言

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

2 研究方案

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

一般來說，開發(fā)人員分析解決智能終端穩(wěn)定性問題，可從軟件和硬件兩個(gè)維度進(jìn)行分析和方案檢驗(yàn)（參見圖1）。

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

圖1

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

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

（1）BootROM 啟動至Bootloader；

（2）Bootloader 啟動至Kernel；

（3）Kernel 加載文件系統(tǒng)和system_server 主服務(wù)等；

（4）system_server 等服務(wù)加載運(yùn)行各個(gè)應(yīng)用等。

當(dāng)開機(jī)啟動至Bootloader 階段，具有開發(fā)經(jīng)驗(yàn)的人員可推測與硬件相關(guān)性更大些；當(dāng)開機(jī)啟動至system_server 主服務(wù)階段，表明外設(shè)驅(qū)動基本功能正常，從而可推測與關(guān)鍵文件損壞或版本燒錄異常導(dǎo)致版本不完整等，或者與硬件受損導(dǎo)致漏電有關(guān)。

3 實(shí)踐分析

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

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

4 結(jié)束語

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