The background: I’m the developer of an app (the scrabble-playalike CrossWords) distributed via fDroid (and the Google store, of course). It was packaged by someone else, and I didn’t even know about fDroid until some users contacted me to tell me it was broken. Since then I’ve been submitting pull requests on the metadata file to keep it up-to-date.
Now Google’s banning one of the features I like best and think users will miss, play-via-SMS implemented using “data” SMS (“narrow band sockets”, for the other greybeards here. I’m making the necessary changes to remain listed on the store, but I’m NOT removing the feature from other variants, including the one for fDroid. Ideally I’d tell unhappy users of the Google Play version to switch to the fDroid version, but that’s not easy – because the two apps have the same appID, but are signed with different keys.
The Question: is there history or best-practice available for allowing an f-droid build to replace a Google build without losing persisted data (as happens if you uninstall in between.) Obviously this would require some user interaction, but I’d hope to make it really simple for them.
I’m just beginning to think about how to do this. If other app developers have been through the process before I hope to learn from them (you).
One solution would be to provide a way for your users to export the app data and then import it in the new app.
(Power users might already be able to do this with adb backup.)
You might also want to have a look at reproducible builds. If your upstream APK and the one we build match, we can publish your (signed) APK on F-Droid. This way, users can switch between the Play Store version and the F-Droid version.
However implementing reproducible builds can be quite a lot of work, depending on the complexity of your app.
I already have a menuitem to export data into a world-readable area that survives uninstall and then another to import from there. So for the most capable users I could write out a bunch of instructions that would let them upgrade using this mechanism.
I’m worried about the rest of the userbase though…
Maybe in an ideal world the old and new versions of the app (with different signing keys, or different appIDs) would cooperate: the old would honor an Intent that caused it to export that data, and the new would honor one that’d cause it to import it. Then the fDroid app, which would be complicit in the upgrade process, would trigger those two intents at the right times.
Obviously this is a lot of work. As I said, I’m new to the f-droid world and wasn’t involved in the original decisions to package my app (leading e.g. to its having a different signing key.) I was hoping that enough other authors had encountered this that there’d be support for fixing things.
This is normal. F-Droid wants to prove that the binary was built from the given source code, so it has to build the app from sources, and of necessity sign it with a key generated by F-Droid.
The way around this is via reproducible builds. That is to say, you have to build your app in such a way that it matches F-Droid’s build, bit for bit. If the builds match, the server can then distribute the app with your signature on it.
I’m making the necessary changes to remain listed on the store, but I’m NOT removing the feature from other variants, including the one for fDroid. Ideally I’d tell unhappy users of the Google Play version to switch to the fDroid version, but that’s not easy – because the two apps have the same appID, but are signed with different keys.