seedvault

e 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...