An Android app remembers its data after uninstall and reinstall

AndroidAndroid 6.0-Marshmallow

Android Problem Overview


While developing an Android app targeting all versions above 4.1, I observed that uninstalling my app and installing it again does not clear its data.

The app is designed to store the details that it asks in its first screen. After uninstalling and installing again in OS version 4.4.4, the app prompts the user to fill in the data, which is normal. However in version 6.0 the same install/uninstall sequence bring backs the data originally input.

I tried to ensure by visiting /data/data/my package folder to see the database is gone after uninstalling and indeed that folder gets deleted during uninstall.

I tried to delete the app by visiting the settings page, through Titanium Backup and the results are same. The device is rooted Nexus 5 running v6.0.

What could be the reason for this strange behavior?

Android Solutions


Solution 1 - Android

It's because Android 6 has automatic backup. You need to tune android:allowBackup and android:fullBackupContent in your manifest <application> tag if you don't want your data backed up or if you want to include or exclude some resources. It's not a bug.

More about AutoBackup on Android here.

Solution 2 - Android

greywolf82's answer is correct but I want to add some info to this.

When developing my Android app (using Xamarin), I noticed that whenever I'd re-launch the app from Visual Studio, my data would revert back to data from a few months ago. It didn't matter if I simply stopped and re-ran it from VS, or if I completely uninstalled the app and reinstalled it.

It's also worth noting that we never explicitly told the app to store a backup.

The backup also seemed to overwrite newer data when launching from Visual Studio, and we have reports of users using the release build of our app and also getting newer data overwritten by the backups.

Since I don't know exactly when backups and restores occur this feature seems to cause only problems.

We've modified our AndroidManifest by adding the following two lines:

android:allowBackup="false"
android:fullBackupOnly="false"

After adding them, our AndroidManifest contained the following xml:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.XXXXXXX" android:versionName="8.0.0" android:installLocation="auto" android:versionCode="439">
	<uses-sdk android:minSdkVersion="14" android:targetSdkVersion="24" />
	<application 
               android:label="@string/appName" 
               android:icon="@drawable/icon_small" 
               android:installLocation="internalOnly" 
               android:largeHeap="true"
               android:allowBackup="false"
               android:fullBackupOnly="false"
               />
...
</manifest>

Once we explicitly set the value to false, all seems to work. I'd expect this to be an opt-in feature but...seems like it might be on by default for apps which don't specify the value either way.

Solution 3 - Android

You should check your device's Backup and Reset settings, and turn off Automatic restore (when reinstalling an application, backed up settings and data will be restored.)

Turning off auto-backup is different from the auto-restore. If you think it will be helpful to turn on auto-backup for your application do so. But if you think this will make end users who are not aware that the auto-restore feature of their device is turned on, feel free to turn it off.

In my case, I turned off the allowBackup feature, but since I already had a backup of the previous version on the Cloud, it still kept on restoring.

See image as reference for a Samsung device on Android 6.0. Other devices and versions may have a different screen. See image below.

Automatic Restore Setting under Backup and Reset

Solution 4 - Android

Just adding to this, we found that in Android 9 (on a HMD Nokia device) that the assets were held, even after deleting the app through the interface and through adb.

The answer of adding:

android:allowBackup="false" android:fullBackupOnly="false"

Obviously, this is not a new answer - but an observation for people who were in the same position as us.

Solution 5 - Android

I recently needed to take advantage of these features, I was able to uncover documentation and upon extensive testing this is what I have been able to deduce:

Android:allowbackup - will backup local app data on the device it is located on.

Android:fullBackupContent - is used in conjunction with Google's backup restore api and CAN be controlled via an xml file to specify what exactly to backup, as well as a BackupManager class you may implement for further control over the process.

However the documentation states, and I have confirmed with testing, that a restore will only occur either when the device is restored and the restore app data process is triggered. OR it will also restore when the app is sideloaded through adb, which is what we do when we run the app for testing or debug on our devices through Android Studio. Note that if you set android:allowbackup but do not configure android:fullBackupContent with a Google api code then the apps data only gets stored locally, whereas if you configured it properly then if your app was backed up and you get a new device the apps data was stored on the cloud so it can be restored on a new device.

Solution 6 - Android

Adding android:allowBackup="false" under application tag in Manifest file solved my issue.

