69

So I was adding some stuff to my application manifest and I saw that I had a warning on my application tag:

On SDK version 23 and up, your app data will be automatically backed up and restored on app install. Consider adding the attribute android:fullBackupContent to specify an @xml resource which configures which files to backup.

And then I searched up for that. Apparently there are only 2 tags for that: <include> and <exclude>. I don't want to exclude any files from the backup as I don't have any local-depending files, and I don't need any <include> tags as

<include>: Specifies a set of resources to back up, instead of having the system back up all data in your app by default.

When I saw that if I don't put any <include> tags, then the system will back up all data in your app by default, which is exactly what I want.

Now I have this question: should I add the backup_content.xml file, but empty as the default settings are good, or not add the file at all? (in which case Android Studio will complain)

Chaoz
  • 2,119
  • 1
  • 20
  • 39

8 Answers8

59

Fast Solution:

AndroidManifest.xml

<application
    android:allowBackup="true"
    android:fullBackupContent="true"
    ...
    ...
    ...
</application>

For more details see: https://developer.android.com/guide/topics/data/autobackup

user_MGU
  • 978
  • 11
  • 11
  • 3
    have a look at https://medium.com/mindorks/auto-backup-in-android-dont-do-it-unless-you-know-it-cc9fe2f9176b – Zar E Ahmer Nov 16 '18 at 07:13
  • 21
    I don't see anything in the documentation saying you can pass a boolean to `fullBackupContent`. – mhsmith Nov 17 '18 at 15:33
  • What's the difference between them exactly? – android developer Sep 19 '19 at 14:41
  • 1
    @mhsmith I agree, I don't think this answer is right, by default most of the files are backed up so I guess whatever you type instead of "true" the result will be the same (you are supposed to provide an XML file, not a boolean). – Yoann Hercouet Jan 24 '20 at 16:41
  • 3
    There is a Lint Warning "Missing resource" when using android:fullBackupContent="true" – activity May 22 '20 at 07:13
  • 6
    Why was this solution accepted? `android:fullBackupContent` doesn't allow boolean value. –  Dec 12 '20 at 04:17
  • 1
    Don't do this! `android:allowBackup="true"` is a vulnerability! Don't backup your data or any hacker can steal them without root access. – CoolMind Jan 11 '21 at 13:53
  • 1
    @CoolMind your comment is misleading. allowBackup="true" won't allow "any hacker" to steal user data. Backup data is stored safely in an encrypted Google Drive folder. You may be referring to the fact that an attacker with *physical access* to the device and knowledge of your unlock code can get data via adb, _if the device has USB debugging enbabled_ which is a pretty niche scenario. – mchandleraz May 27 '22 at 13:14
  • @mchandleraz, USB debugging is often enabled for experienced users (testers, programmers). Please, read https://stackoverflow.com/questions/12648373/what-is-androidallowbackup, https://securitygrind.com/exploiting-android-backup/. If an application keeps sensitive information, it is not advised to allow backup. The phone may be connected to someone's PC. Some service engineers also can enable USB debugging when customize the device or restore data. – CoolMind May 27 '22 at 13:34
  • @CoolMind So you agree that your original comment was misleading, then? Because you just illustrated why only a small percentage of people will even have USB debugging enabled, the SO link you provided repeatedly agrees with me, and the blog post you shared has nothing about data being stolen. – mchandleraz May 27 '22 at 20:02
  • @mchandleraz, I disagree with you. In these topics it is written that `allowBackup="true"` can lead to stealing sensitive data. And it's not a small percentage. When somebody wants to customize a device or install an apk, he enables USB debugging. I agree only that a hacker must have a physical access to the device. – CoolMind May 28 '22 at 20:31
  • @CoolMind Not every app stores sensitive information and some apps may want to allow the user to easily back up everything, like in my case a simple game that only stores settings and custom maps. Yes, it _could_ be a vulnerability, but it's case-by-case (thus why it's an option in the first place that defaults to `true`) and misleading to make a blanket statement such as "don't do this!" – Pilot_51 Sep 10 '22 at 03:47
  • @Pilot_51, you are right! – CoolMind Sep 11 '22 at 12:12
7

If you want to silence the warnings, but don't need to exclude any files from the backup, you could also just add tools:ignore="AllowBackup" to the application tag in your AndroidManifest.xml to suppress the warning (or use the Suppress button that you get when viewing the warning details).

Hemaolle
  • 1,950
  • 18
  • 21
6

Correct solution:

The warning is because is missing <full-backup-content> resource.

For this we have android:fullBackupContent in the application tag, which points to a XML file that contains full backup rules for Auto Backup. These rules determine what files get backed up.

Example:

<application ...
    android:fullBackupContent="@xml/my_backup_rules">
</application>

Create an XML file called my_backup_rules.xml in the res/xml/ directory. Inside the file, add rules with the <include> and <exclude> elements. The following sample backs up all shared preferences except device.xml:

<?xml version="1.0" encoding="utf-8"?>
<full-backup-content>
    <include domain="sharedpref" path="."/>
    <exclude domain="sharedpref" path="device.xml"/>
</full-backup-content>

References for more information:

https://developer.android.com/guide/topics/data/autobackup https://betterprogramming.pub/androids-attribute-android-allowbackup-demystified-114b88087e3b

Henrique Monte
  • 1,272
  • 1
  • 15
  • 22
3

I also struggled the same question and couldn't find an answer. So for backup all, I tried making a backup.xml file like that:

<?xml version="1.0" encoding="utf-8"?>
   <full-backup-content>

   </full-backup-content>

and it works fine.

EDIT 06/04/21

Just got an official answer from Google IssueTracker:

The answer to your question appears at the beginning of the section titled Include and exclude files: "By default, the system backs up almost all app data". In order to back up all supported data, don't include android:fullBackupContent in your manifest file.

Avital
  • 549
  • 5
  • 15
  • What is between tags? https://medium.com/mindorks/auto-backup-in-android-dont-do-it-unless-you-know-it-cc9fe2f9176b and https://betterprogramming.pub/androids-attribute-android-allowbackup-demystified-114b88087e3b reveal some situations. – CoolMind Mar 22 '21 at 09:30
2

Here are a few tidbits I found here.

The default behaviour on Marshmallow and later for apps that target 23+ is to back everything up

I read that as reason to Suppress the warning, if wanting this behavior.

Auto Backup will by default not restore a backup that was created from a newer version of your app, because it assumes it may not work for you. This might be a problem if your user is migrating to a new device that has an older version of your app preinstalled, because it would mean that nothing is restored.

If you are confident you can handle forward compatibility, you can use android:restoreAnyVersion="true" to override the behaviour.

seekingStillness
  • 4,833
  • 5
  • 38
  • 68
2

you can add android:fullBackupContent="true" in your androidmanifest.xml

behrad
  • 1,228
  • 14
  • 21
1
<application
        android:allowBackup="true"
        android:fullBackupOnly="true">
</application>
ZombieSlayer
  • 11
  • 1
-1

I think when you don't define any exclude or include it makes a full backup.

: Specifies a set of resources to back up, instead of having the system back up all data in your app by default. If you specify an element, the system backs up only the resources specified with this element. You can specify multiple sets of resources to back up by using multiple elements

Laire
  • 1,290
  • 6
  • 22
  • 49
  • 3
    This is exactly what I wrote in my original post, and it doesn't answer anything. My question was whether to do this or not as the file at all. – Chaoz Sep 06 '16 at 12:01