做瑞芯微RK平臺Android開發(fā)/技術支持的同學，想必都遇見過內核panic、應用Crash、ANR這類頭疼的問題，排查的核心難點往往是日志難獲取、有效信息少、user版本無日志。而瑞芯微自研的RK Android LOG系統(tǒng)，完美解決了這些痛點——它基于異常觸發(fā)記錄日志，user版本可用，還能自動保存內核和Android層的各類異常信息，是RK平臺問題排查的核心工具。

今天這篇文章，我們就把這套LOG系統(tǒng)的使用方法、排查思路、配置技巧講透，從日志存儲、獲取到問題定位，一步到位幫你搞定RK平臺的Android問題排查！

一、先搞懂：RK LOG系統(tǒng)的核心優(yōu)勢

和傳統(tǒng)Android日志系統(tǒng)相比，RK LOG系統(tǒng)專為線上/線下問題排查設計，核心亮點直擊開發(fā)者痛點，也是我們優(yōu)先選擇它的原因：

1.User版本可用：無需切換到userdebug/eng版本，線上設備也能捕獲異常日志，解決線上問題排查無日志的核心難題；

2.異常觸發(fā)式記錄：避免無意義日志刷屏，僅當系統(tǒng)出現(xiàn)異常時才生成日志，有效信息密度高；

3.全鏈路異常捕獲：既支持內核層panic/卡死，也能捕獲Android層Crash/ANR/低內存/Watchdog等幾乎所有異常；

4.重啟后日志不丟失：內核panic重啟、Android系統(tǒng)重啟后，會自動保存重啟前的異常信息，不會因重啟丟失關鍵日志；

5.存儲與訪問便捷：日志有固定存儲路徑，還提供軟鏈接快速訪問，支持ADB和U盤/SD卡兩種獲取方式；

6.智能控容+防抖：限制日志總大小，自動刪除最早日志；相同異常5分鐘內僅記錄一次，避免日志爆倉。

二、基礎必備：日志的存儲路徑與獲取方式

排查問題的第一步，是找到日志在哪、怎么把日志拿到本地。RK LOG系統(tǒng)的日志存儲做了專門的優(yōu)化，路徑清晰、獲取方式簡單，新手也能快速上手。

2.1日志存儲路徑（核心）

所有異常日志最終都保存在主路徑：

/data/user_de/0/com.android.shell/files/bugreports

為了方便開發(fā)者訪問，系統(tǒng)在根目錄創(chuàng)建了軟鏈接，直接訪問以下路徑即可，無需輸入長路徑：

/bugreports/

（驗證軟鏈接：在設備端執(zhí)行l(wèi)s bugreports -l，可看到鏈接指向主路徑）

2.2兩種日志獲取方式

方式1：ADB命令獲取（推薦開發(fā)/調試時使用）

設備連接電腦并開啟ADB調試后，直接執(zhí)行拉取命令，將日志文件夾拉到本地指定路徑即可：

# 拉取全部日志到本地桌面（示例，可修改本地路徑）adbpull /bugreports/ ~/Desktop/RK_LOG/# 僅拉取指定異常日志（如內核panic日志）adbpull /bugreports/2022-09-24-09-58-10-kernel_panic.zip ~/Desktop/

方式2：U盤/SD卡拷貝（適合無電腦連接的線下設備）

無需ADB，直接通過設備自帶的文件管理器拷貝，前提是先開啟設備的【開發(fā)者選項】，具體步驟如下：

1.進入設備「設置」，點擊「Storage（存儲）」；

2.點擊「Go to Files app to manage and free up space」進入Files文件管理器；

3.點擊左上角列表圖標/從左向右滑動調出列表菜單，找到「Bug reports」選項；

4.進入后可看到所有日志壓縮包，直接選擇需要的日志，拷貝到U盤/SD卡即可（也可直接刪除無用日志）。

2.3關鍵：日志文件的命名規(guī)則

RK LOG系統(tǒng)的日志均為日期開頭的zip壓縮包，文件名直接包含時間+異常類型，能讓我們快速定位「最新日志」和「問題類型」，核心命名規(guī)則如下：