Here goes the android documentation for Back up user data with Auto Backup

Solution 7 - Android

If you are targeting android 10 then you have to put android:hasFragileUserData="true" in application tag of AndroidManifest.xml

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android">
  <application
    android:name=".MyApplication"
    android:icon="@mipmap/ic_launcher"
    android:label="@string/app_name"
    android:theme="@style/AppTheme"
    android:allowBackup="true"
    android:hasFragileUserData="true">

    .....

     </application>

 </manifest>

>android:hasFragileUserData is a new manifest setting (I’m guessing on ). “If true the user is prompted to keep the app’s data on uninstall”. This seems ripe for abuse, but I can see where it might be useful for some apps.

See https://commonsware.com/blog/2019/06/06/random-musings-q-beta-4.html

Solution 8 - Android

I also added:

tools:replace="android:allowBackup"

to override same option in a used component

Solution 9 - Android

Just change android:allowBackup="true" to android:allowBackup="false" in manifiest.xml. It will be worked.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    <application
        android:allowBackup="false"
        android:icon="@mipmap/app_icon"
        android:label="@string/app_name"
        android:supportsRtl="true"
        android:theme="@style/AppTheme">
</manifest>

Solution 10 - Android

This answer summarizes multiple other existing answers, and includes recent details as of Android 12 being introduced, and includes instructions for clearing existing app backup data generated from a device.

For more information, see https://developer.android.com/guide/topics/data/autobackup#EnablingAutoBackup https://developer.android.com/about/versions/12/behavior-changes-12#backup-restore https://developer.android.com/guide/topics/manifest/application-element http://android-doc.github.io/preview/backup/index.html (for clearing existing app backup data stored in Google Drive from a device: Settings > Backup > toggle Google One backup off then back on again, then try uninstall/reinstall again)

As a side note, some of the other answers suggest android:fullBackupContent="false" but that doesn't seem correct anymore since that is currently meant to specify an xml file of a specific format, not a true/false.

These attributes to <application> allow for disabling or configuring specifics for Android auto-backup functionality.

<application
tools:replace="android:label, android:icon, android:allowBackup, '...any other attribute you want to override with a value you set in this file for in case dependencies set them to other values...'"
'...your other attributes set here like android:label and android:icon...'
android:allowBackup="false" '...default is true, and setting this false prevents data backups of any kind (except device to device transfers if your app targets Android 11 (API 30) or higher)...'
android:fullBackupContent="@xml/backup_rules_android_11_and_below" '...optional, for Android 11 and below, referring to a file res/xml/backup_rules_android_11_and_below.xml you need to create...'
android:dataExtractionRules="@xml/backup_rules_android_12_and_above" '...optional, for Android 12 and above (fullBackupContent still needed along with this, assuming you support Android 11 and below), referring to a file res/xml/backup_rules_android_12_and_above.xml you need to create, with a slightly different required xml format...'
android:fullBackupOnly="false" '...optional, and default is false, but if set to true this field description says it enables auto backup on Android 6 (API 23) devices or higher (I am not sure how this matters compared to the more broadly reaching allowBackup)...'
android:hasFragileUserData="false" '...optional, and default is false, but if set to true this field description says it gives the user an option when they uninstall the app whether or not to backup their app data...'
>
'...contents of application element...'
</application>

The <application> changes only affect creation (or lack of creation) of future app backups; any existing app backup data will still exist and be used until overwritten or cleared (see above for instructions to clear that data for a device).

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionNarayananView Question on Stackoverflow
Solution 1 - Androidgreywolf82View Answer on Stackoverflow
Solution 2 - AndroidVictor ChelaruView Answer on Stackoverflow
Solution 3 - Androiduser3899864View Answer on Stackoverflow
Solution 4 - AndroidJRKView Answer on Stackoverflow
Solution 5 - AndroidXijukxView Answer on Stackoverflow
Solution 6 - AndroidVinay JohnView Answer on Stackoverflow
Solution 7 - AndroidManoharView Answer on Stackoverflow
Solution 8 - AndroidFabio SartorView Answer on Stackoverflow
Solution 9 - AndroidNag KosanamView Answer on Stackoverflow
Solution 10 - AndroidTommy ElliottView Answer on Stackoverflow