RK平台Android问题排查神器！LOG系统全方位使用指南

做瑞芯微RK平台Android开发/技术支持的同学，想必都遇见过内核panic、应用Crash、ANR这类头疼的问题，排查的核心难点往往是日志难获取、有效信息少、user版本无日志。而瑞芯微自研的RK Android LOG系统，完美解决了这些痛点——它基于异常触发记录日志，user版本可用，还能自动保存内核和Android层的各类异常信息，是RK平台问题排查的核心工具。

今天这篇文章，我们就把这套LOG系统的使用方法、排查思路、配置技巧讲透，从日志存储、获取到问题定位，一步到位帮你搞定RK平台的Android问题排查！

一、先搞懂：RK LOG系统的核心优势

和传统Android日志系统相比，RK LOG系统专为线上/线下问题排查设计，核心亮点直击开发者痛点，也是我们优先选择它的原因：

1.User版本可用：无需切换到userdebug/eng版本，线上设备也能捕获异常日志，解决线上问题排查无日志的核心难题；

2.异常触发式记录：避免无意义日志刷屏，仅当系统出现异常时才生成日志，有效信息密度高；

3.全链路异常捕获：既支持内核层panic/卡死，也能捕获Android层Crash/ANR/低内存/Watchdog等几乎所有异常；

4.重启后日志不丢失：内核panic重启、Android系统重启后，会自动保存重启前的异常信息，不会因重启丢失关键日志；

5.存储与访问便捷：日志有固定存储路径，还提供软链接快速访问，支持ADB和U盘/SD卡两种获取方式；

6.智能控容+防抖：限制日志总大小，自动删除最早日志；相同异常5分钟内仅记录一次，避免日志爆仓。

二、基础必备：日志的存储路径与获取方式

排查问题的第一步，是找到日志在哪、怎么把日志拿到本地。RK LOG系统的日志存储做了专门的优化，路径清晰、获取方式简单，新手也能快速上手。

2.1日志存储路径（核心）

所有异常日志最终都保存在主路径：

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

为了方便开发者访问，系统在根目录创建了软链接，直接访问以下路径即可，无需输入长路径：

/bugreports/

（验证软链接：在设备端执行ls bugreports -l，可看到链接指向主路径）

2.2两种日志获取方式

方式1：ADB命令获取（推荐开发/调试时使用）

设备连接电脑并开启ADB调试后，直接执行拉取命令，将日志文件夹拉到本地指定路径即可：

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

方式2：U盘/SD卡拷贝（适合无电脑连接的线下设备）

无需ADB，直接通过设备自带的文件管理器拷贝，前提是先开启设备的【开发者选项】，具体步骤如下：

1.进入设备「设置」，点击「Storage（存储）」；

2.点击「Go to Files app to manage and free up space」进入Files文件管理器；

3.点击左上角列表图标/从左向右滑动调出列表菜单，找到「Bug reports」选项；

4.进入后可看到所有日志压缩包，直接选择需要的日志，拷贝到U盘/SD卡即可（也可直接删除无用日志）。

2.3关键：日志文件的命名规则

RK LOG系统的日志均为日期开头的zip压缩包，文件名直接包含时间+异常类型，能让我们快速定位「最新日志」和「问题类型」，核心命名规则如下：

1.时间前缀：YYYY-MM-DD-HH-MM-SS，精确到秒，按时间排序即可找到最新异常；

2.固定标识：

3.SYSTEM_BOOT：设备开机时生成的日志，此文件之后的日志均为本次开机后产生的，是排查开机后问题的时间锚点；

4.SYSTEM_RESTART：Android系统重启时生成的日志，看到此文件说明设备发生过系统重启；

5.异常类型标识：如kernel_panic/TOMBSTONE/system_app_crash等，直接对应具体异常（后续会详细讲解）。

示例：

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的系统应用崩溃日志

三、核心排查思路：按日志类型定位问题根源

RK LOG系统将异常分为内核层和Android层两大类，不同类型的异常对应不同的日志文件，我们只需根据文件名的异常标识，就能快速定位问题根源，无需在海量日志中筛选。

3.1内核层问题排查：关注kernel_panic.zip

内核层问题主要为内核panic和内核卡死，是底层硬件/内核驱动的核心问题，排查重点如下：

1.内核panic重启：系统会生成kernel_panic.zip，压缩包内包含panic的具体内核日志，直接解析即可定位panic原因（如段错误segment fault）；