1.時間前綴：YYYY-MM-DD-HH-MM-SS，精確到秒，按時間排序即可找到最新異常；

2.固定標識：

3.SYSTEM_BOOT：設備開機時生成的日志，此文件之后的日志均為本次開機后產生的，是排查開機后問題的時間錨點；

4.SYSTEM_RESTART：Android系統(tǒng)重啟時生成的日志，看到此文件說明設備發(fā)生過系統(tǒng)重啟；

5.異常類型標識：如kernel_panic/TOMBSTONE/system_app_crash等，直接對應具體異常（后續(xù)會詳細講解）。

示例：

2023-03-14-10-04-27-SYSTEM_BOOT.zip→ 2023-03-14 1027的開機日志

2022-09-24-09-58-10-kernel_panic.zip→ 2022-09-24 0910的內核panic異常日志

2023-03-14-10-04-39-system_app_crash.zip→ 2023-03-14 1039的系統(tǒng)應用崩潰日志

三、核心排查思路：按日志類型定位問題根源

RK LOG系統(tǒng)將異常分為內核層和Android層兩大類，不同類型的異常對應不同的日志文件，我們只需根據(jù)文件名的異常標識，就能快速定位問題根源，無需在海量日志中篩選。

3.1內核層問題排查：關注kernel_panic.zip

內核層問題主要為內核panic和內核卡死，是底層硬件/內核驅動的核心問題，排查重點如下：

1.內核panic重啟：系統(tǒng)會生成kernel_panic.zip，壓縮包內包含panic的具體內核日志，直接解析即可定位panic原因（如段錯誤segment fault）；

2.內核卡死（無重啟）：默認情況下，僅segment fault會觸發(fā)kernel panic，而hard lock/soft lock/rcu stall等情況會導致內核卡死但不重啟，此時無默認日志，需按以下方式處理：

3.若能接串口：在串口使用fiq工具抓取更多內核日志；

4.若無法接串口：開啟內核配置，讓卡死觸發(fā)panic并生成日志，需開啟的配置如下：

CONFIG_BOOTPARAM_HUNG_TASK_PANIC=yCONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=yCONFIG_BOOTPARAM_HARDLOCKUP_PANIC=yCONFIG_BOOTPARAM_RCU_STALL_PANIC=y

5.版本注意事項：瑞芯微SDK/補丁僅在user版本默認開啟上述配置，若在userdebug版本使用，需手動在arch/arm64/configs/rockchip_defconfig文件中添加上述配置。

3.2 Android層問題排查：按標識匹配異常類型

Android層異常覆蓋系統(tǒng)服務、系統(tǒng)App、用戶App、框架層，共10余種核心異常，每種異常都有專屬的日志標識，TOMBSTONE默認強制觸發(fā)日志（除非配置為0），其他異常可通過配置篩選。

以下是Android層核心異常標識與問題對應表，建議收藏備用：

排查技巧：先看日志的SYSTEM_BOOT時間，確定本次開機范圍，再從最新日志的標識判斷問題類型——比如看到data_app_anr，直接定位到用戶第三方App的ANR問題，無需排查系統(tǒng)層。

四、靈活配置：根據(jù)需求調整日志抓取規(guī)則

RK LOG系統(tǒng)提供了異常抓取級別和日志最大容量兩大核心配置，開發(fā)者可根據(jù)排查需求（如僅抓內核問題、限制日志大小）靈活修改，適配不同的使用場景。

4.1配置1：異常抓取級別（persist.sys.rklog.level）

通過系統(tǒng)屬性persist.sys.rklog.level可配置需要捕獲的Android層異常范圍，內核panic日志不受此配置影響（除非配置為0），核心規(guī)則：

?默認值：7，覆蓋大部分核心異常，滿足日常排查需求；

?配置為0：不抓取任何Android層異常，僅捕獲內核panic日志，適合僅排查內核問題的場景；

?數(shù)值含義：數(shù)值為N時，會捕獲枚舉中1~N的所有異常，TOMBSTONE默認觸發(fā)（除非配置0）。

