DataBackup v3.15.0

新增：批量打标签

以前给应用加标签，只能一个个点进详情页。二十个应用就要点二十次。

现在列表里勾选多个应用，右上角「对已选中」可以一次性加上已有标签、新建标签并直接打上、或者批量移除。打的是你勾选的全部应用，跟列表当前筛没筛出无关。

新增：列表直接看版本号

同一款应用装了不同版本，或者同名的两个包，光看名字和包名分不出谁是谁。

筛选面板里加了两个开关：显示包名、显示版本号。包名默认开、版本号默认关，打开后列表副标题会变成 com.databackup.version · 3.15.0 (3615124)，不点进详情页也知道装的是哪一版。

新增：详情页分开显示版本号和版本码

原来只有一行「版本 5.5」。现在拆成两行：「版本号 5.5」是厂商写在包里的版本字符串，「版本码 55」是系统和商店用来比较大小的整数。查同名不同构建、确认升级有没有生效时，后者更有用。

新增：备份到 FAT32 卡时提前拦住

有人把备份目录放在 FAT32 的 SD 卡上，微信 8 GB 的数据写到 4 GiB 就被截断，白等三分钟，最后归档还被判损坏删掉，那一次微信的聊天记录根本没备上。

现在备份前先看目标分区是什么格式、数据大概多大，装不下就直接跳过并说明原因，不用等它写到一半才失败。同时把失败时的提示从「归档损坏」改成能看懂的原因。

修复：批量打标签漏掉被筛掉的应用

勾了 5 个应用，又按标签筛了一下只剩 3 个可见，这时点「添加标签」只给这 3 个打了标签，另外 2 个悄悄漏掉，界面上还显示着 5/37。

现在按你勾选的全部应用来打，和顶部计数一致。

修复：打完标签列表不刷新

打完标签得手动把筛选切一下才看得到更新，否则还是旧的 3 个。原因是列表只盯着「筛选项变没变」，没盯着标签关联本身。

修复：标签多到二十来个时，筛选面板滚不动

标签把面板撑得比屏幕还高，排序和单选项全被挤出可视区，而且面板不能滚——想要的标签点不到，排序也换不了。

现在整个面板可以滚动，打开就是全高。文件列表的筛选只有两个选项，仍旧是半高卡片，不会被拉成一整屏。

其他

• 删标签前会先确认，并说清楚这个标签在应用和文件上是同一个，删了就都没了。
• 删标签时顺带清掉应用和文件的关联记录，不再留孤儿。
• 排序方式和升降序会记住，杀进程重启后保持，不用每次进来重设。
• 备份完成得比倒计时快时，「屏幕将在3秒后关闭」不会再一直挂在完成页上。
• 没开自动息屏的话，上一次任务残留的倒计时值不会再让这一次莫名息屏。

---

版本号：3.15.0（versionCode 3615124）

DataBackup v3.14.0

新增：增量备份

以前每次备份都要把所有内容重新压一遍，哪怕上次备份之后什么都没改。微信这种几万个小文件的目录，压一次 CPU 占满、机身发烫。

现在备份前先比对源目录清单，没变就跳过不打了，只有改动过的类型重打，其余从上一版归档里继承。判断依据包含压缩等级、排除项等设置，改过就回到全量；目录读不全也一律按已变化处理，不会漏东西。云端仍旧全量，因为云端是先写暂存再上传，跳过会把上传一起跳掉。

新增：备份备注

同一个应用常有好几份备份：干净的初始版、配置好的日常版、还有几个保护版本。名字图标都一样，时间一长分不清哪份是哪份。

现在每份备份都能单独写一句说明，列表中直接显示。备注按版本存，主版本、保护版本、本地版、云端版各写各的，改一个不影响别的。搜索框也认备注。

修复：点一下「重载」，云端备份列表就空了

重载会先删掉旧版扫描写错包名留下的脏记录，但删完不重建。重建交给后台扫描任务，而那个任务只要失败或取消过一次，名字就被长期占着，后续请求全被静默忽略。

现在删完立刻写回数据库。实测重载一次，云端 9 条记录全都回来（修复前会变成 0 条）。

修复：有四种数据恢复时不会被勾上

标记「哪些类型能恢复」的代码，把结果写进了一个马上就丢掉的临时对象，赋值从来没生效过。表现是远端明明有归档却不勾选，没注意的话恢复出来就少了东西。

修的是两处共 8 行。

其他

