Implement Auto Backup API in Android

In today’s high-tech world data is the biggest significance. For most of us nowadays, data loss is a nightmare. Backing up data, whether it’s the data on your computer’s hard drive or the custom settings data of an app you use, should be one of your top priorities. As an app developer, we should offer our consumers the ability to backup their data. Fortunately, Android offers a feature called Auto Backup API that has been available for quite some time.

API for Automatic Backups

It saves the local app data in a user’s Google Drive account in a private folder with a maximum storage limit of 25 MB per app. (Data is not counted toward the user’s Google Drive quota). When an app’s quota limit is reached, the system will stop backing up the data. The old backup, on the other hand, is deleted when a new backup is made. To enable it with its default configurations, simply add the following line to the manifest file’s application tag.

android:allowBackup="true"

That’s all there is to it…! The Android framework is in charge of the entire procedure. To make it work, there’s one additional prerequisite. The Google Backup & Reset feature should be enabled on the user’s device, as well as a backup account assigned to it. This option is often available in Settings > Backup and resets> App data on Android 9. The data of the user is now available for backup.

Files, root & externalFiles directories, databases, and sharedPreferences are included by default, however, noBackupFiles, cache, and codeCache folders are always ignored by this API. The question now is when and how frequently the data will be posted to Google Drive. The backup procedure is started by various events.

1. The device is not in use.
2. At least 24 hours have passed since the latest backup.
3. The device is linked to the internet through WiFi or mobile data (depending on the user’s backup configurations).

Image #1: The auto restore

Configurations that are unique

Assume we have a requirement that only sharedPreferences be considered throughout the backup process, with the rest of the files/directories being ignored. The fullBackupContent feature of the manifest’s application tag makes this simple. In res > xml, we need to create an XML file (backup rules.xml) with the following information. The sharedPreferences file is named data.xml in this case.

<full-backup-content>
    <include domain="sharedpref" path="data.xml" />
</full-backup-content>

Then, as shown below, we can point to this file.

android:fullBackupContent="@xml/backup_rules"

Domains included in the <include> tag will be backed up, while those listed in the exclude> tag will be ignored. The include> tag now has a parameter requireFlags, which is used to add flags that are necessary to enable a few functionalities on Android 9 devices. It can take any of the following forms.

• clientSideEncryption: A client-side secret is used to encrypt the backup.
• deviceToDeviceTransfer: Allows a user to move a backup from one device to another utilizing local device-to-device transfer.

Backup Agent 

Android acts as a bridge between the app and the backup system. When working with file backup, it’s usually employed with the Key-Value backup mechanism and isn’t actually necessary. However, if we need delegates or callbacks for events like the completion of a backup process or the reaching of a quota limit, we can design an agent for that.

Java

class gfgAgent : BackupAgentHelper() {
    override fun onFullBackup(data: FullBackupDataOutput?) {
        super.onFullBackup(data)
        Log.e("BACK", "onFullBackup")
    }
}

We must construct a BackupAgentHelper child class and override the needed method/event. After that, we must define our agent in the application tag of the manifest file.

Testing

Using ADB shell commands, we can force backup and restore.

adb shell bmgr enabled

Backup

To create a full backup, run the following four instructions in order.

1. Activate the backup manager

adb shell bmgr backup @pm@
adb shell bmgr run

2. Start the backup manager and run it

adb shell bmgr fullbackup <package_name>

When the system performs a full backup, it will automatically shut down the program to prevent any local data changes during the process. We can enable a flag in the manifest to have a backup running in the foreground. (works with versions greater than 24)

Restore

When the program is reinstalled via the Google Play store or using ADB commands, data is restored automatically (installing using Android Studio). The program is restored after it has been installed but before it is made available to the user. If we need to use shell commands to force a restore, we can do it as detailed here. Isn’t that a little too much theory? Let’s open Android Studio and experiment with this API.

Keeping backups at bay

Although backup is essential, there are a few things that should not be included in this procedure. Consider the following example:

1. Any information related to a device, such as an FCM token
2. When a user installs the program on another device using the same Google account, it will be restored. We shouldn’t have the data from the previous device in this scenario.
3. Any sensitive user information, such as usernames and passwords
4. Tokens of authorization
5. Instead of obtaining the older token and letting the user use the app straight, we should pass him through the login flow when he downloads his app on a different device.
6. A lot of files

Always bear in mind the given quota, which is 25 MB per app. We shouldn’t add files that could take up all of the available space, causing backup failures.