Android 6.0 - Auto Backup for Apps made simple　翻訳

by がく A⁺ a^-

先日のConfiguring Auto Backup for Apps 翻訳に続き、アンドロイド6.0で新しくなったバックアップ関係の翻訳です。Androiod Developerブログの記事ですが、既に翻訳されている人がいたのに後になって気が付いたんだけど、もったいないのでアップです。
バックアップ関係の翻訳ドキュメントとしてはこれで終わりです。

Auto Backup for Apps made simple

URL:http://android-developers.blogspot.jp/2015/07/auto-backup-for-apps-made-simple.html

Auto Backup for Appsはアプリデータのバックアップとレストアをアプリケーションに
コードを追加することなくシームレスに実現します。
この機能はAndroid M以上の端末で動作します。
アプリでAutoBackupを有効にするにはtargetSdkVersionを23以上に設定するだけです。

Auto Backup for AppsはGoogleによって提供されるものであり、ユーザと開発者両方とも料金は必要ありません。
さらに嬉しいことに、Google Driveに保存されるバックアップデータはユーザの容量としてカウントされません。
しかしデータ通信はユーザのモバイル通信として課金される可能性があるので注意して下さい。

Auto-Backup for Appsとは

デフォルトでバックアップはオプトインであり、全てのアプリデータファイルは自動的にユーザのGoogle Driveにコピーされます。
アプリデータファイルにはデータベース、プリファレンス、その他アプリプライベートディレクトリ内のファイルが含まれアプリごとに最大25MBまでバックアップされます。
Context.getCacheDir(), getCodeCacheDir(), getNoBackupFilesDir()はバックアップ対象に含まれません。
外部ストレージのファイルも対象には含まれませんが、getExternalFilesDir()だけは対象に含まれます。

バックアップのコントロールの仕方

設定ファイルをres/xml配下に作成してAndroidManifestから参照することでどのファイルをバックアップするかをカスタマイズできます。

<application
        android:fullBackupContent="@xml/mybackupscheme">

設定ファイル内では<include/>または<exclude/>でどのファイルをバックアップするかを指定します。
設定方法の詳細および書き方に関してはドキュメントを参照して下さい。

バックアップから除外するファイル

アプリにバックアップを望まないデータがあるかもしれません。そのようなデータに対しては以下の方法を適用して下さい。

サーバまたはクライアントで生成するデバイスを特定するような識別データは除外する必要があります。
これにはGoogle Cloud Messaging(GCM)のregistration tokenが含まれます。
もしもこのデーを別の端末に復元してしまった場合は正しくGCMメッセージを受信できなくなってしまいます。
アカウントの資格情報やその他のセンシティブな情報をバックアップから除外することを検討して下さい。
バックアップに保存するのではなく、復元されたアプリを初めて起動するときにユーザに再認証を求めるなどしてください。

多種多様なアプリが存在することを考えると、開発者にとって重要なのは自動バックアップによってユーザの利益を最大化する方法を検討することです。
最終目的はユーザが新しいデバイスをセットアップするときによく行われている、設定ファイルやローカルデータの移行作業を少なくすることです。

例えばユーザのアカウント情報が含まれたSharedPreferenceをインストール時に復元することで、ユーザは以前の端末でどのアカウントを使用していたかを考えずにパスワードを入力するだけで使用開始することができます。

もし複数のログイン方法をサポートしている場合(Google Sign-Inやその他のSign-In、ユーザー名/パスワードによるログインなど)、単純にどのログイン方法を使用していたかをバックアップしておくことでユーザはログイン方法を選択させなくてもよくなります。

key/valueによるバックアップからの移行

もしBackupAgentのサブクラスとManifestファイルの設定(android:backupAgent)でkey/valueによる古いバックアップ方法を使用している場合、ワンステップで今回のフルデータバックアップに移行することができます。単純にandroid:fullBackupOnly="true"属性を<application/>に含めるだけです。
この設定はAndroid6.0以上の端末ではシステムに対してレガシーなBackupAgentの機能を提供しながら新しいAuto Backupの機能を使用することを伝え、古い端末では依然としてonBackup/onRestoreがコールされることを意味します。

この方法はkey/valueバックアップは行わないが、BackupAgent.onCreate()やonFullBackup()、レストアが完了したタイミングを知らせるonRestoreFinished()などをカスタムしている場合にも適用できます。
しかしこの状態でXMLにAutoBackupの設定(include/exclude)がある場合はsuper.onFullBackup()をコールする必要があります。

backup/restoreのライフサイクルとは

データのレストアはユーザがアプリを起動できるようになる前の段階であるパッケージインストール時に行われます。
バックアップは大抵一日に一回、デバイスが充電中かつWi-Fiに接続されている時に実行されます。
もしアプリがバックアプ容量の上限(現状は25MB)を超えた場合、それ以降のバックアップは行われず最後にセーブした内容が後のレストアで使用されます。
フルバックアップ実行後やbmgrコマンドの手動実行(詳細は後述)前にアプリプロセスはkillされます。

アプリのテストをしよう

Auto Backupのテストを始める前にAndroid Mの最新バージョンのエミュレータか端末を要します。
APKをインストールしたらadb shellコマンドでbmgrツールにアクセスします。
BmgrはBackupMangerの操作を可能にするためのコマンドです。

bmgr run このコマンドは即時バックアップを主ケジュールします。Backup Managerが正しく初期化できるようにアプリインストール後に一度このコマンドを実行しておく必要があります。
bmgr full backup <packagename> フルデータバックアップ処理を開始します。
bmgr restore <packagename> バックアップしたデータをレストアします。

もしbmgr runコマンドの実行を忘れていた場合、fullbackupやrestoreコマンドを試した際にLogCatにエラーが表示されます。
問題が解決しない場合はシステム設定>Backup & reset 内でバックアップを有効にしてGoogleアカウントを設定して下さい。