如果要问一个喜欢玩机的 Android 用户：什么最能破坏旧机换新的喜悦气氛，什么又最能让人在恢复出厂设置前犹豫不决？迁移微信聊天记录可能是当之无愧的第一，但还有个差得不远的第二名：重新登录和设置所有应用。
但很多 Android 用户不知道、也很少有机会体验到的是，早在 2015 年，Google 就针对重置、换新场景中的应用重新配置需求推出了自动化的数据备份与恢复功能。
既然如此，为什么国内 Android 用户对此十分陌生甚至毫无感觉？八年后的 2023 年，当我们面对一台全新的 Android 设备时，如何才能少一些重新登录与配置的苦恼？
本文中，我们就从 Android 原生应用备份功能的发展出发，聊聊阻碍这项功能普及的因素，然后介绍曲线救国的技巧。
两代数据备份机制：从存储键值到备份文件
应用数据的备份 API 最初随 Android 2.2 发布，是在 Google 基础服务（如联系人、日历等）的同步模式之上构建的。
但要用上这个功能，第三方应用得完成一套繁文缛节：
- 向系统声明使用备份功能。开发者需要通过应用的属性声明清单（manifest，可以粗略理解为 app 在系统中的「身份档案」）表明自己有一位名为 BackupAgent 的专属「备份代理」陪同；
- 注册登记备份服务。Android 系统针对服务有一套「交通管制」规则，只有「注册在案」才能上路；值得一提的是，有些设备上可能拥有不止一种备份服务（比厂商可能夹带自己开发的选项），每一种都需要单独注册登记；
- 按需扩展备份功能。开发者还需要根据实际备份需求，针对性扩展对「备份代理」BackAgent 的能力。例如，备份数据库、指定备份范围都需要额外开发，涉及的细节考虑多，代码复杂度高。只有在愿意牺牲灵活度的情况下，例如选择只备份特定偏好设置和存储空间中的文件，才能使用更简单的 BackupAgentHelper 实现。
备份格式也很有限：只能以 key=value 这种键值对格式存放，因此也被称为「键值对备份」。更要命的是，当年负责存储备份数据的 Android Backup Service 空间有限，一番折腾下来每个应用能够使用的数据上线其实只有区区 5MB。显然，这不足以记录复杂的备份数据，且为了削足适履，需要大量的代码开发和调试工作。
情况到了 2015 年的 Android 6.0 有所改善，新的「自动备份」机制接过了键值对备份的岗位。
相比前任，自动备份以文件为主要备份单元，对数据的支持更加完整。此外，它采用用户身份数据、应用数据和设置数据的三层架构设计，默认情况下支持的备份内容类型更多了；无论是偏好设置、数据库，还是应用保存在内外部存储空间中的常规文件，都在覆盖范围之内。如果开发者做好了功课（数据过滤、身份验证凭据和授权令牌传输等适配），自动备份甚至能够直接备份、恢复 app 内的账户登录状态。
更加利好的是，新机制适配流程也大幅简化：所有面向 Android 6.0（API 级别 23）或更高版本适配的应用，默认都会自动参与自动备份；之前键值对备份时代的多步流程被简化到：(1) 声明应用是否启用自动备份机制，和 (2) 划定包含和排除的备份文件范围。没有第三步了。
最后，自动备份的数据存储位置也换成了 Google 云端硬盘，每个应用可使用的备份数据上限也来到了 25MB，且不会计入用户的空间配额，因此无论有多少应用都不用担心容量问题。
总结起来，两代数据备份机制的关键区别如下表所示：
| 类别 | 键值对备份 | 自动备份 |
| 支持版本 | Android 2.2（API 级别 8）及更高 | Android 6.0（API 级别 23）及更高 |
| 适配流程 | 启用流程复杂，需要声明备份代理、注册备份服务并根据备份需求 各种开发定制 | 默认启用，仅需要通过声明 开启/关闭并借助 XML 过滤文件 备份范围的包含/排除 |
| 备份内容 | 键值对，可备份数据有限，取决于备份代理的功能扩展 | 文件，可备份数据丰富，且额外开发成本小 |
| 备份位置 | Android Backup Service，每个应用可使用 5MB | Google 云端硬盘，每个应用可使用 25MB |
更简单的适配，换来有条件的「自动」
这么看下来，新版的自动备份机制似乎已经解决了开发层面的主要问题，那为什么还是没有让更多人用上呢？不难猜到，原因出在用户体验层面：所谓的自动备份，真到用起来并没有那么「自动」。
