先に結論：AndroidのAuto Backupは、アプリの設定やユーザーデータを、機種変更や再インストール後に戻せるようにするOS標準のバックアップ機能です。Android 6.0（API 23）以降で利用でき、対象アプリでは基本的に有効ですが、何でも無条件に保存されるわけではありません。

特にAndroid 12（API 31）以降は、Google Driveなどを使うcloud-backupと、旧端末から新端末へ直接送るdevice-transferを分けて設定します。Android 11以前向けのfullBackupContentも残しつつ、Android 12以降向けにdataExtractionRulesを用意するのが基本です。バックアップ成功と復元成功は別なので、最後にテスト端末で復元まで確認してください。

Auto Backupとは？独自クラウド同期との違い

Auto Backupは、アプリが持つファイルやデータベースなどをAndroidのバックアップ基盤が収集し、クラウドまたは端末間転送で復元する仕組みです。対象アプリのコードから毎回アップロード処理を書く必要がなく、ユーザーの機種変更や再インストール時の初期状態を改善できます。

ただし、アプリ独自のサーバー同期とは役割が違います。Auto Backupは端末にあるアプリデータの復元を支援するもので、複数端末間のリアルタイム同期、アカウント横断のデータ統合、大容量メディアの保管を自動で代替するものではありません。

方式主な保存先・経路向いている用途注意点
Auto Backup / cloud-backupユーザーのバックアップ基盤からクラウドへ設定、進捗、軽量なローカルデータの復元通常のクラウド上限はアプリユーザーあたり25MB。実行条件もある
Auto Backup / device-transfer旧端末から新端末へ直接転送機種変更時の端末間移行クラウドとは別の設定・端末条件で動く
独自クラウド同期アプリのサーバーやアカウント複数端末同期、大容量データ、アカウント復元認証、サーバー設計、削除・競合処理を自分で管理する
Androidアプリのデータを選択し、クラウドまたは端末間転送で新端末へ復元するAuto Backupの全体像
バックアップ方式を選び、新端末で復元する全体の流れ

何がバックアップされる？RoomやSharedPreferencesの扱い

Android公式のAuto Backup説明では、初期状態で次のようなアプリ領域が対象になります。

  • SharedPreferencesのファイル
  • getFilesDir()やgetDir()で保存した内部ファイル
  • getDatabasePath()が返すデータベース領域
  • getExternalFilesDir()のアプリ専用外部領域

RoomはSQLiteデータベースなので、保存場所とルールが対象になっていればDBファイルもバックアップ対象になり得ます。ただし、復元されたDBを新しいアプリが開けることは別問題です。Entityやテーブル構造が変わったアプリ更新では、RoomのMigrationが必要になることがあります。これはバックアップ設定ではなく、旧DB schemaを新schemaへ移す問題です。詳しくはRoom Migrationの記事で整理しています。

cache、code_cache、no_backupの領域は、再生成できる一時データとして標準では除外されます。キャッシュをバックアップ対象に入れるより、復元後に再取得・再生成できる設計にする方が安全です。

バックアップから除外するデータの考え方

データ基本方針理由・確認点
ユーザー設定・進捗必要なものは対象にする機種変更後の体験に直結する
Roomのユーザーデータサイズと復元互換性を確認して対象にするschema変更時はRoom Migrationも必要
認証トークン・秘密情報原則として除外し、再ログインや安全な再発行を設計する別端末へのコピーを前提にしない
端末固有ID・不安定なURI除外または再生成する新端末で無効になる可能性がある
キャッシュ・ダウンロード再生成可能データ除外を検討する容量と復元時間を抑えられる
暗号鍵・Keystore依存データ別端末で利用できる前提にしない鍵の移行可否と保護境界が別にある

「保存されているから復元してよい」とは限りません。特に認証情報や暗号鍵は、バックアップ対象に含めるかではなく、復元後に安全な再認証・再発行を行う設計を優先します。

Androidバージョン別の設定

Android 11（API 30）以下ではfullBackupContent形式、Android 12（API 31）以降ではdataExtractionRules形式を使います。Android 12以降でも古い端末をサポートするなら、両方の設定を用意してください。Android 12以降では、旧形式のinclude/exclude指定だけではD2D転送を制御できません。

Manifestの指定例

ファイル名と参照先はサンプルです。実際のres/xml/構成に合わせて変更してください。

<application
    android:allowBackup="true"
    android:fullBackupContent="@xml/backup_rules_legacy"
    android:dataExtractionRules="@xml/backup_rules"
    ... >