• 某类数据被清空后会从主备份里消失（比如 OBB 被卸载），现在会保留上一份归档。
• 从保护版本继承归档失败时会残留半套文件，现在会清掉。
• 备份前的目录扫描从两遍合成一遍。
• 改了两处会误导人的注释（其中一处说硬链接零拷贝，实际上 Android 的 /sdcard 是 FUSE，根本不支持硬链接）。

---

新增两个功能、修了四个问题，直接覆盖安装即可。

文件：DataBackup-3.14.0-arm64-v8a-alpha-release.apk、DataBackupFTPServer-v2.5.exe。

DataBackup v3.13.4

上一版只挡了 .trashed-，漏了同一条规则里的 .pending-。

AOSP 的判定只有一条正则，同时管「已删除」和「写入中」两种状态，大小写还不敏感：

(?i)^\.(pending|trashed)-(\d+)-([^/]+)$

现在判据收敛到一处（PathUtil.TrashedFilePatterns），应用媒体、文件媒体、备份、恢复四处统一引用。

另外日志以前只报匹配模式、看不出到底跳了什么 —— 一个相册目录实测有几百个。现在会列出具体文件名（前 5 个 + 总数）。

两侧均已实机验证。

文件：DataBackup-3.13.4-arm64-v8a-alpha-release.apk、DataBackupFTPServer-v2.5.exe。

DataBackup v3.13.3

这次修的是 OPPO（ColorOS） 上反馈的一个问题：恢复相册备份之后，打开系统相册，照片全都不见了。

查下来，删照片这件事和直觉不一样。ColorOS（以及 Android 11 之后的所有系统）删除媒体文件时，不把文件搬走，而是原地改个名字 —— 在原名前面加上 .trashed-<到期时间戳>-，文件本身还留在原来的目录里。相册看不到它，是因为系统媒体库（MediaStore）里对应那条记录被标成了「已删除」；等 30 天到期，系统才会真正把文件清掉。

问题就出在这里：那些"已删除"的文件还躺在 DCIM、Pictures 里，备份时自然被一起打进了归档。恢复回来之后系统再扫一遍，看到 .trashed- 这个名字，又把它们判成"已删除" —— 相册不显示，30 天后被清得一干二净。用户看到的就是「恢复完照片全没了」，其实那一瞬间照片还在磁盘上。

现在备份和恢复两侧都会跳过这类文件：备份不再收它们，恢复旧归档时也不会把它们放出来。顺带的好处是备份体积也会小一点。

有一点要说明：这个机制不是 OPPO 独有的 —— 小米、三星等 Android 11 以上的机型同样如此，只是这次反馈来自 ColorOS。所以这个修复对所有设备都适用。

顺带两个小提示：

1. 如果你之前恢复出来的照片"消失"了，看看文件名是不是 .trashed-数字- 开头 —— 是的话，把前缀去掉、让相册重新扫一遍就能看见
2. 如果恢复后发现照片变少，检查「设置 → 干净恢复」是否开着 —— 它会在解压前先清空目标目录

文件：DataBackup-3.13.3-arm64-v8a-alpha-release.apk（15,352,684 字节）、DataBackupFTPServer-v2.5.exe。

DataBackup v3.13.2

这次修的是云端的几个问题，其中两个叠在一起，表现成「明明有备份、却什么也看不到」。

云端「文件」列表一直是空的：加载文件备份时，函数收到了云账号却把它丢在一边、固定传了个空值，而下游正是靠这个参数区分「扫云端」还是「扫本地」—— 传空就永远只扫本地，云端那几项从来没进过数据库，所以恢复页的「文件」怎么刷新都是空白、搜也搜不到。同一个文件里，应用备份那份的加载传参是正确的，两行并排一对比就能看出来。

勾选之后点「继续」，预处理页仍然显示 0.00 Bytes：这一页进页面时先按当前来源统计、之后才去确定来源，统计那一步来源还是空的，于是按本地查了一遍，结果当然是 0。应用侧同一处写的是「先确定来源、再统计」，把文件侧的顺序对齐就好了。修好后同一套流程在平板上实测：列表能列出来、勾上、点继续显示 57.60 MB，和外面那个数字对得上。

另外两处顺带修的：

备份时如果目录里有个读不到的条目（比如某些机型相机建的隐藏目录 .tmfs，连 root 都没权限），以前整个任务会被判失败 —— 哪怕数据已经完整写入、归档校验也通过了。现在这类情况不再误报，归档真损坏时校验仍会失败。

