Why is Android not providing backup of app data?

Search This thread

TheMystic

Senior Member
Mar 18, 2017
785
383
Hello community!

I think this is the best place to ask this question as this is a forum of default for all developers.

Why is Android not providing backup of app data?

On iOS, factory reset and restore is a breeze. The process is extremely simple, and there is absolutely no user intervention required after a factory reset. iOS simply puts everything in its place as if nothing happened. Same is true for macOS, WatchOS & iPadOS. This is just a wonderful implementation. The only limitation is if an existing app is no longer available on the Apple AppStore. In that case, the app data would still remain in the cloud (or iTunes backup), and can be easily restored if the app (.ipa file) is backed up using iTunes (or similar 3rd party software).

Can someone answer why the same is not available on Android, despite it being the more versatile software?

As far as I know, backup over ADB isn't reliable. And more importantly, ADB isn't for everyone.

Thanks.
 

aIecxs

Senior Member
Feb 17, 2016
1,888
536
gitlab.com
Android needs to provide a way or redesign itself where it's Backup & Restore function is just as seamless and effortless, as it is on iOS.
Google One looks pretty much like it offers that. This native bloat comes pre-installed on my device in /product/app/GoogleOne so I assume that is google's official backup feature provided for every android device.

If I factory reset my Android phone, the backup will only restore call logs, sms, contacts, and a few basic stuff.
Backup by Google One automatically saves data from your phone. This includes:
- App data
- Call history
- Contacts
- Settings
- SMS messages
- Pictures and videos
- MMS messages
You can check what data and which apps are included in your backup.


What else do you need that isn't covered by "App data"? full backup was possible from the earliest days, so I assume that behavior applies to cloud backup as well.

It will also download all my apps from the Google Play Store. But here ends the similarity. Beyond this, the user has to setup every app from scratch, with the exception of a few like Google's and Microsoft's cloud based apps.
Not true. app is restored including app data, no need to setup from scratch. except for apps where the app developers made decision for. this is not a limitation in design, it's a feature for app developers to deny access to app data. in your opinion this feature is useless, but app developers have different view on things.

User also has to setup all the permissions for apps from scratch. There is a lot of work involved, which can be easily avoided if Android provided an automated way of getting this done.
Besides granting permissions again, what "lot of work" is it exactly you mean here? Again, this is a feature not a limitation. not restoring permissions is for security. Do you realize that apps lose it's permissions intentionally if unused?
https://9to5google.com/2021/09/17/android-unused-apps-permissions

You haven't explained why app developers can choose whether this information can be backed up or not. To me, it seems like Android has a big limitation in the way it is designed, and so is unable to provide a simple backup solution that takes care of these things like in iOS.
So let's have a look into risk of allowing backup app data if we provide a backup solution that includes these things, ignoring app developers decision.
https://digitalforensicforest.com/2016/01/28/android-backup-file-ab-analysis

User configuration files and login credentials belong to the user.
So let's give you example. Few years back (before corona lockdowns) I used app com.limebike. This app also has employee mode with login secured area called "Juicer mode" intended for collecting e-Scooter for maintenance or charging. To get approval for registration user must have business licence, so I have signed up contract as freelancer. each user must be adult and have its own registered account. If you login into one device, all other devices will be logged out automatically. This is realized by additional login credentials (device unique ID) stored in app data.

