一．功能介紹
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合作，讓他們在程序代碼里都加入讓我們獲取他們讀寫權限的配置。