How to Test App Backup and Restore on Android Using ADB bmgr

Modern Android applications rely heavily on Android Backup Service (Auto Backup) and Key/Value Backup to preserve user data, account sessions, and custom preferences across device migrations and factory resets. However, testing backup and restore behaviour manually can take days because the Android operating system schedules cloud sync jobs unpredictably during device idle and charging windows. The Android Debug Bridge (ADB) bmgr (Backup Manager) tool allows developers and power users to force immediate backup passes, inspect backup transports, and simulate restore events directly from the command line.

Understanding the Android Backup Manager (bmgr)

The Android framework manages application data persistence through the BackupManager service. Two primary backup mechanisms exist in Android:

• Auto Backup for Apps (File-Based): Automatically saves all application files, databases, and shared preferences up to 25 MB per app directly to the user’s Google Drive storage quota without custom code.
• Key/Value Backup: Requires an explicit BackupAgent implementation where apps serialize specific key-value pairs to the cloud.

In standard operation, Android enforces strict rate limits and only initiates backups when the device is idle, connected to Wi-Fi, and plugged into a power source. The bmgr command-line utility bypasses these scheduling constraints by sending control directives directly to the underlying backup system service, enabling real-time validation of backup rules, XML inclusions, and data exclusions.

Verifying ADB Connectivity and Enabling the Backup Service

Ensure your Android device has USB Debugging enabled in Developer Options and is connected to your workstation via USB or Wi-Fi debugging. Open a terminal or PowerShell prompt and check connected devices:

adb devices

Once your device is authorized, verify that the Android Backup Manager service is active on the operating system:

adb shell bmgr enabled

If the command outputs Backup Manager is enabled, the service is operational. If it returns disabled, activate the service manually:

adb shell bmgr enable true

Inspecting and Selecting the Active Backup Transport

Backup data is routed to a target transport provider, such as Google Cloud Services or a local test environment. To list all available transports installed on the device, run:

adb shell bmgr list transports

The output typically presents multiple transport options with an asterisk indicating the currently selected active transport:

    android/com.android.internal.backup.LocalTransport
  * com.google.android.gms/.backup.BackupTransportService

For testing cloud synchronisation against real Google accounts, the com.google.android.gms/.backup.BackupTransportService transport should be active. If you need to switch to a specific transport, execute:

adb shell bmgr transport com.google.android.gms/.backup.BackupTransportService

Scheduling and Forcing an Immediate Backup Pass

To back up an application, the operating system must first mark the package as having pending changes. Use the backupnow command, which automatically schedules the package and executes an immediate backup pass without waiting for daily maintenance windows.

To run an immediate backup for a specific application package (for example, com.example.myapp), execute:

adb shell bmgr backupnow com.example.myapp

The terminal will stream real-time logging from the backup manager:

Running incremental backup for 1 requested packages.
Package @pm@ with result: Success
Package com.example.myapp with result: Success
Backup finished with result: Success

The @pm@ package represents the Android Package Manager metadata, which stores app permissions and installation state. A Success response confirms that the app data payload was packaged and uploaded to the transport.

Simulating an Application Restore Operation

Testing that backed-up data restores correctly requires triggering a restore event. Android supports testing restore operations without wiping the physical device or uninstalling the application.

To trigger a restore of the app’s most recent backup token, run the restore sub-command:

adb shell bmgr restore com.example.myapp

Alternatively, you can test a full reinstallation cycle. Clear the app’s local storage to simulate a fresh installation or wipe:

adb shell pm clear com.example.myapp

Then execute the restore pass to verify that your critical shared preferences and local database files are populated back into /data/data/com.example.myapp/:

adb shell bmgr restore com.example.myapp

Launch the application on the device. All preserved user login states, custom settings, and cache flags defined in your backup rules should immediately reflect their restored condition.

Wiping Backup Data for Clean Testing Cycles

When refining backup rules—such as updating backup_rules.xml to exclude cache directories, sensitive encryption keys, or large media folders—historical cloud data must be wiped to avoid testing against obsolete payloads.

To clear an application’s remote backup dataset from the active transport, execute:

adb shell bmgr wipe com.google.android.gms/.backup.BackupTransportService com.example.myapp

The transport clears the stored records for that package. You can now rebuild your application, generate fresh local test data, and run bmgr backupnow to audit the updated rule set.

Debugging Backup Failures and Inspecting System Logs

If bmgr backupnow outputs a result other than Success (such as Package not eligible for backup or Transport rejected package), check the system event logs for detailed diagnostic explanations.

Filter logcat specifically for backup-related system events:

adb logcat -s BackupManagerService PFTBT BackupTransport

Common issues identified by logcat include:

• allowBackup=”false”: The app manifest disables backup entirely. Set android:allowBackup="true" in AndroidManifest.xml.
• Size Limit Exceeded: Auto Backup exceeds the 25 MB quota per package. Audit heavy databases and add <exclude domain="database" ... /> rules.
• Device Not Provisioned: New virtual emulators without Google Play services need account setup before cloud transports can accept payloads.

Using bmgr directly within your development and continuous integration pipelines ensures that data migration, user retention, and device switching operate reliably across all modern Android releases.