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()orgetDir(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/excludetheincludetag supersede - The path reference within the
includeandexcluderefers to the resource location- Example:
<include domain="database" path="test_db.db"
- Example:
- if you use both
- The backup file should be listed in Android Manifest
- Example:
<application android:fullBackupContent="@xml/auto_backup_rules ... >
- Example:
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.
