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:
But on Google One app, the details are quite different:
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:
And see the size of backup of other file managers which have much fewer user configurations:
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.
