Mastodon IzzyOnDroid


Say thanks!

Privacy Links
↓ Your product here? ↓
Das Inoffizielle Android-HandbuchAndroid kennenlernen, Tipps & TricksDas Inoffizielle Android-Handbuch
Android kennenlernen, Tipps & Tricks
Buy at Amazon for EUR 16,99
Das Inoffizielle Android SystemhandbuchTiefer ins System einsteigenDas Inoffizielle Android Systemhandbuch
Tiefer ins System einsteigen
Buy at Amazon for EUR 7,00
Die besten Android-AppsDen Androiden austattenDie besten Android-Apps
Den Androiden austatten
Buy at Amazon for EUR 5,00
 
dehelp

Join the F-Droid Team: Tasks of a Reviewer

check list
Working on my check list…

You’ve read the phrase of the F-Droid team being „permanently understaffed“ at least once a week – and get as tired about it as those repeating it already are? Well: welcome to the … team. Yes, you. If you are an active F-Droid user loving and living the F/LOSS idea, you already have the necessary essentials for that. True, there are complicated things at F-Droid I don’t grasp myself – but at the other end of the scale there are also easy tasks not requiring much „tech-knowledge“, or can be learned easily.

This article should help you getting involved, introduce you to tasks performed during „app review“ at RFP and at Merge Requests with fdroiddata. It will hopefully also serve as reference during your own reviews. Recordings of related workshops can be found in my Peertube channel.

Let me take you through the „life-cycle“ of a review as I perform them daily to show you what tasks are involved. When I started several years ago, it was a little part of the easy steps I could cover. I was no Android developer (and still am not), nor a packager (uhm, this part still holds mostly true – though I meanwhile pushed the „Merge“ button on a few new apps and updates myself). I got more experienced by „jumping in“, trying to help, asking those already there whenever I missed to understand something. Today I’m one of the maintainers and able to give you a rough guide to follow me on this path.

So, here are the steps I usually perform when a new app was requested to be listed with F-Droid. This usually starts at RFP as an issue and then passes to fdroiddata – but sometimes directly starts as a merge request (MR) in the latter. I try to shed light on both places. For now these are just some bullet-point list, but I hopefully will refine them later:

RFP/MR pre-check

RFP: bot results

At the end of this, metadata would be prepared (unless there’s already a related MR having them, in which case they are checked for correctness/completeness). You can find an example metadata file below.

MR: bot results, other CI pipelines

You find those results directly below the initial comment, where it says something like „pipeline #128817296 passed for e5a357b5 on johndoe:master“. Tap the symbol on the right to that string to get a popup of all pipelines, then tap the one you’re interested in. This will open the logs. Don’t be shocked, the first time this might look like gibberish – but one gets used to that… somehow.

MR: APK test

On a successful build, the APK can be downloaded from the artifacts of either the CI build or issue-bot’s build. To find it, open the corresponding log, tap the „Browse“ box in the right-hand side-bar, enter the unsigned folder, download the APK.

Summing up

So whether you’re a geek, a nerd or just an enthusiast – you’re welcome to join us, to help us improving (response times at) F-Droid. Thank you for considering!


Appendix

I’ve collected some details over the past few years. Some of those links already have been integrated above, but let me concentrate them here:

Example metadata file

This is how a complete metadata file would look like; what each field stands for and what it should contain is explained on the Metadata page in F-Droid’s documentation. Let’s pretend we have an app called „My Example App“, going by the packageName com.example.app – so our file is named com.example.app.yml:

AntiFeatures:
  - NonFreeNet
Categories:
  - Theming
License: Apache-2.0
AuthorName: John Doe
AuthorEmail: johndoe@example.com
AuthorWebSite: https://www.example.com/
WebSite: https://www.example.com/myApp
SourceCode: https://github.com/johndoe/my_example_app
IssueTracker: https://github.com/johndoe/my_example_app/issues
Translation: https://github.com/johndoe/my_example_app/wiki/Translation
Changelog: https://github.com/johndoe/my_example_app/releases
Donate: https://github.com/johndoe/my_example_app/wiki/Donate
Liberapay: johndoe
Bitcoin: <BitcoinAddressHere>

RepoType: git
Repo: https://github.com/johndoe/my_example_app.git

Builds:
  - versionName: 1.0.1
    versionCode: 2
    commit: v1.0.1
    subdir: app
    gradle:
      - yes

AutoUpdateMode: Version v%v
UpdateCheckMode: Tags
CurrentVersion: 1.0.1
CurrentVersionCode: 2

Note that not all fields are mandatory – if there are no AntiFeatures, the entire AntiFeature block would simply be left out. Mandatory are, however: at least one category, the license, SourceCode link, RepoType & Repo. Summary & Description shall come via Fastlane, so they are missing here. From the Builds block, versionName and versionCode must correspond to CurrentVersion resp. CurrentVersionCode at the end, commit should be the tag name. In this example, the tag name is the versionName with a prepended v, so AutoUpdateMode becomes v%v (with %v standing for versionName).

There are more complex definitions (e.g. with Flutter projects) – but those are for „advanced contributors“ to handle. Keep in mind that packagers will cross-check your prepared metadata, so no worries if they’re „not perfect“. And while the Builds block as well as the last 4 lines are required as well, they can be set up with the MR – as often versions have advanced before metadata are merged, they usually need to be updated then anyway.

fdroidhowto

2020-12-20 (2021-09-19)