Apps with application backup enabled

What this finding means

android:allowBackup controls whether Android includes an app's private data in platform backups. Setting it to true puts the app's files into device-to-device transfers and Google's cloud backup.

We record this in 2,464 apps, and we do not subtract anything from their score for it. The reason is calibration: backup is enabled by default on Android, so an app that states it explicitly is describing the platform default rather than making an unusual choice. Penalising the majority of apps for a default would make the grade less informative, not more.

Why it is still worth knowing

Backup becomes a real concern when the data being backed up should not leave the device. Authentication tokens, cached personal data, encryption material and anything subject to a retention commitment are all poor candidates for inclusion in a cloud backup that the user, not the app, controls.

On older or developer-enabled devices, adb backup could extract that data over USB from an app with this flag set. Modern Android has narrowed this considerably, which is part of why the finding is informational rather than scored.

How to decide what to do

• If the app holds credentials, tokens or regulated personal data, set android:allowBackup="false".
• If backup is genuinely useful to users, keep it and use a BackupAgent or android:fullBackupContent to exclude the files that should never leave the device.
• Treat anything under a retention or deletion commitment as excluded by default: a backup copy outlives the deletion you promised.
• Do not set it to false reflexively. Losing a user's data on device migration is a real cost, and for many apps the backup is the feature.

How we detect it

The manifest is read directly; there is no inference. Because backup is the platform default, absence of the attribute is not reported — only an explicit true is, and only as a fact on the record rather than a deduction from the grade.