Below is no longer relevant. Get your APKs from release pages on relevant Gitlab projects. Everything is still completely free with no strings attached.
For people who just can’t stand Google Play there’s a F-Droid repository now.
I have been using the F-Droid version for a while now, but just bought the “Unlocker” app on the Play store in order to contribute. For people who don’t have Play Store installed at all, I suppose the “Donate” and “Patreon” buttons at tt hyphen rss dot org are also viable ways to give money?
But f-droid crashes when I go to the details of the app inside f-droid. I deinstalled tt-rss app (I have updated it some days before via direct download from your website, because f-droid was not working) and installed it via f-droid again. But it crashes again.
I think this is a bug in f-droid … Found no error message or something like that on the quickly. I will be looking at this over the next few days.
Or am I on the wrong way and the jar and apk signing keys doesn’t have to be the same?
BTW: The stack trace in f-droid, when opening the app details of “Tiny Tiny RSS” after it was installed (unless it isn’t installed app details can be opened):
java.lang.NullPointerException: Attempt to invoke virtual method 'boolean java.lang.String.equals(java.lang.Object)' on a null object reference
at org.fdroid.fdroid.data.App.findSuggestedApk(App.java:555)
at org.fdroid.fdroid.data.App.findSuggestedApk(App.java:537)
at org.fdroid.fdroid.data.App.update(App.java:299)
at org.fdroid.fdroid.views.AppDetailsActivity.updateAppInfo(AppDetailsActivity.java:747)
at org.fdroid.fdroid.views.AppDetailsActivity.onVersionsChanged(AppDetailsActivity.java:734)
at org.fdroid.fdroid.views.AppDetailsActivity.$r8$lambda$lgtpLd3OEgQKVJA9DmWlIbk-RDQ(Unknown Source:0)
at org.fdroid.fdroid.views.AppDetailsActivity$$ExternalSyntheticLambda2.onChanged(Unknown Source:4)
at androidx.lifecycle.LiveData.considerNotify(LiveData.java:133)
at androidx.lifecycle.LiveData.dispatchingValue(LiveData.java:151)
at androidx.lifecycle.LiveData.setValue(LiveData.java:309)
at androidx.lifecycle.LiveData$1.run(LiveData.java:93)
at android.os.Handler.handleCallback(Handler.java:942)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:226)
at android.os.Looper.loop(Looper.java:313)
at android.app.ActivityThread.main(ActivityThread.java:8757)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:571)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1067)
the repo is supposed to be unsigned, idk if it matters or not.
i’ve just added the repo to foxy droid (which is a imo much better fdroid repo client) and everything seemed to work properly. regardless of something being wrong with the repo (or not) the application shouldn’t crash. maybe report this to fdroid app devs?
But … I think there is another issue with the repo signature …
I tried to pass the crash and also tried to throw away the signature. Then I get the details screen, but no compatible app versions are shown.
As far as I can tell your repo is signed. F-droid seems to use the signature of index-v1.jar
Yeah, I tried to fix it on my own in f-droid, but unfortunately I’m lost in f-droids source code. I’m coding for years and also as profession. But Java just as a hobby and I only have very limited knowledge in Android development.
I’m excited what f-droid team will tell. - Because what’s strange: If it’s a signature failure - why can it be installed the first time?!
this repo is created with a very old version of fdroidserver which publishes signature information with MD5 still. Is there any way the repo owner could update to a newer version?
that entirely depends on how backwards-compatible the newer version is. do they have a migration guide or something? idk.
well it won’t crash but without updating the apps it makes the whole thing useless then.
honestly i’m not sure if the repo is even needed. all apks have built-in update notifications anyway. it might be easier to just keep those with direct downloads and remove the fdroid thing altogether. it feels like an unnecessary kludge.
e: it would be a lot easier for my CI processes anyway if i won’t have to invoke their super-slow docker-based repo builder.
the whole “we’re not going to allow you to install the apps because of some imaginary security circus-tier scenario we’ve imagined where someone goes for a repo signature collision (i guess) which would also involve an SSL MITM and somehow bypass APK signature afterwards” doesn’t fill me with desire to deal with any of this at all.
now that i think about it, i’m using gitlab already anyway so it would make sense to use gitlab CI for build artifacts (in this case, APKs) instead of doing this song-and-dance copying the file somewhere for no particular reason.
For me: I would be happy, if there’s a f-droid repo. But - I got your point above and I’m not the person who has to maintain the repo.
So for me it’s also okay to rely on the app internal updater or something similar (e. g. I track a lot of software releases [Linux/Windows] on github through the RSS-feeds).
I don’t understand what the gitlab CI changes (sorry, I’m technically not really on this topic) beside the app internal updater.
If I have two wishes, they would be:
Delete the f-droid repo, if you don’t maintain it in the future - so it’s clear for the user
What do I have to “migrate” to the “new” update method? Do I have to reinstall the app etc.?
basically it’s something that is a lot easier, for me, to deal with. I’m using CI anyway so it makes sense to use it for binary releases too, that’s pretty much the gist of it.
yep.
no, you won’t have to reinstall anything, the APK is signed with the same key.
fixing in-app update notifications to point to gitlab would involve some digging so i can’t give a ETA. in any case, tt-rss apk updates very rarely so it’s not a big deal.
as a workaround, you can subscribe to the project RSS feed, if there’s a new master commit = there’s a new release.
