1つのGoogleアカウントで複数のAndroidデバイスを使用できることは新しいことではありません。新しいデバイスを初めてオンにすると、自分のデータをGoogleに保存するかどうかを尋ねられます。これにより、基本的に「何らかのもの」がGoogleサーバーに常に同期されます。

• 一部のアプリケーションデータ（アプリが明示的にサポートしている場合）
• Wi-Fiパスワード
• ブラウザのブックマーク
• Google Playからインストールされたアプリのリスト
• 画面キーボードで使用される辞書に追加された単語
• カスタマイズされた設定のほとんど

詳細は、Googleダッシュボードで確認できます。これらの問題をカバーする関連する質問は次のとおりです。

• Googleはどのような情報をバックアップしますか？
• Googleと正確に同期されるものは何ですか？
• AndroidはWiFiプロファイルをどのように同期しますか？

Google BackupのDevelopers APIは、バックアップ関連の仕組みについてのさらなる洞察を提供します（そして、ここでいくつかの質問は、それが実際にどのように機能するかを示します-つまり、時には機能する、時には部分的に、時にはまったく機能しない）。信頼性と、すべての人がプライベートデータをクラウドに望んでいるわけではないという事実（およびAPIリファレンス^2でさえ警告：Androidは、バックアップ使用中のデータのセキュリティについては保証しません。バックアップを使用して機密情報を保存する場合は常に注意が必要です）ユーザー名やパスワードなどのデータ。）、私の主な質問は次のとおりです。

同じアカウントを使用して複数のデバイスからデータをバックアップした：

• 以前にそのように使用されていた工場出荷時の状態にリセットされたデバイスはどうなりますか？それは認識され、以前に使用されたものだけが復元されますか？
  ^{（デバイスの識別は、たとえばIMEIを介して行われます（ただし、Android_IDを介してではなく、工場出荷時設定にリセットされる可能性があります）-これがNalumの回答に記載されている動作の理由である可能性があります）}
• このGoogleアカウントで初めて初期化した（新しい/工場出荷時のリセット）デバイスには何が復元されますか？
  ^{（使用するGoogleアカウントのバックアップでデバイスが識別される場合、「すべて復元、デバイスが変更されました！」などの「新しいデバイス」の特別なアクションをトリガーできます。または、「接続されていないデバイスXからすべて復元おそらく交換されました！」-ただし、工場出荷時のリセットの場合は「そのデバイスにあったもののみを復元する」ことに固執します）}

契約は次のとおりです。複数のデバイスがある場合、特定の問題に使用されることが多いため、すべてのデバイスにすべてが必要なわけではありません。バックアップするデータを選択する方法を見たことがないので（たとえば、「機密データ」を除外するために警告されています：WiFiパスワードはそのカテゴリに属します）、復元にも選択肢がないと思いますか？では、これはどのように処理されますか？

セット、赤ちゃんについて話しましょう

Androidのバックアップサービスには、セットと呼ばれる概念があります：1つのデバイスからバックアップされたすべてのデータのセットです（1つのトランスポートで、しかしそれは詳細です）。各セットは、デバイス上のIMEIなどの一意の文字列によって識別されます。アプリ（またはインストールされているアプリのリスト）がバックアップされると、そのバックアップデータは、バックアップ元のデバイスに関連付けられているセットに入ります。すべてのセットは、ユーザーのGoogleアカウントに固有のものです。デバイスをワイプして他の人に販売した場合、彼はあなたのGoogleアカウントにログインできない限り、そのデバイスのセットにアクセスできません。

デフォルトの動作

アプリがインストールされるか、デバイスのアプリのリストが復元されると、バックアップシステムは最初にそのデバイスのセットでそのパッケージのバックアップデータを検索します。見つからない場合（バックアップデータのない完全に新しいデバイスであるか、そのデバイスにそのパッケージがインストールされたことがないため）、検索を他のセットに拡張します。（選択肢がある場合は、デバイス全体の復元に使用された最後のセットが使用されます。）

したがって、新しいデバイスをセットアップすると、古いデバイスのバックアップからアプリのリストが復元され、古いデバイスのバックアップから各アプリが復元されます。あるデバイスにアプリをインストールし、別のデバイスにインストールした場合、アプリは古いデバイスからのデータで復元されます。どちらの場合でも、データは新しいデバイスのセットにバックアップされるようになりました。つまり、2つのデバイスからのバックアップデータはこれから分離されます。

デバイスを工場出荷時の状態にリセットした後、デバイスがある場合はそのデバイスの最後のバックアップから復元し、失敗した場合は他のデバイスのバックアップがある場合は復元しますが、それ以降は独自のセットの作成を開始します。そのため、Nalumの2つのデバイスは、お互いのバックアップされたアプリを見ることができません。それぞれのデバイスは、最後のバックアップから復元しています。

ソース

このメカニズムにはユーザー向けのドキュメントがありません。これは自動的に正しいことを行うためのものですが、コードは利用可能です。