系统数据的「从云端恢复」，在你还没把这项传到云端时，以前点了才失败、而且分不清是「云端没有」还是「网络出错」。现在选账号的面板里不存在的账号会置灰并写明原因；连不上则保持可选（那只是没问到，不代表没有）。

还有个小改动：压缩等级与压缩线程数的说明各加了一句「关闭只是折叠此项，仍生效，默认 1 / 2」，免得被读成「关掉就不用了」，同时去掉了「压缩线程数」里那句「（如 2）」。19 个语言同步。

文件：DataBackup-3.13.2-arm64-v8a-alpha-release.apk（15,352,192 字节）、DataBackupFTPServer-v2.5.exe。

DataBackup v3.13.1

这次更新是「重载」（恢复页 → 高级 → 重载）的收尾清理，三处问题都来自真机实测。

重载以前会把 .md5 校验文件也当成备份归档去解析：walkFileTree 返回的每个文件都会进一次分支判断，而 xxx.tar.zst.md5 的扩展名被解析成 tar.zst.md5、取不到压缩类型，于是每种类型都白打一行 Dumping xxx... 和一行 Failed to parse compression type；分类阶段同样逐文件打印一行。用一台装了 9 个应用（13.96 GB）的平板实测，日志从 445 行降到 274 行，Failed to parse 由 36 行归零，Total paths count 也从 83（含水印文件）变成 46（只算真实归档）。

重载中途出错会卡在加载中：isLoading 置真之后没有兜底，执行体一抛异常就再也回不到可用状态。现在用 try/finally 收口，异常也会正常结束。

重载页的「版本」在中文界面下显示的是硬编码英文 current，是全项目唯一的英文孤例；已改为资源字符串，跟随语言显示（当前版本 / 目前版本 / Current）。

此外顺手补了压缩等级与压缩线程数的说明：这两项改成折叠开关之后，关掉开关只是把设置折叠起来、并不会停用它（等级默认 1、线程数默认 2），描述里写清楚了；「压缩线程数」里那句「（如 2）」也去掉了。19 个语言同步。

顺带一条实测结论：只想让列表认出你新拷进来的备份、不需要刷新图标和版本号时，先把「解析安装包」关掉再点重载 —— 同一个平板、同一批备份，实测 4.01 秒降到 0.18 秒。

文件：DataBackup-3.13.1-arm64-v8a-alpha-release.apk（15,350,324 字节）、DataBackupFTPServer-v2.5.exe。

DataBackup v3.13.0

新增：云端备份分卷上传

部分网盘（WebDAV 等）有单文件大小限制，超限时上传会失败。新增 设置 → 备份设置 → 云端分卷大小（可选 关闭 / 1 GB / 2 GB / 4 GB，默认关闭）：开启后，云端上传的归档超过设定值时会切成若干分卷逐卷上传，用于绕开单文件限制；恢复或导入时按顺序下载并自动合并，校验用的 .md5 仍是整档的值，与不分卷时完全一致。

本地备份不受影响 —— 本地始终是一个完整文件。目前覆盖应用备份、文件备份、一键迁移导出三条云端上传路径。

新增：归档过大提醒

云端归档超过 10 GB 且没开分卷时，会在任务日志里提示一次（同一次任务只提示一次），并带上实际大小，方便判断要不要开分卷。

新增：应用内「更新日志」

主页顶栏的版本号徽章、设置 → 关于 → 更新日志 都能打开更新日志页，直接看当前版本与历史版本改了什么。随包离线可看，不再需要跳浏览器。

优化

• 澎湃系统默认关闭「恢复权限」：HyperOS 上这个开关不是"还原备份时的授权状态"，而是恢复时强制授予全部权限；现在默认关掉、交给系统自己恢复。手动改过的话以你的设置为准。
• 备份设置排版：「云端分卷大小」移到「杀死应用选项」下方；「压缩等级」「压缩线程数」改为开关 + 可折叠（默认展开，行为与之前一致）。

修复

• 恢复分卷备份时应用数据被跳过：恢复侧的存在性判断只看整档，而分卷上传后云端只有 part.*，会被当成"缺失"直接跳过；现统一为「整档存在 或 有分卷即为存在」。
• 分卷合并写出损坏文件：合并原本走 sh -c "cat … > …"，App 的 shell 包装会在命令尾部追加哨兵串并被 > 重定向进目标文件（实测 1.73 GB 合并成 121 字节）；改为流式拼接 + 长度自校验。

---

配套工具 DataBackupFTPServer v2.5 本次无改动，一并附上。

DataBackup v3.12.1

修复：应用装得多时，扫描列表会卡

