Why Uninstalling Your Flutter App Won't Delete Data: The Android Auto Backup Trap

The "Ghost Data" Mystery

Imagine this scenario: You are deep in the development cycle of a new Flutter application. You are testing a critical authentication flow or a database migration. To ensure a clean slate, you do what every mobile developer has done thousands of times—you uninstall the app from your device and reinstall it.

You launch the fresh installation, expecting to see the onboarding screen. Instead, you are greeted by the "Home" screen. The user is still logged in. Your local database settings are still applied. The app acts as if it never left the phone.

Panic sets in. Is it a caching issue? Is your auth token sticking to the device ID? Is Firebase doing something behind your back?

While testing one of my recent Flutter apps, I encountered this exact behavior. Even after uninstalling, my SharedPreferencesand SQLite data remained intact upon reinstallation. After digging deeper, I discovered this wasn't a bug in my code—it was a feature of the Android operating system working exactly as intended, but perhaps not how a developer wants it to work during testing.

In this guide, we will explore why Android persists data across installations, the impact on Flutter development, and the specific configuration to disable it.

Understanding Android Auto Backup

To understand why your data is sticking around, you have to look at what Android does under the hood.

Google wants to provide a seamless experience for users. If a user buys a new phone or accidentally deletes an app, Google believes they shouldn't lose their progress, settings, or login state. To achieve this, Android automatically backs up app data to the user's private Google Drive storage.

This feature, known as Auto Backup for Apps, covers:

• Shared Preferences
• Files saved to the app's internal storage
• SQLite databases (and by extension, libraries like Drift or Floor)
• External storage files

When you reinstall the app—even a debug build signed with the same key—Android detects the package name, retrieves the backup from the cloud, and silently restores it before your main() function even runs.

The Solution: Modifying AndroidManifest.xml

If you want a truly clean install—perfect for testing edge cases, onboarding flows, or ensuring your database creation scripts run correctly—you need to tell Android to stop helping you.

The solution lies in your android/app/src/main/AndroidManifest.xml file. You need to explicitly disable the backup features.

Here is the configuration you need to add to the <application> tag:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.yourapp">

    <application
        android:label="your_app_label"
        android:name="${applicationName}"
        android:icon="@mipmap/ic_launcher"
        
        android:allowBackup="false"
        android:fullBackupContent="false">
        
        <activity...>
            </activity>
    </application>
</manifest><manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.yourapp">

    <application
        android:label="your_app_label"
        android:name="${applicationName}"
        android:icon="@mipmap/ic_launcher"
        
        android:allowBackup="false"
        android:fullBackupContent="false">
        
        <activity...>
            </activity>
    </application>
</manifest>

What do these flags do?

android:allowBackup="false": This is the master switch. It disables the Auto Backup feature completely. It also prevents the specialized adb backup command from working on your app.

android:fullBackupContent="false": This specifically targets the auto-backup rules for Android 6.0 (API 23) and higher. While allowBackup usually covers it, setting this ensures that no custom extraction rules define a backup scheme.

When Should You Use This?

It is important to note that Auto Backup is generally a good thing for end-users. Nobody likes losing their high score or having to re-login just because they switched phones.

However, for developers, it can be a nightmare. Here is how you should approach this configuration:

1. For Development and QA (The "Clean Slate" Approach)

When you are actively building the app, you almost always want allowBackup="false". You need to know that when you wipe the app, the data is gone. This guarantees that your logic for checking "Is this a first-time user?" triggers correctly.

2. For Production (The User-Centric Approach)

For the release version, you might want to re-enable it, unless your app handles sensitive data (like banking apps) or requires strict security protocols where cloud backups are a compliance risk.

If you want to keep backups for users but disable them for yourself, you can use Android Build Variants.

You can create a debug specific manifest at android/app/src/debug/AndroidManifest.xml that forces backups off, while leaving your main manifest enabled.

Impact on Local Storage Libraries

This behavior affects nearly every persistence library used in the Flutter ecosystem.

• SharedPreferences: These are XML files stored in internal storage. They are the first thing Android backs up.
• Hive: Hive boxes are files. If they are in the default document directory, they get backed up.
• SQLite / Drift: Your .db files are included in the restoration.
• Isar: Similar to Hive, Isar database files are subject to backup.

If you have ever migrated a database schema, uninstalled the app to reset it, and then crashed on reinstall because the olddatabase was restored against the new schema code—this is the culprit.

How to Verify the Fix

Once you have updated your AndroidManifest.xml, follow these steps to verify the data is truly gone:

Uninstall the existing app from your device/emulator.

Run flutter clean in your terminal (optional, but good practice).

Run the app (flutter run).

Generate Data: Log in, save some settings, or create a database entry.

Uninstall the app again.

Reinstall and run.

If the app starts in its default, empty state, the fix worked. If your data persists, double-check that you edited the correct AndroidManifest.xml (the one in src/main, not src/debug or src/profile unless intended).

Conclusion

Android's Auto Backup is a powerful feature for user retention and experience, but it can be a silent productivity killer for Flutter developers debugging local storage. By adding android:allowBackup="false" to your manifest, you regain control over your app's lifecycle and ensure that "uninstall" truly means "delete."

Small configuration tweaks like this can save you hours of confused debugging. Always be aware of what the OS is doing behind the scenes!