2.内核卡死（无重启）：默认情况下，仅segment fault会触发kernel panic，而hard lock/soft lock/rcu stall等情况会导致内核卡死但不重启，此时无默认日志，需按以下方式处理：

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

4.若无法接串口：开启内核配置，让卡死触发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层异常覆盖系统服务、系统App、用户App、框架层，共10余种核心异常，每种异常都有专属的日志标识，TOMBSTONE默认强制触发日志（除非配置为0），其他异常可通过配置筛选。

以下是Android层核心异常标识与问题对应表，建议收藏备用：

日志标识	对应具体问题	问题层级
TOMBSTONE	Native层代码Crash	框架/应用底层
system_server_crash	Android系统服务崩溃	系统核心服务
system_server_anr	Android系统服务ANR	系统核心服务
system_server_lowmem	系统服务触发低内存异常	系统资源
system_server_watchdog	系统服务出现Watchdog看门狗异常	系统核心服务
system_server_wtf	Android框架层严重错误（WTF）	系统框架
SYSTEM_RESTART	Android系统重启	整体系统
system_app_crash	系统自带App崩溃（Force Close）	系统应用
system_app_anr	系统自带App出现ANR	系统应用
system_app_wtf	系统自带App触发框架严重错误	系统应用
data_app_crash	用户安装的第三方App崩溃	第三方应用
data_app_anr	用户安装的第三方App出现ANR	第三方应用
data_app_wtf	用户安装的第三方App触发框架错误	第三方应用

排查技巧：先看日志的SYSTEM_BOOT时间，确定本次开机范围，再从最新日志的标识判断问题类型——比如看到data_app_anr，直接定位到用户第三方App的ANR问题，无需排查系统层。

四、灵活配置：根据需求调整日志抓取规则

RK LOG系统提供了异常抓取级别和日志最大容量两大核心配置，开发者可根据排查需求（如仅抓内核问题、限制日志大小）灵活修改，适配不同的使用场景。

4.1配置1：异常抓取级别（persist.sys.rklog.level）

通过系统属性persist.sys.rklog.level可配置需要捕获的Android层异常范围，内核panic日志不受此配置影响（除非配置为0），核心规则：

•默认值：7，覆盖大部分核心异常，满足日常排查需求；

•配置为0：不抓取任何Android层异常，仅捕获内核panic日志，适合仅排查内核问题的场景；

•数值含义：数值为N时，会捕获枚举中1~N的所有异常，TOMBSTONE默认触发（除非配置0）。

异常枚举定义（关键）：

