backup, migrate and examine internal data of any F-Droid app
rollback and downgrade to previous versions, test beta versions without loosing data
in short have full control of his own data even on unrooted devices? Isn’t that what FOSS is about?
Turns out that technically F-Droid can do that surprisingly easy. Since all apps are signed by F-Droid it is possible to build 2 additional special versions of every app with lowest and highest possible version number that would be simple archive managers, packing or restoring the private data to/from some publicly accessible place.
Anytime a user would want to backup the private data he would “upgrade” his app to this special version with vers-max, do the backup, uninstall the special app, and if desired install the special version vers-min from where he could install any real version of the app - even downgrade.
Did nobody ever have this idea? Am I missing something? It would need a decent UI so average users could understand and use that but think of the endless opportunities like debugging etc where it would be a life saver.
The data format that apps use changes. If the new version migrates the database to a new structure and you copy that same database to the old app version, it will crash (or, even worse, not crash but do unexpected things). Database changes happen all the time.
If downgrading was that easy, Android wouldn’t restrict it
I know about this problem. However the idea was to do a snapshot of the data before an upgrade. Perfectly doable with this technique.
The other solution, the user could attempt to convert the data between versions. The source code is available so this should not be black magic.
The reason Android restricts downgrades are not purely technical but the same why it allows apps to disable adb based backup: it would break the business model of proprietary apps if people could get at their data. By downgrading apps users could do all kinds of things that creators of proprietary apps don’t like.
No, that isn’t optional.
If F-Droid abused their signing key to add incorrect version codes that would be a massive security issue with retroactive repercussions.
Please explain in some detail why you consider it so diabolical. There would be a new “feature” which nobody is forced to use but can save your a** if an upgrade goes wrong. So where is the problem? Maybe I didn’t explain my idea good enough?
And… if F-Droid decided to screw me it can do so anytime with or without this feature.
Forced? No, but… when I get my hands on your device… I (or the border guard that seized your device) will downgrade the app to the old version that didn’t need fingerprint/password to open… so I’ll bypass the auth, and read all your data/messages/pics etc.
Getting at my own data is the motivation for this proposal so this is not only perfectly ok but desired.
Any app wanting to protect your data by an additional password should use that password to encrypt the secret data, anything else offers a very questionable level of security.
Just like backup by adb F-Droid could have an opt out mechanism for apps that for some reason don’t want it and it should be tagged as Anti-Feature if you ask me.
You may wonder why adb app data backup isn’t good enough for me - well it would be but a surprising number of apps are forced to disable it because Google backup would break them - one such example being Termux.
fwiw apps targeting Android 12 cannot opt-out of backups:
If your app is running on a device with Android 12 or higher and your app targets Android 12 (API level 31) or higher, you cannot disable device-to-device migration of your app’s files. In this case, the system automatically allows this functionality.
Interesting, does that, mean adb app data backup will work for all apps? Somewhat doubt that google will let everyone examine the data stored by your banking apps?
Btw thanks for reminding me of seedvault. Unfortunately it looks like
only a miniscule fraction of Android users can use it as it needs support from the ROM vendor, the rest can in the best case “benefit” from Huawei/Xiaomi/Realme cloud backups that make you agree to dozens of pages of bullshit eulas and technically often suck
Seedvault still won’t deal with apps that disabled backups (for technical or other reasons) which is the subject of this thread
adb backup probably going away soon, making it even more urgent to have an alternative for the majority of users
Nevertheless I would consider it a great progress if F-Droid could list the fact whether an App allows data backups (adb, seedvault, Google cloud) next to the permissions and anti-features. Otherwise most users won’t notice until it is too late.
If people are that much concerned about this, it would be possible to have this as an opt-in feature: offer both versions of an app - one where the user is free to export and manipulate his own data and one where standard android data lock-in can’t be broken.
I am using Unix and Linux systems where every user has full access to his data since 30+ years so I am pretty sure which variant I would choose.
This is not *nix, I think Google might not want Linux (the kernel) in Android anyway, it was nice and useful to get devs and OEMs on board but all this openness costs them money… look at Apple… Google wants more of their pie!
Fully agree this isn’t Linux - but given the popularity of Termux I wonder if I am the only one who would like to see more of the Linux pie than that of vendor lock-in.
F-Droid is making a big difference but having free access to my own user data is another very important aspect.
Now, technically F-Droid can do it. Some people don’t like the idea because they think it loses security. I think there are at least two ways to make the free data access fully optional.
One mentioned above, the other would be an option to re-sign some (or all) apps locally… that way there would be no additional burden for F-Droid to distribute separate apks. This is of course already doable without the help of F-Droid and could also be used to work around issues like the broken Termux:GUI signature or beta testing apps with incompatible signature.
