android:allowBackup: what it backs up and when to turn it off

Open almost any Android manifest and you will find android:allowBackup="true", often added by a project template and never looked at again. Leave it out and the effect is the same: on Android, app data backup is on by default. For many apps that is fine, even helpful. For an app that keeps login tokens, health data or payment details on the device, it deserves a decision.

This guide explains what Android backs up, where it goes, what changed in Android 12, and how to set it up so users keep the data they expect and lose nothing they should not carry around.

What Auto Backup copies

Since Android 6.0 (API level 23), Auto Backup saves an app's data to the user's Google Drive, up to 25 MB per app, when the phone is idle, charging and on Wi-Fi. When the user sets up a new phone or reinstalls the app, the data is restored. By default it includes:

• Shared preferences.
• Files in the app's internal storage (getFilesDir()).
• Databases (getDatabasePath()).
• Files in external app specific storage.

It leaves out the cache folders and getNoBackupFilesDir(). A second path, device to device transfer, copies the same kind of data when a user moves to a new phone with a cable or over Wi-Fi.

Why it can be a problem

Think about what your app writes to shared preferences and its database. Common examples:

• An OAuth refresh token or session cookie. Restored on another device, the user may be signed in where your server never expected them to be, and some auth flows treat a restored token as a cloned session.
• A device bound key or an identifier your fraud checks rely on. A restored copy on a second phone looks like the same device.
• Cached personal data: messages, health records, documents. It now also lives in a backup the user may not think about.

Tokens protected with a key from the Android Keystore are less of an issue, because the key itself is not backed up and the restored ciphertext cannot be decrypted on another device. But that also means the restored data is broken, which is its own bug: users on a new phone see crashes or odd sign in loops. Either way, it should be a decision, not a default.

In the OWASP MASVS, this is part of MASVS-STORAGE: sensitive data should not leak through backups.

What changed in Android 12

Android 12 (API level 31) added a new attribute, android:dataExtractionRules, with separate sections for cloud backup and device to device transfer. Two details catch people out:

• For apps that target API 31 or higher, android:allowBackup="false" still turns off cloud backup, but it no longer turns off device to device transfer. To control that, use dataExtractionRules.
• The older android:fullBackupContent rules still apply on Android 11 and lower. If you support those versions, keep both.

Also since Android 12, adb backup leaves out app data for apps that target API 31 or higher, unless the build is debuggable. That is one more reason never to send a debuggable build outside the team.

Three sensible setups

1. Back up nothing

For banking, health and enterprise apps where everything sensitive comes from the server anyway:

<application
    android:allowBackup="false"
    android:dataExtractionRules="@xml/data_extraction_rules"
    android:fullBackupContent="false">

With res/xml/data_extraction_rules.xml excluding everything in both sections:

<data-extraction-rules>
  <cloud-backup>
    <exclude domain="root" path="." />
    <exclude domain="file" path="." />
    <exclude domain="database" path="." />
    <exclude domain="sharedpref" path="." />
    <exclude domain="external" path="." />
  </cloud-backup>
  <device-transfer>
    <exclude domain="root" path="." />
    <exclude domain="file" path="." />
    <exclude domain="database" path="." />
    <exclude domain="sharedpref" path="." />
    <exclude domain="external" path="." />
  </device-transfer>
</data-extraction-rules>

2. Back up settings, not secrets

For most consumer apps. Keep user preferences such as theme and language, leave out the auth store and caches:

<data-extraction-rules>
  <cloud-backup>
    <include domain="sharedpref" path="settings.xml" />
  </cloud-backup>
  <device-transfer>
    <include domain="sharedpref" path="settings.xml" />
  </device-transfer>
</data-extraction-rules>

Once you list an include, only the listed files are backed up. Mirror the same rule in a fullBackupContent file for Android 11 and lower.

3. Keep the default on purpose

A game, a notes app with no account, an offline tool: users will thank you for restoring their data. Then leave backup on, but move anything token like to getNoBackupFilesDir() or to an encrypted store tied to the Keystore.

How to test it

1. Install the build on a test phone and use it until it has real data.
2. Run adb shell bmgr backupnow your.package.name to force a backup.
3. Uninstall the app and install the same build again. Auto Backup restores the data during the install.
4. Check what came back, and that signing in again works cleanly when the token is not restored.

This needs a backup transport on the phone, usually a Google account signed in with backup turned on.

Catching it on every build

The manifest you edit is not always the one that ships. Libraries merge their own attributes, and a build variant can override the value. Check the merged manifest of the built APK, not the source file.

AppForShare reads the manifest of every uploaded APK, including APKs made from an .aab. The security scan shows a warning when app data is backed up, either because allowBackup is on or because it is not set, and the build has neither dataExtractionRules nor fullBackupContent. Builds that have rules pass, because the rules show someone made the decision. The finding carries the MASVS-STORAGE category and the fix, and the docs list the other Android checks: exported components, user added certificates, debuggable builds and plain HTTP.

Free accounts see the counts; Pro and Team see the findings and can fail a pipeline on them with appforshare security --fail-on warn. It is a static read of the manifest, so it cannot tell what your app writes at runtime. Only you know whether that data is sensitive.

Common questions

Does Google Play reject apps with allowBackup on?

No. It is a normal setting. Security reviews and scanners flag it because it is easy to leave on without thinking about it.

Is the backup encrypted?

Google encrypts backups, and on recent Android versions with a screen lock set, they are encrypted with a key tied to the user's lock screen. That protects against others reading the backup, but it does not stop your own data from being restored to another device.

We set allowBackup to false. Are we done?

Not quite. If you target API 31 or higher, device to device transfer still copies data unless dataExtractionRules excludes it. The scan does not warn about an explicit allowBackup="false", so this one is up to you: add the rules file.

For the other items to check before a build leaves your desk, read security checks before you share an IPA or APK and exported Android components. To see the backup check on your own build, create a free account and upload an APK.