android:allowBackupの既定値はtrueと公式に説明されていますが、意図を明示するために設定しておく方が確認しやすいでしょう。Android 12以降は端末メーカーによって、allowBackup="false"がクラウドを止めてもD2D転送まで同じように止めるとは限らないため、D2Dも含めて公式仕様と対象端末で確認します。

Android 11以前：fullBackupContent

<full-backup-content>
    <include domain="database" path="app.db" />
    <include domain="sharedpref" path="settings.xml" />
    <exclude domain="sharedpref" path="auth.xml" />
</full-backup-content>

この例は対象を絞るサンプルです。includeを使うとバックアップ範囲が指定対象中心になるため、「設定を書いたら他の必要ファイルまで消えた」という事故に注意します。実際のDB名、SharedPreferences名、ファイルパスはアプリの構成に合わせてください。

Android 12以降：dataExtractionRules

<data-extraction-rules>
    <cloud-backup disableIfNoEncryptionCapabilities="true">
        <include domain="database" path="app.db" />
        <include domain="sharedpref" path="settings.xml" />
        <exclude domain="sharedpref" path="auth.xml" />
    </cloud-backup>
    <device-transfer>
        <include domain="database" path="app.db" />
        <include domain="sharedpref" path="settings.xml" />
        <exclude domain="sharedpref" path="auth.xml" />
    </device-transfer>
</data-extraction-rules>

cloud-backupとdevice-transferは別のルール集合です。クラウドだけ除外したい、D2Dでは移したい、という判断もできます。上の例でdisableIfNoEncryptionCapabilities="true"を指定すると、暗号化能力がない場合のクラウドバックアップを止める意図になりますが、D2Dはクラウド送信ではないため扱いが同じではありません。

クラウドバックアップと端末間転送の保存経路、設定差、テスト方針を比較するオリジナル図解
cloud-backupとdevice-transferは別経路として考える

バックアップの実行条件と復元タイミング

Auto Backupは、ユーザーが端末のバックアップを有効にしていること、前回から一定時間が経過していること、端末がアイドルであること、通常はWi-Fi接続中であることなど、複数の条件が整ったときに実行されます。設定直後に必ずクラウドへ保存されるわけではありません。

復元はアプリのインストール時や端末セットアップ時に行われます。ユーザーが選択したバックアップデータセット、Googleアカウント、端末状態、採用されたtransportなどで結果が変わるため、「バックアップ操作が成功した」だけで復元まで保証されたとは判断しないでください。

クラウド上のAuto Backupは、公式説明ではアプリユーザーあたり25MBまでです。容量超過時はクラウドへのバックアップが受け付けられない場合があります。大容量の写真・動画やサーバーで再取得できるデータを無理にAuto Backupへ詰め込まず、独自同期や別の保存方式を検討します。

公式手順に沿ったバックアップ・復元テスト

Android Developersは、クラウドバックアップとD2D転送の両方を、主要リリースごとにテストするよう案内しています。ここでは公式ツールを使った確認の流れを整理します。以下は手順の紹介であり、この環境で実機検証した結果ではありません。

  1. テスト端末またはエミュレーターを用意し、対象API、Googleアカウント、バックアップ設定、ネットワークを確認する。
  2. アプリへサンプルの設定、Roomデータ、SharedPreferences、添付ファイルを入れ、復元前の値を記録する。
  3. adb shell bmgr enable trueなどでテスト環境を準備し、公式手順に沿ってtransportを選ぶ。
  4. adb shell bmgr backupnow com.example.appのように、実際のパッケージ名でバックアップを要求する。
  5. adb logcatでBackup Managerの成功、quota超過、agent timeoutなどを確認する。
  6. テスト端末のデータを消す操作やアンインストールを行い、再インストール時の復元結果を確認する。
  7. 設定値、DBの件数と代表値、ログイン状態、画像、除外したキャッシュが再生成されることを確認する。

アンインストールやデータ消去はテスト端末・テストデータだけで行います。実運用端末で実行しないでください。D2Dは旧端末と新端末の組み合わせを前提にするため、クラウドテストが通っただけでD2Dも通ったとは扱いません。

# パッケージ名はサンプル。自分のアプリに置き換える
adb shell bmgr backupnow com.example.app

# 失敗理由やquotaを確認する
adb logcat
Androidのバックアップ復元が動かないとき、設定、対象データ、実行条件、復元条件を順番に確認する診断フロー
復元できないときは設定だけでなく経路とデータを分けて確認する

復元できないときの診断フロー

