AntiSplit-M项目中的只读文件系统问题分析与解决方案

问题背景

在Android开发领域，处理APK文件合并时经常会遇到文件系统权限问题。近期在AntiSplit-M项目中，用户报告了一个典型的"Read-only file system"错误，这个问题在LineageOS 21(Android 14)系统上尤为明显，特别是在处理从APKMirror下载的分割APK文件时。

问题现象

当用户尝试使用AntiSplit-M合并Twitter等应用的APK文件时，应用程序会抛出以下两种异常之一：

1. java.nio.file.FileSystemException：提示目标文件系统为只读
2. java.io.FileNotFoundException：同样指出EROFS(只读文件系统)错误

从日志中可以清楚地看到，应用程序在尝试写入合并后的APK文件时遇到了权限问题，特别是在/document/primary:Download/路径下。

技术分析

根本原因

这个问题源于Android的存储访问框架(SAF)和Scoped Storage限制。自Android 10以来，Google引入了更严格的存储访问策略：

1. 作用域存储：应用只能访问自己创建的或用户明确授予访问权限的文件
2. 外部存储限制：即使拥有权限，某些目录也可能被标记为只读
3. 缓存目录差异：内部缓存和外部缓存的权限模型不同

在AntiSplit-M的案例中，应用程序最初尝试使用外部缓存目录进行临时文件操作，这在某些定制ROM(如LineageOS)上可能被配置为只读模式。

解决方案演进

开发者通过多次迭代找到了有效的解决方案：

1. 初始尝试：调整文件操作API，从java.nio.file切换到传统的java.io，但问题依旧
2. 版本回退：测试旧版应用，确认不是新引入的变更导致的问题
3. 最终方案：将临时文件操作从外部缓存目录迁移到内部缓存目录

技术实现细节

内部缓存目录(Context.getCacheDir())相比外部缓存目录有几个优势：

1. 无需额外权限：应用自动拥有完全访问权限
2. 更稳定的访问：不受外部存储挂载状态影响
3. 更好的兼容性：在所有Android版本和设备上行为一致

修改后的实现确保了文件操作在受控环境中进行，避开了系统级的存储限制。

开发者建议

对于类似的文件系统权限问题，建议采取以下策略：

1. 优先使用内部存储：对于临时文件操作，首选内部缓存目录
2. 正确处理异常：捕获并妥善处理可能出现的权限异常
3. 兼容性测试：在不同Android版本和定制ROM上进行充分测试
4. 清晰的用户指引：当需要外部存储访问时，提供明确的权限请求说明

总结

AntiSplit-M项目中的这个案例展示了Android存储权限模型的复杂性，特别是在分裂APK处理这种需要大量文件操作的场景下。通过将临时文件存储位置从外部缓存迁移到内部缓存，开发者成功解决了只读文件系统的问题，这一解决方案不仅提高了应用的稳定性，也增强了在不同Android设备和ROM上的兼容性。

这个案例也为其他Android开发者提供了宝贵的经验：在设计和实现文件操作逻辑时，必须充分考虑Android不断演进的存储权限模型，选择最合适的存储策略来确保应用的可靠运行。