標籤:
一.功能介紹
Android m 的自動備份資料功能運用的是Android Backup Service,將資料備份到了google drive中。Android Backup Service其實在安卓2.2就已經有了。但一開始Google的備份服務並不是用來同步備份應用資料,而是為了方便使用者可以在不同裝置上擷取到備份的資料。而現在,只要你的app資料發生變化,或者系統升級時,Android M的應用資料備份功能便會啟動。所以應用可以隨時恢複之前儲存過的資料,即使是裝置恢複過出廠設定或者更換了新的裝置。這樣,遊戲會記得使用者遊戲過程中暫停位置,而應用也能夠儲存登入資訊和偏好設定。
但自動備份功能也有一定的限制性
一方面它每個app最多隻能備份25MB的資料。原文如下:
另一方面,對於使用Google雲訊息推播通知的應用程式,有一個已知的問題,即備份Google雲資訊註冊返回的註冊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匹配的檔案中。
四. 我們能實現嗎
上文已經提到,Google實現自動備份,其實是擷取了其他app的讀寫權限,在app裡寫入相應配置從而實現備份的。那為什麼Google能擷取到其他app的讀寫權限呢?因為他擁有系統許可權,所有安裝到他系統內的app他都擁有讀寫權限。但app與app之間是沒法擷取到對方的讀寫權限的。Android 應用借用了 Linux Sandbox技術,將不同 APP 之間做了隔離;APP 之間的隔離主要是資源隔離和許可權訪問隔離。雖然APP 許可權機製為應用程式之間的資源互訪提供了可行性,APP申請到許可權並經過使用者授權後可以訪問其他程式的服務。但這需要兩個app都在代碼裡面進行相應配置。首先要用相同的 private key 來簽名從而保證兩個app運行在同一個進程中,接著要自訂<permission> 標籤到時詢問使用者是否要擷取該app的讀寫權限。但這是不實際的,我們不可能同所有app合作,讓他們在程式碼裡都加入讓我們擷取他們讀寫權限的配置。
Android M 新特性——應用資料自動備份功能