bmgr：基本的な使用

Izzyが見つけたように、このbmgrツールを使用すると、このプロセスをある程度制御できます。プログラマーがアプリのバックアップ統合のテストとデバッグを支援することを目的としています。このツールを使用してadb shell、選択したパッケージのバックアップと復元、パッケージのバックアップデータの消去、さらにはデバイス全体の復元をトリガーできます。

root以外でデバイス上のシェルで使用しようとしないでください：android.permission.BACKUP何か面白いことをするにはシステムレベルが必要です。

バックアップしたデータをすぐにアプリに更新させることができます：

bmgr backup com.shadowburst.showr
bmgr run

（またはアプリのパッケージ名は何でも）。データを変更するたびにアプリが独自のバックアップを要求するため、通常はこれを行う必要はありませんが、これにより、不適切に作成されたアプリを回避できます。バックアップデータから1つのパッケージを復元するには、デフォルトで選択します。

bmgr restore com.shadowburst.showr

繰り返しますが、これはデバイスが単独で行うことのみを行うため、使用する必要はありません。また、この機能を使用するにはデバイスをインストールする必要があることに注意してください。

より詳細な制御

次に、バックアップシステムが実行しない処理について説明します。使用可能なバックアップデータのセットを確認するには：

bmgr list sets

次のような出力が得られます。

  3ff7800e963f25c5 : manta
  3f0e5c90a412cca7 : manta
  3dd65924a70e14c8 : TF101
  3baa67e9ce029355 : m0

左側の64ビットの16進数はトークンです。これはすぐに必要になります。右側のものは、セットを所有するデバイスの（比較的）わかりやすい名前です。たとえば、mantaはnexus-10のコード名です。TF-101は、元のasus-eee-pad-transformerを指します。必要なセットを特定したら、トークンを使用してそのセットからアプリを復元できます。

bmgr restore 3ff7800e963f25c5 com.shadowburst.showr

コマンドの最後にパッケージ名を追加して複数のパッケージを一度に復元するか、パッケージ名を指定せず（トークンのみ）、そのセットのデータを含むすべてのアプリを復元できます（つまり、システム全体を実行します）戻す）。

最後に、現在のセットからアプリのデータを消去できます。

bmgr wipe com.shadowburst.showr

これにより、次のバックアップ操作がゼロから開始されます。アプリのエラーによりバックアップデータが破損し、復元したくない場合は、アプリをアンインストールした後に便利です。

デバイスに別のセットへの書き込みを開始させることも、セット全体を消去することもできません。

以下は質問に対する答えとしては断然ですが、いくつかの詳細に光を当てる可能性があります。

バックアップAPIから抽出された一部

APIは主に開発者を対象としていますが、このケースで抽出できる可能性があるいくつかの事実があります。次のリストで、斜体はAPIドキュメントからの引用を示します。

• Androidは、アプリケーションがインストールされ、ユーザーに関連付けられたバックアップデータが存在する場合、自動的に復元操作を実行します。
  →これは2つのことを意味します。
  • アプリがGoogle Backup APIをサポートし、ユーザーがGoogle Backupを有効にしている場合、利用可能なバックアップデータはインストール時に自動的に復元されます。単一のデバイスで使用されるアプリを初めて2番目のデバイスにインストールする場合に便利です。
  • バックアップは、デバイスではなく、Googleアカウントにのみ関連付けられます（ユーザーに関連付けられたバックアップデータが存在します）-または、この特別なケースに関係ないため、他の事実は無視されました（「アプリがインストールされています」）
• バックアップトランスポートは、Androidのバックアップフレームワークのクライアント側コンポーネントであり、デバイスメーカーとサービスプロバイダーによってカスタマイズ可能です。バックアップ転送はデバイスごとに異なる場合があります [...]
  →これは、異なるデバイス（または異なるAndroidバージョン）の場合の信頼性を説明する可能性があります。
  ^{（エンファシス鉱山）}
• データバックアップは、すべてのAndroid搭載デバイスで利用できることを保証されていません。
  （コメント無し）
• Googleは、Android 2.2以降を実行するほとんどのAndroid搭載デバイス向けに、Androidバックアップサービスを使用したバックアップトランスポートを提供します。
  →ここでは、Googleバックアップに必要なAndroidの最小バージョンがあります：Froyo、AKA Android 2.2
• バックアップサービスキーを取得するには、Androidバックアップサービスに登録します。[...]
  →各アプリには独自のキーが必要です。「理由」は説明されていませんが、良い推測です。アプリが別のアプリのバックアップを読み取れないようにバックアップを分離する（間違ったキー。別のユーザーのバックアップは間違ったアカウントです）
• アプリケーションの開発中に、bmgrツールを使用して、バックアップマネージャーからすぐにバックアップ操作を開始できます。
  →バックアップを手動でトリガーする方法があるように見えますか？それについては後で掘り下げましょう。↓
