It is ongoingly stunning to me given all Google's BS that Android has no backup option which will get my apps, their data and the state of my home screen back exactly the way I left it if my phone is destroyed.

I run a custom honescreen: it's just another Android app! And yet everytime I have to set that back up again manually.

Yes, I was going to say the same thing. My samsung galaxy s10+ has a cracked screen and I need to take it to repair but the thought of the work needed to backup everything stops me from doing so.

I have very little trust in Google so I don't want to backup to google cloud (I just researched and it seems they do provide end to end backup encryption without Google having the key anywhere since Android 9, is that really the case now?)

Your definition of complete backup exceeds even the definition the parent is using for IOS. There are some things like downloaded files that don't get backed up to the cloud. (Some of them probably do get backed up via iTunes backups, but even there, I'm quite certain that not quite everything gets backed up. Instead it contains nearly everything that an non-jailbroken user might care about.)

Things like the set of apps, settings (both app and system level), game progress, the set of open tabs, etc can be backed up, and IOS is even able to restore old app versions specified in the backup by downloading them from the store.

All that said, both IOS backup options are more comprehensive than the built-in android options.

> IOS is even able to restore old app versions specified in the backup by downloading them from the store.

iOS even restores your open applications and task manager state when you restore from the backup. Even more so, theoretically, it can restore every apps state at the point of backing up. It's a feature ported from macOS.

local backups (used to be iTunes, now it’s just done from the Finder) do indeed backup everything. And as another commenter pointed out, your application state is also backed up and restored.

#1. Local backups are still itunes based on windows. #2. Stateing everything is still not quite true. The OS is not backed up, since old versions cannot be restored. and unless things have changed since a few versions back, local backups deliberatly omit some data if it can be downloaded on restore. For example, the actually apps just have their names and versions recorded so they can be redownloaded. Which is not really a problem, except in those rare cases where an app has been completely deleted from Apple's servers, which typically only happens for malware or for legal reasons. (I suspect that any apps not in the store at the time of the backup are included in the backup, so hitting this case should be incredibly rare.)

Backups are a total black pattern where you either pay Apple for ever or the respective APIs are horribly broken. It would require zero effort on Apple's side to integrate backup to other servers using the OS or other Apps. That means without silently stopping them or even worse slowing them down to kb/s once in the background.

You can backup your iPhone anytime you want to your own computer. iCould makes it pretty easy to do settings and config backups that will be included in their free tier.

There is no way Apple is going to let 3rd party could providers do backups directly. I doubt exposing the iPhone as a USB device over the internet with a VM running iTunes would work efficiently.

Assuming you've already paid Apple for the device and you don't want to make use of the 5GB free iCloud storage for backups, you could backup iPhone to iTunes on your laptop (encrypted) and then ensure your laptop was backed up locally also. This way you avoid paying Apple for ever.

So yes you also need to install itunes to backup on your computer, because why directly mount it as a usb drive without an apple app? That would also need zero effort from apple, but I was talking about an online backup with since forever established protocols.

"I can't back it up completely" and "I can't back it up completely the way I want to" are two different arguments. It's fine if the second is the argument you actually want to make, just be clear you're making it.

I appears to me that my actual statement "backup to other servers" is clear enough.

One of my colleagues have a pipeline which locally backs-up his iPhone and uploads the encrypted back-up to his VM.

Maybe you can create an automation like that.

"When switching phones it's still a process of hours / days to get everything set-up the way you had it on a previous phone"

From my experience this is completely false. I just switched from Galaxy S8 to S20, and I transferred everything and had the new phone setup exactly like the old one, with all apps (that would allow it, LINE wouldn't) and even ringtones and text tones set how I had them in about 20 minutes.

> Android does not allow you to take complete backups

Can't you enable developer mode, open a terminal and just run `dd`?

Out of a variety of reasons: no.

1) You don't want to risk dumping a mounted filesystem because of inconsistencies

2) Good luck getting the right device - in the end it's devicemapper all the way down with a lot of layers (ecryptfs, sdcardfs, bind mounts, ...) stacked between your shell and the device.

