What is "android:allowBackup"?

Question

Since the new ADT preview version (version 21), they have a new lint warning that tells me the next thing on the manifest file (in the application tag):

Should explicitly set android:allowBackup to true or false (it's true by default, and that can have some security implications for the application's data)

In the official website, they've written:

A couple of new checks: you must explicitly decide whether your app allows backups, and a label check. There's a new command line flag for setting the library path. Many improvements to the incremental lint analysis while editing.

What is this warning? What is the backup feature, and how do I use it?

Also, why does the warning tell me it has security implications? What are the disadvantages and advantages of disabling this feature?

---

There are two concepts of backup for the manifest:

• "android:allowBackup" allows to backup and restore via adb, as shown here:

Whether to allow the application to participate in the backup and restore infrastructure. If this attribute is set to false, no backup or restore of the application will ever be performed, even by a full-system backup that would otherwise cause all application data to be saved via adb. The default value of this attribute is true.

This is considered a security issue because people could backup your app via ADB and then get private data of your app into their PC.

However, I think it's not that of a problem, since most users don't know what adb is, and if they do, they will also know how to root the device. ADB functions would only work if the device has the debugging feature enabled, and this needs the user to enable it.

So, only users that connect their devices to the PC and enable the debugging feature would be affected. If they have a malicious app on their PC that uses the ADB tools, this could be problematic since the app could read the private storage data.

I think Google should just add a feature that is disabled by default, in the developer category, to allow backup&restore of apps via ADB.

• "android:backupAgent" allows to use the backup and restore feature of the cloud, as shown here and here:

The name of the class that implement's the application's backup agent, a subclass of BackupAgent. The attribute value should be a fully qualified class name (such as, "com.example.project.MyBackupAgent"). However, as a shorthand, if the first character of the name is a period (for example, ".MyBackupAgent"), it is appended to the package name specified in the element. There is no default. The name must be specified.

This isn't a security issue.

Groschen