• アプリケーションデータを復元するとき、バックアップマネージャはバックアップエージェントのonRestore()メソッドを呼び出します。
  →これにより、このリストの最初の項目に再び下線が引かれます。最初にアプリをインストールする必要があり、次に独自の実装を使用してデータを復元します。再確認：アプリの復元が失敗した場合、失敗したアプリのデータの復元はありません-Google Playを使用して手動でインストールするまで。次に、最初の項目が示したように、説明された条件でデータがGoogleバックアップを介して自動的に復元されます（同じアカウントでバックアップされている必要があります）。
• 他のファイルのバックアップ
  →その章の（技術的な）内容から引用するのではなく、簡単に言うと、内部ストレージのファイルのみをバックアップすることができます。

bmgr APIから抽出された一部

• バックアップおよび復元操作を誘導するコマンドを提供します[...]
  →「自動化」が失敗した場合に手動でアクションをトリガーする方法は次のように見えます
• これらのコマンドには、adbシェルを介してアクセスします。
  →これは説明を必要としません:)
• adb shell bmgr backup <package>
  →OK、このアクションはアプリにバインドされています。データプロバイダーのパッケージ名がわかっている場合は、これも機能するはずです（たとえばcom.android.providers.settings、システム設定やcom.android.providers.telephonySMS / MMSなど）。
• bmgr runコマンドを使用して、保留中のすべてのバックアップ操作をすぐに強制的に実行できます
  。最初のコマンドは、バックアップを「スケジュール」するだけです。すべてのパッケージをトリガーすると、これを使用してすぐにパッケージを実行できます。
• adb shell bmgr restore <package>
  →これは本当のことですよね？その理由は次のとおりです。バックアップマネージャは、アプリケーションのバックアップエージェントを即座にインスタンス化し、復元のために呼び出します。データは、アプリが既に存在する必要があるため（そのルーチンが呼び出されるため）。

つまり、bmgrインストール済みのGoogleバックアップをサポートするアプリのバックアップをトリガーするために使用できます。また、同じデータの復元をトリガーすることもできます。完全な復元をトリガーするために使用することはできません-少なくともここには記載されていません。

Googleバックアップに関する詳細情報。カスタムファームウェアをフラッシュしたとき、期待どおりにアプリが復元されませんでした。[設定]-> [ バックアップとリセット ] で、「デバッグ専用のプライベートキャッシュにバックアップする」と表示されbmgr list sets、結果は得られませんでした。
私は、これらのステップを実行して、私の問題を解決するadb shell：
$ bmgr transport com.google.android.backup/.BackupTransportService
$ bmgr list sets 3a0a00a516a1daf1 : LT22i
これは十分ではありませんでした、しかし。アプリのインストールは開始されませんでした。これは、
$ bmgr list sets 3179e4ab08d74930 : LT22i 3a0a00a516a1daf1 : LT22i
IMEIが明らかに同じであるにもかかわらず、新しいセットを作成した理由を示しています。とにかく、これは修正でした：（
$ bmgr restore 3a0a00a516a1daf1最初に表示されたID）
$ bmgr run（確かに）
その後、アプリのダウンロードを開始しました。

私の経験では、各デバイスには独自のバックアップがあります。これは、Nexus 7とGalaxy S IIをいじり回すことで得られます。それ以外は知りません。

アプリ：

Nexus 7にはこれらのアプリCaustic、DC Comicsおよび20 Minute Mealsがあり、Galaxy S IIの工場出荷時のリセット時にGalaxy S IIにインストールされません。

Galaxy S IIにはこれらのアプリDriveDroidとHuman Japaneseがあり、Nexus 7を工場出荷時にリセットしてもNexus 7にはインストールされません。

アプリは両方のデバイスと互換性があるため、非互換性が、それぞれのデバイスにインストールされない理由にはなりません。

データ：

Wifiやその他のデータに関しては、Androidの初期セットアップ中に各デバイスでWifiをセットアップするたびに確信が持てません。他のGoogleアカウントについては、各デバイスにコピーされていないようで、各デバイスのSkypeアカウントとGitHubアカウントについても同じことが言えます。

Nexus 4（KitKatストックから）にCarbonカスタムROMを消去してインストールする前に、組み込みのGoogleバックアップとHeliumバックアップの両方を使用してバックアップしました。この携帯電話を復元したときと同じように、Googleがアプリや設定などを復元することを期待していましたが、喜びはありませんでした。

手動の「PCダウンロード」復元でも、ヘリウムも試してみましたが、喜びもありませんでした-「復元された」と言いましたが、Wifiとアプリのデータはまだありません。

bmgr restore <xxx>完全な復元を実行しbmgr run、上記で説明したように、完全なGoogle復元をトリガーし、大いに役立ちました-私にとっては命の恩人です！

特にAppleが「うまくいく」というアイデアと競争したい場合、Googleはより良い努力をすることができます...それでも、落とし穴にもかかわらずAndroidのハッキング性が大好きです！