为什么Android中无法通过File对象还原得到原有DocumentFile对象

问题成因 #

1. 错误的File对象构造逻辑 #

File类构造函数仅接受本地文件系统纯路径字符串，而DocumentFile.getUri()返回的是带协议前缀的Uri：

• 绝大多数场景下该Uri是SAF（存储访问框架）提供的content://协议地址，toString()结果类似content://com.android.externalstorage.documents/tree/primary%3AMyFolder，并非本地路径，直接传入File构造函数会得到指向完全不存在路径的无效fFoo对象
• 即便少数场景下Uri为file://协议，toString()结果也会携带file://前缀，无法被File正确识别，必须调用Uri.getPath()取纯路径部分才能构造有效File

2. 分区存储权限限制 #

就算你通过Uri解析拿到了正确的本地路径，Android 10及以上版本的分区存储规则也会拦截直接File API访问：

• 原始dfFolderFoo是通过SAF用户授权生成的实例，持有对应目录的合法访问权限，因此listFiles()可以正常返回文件列表
• 通过DocumentFile.fromFile()生成的新实例底层走原生File API权限校验，App未获得该目录的直接文件访问权限，就算路径正确，listFiles()也会返回空

3. DocumentFile两类实现的底层差异 #

DocumentFile存在两类完全独立的实现，逻辑不互通：

• 从SAF content:// Uri生成的是TreeDocumentFile实例，底层通过ContentProvider调用系统SAF接口访问文件，走Uri授权校验逻辑
• 从File生成的是RawDocumentFile实例，底层直接调用Java File API，走文件系统权限校验逻辑
  你这种强制跨类型转换的用法本身就不符合DocumentFile的设计规范，不可能得到和原实例一致的结果。

内容的提问来源于stack exchange，提问作者Hong