Dauris Little

  • About
  • Dauris’s Portfolio
  • Blogging Lyf
  • Contact

allowBackup: Android’s Attributes

Avatar photo
Dauris
Saturday, 06 March 2021 / Published in Android, Java, Kotlin, Programming Languages

allowBackup: Android’s Attributes

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.

Tagged under: android, android development, android manifest, Mobile Development, programming

What you can read next

Android, SQLite & Kotlin
Android reCAPTCHA
Integrating Google’s reCAPTCHA w/Android
val vs var
Val vs Var

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Categories

Recent Posts

  • Gesture Controls for Android w/Kotlin

    Incorporating Gesture controls in your android ...
  • Android Rating: In-App Review API

    An app rating and reviews are crucial if you wa...
  • QR Reader in Android w/ Kotlin

    Turn your phone's camera into a QR scanner...
  • Creating Advance Custom Snackbar w/ Kotlin

    Ask 100 different developers about what they fi...
  • Swift Has Tuple

    Swift provides us with a type called Tuple whic...

© 2017. All rights reserved. Designed by Dauris Little

TOP
This site uses tracking cookies to personalize content and ads. AcceptLearn More