Stupidly enough, app developers have set android:allowBackup="true" accidentially (it's a cloud-based app all data is saved on server bonded to user account, so there is no need to backup anything btw) so I was able to access app data by simply typing adb backup com.limebike which makes 1:1 copy of secret login credentials. I was able to adb restore backup.ab to other android device (without root) and - voilà - both devices were logged in simultaniously ("Two Juicers are better than one")

In Juicer mode a "Juicer" can unlock the scooter for 24 hours for collection. So guess what? I sent backup.ab to all my friends (and even my minor son) and they were able to unlock scooters and ride for free! Even better, I gave them chargers, so whenever one of my friends decided to take a free ride, I earned money!

I think thats 'good reason' for app developer to opt out of data backup, don't you agree?

I am sure there are plenty much apps where access to app data is forbidden for reason. I don't use banking apps, crypto wallets, amazon or netflix personally, neither I am app developer so I can't say if there better methods to protect app data, but one thing all cheats have in common they depend on security vulvnerabilities and app data leaks. (If you're playing games on your mobile you probably know about Lucky Patcher)

Now, imagine you're the app developer of com.limebike and want to close this backdoor by checking SafetyNet and changing android:allowBackup="false". What do you think, would you still provide your app in Google Play if android says "Hey, we don't care about your security, let users backup their data anyway"?

So in your opinion Android has a big limitation in the way it is designed, but in fact that's not a technical limitation but a feature.
 

Attachments

  • Pick Up Screen View 2.png.jpg
    Pick Up Screen View 2.png.jpg
    181 KB · Views: 8
Last edited:

TheMystic

Senior Member
Mar 18, 2017
785
383
Google One looks pretty much like it offers that. This native bloat comes pre-installed on my device in /product/app/GoogleOne so I assume that is google's official backup feature provided for every android device.
This app is useful for managing cloud storage as well as the membership. It allows you to also see what apps have been backed up, even though there is no control over it, i.e. user can't choose what to backup.


Backup by Google One automatically saves data from your phone. This includes:
- App data
- Call history
- Contacts
- Settings
- SMS messages
- Pictures and videos
- MMS messages
You can check what data and which apps are included in your backup.


What else do you need that isn't covered by "App data"? full backup was possible from the earliest days, so I assume that behavior applies to cloud backup as well.

I just checked the details under System Settings, and here's what I see:

Screenshot_20220701-110240_Google Play services.png


But on Google One app, the details are quite different:

Screenshot_20220701-110308_Google One.png


When you look at the size of the backup, 88 MB is just too small. Moreover, I have over well over 200 apps downloaded and installed (Google Play Store shows 294, which includes preinstalled apps). What about the backup for the remaining apps?

If I delete all my backups on my iPhone and do a fresh backup, it will be well over 1 GB (no user files included, just the app data).

Not true. app is restored including app data, no need to setup from scratch. except for apps where the app developers made decision for. this is not a limitation in design, it's a feature for app developers to deny access to app data. in your opinion this feature is useless, but app developers have different view on things.

Very few apps are included here. For example, the same file manager app which you confirmed allows app data to be backed up, see the size of the backup:

Screenshot_20220701-104948_Google One.png


And see the size of backup of other file managers which have much fewer user configurations:

Screenshot_20220701-104921_Google One.png


9 KB is just too small, and I'm sure this app will need to set up again if restored from a Google backup.

Besides granting permissions again, what "lot of work" is it exactly you mean here? Again, this is a feature not a limitation. not restoring permissions is for security. Do you realize that apps lose it's permissions intentionally if unused?
https://9to5google.com/2021/09/17/android-unused-apps-permissions

Quite strange that you are defending a feature that you don't use yourself. There is a lot of manual work involved in setting up a device after a factory reset. On Android, app permissions are scattered in 3 different places:

1. App Info (ideally, every single permission must show up here)
2. Permissions Manager
3. Special Access

One has to configure all those for each app, and doing that for 100 apps or more is quite a lot of work.

On iPhone, none of that is required. Besides, iPhone also allow for 'offloading' apps, which allows you to uninstall an app (to save space or for any other reason) while keeping the app specific configurations saved on the device/ iCloud. So next time you install the same app, you'll find that it is already setup. Can you do that on Android? We are not talking about ADB backups or those made by Titanium Backup/ Migrate or others.

Removing permissions for unused apps is a good security feature. But here the issue is for all apps. A restore after factory reset doesn't restore any of the permissions set for the app. They have to be redone manually, e.g. internet access, battery optimization, wifi control, modify system settings, etc.

So let's have a look into risk of allowing backup app data if we provide a backup solution that includes these things, ignoring app developers decision.
https://digitalforensicforest.com/2016/01/28/android-backup-file-ab-analysis
This points to another major flaw with Android. An app should only have access to what it needs for core functionality. Where critical information is involved, such as login credentials, Android must provide something similar to Apple's 'Keychain', that will store everything in encrypted form within Android's security framework.

And what gets included in backups should be purely user configurations. For file managers, that would be all remote connections, app settings, etc. For launchers, that would be wallpaper, homescreen layout, etc. Those that the user has specifically provided. It shouldn't include information that the app itself has collected over time or cached in its directories.

On iPhone, most things have to be strictly done in a very specific way, and may be that's why iPhone is able to provide features like 'offloading apps' as well as able to restore backups without any manual intervention whatsoever. On Android, developers seem to have a free hand in designing their apps the way they want, making it difficult to provide a reliable way to offer features like the ones above.


So let's give you example. Few years back (before corona lockdowns) I used app com.limebike. This app also has employee mode with login secured area called "Juicer mode" intended for collecting e-Scooter for maintenance or charging. To get approval for registration user must have business licence, so I have signed up contract as freelancer. each user must be adult and have its own registered account. If you login into one device, all other devices will be logged out automatically. This is realized by additional login credentials (device unique ID) stored in app data.

Stupidly enough, app developers have set android:allowBackup="true" accidentially (it's a cloud-based app all data is saved on server bonded to user account, so there is no need to backup anything btw) so I was able to access app data by simply typing adb backup com.limebike which makes 1:1 copy of secret login credentials. I was able to adb restore backup.ab to other android device (without root) and - voilà - both devices were logged in simultaniously ("Two Juicers are better than one")

In Juicer mode a "Juicer" can unlock the scooter for 24 hours for collection. So guess what? I sent backup.ab to all my friends (and even my minor son) and they were able to unlock scooters and ride for free! Even better, I gave them chargers, so whenever one of my friends decided to take a free ride, I earned money!

I think thats 'good reason' for app developer to opt out of data backup, don't you agree?

I am sure there are plenty much apps where access to app data is forbidden for reason. I don't use banking apps, crypto wallets, amazon or netflix personally, neither I am app developer so I can't say if there better methods to protect app data, but one thing all cheats have in common they depend on security vulvnerabilities and app data leaks. (If you're playing games on your mobile you probably know about Lucky Patcher)

Now, imagine you're the app developer of com.limebike and want to close this backdoor by checking SafetyNet and changing android:allowBackup="false". What do you think, would you still provide your app in Google Play if android says "Hey, we don't care about your security, let users backup their data anyway"?

So in your opinion Android has a big limitation in the way it is designed, but in fact that's not a technical limitation but a feature.
In your example, the failure points to the fact that there was no verification of device ID. If that was implemented properly, the backups wouldn't have worked on another device because of a device ID mismatch.
 

TheMystic

Senior Member
Mar 18, 2017
785
383
start with the first one, or with the last
All your questions have been answered, with examples and illustrations.

Google Backup doesn't restore all apps with their data after a factory reset. User's own settings and information provided to apps belong to the user, and Android has an inherent limitation in not being able to backup just those. This applies to both configurations set within apps, and those set for apps.
 

aIecxs

Senior Member
Feb 17, 2016
1,888
536
gitlab.com
nope, you haven't answered the first one
What else do you need that isn't covered by "App data"?
Code:
apps/pkgname/a/  : /data/app/pkgname-1/base.apk
apps/pkgname/obb/: /data/media/0/Android/obb/pkgname/
apps/pkgname/f/  : /data/data/pkgname/files/
apps/pkgname/db/ : /data/data/pkgname/databases/
apps/pkgname/sp/ : /data/data/pkgname/shared_prefs/
apps/pkgname/r/  : /data/data/pkgname/
apps/pkgname/c/  : /data/data/pkgname/cache/
apps/pkgname/ef/ : /data/media/0/Android/data/pkgname/files/
shared/          : /data/media/0/
nor the last
there are plenty much apps where access to app data is forbidden for reason [...] would you still provide your app in Google Play if android says "Hey, we don't care about your security, let users backup their data anyway"?

for another question, your answer was
1. permissions
2. permissions
3. permissions
Besides granting permissions again, what "lot of work" is it exactly you mean here?

so for File Manager backup
9 KB is just too small, and I'm sure this app will need to set up again if restored from a Google backup.
why not test it yourself? you're contradictory claiming android would not differ between different kind of app data, but at the same time claiming only partially app data is restored. so what is true then? you're comparing sizes, so please tell me, is app data backed up or not? You gave the answer already...
It shouldn't include information that the app itself has collected over time or cached in its directories.
I have already replied to your first post that files in EXTERNAL_STORAGE are memory wasting garbage (and no app data). fairly enough, let's mention that has changed now with Android 11 scoped storage where it contains important data (but still no app data to be backed up)
 
Last edited:

TheMystic

Senior Member
Mar 18, 2017
785
383
nope, you haven't answered the first one

nor the last


for another question, your answer was
1. permissions
2. permissions
3. permissions


so for File Manager backup

why not test it yourself? you're contradictory claiming android would not differ between different kind of app data, but at the same time claiming only partially app data is restored. so what is true then? you're comparing sizes, so please tell me, is app data backed up or not? You gave the answer already...

I have already replied to your first post that files in EXTERNAL_STORAGE are memory wasting garbage (and no app data). fairly enough, let's mention that has changed now with Android 11 scoped storage where it contains important data (but still no app data to be backed up)
I'm talking of Google Backups, but you continue referring to ADB backups. The two are not the same. Google Backup is what over 98% users use.

Setting up permissions and configuring 100s of apps is a time consuming exercise. It takes hours to set them all up, if you are particular about app permissions. On an iPhone, if I factory reset, all I have to do is to login to my iCloud account and choose to restore a backup. That is all I have to do. iOS takes care of everything else. That is how the experience should be for Android too.

Just because I am not sure about 1 app, do you really think it makes sense to do a factory reset and test it? I showed you I have about 294 apps on my phone, but the backup includes only 90 apps in my case. Does that not tell you that the Google Backup leaves out a large majority of apps during the backup process?

Even though this particular app was included in the backup, the size of it tells me it is unlikely to include all the remote connections I have set up within the app. Out of some 15 file managers I have installed in my phone, I see only 3 in the backup.

What I know from my previous experience is what I have stated. It is not difficult to confirm as the numbers are clear.

If an app has not been coded nicely enough to protect user data, it is not an excuse to stop it from being backed up. It also shows weaknesses in the how Android is designed. And as mentioned before, the data that I am referring to is nothing crucial. These are simply configurations set inside the app, and those set for the apps.

All that said, since you claim there is very little work after a factory reset, why don't you give it a try? My device is in stock form and it is kind of a forbidden exercise for me, given how much time I know I'll have to put in after a factory reset.
 
  • Like
Reactions: aIecxs

V0latyle

Forum Moderator
Staff member
Android segregates app data, so without root access, no process can access another app's data without explicit permission to do so. I believe Android system processes are also excluded from app data access. This is done through permissions - the application packages themselves reside in a directory to which system has access, but individual applications have their own directories in /data to which system does not have access. So, the system can only back up system settings as well as installed applications, but not the applications' private data.

The ADB daemon, which provides remote access to the device system shell, does not have root access, and therefore cannot access app data, unless the shell is elevated with su.

So, unless I'm sorely mistaken, the only way to fully backup a device, including private application data, is via root privileges, using either ADB, or an app such as Titanium Backup or Swift Backup.
 

TheMystic

Senior Member
Mar 18, 2017
785
383
Android segregates app data, so without root access, no process can access another app's data without explicit permission to do so. I believe Android system processes are also excluded from app data access. This is done through permissions - the application packages themselves reside in a directory to which system has access, but individual applications have their own directories in /data to which system does not have access. So, the system can only back up system settings as well as installed applications, but not the applications' private data.

The ADB daemon, which provides remote access to the device system shell, does not have root access, and therefore cannot access app data, unless the shell is elevated with su.

So, unless I'm sorely mistaken, the only way to fully backup a device, including private application data, is via root privileges, using either ADB, or an app such as Titanium Backup or Swift Backup.
The data in question isn't all that private or critical. It is simply the settings and configurations that the user has created both within the app, and for the app under System Settings. Android probably does not have a way to collect that data in isolation, which is why it is unable to provide features like 'Offloading apps' which is available on iPhones.
 

V0latyle

Forum Moderator
Staff member
The data in question isn't all that private or critical. It is simply the settings and configurations that the user has created both within the app, and for the app under System Settings. Android probably does not have a way to collect that data in isolation, which is why it is unable to provide features like 'Offloading apps' which is available on iPhones.
"Private" in this context means data that belongs specifically to a particular app. Android was designed from the outset to prevent apps from accessing other apps' private data. So, again, the only way to perform a backup of app data is using a tool with root privileges.
 

V0latyle

Forum Moderator
Staff member

aIecxs

Senior Member
Feb 17, 2016
1,888
536
gitlab.com
@V0latyle well, it's not a exploit at all. actually, it's very simple: any app data can be backed up without root, if the app developer has set android:allowBackup="true"

this was the case for WhatsApp up to v2.11.431 (later versions WhatsApp decided to change android:allowBackup="false")

so what this little script does
- install WhatsApp v2.11.431
- adb backup com.whatsapp
- extract app data from backup.ab

you could have known that if you had read the example about com.limebike in post #21 (or at least post #4)
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 1
    I think we can track it down to simple rule.
    if you wanna have control and responsibility about your phone in your hands, use android.
    if you don't care a f** about what's stored in cloud - buy iPhone
    You missed an important point: on iOS, user decides whether his data that is collected by an app should be backed up to the cloud or not. You get to control what to backup, and what not to backup. If user chooses to save in the cloud, Apple is pretty good in keeping that data secure. Most cases of breach are users' own stupidity.

    With Android, it is absurd that the app developers make this decision for the users. And you are saying one should use Android if he wants to take control of this. I don't see a simple or reliable way to do that.
    1
    It's simple, main reason is GDPR, cmiiw

    Data needs to be separated between application data (config, everything that is not stored any customer/user/client information) and user's data (login sessions, anything that might compromise customer/user/client information).

    For most application data, it can be safely assumed, google, huawei, or any third party software, can back it up, stores it in any kind of their backup storage (cloud, ftp, you name it), and restores it as they wished. However, as the user's data, they cannot. At least without user's consent. And it's because of GDPR.

    And @Alecxs is correct. Imagine if someone can restore your data in their phone, and then they were identified as you, imagine the horror. If you think no it's impossible, think again. If you think Apple is secure and that's not possible, think again.

    And now, why many backup apps exist in play store that can do that? Simple, they don't provide any kind of agreement that they will store your data in their storage, it's always in your local storage or your own cloud storage (dropbox, drive, you name it). And because there isn't any clear protocol from android to do so (separated backup between application or user data), most of them needs to be operated under root.
    1
    can you please provide pkgname (or google play link) of your file manager, so I can double check?
    1
    nope, you haven't answered the first one

    nor the last


    for another question, your answer was
    1. permissions
    2. permissions
    3. permissions


    so for File Manager backup

    why not test it yourself? you're contradictory claiming android would not differ between different kind of app data, but at the same time claiming only partially app data is restored. so what is true then? you're comparing sizes, so please tell me, is app data backed up or not? You gave the answer already...

    I have already replied to your first post that files in EXTERNAL_STORAGE are memory wasting garbage (and no app data). fairly enough, let's mention that has changed now with Android 11 scoped storage where it contains important data (but still no app data to be backed up)
    I'm talking of Google Backups, but you continue referring to ADB backups. The two are not the same. Google Backup is what over 98% users use.

    Setting up permissions and configuring 100s of apps is a time consuming exercise. It takes hours to set them all up, if you are particular about app permissions. On an iPhone, if I factory reset, all I have to do is to login to my iCloud account and choose to restore a backup. That is all I have to do. iOS takes care of everything else. That is how the experience should be for Android too.

    Just because I am not sure about 1 app, do you really think it makes sense to do a factory reset and test it? I showed you I have about 294 apps on my phone, but the backup includes only 90 apps in my case. Does that not tell you that the Google Backup leaves out a large majority of apps during the backup process?

    Even though this particular app was included in the backup, the size of it tells me it is unlikely to include all the remote connections I have set up within the app. Out of some 15 file managers I have installed in my phone, I see only 3 in the backup.

    What I know from my previous experience is what I have stated. It is not difficult to confirm as the numbers are clear.

    If an app has not been coded nicely enough to protect user data, it is not an excuse to stop it from being backed up. It also shows weaknesses in the how Android is designed. And as mentioned before, the data that I am referring to is nothing crucial. These are simply configurations set inside the app, and those set for the apps.

    All that said, since you claim there is very little work after a factory reset, why don't you give it a try? My device is in stock form and it is kind of a forbidden exercise for me, given how much time I know I'll have to put in after a factory reset.