Change package name/app id of an app on the main repo

Is that possible/feasible?.

I would like to change app ids for KOReader and Coolreader

There’s no problem upstream as I’m contributor on both projects.

The rationale with KOReader change is in https://github.com/koreader/android-luajit-launcher/issues/304. Changing the package name would prevent signature problems and the main package listed in F-Droid client when it gets updates from a different channel. Sadly I didn’t think about it when we implemented the changes required for inclusion: https://github.com/koreader/koreader/issues/2040

In the case of Coolreader some changes are needed to remove GMS from the fdroid build: https://github.com/buggins/coolreader/issues/284.

In both cases the change would be the same: append suffix .fdroid to the package name:

org.koreader.launcher -> org.koreader.launcher.fdroid
org.coolreader -> org.coolreader.fdroid

Both apps keep their inner settings in the filesystem, so the change on the package name wouldn’t prevent users to repurpose their settings on the new package.

I’m aware that things could be a bit difficult. Users would need to uninstall the APK or install the new one and have two different copies of the same problem. No idea about infrastructure/metadata/etc.

Generally we regard it as a new app. We can notify users to install the new app in description.

I wish there was an easier way to do this. I had to do this on my repo recently, and geometric weather also went through this.

Some limitations (for example, moving preferences) would need to be handled by the app directly, but maybe it’d be nice to add a tag to the metadata saying this has been replaced and listing the new app’s id

thanks for your comment!!

Is it possible to remove the old packages and keep just the newer ones?

It doesn’t need to be at the same time, but a couple of months after the new ones are pushed. Sounds a bit cleaner than having both packages on the same repo :slight_smile:

We can archive the old one when the new one is available.

What’s the problem? Do users want to install both versions of the app (built by you and by F-Droid) at the same time?

Maybe problem is a big word. It just happens that the same package name is shared across 2 different build types. The issue is with Google lack of clarity of why an install failed.

I do remember both bug reports and forum questions related to this issue, but can’t locate most of them. Just a sample in https://github.com/koreader/koreader/issues/6698

Some people discover the app through F-Droid, catch a bug, report it and receive the answer: fixed in today’s nightly. Since fdroid releases the package on tagged releases some users might be tempted to check if their issues were, indeed, fixed. This would lead to the usual dance:

What’s a nightly? -> Here’s the nightly http://build.koreader.rocks/download/nightly/ -> APK failed to install -> open bug report.

That could be solved with a different package name (as others app have, for instance Librera). People downloading from github could still use their f-droid client for other apps without the github package appearing as installed. F-Droid users could check if the last nightly fixed a bug without having to uninstall the APK first.

Keep in mind that KOReader is a very niche app, so the total number of users affected shouldn’t be too high. It just happens that we’re not in Play Store (and we won’t) and F-Droid is the easiest way of getting the apk installed on Android. Also the F-Droid build requires less permissions and is a bit more secure, so I would recommend it for most users that don’t want to be on the bleeding edge.

Why not have a different package id for your nightlies? Then the id for the fdroid release version can stay as it is.

Thanks for the suggestion. That’s not an option. All the infrastructure for OTA updates relies on intercompatibility between stable and nightly channels.

intercompatibility between stable and nightly channels

How do you handle downgrades? I mean from a nightly (higher version code) to a stable (lower version code).

Downgrading an APK is not possible without install the new one first :).

But that’s a valid point I didn’t think about. I guess we can give explicit hints on android.

diff --git a/frontend/ui/otamanager.lua b/frontend/ui/otamanager.lua
index 76de33d9..99513dcf 100644
--- a/frontend/ui/otamanager.lua
+++ b/frontend/ui/otamanager.lua
@@ -232,6 +232,19 @@ function OTAManager:fetchAndProcessUpdate()
                                  BD.ltr(ota_version))
         local update_ok_text = _("Update")
         if ota_version < local_version then
+            if Device:isAndroid() then
+                UIManager:show(ConfirmBox:new{
+                    text = T(_("The currently installed version is newer than the available version.\nYou'll need to uninstall the app before installing a previous version\n. Download anyways?\nInstalled version: %1\nAvailable version: %2"),
+                        BD.ltr(local_version),
+                        BD.ltr(ota_version))
+                    ok_text = _("Download"),
+                    ok_callback = function()
+                        Device:openLink(link)
+                    end,
+                })
+                return
+            end

             update_message =  T(_("The currently installed version is newer than the available version.\nWould you still like to continue and downgrade?\nInstalled version: %1\nAvailable version: %2"),
                                 BD.ltr(local_version),
                                 BD.ltr(ota_version))

I would use this in cases like Geometric Weather, where a package id is changed and replaced with another.