在基于ARM的設(shè)計上調(diào)試Android平臺

如果不觸及 Android 軟件堆棧的內(nèi)部，就無法在新設(shè)備上啟動 Android。雖然 Java 應(yīng)用層在很大程度上保持不變，但必須在 Java 原生層、硬件適配層以及底層 Linux 內(nèi)核及其驅(qū)動程序中完成工作。此外，特定于設(shè)備的服務(wù)和應(yīng)用程序需要與 Android 的其余部分一起集成和測試。

在軟件堆棧中的所有這些層之間垂直集成設(shè)備功能是一個相當(dāng)大的挑戰(zhàn)。在單層中隔離和調(diào)試一個軟件模塊可能很困難；更重要的是，任何調(diào)試框架都不支持跨所有層調(diào)試多個交互模塊，因此需要耐心和許多 printf 跟蹤消息。

為了解決這個問題，CoWare 開發(fā)了適用于 Android 的 Virtual ARM 開發(fā)板，它提供了一個 Android 感知的調(diào)試和分析框架，支持確定性和連續(xù)的自上而下的調(diào)試方法。Android 意識首先通過檢測和跟蹤 ARM Linux 操作系統(tǒng)上下文（如中斷處理程序、內(nèi)核線程、驅(qū)動程序和用戶空間進(jìn)程）的能力而引人注目。立即觀察進(jìn)程調(diào)度的能力可以洞察整個系統(tǒng)行為。

例如，圖 1 顯示了設(shè)備從深度睡眠掛起模式恢復(fù)后系統(tǒng)死鎖的在線上下文跟蹤。當(dāng)設(shè)備喚醒但未對任何按鍵或觸摸屏做出反應(yīng)時，系統(tǒng)陷入軟件中斷 （swi） 處理程序和 Android 的輸入設(shè)備讀取器進(jìn)程 （InputDeviceRead） 之間的死鎖。通過這種分析，很明顯沒有其他重要進(jìn)程（例如窗口管理器）用于處理按鍵操作。

圖 1：在線上下文跟蹤顯示設(shè)備從深度睡眠掛起模式喚醒后出現(xiàn)系統(tǒng)死鎖。

支持自上而下的調(diào)試流程，每個過程都可以在功能上進(jìn)一步研究到指令級。甚至可以跟蹤內(nèi)存訪問，從而可以有效地分析軟件堆棧中各層的行為。

圖 2 說明了 Android 輸入設(shè)備讀取器進(jìn)程與內(nèi)核軟件中斷之間的函數(shù)級交互。識別實際執(zhí)行的代碼有助于隔離大型第三方軟件代碼庫中需要開發(fā)人員注意的位置，并演示軟件如何跨各個層進(jìn)行交互。在圖 2 中，觀察 Android 中間件函數(shù) read_notify 如何觸發(fā)內(nèi)核軟件中斷 swi。

圖 2：調(diào)試 Android 用戶空間和 Linux 內(nèi)核之間的差距展示了軟件堆棧中跨層的行為。

分析解決方案集成了 Android 和 Linux 中存在的日志記錄和跟蹤功能。無需對軟件的任何部分進(jìn)行檢測或更改，Android 記錄器和內(nèi)核調(diào)試消息就會與之前引入的跟蹤一起被捕獲和可視化。這樣，開發(fā)人員可以繼續(xù)使用那些具有附加值的工具，即所有日志和跟蹤都同步，并且可以輕松地與流程和軟件功能相關(guān)聯(lián)，如圖 3 所示。

圖 3：開發(fā)人員可以可視化 Android 記錄器和內(nèi)核調(diào)試消息以及之前引入的跟蹤。

請注意，Android 日志并沒有與重要的內(nèi)核調(diào)試消息分開，查看這些消息不再需要工作的用戶空間應(yīng)用程序（例如 dmesg 或 logcat）。當(dāng)系統(tǒng)損壞并且查看器應(yīng)用程序或調(diào)試橋不再運行時，通常需要訪問跟蹤。一個示例是引導(dǎo)的早期階段或與深度睡眠模式之間的轉(zhuǎn)換。該分析解決方案通過虛擬平臺提供的非侵入式控制和檢查功能直接從嵌入式軟件中捕獲跟蹤。

虛擬 ARM 開發(fā)板和工具通過強(qiáng)大的系統(tǒng)級分析工具補充了現(xiàn)有的 Android 開發(fā)環(huán)境。該板可與使用 Android 調(diào)試橋的 Google Eclipse SDK 等工具配合使用。RealView Debugger （RVD）、Lauterbach 或 Data Display Debugger （DDD） 等最先進(jìn)的調(diào)試器可以使用板作為目標(biāo)而不是硬件來執(zhí)行嵌入式軟件調(diào)試（參見圖 4）。

這種高水平的可見性以及非侵入式檢查和可控性使調(diào)試 Android 成為一項更加簡化和可預(yù)測的任務(wù)。

審核編輯：郭婷