Publishing Applications through F-Droid

In 2016 I started working on a set of Python modules for reading and writing bytecode for the Dalvik virtual machine so that I could experiment with creating applications on Android without having to write them in Java. In the time since then, on and off, I have written a few small applications to learn about Android and explore the capabilities of the devices I own. Some of these were examples, demos and tests for the compiler framework, but others were intended to be useful to me. I could have just downloaded applications to perform the tasks I wanted to do, but I wanted minimal applications that I could understand and trust, so I wrote my own simple applications and was happy to install them locally on my phone.

In September I had the need to back up some data from a phone I no longer use, so I wrote a few small applications to dump data to the phone's storage area, allowing me to retrieve it using the adb tool on my desktop computer. I wondered if other people might find applications like these useful and asked on the FSFE's Android mailing list. In the discussion that followed it was suggested that I try to publish my applications via F-Droid.

Preparations

The starting point for someone who wants to publish applications via F-Droid is F-Droid's Contribute page. The documentation contains a set of links to relevant guides for various kinds of developers, including those making applications and those deploying the F-Droid server software on their own servers.

I found the Contributing to F-Droid document to be a useful shortcut for finding out the fundamental steps needed to submit an application for publication. This document is part of the F-Droid Data repository which holds information about all the applications provided in the catalogue. However, I was a bit uncertain about how to write the metadata for my applications. The problem being that the F-Droid infrastructure builds all the applications from source code and most of these are built using the standard Android SDK, but my applications are not.

Getting Help

I joined the F-Droid forum to ask for assistance with this problem under the topic of Non-standard development tools and was quickly offered help in getting my toolchain integrated into the F-Droid build process. I had expected it was going to take a lot of effort on my part but F-Droid contributor Pierre Rudloff came up with a sample build recipe for my application, showing how simple it could be. To include my application in the F-Droid catalogue, I just needed to know how to describe it properly.

The way to describe an application, its build process and available versions is contained in the Build Metadata Reference document. It can be a bit intimidating to read, which is why it was so useful to be given an example to start with. Having an example meant that I didn't really have to look too hard at this document, but I would be returning to it before too long.

To get the metadata into the build process for the applications hosted by F-Droid, you need to add it to the F-Droid Data repository. This is done using the familiar cycle of cloning, committing, testing, pushing, and making merge requests that many of us are familiar with. The Data repository provides a useful Quickstart guide that tells you how to set up a local repository for testing. One thing I did before cloning any repositories was to fork the Data repository so that I could add my metadata to that. So, what I did was this:

I added a file in the metadata directory of the repository called uk.org.boddie.android.weatherforecast.txt containing a description of my application and information about its version, dependencies, build process, and so on. Then I ran some checks using the fdroid tool from the Server repository, checking that my metadata was valid and in a suitable format for the Data repository, before verifying that a package could be built:

The third of these commands requires the ANDROID_HOME environment variable to be set. I have a very old Android SDK installation that I had to refer to in order for this to work, even though my application doesn't use it. For reference, the ANDROID_HOME variable refers to the directory in the SDK or equivalent that contains the build-tools directory.

Build, Test, Repeat

At this point it was time to commit my new file to my fork of the Data repository and push it back up to GitLab. While logged into the site, verifying that my commit was there, I was offered the option to create a merge request for the official F-Droid Data repository, and this led to my first merge request for F-Droid. Things were moving forward.

Unfortunately, I had not managed to specify all the dependencies I needed to build my application using my own tools. In particular, I rely on PyCrypto to create digests of files, and this was not available by default in the build environment. This led to another change to the metadata and another merge request. Still, it was not plain sailing at this point because, despite producing an application package, the launcher icon was generated incorrectly. This required a change to the application itself to ensure that the SVG used for the icon was in a form that could be converted to PNG files by the tools available in the build environment. Yet another merge request updated the current version number so that the fixed application could be build and distributed. My application was finally available in the form I originally intended!

Still, not everything was perfect. A couple of users quickly came forward with suggestions for improvements and a bug report concerning the way I handled place names – or rather failed to handle them. The application was fixed and yet another merge request was created and handled smoothly by the F-Droid maintainers.

Finishing Touches

There are a few things I've not done when developing and releasing this application; there's at least one fundamental thing and at least one cosmetic enhancement that could be done to improve the experience around the installation process.

The basic thing is to write a proper changelog. Since it was really just going to be the proof of concept that showed applications written with DUCK could be published via F-Droid, the application evolved from its original form very informally. I should go back and at least document the bug fixes I made after its release.

The cosmetic improvement would be to improve its F-Droid catalogue entry to include a screenshot or two, then at least prospective users could see what they were getting.

Another meta-feature that would be useful for me to use is F-Droid's auto-update facility. I'm sure I'll need to update the application again in the future so, while this document will remind me how to do that, it would be easier for everyone if F-Droid could just pick up new versions as they appear. There seem to be quite a few ways to do that, so I think that I'll have something to work with.

In summary, it was easier than I had imagined to publish an application in the F-Droid catalogue. The process was smooth and people were friendly and happy to help. If you write your own Free Software applications for Android, I encourage you to publish them via F-Droid and to submit your own metadata for them to make publication as quick and easy as possible.

This document is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International license.

Publishing Applications via F-Droid

Preparations

Getting Help

Build, Test, Repeat

Finishing Touches