3) Unrooted phones don't allow access to raw Unix devices

4) You can't restore these backups anywhere if your phone (like almost all, I think it's a Netflix requirement) uses hardware key storage - simply because the key is in the secure element of your phone. Rooting a Samsung phone kills the HSM and switches over to software key management though.

5) Assuming encryption keys don't get in your way, you can only restore the dump on exactly the same model and firmware of device you have, because every manufacturer does stuff slightly different.

Makes me wonder if you can just dump the Flash storage chips through JTAG or similar - assuming the JTAG ports are accessible without completely dismantling the phone.

That still doesn't solve the problem of getting the crypto keys.

Not without root. Assuming by developer mode you mean to enable adb connectivity, you'll still need root in order to gain access to dd the filesystem.

To root "well made" phones, you need to unlock the bootloader, and this will erase the data on the device, to prevent data theft or compromise...

And even if you do root your phone and dd the storage, you'll only be able to conveniently restore to an identical (or the same) phone. I generally prefer Android to iOS, but they're not even on the same planet in terms of backups.

"developer mode" is typically a custom recovery environment that requires an unlocked bootloader to be flashed. A nandroid backup is effectively a dd image.

It's a bit messier if your data also lives on an internalized sd card.

Even if it id, is that an acceptable mechanism for users to take backups of their mobile phone?

> Android does not allow you to take complete backups. Let alone "built-in".

Android has had full system backup capabilities through `adb backup` for years. It does not require removing carrier locks or rooting and has been available since Android 2.x iirc.

I've used this to transfer all of my apps, app settings, and system settings between all of my Android phones:

Nexus One -> Galaxy Nexus -> Note 3 -> Galaxy S6 -> Galaxy S8 -> Galaxy S9 -> Galaxy S10 -> Z Fold 2, all with one continuous chain of backup and restores via `adb backup` and `adb restore`.

These restores sometimes even worked flawlessly across different Android OS versions! Sometimes this has caused a lot of weird issues wrt system settings, so admittedly this process can be quite buggy.

> This is false. Android has had full system backup capabilities through `adb backup` for years.

Apparently this is false, because apps can "opt out" of ADB backup and many do (see other comments), furthermore it doesn't backup the entire phone, but only the system image (partly). Does it backup the root state of the phone? Nope. Does it backup the restore partition of the phone? Nope. Making it a "maybe full system backup but not full system image backup that is kind of buggy". In other words, like I wrote earlier: not a -full- system backup at all.

I was specifically talking about effortlessly backing up and restoring a full system image. Blackberry OS10 style: plug in phone, press "backup system image" and get a carbon copy of EVERYTHING that runs on the phone that can be restored to a new or existing phone with 1 click. Your post confirms that this is not possible in Android: using ADB is not "effortlessly" and it's not a full system image backup.

Even if I would backup and restore from and to the exact same rooted phone (that's all I'm asking), the restored backup would not be the same as whatever was on the phone when the ADB backup was pulled. Nandroid can do this, in theory, with a lot of hassle (but not on my phone, because TWRP for my phone doesn't support decryption of the system partition).

Many apps opt out of including their state in "adb backup" or act oddly when restored. Maybe this changed in the past few years, but it is still nowhere as complete as any automated or manual iOS backup.

When I last tried, a lot of apps opted out of adb backups rendering it pretty much useless.

Does it automatically run when I leave my phone on the charger for the night?

It can if you charge from your PC and set up some very convoluted scripts (not recommended).

I use `adb backup` solely as a means of transferring my settings & app library between devices.

These are full system backups including potentially gigabytes of APKs, so I wouldn't want to run it every night. It is possible to use `adb backup` to only backup settings (no app files) if you want a lighter backup, but those backups aren't as useful for my purposes.

Thanks for the answer. I just wanted to highlight that, I can just take my phone for the day, throw it under a bus, go to an apple store, get a new phone and continue where I exactly left off (minus a couple of 2FA keys, which I have backups of).

This is what I like about iOS. I tested this method a couple of times (with less destruction though), and it just works.