異常枚舉定義（關鍵）：

enum{DROPBOX_SYSTEM_SERVER_CRASH =1, // 系統(tǒng)服務CrashDROPBOX_SYSTEM_SERVER_ANR =2,  // 系統(tǒng)服務ANRDROPBOX_SYSTEM_SERVER_LOWMEM =3,// 系統(tǒng)服務低內存DROPBOX_SYSTEM_SERVER_WATCHDOG =4,// 系統(tǒng)服務WatchdogDROPBOX_SYSTEM_RESTART =5,   // 系統(tǒng)重啟DROPBOX_SYSTEM_APP_CRASH =6,  // 系統(tǒng)App CrashDROPBOX_SYSTEM_APP_ANR =7,   // 系統(tǒng)App ANRDROPBOX_SYSTEM_SERVER_WTF =8,  // 系統(tǒng)服務WTFDROPBOX_SYSTEM_APP_WTF =9,   // 系統(tǒng)App WTFDROPBOX_DATA_APP_ANR =10,    // 用戶App ANRDROPBOX_DATA_APP_CRASH =11,   // 用戶App CrashDROPBOX_DATA_APP_WTF =12,    // 用戶App WTF};

配置方法（ADB臨時配置，重啟后失效；若需永久配置，需修改系統(tǒng)屬性默認文件）：

# 配置為12，捕獲所有Android層異常（適合全面排查）adbshell setprop persist.sys.rklog.level12# 配置為0，僅抓內核panicadbshell setprop persist.sys.rklog.level0

4.2配置2：日志最大容量（dumpstate.max_log_size）

RK LOG系統(tǒng)默認限制日志總大小為300M，避免日志占滿設備存儲，可通過該屬性調整容量，核心規(guī)則：

1.單位：MB，配置值為N則日志總大小限制為N M；

2.觸發(fā)機制：日志總大小超過限制時，自動刪除最早生成的日志，保證新日志能正常生成；

3.核心說明（回應核心疑問）：①原文確實未提及getprop dumpstate.max_log_size相關配置，補充該命令是因為：原文僅講配置方法，未提供「驗證配置是否生效」的實操手段，而getprop是Android系統(tǒng)通用的屬性查詢命令，能快速確認配置是否落地，完善配置全流程（修改→生效→驗證），適配開發(fā)者實際調試場景；②該配置雖在dumpstate.cpp中通過代碼實現(xiàn)，但支持動態(tài)修改（臨時生效），核心邏輯的結合你找到的代碼分析如下：

代碼核心行：long long int max_log_size = (long long int)android::GetIntProperty("dumpstate.max_log_size", 300);
邏輯拆解：函數(shù)GetIntProperty的優(yōu)先級是「動態(tài)系統(tǒng)屬性>代碼默認值」——先讀取系統(tǒng)中dumpstate.max_log_size的動態(tài)屬性值（若用setprop設置過），若未設置，則使用代碼中定義的默認值300；因此，動態(tài)修改（setprop）是臨時生效（重啟后動態(tài)屬性消失，恢復代碼默認值），永久修改需修改代碼默認值并編譯生效。

1.臨時配置（ADB動態(tài)修改，重啟失效）

適合調試階段快速調整，無需編譯源碼，直接通過setprop動態(tài)修改，驗證效果：

# 設置日志最大容量為200M（數(shù)值可自定義）adbshell setprop dumpstate.max_log_size200# 立即查詢動態(tài)修改后的數(shù)值（驗證動態(tài)修改是否生效）adbshell getprop dumpstate.max_log_size

注意：動態(tài)修改僅在本次開機有效，重啟設備后，動態(tài)屬性消失，恢復為dumpstate.cpp中定義的代碼默認值。

2.永久配置（適配RK3576 Android 15，源碼層修改）

適合正式版本固化配置，需修改代碼默認值并編譯，步驟如下：

步驟1：打開源碼文件

vim~/teamstore/xiesc/RK72/rk3576_android15/frameworks/native/cmds/dumpstate/dumpstate.cpp

步驟2：修改代碼默認值

找到你通過grep定位到的核心代碼行（默認值為300）：

// 修改前l(fā)onglongintmax_log_size = (longlongint)android::GetIntProperty("dumpstate.max_log_size",300);// 修改后（以200M為例，可自定義數(shù)值）longlongintmax_log_size = (longlongint)android::GetIntProperty("dumpstate.max_log_size",200);

保存并退出（Esc→:wq）。

步驟3：編譯dumpstate模塊

在源碼根目錄執(zhí)行編譯命令（Android 15推薦用mm替代舊版mmm）：

# 進入源碼根目錄cd~/teamstore/xiesc/RK72/rk3576_android15/# 單獨編譯dumpstate模塊（僅編譯修改的文件，速度快）mm frameworks/native/cmds/dumpstate/

步驟4：讓配置生效（兩種方式任選）

?調試場景（無需全量刷鏡像）：

?正式發(fā)布場景（全量編譯鏡像）：

3.配置生效驗證（核心：getprop命令的作用）

無論臨時動態(tài)修改，還是永久源碼修改，均需通過getprop命令驗證，確保配置落地：

adb root# Android 15需先關閉分區(qū)驗證才能重掛載adb shell disable-verityadb rebootadb rootadb remount# 推送編譯后的文件到設備adb push out/target/product/<你的板型名稱>/system/bin/dumpstate /system/bin/# 修改權限并重啟服務adb shellchmod755 /system/bin/dumpstateadb shell stop dumpstate && adb shell start dumpstate

4.3特殊機制：5分鐘異常防抖

為避免相同異常短時間反復觸發(fā)導致日志爆倉（如同一處system_server_wtf反復報錯），RK LOG系統(tǒng)做了防抖處理：

本次開機內，相同原因的異常5分鐘內僅生成一次日志。

注意：并非系統(tǒng)未捕獲異常，而是防抖機制限制，5分鐘后若異常再次觸發(fā)，會生成新的日志。

五、排查實戰(zhàn)小技巧（效率翻倍）

1.快速找最新日志：設備端執(zhí)行l(wèi)s -l /bugreports/，日志會按時間倒序排列，最后一行即為最新異常日志；

2.按異常類型篩選：使用ls /bugreports/ | grep 異常標識快速篩選，如ls /bugreports/ | grep crash篩選所有Crash日志；

3.線上設備排查：優(yōu)先用「U盤/SD卡拷貝」方式獲取日志，無需開啟ADB，避免線上設備調試風險；

4.內核問題優(yōu)先串口：若能接設備串口，內核卡死時優(yōu)先用fiq工具抓取日志，比開啟配置更高效；

5.日志及時備份：異常日志為zip壓縮包，拉取到本地后建議按「設備號+時間+異常類型」重命名，方便后續(xù)歸檔和分析；

6.多設備批量排查：通過ADB批量命令拉取多臺設備的/bugreports/日志，統(tǒng)一分析異常規(guī)律；

7.Android 15權限適配：修改/system/bin/下文件時，需先執(zhí)行adb shell disable-verity關閉分區(qū)驗證，否則remount會失敗。

六、總結

RK Android LOG系統(tǒng)是瑞芯微為RK平臺量身打造的問題排查核心工具，其「user版本可用、異常觸發(fā)、全鏈路捕獲」的特性，完美解決了Android開發(fā)中日志難獲取、有效信息少的痛點。

針對RK3576 Android 15版本，結合代碼實現(xiàn)和實際調試場景，掌握這套工具的核心要點：

1.記路徑：日志核心路徑/bugreports/（軟鏈接），無需記憶長路徑；

2.識命名：通過日志文件名的「時間+異常標識」快速定位問題類型；

3.調配置：異常抓取級別改persist.sys.rklog.level；日志最大容量支持「臨時動態(tài)修改（setprop，重啟失效）」和「永久源碼修改（改dumpstate.cpp默認值，編譯生效）」，兩者優(yōu)先級：動態(tài)屬性>代碼默認值；

希望這篇適配RK3576 Android 15的指南能幫你搞定RK平臺的日志排查，讓問題定位更高效！

審核編輯 黃宇