Android 6.0 - Auto Backup for Apps made simple 翻訳

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アカウントを設定して下さい。

最後に

バックアップ周りは各段に楽になりましたね。
今回2本翻訳記事をアップしましたが、これらの文章の不明瞭な点や、もっと詰めたほうが良い点については、また機会があれば書いていきたいと思っております。


がく

がく

アンドロイドアプリの脆弱性検査ツールのRiskFinder株式会社 代表取締役 スマフォのセキュリティ色々やってます。

リスクファインダーはAndroidアプリのセキュリティホールを見つけます!

Androidスマートフォンが急速に普及するとともにアプリの脆弱性報告も急増しています。
リスクファインダーは、Androidアプリの脆弱性診断WEBサービスです。
500項目以上のチェックでアプリの脆弱性や問題を検出し、セキュアなアプリ開発をサポートします。

  • ブラウザでファイルをアップロードするだけ
  • アプリの脆弱性を指摘するだけでなく対処方法も提示
  • 頻繁にバージョンアップするAndroidの最新情報に素早く対応

リスクファインダーの詳細はこちら