核心目标：解决library not found、dlopen failed、UnsatisfiedLinkError等 Native 层崩溃。适用场景：腾讯会议、Flutter 应用或定制 APK 在 ARM/x86 设备（特别是 RK3566 等定制系统）上无法启动。
🔍 第一阶段：诊断与溯源 (Diagnosis)
在动手修复前，必须先确定问题是“安装包缺失”还是“系统未解压/路径错误”。
1. 检查 APK 内部 (源头验证) —— “金标准”
如果 APK 里都没有，设备上肯定找不到。
# 1. 获取 APK 安装路径 adb shell pm path com.tencent.wemeet.controller # 输出示例: package:/data/app/com.tencent.wemeet.controller-xxx/base.apk # 2. 直接查看 APK 压缩包内是否包含目标库 (将 <PATH> 替换为上一步结果) adb shell "unzip -l <PATH> lib/arm64-v8a/libflutter.so"- 成功：显示文件名和大小（如
10005701），说明APK 完整。 - 失败：
filename not matched，说明APK 打包时就不包含该库，需重新打包。
2. 检查运行时环境 (落地验证)
确认系统是否已将库文件从 APK 中解压到数据目录。
# 1. 检查应用数据目录下的库文件 (最常见的解压路径) adb shell ls -l /data/data/com.tencent.wemeet.controller/lib/ # 2. 检查应用支持的 CPU 架构 (确认是否为 64 位) adb shell dumpsys package com.tencent.wemeet.controller | grep -E "primaryCpuAbi|supportedAbis"- 关键点：
- 如果
/data/data/.../lib/目录为空，但 APK 里有文件，通常是Split APK 机制导致的（系统按需解压，但可能误判了设备架构）。 - 如果目录结构多了一层
arm64-v8a（即/lib/arm64-v8a/lib.so），而代码去/lib/下找，就会报错。
- 如果
🛠️ 第二阶段：修复流程 (Repair)
1. 软件级修复 (推荐，无需改分区)
适用于 APK 内有库，但数据区丢失或损坏的情况。
# 强制清除应用数据 (触发系统重新解压库文件) adb shell pm clear com.tencent.wemeet.controller注意：此操作会清除应用缓存和登录信息，但能强制系统在下次启动时重新从 APK 解压 SO 库。
2. 硬件级/系统级修复 (手动替换)
适用于定制固件或系统分区被锁定，无法自动修复的情况。
# 1. 获取 Root 权限并重新挂载系统分区 adb root adb remount # 2. 推送新的库文件到手机临时目录 adb push libflutter.so /data/local/tmp/ # 3. 复制到系统目录并修改权限 (关键步骤) adb shell "cp /data/local/tmp/libflutter.so /system/app/Controller/lib/arm64/ && chmod 644 /system/app/Controller/lib/arm64/libflutter.so" # 4. 验证文件是否到位 adb shell ls -l /system/app/Controller/lib/arm64/libflutter.so💡 目录结构调整技巧： 如果发现库文件在arm64-v8a子目录中，需要将其提升到父目录（arm64）：
adb shell cd /system/app/Controller/lib/arm64 # 如果存在 arm64-v8a 目录，则进入并移动文件 if [ -d "arm64-v8a" ]; then mv arm64-v8a/* . rmdir arm64-v8a fi ls -l # 确认文件列表 reboot🧠 第三阶段：核心排错思维导图
当遇到dlopen failed: library "libflutter.so" not found时，请按此顺序排查：
文件是否存在？
- 检查点：
unzip -l <APK_PATH>。 - 结论：如果这里没有，必须换包或重新打包。
- 检查点：
路径是否正确？
- 检查点：
/data/data/<PKG>/lib/。 - 现象：文件缺失 -> 执行
pm clear。 - 现象：目录结构嵌套（
arm64/arm64-v8a/xxx.so） -> 手动mv移动文件。
- 检查点：
架构是否匹配？
- 检查点：
dumpsys package查看primaryCpuAbi。 - 现象：设备是
arm64，但 APK 只有armeabi-v7a-> 兼容性问题，需找对应版本 APK。 - 坑点：不要把 x86 的 SO 放到 ARM 设备上（
has unexpected e_machine错误）。
- 检查点：
依赖是否满足？
- 现象：文件存在、路径对、权限好，但依然报找不到。
- 原因：该 SO 依赖其他系统库（如
libandroid.so）。需检查系统版本或联系 SDK 提供商。
⚡ 常用命令速查表
| 功能 | 命令 |
|---|---|
| 重启 ADB 为 Root 模式 | adb root |
| 重新挂载 System 分区 | adb remount |
| 清除应用数据 | adb shell pm clear <PKG> |
| 查看文件列表 | adb shell ls -l <PATH> |
| 修改文件权限 | adb shell chmod 644 <FILE> |
| 断开所有连接 | adb disconnect |
📝 定制系统 (RK3566) 特别补充
针对设备 shell 命令缺失（如find、grep不可用）的情况：
- 诊断转移：利用电脑端的
adb shell "unzip -l <PATH>"检查 APK 内部，不要依赖设备的find命令。 - 修复转移：在电脑上解压 APK 确认文件完整性，或者直接使用
adb push将准备好的 SO 文件推送到/system目录，绕过设备复杂的脚本环境。
总结建议： 大多数“库找不到”的问题，通过adb shell pm clear <PKG>即可解决（触发系统重新解压）。如果是在定制系统上，请务必检查/system/app/.../lib/arm64/目录结构，确保没有多余的arm64-v8a嵌套层级。
