The android:allowBackup flag decides whether Android backs up your app's data, and left at its permissive default it can let someone extract that data off the device. Backup sounds harmless, even helpful, but for an app holding tokens, local databases, or other sensitive files, an unrestricted backup is a way for those files to leave the device through a backup transfer or, on some setups, an adb backup. Here is what the flag does, when it is a risk, and how to keep sensitive data out of backups.
Short answer
android:allowBackup controls whether Android includes your app's data in its backup and transfer mechanisms. Per Android's data backup documentation, when it is enabled, your app's local data can be backed up and restored, which is convenient but means sensitive files can leave the device through a backup or device transfer. For an app holding tokens, credentials, or sensitive local data, set android:allowBackup="false", or keep backup enabled but exclude the sensitive files using backup rules. The safe default for sensitive apps is to not back up data that should never leave the device, so it cannot be extracted from a backup.
What you should know
- It governs app-data backup: whether your data is included in backups and transfers.
- Enabled means data can leave: through a backup or device transfer.
- Sensitive data is the concern: tokens, databases, and credentials.
- Disable or exclude: set it false, or use backup rules to exclude files.
- Do not rely on it alone: also store secrets in encrypted, proper storage.
What does allowBackup do?
It tells Android whether your app participates in the system backup and restore mechanisms. When allowBackup is enabled, Android can include your app's data in its backup system and restore it, including to a new device during transfer, and on some configurations the data can be pulled with an adb backup. When it is disabled, your app's data is excluded from those mechanisms. The flag exists for a good reason, seamless restore is a nice user experience, but it has a security dimension, because anything backed up is data that can exist outside the device you stored it on. So allowBackup is the switch that decides whether your app's local data is portable beyond the device, which matters as soon as that data is sensitive.
When is allowBackup a risk?
When sensitive data is backed up and can be extracted. The table weighs it.
| App data | allowBackup risk |
|---|---|
| Only non-sensitive preferences | Low; backup is harmless |
| Auth tokens or credentials on device | High; they can leave via backup |
| A local database of personal data | High; the database can be extracted |
| Cached sensitive content | Medium to high; depends on sensitivity |
| Nothing stored locally that is sensitive | Low; little to expose |
The risk concentrates wherever your app keeps sensitive data locally. If a token, a credentials store, or a database of personal information is included in a backup, that backup becomes a copy of sensitive data outside the device, which an attacker with access to the backup, or to a device that allows adb backup, could read. For an app with no sensitive local data, backup is harmless, which is why the decision depends on what your app actually stores.
How do you control backup safely?
Disable backup for sensitive apps, or exclude the sensitive parts. The simplest safe option for an app holding sensitive local data is android:allowBackup="false", which keeps that data out of Android's backup entirely. If you want backup for the user's convenience but have specific sensitive files, keep backup enabled and use Android's backup rules to exclude those files, so the harmless data is backed up and the sensitive data is not. Pair either approach with proper storage: secrets should be in encrypted storage like the Keystore-backed mechanisms rather than a plain file, so backup is not your only line of defense. The principle is that data which should never leave the device should be both excluded from backup and stored securely, not protected by one control alone.
What to watch out for
The first trap is leaving allowBackup at a permissive default without considering what your app stores, so a sensitive database or token store ends up in backups. The second is disabling backup but still keeping secrets in plain storage, since backup is only one exposure path; use encrypted storage too. The third is forgetting that backup rules let you keep convenience for non-sensitive data while excluding the sensitive files. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK or AAB against OWASP MASVS and surfaces your allowBackup setting and how the app stores data, so you can confirm sensitive data is not exposed through backup before you ship. Setting the flag and the storage correctly is the fix.
What to take away
android:allowBackupcontrols whether your app's data is included in Android's backup and transfer, so enabled means sensitive data can leave the device.- The risk concentrates where your app stores tokens, credentials, or a database of personal data locally.
- Set
allowBackup="false"for sensitive apps, or keep backup on and exclude the sensitive files with backup rules. - Combine that with encrypted storage so backup is not your only protection, and use a pre-submission scan such as PTKD.com to confirm your backup and storage settings.