I think you should remove that additional info in your Edit, because that is referring to the Backup cloud service, instead of the ADB backup tool that this issue is actually referencing (as per Tor Norbye's answer) – Zannini

@Turbo yes you are correct. i think it wasn't updated this much when i've read it, but now it's clear. i will update the question . thanks. i wonder if the adb backup feature can be used on rooted devices even for apps that have set it to false. – Groschen

Look at BackupManager doc: developer.android.com/reference/android/app/backup/… It totally mentions android:allowBackup!!! – T

@T so i'm totally confused right now. why did they mention it in 2 totally different features? is it possible that the same flag is responsible for both features? or maybe it's a mistake ? do you think i should untick the answer i've ticked? – Groschen

@androiddeveloper we'll that's definitely confusing. I'm hoping it is a doc mistake, which wouldn't be too surprising. And I also have the same question concerning rooted devices (i'm leaning toward the attribute having no affect, i.e. can't stop rooted devices). Maybe we can get answers on G+ or Groups... – Zannini

I think that the lint warning in your situation has to do with allowing backup of app contents on the device. I doubt that this lint warning pertains to cloud backup with BackupManager... – T

@T yes that was my logic too. after seeing both possible features , i assumed that the first one that i've noticed (which is the backupManager) don't really have a security risk that i can think of, but i still don't understand how come the same exact attribute exists on both features. – Groschen

@androiddeveloper The reason that the same exact attribute exists on both features is probably because it is intended for the same ultimate purpose: backing up data. Whether on the device or in the cloud... – T

@T but each of them says a different thing, and is related to a different way the backup works. therefore, it's very confusing and if you read only from one of the places you could think it's related to it alone. – Groschen

tutorialspoint.com/android/android_data_backup.htm – Venturous

As an Android user I'd like to weigh in for anyone finding this, and say that I can't stand apps - and there are many - that disable backup. If a person has access to an unlocked phone, they should be able to copy data off of it. Any "security" measure at that point is meaningless, as they could always root the phone to get the data. But as a user, being able to back up my app data (without rooting and tripping my Knox bit) is hugely valuable. It's really frustrating that so many apps disallow it, and honestly that Android even has this switch at all. – Ogbomosho

Answer 1

For this lint warning, as for all other lint warnings, note that you can get a fuller explanation than just what is in the one line error message; you don't have to search the web for more info.

If you are using lint via Eclipse, either open the lint warnings view, where you can select the lint error and see a longer explanation, or invoke the quick fix (Ctrl-1) on the error line, and one of the suggestions is "Explain this issue", which will also pop up a fuller explanation. If you are not using Eclipse, you can generate an HTML report from lint (lint --html <filename>) which includes full explanations next to the warnings, or you can ask lint to explain a particular issue. For example, the issue related to allowBackup has the id AllowBackup (shown at the end of the error message), so the fuller explanation is:

$ ./lint --show AllowBackup
AllowBackup
-----------
Summary: Ensure that allowBackup is explicitly set in the application's
manifest

Priority: 3 / 10
Severity: Warning
Category: Security

The allowBackup attribute determines if an application's data can be backed up and restored, as documented here.

By default, this flag is set to true. When this flag is set to true, application data can be backed up and restored by the user using adb backup and adb restore.

This may have security consequences for an application. adb backup allows users who have enabled USB debugging to copy application data off of the device. Once backed up, all application data can be read by the user. adb restore allows creation of application data from a source specified by the user. Following a restore, applications should not assume that the data, file permissions, and directory permissions were created by the application itself.

Setting allowBackup="false" opts an application out of both backup and restore.

To fix this warning, decide whether your application should support backup and explicitly set android:allowBackup=(true|false)

Click here for More information

Inquiline

users usually don't even know what is adb , and if they do , they probably know how to root their device and get the data by themselves anyway , no ? – Groschen

@Tor When you say "copy application data off of the device", do you mean copy from data/data/com.myapp or from sdcard? The former directory is protected and cannot be read unless the device is rooted. – T

So for clarification this backup that Lint is referencing is the ADB tool, and not the cloud backup service, correct? Seems a lot of the other answers are getting that confused. – Zannini

@T i think that using ADB will copy the private data, and that's why there is a warning. i think only people that have the debugging feature enabled and connect their device to the PC are affected. such people are usually power users or developers, so they should know what they are doing. the security risk is for people who did it by mistake and installed a malicious app on the PC that uses the ADB tool to make those operations. there is an app for backup&restore without root, called "Helium" : play.google.com/store/apps/… – Groschen

"If you are using lint via Eclipse.." you should probably migrate to AndroidStudio since the ADT Plugin is deprecated. – Bogosian

Answer 2

Here is what backup in this sense really means:

Android's backup service allows you to copy your persistent application data to remote "cloud" storage, in order to provide a restore point for the application data and settings. If a user performs a factory reset or converts to a new Android-powered device, the system automatically restores your backup data when the application is re-installed. This way, your users don't need to reproduce their previous data or application settings.

~Taken from http://developer.android.com/guide/topics/data/backup.html

You can register for this backup service as a developer here: https://developer.android.com/google/backup/signup.html

The type of data that can be backed up are files, databases, sharedPreferences, cache, and lib. These are generally stored in your device's /data/data/[com.myapp] directory, which is read-protected and cannot be accessed unless you have root privileges.

UPDATE: You can see this flag listed on BackupManager's api doc: BackupManager

T

I think the changes in API level 23 point to this being the correct answer. Here's the training docs for the changes: developer.android.com/training/backup/autosyncapi.html – Galenic

Answer 3

This is not explicitly mentioned, but based on the following docs, I think it is implied that an app needs to declare and implement a BackupAgent in order for data backup to work, even in the case when allowBackup is set to true (which is the default value).

http://developer.android.com/reference/android/R.attr.html#allowBackup http://developer.android.com/reference/android/app/backup/BackupManager.html http://developer.android.com/guide/topics/data/backup.html

Anam

what if the app doesn't have anything related to the backupAgent? will android backup its data automatically nevertheless ? – Groschen

the correct answer is found in here: https://mcmap.net/q/99809/-what-is-quot-android-allowbackup-quot . it seems that it has nothing to do with the backupAgent. i've also updated my question to show what it's all about. – Groschen

Answer 4

It is privacy concern. It is recommended to disallow users to backup an app if it contains sensitive data. Having access to backup files (i.e. when android:allowBackup="true"), it is possible to modify/read the content of an app even on a non-rooted device.

Solution - use android:allowBackup="false" in the manifest file.

You can read this post to have more information: Hacking Android Apps Using Backup Techniques

Glorify

are you serious with this answer in 2017? please read it here developer.android.com/guide/topics/data/… – Parabasis

You can disable backups by setting android:allowBackup to false. You might want to do this if your app can recreate its state through some other mechanism or if your app deals with sensitive information that Android shouldn't back up. – Roxanaroxane

Currently you can exclude sensitive data from backups via attribs in manifest. – Emmert

Answer 5

Auto Backup for Apps automatically backs up a user's data from apps that target and run on Android 6.0 (API level 23) or higher.

Android preserves app data by uploading it to the user's Google Drive, where it's protected by the user's Google account credentials.

The backup is end-to-end encrypted on devices running Android 9 or higher using the device's PIN, pattern, or password.

Backup data is stored in a private folder in the user's Google Drive account, limited to 25 MB per app.

The documentation says 25 mb per user, but I think this is a mistake.

Note :

@androiddeveloper pointed out that there is already a topic about this. Bug - Issue Link

Source

Dittography

Isn't it 25 MB per app? Where can I find a sample of performing the backup, including checking how much space is left in the backup and be able to remove items from the backup? – Groschen

yes per app 25 mb. I don't have a clear answer to your second question, but I can make a guess. I think you can access Google Drive and get capacity information. If there is Google Drive API support. – Pissarro

Please check . I can't find much information about how to implement such a thing. Maybe this is why many apps just don't have a backup. BTW, the reason I wrote "per app" is because you wrote "25 MB per user". – Groschen

Backup data is stored in a private folder in the user's Google Drive account, limited to 25 MB per app. However, in the documentation it is also specified as 25 MB per user. developer.android.com/guide/topics/data/autobackup?hl=en – Pissarro

I think it's a mistake. They mention this indeed for "user" and "app". Doesn't make sense. Reported here: issuetracker.google.com/issues/307323843 . Please consider starring. Also if you know how to implement this well, please update the answer. Maybe you know of a nice sample to show how it's done? – Groschen

To be honest I don't have an example. But I updated my answer as much as I could. Your support will be appreciated. I think we found a bug. :) – Pissarro

@androiddeveloper i shared linkedin post. linkedin.com/posts/… – Pissarro

Answer 6

Here you can see android official doc

https://developer.android.com/reference/android/R.attr#allowBackup

Gutbucket