このページでは、アプリのクラウド バックアップとデバイス間（D2D）転送プロセスをテストする方法について説明します。ユーザーが新しいデバイスでアプリを継続して使用できるように、アプリのメジャー リリースごとに両方をテストすることが重要です。バックアップと転送はどちらも似ていますが、Android 12（API レベル 31）以降では、両者の間に重要な違いがあります。最も顕著なのは、転送のデータサイズの上限が 2 GB と、クラウド バックアップの 25 MB と比べてはるかに大きいことです。
このガイドでは、開発サイクル全体でクラウド バックアップと復元、D2D 転送の両方を効率的にテストする方法について説明します。
バックアップのテストの仕組み
このセクションでは、Android バックアップ フレームワークのさまざまな要素と、それらが自動バックアップおよび Key-Value バックアップをサポートするアプリとどのようにやり取りするかを説明します。アプリ開発段階では、フレームワークの内部作業のほとんどが抽象化されているため、このような情報を知る必要はありません。ただし、テスト段階では、こうした概念を理解することがより重要になります。
次の図は、クラウド バックアップと復元時のデータの流れを示しています。テスト目的であれば、クラウド バックアップと復元に同じデバイスを使用できます。
次の図は、D2D 転送時のデータの流れを示しています。
クラウド バックアップと復元のテストとは異なり、D2D テストでは、コピー元とコピー先のソースデバイスとターゲット デバイスが必要です。
バックアップ マネージャー サービスは、バックアップと復元処理を調整および開始する Android システム サービスです。このサービスには Backup Manager API でアクセスできます。
バックアップ処理では、このサービスはアプリにバックアップ データをクエリしてバックアップ トランスポートに渡します。データはバックアップ トランスポートによってクラウドにアーカイブされます。復元処理中、Backup Manager Service はバックアップ トランスポートからバックアップ データを取得し、デバイスにデータを復元します。D2D 転送の場合、バックアップ マネージャー サービスはアプリにバックアップ データをクエリし、新しいデバイスのバックアップ マネージャー サービスに直接渡します。新しいデバイスのバックアップ マネージャー サービスは、そのデータをアプリに読み込みます。
バックアップ トランスポートは、アプリデータの保存と取得を行う Android コンポーネントです。Android 搭載デバイスには 0 個以上のバックアップ トランスポートを含めることができますが、アクティブとしてマークできるのは 1 つだけです。デバイス メーカーとサービス プロバイダによるカスタマイズが原因で、利用できるバックアップ トランスポートはデバイスによって異なりますが、ほとんどの Google Play 対応デバイスには以下のトランスポートが付属しています。
- GMS トランスポート: ほとんどのデバイスでアクティブなクラウド バックアップ トランスポート。Google モバイル サービスの一部です。このトランスポートは、Android Backup Service にデータを保存します。
- D2D 転送: この転送は、D2D 移行でデバイス間でデータを直接転送するために使用されます。
ツール
バックアップと復元処理をテストするには、以下のツールに関する知識が少々必要です。
adb: デバイスまたはエミュレータでコマンドを実行します。bmgr: さまざまなバックアップと復元オペレーションを実行します。logcat: バックアップ オペレーションと復元オペレーションの出力を確認します。
クラウド バックアップをテストする
このセクションの手順に沿って操作すると、1 台のデバイスでクラウド バックアップと復元を実行できます。
クラウド バックアップ用にデバイスまたはエミュレータを準備する
次のチェックリストを確認して、バックアップ テスト用のデバイスまたはエミュレータを準備します。
- 自動バックアップの場合は、Android 6.0（API レベル 23）以上を搭載したデバイスまたはエミュレータを使用していることを確認します。
- Key-Value バックアップの場合は、Android 2.2（API レベル 8）以上を搭載したデバイスまたはエミュレータを使用していることを確認します。
- クラウド バックアップをテストするには、インターネットにアクセスできる必要があります。
- Google アカウントでデバイスにログインし、[設定] -> [Google] -> [バックアップ] でバックアップ アカウントとして設定します。
クラウド バックアップをテストするには、クラウド バックアップをトリガーしてから、アプリをアンインストールして再インストールします。これらの手順を繰り返すには、次のスクリプト test_cloud_backup.sh を使用します。このスクリプトは、アプリをバックアップし、APK をローカルにダウンロードして、アンインストールしてから APK を再インストールします。
#!/bin/bash -eu
: "${1?"Usage: $0 package name"}"
# Initialize and create a backup
adb shell bmgr enable true
adb shell bmgr transport com.android.localtransport/.LocalTransport | grep -q "Selected transport" || (echo "Error: error selecting local transport"; exit 1)
adb shell settings put secure backup_local_transport_parameters 'is_encrypted=true'
adb shell bmgr backupnow "$1" | grep -F "Package $1 with result: Success" || (echo "Backup failed"; exit 1)
# Uninstall and reinstall the app to clear the data and trigger a restore
apk_path_list=$(adb shell pm path "$1")
OIFS=$IFS
IFS=$'\n'
apk_number=0
for apk_line in $apk_path_list
do
(( ++apk_number ))
apk_path=${apk_line:8:1000}
adb pull "$apk_path" "myapk${apk_number}.apk"
done
IFS=$OIFS
adb shell pm uninstall --user 0 "$1"
apks=$(seq -f 'myapk%.f.apk' 1 $apk_number)
adb install-multiple -t --user 0 $apks
# Clean up
adb shell bmgr transport com.google.android.gms/.backup.BackupTransportService
rm $apks
echo "Done"
テスト手順
- アプリを開いてログインし、すべての設定を変更します。
test_cloud_backup.sh com.example.myappなどのパッケージ名を渡してスクリプトを実行します。- アプリを再度開き、すべてのデータが保持された状態で正常に動作することを確認します。
ユーザーにログインを求める必要はなく、すべての設定、進行状況、アプリデータは以前の状態のままである必要があります。テスト結果がこれらの条件を満たしていない場合は、重要なデータを省略せずにバックアップを正しく構成し、バックアップから除外したキャッシュ データの再作成も処理していることを確認してください。テスト イテレーションごとに手順 1 ～ 3 を繰り返します。
D2D 転送をテストする
D2D 転送をテストする最も包括的な方法は、スマートフォンのコンテンツ全体を新しい出荷時の設定にリセットされたデバイスに転送し、正しく動作することを確認することです。ただし、このプロセスを複数回繰り返す必要がある場合は、不便で時間がかかることがあります。この手順では、デバイスを出荷時の設定に繰り返しリセットすることなく、1 台のデバイスで移行をシミュレートする方法について説明します。
D2D テスト用にデバイスを準備する
単一のデバイスで D2D 転送をテストするには、次のように準備します。
- デバイスに Android 12（API レベル 31）以降が搭載されている必要があります。
- 最新バージョンの D2D をテストするには、アプリで Android 12（API レベル 31）以上をターゲットにします。
- テストの繰り返しをサポートする次のスクリプト
test_d2d.shを作成します。
#!/bin/bash -eu
: "${1?"Usage: $0 package name"}"
# Initialize and create a backup
adb shell bmgr enable true
adb shell settings put secure backup_enable_d2d_test_mode 1
adb shell bmgr transport com.google.android.gms/.backup.migrate.service.D2dTransport
adb shell bmgr init com.google.android.gms/.backup.migrate.service.D2dTransport
adb shell bmgr list transports | grep -q -F " * com.google.android.gms/.backup.migrate.service.D2dTransport" || (echo "Failed to select and initialize backup transport"; exit 1)
adb shell bmgr backupnow "$1" | grep -F "Package $1 with result: Success" || (echo "Backup failed"; exit 1)
# Uninstall and reinstall the app to clear the data and trigger a restore
apk_path_list=$(adb shell pm path "$1")
OIFS=$IFS
IFS=$'\n'
apk_number=0
for apk_line in $apk_path_list
do
(( ++apk_number ))
apk_path=${apk_line:8:1000}
adb pull "$apk_path" "myapk${apk_number}.apk"
done
IFS=$OIFS
adb shell pm uninstall --user 0 "$1"
adb shell bmgr transport com.google.android.gms/.backup.BackupTransportService
apks=$(seq -f 'myapk%.f.apk' 1 $apk_number)
adb install-multiple -t --user 0 $apks
# Clean up
adb shell bmgr init com.google.android.gms/.backup.migrate.service.D2dTransport
adb shell settings put secure backup_enable_d2d_test_mode 0
adb shell bmgr transport com.google.android.gms/.backup.BackupTransportService
rm $apks
echo "Done"
テスト手順
- テストするアプリをデバイスにインストールします。
- アプリを開き、ログインして、アプリの設定を変更します。
- デバイスでスクリプトを実行し、パッケージ名（
test_d2d.sh com.example.myappなど）を渡します。 - スクリプトが完了したら、デバイスでアプリを開き、すべてのデータが保持された状態でアプリが正しく動作することを確認します。
ユーザーがログインする必要がなく、すべての設定、進行状況、アプリデータがスクリプトを実行する前と同じように表示されるようにします。テスト結果がこれらの条件を満たしていない場合は、重要なデータを省略せずに転送を正しく構成し、転送から除外したキャッシュ データの再作成も処理していることを確認してください。テストのイテレーションごとに手順 2 ～ 4 を繰り返します。
バックアップと復元に関するトラブルシューティング
このセクションでは、よくある問題のトラブルシューティングについて説明します。
トランスポートの容量を超過した
Logcat に次のメッセージが表示された場合は、アプリが転送割り当てを超過したことを示します。
I/PFTBT: Transport rejected backup of <PACKAGE>, skipping
--- or ---
I/PFTBT: Transport quota exceeded for package: <PACKAGE>
バックアップ データの量を減らしてから、もう一度試してください。たとえば、アプリのキャッシュ ディレクトリにのみデータをキャッシュしていることを確認します。キャッシュ ディレクトリはバックアップに含まれません。
フル バックアップができない
Logcat に次のメッセージが表示された場合、Key-Value バックアップ処理がまだデバイスで行われていないため、フル バックアップ処理が失敗したことを示します。
I/BackupManagerService: Full backup not currently possible -- key/value backup
not yet run?
bmgr run コマンドで Key-Value バックアップをトリガーしてから、もう一度お試しください。
エージェントの待機中にタイムアウトした
Logcat に次のメッセージが表示された場合、アプリがバックアップを起動するのに 10 秒以上かかっていることを示します。
12-05 18:59:02.033 1910 2251 D BackupManagerService:
awaiting agent for ApplicationInfo{5c7cde0 com.your.app.package}
12-05 18:59:12.117 1910 2251 W BackupManagerService:
Timeout waiting for agent ApplicationInfo{5c7cde0 com.your.app.package}
12-05 18:59:12.117 1910 2251 W BackupManagerService:
Can't find backup agent for com.your.app.package
ログ出力に示されているタイムスタンプの差分を確認してください。通常、このエラーはアプリが ProGuard なしで Multidex 構成を使用している場合に発生します。
バックアップ アカウントが初期化されていない
Logcat に次のメッセージが表示された場合、バックアップ データセットが初期化されていないため、バックアップが停止したことを示します。
01-31 14:32:45.698 17280 17292 I Backup: [GmsBackupTransport] Try to backup for
an uninitialized backup account.
01-31 14:32:45.699 1043 18255 W PFTBT: Transport failed; aborting backup: -1001
01-31 14:32:45.699 1043 18255 I PFTBT: Full backup completed with status: -1000
adb shell bmgr run コマンドでバックアップ マネージャーを実行してから、もう一度バックアップを実行してください。
アプリのメソッドが呼び出されていない
自動バックアップでは Application の基本クラスを使用してアプリを起動するので、アプリの設定メソッドが呼び出されない場合があります。自動バックアップもアプリのアクティビティを起動しないため、アプリがアクティビティで設定を行うとエラーが表示される場合があります。詳しくは、BackupAgent を実装するをご覧ください。
一方、Key-Value バックアップでは、アプリ マニフェスト ファイルで宣言された Application サブクラスを使用してアプリを起動します。
バックアップするデータがない
Logcat に次のメッセージが表示された場合、アプリにバックアップするデータがないことを示します。
I Backup : [FullBackupSession] Package com.your.app.package doesn't have any backup data.
--- or ---
I Backup : [D2dTransport] Package com.your.app.package doesn't have any backup data.
独自の BackupAgent を実装した場合、バックアップにデータやファイルを追加していない可能性があります。