enum{DROPBOX_SYSTEM_SERVER_CRASH =1, // 系统服务CrashDROPBOX_SYSTEM_SERVER_ANR =2,  // 系统服务ANRDROPBOX_SYSTEM_SERVER_LOWMEM =3,// 系统服务低内存DROPBOX_SYSTEM_SERVER_WATCHDOG =4,// 系统服务WatchdogDROPBOX_SYSTEM_RESTART =5,   // 系统重启DROPBOX_SYSTEM_APP_CRASH =6,  // 系统App CrashDROPBOX_SYSTEM_APP_ANR =7,   // 系统App ANRDROPBOX_SYSTEM_SERVER_WTF =8,  // 系统服务WTFDROPBOX_SYSTEM_APP_WTF =9,   // 系统App WTFDROPBOX_DATA_APP_ANR =10,    // 用户App ANRDROPBOX_DATA_APP_CRASH =11,   // 用户App CrashDROPBOX_DATA_APP_WTF =12,    // 用户App WTF};

配置方法（ADB临时配置，重启后失效；若需永久配置，需修改系统属性默认文件）：

# 配置为12，捕获所有Android层异常（适合全面排查）adbshell setprop persist.sys.rklog.level12# 配置为0，仅抓内核panicadbshell setprop persist.sys.rklog.level0

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

RK LOG系统默认限制日志总大小为300M，避免日志占满设备存储，可通过该属性调整容量，核心规则：

1.单位：MB，配置值为N则日志总大小限制为N M；

2.触发机制：日志总大小超过限制时，自动删除最早生成的日志，保证新日志能正常生成；

3.核心说明（回应核心疑问）：①原文确实未提及getprop dumpstate.max_log_size相关配置，补充该命令是因为：原文仅讲配置方法，未提供「验证配置是否生效」的实操手段，而getprop是Android系统通用的属性查询命令，能快速确认配置是否落地，完善配置全流程（修改→生效→验证），适配开发者实际调试场景；②该配置虽在dumpstate.cpp中通过代码实现，但支持动态修改（临时生效），核心逻辑的结合你找到的代码分析如下：

代码核心行：long long int max_log_size = (long long int)android::GetIntProperty("dumpstate.max_log_size", 300);
逻辑拆解：函数GetIntProperty的优先级是「动态系统属性>代码默认值」——先读取系统中dumpstate.max_log_size的动态属性值（若用setprop设置过），若未设置，则使用代码中定义的默认值300；因此，动态修改（setprop）是临时生效（重启后动态属性消失，恢复代码默认值），永久修改需修改代码默认值并编译生效。

1.临时配置（ADB动态修改，重启失效）

适合调试阶段快速调整，无需编译源码，直接通过setprop动态修改，验证效果：

# 设置日志最大容量为200M（数值可自定义）adbshell setprop dumpstate.max_log_size200# 立即查询动态修改后的数值（验证动态修改是否生效）adbshell getprop dumpstate.max_log_size

注意：动态修改仅在本次开机有效，重启设备后，动态属性消失，恢复为dumpstate.cpp中定义的代码默认值。

2.永久配置（适配RK3576 Android 15，源码层修改）

适合正式版本固化配置，需修改代码默认值并编译，步骤如下：

步骤1：打开源码文件

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

步骤2：修改代码默认值

找到你通过grep定位到的核心代码行（默认值为300）：

// 修改前longlongintmax_log_size = (longlongint)android::GetIntProperty("dumpstate.max_log_size",300);// 修改后（以200M为例，可自定义数值）longlongintmax_log_size = (longlongint)android::GetIntProperty("dumpstate.max_log_size",200);

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

步骤3：编译dumpstate模块

在源码根目录执行编译命令（Android 15推荐用mm替代旧版mmm）：

# 进入源码根目录cd~/teamstore/xiesc/RK72/rk3576_android15/# 单独编译dumpstate模块（仅编译修改的文件，速度快）mm frameworks/native/cmds/dumpstate/

步骤4：让配置生效（两种方式任选）

•调试场景（无需全量刷镜像）：

•正式发布场景（全量编译镜像）：

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

无论临时动态修改，还是永久源码修改，均需通过getprop命令验证，确保配置落地：

adb root# Android 15需先关闭分区验证才能重挂载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分钟异常防抖

为避免相同异常短时间反复触发导致日志爆仓（如同一处system_server_wtf反复报错），RK LOG系统做了防抖处理：

本次开机内，相同原因的异常5分钟内仅生成一次日志。

注意：并非系统未捕获异常，而是防抖机制限制，5分钟后若异常再次触发，会生成新的日志。

五、排查实战小技巧（效率翻倍）

1.快速找最新日志：设备端执行ls -l /bugreports/，日志会按时间倒序排列，最后一行即为最新异常日志；

2.按异常类型筛选：使用ls /bugreports/ | grep 异常标识快速筛选，如ls /bugreports/ | grep crash筛选所有Crash日志；

3.线上设备排查：优先用「U盘/SD卡拷贝」方式获取日志，无需开启ADB，避免线上设备调试风险；

4.内核问题优先串口：若能接设备串口，内核卡死时优先用fiq工具抓取日志，比开启配置更高效；

5.日志及时备份：异常日志为zip压缩包，拉取到本地后建议按「设备号+时间+异常类型」重命名，方便后续归档和分析；

6.多设备批量排查：通过ADB批量命令拉取多台设备的/bugreports/日志，统一分析异常规律；

7.Android 15权限适配：修改/system/bin/下文件时，需先执行adb shell disable-verity关闭分区验证，否则remount会失败。

六、总结

RK Android LOG系统是瑞芯微为RK平台量身打造的问题排查核心工具，其「user版本可用、异常触发、全链路捕获」的特性，完美解决了Android开发中日志难获取、有效信息少的痛点。

针对RK3576 Android 15版本，结合代码实现和实际调试场景，掌握这套工具的核心要点：

1.记路径：日志核心路径/bugreports/（软链接），无需记忆长路径；

2.识命名：通过日志文件名的「时间+异常标识」快速定位问题类型；

3.调配置：异常抓取级别改persist.sys.rklog.level；日志最大容量支持「临时动态修改（setprop，重启失效）」和「永久源码修改（改dumpstate.cpp默认值，编译生效）」，两者优先级：动态属性>代码默认值；

希望这篇适配RK3576 Android 15的指南能帮你搞定RK平台的日志排查，让问题定位更高效！

审核编辑 黄宇