Forkgram update from GitHub installs as a separate app next to that from F-Droid — instead of seamlessly replacing it

[kirisakow]

As I downloaded and installed on my Android 13 today's 12.3.2.0 hotfix (see #380) from GitHub to patch the hapless 12.3.1.0 previously downloaded from fdroid, the long awaited hotfix from GitHub (many thanks BTW <3) has been installed as a separate app, leaving me with a brand new Forkgram 12.3.2.0 on the one hand, and an unpatched Forkgram 12.3.1.0 on the other.

It's not the first time I get a hotfix from GitHub for a FOSS app originally installed from fdroid: this happens pretty regularly — mostly with NewPipe. But it is the first time an update is treated as a separate app. So I asked Claude who explained

Android uses the app's signing certificate as its unique identity. An update can seamlessly replace an existing app only if:

• Package name matches (e.g., com.example.app)
• Signing certificate matches - the new APK must be signed with the same cryptographic key (...)

Do you guys use the same signing certificate across repositories?

[23rd]

F-droid version is only for f-droid updates, Github version is only for updates from Github.

[kirisakow]

FYI it usually takes >= 48h for a release to be pushed to fdroid users. E.g.: the now 3 days old 12.3.1.0 release reached me from fdroid only about 10—12h ago 💔

Other than that — no big deal, sure. Can wait.

[kirisakow]

FYI it usually takes >= 48h for a release to be pushed to fdroid users. E.g.: the now 3 days old 12.3.1.0 release reached me from fdroid only about 10—12h ago 💔

Other than that — no big deal, sure. Can wait.

Eventually, I must admit that it is a big deal. I spent quite a frustrating weekend waiting for the hotfix — which arrived today, Monday, just an hour or so ago — i. e. 48h or so after it has been released here on GitHub. For a hotfix, it was cold AF 💔

Thus I reopen this issue. If you guys can do something about that signing certificate (or whatever the cause is), that would be greatly appreciated.

[23rd]

Once again.
F-Droid users trust this source because they know for sure that the binary APKs from this repository are compiled by them on their side and they act as a trusted source.

If I compile F-Droid-compatible APKs myself, the whole point of this “trust” will be completely lost.

If you don't care about this and don't care who to trust, then why not just use the version from Github, which gets updates instantly?

I just don't understand why I should do this. If I start compiling F-Droid versions myself, then why would this F-Droid version exist at all?

[kirisakow]

I just don't understand why I should do this. If I start compiling F-Droid versions myself, then why would this F-Droid version exist at all?

I'm not asking you to give up on F-Droid. I've got a better idea of what F-Droid is all about, and I'm coming to terms with the fact that there's not much you can do about it. Thank you for your time, effort, and explanation.

If you don't care about this and don't care who to trust, then why not just use the version from Github, which gets updates instantly?

Well, it's simply because Telegram has a few dozen local parameters, and Forkgram has even more of them — which is great, per se. However, you can't export local settings from one installation and import them into another. This means that installing a brand new Telegram client requires the user to perform a long and cumbersome manual setup process.

But if that's what it takes to avoid that 48-hour wait from happening again, I'll definitely have to install a separate Forkgram instance from GitHub, too, then set up each option manually. I'll also have to keep apps from both sources — at least for the time being — just in case.

[zc-devs]

However, you can't export local settings from one installation and import them into another. This means that installing a brand new Telegram client requires the user to perform a long and cumbersome manual setup process.

Agree. This could be a separate feature request.