一．功能介绍
Android m 的自动备份数据功能运用的是Android Backup Service，将数据备份到了google drive中。Android Backup Service其实在安卓2.2就已经有了。但一开始谷歌的备份服务并不是用来同步备份应用数据，而是为了方便用户可以在不同设备上获取到备份的数据。而现在，只要你的app数据发生变化，或者系统升级时，Android M的应用数据备份功能便会启动。所以应用可以随时恢复之前存储过的数据，即使是设备恢复过出厂设置或者更换了新的设备。这样，游戏会记得用户游戏过程中暂停的位置，而应用也能够保存登录信息和偏好设定。
但自动备份功能也有一定的限制性
一方面它每个app最多只能备份25MB的数据。原文如下：
另一方面，对于使用谷歌云消息推送通知的应用程序，有一个已知的问题，即备份谷歌云信息注册返回的注册id会打破恢复的应用程序的推送。所以当app安装到一个新设备后，询问API从而获取到一个新的注册id是很重要的，但如果你把旧的注册id备份上去了，在新设备安装的这个app就不会再去询问API获取新的注册id了。所以为了避免这个问题，要在xml中的exclude标签里进行相应配置。通俗易懂点讲，一般设备的id信息是要根据设备生成的，不能用旧的。但如果你将之前的id信息也备份了上去，那新设备就不会去生成新的信息了。原文如下：
二． 关于备份
自动备份服务支持通过XML配置文件和app manifest来设定备份规则。
在app manifest中，只需要一行代码来指定你要引入规则的xml文件(mybackupscheme为xml文件名)
接着在xml中配置相应规则即可
· <include>指定要备份的文件
· <exclude>指定不备份的文件
· domain指定文件类型
· path 指定要备份的文件路径
那么Android M是如何实现对app进行自动备份的呢，其实他是通过获取app的读写权限，读取app的app manifest从而在里面写入相关的备份配置。
三． 关于恢复
数据需要恢复的时候，Backup Manager 会先调用requestRestore()方法从google drive把数据下载下来
再调用onStore()方法将数据恢复到你的设备上。这个方法需要传三个参数
· data： 一个 BackupDataInput，从而允许你读取到备份的数据
· appVersionCode： 就是你应用里的android:versionCode属性值，用它可以来判断应用数据和云端备份的数据格式是否兼容。
· newState：一个开放的，可读写的，指向保存着你最终的数据备份状态的文件的ParcelFileDescriptor. 这个对象将会在下一次调用onBackup的时候，以oldState的变量名返回。
执行onStore()方法的时候，首先会调用readNextHeader()方法去遍历数据组中存在的所有实体。每找到一个实体，便会进行下列的操作：
- 用getKey()方法获取实体的key
2. 将实体的key和你在BackupAgent类中声明的所有static final类型的key值比较，一旦和你现有的其中一个key值匹配，便会将从云端下载下来的数据提取出来并保存到你的设备上。
保存数据用到了上图中的helper.restoreEntity()方法，他会将数据写入到和key匹配的文件中。
四． 我们能实现吗
上文已经提到，谷歌实现自动备份，其实是获取了其他app的读写权限，在app里写入相应配置从而实现备份的。那为什么谷歌能获取到其他app的读写权限呢？因为他拥有系统权限，所有安装到他系统内的app他都拥有读写权限。但app与app之间是没法获取到对方的读写权限的。Android 应用借用了 Linux Sandbox技术，将不同 APP 之间做了隔离；APP 之间的隔离主要是资源隔离和权限访问隔离。虽然APP 权限机制为应用程序之间的资源互访提供了可行性，APP申请到权限并经过用户授权后可以访问其他程序的服务。但这需要两个app都在代码里面进行相应配置。首先要用相同的 private key 来签名从而保证两个app运行在同一个进程中，接着要自定义<permission> 标签到时询问用户是否要获取该app的读写权限。但这是不实际的，我们不可能同所有app合作，让他们在程序代码里都加入让我们获取他们读写权限的配置。