F-Droid APK

[gaul]

Given that there is no direct package from Fox any more perhaps we should try to get F-Droid to include this? I don't think most users will know how to compile themselves and relying on third-party packages will have less trust. References #17.

[courville]

As an interim temporary solution, you can use obtainium to pick the apk that I generated on my fork (for personal use), see https://github.com/courville/tt-rss-android/releases. But I agree we need a long term solution.

[gaul]

Upstream issue: https://gitlab.com/fdroid/rfp/-/issues/135

[courville]

@gaul, I think a new submission should be done instead of reopening this one to get all the right pointers to this new repo.

[gaul]

FDroid packaging made some progress: https://gitlab.com/fdroid/rfp/-/work_items/135#note_3266411953 . One remaining issue is getting a non-zero versionCode. fox introduced a dynamic scheme in 712afbc which seems to confuse FDroid. Claude suggests:

Looking at org.fox.ttrss/build.gradle:100-130, getGitVersionCode() calls git log --pretty=%ct -n1 HEAD and formats the commit date as yyyyMMdd. Two things prevent this from working in F-Droid's scanner/builder:

1. The RFP scanner does static parsing, not execution
   F-Droid's issuebot parses build.gradle without evaluating Groovy, so getGitVersionCode() is never called — it reports versionCode: 0 by default. This is informational and won't block the actual build, but it's what you see in the note.

2. F-Droid's buildserver needs either:

• A literal versionCode in the Gradle file at the built commit, so their static metadata extraction works; OR
• Explicit versionCode: / versionName: in the fdroiddata recipe (metadata/org.fox.ttrss.yml), one per Builds: entry. This is the normal path — the recipe author hardcodes them per release tag.

Either way, F-Droid builds from a specific git tag (set via commit: in the recipe). Your current scheme depends on HEAD's commit timestamp, which is fine if the recipe pins commit: — git history is present in their builder, so git log -n1 HEAD will succeed.

What would make the dynamic computation "just work":

1. Tag releases with annotated tags (e.g., v25.09). The fdroiddata recipe then references those tags and your Gradle code produces a deterministic versionCode from the tagged commit's timestamp.
2. Keep a graceful fallback (you already return 0 on failure at line 128), but consider making it a real number read from a checked-in version.properties or similar, so static scanners and non-git builds produce a sensible value.
3. Document the derivation in the repo so the F-Droid packager (licaon-kter) can write the recipe with matching literal
   versionCode/versionName fields — F-Droid generally prefers recipes where the expected values are explicit and reproducible.

The shortest path to unblocking the RFP is option 3 combined with tags: pick a tag, compute yyyyMMdd from its commit timestamp, and hand licaon-kter the exact versionCode/versionName to put in the recipe.

@supahgreg Perhaps the easiest way to unblock this would be to set versionCode 20260420, versionName 26.04-0276170d in a commit, tag 26.04-xxxxxxxx, then revert the fixed version code?

[supahgreg]

@gaul 26.04-ab99085d