1. 項(xiàng)目概述MTK平臺(tái)AEE異常數(shù)據(jù)庫(kù)文件的定位與解析在MTK聯(lián)發(fā)科平臺(tái)的設(shè)備開發(fā)與維護(hù)過程中工程師們經(jīng)常會(huì)遇到一個(gè)棘手但又無法回避的問題系統(tǒng)或應(yīng)用發(fā)生嚴(yán)重異常如內(nèi)核崩潰、應(yīng)用無響應(yīng)、系統(tǒng)重啟后如何快速、準(zhǔn)確地定位問題根源答案往往就藏在那些自動(dòng)生成的、后綴為.db的AEEAndroid Exception Engine數(shù)據(jù)庫(kù)文件中。這些文件不是普通的日志文本而是MTK平臺(tái)特有的一套結(jié)構(gòu)化異常信息存儲(chǔ)系統(tǒng)它像是一個(gè)事發(fā)現(xiàn)場(chǎng)的“黑匣子”記錄了崩潰瞬間的進(jìn)程狀態(tài)、內(nèi)存快照、調(diào)用堆棧、寄存器值等關(guān)鍵法證信息。然而對(duì)于許多剛接觸MTK平臺(tái)的開發(fā)者或測(cè)試人員來說面對(duì)散落在設(shè)備存儲(chǔ)中各個(gè)角落的AEE db文件常常感到無從下手。如何系統(tǒng)地找到它們?nèi)绾闻袛嗄男┦恰爱惓！钡?、需要重點(diǎn)分析的找到了又該如何打開和解讀其中晦澀難懂的數(shù)據(jù)這構(gòu)成了一個(gè)從文件獲取到初步分析的小型技術(shù)閉環(huán)。本文將從一個(gè)資深嵌入式調(diào)試工程師的視角手把手拆解在MTK平臺(tái)上獲取所有異常AEE db文件的完整流程并深入探討其背后的原理、工具選用以及實(shí)戰(zhàn)中積累的避坑技巧。無論你是負(fù)責(zé)系統(tǒng)穩(wěn)定性優(yōu)化的開發(fā)還是需要進(jìn)行問題復(fù)現(xiàn)和提單的測(cè)試掌握這套方法都能極大提升你的問題排查效率。2. AEE異常報(bào)告系統(tǒng)核心機(jī)制解析要有效地獲取文件首先必須理解這些文件是如何被創(chuàng)建以及存儲(chǔ)在何處的。MTK的AEE系統(tǒng)是構(gòu)建在Android原生機(jī)制如tombstone、dropbox之上的一套增強(qiáng)型錯(cuò)誤收集框架其設(shè)計(jì)初衷是為了在資源有限的嵌入式環(huán)境中以更低的性能開銷捕獲更豐富的崩潰上下文信息。2.1 AEE異常觸發(fā)與文件生成流程當(dāng)系統(tǒng)發(fā)生嚴(yán)重錯(cuò)誤時(shí)觸發(fā)AEE收集的源頭主要有以下幾個(gè)內(nèi)核空間崩潰如內(nèi)核Oops、Panic通常由KEKernel Exception模塊處理。用戶空間原生層崩潰如Native進(jìn)程的段錯(cuò)誤SIGSEGV、中止信號(hào)SIGABRT由NENative Exception模塊處理。Java層崩潰與ANR應(yīng)用無響應(yīng)ANR或Java未捕獲異常由JEJava Exception模塊處理。硬件看門狗超時(shí)復(fù)位由HWHardware模塊處理。一旦這些異常被捕獲AEE守護(hù)進(jìn)程通常是/system/bin/aee或/vendor/bin/aee會(huì)被喚醒。它的工作流程可以概括為信息收集立即凍結(jié)現(xiàn)場(chǎng)收集崩潰進(jìn)程的完整內(nèi)存映射/proc/[pid]/maps、所有線程的調(diào)用棧通過ptrace或內(nèi)嵌的unwind庫(kù)、寄存器狀態(tài)、以及內(nèi)核的dmesg環(huán)形緩沖區(qū)的最新內(nèi)容。數(shù)據(jù)序列化將收集到的這些非結(jié)構(gòu)化的、海量的數(shù)據(jù)序列化并壓縮后寫入一個(gè)結(jié)構(gòu)化的SQLite數(shù)據(jù)庫(kù)文件中。這就是我們看到的.db文件。選擇SQLite而非純文本是為了便于高效地查詢和關(guān)聯(lián)不同類型的數(shù)據(jù)如將堆棧地址與符號(hào)表對(duì)應(yīng)。文件存儲(chǔ)生成的db文件會(huì)被存儲(chǔ)到指定的目錄下并遵循特定的命名規(guī)則以便于識(shí)別。2.2 AEE數(shù)據(jù)庫(kù)文件的存儲(chǔ)路徑與命名規(guī)則這是定位文件的關(guān)鍵。MTK平臺(tái)AEE文件的存儲(chǔ)路徑并非一成不變但遵循一定的規(guī)律。最常見的基礎(chǔ)路徑包括/data/aee_exp/這是最主要的存儲(chǔ)目錄絕大多數(shù)異常db文件都會(huì)放在這里或其子目錄下。該目錄需要root權(quán)限才能訪問。/data/vendor/aee_exp/在一些新的、遵循Treble架構(gòu)的設(shè)備上AEE組件可能被移到vendor分區(qū)因此異常文件也會(huì)存儲(chǔ)在此路徑。/sdcard/mtklog/aee_exp/或/storage/emulated/0/mtklog/aee_exp/為了方便在不獲取root權(quán)限的情況下拉取日志部分設(shè)備配置了將db文件同時(shí)或僅寫入到外部存儲(chǔ)sdcard的mtklog目錄下。這對(duì)于測(cè)試人員非常友好。/data/system/dropbox/ANR或一些系統(tǒng)級(jí)異常也可能被同時(shí)存入Android標(biāo)準(zhǔn)的dropbox目錄但這里的文件可能是文本格式.txt或經(jīng)過處理的原始的db文件通常仍在上述aee_exp目錄。文件的命名規(guī)則包含了關(guān)鍵元信息一個(gè)典型的文件名如下SYSTEM_JE2024-10-27-14_30_05_1240x12345678v1.db異常類型SYSTEM_JE。JE代表Java異常NE代表Native異常KE代表內(nèi)核異常HW代表硬件看門狗EXP代表通用異常。SYSTEM或SYSTEM_SERVER表示系統(tǒng)進(jìn)程。時(shí)間戳2024-10-27-14_30_05_124。精確到毫秒的異常發(fā)生時(shí)間對(duì)于問題時(shí)間線排序至關(guān)重要。哈?；驑?biāo)識(shí)符0x12345678。通常是崩潰地址或進(jìn)程ID的哈希值用于唯一標(biāo)識(shí)此次事件。版本號(hào)v1.db。AEE數(shù)據(jù)庫(kù)的格式版本。理解這些規(guī)則后我們就可以通過路徑和文件名模式在設(shè)備上精準(zhǔn)地定位到所有AEE db文件。3. 系統(tǒng)化獲取異常AEE db文件的實(shí)操方法知道了文件在哪接下來就是如何把它們“弄出來”。根據(jù)你的身份開發(fā)者、測(cè)試員和擁有的設(shè)備權(quán)限r(nóng)oot、非root方法有所不同。3.1 方法一通過ADB Shell命令直接查找與拉取需Root權(quán)限這是最直接、最完整的方法適合開發(fā)人員在自己的工程機(jī)上操作。步驟1連接設(shè)備并進(jìn)入ADB Shelladb shell su執(zhí)行su后在設(shè)備上授權(quán)root權(quán)限?？吹教崾痉?yōu)?即表示成功。步驟2定位AEE數(shù)據(jù)庫(kù)文件目錄# 查找所有可能的aee_exp目錄 find /data -name aee_exp -type d 2/dev/null find /data/vendor -name aee_exp -type d 2/dev/null # 如果開啟了sdcard存儲(chǔ)也可以查找 find /sdcard -name “aee_exp” -type d 2/dev/null通常主目錄是/data/aee_exp。進(jìn)入該目錄cd /data/aee_exp ls -la你會(huì)看到以日期命名的文件夾如20241027里面存放著當(dāng)天的異常db文件。步驟3篩選與識(shí)別“異?！蔽募⒎窃撃夸浵滤衐b文件都代表需要關(guān)注的嚴(yán)重異常。AEE系統(tǒng)有時(shí)也會(huì)記錄一些警告或信息性事件。如何篩選通過文件名優(yōu)先關(guān)注包含KE內(nèi)核錯(cuò)誤、JE/NE后跟關(guān)鍵進(jìn)程名如system_server、surfaceflinger、HW看門狗的文件。EXP類型需要結(jié)合時(shí)間判斷可能是一般性異常。通過文件大小一個(gè)只有幾KB的db文件可能只包含了簡(jiǎn)單的心跳信息而一個(gè)包含完整內(nèi)存dump的db文件可能達(dá)到幾MB甚至幾十MB后者肯定是需要重點(diǎn)分析的嚴(yán)重異常。通過時(shí)間戳與你發(fā)現(xiàn)設(shè)備出現(xiàn)問題的如重啟、卡死時(shí)間點(diǎn)最接近的文件就是首要分析對(duì)象。你可以使用組合命令來列出所有db文件并按時(shí)間排序find . -name “*.db” -type f | xargs ls -lt步驟4將文件拉取到本地電腦退出shell按CtrlD或輸入exit回到本地命令行。使用adb pull命令。# 拉取整個(gè)aee_exp目錄文件可能很多體積大 adb pull /data/aee_exp/ ./ # 或者只拉取特定文件 adb pull /data/aee_exp/20241027/SYSTEM_JE2024-10-27-14_30_05_1240x12345678v1.db ./注意/data分區(qū)下的文件需要root權(quán)限才能讀取。如果adb pull失敗并提示“權(quán)限被拒絕”請(qǐng)確保你在ADB Shell中已經(jīng)成功執(zhí)行了su并且有些設(shè)備可能需要先remount分區(qū)。更穩(wěn)妥的方式是先在shell內(nèi)用cat或dd命令將文件拷貝到/sdcard再?gòu)?sdcard拉取。3.2 方法二利用MTKLogger工具獲取無需Root權(quán)限對(duì)于測(cè)試人員或無法獲取root權(quán)限的場(chǎng)景MTK官方提供了一個(gè)用戶友好的工具——MTKLogger。它是一個(gè)系統(tǒng)應(yīng)用可以圖形化地開啟日志錄制并在結(jié)束后打包所有日志包括AEE db文件供導(dǎo)出。操作流程在設(shè)備上找到并打開“MTKLogger”或“日志工具”應(yīng)用。在設(shè)置中務(wù)必確保勾選“AEE異常日志”或“Mobile Log”中的“AEE”選項(xiàng)。默認(rèn)可能不開啟。開始錄制日志。此時(shí)你可以開始復(fù)現(xiàn)你遇到的異常問題。問題復(fù)現(xiàn)后停止錄制。MTKLogger會(huì)將錄制期間產(chǎn)生的所有日志包括AEE db、kernel log、modem log等打包成一個(gè)壓縮文件通常存儲(chǔ)在/sdcard/mtklog/下文件名包含時(shí)間戳。通過USB連接電腦直接在/sdcard/mtklog/目錄下找到最新的壓縮包或者使用MTKLogger應(yīng)用內(nèi)的“發(fā)送”功能分享到電腦。優(yōu)缺點(diǎn)分析優(yōu)點(diǎn)無需root操作簡(jiǎn)單能一次性獲取完整的問題上下文日志包。缺點(diǎn)日志文件體積巨大AEE db文件可能不是實(shí)時(shí)生成的而是錄制結(jié)束后才統(tǒng)一收集如果問題發(fā)生概率低長(zhǎng)時(shí)間錄制會(huì)影響設(shè)備性能和存儲(chǔ)空間。3.3 方法三從系統(tǒng)Bugreport中提取Android系統(tǒng)的bugreport命令也會(huì)收集AEE異常信息但通常不是原始的.db文件而是經(jīng)過解析后的文本摘要。不過這是獲取問題初步線索的一個(gè)快速途徑。adb bugreport生成的bugreport壓縮包中在FS/data/aee_exp/或類似路徑下你可能會(huì)找到db文件的副本但更常見的是在main_entry.txt或SYSTEM_JE_2024-10-27-14_30_05_124.txt這樣的文本文件中看到解析后的關(guān)鍵堆棧信息。4. 解析AEE db文件工具選擇與核心數(shù)據(jù)解讀獲取到db文件只是第一步如何“打開”并讀懂它才是關(guān)鍵。AEE db文件是SQLite 3格式但直接用通用的SQLite瀏覽器查看你會(huì)看到一堆難以理解的二進(jìn)制數(shù)據(jù)和表結(jié)構(gòu)。4.1 官方解析工具AEE Database ParserMTK為內(nèi)部開發(fā)和合作伙伴提供了專門的解析工具通常是一個(gè)Python腳本如aee_extract.py或可執(zhí)行文件。它的核心功能是解析數(shù)據(jù)庫(kù)結(jié)構(gòu)讀取db文件中的各個(gè)數(shù)據(jù)表如summary,backtrace,memory,register,maps等。符號(hào)化Symbolize這是最關(guān)鍵的一步。工具需要你提供對(duì)應(yīng)系統(tǒng)版本的符號(hào)表文件Symbol files 通常是*.sym或從編譯產(chǎn)物中提取的vmlinux和帶有調(diào)試信息的庫(kù)文件。通過符號(hào)表工具能將堆棧中的內(nèi)存地址如0x7f8a3b4c轉(zhuǎn)換為具體的函數(shù)名和代碼行號(hào)如libc.so!malloc0x1c。生成可讀報(bào)告最終輸出一個(gè)結(jié)構(gòu)化的文本報(bào)告通常是.txt文件包含清晰的異常類型、崩潰線程的完整調(diào)用棧、寄存器值、內(nèi)存映射、以及可能的疑似根本原因提示。使用官方工具的基本命令流如下# 假設(shè)你已有解析工具aee_parser和符號(hào)表目錄symbols/ python aee_parser.py -d SYSTEM_JE2024-10-27-14_30_05_1240x12345678v1.db -s ./symbols -o ./parsed_report.txt執(zhí)行后打開parsed_report.txt你就能看到人類可讀的崩潰分析了。4.2 備用方案DB Browser for SQLite的輔助查看如果你暫時(shí)沒有官方解析工具可以使用開源的DB Browser for SQLite (DB4S)來應(yīng)急查看db文件的結(jié)構(gòu)和原始數(shù)據(jù)。這在判斷文件是否完整、快速查看異常類型和時(shí)間時(shí)有用。操作步驟從官網(wǎng)下載并安裝DB Browser for SQLite。用DB4S打開一個(gè)AEE db文件。切換到“瀏覽數(shù)據(jù)”選項(xiàng)卡你會(huì)看到多個(gè)表。最重要的幾張表是summary 包含異常類型、進(jìn)程名、PID、時(shí)間戳等概要信息。backtrace 存儲(chǔ)原始的內(nèi)存地址堆棧。process和thread 記錄進(jìn)程和線程信息。detail 可能包含額外的詳細(xì)信息。重要提示DB4S無法進(jìn)行符號(hào)化。你在backtrace表里看到的是一長(zhǎng)串十六進(jìn)制地址沒有函數(shù)名這對(duì)于問題定位價(jià)值有限。它主要用于驗(yàn)證文件完整性或提取元數(shù)據(jù)。4.3 解讀解析報(bào)告中的關(guān)鍵信息拿到解析后的文本報(bào)告你應(yīng)該關(guān)注以下部分異常摘要 (Exception Summary)Build Fingerprint: ‘vendor/xxx/yyy:11/RP1A.200720.012/eng.user.20241027.123456:userdebug/test-keys’ Process: system_server [pid: 1234] Exception Type: JE (Java Exception) Exception Time: 2024-10-27 14:30:05 Reason: java.lang.NullPointerException: Attempt to invoke virtual method ‘void android.widget.TextView.setText(java.lang.CharSequence)’ on a null object reference這里告訴你是什么進(jìn)程、在什么時(shí)間、因?yàn)槭裁丛虮罎⒌?。?duì)于JE異常Reason字段直接給出了Java異常堆棧的第一行是定位問題的黃金線索。崩潰線程調(diào)用棧 (Crash Thread Backtrace)#00 pc 0000000000123456 /system/lib64/libandroid_runtime.so (android::NativeException::throwNullPointerException(_JNIEnv*, jstring)0x1a) #01 pc 0000000000abcdef /system/framework/arm64/boot-framework.oat (android.app.ActivityThread.performLaunchActivity0x1234) ...符號(hào)化后的堆棧顯示了從崩潰點(diǎn)開始函數(shù)調(diào)用的層層回溯。你需要從下往上從#00開始或從上往下從最外層開始尋找你自己編寫的代碼或熟悉的系統(tǒng)模塊。pc后面的地址和庫(kù)文件信息結(jié)合源碼可以精確定位。寄存器狀態(tài) (Register State) 對(duì)于NE/KE異常寄存器值如x0-x30,pc,sp,lr極其重要。pc程序計(jì)數(shù)器指向崩潰時(shí)執(zhí)行的指令地址lr鏈接寄存器通常保存著返回地址能幫助還原調(diào)用鏈。內(nèi)存映射 (Memory Maps) 列出了崩潰進(jìn)程加載的所有內(nèi)存區(qū)域庫(kù)、代碼段、數(shù)據(jù)段的起始-結(jié)束地址和權(quán)限。這用于驗(yàn)證堆棧地址是否落在某個(gè)可執(zhí)行的庫(kù)中也是符號(hào)化工具工作的依據(jù)。5. 實(shí)戰(zhàn)疑難排查與經(jīng)驗(yàn)技巧實(shí)錄在實(shí)際操作中你肯定會(huì)遇到各種預(yù)料之外的情況。下面分享一些從大量實(shí)戰(zhàn)中總結(jié)出來的經(jīng)驗(yàn)和“坑點(diǎn)”。5.1 常見問題速查表問題現(xiàn)象可能原因排查步驟與解決方案adb shell后su失敗提示Permission denied或沒有#提示符1. 設(shè)備未解鎖Bootloader或未刷入帶root權(quán)限的系統(tǒng)。2. 工程機(jī)可能需要在開發(fā)者選項(xiàng)中開啟“Root權(quán)限”或“ADB調(diào)試安全設(shè)置”。3. 臨時(shí)root方案失效。1. 確認(rèn)使用的是工程機(jī)或userdebug版本的設(shè)備零售機(jī)(user版本)通常無法獲取root。2. 檢查開發(fā)者選項(xiàng)中的“USB調(diào)試安全設(shè)置”是否允許授予shell root權(quán)限。3. 嘗試使用adb root命令僅適用于部分開啟該服務(wù)的調(diào)試版本。adb pull /data/aee_exp失敗提示remote couldn’t create file: Read-only file system/data分區(qū)在正常系統(tǒng)下以只讀方式掛載給ADB。方法1推薦在adb shell內(nèi)先將文件復(fù)制到可讀寫的目錄如/sdcardcp /data/aee_exp/xxx.db /sdcard/然后從本地執(zhí)行adb pull /sdcard/xxx.db ./方法2重啟設(shè)備到recovery模式有時(shí)可以以讀寫方式掛載/data分區(qū)。使用官方解析工具時(shí)符號(hào)化失敗堆棧全是[unknown]或地址1. 使用的符號(hào)表文件與產(chǎn)生db文件的系統(tǒng)版本不匹配。2. 符號(hào)表文件路徑錯(cuò)誤或文件損壞。3. 工具版本與db文件格式版本不兼容。1.嚴(yán)格匹配版本確保符號(hào)表來自編譯該設(shè)備系統(tǒng)鏡像的完全相同的代碼版本包括代碼提交哈希、編譯時(shí)間。差一個(gè)提交都可能導(dǎo)致偏移量對(duì)不上。2. 檢查符號(hào)表目錄結(jié)構(gòu)通常需要包含system、vendor、product等子目錄里面是對(duì)應(yīng)的.so.sym或未strip的.so文件。內(nèi)核符號(hào)需要vmlinux。3. 咨詢平臺(tái)提供方獲取正確版本的解析工具。MTKLogger沒有生成AEE db文件1. AEE日志功能未在MTKLogger中啟用。2. 異常類型可能被配置為不記錄db如某些低內(nèi)存場(chǎng)景。3. 存儲(chǔ)空間已滿。1. 打開MTKLogger進(jìn)入設(shè)置仔細(xì)檢查“Mobile Log”或“AEE Log”的開關(guān)是否打開。2. 檢查系統(tǒng)屬性persist.vendor.aee.core的值通過adb shell getprop確保不是disable。3. 嘗試手動(dòng)觸發(fā)一個(gè)已知的崩潰如kill -11 [system_server_pid]看是否能生成db文件以驗(yàn)證功能是否正常。db文件用DB Browser打開后表是空的或損壞db文件在生成或傳輸過程中損壞。1. 嘗試重新從設(shè)備拉取文件。2. 在設(shè)備上使用sqlite3 /path/to/file.db “.schema”命令檢查數(shù)據(jù)庫(kù)結(jié)構(gòu)是否完整。3. 如果文件來自sdcard檢查存儲(chǔ)卡是否有壞塊。5.2 高級(jí)技巧與心得自動(dòng)化抓取腳本如果你需要頻繁抓取日志可以寫一個(gè)簡(jiǎn)單的shell腳本放在設(shè)備里需要root定時(shí)檢查/data/aee_exp目錄將新產(chǎn)生的db文件自動(dòng)拷貝到sdcard的某個(gè)目錄方便后續(xù)批量拉取。#!/system/bin/sh # 一個(gè)簡(jiǎn)單的示例腳本 SOURCE_DIR“/data/aee_exp” DEST_DIR“/sdcard/auto_collected_aee” mkdir -p $DEST_DIR # 查找過去10分鐘內(nèi)修改過的db文件并復(fù)制 find $SOURCE_DIR -name “*.db” -mmin -10 -exec cp {} $DEST_DIR \;優(yōu)先分析“新鮮”且“完整”的文件設(shè)備重啟后舊的aee_exp目錄可能會(huì)被清理或歸檔。因此問題發(fā)生后第一時(shí)間抓取的文件最有價(jià)值。同時(shí)通過文件大小初步判斷一個(gè)完整的KE db通常大于1MB一個(gè)包含system_server完整堆棧的JE db也至少有幾百KB太小的文件信息量可能不足。結(jié)合其他日志綜合分析AEE db是“現(xiàn)場(chǎng)快照”但要還原“事故全過程”還需要結(jié)合其他動(dòng)態(tài)日志Kernel Log (dmesg或kernel.log)查看崩潰前后內(nèi)核打印的信息有助于理解硬件驅(qū)動(dòng)、內(nèi)存管理等方面的底層問題。Android Log (logcat)查看應(yīng)用層和系統(tǒng)服務(wù)的打印輸出了解崩潰前的業(yè)務(wù)邏輯和錯(cuò)誤警告。Tombstones對(duì)于Native崩潰Android原生的tombstone文件/data/tombstones/與AEE NE db內(nèi)容互補(bǔ)可以對(duì)照分析。符號(hào)表的管理是一門學(xué)問對(duì)于持續(xù)集成的項(xiàng)目建議建立自動(dòng)化系統(tǒng)在每次構(gòu)建版本時(shí)自動(dòng)歸檔對(duì)應(yīng)的符號(hào)表文件包括內(nèi)核的vmlinux和所有動(dòng)態(tài)庫(kù)的未strip版本?？梢园礃?gòu)建編號(hào)或日期組織這樣在分析任何歷史版本的崩潰文件時(shí)都能快速找到匹配的符號(hào)表。理解“異?！辈坏扔凇癇ug”有些AEE異常是預(yù)期的例如內(nèi)核在內(nèi)存極度緊張時(shí)主動(dòng)觸發(fā)KE來殺死進(jìn)程以回收內(nèi)存。分析時(shí)需結(jié)合具體場(chǎng)景。重點(diǎn)應(yīng)關(guān)注那些導(dǎo)致用戶體驗(yàn)受損如應(yīng)用閃退、系統(tǒng)重啟的、可穩(wěn)定復(fù)現(xiàn)的異常。通過這套從獲取到解析的完整流程你就能系統(tǒng)化地處理MTK平臺(tái)上的異常問題。核心在于理解AEE系統(tǒng)的運(yùn)作機(jī)制熟練運(yùn)用ADB和文件操作命令并掌握符號(hào)化解析的核心技能。這就像偵探破案AEE db是核心物證而你的工具和知識(shí)就是解讀物證、還原真相的關(guān)鍵。