Support app revisions for updates where upstream version doesn't change
Right now when a build succeeds but the resulting apk is broken or we need to otherwise iterate on the build this is quite hard to do. See here for a description of the problem: #207 (closed)
I'm also right now looking to solve the same problem for Andor's Trail
Debian has the concept of debian-revisions after the upstream version number, i.e.: 1.0.6-1, 1.0.6-2, etc... these can become more complicated than that and serve for quite a few purposes (backports, rebuilds against newer library versions, packaging fixes, marking patched or otherwise altered upstream code, etc... ).
This would also solve the problem with rebuilds needed because of the signature algorithm deprecation for a lot of apps.
The hard part is how to do this in the android ecosystem, the only thing that counts for android is the version code. We can't arbitrarily bump this because we depend on being in sync with upstream apk versionCode for update checking and possibly other things and upstream might only use single step increments of the VC between versions.
-
We could decouple us from the upstream version codes completely and just build apps with a monotonic sequence of versionCodes. But this would be a change with very wide implications and has potentially a lot problems ahead.
-
We could also somehow build in top of Vercode-Operation wich basically leads to for any app using this but in a less fundamental way. This still seems quite messy and might be hard to maintain.
-
We build the revisions with the same versioncode. This would require some changes for server to handle this correctly and some way of marking this in the metadata, like:
Build:1.0.1,101-2
for the second revision of the versioncode 101 build. Then the client will need to know this is actually an update for the old 101 version. And the last part it will need to install the apk when updating with the--reinstall
flag. This works fromadb
so I guess this would work from thepm
api?
I think 3. might be the cleanest and least invasive change, if this is doable on client side. What do you think?