If you’ve ever been sky diving, you know that it’s essential to prepare for redundancies in your jump. That way, if one shoot fails you have a spare as your backup. This philosophy isn’t left behind within android and this is accomplished using allowBackup, which helps automatically backing up application data.

allowBackup Purpose

According to the documentation, this feature allows Auto Backup for App automatically backs up a user’s data from apps that target and run on Android 6.0 (API level 23) or later. This can be accomplished in your android app so the user(s) can more quickly recover the data. This feature allows the user to delete the application using any method such as manually deleting/uninstalling the app to using the device “factory reset”, regardless of the method the app will retain the user data when they decide to reinstall. This feature is taken a step further across multiple devices which allows the user to get a new device and this information will be available for a new device.  

How Much Data?

When implemented the user can store the data limited to 25MB, which persists across the lifetime of an app being installed on your device. Though that does not sound like a lot in reality it is more than enough to save preferences/settings.

Where Is It Stored?

This data is stored by uploading it to the user’s Google Drive, where it is protected but the user’s account credentials. Don’t worry this data is stored in a private folder on the user’s drive and doesn’t count towards the user’s personal Drive quota. 

Note: Only the most recent backup is stored in the drive. 

What is Being Backed Up

The default function of this feature includes files in most directories that are assigned within your app by the system:

• shared preferences
• getFilesDir() or getDir(String, int)
  • Files stored in the app internal storage
• getDatabasePath(String)
  • Files within this directory
• getExternalFilesDir()
  • Files on external storage within this directory

So in short you can configure the application to include as well as exclude any files.

Customizing Your Backup

Within the android manifest, ensure that you add android:fullBackupContent within your application block. This points to an XML file that should contain all the rules for the full backup for the Auto Backup. Follow these steps and you can accomplish the task:

• within the res directory create a directory called xml
  • now create an XML file called auto_backup_rules.xml
• Use the syntax include/exclude
  • if you use both include/exclude the include tag supersede
  • The path reference within the include and exclude refers to the resource location
    • Example: <include domain="database" path="test_db.db"
• The backup file should be listed in Android Manifest
  • Example: <application android:fullBackupContent="@xml/auto_backup_rules ... >

Triggering the Backup

Backups are triggered automatically when any of the following conditions are met:

• backup must be enabled by the user. From Android 9 this setting is within Setting> System > Backup
• 24 hours has elapsed since the last backup
• The device is not  in use
• The device is connected to a stable Wi-Fi network

Should Backups Cause Problem

Android backups rely on the Android Debug Bridge (ADB) command to perform backup and restore. ADB, however, has been a soft target for hackers and is still not trusted by respected developers. The idea that someone can inject malicious code into your backup data is unsettling, to say the least. This generally isn’t a problem for end-users as it requires debugging to be enabled on the device, but since a lot of Android users are fond of exploring and rooting their devices, it can become a serious problem.

Once backed up, all application data can be read by the user. adb restore allows the 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.

Therefore, applications that handle and store sensitive information such as card details, passwords, etc., should have this setting explicitly set to false — by default, it is set to exclude — to prevent such risks, or you can also customize what needs to be backed up.

If there is anything that is missing or being overlooked please do not hesitate to comment so we can all learn.