Yes, I agree with you - f-droid shouldn’t crash. I’ve created an issue report: App details: java.lang.NullPointerException (#2598) · Issues · F-Droid / Client · GitLab
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
fox
12
maybe they’ll figure out why it crashes and what needs to be done to fix the repo. 
1 Like
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?!
fox
14
have you tried adding the same repo using foxy droid?
Yes, Foxy Droid works and is a workaround for me.
Meanwhile F-Droid team has written:
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?
Don't crash when app has no signer at all (!1217) · Merge requests · F-Droid / Client · GitLab will fix the crash, but users won’t be able to update the apps without SHA256 signer, because fdroidclient doesn’t support the old MD5 sig anymore, so it considers the signatures to be incompatible.
(Torsten Grote, App details: java.lang.NullPointerException (#2598) · Issues · F-Droid / Client · GitLab)
So I think that’s the point, why Foxy Droid still works.
Is it possible that you update to a newer version of fdroidserver?
fox
16
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.
fox
17
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.
i.e. https://gitlab.tt-rss.org/tt-rss/tt-rss-android/-/jobs/65/artifacts/browse/org.fox.ttrss/build/outputs/apk/fdroid/ etc
to make it a bit easier to figure out CI could generate a release linking to the artifact.
fox
18
to give a concrete example on how this could work:
https://gitlab.tt-rss.org/main/the-epube-android/-/pipelines/161
above pipeline builds an APK and creates a project release visible here
https://gitlab.tt-rss.org/main/the-epube-android
which leads to here
https://gitlab.tt-rss.org/main/the-epube-android/-/releases
where there’s an APK link
the whole thing is built using a dead simple CI template (https://gitlab.tt-rss.org/ci/ci-templates/-/blob/master/.ci-build-apk-fdroid.yml) which is about as straightforward as you can get.
this is how this should work. screw stupid bespoke repos and screw f-droid in particular.
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.?
fox
20
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.
https://gitlab.tt-rss.org/tt-rss/tt-rss-android/-/releases - installing an APK from here should just work.
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.
1 Like
fox
21
update: fdroid repo / web glue is no more.
1 Like
fox
24
i’ve updated android build CI pipelines so that
- gitlab releases contain apk version info in readable form - https://gitlab.tt-rss.org/tt-rss/tt-rss-android/-/releases/
- json files necessary for in-app update notifications to work are also generated and published during build - https://gitlab.tt-rss.org/tt-rss/tt-rss-android/-/jobs/611
1 Like
I might have a very old version, is it expected that I can not easily update to the latest gitlab release?
fox
26
if you installed from play store originally, you’ll have to reinstall because the signing key is different. it’s the same key from then on though.
1 Like
Yeah, now the build number hast a -fdroid suffix, I guess I was still on a Play Store version. Feels a little bit snappier, should not have waited so long for the update 
Did I understand correctly that it now reaches out to your server to check if there is an update when the app starts? Would it be possible to make this optional and only trigger this manually?
fox
28
nope, can’t disable it at the moment. i could make an opt-out checkbox i guess. 
its a simple json file https://srv.tt-rss.org/fdroid/updates/org.fox.ttrss.json
Sure, it’s not a big problem and I hope the updater library has something implemented to not block the app if some reason the server goes offline or at some point a wild CI config created a very big file, which is downloaded automatically by all users of the app at start.
Sure, the playstore and f-droid are doing the same, but it just does not feel right for a self-hosting crowd of people (which are too lazy to self-built an android app).
Looking through the code it seems like it already loads the settings, but from my glances over the code I was not able to understand how the settings UI is build (and I guess it does not fit to any of the current category)? So if I’m bored I would try to have the Android Developer Experience and create a try creating a PR.
Could the “Debugging” category maybe be the “Application settings”? But this would need new translations, maybe I will not bother implementing it
fox
30
now i remember. i haven’t bothered to add an update opt-out checkbox because, well, to get to auto updates you need to download and install the APK off my server which implies rather impressive amount of trust, because android is a sieve of vulnerabilities.
trying to sever all further connections to the exact same infrastructure which somehow becomes a privacy-invading nightmare or w/e directly afterwards doesn’t make a lot of sense to me - at this point, if i was a bad actor, the damage has already been done.
lazy, technically inept, paranoid people are not the userbase i’m interested in. if using my software doesn’t feel right for them, they can collectively fuck off and use something else instead.
that said, i’ll make a note to add an opt-out knob for updates.
