简介这份Android小米文件管理器源码包面向Android中高级开发者尤其适合想研究系统级文件管理类应用的人群。资源共403个文件其中含144个类文件与78个编码源文件构成的代码主体另有144张界面图片、24个布局配置文件以及安装包、字节码包、依赖扩展包等构建产物整体压缩后仅1.57兆目录划分清晰按模块检索非常方便。目前已有131人浏览学习过这份资源。通过源码可拆解文件管理的完整链路借助内容提供器访问文件根据媒体类型识别并分类图片、视频、文档覆盖搜索、排序、复制、移动、重命名等操作同时研究目录树构建、缓存策略、运行时权限申请、列表异步加载与线程池调度等机制能直观理解一款商用文件管理器的实现思路。对希望提升文件系统编程能力、掌握界面交互设计与开源应用架构的开发者而言这是一份性价比很高的参考资料。1. 拿到 Android 小米文件管理器源码包后先弄清它到底是什么Android 小米文件管理器源码.rar这个文件名很有吸引力但解压之后你看到的通常不是 MIUI 里那个文件管理的官方源码而是一组 smali 目录、resources.arsc 和签名文件——也就是反编译产物或是别人整理过的可编译骨架并非小米开源代码。有价值的是它背后的整套 Android 文件管理实现存储权限、MediaStore 查询、FileProvider 授权、复制进度、分区存储适配每个点都是一本排错记录。下面这条从验包、反编译到重建工程的路径会把每一条命令和参数讲透适合做工具类 App 或需要处理存储适配的 Android 开发者。2. 文件管理器源码的骨架Android 存储分层与 SAF 权限模型要读懂任何一份文件管理器源码先得把 Android 的存储层拆开。文件管理器不是简单的读目录因为从 Android 6 到 Android 13每一次权限模型变化都直接改写源码里的访问方式。2.1 为什么源码里到处是 ContentResolver 和 Uri现代文件管理器源码里你很少看到直接new File(/sdcard/DCIM)这种写法更多的是ContentResolver.query、openFileDescriptor、takePersistableUriPermission这类调用。原因是路径访问在 Android 11 之后受到严格限制内容访问Content模式是系统推荐的替代方案。源码里凡是涉及图片、视频、音频分类的模块几乎都走 MediaStore涉及第三方目录比如 Android/data 下的应用数据则走 Storage Access Framework 的 DocumentFile。理解这一点你才能看懂为什么源码里到处是 Uri 而不是 String 路径。2.2 传统 File API 与分区存储的分界targetSdk 决定兼容策略文件管理器源码里通常会有两套实现并存旧版本地 File 直接递归目录新版本用 MediaStore 加 ActivityResultContracts。分界线就是 targetSdkVersion 和运行时权限访问方式适用场景权限要求Android 11 限制File API 直接路径应用私有目录、Android 10 以下设备READ_EXTERNAL_STORAGE/Android/data 不可读MediaStore API媒体文件分类、检索、插入READ_EXTERNAL_STORAGE查询受限需按集合查询SAF / DocumentFile用户主动挑选目录、跨应用文件共享无需持久权限需 takePersistableUriPermission推荐方式MANAGE_EXTERNAL_STORAGE全文件管理 App特殊权限需 Intent 引导用户授权应用市场审核严格拿到源码后第一件事就是查 AndroidManifest.xml 里的 targetSdkVersion。如果它停在 29说明源码作者还没处理分区存储如果已经到 30 以上注意看有没有MANAGE_EXTERNAL_STORAGE声明以及对应Settings.ACTION_MANAGE_APP_ALL_FILES_ACCESS_PERMISSION的跳转代码。这也是为什么同一个小米文件管理器 APK在 Android 10 手机上一切正常换到 Android 13 上却点进目录就闪退。2.3 源码里常见的文件访问路径三件套一份完整的文件管理器源码通常会包含下面三个模块对应三种访问方式// 方式一MediaStore 查询图片集合 ContentResolver resolver context.getContentResolver(); Uri collection MediaStore.Images.Media.getContentUri(MediaStore.VOLUME_EXTERNAL_PRIMARY); String[] projection {MediaStore.Images.Media._ID, MediaStore.Images.Media.DISPLAY_NAME, MediaStore.Images.Media.SIZE, MediaStore.Images.Media.DATE_MODIFIED}; try (Cursor cursor resolver.query(collection, projection, null, null, MediaStore.Images.Media.DATE_MODIFIED DESC)) { while (cursor.moveToNext()) { long id cursor.getLong(cursor.getColumnIndexOrThrow(MediaStore.Images.Media._ID)); Uri contentUri ContentUris.withAppendedId(collection, id); // 这里拿到的 contentUri 可以直接交给图片加载库使用 } }这段代码是文件管理器图片分类页的基础。VOLUME_EXTERNAL_PRIMARY表示主外置存储也就是通常说的内置存储查询条件里可以使用RELATIVE_PATH按目录过滤但这个字段在 Android 10 才有源码里要兼容旧设备就得先判断SDK_INT再决定是否把RELATIVE_PATH拼进 selection。排序用DATE_MODIFIED DESC是为了让最近修改的文件排前面这是文件管理器最常用的排序参数和桌面端文件列表的习惯一致。3. 从 .rar 到可读工程jadx、apktool 与资源还原的完整链路3.1 先验包怎么判断手里是 smali 还是可编译 Java 工程拿到 .rar 先解压然后 cd 进去看目录结构。如果顶层有app/src/main/java这样的路径说明是 Android Studio 工程如果看到一堆以 smali 命名的目录里面全是 .smali 文件那就是反编译产物如果只有 classes.dex 加 AndroidManifest.xml那连反编译都还没做。先跑一条 find 确认find . -maxdepth 4 -type d \( -name smali* -o -name java -o -name kotlin \) | head -20这一步决定了整个工作流的方向。smali 目录说明需要先用 jadx 还原 Java 再人工阅读有 java 目录说明可以直接导入 Android Studio只有 manifest 和 dex 的需要自己补完整的 Gradle 工程骨架。3.2 用 jadx 把 DEX 还原成可读 Java 的最小命令如果是 APK 或 dex 形态jadx 是还原度最高的选择能把混淆前的方法调用关系、资源引用恢复得比较完整# 把整个 APK 反编译成可读 Java 工程 jadx -d output_src -j 8 mi_file_manager.apk # 只反编译指定类适合快速定位 jadx --show-bad-code -d output_src -c com.android.filemanager.MainActivity-d指定输出目录-j 8是并行线程数机器内存小就降到 4--show-bad-code让 jadx 在无法完整还原的方法体里输出近似代码而不是留一具空壳。反编译完成后源码里经常出现形如String str;的占位变量名这是混淆开启且变量表被移除的结果阅读时要结合调用上下文去猜语义。这时候不要急着逐行读先全局搜onCreate、onResume入口方法把主流程串起来。提示jadx 输出的工程里夹杂大量反编译噪声先跑一遍编译让 IDE 的标红过滤出能编译与不能编译的类效率远高于人肉逐行排查。3.3 用 apktool 解码资源和 AndroidManifest找回包结构与权限申请jadx 负责 Java 代码apktool 负责资源和 manifest。很多关键信息——申请的权限、FileProvider 的 authority、targetSdkVersion——都藏在解码后的 AndroidManifest.xml 里# 解包 APK得到 smali 目录、未编码的 manifest 和 res 目录 apktool d mi_file_manager.apk -o apk_decode # 重打包改完 smali 或资源后 apktool b apk_decode -o repack.apk解码后立即查看apk_decode/AndroidManifest.xml里的uses-permission和application节点。文件管理器源码通常会申请READ_EXTERNAL_STORAGE、WRITE_EXTERNAL_STORAGE、MANAGE_EXTERNAL_STORAGE以及一组provider节点用于 FileProvider。注意 apktool 解出来的 manifest 是可读明文 XML如果你只是想知道它申请了哪些权限这一步比 jadx 更快。3.4 在 Android Studio 重建可编译工程的三个必调参数把反编译产物变成能一键运行的工程是工作量最大的环节。常见做法是新建一个空 Android 工程把 jadx 输出的 java 目录拷进 app/src/main/java把 apktool 解出的 res 拷进 app/src/main/res然后改三个地方// app/build.gradle 里的三个关键参数 android { compileSdk 34 defaultConfig { applicationId com.android.filemanager // 与原包一致避免 FileProvider 冲突 minSdk 21 targetSdk 29 // 先降到 29绕过分区存储跑通了再升 versionCode 1 } compileOptions { sourceCompatibility JavaVersion.VERSION_1_8 targetCompatibility JavaVersion.VERSION_1_8 } }三个参数各有讲究。applicationId必须和原包名一致否则 ContentProvider 的 authority 和桌面快捷方式都会错位targetSdk先设 29 不是因为安全而是 30 之后分区存储强制生效源码里那套 File 路径递归在 30 以上必然崩溃先跑通核心逻辑再回来适配compileSdk使用本机 Android SDK 里最新的稳定版即可不要低于源码里的 targetSdk。改完这三处再把缺失的依赖一般是 androidx.appcompat、material、glide补进 dependencies理论上就能编译了。实际编译报错集中在资源引用和隐藏 API 调用两处前者去 res 目录里找缺失的 drawable后者要删除或替换对非公开 API 的反射调用。4. 源码核心模块拆解文件列表、复制传输与分类页的实现参数4.1 文件列表的双层结构目录枚举与排序参数文件管理器的核心是列表页源码里通常拆成两层数据层用ListFileInfo持有文件元数据UI 层用 RecyclerView 的 Adapter 渲染。FileInfo 一般只有几个字段name、path、size、isDirectory、modifiedTime、mimeType。目录枚举的关键在排序和过滤private ListFileInfo listFiles(File dir, boolean showHidden) { File[] files dir.listFiles(); if (files null) return new ArrayList(); ListFileInfo result new ArrayList(); for (File f : files) { if (!showHidden f.isHidden()) continue; // 隐藏文件过滤 String name f.getName().toLowerCase(); if (name.endsWith(.db) || name.endsWith(.nomedia)) continue; // 系统文件过滤 FileInfo info new FileInfo(); info.setPath(f.getAbsolutePath()); info.setName(f.getName()); info.setDirectory(f.isDirectory()); info.setSize(f.isDirectory() ? -1 : f.length()); info.setModifiedTime(f.lastModified()); result.add(info); } // 目录在前目录和文件各自按名称排序 result.sort((a, b) - { if (a.isDirectory() ! b.isDirectory()) return a.isDirectory() ? -1 : 1; return a.getName().compareToIgnoreCase(b.getName()); }); return result; }注意listFiles()返回 null 有两种情况一是目录不存在二是无权限访问。如果源码里没有判空一进文件夹就白屏这是反编译源码最常见的隐藏 bug 之一。过滤.nomedia是因为多媒体扫描会跳过这些目录文件管理器如果显示了反而和系统相册表现不一致。排序用compareToIgnoreCase避免大小写敏感导致中文文件名排到最后。实际使用中排序参数经常要调文件管理器都有名称/时间/大小/类型四种排序切换到时间排序时把比较器换成基于modifiedTime即可。4.2 复制与移动进度回调拆成可取消的循环复制文件是文件管理器里最容易写得又慢又难用的部分。简单写法是流循环读再写但缺了进度和取消。源码里一个常见做法是把复制动作封装成 Runnable用回调接口上报进度public interface TransferCallback { void onProgress(int percent, String currentFile); boolean isCancelled(); void onFinished(boolean success, long totalBytes); } public void copyFile(File src, File dst, TransferCallback cb) throws IOException { byte[] buffer new byte[512 * 1024]; // 512KB 缓冲区 try (InputStream in new FileInputStream(src); OutputStream out new FileOutputStream(dst)) { long total src.length(); long copied 0; int len; while ((len in.read(buffer)) ! -1) { if (cb.isCancelled()) { out.flush(); dst.delete(); // 取消时清理半成品文件 throw new IOException(user cancelled); } out.write(buffer, 0, len); copied len; cb.onProgress((int) (copied * 100 / total), src.getName()); } } }缓冲区大小直接决定传输速度与进度粒度。512KB 在绝大多数 Android 设备上是吞吐和内存的平衡点1MB 以上在低端机上会因为 GC 抖动导致速度反倒下降缓冲区过小比如 8KB则会让小文件拷贝慢得离谱。取消不是简单 break而是要做到取消时把已创建的半成品删掉否则目录里会残留一个不完整文件。onProgress回调不要在子线程里直接更新 UI源码里一般通过 Handler 或 LiveData 转发到主线程否则会崩在CalledFromWrongThreadException。移动文件同目录下就是 Java 的File.renameTo跨目录则要先复制后删除。4.3 分类页MIME 类型与 MediaStore 查询条件的映射小米文件管理器的图片/视频/音频/文档四个分类页本质是四组不同的 MediaStore 查询条件。文档分类比媒体分类复杂因为文档没有独立集合只能靠 MIME 类型过滤private void queryDocuments(ContentResolver resolver) { Uri collection MediaStore.Files.getContentUri(MediaStore.VOLUME_EXTERNAL_PRIMARY); String selection MediaStore.Files.FileColumns.MIME_TYPE IN (?, ?, ?, ?); String[] selectionArgs {text/plain, application/pdf, application/msword, application/vnd.openxmlformats-officedocument.wordprocessingml.document}; String[] projection {MediaStore.Files.FileColumns._ID, MediaStore.Files.FileColumns.DISPLAY_NAME, MediaStore.Files.FileColumns.SIZE, MediaStore.Files.FileColumns.DATE_MODIFIED}; try (Cursor cursor resolver.query(collection, projection, selection, selectionArgs, MediaStore.Files.FileColumns.DATE_MODIFIED DESC)) { while (cursor.moveToNext()) { long id cursor.getLong(cursor.getColumnIndexOrThrow(MediaStore.Files.FileColumns._ID)); Uri fileUri ContentUris.withAppendedId(collection, id); // 用 fileUri 读取或分享该文档 } } }MediaStore.Files是所有文件的统一集合用 MIME_TYPE 过滤出任意类型。MIME 映射表要单独维护APK 是application/vnd.android.package-archive压缩包是application/x-zip-compressed和application/x-rar-compressed表格是application/vnd.ms-excel。这个映射表在源码里通常是一个HashMapString, Stringkey 是扩展名value 是 MIME。改分类页展示时只需要在这个表里增删条目不需要动查询逻辑。5. 源码踩坑实录混淆定位、FileProvider 冲突与 Android 11 分区存储5.1 混淆后的类名定位从崩溃堆栈倒推源码反编译源码最常见的问题是类名和方法名已经变成 a、b、c 这种短名崩溃日志里也是这些短名。定位方式不是去源码里搜完整类名而是用映射表。如果 APK 发布时附带 mapping.txt通常是和 APK 一起发布的那份先把它跑一遍 Retrace 工具如果没有映射表就靠入口方法和布局反查。常见做法是先打开res/layout/main.xml找到界面结构然后通过findViewById的调用点反推业务类比大海捞针快得多。5.2 FileProvider authority 冲突为什么 content:// 分享会闪退文件管理器几乎必然有分享文件功能实现方式是 FileProvider。反编译源码里 FileProvider 的 authority 往往写死比如com.android.filemanager.fileprovider。如果改包名时没同步改AndroidManifest.xml中provider的authorities和res/xml/file_paths.xml运行时一调FileProvider.getUriForFile就抛IllegalArgumentException: Couldnt find meta-data for provider。检查点是两处保持一致!-- AndroidManifest.xml 中的声明 -- provider android:nameandroidx.core.content.FileProvider android:authorities${applicationId}.fileprovider android:exportedfalse android:grantUriPermissionstrue meta-data android:nameandroid.support.FILE_PROVIDER_PATHS android:resourcexml/file_paths / /providerauthorities写成${applicationId}.fileprovider是 Android Studio 模板的推荐做法而反编译源码里往往是硬编码。用 Gradle 改applicationId时 Placeholder 会自动替换硬编码不会这就是改包名后分享功能必崩的原因。另外注意file_paths.xml里若保留了root-path对应整个文件系统即使自己有全部文件权限也拿不到/Android/data/下的访问权那是系统限制和 authority 无关。此前网上流传的各种content://...fileprovider/external_path/android/data/...直链在 Android 11 之后用浏览器或文件管理器打开基本都返回空目录或报错根源就是分区存储规则不是链接本身写错。5.3 Android 11 之后 /Android/data 不可读的适配方案这是文件管理器源码适配里绕不开的问题。Android 11 起普通应用即使申请了MANAGE_EXTERNAL_STORAGE也无法通过路径访问/Android/data和/Android/obb。很多从 Android 10 移植来的源码在这里直接失效。常见适配策略是分层处理对/Android/data引导用户在系统文件管理器中手动操作自己的 App 不展示该目录对应用自身的数据用context.getExternalFilesDir()拿到应用专属路径展示对用户选择的任意目录用ACTION_OPEN_DOCUMENT_TREE让用户授权后以DocumentFile.fromTreeUri访问并调用takePersistableUriPermission持久化授权避免每次重启都要重新选目录。注意不要试图用反射绕过 /Android/data 的限制Android 13 以上系统服务层直接拦截投入产出比极低老老实实按 SAF 授权路径走。5.4 反编译源码再打包的三个验证点反编译又重打包的 APK容易出现三个问题签名不对、资源引用错位、权限声明丢失。验证命令如下# 检查 APK 的包名、版本、权限与 targetSdk aapt dump badging app-debug.apk | grep -E package|uses-permission|targetSdk # 查看签名信息是否完整 apksigner verify --print-certs app-debug.apk # 用 zipalign 对齐后再签名避免运行时资源读取异常 zipalign -v 4 app-debug.apk aligned.apk apksigner sign --ks my.keystore --ks-pass pass:123456 --out signed.apk aligned.apkaapt dump badging是最快的验证手段一行输出就能确认包名、targetSdk 和权限有没有丢。zipalign对齐是 Google Play 的硬性要求未对齐的 APK 在部分机型上会出现资源读取段错误反编译工程尤其容易漏这一步。签名用 debug keystore 即可自测但注意同一台设备上不能同时安装 debug 签名和 release 签名的同包名应用卸载重装是常见操作。6. 把这份源码改造成最小可用工程自校验与产物核验6.1 最小裁剪边界只保留四个页面拿到一份反编译源码不要试图全量理解。先做最小可跑裁剪保留首页文件列表、分类页图片/视频/音频/文档、搜索入口和分享动作其余如云盘、回收站、清理加速全部注释掉。裁剪标准是——凡是入口在主页 Tab 上、切换后需要独立权限的模块全部从MainActivity里摘除。这样编译时间从几分钟降到几十秒调试定位范围也缩小到几条主线。6.2 用 adb 脚本做存储行为冒烟测试改造完成后用 adb 脚本做冒烟测试比手动点界面高效得多# 安装并授予文件访问权限 adb install -r app-debug.apk adb shell pm grant com.myfilemanager android.permission.READ_EXTERNAL_STORAGE # 启动主界面并 dump 当前 Activity确认没有闪退 adb shell am start -n com.myfilemanager/.MainActivity sleep 2 adb shell dumpsys activity top | grep ACTIVITY # 触发随机事件观察崩溃日志 adb shell monkey -p com.myfilemanager --pct-syskeys 0 --throttle 300 200 adb logcat -d -s AndroidRuntime:E | tail -30pm grant只能授予普通权限MANAGE_EXTERNAL_STORAGE这类特殊权限必须通过系统设置页手动授予脚本无法直接完成这是测试时容易误判的一环。monkey随机事件配合logcat -s AndroidRuntime:E过滤能在十分钟内暴露大部分空指针和越界问题。最后用apksigner verify确认签名合格再确认 logcat 里没有指向/Android/data的FileNotFoundException然后把targetSdk从 29 升到 30 重新过一遍冒烟脚本一套能自用的文件管理器工程就算交付了。本文还有配套的精品资源点击获取
简介这份Android小米文件管理器源码包面向Android中高级开发者尤其适合想研究系统级文件管理类应用的人群。资源共403个文件其中含144个类文件与78个编码源文件构成的代码主体另有144张界面图片、24个布局配置文件以及安装包、字节码包、依赖扩展包等构建产物整体压缩后仅1.57兆目录划分清晰按模块检索非常方便。目前已有131人浏览学习过这份资源。通过源码可拆解文件管理的完整链路借助内容提供器访问文件根据媒体类型识别并分类图片、视频、文档覆盖搜索、排序、复制、移动、重命名等操作同时研究目录树构建、缓存策略、运行时权限申请、列表异步加载与线程池调度等机制能直观理解一款商用文件管理器的实现思路。对希望提升文件系统编程能力、掌握界面交互设计与开源应用架构的开发者而言这是一份性价比很高的参考资料。1. 拿到 Android 小米文件管理器源码包后先弄清它到底是什么Android 小米文件管理器源码.rar这个文件名很有吸引力但解压之后你看到的通常不是 MIUI 里那个文件管理的官方源码而是一组 smali 目录、resources.arsc 和签名文件——也就是反编译产物或是别人整理过的可编译骨架并非小米开源代码。有价值的是它背后的整套 Android 文件管理实现存储权限、MediaStore 查询、FileProvider 授权、复制进度、分区存储适配每个点都是一本排错记录。下面这条从验包、反编译到重建工程的路径会把每一条命令和参数讲透适合做工具类 App 或需要处理存储适配的 Android 开发者。2. 文件管理器源码的骨架Android 存储分层与 SAF 权限模型要读懂任何一份文件管理器源码先得把 Android 的存储层拆开。文件管理器不是简单的读目录因为从 Android 6 到 Android 13每一次权限模型变化都直接改写源码里的访问方式。2.1 为什么源码里到处是 ContentResolver 和 Uri现代文件管理器源码里你很少看到直接new File(/sdcard/DCIM)这种写法更多的是ContentResolver.query、openFileDescriptor、takePersistableUriPermission这类调用。原因是路径访问在 Android 11 之后受到严格限制内容访问Content模式是系统推荐的替代方案。源码里凡是涉及图片、视频、音频分类的模块几乎都走 MediaStore涉及第三方目录比如 Android/data 下的应用数据则走 Storage Access Framework 的 DocumentFile。理解这一点你才能看懂为什么源码里到处是 Uri 而不是 String 路径。2.2 传统 File API 与分区存储的分界targetSdk 决定兼容策略文件管理器源码里通常会有两套实现并存旧版本地 File 直接递归目录新版本用 MediaStore 加 ActivityResultContracts。分界线就是 targetSdkVersion 和运行时权限访问方式适用场景权限要求Android 11 限制File API 直接路径应用私有目录、Android 10 以下设备READ_EXTERNAL_STORAGE/Android/data 不可读MediaStore API媒体文件分类、检索、插入READ_EXTERNAL_STORAGE查询受限需按集合查询SAF / DocumentFile用户主动挑选目录、跨应用文件共享无需持久权限需 takePersistableUriPermission推荐方式MANAGE_EXTERNAL_STORAGE全文件管理 App特殊权限需 Intent 引导用户授权应用市场审核严格拿到源码后第一件事就是查 AndroidManifest.xml 里的 targetSdkVersion。如果它停在 29说明源码作者还没处理分区存储如果已经到 30 以上注意看有没有MANAGE_EXTERNAL_STORAGE声明以及对应Settings.ACTION_MANAGE_APP_ALL_FILES_ACCESS_PERMISSION的跳转代码。这也是为什么同一个小米文件管理器 APK在 Android 10 手机上一切正常换到 Android 13 上却点进目录就闪退。2.3 源码里常见的文件访问路径三件套一份完整的文件管理器源码通常会包含下面三个模块对应三种访问方式// 方式一MediaStore 查询图片集合 ContentResolver resolver context.getContentResolver(); Uri collection MediaStore.Images.Media.getContentUri(MediaStore.VOLUME_EXTERNAL_PRIMARY); String[] projection {MediaStore.Images.Media._ID, MediaStore.Images.Media.DISPLAY_NAME, MediaStore.Images.Media.SIZE, MediaStore.Images.Media.DATE_MODIFIED}; try (Cursor cursor resolver.query(collection, projection, null, null, MediaStore.Images.Media.DATE_MODIFIED DESC)) { while (cursor.moveToNext()) { long id cursor.getLong(cursor.getColumnIndexOrThrow(MediaStore.Images.Media._ID)); Uri contentUri ContentUris.withAppendedId(collection, id); // 这里拿到的 contentUri 可以直接交给图片加载库使用 } }这段代码是文件管理器图片分类页的基础。VOLUME_EXTERNAL_PRIMARY表示主外置存储也就是通常说的内置存储查询条件里可以使用RELATIVE_PATH按目录过滤但这个字段在 Android 10 才有源码里要兼容旧设备就得先判断SDK_INT再决定是否把RELATIVE_PATH拼进 selection。排序用DATE_MODIFIED DESC是为了让最近修改的文件排前面这是文件管理器最常用的排序参数和桌面端文件列表的习惯一致。3. 从 .rar 到可读工程jadx、apktool 与资源还原的完整链路3.1 先验包怎么判断手里是 smali 还是可编译 Java 工程拿到 .rar 先解压然后 cd 进去看目录结构。如果顶层有app/src/main/java这样的路径说明是 Android Studio 工程如果看到一堆以 smali 命名的目录里面全是 .smali 文件那就是反编译产物如果只有 classes.dex 加 AndroidManifest.xml那连反编译都还没做。先跑一条 find 确认find . -maxdepth 4 -type d \( -name smali* -o -name java -o -name kotlin \) | head -20这一步决定了整个工作流的方向。smali 目录说明需要先用 jadx 还原 Java 再人工阅读有 java 目录说明可以直接导入 Android Studio只有 manifest 和 dex 的需要自己补完整的 Gradle 工程骨架。3.2 用 jadx 把 DEX 还原成可读 Java 的最小命令如果是 APK 或 dex 形态jadx 是还原度最高的选择能把混淆前的方法调用关系、资源引用恢复得比较完整# 把整个 APK 反编译成可读 Java 工程 jadx -d output_src -j 8 mi_file_manager.apk # 只反编译指定类适合快速定位 jadx --show-bad-code -d output_src -c com.android.filemanager.MainActivity-d指定输出目录-j 8是并行线程数机器内存小就降到 4--show-bad-code让 jadx 在无法完整还原的方法体里输出近似代码而不是留一具空壳。反编译完成后源码里经常出现形如String str;的占位变量名这是混淆开启且变量表被移除的结果阅读时要结合调用上下文去猜语义。这时候不要急着逐行读先全局搜onCreate、onResume入口方法把主流程串起来。提示jadx 输出的工程里夹杂大量反编译噪声先跑一遍编译让 IDE 的标红过滤出能编译与不能编译的类效率远高于人肉逐行排查。3.3 用 apktool 解码资源和 AndroidManifest找回包结构与权限申请jadx 负责 Java 代码apktool 负责资源和 manifest。很多关键信息——申请的权限、FileProvider 的 authority、targetSdkVersion——都藏在解码后的 AndroidManifest.xml 里# 解包 APK得到 smali 目录、未编码的 manifest 和 res 目录 apktool d mi_file_manager.apk -o apk_decode # 重打包改完 smali 或资源后 apktool b apk_decode -o repack.apk解码后立即查看apk_decode/AndroidManifest.xml里的uses-permission和application节点。文件管理器源码通常会申请READ_EXTERNAL_STORAGE、WRITE_EXTERNAL_STORAGE、MANAGE_EXTERNAL_STORAGE以及一组provider节点用于 FileProvider。注意 apktool 解出来的 manifest 是可读明文 XML如果你只是想知道它申请了哪些权限这一步比 jadx 更快。3.4 在 Android Studio 重建可编译工程的三个必调参数把反编译产物变成能一键运行的工程是工作量最大的环节。常见做法是新建一个空 Android 工程把 jadx 输出的 java 目录拷进 app/src/main/java把 apktool 解出的 res 拷进 app/src/main/res然后改三个地方// app/build.gradle 里的三个关键参数 android { compileSdk 34 defaultConfig { applicationId com.android.filemanager // 与原包一致避免 FileProvider 冲突 minSdk 21 targetSdk 29 // 先降到 29绕过分区存储跑通了再升 versionCode 1 } compileOptions { sourceCompatibility JavaVersion.VERSION_1_8 targetCompatibility JavaVersion.VERSION_1_8 } }三个参数各有讲究。applicationId必须和原包名一致否则 ContentProvider 的 authority 和桌面快捷方式都会错位targetSdk先设 29 不是因为安全而是 30 之后分区存储强制生效源码里那套 File 路径递归在 30 以上必然崩溃先跑通核心逻辑再回来适配compileSdk使用本机 Android SDK 里最新的稳定版即可不要低于源码里的 targetSdk。改完这三处再把缺失的依赖一般是 androidx.appcompat、material、glide补进 dependencies理论上就能编译了。实际编译报错集中在资源引用和隐藏 API 调用两处前者去 res 目录里找缺失的 drawable后者要删除或替换对非公开 API 的反射调用。4. 源码核心模块拆解文件列表、复制传输与分类页的实现参数4.1 文件列表的双层结构目录枚举与排序参数文件管理器的核心是列表页源码里通常拆成两层数据层用ListFileInfo持有文件元数据UI 层用 RecyclerView 的 Adapter 渲染。FileInfo 一般只有几个字段name、path、size、isDirectory、modifiedTime、mimeType。目录枚举的关键在排序和过滤private ListFileInfo listFiles(File dir, boolean showHidden) { File[] files dir.listFiles(); if (files null) return new ArrayList(); ListFileInfo result new ArrayList(); for (File f : files) { if (!showHidden f.isHidden()) continue; // 隐藏文件过滤 String name f.getName().toLowerCase(); if (name.endsWith(.db) || name.endsWith(.nomedia)) continue; // 系统文件过滤 FileInfo info new FileInfo(); info.setPath(f.getAbsolutePath()); info.setName(f.getName()); info.setDirectory(f.isDirectory()); info.setSize(f.isDirectory() ? -1 : f.length()); info.setModifiedTime(f.lastModified()); result.add(info); } // 目录在前目录和文件各自按名称排序 result.sort((a, b) - { if (a.isDirectory() ! b.isDirectory()) return a.isDirectory() ? -1 : 1; return a.getName().compareToIgnoreCase(b.getName()); }); return result; }注意listFiles()返回 null 有两种情况一是目录不存在二是无权限访问。如果源码里没有判空一进文件夹就白屏这是反编译源码最常见的隐藏 bug 之一。过滤.nomedia是因为多媒体扫描会跳过这些目录文件管理器如果显示了反而和系统相册表现不一致。排序用compareToIgnoreCase避免大小写敏感导致中文文件名排到最后。实际使用中排序参数经常要调文件管理器都有名称/时间/大小/类型四种排序切换到时间排序时把比较器换成基于modifiedTime即可。4.2 复制与移动进度回调拆成可取消的循环复制文件是文件管理器里最容易写得又慢又难用的部分。简单写法是流循环读再写但缺了进度和取消。源码里一个常见做法是把复制动作封装成 Runnable用回调接口上报进度public interface TransferCallback { void onProgress(int percent, String currentFile); boolean isCancelled(); void onFinished(boolean success, long totalBytes); } public void copyFile(File src, File dst, TransferCallback cb) throws IOException { byte[] buffer new byte[512 * 1024]; // 512KB 缓冲区 try (InputStream in new FileInputStream(src); OutputStream out new FileOutputStream(dst)) { long total src.length(); long copied 0; int len; while ((len in.read(buffer)) ! -1) { if (cb.isCancelled()) { out.flush(); dst.delete(); // 取消时清理半成品文件 throw new IOException(user cancelled); } out.write(buffer, 0, len); copied len; cb.onProgress((int) (copied * 100 / total), src.getName()); } } }缓冲区大小直接决定传输速度与进度粒度。512KB 在绝大多数 Android 设备上是吞吐和内存的平衡点1MB 以上在低端机上会因为 GC 抖动导致速度反倒下降缓冲区过小比如 8KB则会让小文件拷贝慢得离谱。取消不是简单 break而是要做到取消时把已创建的半成品删掉否则目录里会残留一个不完整文件。onProgress回调不要在子线程里直接更新 UI源码里一般通过 Handler 或 LiveData 转发到主线程否则会崩在CalledFromWrongThreadException。移动文件同目录下就是 Java 的File.renameTo跨目录则要先复制后删除。4.3 分类页MIME 类型与 MediaStore 查询条件的映射小米文件管理器的图片/视频/音频/文档四个分类页本质是四组不同的 MediaStore 查询条件。文档分类比媒体分类复杂因为文档没有独立集合只能靠 MIME 类型过滤private void queryDocuments(ContentResolver resolver) { Uri collection MediaStore.Files.getContentUri(MediaStore.VOLUME_EXTERNAL_PRIMARY); String selection MediaStore.Files.FileColumns.MIME_TYPE IN (?, ?, ?, ?); String[] selectionArgs {text/plain, application/pdf, application/msword, application/vnd.openxmlformats-officedocument.wordprocessingml.document}; String[] projection {MediaStore.Files.FileColumns._ID, MediaStore.Files.FileColumns.DISPLAY_NAME, MediaStore.Files.FileColumns.SIZE, MediaStore.Files.FileColumns.DATE_MODIFIED}; try (Cursor cursor resolver.query(collection, projection, selection, selectionArgs, MediaStore.Files.FileColumns.DATE_MODIFIED DESC)) { while (cursor.moveToNext()) { long id cursor.getLong(cursor.getColumnIndexOrThrow(MediaStore.Files.FileColumns._ID)); Uri fileUri ContentUris.withAppendedId(collection, id); // 用 fileUri 读取或分享该文档 } } }MediaStore.Files是所有文件的统一集合用 MIME_TYPE 过滤出任意类型。MIME 映射表要单独维护APK 是application/vnd.android.package-archive压缩包是application/x-zip-compressed和application/x-rar-compressed表格是application/vnd.ms-excel。这个映射表在源码里通常是一个HashMapString, Stringkey 是扩展名value 是 MIME。改分类页展示时只需要在这个表里增删条目不需要动查询逻辑。5. 源码踩坑实录混淆定位、FileProvider 冲突与 Android 11 分区存储5.1 混淆后的类名定位从崩溃堆栈倒推源码反编译源码最常见的问题是类名和方法名已经变成 a、b、c 这种短名崩溃日志里也是这些短名。定位方式不是去源码里搜完整类名而是用映射表。如果 APK 发布时附带 mapping.txt通常是和 APK 一起发布的那份先把它跑一遍 Retrace 工具如果没有映射表就靠入口方法和布局反查。常见做法是先打开res/layout/main.xml找到界面结构然后通过findViewById的调用点反推业务类比大海捞针快得多。5.2 FileProvider authority 冲突为什么 content:// 分享会闪退文件管理器几乎必然有分享文件功能实现方式是 FileProvider。反编译源码里 FileProvider 的 authority 往往写死比如com.android.filemanager.fileprovider。如果改包名时没同步改AndroidManifest.xml中provider的authorities和res/xml/file_paths.xml运行时一调FileProvider.getUriForFile就抛IllegalArgumentException: Couldnt find meta-data for provider。检查点是两处保持一致!-- AndroidManifest.xml 中的声明 -- provider android:nameandroidx.core.content.FileProvider android:authorities${applicationId}.fileprovider android:exportedfalse android:grantUriPermissionstrue meta-data android:nameandroid.support.FILE_PROVIDER_PATHS android:resourcexml/file_paths / /providerauthorities写成${applicationId}.fileprovider是 Android Studio 模板的推荐做法而反编译源码里往往是硬编码。用 Gradle 改applicationId时 Placeholder 会自动替换硬编码不会这就是改包名后分享功能必崩的原因。另外注意file_paths.xml里若保留了root-path对应整个文件系统即使自己有全部文件权限也拿不到/Android/data/下的访问权那是系统限制和 authority 无关。此前网上流传的各种content://...fileprovider/external_path/android/data/...直链在 Android 11 之后用浏览器或文件管理器打开基本都返回空目录或报错根源就是分区存储规则不是链接本身写错。5.3 Android 11 之后 /Android/data 不可读的适配方案这是文件管理器源码适配里绕不开的问题。Android 11 起普通应用即使申请了MANAGE_EXTERNAL_STORAGE也无法通过路径访问/Android/data和/Android/obb。很多从 Android 10 移植来的源码在这里直接失效。常见适配策略是分层处理对/Android/data引导用户在系统文件管理器中手动操作自己的 App 不展示该目录对应用自身的数据用context.getExternalFilesDir()拿到应用专属路径展示对用户选择的任意目录用ACTION_OPEN_DOCUMENT_TREE让用户授权后以DocumentFile.fromTreeUri访问并调用takePersistableUriPermission持久化授权避免每次重启都要重新选目录。注意不要试图用反射绕过 /Android/data 的限制Android 13 以上系统服务层直接拦截投入产出比极低老老实实按 SAF 授权路径走。5.4 反编译源码再打包的三个验证点反编译又重打包的 APK容易出现三个问题签名不对、资源引用错位、权限声明丢失。验证命令如下# 检查 APK 的包名、版本、权限与 targetSdk aapt dump badging app-debug.apk | grep -E package|uses-permission|targetSdk # 查看签名信息是否完整 apksigner verify --print-certs app-debug.apk # 用 zipalign 对齐后再签名避免运行时资源读取异常 zipalign -v 4 app-debug.apk aligned.apk apksigner sign --ks my.keystore --ks-pass pass:123456 --out signed.apk aligned.apkaapt dump badging是最快的验证手段一行输出就能确认包名、targetSdk 和权限有没有丢。zipalign对齐是 Google Play 的硬性要求未对齐的 APK 在部分机型上会出现资源读取段错误反编译工程尤其容易漏这一步。签名用 debug keystore 即可自测但注意同一台设备上不能同时安装 debug 签名和 release 签名的同包名应用卸载重装是常见操作。6. 把这份源码改造成最小可用工程自校验与产物核验6.1 最小裁剪边界只保留四个页面拿到一份反编译源码不要试图全量理解。先做最小可跑裁剪保留首页文件列表、分类页图片/视频/音频/文档、搜索入口和分享动作其余如云盘、回收站、清理加速全部注释掉。裁剪标准是——凡是入口在主页 Tab 上、切换后需要独立权限的模块全部从MainActivity里摘除。这样编译时间从几分钟降到几十秒调试定位范围也缩小到几条主线。6.2 用 adb 脚本做存储行为冒烟测试改造完成后用 adb 脚本做冒烟测试比手动点界面高效得多# 安装并授予文件访问权限 adb install -r app-debug.apk adb shell pm grant com.myfilemanager android.permission.READ_EXTERNAL_STORAGE # 启动主界面并 dump 当前 Activity确认没有闪退 adb shell am start -n com.myfilemanager/.MainActivity sleep 2 adb shell dumpsys activity top | grep ACTIVITY # 触发随机事件观察崩溃日志 adb shell monkey -p com.myfilemanager --pct-syskeys 0 --throttle 300 200 adb logcat -d -s AndroidRuntime:E | tail -30pm grant只能授予普通权限MANAGE_EXTERNAL_STORAGE这类特殊权限必须通过系统设置页手动授予脚本无法直接完成这是测试时容易误判的一环。monkey随机事件配合logcat -s AndroidRuntime:E过滤能在十分钟内暴露大部分空指针和越界问题。最后用apksigner verify确认签名合格再确认 logcat 里没有指向/Android/data的FileNotFoundException然后把targetSdk从 29 升到 30 重新过一遍冒烟脚本一套能自用的文件管理器工程就算交付了。本文还有配套的精品资源点击获取
