Users often invest significant time and effort creating an identity,
adding data, and customizing settings and preferences within your app.
Preserving this data and personalization for users when they upgrade to a
new device or re-install your app is an important part of ensuring a
great user experience. This page describes what data to back up and
the backup options available to you.

## Select which data to back up

![Identity and account data, settings data, and app data on a device.](https://developer.android.com/static/guide/topics/data/images/restore-data.png)


**Figure 1.**Make sure you restore identity data, app data, and settings
data for users returning to your app.

Users generate a lot of data when using your apps. Take care to
back up the appropriate data---only backing up some of the data can
frustrate users when they open the app on a new device and discover something
missing. The important data to back up for your users is their identity data,
user-generated app data, and settings data, as described below.

### Identity data

You can help maintain existing user engagement by transferring the
user's account when they get started with a new device.

- For details on transferring authentication credentials and authorization tokens,
  see [Block Store](https://developers.google.com/identity/blockstore/android).

- To explore Google sign-in solutions to facilitate user login to your app, see
  [Google Identity](https://developers.google.com/identity).

### App data

App data can include user-generated content, such as text, images, and
other media. You can synchronize app data between Android-powered devices and
save data that you want to use during the normal app lifecycle. You can also
restore a returning user's data onto a new device.
To learn how, see [Transfer data using sync
adapters](https://developer.android.com/training/sync-adapters).

### Settings data

Make sure you also back up and restore settings data to preserve
a returning user's personalized preferences on a new device. You can
restore settings data even if a user doesn't log in to your app. You can
back up settings that a user explicitly sets in your app's UI, as well as
transparent data, such as a flag indicating whether a user has seen a
setup wizard.
| **Note:** Any permissions a user grants to your app are automatically backed up and restored by the system on devices running Android version 7.0 (API level 24) and higher. However, if a user uninstalls your app, then the system clears any granted permission and the user must grant them again.

To preserve as much of an existing user's experience on a new device as
possible, make sure you back up the following user settings:

- Any settings modified by the user, for example when using the Jetpack
  [Preference library](https://developer.android.com/reference/androidx/preference/package-summary).

- Whether the user has turned notifications and ringtones on or off.

- Boolean flags that indicate whether the user has seen welcome screens or
  introductory tooltips.

![Transfer of settings from one mobile device to another.](https://developer.android.com/static/guide/topics/data/images/restore-settings.png)


**Figure 2.**Restoring settings on new devices helps ensure a great user
experience.

<br />

Avoid backing up URIs, because they
can be unstable. In some cases a restoration to a new mobile device can result
in an invalid URI that does not point to a valid file. One example of this is
using URIs to save a user's ringtone preference. When the user reinstalls the
app, the URI might point to no ringtone or to a different ringtone from the one
intended. Instead of backing up the URI, you can instead back up some metadata
about the setting, such as a ringtone title or a hash of the ringtone.

## Backup options

Android provides two ways for apps to back up their data to the cloud:
[Auto Backup for Apps](https://developer.android.com/guide/topics/data/autobackup) and [key-value
backup](https://developer.android.com/guide/topics/data/keyvaluebackup). Auto Backup, which is available on
Android version 6.0 and higher, preserves data by uploading it to the user's
Google Drive account. Auto Backup [includes
files](https://developer.android.com/guide/topics/data/autobackup#Files) in most of the directories that are
assigned to your app by the system. Auto Backup can store up to 25 MB of
file-based data per app. The key-value backup feature (formerly known as the
Backup API and the Android Backup Service) preserves settings data in the form
of key-value pairs by uploading it to the Android Backup Service.

Generally, we recommend Auto Backup because it's enabled by default and requires
no work to implement. Apps that target Android version 6.0 or higher are
automatically enabled for Auto Backup. The Auto Backup feature is a file-based
approach to backing up app data. While Auto Backup is simple to implement,
consider using the key-value backup feature if you have more specific needs
for backing up data.
| **Note:** If your app doesn't have a backup mechanism for app contents and the size of your app contents is unlikely to exceed the 25 MB limit, then Auto Backup may be sufficient for your needs.

The following table describes some of the key differences between
key-value backup and Auto Backup:

| Category | Key-value backup (Android Backup Service) | Android Auto Backup |
|---|---|---|
| Supported versions | Android 2.2 (API level 8) and higher. | Android 6.0 (API level 23) and higher. |
| Participation | Disabled by default. Apps can opt in by [declaring a backup agent](https://developer.android.com/guide/topics/manifest/application-element#agent). | Enabled by default. Apps can opt out by [disabling backups](https://developer.android.com/guide/topics/data/autobackup#EnablingAutoBackup). |
| Implementation | Apps must implement a [BackupAgent](https://developer.android.com/reference/android/app/backup/BackupAgent). The backup agent defines what data to back up and how to restore data. | By default, Auto Backup includes almost all of the app's files. You can use XML to [include and exclude files](https://developer.android.com/guide/topics/data/autobackup#IncludingFiles). Internally, Auto Backup relies on a backup agent that is bundled into the SDK. |
| Frequency | Apps must issue a request when there is data that is ready to be backed up. Requests from multiple apps are batched and executed every few hours. | Backups happen automatically, roughly once a day. |
| Transmission | Backup data can be transmitted using Wi-Fi or cellular data. | Backup data is transmitted using Wi-Fi by default, but the device user can turn on mobile-data backups. If the device is never connected to a Wi-Fi network or the user doesn't change their mobile-data backup settings, then Auto Backup never occurs. |
| Transmission conditions | [Define device conditions](https://developer.android.com/guide/topics/data/autobackup#define-device-conditions) required for backup in [`onBackup()`](https://developer.android.com/reference/android/app/backup/BackupAgent#onBackup(android.os.ParcelFileDescriptor,%20android.app.backup.BackupDataOutput,%20android.os.ParcelFileDescriptor)). | [Define device conditions](https://developer.android.com/guide/topics/data/autobackup#define-device-conditions) required for backup in XML file, if using the default backup agent. |
| App shut down | Apps are not shut down during backup. | The system shuts down the app during backup. |
| Backup storage | Backup data is stored in Android Backup Service and limited to 5 MB per app. Google treats this data as personal information in accordance with Google's [Privacy Policy](https://www.google.com/privacypolicy). | Backup data is stored in the user's Google Drive limited to 25 MB per app. Google treats this data as personal information in accordance with Google's [Privacy Policy](https://www.google.com/privacypolicy). |
| User login | Doesn't require a user to be logged into your app. The user must be logged into the device with a Google Account. | Doesn't require a user to be logged into your app. The user must be logged into the device with a Google Account. |
| API | Related API methods are entity-based: - [onBackup()](https://developer.android.com/reference/android/app/backup/BackupAgent#onBackup(android.os.ParcelFileDescriptor, android.app.backup.BackupDataOutput, android.os.ParcelFileDescriptor)) - [onRestore()](https://developer.android.com/reference/android/app/backup/BackupAgent#onRestore(android.app.backup.BackupDataInput, int, android.os.ParcelFileDescriptor)) | Related API methods are file-based: - [onFullBackup()](https://developer.android.com/reference/android/app/backup/BackupAgent#onFullBackup(android.app.backup.FullBackupDataOutput)) - [onRestoreFile()](https://developer.android.com/reference/android/app/backup/BackupAgent#onRestoreFile(android.os.ParcelFileDescriptor, long, java.io.File, int, long, long)) |
| Data restore | Data is restored when the app is installed. If needed, you can request a manual restore. | Data is restored when the app is installed. Users can select from a list of backup datasets if multiple datasets are available. |
| Documentation | [Back up key-value pairs with Android Backup Service](https://developer.android.com/guide/topics/data/keyvaluebackup) | [Back up user data with Auto Backup](https://developer.android.com/guide/topics/data/autobackup) |

For more information about how backup and restore works for each service,
see [Test backup and restore](https://developer.android.com/guide/topics/data/testingbackup).
| **Note:** If Wi-Fi isn't available, key-value backup might use mobile data. Key-value backup therefore isn't typically suitable for app data contents, such as media, downloaded files, and caches, unless the amount of data is very small.