标题里问的这件事我先说结论不 ROOT 取应用数据技术上确实存在几条可行通道但每一条能拿到的东西都远比想象中少。过去几年我帮人处理过不少类似需求——换机丢了聊天记录想找回、自己写的脚本要读取某个应用的通知、做数据分析需要一批公开可见的内容——每次我都会先问一句你要的是备份迁移还是要把别人手机里的东西拿出来。这两种诉求在技术上可能有交集在性质上完全是两回事前者是正当需求后者无论用什么工具都不该碰。下文涉及的那个具体应用我统一用某 IM 应用指代讲的是 Android 平台上应用数据访问的通用机制任何 App 都适用。这篇文章不打算给你一套照着敲就能导出全部数据的步骤——那既做不到也不该做。我要拆的是免 ROOT 场景下权限的真实天花板在哪、每条通道能摸到什么颗粒度的数据、以及为什么大部分网上流传的方法在现在的系统版本上根本跑不通。1. 把不 ROOT 取数据拆成三个可解的子问题很多人一上来就问有没有工具这个问法本身就错了。取数据是个笼统说法拆开看至少是三个独立问题数据物理存在哪、我以什么身份去读、读出来的东西算不算完整。这三个问题的答案互相制约任何一个没解决后面全白搭。1.1 数据到底存在哪应用沙箱的三层边界Android 的应用隔离不是一层是三层层层叠加的。第一层是Linux 的 UID 隔离——每装一个应用系统给它分配一个独立的 uid/data/data/package这个目录的所有者就是那个 uid权限位通常是700也就是只有属主能进。你随便开个终端ls -l /data/data会看到一列数字 uid那些数字就是各应用的身份证。第二层是SELinux 的类型强制访问控制。就算你把自己的进程 uid 改成了目标应用的 uidSELinux 的 domain 不匹配照样拒绝。这一层是很多人忽略的——他们以为拿到 root 就万事大吉实际上老设备上 root 之后还要处理 SELinux 的 enforcing 状态新设备上更是几乎不可能。第三层是应用自身的加密。主流 IM 应用早就不把聊天内容明文写盘了数据库文件本身可能是 SQLCipher 加密的密钥存在别处或者由用户口令派生。这意味着即使你突破了前两层拿到的也可能只是一堆二进制噪声。# 典型的一次尝试注意看报错 adb shell ls -l /data/data/ # ls: /data/data/: Permission denied adb shell run-as com.example.app ls # run-as: package not debuggable: com.example.app这两行输出基本就宣告了绝大多数免 root 直读数据库的幻想破灭。run-as只对android:debuggabletrue的应用有效而任何正式发布的商用 App 都不可能开这个开关。市面上偶尔有号称能用的多半是拿到了开发版安装包或者根本不是走这条路。1.2 免 root能拿到的权限上限是什么免 root 不等于没有权限提升的余地关键在于你能借到哪个身份的权限。Android 上有一个特殊身份叫shelluid 2000它是 ADB 调试通道的默认身份权限比普通应用高很多能pm装卸应用、能dumpsys看系统服务状态、能content query查 ContentProvider、能读/sdcard下的公共目录、能抓logcat。但shell依然不是 root。它进不去别的应用的私有目录改不了系统分区也绕不过 SELinux。这一点非常关键因为大量教程把ADB 能做很多事和ADB 什么都能做混为一谈。我见过有人折腾一整天就为了用 ADB 把某个应用的数据库pull出来最后发现adb pull /data/data/pkg/databases/xxx.db直接报Permission denied——这不是命令写错了是这条路本来就不通。所以免 root 的权限上限准确表述是你能拿到 shell 身份的全部能力外加用户主动授予的运行时权限和无障碍授权但拿不到应用私有目录的读权限。1.3 为什么大多数教程在第一步就走偏了常见的走偏方式有三种我按出现频率排一下。第一种是把界面上看得见当成数据能导出。你在聊天窗口里能翻到三年前的记录不代表这些记录能以结构化形式落盘。这两件事之间隔着整个应用的渲染层和存储层。第二种是拿旧版本系统的结论套新系统。adb backup这个命令在 Android 4.x 时代确实能整包备份应用数据2016 年之后随着targetSdkVersion提到 24 以上应用只要不显式开allowBackup这条命令就基本失效了。现在还在传播这套方法的内容八成是抄的五六年前的帖子。第三种是混淆了数据可见和数据完整。走无障碍通道确实能把屏幕上的文字一条条抓下来但附件、语音、撤回消息、时间戳精度、消息顺序这些信息在 UI 层是丢失或残缺的。做备份勉强够用做数据分析基本没法看。2. 三条免 root 通道的能力横评把能用的通道列清楚比盲目试工具效率高得多。我按能拿到的数据深度从高到低排同时把授权成本和稳定性也标出来。2.1 四条通道的横向对比通道需要的授权能触达的数据层级稳定性典型适用场景ADB 调试通道USB 调试 / 无线调试配对系统服务状态、ContentProvider 公开数据、公共存储、日志高设备排查、应用信息清点、日志分析无障碍服务用户在设置里手动开启屏幕上的节点文本、控件状态、可点击区域中本人设备的记录整理、UI 自动化测试屏幕采集 OCR录屏授权每次会话确认像素级画面需二次识别低兜底方案、无法获取节点树的场景系统备份 / 迁移工具跟随系统引导应用自己声明可备份的部分高换机迁移、整机备份这张表最该被注意的是第二列。授权方式决定了这件事的性质ADB 是你对自己的设备开的调试口无障碍是你自己点的开关录屏是你自己按的确认——全部需要设备持有者主动参与。任何号称远程就能拿到的方案在技术上就不成立可以直接判定为骗局。2.2 ADB 通道最接近 root 的合法口子ADB 是我平时用得最多的。Android 11 之后有了无线调试配对不用数据线也能连配对码六位数一次配对长期有效换网络要重新配。它的价值不在于能读私有数据——它读不到——而在于能把一个应用的运行状态摸得很清楚。# 看设备连接状态 adb devices -l # 列出所有包名配合 grep 过滤 adb shell pm list packages | grep -i example # 看某个包的详细信息版本、权限、数据目录、是否可调试 adb shell dumpsys package com.example.app | head -60 # 查询该应用暴露的 ContentProvider adb shell dumpsys activity providers | grep -A3 com.example.appdumpsys package的输出里有一行dataDir/data/user/0/com.example.app这就是它的私有目录路径你能看到路径但ls不进去。这个反差是很多人第一次接触时的困惑点其实很合理——元信息是公开的内容不是。content query值得单独说一句。如果某个应用注册了exportedtrue的 ContentProvidershell 身份是可以查询的。但主流 IM 应用早就把这类 Provider 收紧了能查到的通常是媒体索引、联系人映射这类辅助数据不是消息本体。你可以用dumpsys activity providers看有哪些但别抱太高期待。2.3 无障碍服务本质是替你点屏幕无障碍服务经常被误解成某种破解手段其实它的定位非常明确帮助操作不便的用户完成界面交互。它能拿到的是当前窗口的节点树每个节点带着text、contentDescription、className、boundsInScreen这些属性。!-- AndroidManifest.xml 里的服务声明 -- service android:name.ExportService android:exportedfalse android:permissionandroid.permission.BIND_ACCESSIBILITY_SERVICE intent-filter action android:nameandroid.accessibilityservice.AccessibilityService / /intent-filter meta-data android:nameandroid.accessibilityservice android:resourcexml/accessibility_config / /service!-- res/xml/accessibility_config.xml -- accessibility-service android:accessibilityEventTypestypeWindowContentChanged|typeViewScrolled android:accessibilityFeedbackTypefeedbackGeneric android:accessibilityFlagsflagReportViewIds|flagRetrieveInteractiveWindows android:canRetrieveWindowContenttrue android:notificationTimeout100 /这里flagReportViewIds很重要。加上它之后节点会带上viewIdResourceName你就可以用findAccessibilityNodeInfosByViewId()精确定位控件而不是靠文本匹配瞎猜。notificationTimeout设成 100 毫秒是为了做节流设太小会疯狂回调把 CPU 吃满设太大会漏掉快速滚动的中间态。它的硬伤也很清楚只能拿到当前渲染出来的东西。列表是虚拟化的划出屏幕的 item 会被回收节点树里就没有了。所以必须配合滚动动作一屏一屏抓中间还要处理加载延迟和重复项。2.4 屏幕采集加 OCR最后的兜底有些界面压根不暴露节点信息比如自绘的 Canvas 或者用了特殊渲染方案。这时候只能录屏截图再识别。MediaProjection需要每次会话弹窗确认这是系统的隐私保护设计绕不过去。拿到画面后用 ML Kit 或者 PaddleOCR 之类的本地模型识别中文场景下清晰截图的字符准确率能到 95% 以上但行序恢复是个大坑——OCR 返回的是带坐标的文本框你得自己按 y 坐标聚类成行、按 x 坐标排序遇到气泡左右分布自己发的靠右、对方发的靠左还得判断归属。我做过一次光排版还原的代码量就超过了识别本身。3. ADB 实操一次完整的本机数据清点上面讲的是能力边界这一节讲具体怎么跑。我按真实操作顺序写包括每一步的预期输出和常见报错。3.1 环境搭建与连接方式的取舍装platform-tools就行不要去下那些打包了一堆东西的一键工具版本混乱是排查问题的最大障碍。装完adb version确认一下建议 34 以上。连接有两种。有线最稳插上后在开发者选项里打开USB 调试首次连接手机上会弹授权框勾始终允许就不用每次点了。无线适合设备不方便插线的情况Android 11 之后路径是开发者选项 → 无线调试 → 使用配对码配对设备。# 配对端口和码在手机界面上显示每次不同 adb pair 192.168.1.100:37123 # 输入六位配对码 # 配对成功后连接注意这是另一个端口 adb connect 192.168.1.100:5555 # 确认 adb devices有个细节无线调试的端口每次重连可能变尤其是设备重启后。所以脚本里不要写死端口从adb mdns services动态取更靠谱。另外同一局域网内多台设备时adb -s serial指定目标不然命令会报 more than one device。3.2 包名侦察与目录探测的真实反馈# 第一步确认包名不同渠道包名可能不同 adb shell pm list packages -3 # -3 只列第三方应用比全量列表干净得多 # 第二步拿数据目录和 UID adb shell dumpsys package com.example.app | grep -E userId|dataDir|versionName # 第三步试着进目录预期失败 adb shell ls /data/data/com.example.app # ls: /data/data/com.example.app: Permission denied # 第四步换个角度看外部存储里有什么 adb shell ls /sdcard/Android/data/com.example.app/ adb shell ls /sdcard/Android/media/com.example.app/第三、第四步的结果对比很有意思。私有目录进不去但外部存储的Android/data/pkg目录Android 11 之后通过 ADB 是可以访问的里往往躺着缓存图片、下载的附件、临时文件。这部分不是聊天记录本体但附件类内容经常能在这里找到。我还遇到过一次特殊情况某应用把导出的备份文件写在/sdcard/Download/下文件名带时间戳用户自己都忘了。这种应用主动写到公共目录的情况是免 root 条件下唯一能完整拿到结构化数据的场景——因为它自己交出来的。3.3 备份指令为什么从能用变成不能用adb backup的历史值得讲清楚因为这是被误传最多的一个点。# 老教程里的写法 adb backup -f backup.ab -apk -shared -all com.example.app这个命令走的是 Android 的 Backup Manager 框架。应用有没有资格被备份取决于清单里的android:allowBackup默认 true。但从targetSdkVersion 24 开始系统对备份范围做了收紧只有在应用主动声明的情况下私有数据才会被纳入。绝大多数商用 App 直接把allowBackup设成false命令跑完你会得到一个几百字节的空文件。# 验证备份文件是不是空的 ls -lh backup.ab # 如果只有几百字节那就是什么都没备份到Android 12 之后又引入了dataExtractionRules把云备份和设备迁移两条路径分开配置可控性进一步细化。到这一步adb backup对第三方应用的实用价值基本归零。想解包.ab文件还得用abe之类的工具转成 tar转完发现里面是空的白忙一场。提示如果你只是想知道某个应用有没有开allowBackupdumpsys package的输出里能直接看到flags字段不用真的去跑备份命令。3.4 一条可复现的排查链路我把判断流程整理成一条链路按顺序走能快速定位到这条路通不通。第一步确认身份。adb shell id看当前是uid2000(shell)这是判断后续所有权限的基础。如果显示的是 root那说明设备已经 root 了讨论前提就变了。第二步确认包名和目标路径。dumpsys package里的dataDir是权威来源不要靠猜。第三步试探读权限。直接cat目标文件看报错是Permission denied还是No such file。前者是权限问题后者可能是路径错了或者文件压根不存在很多应用把数据存在加密容器里磁盘上看不到独立文件。第四步找替代路径。检查外部存储目录、检查应用有没有导出功能、检查系统备份里有没有这个应用的数据。第五步判定方案。如果前四步全部走不通那就只剩无障碍和 OCR 两条路此时要评估数据量和精度要求决定值不值得投入。这套流程我跑过几十次结论高度一致对主流 IM 应用免 root 直读数据库这条路是死的不存在换个命令就好了的可能。所有声称能做到的要么是骗人的要么设备其实已经 root 了而用户不知道有些第三方 ROM 或刷机包默认带 root。4. 无障碍自动化把屏幕上的内容搬下来这是免 root 条件下唯一有实际产出的方案缺点是慢、不完整、需要设备保持亮屏。我做过一个导出的工具踩的坑比预想多得多下面按开发顺序讲。4.1 服务注册与首屏接管前面贴过清单配置这里补几个实战要点。android:accessibilityFeedbackType设成feedbackGeneric就够了不需要震动或语音反馈。accessibilityEventTypes不要图省事写typeAllMask那样回调太频繁处理不及时会丢事件。只监听typeWindowContentChanged内容变化和typeViewScrolled滚动两个就够。服务启动后第一件事是getRootInActiveWindow()拿到根节点然后遍历。遍历要用递归但必须限制深度一般 25 层封顶再深基本是广告位或者装饰性容器。void walk(AccessibilityNodeInfo node, int depth, ListString out) { if (node null || depth 25) return; CharSequence text node.getText(); if (text ! null text.length() 0) { Rect r new Rect(); node.getBoundsInScreen(r); out.add(r.top \t r.left \t text); } for (int i 0; i node.getChildCount(); i) { walk(node.getChild(i), depth 1, out); } }把boundsInScreen一起记下来是有原因的后面判断消息归属左边还是右边、判断是否同一条消息的多行全靠这个坐标。4.2 翻页、等待与滚动到底的判定虚拟列表的滚动不能靠dispatchGesture模拟手指滑动那个太不可控。用performAction(AccessibilityNodeInfo.ACTION_SCROLL_FORWARD)让系统自己滚一次滚一屏左右行为稳定得多。AccessibilityNodeInfo list root.findAccessibilityNodeInfosByViewId( com.example.app:id/message_list).get(0); boolean ok list.performAction(AccessibilityNodeInfo.ACTION_SCROLL_FORWARD);这里有个必须处理的时序问题performAction是异步的返回 true 只代表动作被接受不代表新内容已经渲染。必须等typeWindowContentChanged事件到达再读下一屏直接Thread.sleep(500)在低端机上会漏在高性能机上会浪费时间。正确的做法是注册一个回调加超时保护。滚动到底的判定更麻烦。我试过三种一是比较两次抓取的首尾文本是否完全一致二是比较节点总数三是看有没有出现没有更多消息的提示节点。第三种最可靠但这取决于应用有没有这个提示第二种容易误判列表回收会导致数量波动第一种最通用但要多存一份上一屏的快照做比对。4.3 去重、断点续传与数据落地抓下来的数据一定会有重复因为滚动过程中上一屏的尾部往往会留在下一屏的顶部。去重的锚点要选好纯文本做哈希不够因为同一个人连发两条好的哈希值一样会被误删。我的做法是三元组(发送者标识, 消息文本, 屏幕坐标的相对位置)再加上抓取顺序的序号做二次校验。落地用 SQLite建唯一索引(sender, content, seq_window)用INSERT OR IGNORE写入这样中断重跑也不会脏数据。断点续传靠记录最后一屏的第一条消息的哈希下次从这个位置往前找。实践下来成功率大概八成——剩下的两成是因为消息被撤回了或者应用重启了列表位置只能人工对齐。还有一个细节容易忽略长文本消息在屏幕上会被折叠节点树里拿到的只有前半段后面是全文按钮。所以遍历的时候要检查有没有可点击的展开控件有就先点开再抓。这个坑我卡了很久导出结果里一堆消息莫名其妙被截断最后才定位到这儿。5. 官方通道才是最优解讲了一堆技术方案但我必须说句实话如果你的目的是换机、备份、找回自己的记录官方通道的成功率和完整性都远高于上面任何一种。很多人舍近求远是因为不知道或者不愿意用。5.1 系统级备份与迁移工具的能力边界Android 的换机迁移工具各家厂商都有自己的实现走的是系统级的设备间直传原理上是通过BackupTransport把应用声明的可备份数据打包搬到新设备。哪些数据会被搬由应用的dataExtractionRules决定。!-- 应用侧的配置示例决定哪些目录参与设备迁移 -- data-extraction-rules device-transfer include domaindatabase path. / include domainsharedpref path. / exclude domainfile pathcache / /device-transfer /data-extraction-rules配置里device-transfer和cloud-backup是分开的前者对应换机直传后者对应云备份。很多应用允许前者、禁止后者怕数据上云有合规风险这就解释了为什么换机后记录还在但从云备份恢复就没有。实操上的建议很直接换机前先看应用内的设置里有没有聊天记录迁移之类的入口有就先用它这是最省事的。厂商的整机迁移工具可以作为第二选择注意两台设备都要保持电量充足、连同一个 Wi-Fi、不要中途锁屏。5.2 应用自带的导出功能被严重低估我见过太多人折腾 ADB 折腾一整天最后发现应用设置里就有一个导出按钮。主流 IM 应用基本都提供了单聊记录导出、收藏内容导出、账单导出这些功能只是入口埋得深藏在设置 → 通用 → 存储空间或者帮助与反馈里面。这些功能的输出格式通常是 HTML 或纯文本打包附件会一起打进去。缺点是只支持单会话、不支持全量、导出大文件时容易中断。但如果你只是要保留某几个重要会话这已经是最优解了。5.3 什么时候该果断放弃技术方案我给自己定了几条止损线碰到就换思路不再死磕第一条目标应用没开allowBackup且没开device-transfer同时界面不暴露节点文本。这种情况三条通道全堵死只剩 OCR成本收益完全不匹配。第二条数据量超过几千条消息。无障碍方案抓几千条要跑几个小时中间任何一次来电、通知、息屏都可能打断重跑的成本太高。第三条对时间戳和顺序有严格要求。UI 层能拿到的信息不足以还原精确的时间顺序同一分钟内的多条消息顺序只能靠坐标猜做时序分析会得出错误结论。6. 合规边界与几条踩坑经验技术之外的话我放在最后讲因为这部分比代码重要。6.1 三条我不碰的线第一条不是自己的设备不碰。哪怕对方口头授权哪怕关系再亲近只要设备不属于你动手就是错的。技术上能做到和应该做之间没有任何推导关系。第二条不碰别人的账号数据。备份自己的数据和读取别人的数据中间隔着的不是技术难度是性质。第三条不做绕过安全机制的事。如果一个方案的前提是破解绕过解除限制那它就已经出界了。我上面讲的 ADB、无障碍、录屏全部依赖设备持有者主动授权授权这个动作本身就是合法性的来源。我遇到过有人问有没有不用对方同意就能看的办法这类问题我一律不接。不是我技术不行是这条路从起点就不该走。而且从现实角度看这类需求催生的所谓工具绝大多数是木马装上去数据没拿到自己的账号先被盗了。6.2 几条实际踩过的坑坑一以为 root 了就万事大吉。早期设备上 root 之后su一拿确实能进/data/data但新系统上 SELinux 是 enforcing 的ls照样被拒得先setenforce 0。再往后应用数据加密普及数据库文件打开是乱码。所以root 就能读这个认知已经过时好几年了。坑二run-as对 release 包完全无效。我一开始不知道run-as要求debuggabletrue写了个脚本天天跑报错当成环境问题排查了半天最后发现是方向错了。坑三无线调试连上后忘了断。有一次调试完没关连接设备换了个网络adb devices里挂着一堆offline的僵尸条目新命令一直超时。清理办法是adb kill-server然后重连或者用adb disconnect ip:port精确断掉。坑四无障碍服务被系统回收。长时间运行的无障碍服务会被功耗管理干掉尤其是设备息屏之后。做长时间导出任务必须申请WakeLock同时在onServiceConnected里做恢复逻辑检测到被中断就从上次的位置继续。坑五OCR 的行序还原比想象中难得多。气泡左右分布、表情符号、 提及、引用回复的缩进块这些排版元素都会干扰排序。我最后的做法是先用气泡背景色的连通域划分消息块再在块内做行聚类比纯坐标排序靠谱得多。坑六备份文件别往公共目录乱丢。导出的数据落在/sdcard/Download/之后任何有存储权限的应用都能读到。落地位置最好选应用私有目录导出完成再通过系统分享交给用户中间态不要暴露。坑七数据量大的时候别一次性读进内存。我第一版实现是把所有节点拼成一个大 List 最后统一写库抓到两万条的时候 OOM 了。改成流式写入、每屏提交一次事务之后就稳了速度还快了不少。最后说个我自己的体会。这几年处理这类需求最大的收获不是学会了多少取数技巧而是学会了在动手之前先判断这件事该不该做。技术上的可能性是无限的但每一条路都有它的成本和边界认清边界比突破边界更有价值。真要备份自己的数据翻翻应用设置、用用官方迁移工具往往比写几百行自动化代码管用得多。
标题里问的这件事我先说结论不 ROOT 取应用数据技术上确实存在几条可行通道但每一条能拿到的东西都远比想象中少。过去几年我帮人处理过不少类似需求——换机丢了聊天记录想找回、自己写的脚本要读取某个应用的通知、做数据分析需要一批公开可见的内容——每次我都会先问一句你要的是备份迁移还是要把别人手机里的东西拿出来。这两种诉求在技术上可能有交集在性质上完全是两回事前者是正当需求后者无论用什么工具都不该碰。下文涉及的那个具体应用我统一用某 IM 应用指代讲的是 Android 平台上应用数据访问的通用机制任何 App 都适用。这篇文章不打算给你一套照着敲就能导出全部数据的步骤——那既做不到也不该做。我要拆的是免 ROOT 场景下权限的真实天花板在哪、每条通道能摸到什么颗粒度的数据、以及为什么大部分网上流传的方法在现在的系统版本上根本跑不通。1. 把不 ROOT 取数据拆成三个可解的子问题很多人一上来就问有没有工具这个问法本身就错了。取数据是个笼统说法拆开看至少是三个独立问题数据物理存在哪、我以什么身份去读、读出来的东西算不算完整。这三个问题的答案互相制约任何一个没解决后面全白搭。1.1 数据到底存在哪应用沙箱的三层边界Android 的应用隔离不是一层是三层层层叠加的。第一层是Linux 的 UID 隔离——每装一个应用系统给它分配一个独立的 uid/data/data/package这个目录的所有者就是那个 uid权限位通常是700也就是只有属主能进。你随便开个终端ls -l /data/data会看到一列数字 uid那些数字就是各应用的身份证。第二层是SELinux 的类型强制访问控制。就算你把自己的进程 uid 改成了目标应用的 uidSELinux 的 domain 不匹配照样拒绝。这一层是很多人忽略的——他们以为拿到 root 就万事大吉实际上老设备上 root 之后还要处理 SELinux 的 enforcing 状态新设备上更是几乎不可能。第三层是应用自身的加密。主流 IM 应用早就不把聊天内容明文写盘了数据库文件本身可能是 SQLCipher 加密的密钥存在别处或者由用户口令派生。这意味着即使你突破了前两层拿到的也可能只是一堆二进制噪声。# 典型的一次尝试注意看报错 adb shell ls -l /data/data/ # ls: /data/data/: Permission denied adb shell run-as com.example.app ls # run-as: package not debuggable: com.example.app这两行输出基本就宣告了绝大多数免 root 直读数据库的幻想破灭。run-as只对android:debuggabletrue的应用有效而任何正式发布的商用 App 都不可能开这个开关。市面上偶尔有号称能用的多半是拿到了开发版安装包或者根本不是走这条路。1.2 免 root能拿到的权限上限是什么免 root 不等于没有权限提升的余地关键在于你能借到哪个身份的权限。Android 上有一个特殊身份叫shelluid 2000它是 ADB 调试通道的默认身份权限比普通应用高很多能pm装卸应用、能dumpsys看系统服务状态、能content query查 ContentProvider、能读/sdcard下的公共目录、能抓logcat。但shell依然不是 root。它进不去别的应用的私有目录改不了系统分区也绕不过 SELinux。这一点非常关键因为大量教程把ADB 能做很多事和ADB 什么都能做混为一谈。我见过有人折腾一整天就为了用 ADB 把某个应用的数据库pull出来最后发现adb pull /data/data/pkg/databases/xxx.db直接报Permission denied——这不是命令写错了是这条路本来就不通。所以免 root 的权限上限准确表述是你能拿到 shell 身份的全部能力外加用户主动授予的运行时权限和无障碍授权但拿不到应用私有目录的读权限。1.3 为什么大多数教程在第一步就走偏了常见的走偏方式有三种我按出现频率排一下。第一种是把界面上看得见当成数据能导出。你在聊天窗口里能翻到三年前的记录不代表这些记录能以结构化形式落盘。这两件事之间隔着整个应用的渲染层和存储层。第二种是拿旧版本系统的结论套新系统。adb backup这个命令在 Android 4.x 时代确实能整包备份应用数据2016 年之后随着targetSdkVersion提到 24 以上应用只要不显式开allowBackup这条命令就基本失效了。现在还在传播这套方法的内容八成是抄的五六年前的帖子。第三种是混淆了数据可见和数据完整。走无障碍通道确实能把屏幕上的文字一条条抓下来但附件、语音、撤回消息、时间戳精度、消息顺序这些信息在 UI 层是丢失或残缺的。做备份勉强够用做数据分析基本没法看。2. 三条免 root 通道的能力横评把能用的通道列清楚比盲目试工具效率高得多。我按能拿到的数据深度从高到低排同时把授权成本和稳定性也标出来。2.1 四条通道的横向对比通道需要的授权能触达的数据层级稳定性典型适用场景ADB 调试通道USB 调试 / 无线调试配对系统服务状态、ContentProvider 公开数据、公共存储、日志高设备排查、应用信息清点、日志分析无障碍服务用户在设置里手动开启屏幕上的节点文本、控件状态、可点击区域中本人设备的记录整理、UI 自动化测试屏幕采集 OCR录屏授权每次会话确认像素级画面需二次识别低兜底方案、无法获取节点树的场景系统备份 / 迁移工具跟随系统引导应用自己声明可备份的部分高换机迁移、整机备份这张表最该被注意的是第二列。授权方式决定了这件事的性质ADB 是你对自己的设备开的调试口无障碍是你自己点的开关录屏是你自己按的确认——全部需要设备持有者主动参与。任何号称远程就能拿到的方案在技术上就不成立可以直接判定为骗局。2.2 ADB 通道最接近 root 的合法口子ADB 是我平时用得最多的。Android 11 之后有了无线调试配对不用数据线也能连配对码六位数一次配对长期有效换网络要重新配。它的价值不在于能读私有数据——它读不到——而在于能把一个应用的运行状态摸得很清楚。# 看设备连接状态 adb devices -l # 列出所有包名配合 grep 过滤 adb shell pm list packages | grep -i example # 看某个包的详细信息版本、权限、数据目录、是否可调试 adb shell dumpsys package com.example.app | head -60 # 查询该应用暴露的 ContentProvider adb shell dumpsys activity providers | grep -A3 com.example.appdumpsys package的输出里有一行dataDir/data/user/0/com.example.app这就是它的私有目录路径你能看到路径但ls不进去。这个反差是很多人第一次接触时的困惑点其实很合理——元信息是公开的内容不是。content query值得单独说一句。如果某个应用注册了exportedtrue的 ContentProvidershell 身份是可以查询的。但主流 IM 应用早就把这类 Provider 收紧了能查到的通常是媒体索引、联系人映射这类辅助数据不是消息本体。你可以用dumpsys activity providers看有哪些但别抱太高期待。2.3 无障碍服务本质是替你点屏幕无障碍服务经常被误解成某种破解手段其实它的定位非常明确帮助操作不便的用户完成界面交互。它能拿到的是当前窗口的节点树每个节点带着text、contentDescription、className、boundsInScreen这些属性。!-- AndroidManifest.xml 里的服务声明 -- service android:name.ExportService android:exportedfalse android:permissionandroid.permission.BIND_ACCESSIBILITY_SERVICE intent-filter action android:nameandroid.accessibilityservice.AccessibilityService / /intent-filter meta-data android:nameandroid.accessibilityservice android:resourcexml/accessibility_config / /service!-- res/xml/accessibility_config.xml -- accessibility-service android:accessibilityEventTypestypeWindowContentChanged|typeViewScrolled android:accessibilityFeedbackTypefeedbackGeneric android:accessibilityFlagsflagReportViewIds|flagRetrieveInteractiveWindows android:canRetrieveWindowContenttrue android:notificationTimeout100 /这里flagReportViewIds很重要。加上它之后节点会带上viewIdResourceName你就可以用findAccessibilityNodeInfosByViewId()精确定位控件而不是靠文本匹配瞎猜。notificationTimeout设成 100 毫秒是为了做节流设太小会疯狂回调把 CPU 吃满设太大会漏掉快速滚动的中间态。它的硬伤也很清楚只能拿到当前渲染出来的东西。列表是虚拟化的划出屏幕的 item 会被回收节点树里就没有了。所以必须配合滚动动作一屏一屏抓中间还要处理加载延迟和重复项。2.4 屏幕采集加 OCR最后的兜底有些界面压根不暴露节点信息比如自绘的 Canvas 或者用了特殊渲染方案。这时候只能录屏截图再识别。MediaProjection需要每次会话弹窗确认这是系统的隐私保护设计绕不过去。拿到画面后用 ML Kit 或者 PaddleOCR 之类的本地模型识别中文场景下清晰截图的字符准确率能到 95% 以上但行序恢复是个大坑——OCR 返回的是带坐标的文本框你得自己按 y 坐标聚类成行、按 x 坐标排序遇到气泡左右分布自己发的靠右、对方发的靠左还得判断归属。我做过一次光排版还原的代码量就超过了识别本身。3. ADB 实操一次完整的本机数据清点上面讲的是能力边界这一节讲具体怎么跑。我按真实操作顺序写包括每一步的预期输出和常见报错。3.1 环境搭建与连接方式的取舍装platform-tools就行不要去下那些打包了一堆东西的一键工具版本混乱是排查问题的最大障碍。装完adb version确认一下建议 34 以上。连接有两种。有线最稳插上后在开发者选项里打开USB 调试首次连接手机上会弹授权框勾始终允许就不用每次点了。无线适合设备不方便插线的情况Android 11 之后路径是开发者选项 → 无线调试 → 使用配对码配对设备。# 配对端口和码在手机界面上显示每次不同 adb pair 192.168.1.100:37123 # 输入六位配对码 # 配对成功后连接注意这是另一个端口 adb connect 192.168.1.100:5555 # 确认 adb devices有个细节无线调试的端口每次重连可能变尤其是设备重启后。所以脚本里不要写死端口从adb mdns services动态取更靠谱。另外同一局域网内多台设备时adb -s serial指定目标不然命令会报 more than one device。3.2 包名侦察与目录探测的真实反馈# 第一步确认包名不同渠道包名可能不同 adb shell pm list packages -3 # -3 只列第三方应用比全量列表干净得多 # 第二步拿数据目录和 UID adb shell dumpsys package com.example.app | grep -E userId|dataDir|versionName # 第三步试着进目录预期失败 adb shell ls /data/data/com.example.app # ls: /data/data/com.example.app: Permission denied # 第四步换个角度看外部存储里有什么 adb shell ls /sdcard/Android/data/com.example.app/ adb shell ls /sdcard/Android/media/com.example.app/第三、第四步的结果对比很有意思。私有目录进不去但外部存储的Android/data/pkg目录Android 11 之后通过 ADB 是可以访问的里往往躺着缓存图片、下载的附件、临时文件。这部分不是聊天记录本体但附件类内容经常能在这里找到。我还遇到过一次特殊情况某应用把导出的备份文件写在/sdcard/Download/下文件名带时间戳用户自己都忘了。这种应用主动写到公共目录的情况是免 root 条件下唯一能完整拿到结构化数据的场景——因为它自己交出来的。3.3 备份指令为什么从能用变成不能用adb backup的历史值得讲清楚因为这是被误传最多的一个点。# 老教程里的写法 adb backup -f backup.ab -apk -shared -all com.example.app这个命令走的是 Android 的 Backup Manager 框架。应用有没有资格被备份取决于清单里的android:allowBackup默认 true。但从targetSdkVersion 24 开始系统对备份范围做了收紧只有在应用主动声明的情况下私有数据才会被纳入。绝大多数商用 App 直接把allowBackup设成false命令跑完你会得到一个几百字节的空文件。# 验证备份文件是不是空的 ls -lh backup.ab # 如果只有几百字节那就是什么都没备份到Android 12 之后又引入了dataExtractionRules把云备份和设备迁移两条路径分开配置可控性进一步细化。到这一步adb backup对第三方应用的实用价值基本归零。想解包.ab文件还得用abe之类的工具转成 tar转完发现里面是空的白忙一场。提示如果你只是想知道某个应用有没有开allowBackupdumpsys package的输出里能直接看到flags字段不用真的去跑备份命令。3.4 一条可复现的排查链路我把判断流程整理成一条链路按顺序走能快速定位到这条路通不通。第一步确认身份。adb shell id看当前是uid2000(shell)这是判断后续所有权限的基础。如果显示的是 root那说明设备已经 root 了讨论前提就变了。第二步确认包名和目标路径。dumpsys package里的dataDir是权威来源不要靠猜。第三步试探读权限。直接cat目标文件看报错是Permission denied还是No such file。前者是权限问题后者可能是路径错了或者文件压根不存在很多应用把数据存在加密容器里磁盘上看不到独立文件。第四步找替代路径。检查外部存储目录、检查应用有没有导出功能、检查系统备份里有没有这个应用的数据。第五步判定方案。如果前四步全部走不通那就只剩无障碍和 OCR 两条路此时要评估数据量和精度要求决定值不值得投入。这套流程我跑过几十次结论高度一致对主流 IM 应用免 root 直读数据库这条路是死的不存在换个命令就好了的可能。所有声称能做到的要么是骗人的要么设备其实已经 root 了而用户不知道有些第三方 ROM 或刷机包默认带 root。4. 无障碍自动化把屏幕上的内容搬下来这是免 root 条件下唯一有实际产出的方案缺点是慢、不完整、需要设备保持亮屏。我做过一个导出的工具踩的坑比预想多得多下面按开发顺序讲。4.1 服务注册与首屏接管前面贴过清单配置这里补几个实战要点。android:accessibilityFeedbackType设成feedbackGeneric就够了不需要震动或语音反馈。accessibilityEventTypes不要图省事写typeAllMask那样回调太频繁处理不及时会丢事件。只监听typeWindowContentChanged内容变化和typeViewScrolled滚动两个就够。服务启动后第一件事是getRootInActiveWindow()拿到根节点然后遍历。遍历要用递归但必须限制深度一般 25 层封顶再深基本是广告位或者装饰性容器。void walk(AccessibilityNodeInfo node, int depth, ListString out) { if (node null || depth 25) return; CharSequence text node.getText(); if (text ! null text.length() 0) { Rect r new Rect(); node.getBoundsInScreen(r); out.add(r.top \t r.left \t text); } for (int i 0; i node.getChildCount(); i) { walk(node.getChild(i), depth 1, out); } }把boundsInScreen一起记下来是有原因的后面判断消息归属左边还是右边、判断是否同一条消息的多行全靠这个坐标。4.2 翻页、等待与滚动到底的判定虚拟列表的滚动不能靠dispatchGesture模拟手指滑动那个太不可控。用performAction(AccessibilityNodeInfo.ACTION_SCROLL_FORWARD)让系统自己滚一次滚一屏左右行为稳定得多。AccessibilityNodeInfo list root.findAccessibilityNodeInfosByViewId( com.example.app:id/message_list).get(0); boolean ok list.performAction(AccessibilityNodeInfo.ACTION_SCROLL_FORWARD);这里有个必须处理的时序问题performAction是异步的返回 true 只代表动作被接受不代表新内容已经渲染。必须等typeWindowContentChanged事件到达再读下一屏直接Thread.sleep(500)在低端机上会漏在高性能机上会浪费时间。正确的做法是注册一个回调加超时保护。滚动到底的判定更麻烦。我试过三种一是比较两次抓取的首尾文本是否完全一致二是比较节点总数三是看有没有出现没有更多消息的提示节点。第三种最可靠但这取决于应用有没有这个提示第二种容易误判列表回收会导致数量波动第一种最通用但要多存一份上一屏的快照做比对。4.3 去重、断点续传与数据落地抓下来的数据一定会有重复因为滚动过程中上一屏的尾部往往会留在下一屏的顶部。去重的锚点要选好纯文本做哈希不够因为同一个人连发两条好的哈希值一样会被误删。我的做法是三元组(发送者标识, 消息文本, 屏幕坐标的相对位置)再加上抓取顺序的序号做二次校验。落地用 SQLite建唯一索引(sender, content, seq_window)用INSERT OR IGNORE写入这样中断重跑也不会脏数据。断点续传靠记录最后一屏的第一条消息的哈希下次从这个位置往前找。实践下来成功率大概八成——剩下的两成是因为消息被撤回了或者应用重启了列表位置只能人工对齐。还有一个细节容易忽略长文本消息在屏幕上会被折叠节点树里拿到的只有前半段后面是全文按钮。所以遍历的时候要检查有没有可点击的展开控件有就先点开再抓。这个坑我卡了很久导出结果里一堆消息莫名其妙被截断最后才定位到这儿。5. 官方通道才是最优解讲了一堆技术方案但我必须说句实话如果你的目的是换机、备份、找回自己的记录官方通道的成功率和完整性都远高于上面任何一种。很多人舍近求远是因为不知道或者不愿意用。5.1 系统级备份与迁移工具的能力边界Android 的换机迁移工具各家厂商都有自己的实现走的是系统级的设备间直传原理上是通过BackupTransport把应用声明的可备份数据打包搬到新设备。哪些数据会被搬由应用的dataExtractionRules决定。!-- 应用侧的配置示例决定哪些目录参与设备迁移 -- data-extraction-rules device-transfer include domaindatabase path. / include domainsharedpref path. / exclude domainfile pathcache / /device-transfer /data-extraction-rules配置里device-transfer和cloud-backup是分开的前者对应换机直传后者对应云备份。很多应用允许前者、禁止后者怕数据上云有合规风险这就解释了为什么换机后记录还在但从云备份恢复就没有。实操上的建议很直接换机前先看应用内的设置里有没有聊天记录迁移之类的入口有就先用它这是最省事的。厂商的整机迁移工具可以作为第二选择注意两台设备都要保持电量充足、连同一个 Wi-Fi、不要中途锁屏。5.2 应用自带的导出功能被严重低估我见过太多人折腾 ADB 折腾一整天最后发现应用设置里就有一个导出按钮。主流 IM 应用基本都提供了单聊记录导出、收藏内容导出、账单导出这些功能只是入口埋得深藏在设置 → 通用 → 存储空间或者帮助与反馈里面。这些功能的输出格式通常是 HTML 或纯文本打包附件会一起打进去。缺点是只支持单会话、不支持全量、导出大文件时容易中断。但如果你只是要保留某几个重要会话这已经是最优解了。5.3 什么时候该果断放弃技术方案我给自己定了几条止损线碰到就换思路不再死磕第一条目标应用没开allowBackup且没开device-transfer同时界面不暴露节点文本。这种情况三条通道全堵死只剩 OCR成本收益完全不匹配。第二条数据量超过几千条消息。无障碍方案抓几千条要跑几个小时中间任何一次来电、通知、息屏都可能打断重跑的成本太高。第三条对时间戳和顺序有严格要求。UI 层能拿到的信息不足以还原精确的时间顺序同一分钟内的多条消息顺序只能靠坐标猜做时序分析会得出错误结论。6. 合规边界与几条踩坑经验技术之外的话我放在最后讲因为这部分比代码重要。6.1 三条我不碰的线第一条不是自己的设备不碰。哪怕对方口头授权哪怕关系再亲近只要设备不属于你动手就是错的。技术上能做到和应该做之间没有任何推导关系。第二条不碰别人的账号数据。备份自己的数据和读取别人的数据中间隔着的不是技术难度是性质。第三条不做绕过安全机制的事。如果一个方案的前提是破解绕过解除限制那它就已经出界了。我上面讲的 ADB、无障碍、录屏全部依赖设备持有者主动授权授权这个动作本身就是合法性的来源。我遇到过有人问有没有不用对方同意就能看的办法这类问题我一律不接。不是我技术不行是这条路从起点就不该走。而且从现实角度看这类需求催生的所谓工具绝大多数是木马装上去数据没拿到自己的账号先被盗了。6.2 几条实际踩过的坑坑一以为 root 了就万事大吉。早期设备上 root 之后su一拿确实能进/data/data但新系统上 SELinux 是 enforcing 的ls照样被拒得先setenforce 0。再往后应用数据加密普及数据库文件打开是乱码。所以root 就能读这个认知已经过时好几年了。坑二run-as对 release 包完全无效。我一开始不知道run-as要求debuggabletrue写了个脚本天天跑报错当成环境问题排查了半天最后发现是方向错了。坑三无线调试连上后忘了断。有一次调试完没关连接设备换了个网络adb devices里挂着一堆offline的僵尸条目新命令一直超时。清理办法是adb kill-server然后重连或者用adb disconnect ip:port精确断掉。坑四无障碍服务被系统回收。长时间运行的无障碍服务会被功耗管理干掉尤其是设备息屏之后。做长时间导出任务必须申请WakeLock同时在onServiceConnected里做恢复逻辑检测到被中断就从上次的位置继续。坑五OCR 的行序还原比想象中难得多。气泡左右分布、表情符号、 提及、引用回复的缩进块这些排版元素都会干扰排序。我最后的做法是先用气泡背景色的连通域划分消息块再在块内做行聚类比纯坐标排序靠谱得多。坑六备份文件别往公共目录乱丢。导出的数据落在/sdcard/Download/之后任何有存储权限的应用都能读到。落地位置最好选应用私有目录导出完成再通过系统分享交给用户中间态不要暴露。坑七数据量大的时候别一次性读进内存。我第一版实现是把所有节点拼成一个大 List 最后统一写库抓到两万条的时候 OOM 了。改成流式写入、每屏提交一次事务之后就稳了速度还快了不少。最后说个我自己的体会。这几年处理这类需求最大的收获不是学会了多少取数技巧而是学会了在动手之前先判断这件事该不该做。技术上的可能性是无限的但每一条路都有它的成本和边界认清边界比突破边界更有价值。真要备份自己的数据翻翻应用设置、用用官方迁移工具往往比写几百行自动化代码管用得多。