有用户反馈设备上应用装得多了，进备份页扫描时会卡住。查下来原因不在扫描本身，而在进度通知。

每处理一个应用，程序都会更新一次「正在初始化应用列表」这条前台通知。而系统更新通知的动作只能在主线程做，每次还要跟系统进程来回通信一次。

实测一台装了 47 个第三方应用的设备：扫描全程只用了 145 毫秒，但光是刷新通知就在 0.79 秒里做了 291 次，全部挤在主线程上——通知开销是实际工作量的 5 倍以上。应用数量上百时，主线程会被连续占满，表现就是界面卡死。

现在改成按时间合帧：250 毫秒内最多更新一次通知，开始和结束两条保证发出，进度条照常走。

同一台设备复测：通知更新从 291 次降到 6 次，主线程不再被占满。

修复：后台启动时，恢复页的备份列表可能加载不出来

如果 App 启动后立刻退到后台（比如返回桌面），系统会禁止后台程序弹前台通知。

原来的代码没有处理这个拒绝，异常直接把整个加载任务打断了——恢复页因此看不到已经备份好的应用，看起来就像「备份丢了」。

现在改成：通知发不出去也要把数据加载完。通知只是展示，不该让正事失败。

复测（启动后立即切后台）：加载任务从「失败」变成「成功」，已备份列表正常显示，数据一条不少。

其他优化

顺手清掉了几处「每个应用都要从头算一遍」的重复开销：应用的权限定义、SSAID 读取、数据库序列化，都改成复用缓存。这几项在应用少的时候感觉不明显，应用多时是实打实的累积成本。

---

本次是纯性能与稳定性修复，功能没有变化，直接覆盖安装即可。

版本号：3.12.1（versionCode 3612134）

---

配套工具更新：Windows 端 FTP 服务器 v2.5

手机要把备份传到电脑，得先在电脑上起个 FTP 服务，这个配套工具就是干这个的。这次从 v1.5 直接提到 v2.5，把原来的控制台向导换成了窗口界面，另外修掉了几个容易让人白折腾的问题。

界面这块，账号、密码、端口、备份目录都在窗口里填，点「开启」就跑起来。密码能一键随机生成，也能临时切成明文看一眼；备份目录能浏览选择，选过的会记住。窗口下半部分是给手机端看的连接信息，点「复制全部」直接粘过去就行。

地址选择改成按默认路由排：真实网卡排第一并标「推荐」，其余标成「备用地址（多半是虚拟网卡，手机连不上）」。以前是按系统返回的顺序列，VMware 的虚拟网卡经常排在第一位，用户照着第一个填，怎么都连不上。

顺带修了旧版一个很隐蔽的毛病。旧版把数据连接（PASV）的地址写成列表里的第一个地址，而那个地址常常就是虚拟网卡，于是手机能登录、能看目录，一传文件就失败。现在改成按客户端实际连进来的地址回应。这事我们自己的机器上复现过：修之前手机被指向 VMware 网卡的地址，修之后才是真实网卡的地址。

日志也不再刷英文了。手机点一下「测试连接」，以前日志里是一串 FEAT、USER、TYPE、PASV、Goodbye，现在只留关键几行：

客户端已连接: 192.xxx.xxx.xxx
通信正常: 账号 123 登录成功（来自 192.xxx.xxx.xxx）
上传完成: ...\com.mn.quicknote\user_0\apk.tar.zst（9860890 字节）
客户端已断开: 192.xxx.xxx.xxx

日志同时会写一份到磁盘（%TEMP%\DataBackupFTP\logs，保留最近 5 个），在日志区右键可以复制、另存为、清空。

诊断包也重做了。以前打出来的包只有环境信息和文件清单，用户报问题还是得靠打字描述；现在包里带上运行日志，另外会写清楚：2121 端口上是谁在监听（进程名 + PID）、连上去读到的问候语是不是本工具、防火墙那两条规则还在不在、每张网卡是真实网卡还是虚拟网卡、密码是否为空（只记长度，不写内容）。包里附了一份 README 说明怎么看，一般照着顺序读就能定位。

其他还有：浅色/深色主题可切换并记住；启动后只留一个界面窗口（以前会多弹一个命令行）；账号、密码、目录、主题都存在 %USERPROFILE%\.databackup_ftp_config.json，下次打开自动带出。

用法：下载 exe 双击（第一次会请求管理员权限，用来放行防火墙），填好账号密码和备份目录，点「开启」，手机端 DataBackup 的云备份里照连接卡片填写。bat 脚本版同样已经是界面版，跟 exe 是同一份代码。