症状確認すること対処の方向
バックアップ自体が作られないバックアップ設定、Wi-Fi、アイドル状態、データ量条件を満たすテスト環境で再実行し、logcatを確認
特定ファイルだけ戻らないdomain/path、includeによる範囲限定、exclude対象パスを実際の保存場所と照合
クラウドは戻るがD2Dは戻らないcloud-backupとdevice-transferの別ルールD2D側のinclude/excludeを確認
Room起動時に失敗する復元されたDB schemaとアプリのRoom versionバックアップ設定ではなくMigration pathを確認
ログイン状態だけ戻らないトークンを除外しているか、鍵や期限の仕様再認証・トークン再発行を設計する
quotaやagent timeout25MB上限、バックアップ量、起動時間不要データを除外し、ログの原因に合わせて縮小

診断の順番は、まずどの経路を試しているか、次にXMLの対象範囲、続いて実行条件、最後に復元後のアプリ処理です。復元できない原因をすべてallowBackupだけで説明しようとすると、D2D、quota、Room schemaなど別の問題を見落とします。

Room MigrationとAuto Backupの違い

Auto Backupは、アプリデータを別の端末や再インストール後へ戻すための仕組みです。Room Migrationは、旧バージョンのDB構造を新バージョンのschemaへ変換する仕組みです。

項目Auto BackupRoom Migration
目的データを別の状態・端末へ復元するDB schema変更後も既存DBを開けるようにする
主な対象ファイル、設定、DBなどRoomが管理するSQLite DBの構造とデータ
失敗時の確認transport、ルール、quota、復元条件version、Migration path、schema validation

機種変更とアプリ更新が同時に起きることもあるため、両方をテストします。バックアップでDBが戻っても、新しいRoomが旧DBを扱えなければ起動時に失敗します。

公開前チェックリスト

  • バックアップしたいユーザーデータと除外データを一覧化した
  • cache、code_cache、no_backupを一時データとして扱っている
  • 認証トークン、端末固有ID、暗号鍵、秘密情報を無条件に含めていない
  • Android 11以前用のfullBackupContentを確認した
  • Android 12以降用のdataExtractionRulesを確認した
  • cloud-backupとdevice-transferのルールを別々にレビューした
  • includeを使ったことで必要なデータまで対象外になっていない
  • 25MBのクラウド上限とデータ量を確認した
  • Room schema変更時はMigrationテストも実施した
  • クラウドバックアップとD2D転送をそれぞれテストした
  • テスト端末で復元後のDB、設定、画像、再認証フローを確認した

FAQ

Auto Backupは標準で有効ですか？

Android 6.0（API 23）以降を対象とするアプリでは、Auto Backupは基本的に有効で、android:allowBackupで明示的に制御できます。対象端末、target SDK、メーカー実装による違いがあるため、設定と実機で確認してください。

RoomのDBはバックアップされますか？

RoomのSQLite DBは、保存場所とバックアップルールが対象ならバックアップされ得ます。ただし復元後のschema互換性は別なので、Room Migrationも確認します。

dataExtractionRulesだけ設定すればよいですか？

Android 12以降向けにはdataExtractionRulesを使いますが、Android 11以前もサポートするならfullBackupContentも用意します。

allowBackup=falseならD2Dも必ず止まりますか？

Android 12以降は端末メーカーによって挙動が異なる場合があります。クラウドとD2Dを分け、公式の現行説明と対象端末で確認します。

バックアップが成功すれば復元も成功しますか？

いいえ。バックアップ作成と復元は別工程です。再インストールまたは公式テスト手順を使い、復元後のデータを実際に確認します。

認証トークンもバックアップすべきですか？

別端末へそのまま移す前提にせず、原則として除外と再認証・再発行を検討します。アプリの脅威モデルと認証基盤に合わせて判断してください。

まとめ

Auto Backupは、Androidアプリの設定やローカルデータを機種変更・再インストール後へ戻すためのOS標準機能です。API 23以降で使え、標準対象にはSharedPreferences、内部ファイル、SQLite/Room DBなどが含まれますが、cacheや秘密情報をそのまま保存する仕組みではありません。

Android 12以降はcloud-backupとdevice-transferを分けてdataExtractionRulesを設計し、古い端末向けにはfullBackupContentも確認します。最後はadb、bmgr、logcatでバックアップ作成だけでなく復元まで検証し、Room Migrationや再認証の問題も別軸で確認してください。

参考：Android Developers：Back up user data with Auto Backup、Data backup overview、Test backup and restore、Android 12 behavior changes