Android Auto Backup and why we need to manage it properly in Xamarin

As Xamarin Forms Developers even though we are developing most of our code in Forms, we still need to be attentive to each native platform features and how their ecosystem evolves and how does this affect our apps, a common case is using Shared Preferences each platform deals with them differently and that brings me to this new article.

Each platform decides how it handles it’s OS, and I want to focus on Shared Preferences and how it is affected by an awesome feature android has added to automatically backup user’s data that target Android 6.0(API Level 23) or later. Android saves app data by uploading it to the user’s Google Drive. But the issue is that this default behavior might not be made for every app scenario, you must be aware that if you have settings for enabling things like auto-login, themes preferences, and upgrades there might be some additional setup you need to make, so your app works correctly taking this into consideration.

If we don’t each time the user completely uninstall the app and installs it again android will restore its app data backup and cause unexpected behavior in your app fresh install flow, like an auto logging flow being triggered, or setting a theme by default he had before he uninstalled the app generating an inconsistent and erroneous logic for your app.

A few basics to know . . .

  • Auto backup has a limit of 25MB per user (this has no charge for the user to store it’s app data).
  • We can opt out of this feature completely.
  • We can customize this feature to our needs.
  • By default auto backup will include files in most of the directories that are assigned to your app by the Android system:
    • Shared Preferences Files
    • Files saved to your app’s internal storage, which you can access by getFilesDir() or getDir(String, int)
    • Files in the directory returned by getDatabasePath(String)

Examples Cases

I will walk through 3 example app scenarios that could go wrong and sometimes unnoticed without proper testing of your app while developing (because let’s face it, sometimes edge cases like fresh install situations can fly by if we are continuously developing an app and don’t have the need to uninstall it completely from the device we are testing in).

Theming

So let’s say we using our shared preferences plugin to store what theme our user like to use in our app, everything works great. but once the user decides to uninstall we want to be able to provide a default user experience to our future user using this device if he decides to install the device again, in this case since we still have autobackup by default, if the user reinstall the app. he will not see the default red theme, but instead will see the blue theme set by the previous install he used in the app. (you always have to make sure what is the requirement of the feature asking for, for some apps this may be an acceptable behavior but for others maybe they don’t want to persist this decision or at least not generally so you must do a workaround by doing it per users when they login and updating the theme of the app by asking the db what is his preferred theme or any other idea you might come up with :P)

Custom Authentication Experiences

In these case we are analyzing: what if our app provides custom authentication experiences for our user and we decided to use shared preferences to enable or disable these features like fast auth or auto login. Once the user has enabled one his start screen will be different depending which feature he enabled, so imagen the user uninstalls the app on the device and installs it months after, the app will no longer show him the default starting page on fresh install but instead will show the methods he choose the last time the app was installed causing him to be asked a fingerprint that might not be his, or auto login him in to the app.

How can we manage Android Auto Back feature

Once we know this default feature our Forms App will have in Android we can mitigate it accordingly, and Android provides us 2 ways to do it, we can either opt out completely of the auto back up feature or we can manage our app data more atomic and include or exclude what we don’t wish to persist in our backup.

Opting out of Feature

We can disable backups by simply setting the android:allowBackup property to false in our application tag in our Android Project manifest file.

Include and Exclude data

We must remember that Android is backing up by default almost all app related data, so how can we decide what to include or exclude? we simply need to define XML rules which will give us control on what we want to backup.

First, we create a new XML resource called back_up_rules.xml or any name you want to give it and define inside this file our rules using the <include> and <exclude> tags like for example:

Once we have our rules ready all that is left is to tell our Android Application where it can find the rules it should follow if the auto backup is enabled, we can do this by simply adding the android:fullBackUpContent attribute to the application tag in our application tag in the manifest file for our app:

Ce finito Guys! Now you are able to manage your app’s data backup correctly and solve the issue of why the shared preferences of your Forms App were always being persisted even after uninstall on Android.

Made with ❤ by Pujolsluis

Good References to learn more about Android Auto Backup feature

Back up user data with Auto Backup – Android:

https://developer.android.com/guide/topics/data/autobackup

Files that are backed up with the auto backup feature – Android:

https://developer.android.com/guide/topics/data/autobackup#Files

Credits for artwork components:
Mobile Icons for the banner of the post made by Freepik

(Visited 1,465 times, 1 visits today)

Leave A Comment

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.