zlacker

>>skille+(OP)
I feel like the elephant in the room is that there's no phone battery that's going to stay useful in anywhere close to that time frame, and replacing phone batteries is usually a losing proposition. I've tried, several times. Fake, low-quality batteries are rampant (usually degrading within weeks), and genuine ones are prohibitively expensive -- usually a significant fraction of the cost of a new phone.

>>wheels+B7
Even if properly replacing the battery costs 2/3rds of a new phone, I'd be happy to pay that a couple times over its lifetime to squeeze extra years out of it and reduce how often I have to go through the gruelling process of successfully migrating everything over to a new phone (it's a real pain for those who prefer to avoid forking your data over to Google, which I gather is required by the built-in options like cloud backups and D2D transfer).

>>rkager+3y
> gruelling process of successfully migrating

I hate this. Why do I have to relogin to every app on a new phone? Why are some apps missing after every migration? Why do some apps just randomly lose all config and settings and force you to set them up again?

I want Google/Apple to force app devs to make backup and restore seamless. Like, if I am halfway through typing this comment on HN and then lightning fries my phone, when I restore to a new phone I want the exact same chrome tabs open with the same half-written comment. I don't want to have to battle to re-pair my printer or watch. I don't want stupid cookie warnings on every website again. I don't want to have to retrain every single fingerprint. I don't want to yet again opt out of data collection. I don't want to re-accept the same T&C's for photo backup I already agreed to last year, and the year before, and 10 years before that.

Please... just make migration work the way it should have always worked.

>>london+vB
Why do I have to relogin to every app on a new phone? Why are some apps missing after every migration? Why do some apps just randomly lose all config and settings and force you to set them up again?

Why indeed.

A major part of the problem is instead of charting a coherent strategy for backups from the beginning, Google constantly changes their minds as to how it should work and what behavior is expected from users and app developers.

Once upon a time a simple pair of adb backup and restore commands did the trick.

Then they introduced the android:allowBackup="false" app manifest flag[1], which silently breaks adb backup. (Yes, this got me once, resulting in lost data). That effectively wrenched sovereignty over your data out of your hands and shifted its control into the hands of app publishers, many of whom couldn't be bothered to change defaults. There are also limits (e.g. even when enabled, I gather Google's cloud only allows 25MB of data per app). I think more recently it's been enhanced with a flag that allows backups only if encrypted.

All this degraded the user experience upgrading phones, so they carved out a Google-only exception in the form of a Device-to-Device (D2D) transfer process which has the privilege of totally ignoring the flag (so it can capture apps that advertise themselves as do-not-backup). But I've never seen a means of triggering that process without first being forced to turn on backups to Google servers[2], and allowing Google Play services to collect data like your email address.

It's a horrible state of affairs that makes it impossible for third-party solutions like SeedVault to work reliably (to the point where users have suggested bastardizing/impersonating D2D to bypass the restrictions[3][4]).

I don't understand why anti-trust efforts aren't examining lock-in like this, which forces you to use Google's cloud instead of your own, and intentionally creates an unequal playing field for competitors whose clouds you might trust more. It causes real harm to users like me.

The only reliable method is rooting your phone, which recovers your sovereignty and allows apps like Titanium to bypass all this nonsense. I suspect that's a major reason some people still choose to root, despite all the security warnings against it. Of course depending on what exactly you're backing up you can still run into issues if restoring to a different model phone or version of the OS (although in the past I've had some success surgically extracting the desired records via a sqlite explorer).

I wish someone would compile a flavour of Android with a Developer Option that undoes or ignores the effects of android:allowBackup. Depending on your viewpoint that would "break the Android security model", or fix it.

Some users have even resorted to decompiling their app's stock APK, patching android:allowBackup to true, self-signing and recompiling [5], which I presume would have to be done after every app update (maybe there's a niche market opportunity for a service that automates this).

If I created a mobile device platform I'd make darn sure critical functions like backup, restore, migration, maintaining "hot standby" devices, etc. just work(tm), seamlessly and reliably, out of the box. The architecture would make it easy and simple (instead of difficult and convoluted) for developers to ensure user data is captured (incidentally the normalized Palm pdb system didn't do a bad job of that), provide tools and examples of how to maintain forward compatibility, and generally funnel developers into good habits. It's not an easy problem to solve but I'm convinced it can be done with 100X more elegance. And users would have the power to backup to wherever they choose, with an easy way to custody their own encryption keys (with peer-to-peer recovery models e.g. X of Y friends or commercial-designates).

[1] https://stackoverflow.com/questions/12648373/what-is-android...

[2] https://support.google.com/android/answer/6193424?hl=en

[3] https://github.com/seedvault-app/seedvault/issues/165

[4] https://github.com/seedvault-app/seedvault/pull/562

[5] https://stackpointer.io/mobile/android-enable-adb-backup-for...