把 LibChecker 用成 APK 侦察兵：5 个藏得很深的技巧

项目	内容
软件	LibChecker
版本	2.5.1.dev.4109a56d
平台	Android APK
体积	4.24M
分类	系统工具
包名	com.absinthe.libchecker
官网	LibChecker 官网
下载一	LibChecker 下载，LibChecker 下载
下载二	LibChecker 下载，LibChecker 下载
文档	LibChecker 文档
介绍	LibChecker 不只是看三方库的小工具，挖透它你会发现快照追踪、规则库切换、组件统计这些冷功能能帮你排查自启动、跨设备迁移、识别全家桶。

LibChecker 是什么

LibChecker 是一个跑在 Android 上的 APK 分析工具。装到手机里之后，它会扫描你设备上所有已安装的应用，把每个 App 引用的原生库、组件、权限、Intent Action 这些底层信息全部拉出来，还能和一份开源规则库做匹配，给常见 SDK 打上彩色徽标。

开发者用它看竞品依赖，逆向爱好者用它扒 APK 结构，普通用户也能借它看看自己手机里藏了哪些广告 SDK。这个定位不算冷门，但大部分人真的只是打开应用列表翻两下，然后就退出去了——它真正有用的几个功能，藏得比想象中深。

快照追踪：让系统预装应用也无处遁形

LibChecker 的快照对比机制，默认只在两种情况下触发：目标 App 的 versionCode 变了，或者 lastUpdateTime 改了。这对普通第三方应用没问题，但系统预装应用就尴尬了——很多 ROM 里，预装 App 即使 OTA 升级，版本号和更新时间都不一定会变。结果就是你以为它从来没变过，实际上系统偷偷换了组件、加了广播接收器，你完全看不到。

解决办法就是那个几乎没人点开的「追踪」功能。在快照页面，选中某个 App 加入追踪列表之后，每次做快照对比都会强制检查它，不管 versionCode 有没有变化。我第一次用这个功能是为了排查某款国产 ROM 的应用商店为什么每天都会悄悄自启一次，加进追踪列表后第二次快照对比，赫然发现它偷偷注册了一个监听 PACKAGE_ADDED 广播的静态接收器——每当手机里安装新应用，它就被唤醒。这个变化如果不靠强制追踪，正常快照永远发现不了。

适合谁：经常刷 ROM、关心预装应用行为的玩家。如果你手机里 App 都是正经第三方，这条可以无视。

云端规则库切换：国内网络的救命开关

LibChecker 的知名库标记效果很直观——匹配到规则后，列表项右侧会冒出对应 SDK 的彩色徽标。但很多人装完打开一看，咦，怎么全是灰的没标记？原因八成是云端规则没拉下来，而规则仓库默认走 GitHub，国内网络访问不稳定。

藏在设置里的「云端规则仓库切换」就是为此准备的。进入设置页往下翻，找到规则库相关的选项，手动把仓库地址切到 Gitee 镜像，再点一次「检查更新」，几秒钟后规则库就同步完了，刚才还一片灰白的库列表瞬间冒出各种彩色标签。

另一个冷知识：LibChecker 的规则库不是死的，它有版本号（目前已迭代到 v44+），每次更新都会补充新的库识别规则。设置里能看到当前版本，有新版会弹出提示。保持规则库更新，才能识别刚冒出来的新 SDK。

适合谁：所有国内网络环境的用户。如果你的 LibChecker 标记栏常年灰白，先检查这个设置，别忙着重装。

组件维度统计：从库引用跳到行为分析

主页底部三个 Tab，大家盯着第一个「应用列表」看，偶尔切到第三个「快照」试一下，中间那个「库引用统计」几乎没人认真用。更没人注意的是，统计页面右上角有个更多按钮，点开之后可以切换展示维度——默认只显示原生库（.so 文件），但你可以切到组件、权限、Intent Action、元数据、签名、sharedUserId、包名这些维度。

切换到组件维度，立刻就能看到哪些 App 注册了最多的服务、活动、广播接收器。这个视角比单纯看库名有用得多——比如你想知道手机里哪些 App 爱注册 BOOT_COMPLETED 广播，切到 Intent Action 维度排序，排在前面的就是开机自启动重灾区。再配合广播接收器的详情视图，能看到每个接收器监听了哪些广播、是否 exported、需要什么权限。

我自己的用法是定期切到广播 Action 维度，扫一眼 CONNECTIVITY_ACTION、TIME_SET、SCREEN_ON 这几个高频唤醒源，看看有没有哪个陌生 App 混在一堆系统应用中间——那大概率就是个常驻后台的惯犯。

适合谁：对 Android 组件体系有基本了解的用户。纯小白看到这些维度切换可能会懵，但只要明白「组件 = App 的行为入口」，就能反推不少有用的结论。

快照备份恢复：换手机不丢分析基线

LibChecker 的快照数据是存在本地的 SQLite 数据库里，换手机就没了。但设置里藏着一套完整的备份恢复流程，依赖 Android 的 SAF（Storage Access Framework）框架。操作路径是：仪表盘 → 备份与恢复 → 选择备份位置。

备份出来的文件可以直接拷贝到新手机，在新版本 LibChecker 里执行恢复，所有历史快照就完整迁移过来了。这个功能对经常换设备的折腾党尤其友好——你在旧手机上积累的快照对比基线，不会因为换手机从零开始。

不过有个坑：某些国产 ROM 为了精简，剥离了系统自带的「文件」应用（com.google.android.documentsui），SAF 框架就没法正常工作，备份恢复会直接报错。遇到这种情况基本无解，只能等厂商后续更新，或者在备份前先用 adb 命令手动导出数据库文件作为应急方案。

适合谁：有快照积累需求、会折腾 ROM 的玩家。如果你从没做过快照对比，这条也用不上。

别让追踪列表变成垃圾场

最后说个反面提醒。追踪功能好用，但别见到什么 App 都往里面塞。追踪列表里每多一个 App，每次快照对比的耗时就会增加——本来半分钟能跑完的快照，塞了二三十个追踪对象可能要等两三分钟。而且快照数据本身也会持续膨胀，长期不清理的话，SQLite 数据库会越来越大，最终拖慢整个应用的启动速度。

清理方式是在快照页面进入「管理」功能，选中不需要的快照执行删除。删除操作不可恢复，动手前确认一下哪些快照已经没用了。一个实用的节奏：普通 App 保留最近两三个版本对比即可，长期追踪的预装 App 可以保留更长时间，但至少每隔几个月回顾一遍追踪列表，把已经不再关心的对象移除。

收尾

LibChecker 这类工具的尴尬在于，它的核心用户群（开发者、逆向爱好者）大多知道这些功能，而把它当成「查看三方库小工具」的普通用户，根本不会点进设置、不会切 Tab、不会读仪表盘。写这篇文章的目的其实很简单——如果你手机里装了它但只用了 20% 的功能，不妨花十分钟翻一下设置页和三个 Tab，说不定会发现一个你以为「不存在」的侧世界。

本文为个人基于网络公开资料整理编写，非官方内容，仅供学习交流参考；软件版权归原作者所有，请支持正版；使用过程中遇到问题请查阅官方渠道，本文不承担任何责任。