文件：DataBackupFTPServer-v2.5.exe（约 14 MB，免安装，双击即用；README 里有更详细的说明）。

DataBackup v3.12.0

新增：系统数据备份（短信 / 通话记录 / WiFi）

主页「快捷操作」里多了一个「系统数据」入口，把以前只能靠第三方工具做的事收进来了：

• 短信（含彩信）、通话记录、WiFi 网络，三项都能 备份 / 恢复。
• 每项都可以选择存到本地（用系统文件管理器挑位置，想放哪放哪），或传到云端（用你已经配置好的云账号，存到远端目录下的 system_data/）。

WiFi 恢复是「重新连接」而不是「覆盖配置文件」 —— 备份出来的是一份含 SSID 与密码的网络清单，恢复时会逐条把网络加回系统并连接。好处是不挑设备：换品牌、换机型也能用（前提是对方系统的 WiFi 命令是标准的 Android 实现）。

WiFi 密码的安全提醒

备份文件里的 WiFi 密码是明文，界面上有明确提示：请妥善保管这份文件，别随手转发。

另外，凡是命令行里会带上 WiFi 密码的操作，一律不写进日志 —— 日志是可以一键导出、提交给开发者分析的，避免密码顺带泄露出去。

恢复前的「结构体检」

恢复数据库是整库覆盖：覆盖过去之后，你这台设备原本的短信 / 通话库就没了。

所以恢复前会先做一次比对 —— 把「本机现在这张库」和「你要恢复的这份备份」的表结构对一遍：

• 完全一致（同机型 / 同品牌）→ 直接恢复，不打扰你。
• 对不上 → 弹窗列出缺了哪些内容，由你决定是否继续。

典型会触发提示的场景是跨品牌恢复：例如一加的库带有 oplus_* / rcs_* 这类厂商私有字段，而小米期望的是 miui_*。库被整份覆盖后，目标机的短信 App 会按它自己的结构去查询，备份里没有的字段就查不到 —— 轻则功能异常，重则数据错乱。同品牌之间通常没有差异，跨品牌建议先看一眼这个提示再决定。

其他

• 设置 → 高级 → 「历史记录」：去掉了前置图标，中文名称由「历史」改为「历史记录」，并补齐了副标题 —— 这一项原本是该区块里唯一没有副标题的，行高和相邻项对不齐。

---

这是常规更新，直接覆盖安装即可，不需要卸载重装。

版本号：3.12.0（versionCode 3612124）

DataBackup v3.11.0

修好的几个烦人问题

• 云端导出报「失败」，其实包已经传完了：包完整上传到云端后，本地临时文件的清理如果失败，导出会被判成失败——你看到「导出失败」就去重试，云端就多出一份重复的包。现在清理失败不再影响导出结果（原因仍写进日志）。

• WebDAV 上传缺一道完整性检查：WebDAV 以前只看服务器返回的 HTTP 状态码，传输中途被截断也算成功，而本地那份临时包随后就被删了——数据只剩云端那个残缺包。现在传完会核对远端文件大小（服务器不报大小的会跳过，避免误判）。

• 上传失败后云端留下半截包：FTP / SFTP / SMB / WebDAV 在传输失败、字节数对不上时，现在会把远端那个不完整的文件删掉，不再让残缺归档留在列表里被选中。

导出到云端

• 成功后提示改为「迁移包已上传到云端」——以前复用本地导出的「迁移包已写入所选位置」，但云端导出并没有"所选位置"。
• 上传进度条不再抖：WebDAV 是按每 256 KB 回调一次，之前每次都刷新界面，十几 G 的包会有几万次刷新。现在和本地导出一样按 300 ms 节流。
• 连点两次「导出到云端」只会启动一次导出，不会重复打包上传。

导出进度更清楚

• 导出过程分成 4 段显示（校验 / 打包 / 校验码 / 上传），打包和算校验码时能看到已写入体积、速度和用时。
• 进导出页不再卡死：备份目录扫描（十几 G、海量小文件）以前跑在主线程，会直接 ANR。
• 屏幕旋转不再中断导出：以前转一下屏，打包和校验码都跑完了，最后一步却失败。

其他改动

• 导出时自动识别旧版本的备份目录命名（纯包名），老备份不再报「目录不存在」。
• 云端成功文案同步 18 种语言。

---

这是常规更新，直接覆盖安装即可，不需要卸载重装。

版本号：3.11.0（versionCode 3611124）