Android使用SAF存取云存储文件跨设备修改不同步问题咨询

关于是否是SAF固有机制 #

这个问题不是Storage Access Framework本身的设计导致的。SAF只是一套系统级的文件访问抽象层，实际的文件读写、云端同步逻辑完全由对应云存储服务实现的DocumentsProvider模块决定。

• Google Drive、Dropbox目前自带的SAF Provider实现都没有做跨设备的实时版本校验与同步：当你在另一台设备打开之前创建的文件时，Provider默认读取本地缓存的旧副本，写入时不会主动拉取云端最新版本做冲突检测，直接将本地修改作为新版本上传，最终导致两端看不到对方的修改。
• Dropbox客户端能展示多版本是因为它本身的版本管理机制，本质上还是生成了副本；Google Drive的Provider直接覆盖了本地缓存对应的云端节点，但没有同步到其他设备的本地缓存，才会出现网页端能看到修改、其他设备看不到的情况。
• 目前主流消费级云存储的SAF实现都存在同类问题，包括OneDrive在内的服务商都没有做跨设备的SAF文件实时同步适配，不存在能完美规避这个问题的通用云服务商。

关于是否必须对接私有云API #

不需要单独集成Google Drive这类服务的私有API，这种方案会直接丧失SAF的跨云存储兼容性，完全有更通用的解决方案，核心是修正你现有SAF使用逻辑的几个误区。 #

你的实现存在三个直接触发不同步的错误：

1. 没有申请Uri的持久化读写权限，仅持有onActivityResult返回的临时权限，应用重启、设备重启后权限失效，后续访问的是云盘本地缓存的旧文件副本，不是云端最新实体。
2. 读写操作前没有触发Provider同步云端状态，直接复用内存中缓存的Uri操作，云盘Provider不会主动拉取云端最新版本，也不会在写入后立刻触发上传。
3. 写入时仅用"w"模式打开文件，写入完成后没有强制刷盘、也没有通知系统文件变更，云盘Provider无法及时捕获文件修改触发同步。

这套方案兼容所有支持SAF的云存储服务，不需要对接任何私有SDK：

1. 持久化Uri与对应权限 #

拿到Uri后第一时间申请持久化读写权限，同时将Uri持久化到本地存储，不要只存在内存变量中：

// 建议把持久化的Uri存在SharedPreferences中，应用重启后直接读取解析
private val sp by lazy { getSharedPreferences("saf_config", Context.MODE_PRIVATE) }
private var uri: Uri?
    get() = sp.getString("target_uri", null)?.let { Uri.parse(it) }
    set(value) = sp.edit().putString("target_uri", value?.toString()).apply()

override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) {
    if (resultCode != RESULT_OK) return
    val targetUri = data?.data ?: return
    val takeFlags = data.flags and (Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_GRANT_WRITE_URI_PERMISSION)
    // 申请持久化权限，权限会跨重启保留
    contentResolver.takePersistableUriPermission(targetUri, takeFlags)
    
    uri = targetUri
    when(requestCode) {
        SAVE -> write()
        OPEN -> read()
    }
}

2. 读写前主动触发云端同步 #

每次读写前先查询文件元数据，强制触发Provider拉取云端最新状态，写入完成后主动通知系统触发云盘上传：

// 触发同步并返回云端最新修改时间
fun getFileLastModified(uri: Uri): Long {
    var lastMod = 0L
    contentResolver.query(
        uri,
        arrayOf(DocumentsContract.Document.COLUMN_LAST_MODIFIED),
        null, null, null
    )?.use { cursor ->
        if (cursor.moveToFirst()) {
            lastMod = cursor.getLong(0)
        }
    }
    return lastMod
}

fun write() {
    val targetUri = uri ?: return
    // 先拉取云端最新元数据
    val remoteLastMod = getFileLastModified(targetUri)
    val localLastMod = sp.getLong("last_modified", 0L)
    // 可选：如果remoteLastMod > localLastMod，提示用户文件已在其他设备修改，确认是否覆盖
    // 用rw模式打开，避免部分Provider的w模式直接创建新副本
    contentResolver.openFileDescriptor(targetUri, "rw")?.use { pfd ->
        FileOutputStream(pfd.fileDescriptor).use { fos ->
            fos.channel.truncate(0)
            fos.write(string_to_save.toByteArray())
            fos.fd.sync() // 强制将修改刷入存储，确保Provider能捕获变更
        }
    }
    // 通知系统文件已变更，触发云盘上传
    contentResolver.notifyChange(targetUri, null)
    // 更新本地记录的修改时间
    sp.edit().putLong("last_modified", System.currentTimeMillis()).apply()
}

fun read() {
    val targetUri = uri ?: return
    // 触发同步拉取最新版本
    getFileLastModified(targetUri)
    contentResolver.openInputStream(targetUri)?.use { ins ->
        BufferedReader(InputStreamReader(ins)).use { reader ->
            // 用readText替代readLine，避免内容包含换行时读取不全
            string_from_file = reader.readText()
        }
    }
    sp.edit().putLong("last_modified", getFileLastModified(targetUri)).apply()
}

3. 异常兜底 #

如果操作时抛出SecurityException，说明对应云盘的持久化权限已经失效，引导用户重新通过ACTION_OPEN_DOCUMENT选择目标文件即可，不需要额外的适配逻辑。 #

这套方案可以解决绝大多数SAF云存储的跨设备不同步、生成副本问题，同时保持对所有支持SAF的存储服务的兼容性。如果需要100%无感知的实时冲突合并、多端同步，确实需要对接对应云服务的私有API，但对于普通的跨设备编辑同文件的需求，这套方案的覆盖度已经足够。

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