After implementing the first part, the repository is created and working: once you have included it in the F-Droid client of your choice, it can be browsed. But it looks a bit meager: no screenshots at all, and probably even an icon is missing here and there. This is quite unsatisfying for most – which is why this article should take care of the corresponding extensions.
Many additions build on the structures of Fastlane. I will describe the respective structure parts at the respective places. For a general overview with further details (e.g. recommended sizes for graphics) I would like to refer to my Fastlane Cheat Sheet as a reference. As an „example app“ I will use
com.example.app again, and also use the directory structure mentioned before.
Grapics: Screenshots & more
Since this is the most important thing for most of you, we will start with the graphics (and especially the screenshots) right away. The main thing first:
Graphic files need to be placed inside the
So that’s what we do now, and create a directory there for our app:
cd /var/www/fdroid/repo mkdir -p com.example.app/en-US
Oops: What is the
en-US doing there? F-Droid is inherently multi-lingual, and American English is used as a „fall-back“ for anything that is not available in the user’s language. So to make our graphics available to all visitors of our repo regardless of their language settings, we put them in
Directly in the just created directory two graphics can be placed: An app icon (as
icon.png) as well as a so-called „feature graphic“ (
featureGraphic.jpg), which is then displayed in the detail view in the client above the app description. For the screenshots themselves we create another directory below
phoneScreenshots. It would be possible to create more directories (e.g. for screenshots of 10 inch tablets, Android TV etc.) – but we don’t want to overdo it
Please keep in mind for all graphics that some of your visitors might have...
- a weak network connection
- a small display
- a low-end device
So please try to:
- keep file sizes small. With the exception of the icon (which must be a PNG), converting to JPG often helps. In my repo I still keep the feature graphic at 512x250 and resize screenshots to a width (portrait) or height (landscape) of 350px.
- no (exaggerated) „framing“. The small „screen estate“ should allow essential details to be seen. Large „blank areas” around the actual screenshot don’t help anyone.
You don’t have to limit yourself to the
phoneScreenshots directory, but can of course use the directories described in the Fastlane Cheat Sheet for the other formats as well. The decision is up to you.
Text files are placed inside
Again, the structure follows that of Fastlane. So let’s give our example app English and German descriptions:
cd /var/www/fdroid/metadata mkdir -p com.example.app/en-US mkdir -p com.example.app/de
OK, we already looked at
en-US in the screenshots. Shouldn’t it then also be called
de-DE? As long as you don’t want to use certain language variants (e.g.
de-DE) in parallel, suit yourself. Only
en-US must exist, because it is used as fall-back – for all other languages the language variant is optional.
As described in the Fastlane Cheat Sheet, the appropriate text files can now be created in each of the language-specific directories. The two crucial ones are:
short_description.txt: short description, maximum 80 characters (anything longer will be cut radically!); will always be displayed in context with the name of the app, so you don’t need to repeat it in the short description. Describes short, crisp and meaningful, what the app is for (so not „Foobar is an app for Foobar”, but better „manage your grumpfels“ )
full_description.txt: Note: „full“, not „long“ – mass ≠ class. Here you can also use simple HTML – e.g. tags like P B I BR, lists, CODE – but no
<SCRIPT>or similar. It is also better not to use explicit „headings” (especially H1/H2): When displaying the description on web pages, this could „break“ the structure there (just looks sh… oddy).
For the other files („icing on the cake“), please see the Fastlane Cheat Sheet.
- a template for newly added apps with the desired fields (without values) can be stored as
template.ymldirectly in the main directory of the repo (in our example:
fdroid update -cis called, it will be copied to
metadata/(using the appropriate name) when new apps are found, so you only need to modify it.
- if you want to extend your repo with malware check etc., you can find the libraries etc. used by IzzyOnDroid in the associated gitLab repo. However, the configuration requires a little technical background and a good bit of time.
- for a simpler variant for the preliminary check for libraries contained in an app, there is an article at IzzyOnDroid for my „APK Library Scanner“, which is also in use at F-Droid: Identifying modules in apps. In the meantime, the output also includes the license under which the respective library stands. A statistic about the used library definitions can be found here.
Make your repo known
Now, of course, it’s great to have the repo flying successfully and „nicely“ – only without users it’s a bit sad. So how do you make sure that the news gets around – especially if you only have a small „reach“ yourself? You make sure that it appears in as many repo lists as possible. For example, there is one in the F-Droid forum. Another one I maintain here. Also Mondstern maintains a list – both of us can be reached via Mastodon, for example, and are happy to receive hints.