IzzyOnDroid

• Intro
• App-Lists
• Articles
• Books
• Downloads
• App-Repo
• Imprint

F-Droid for advanced users and developers

The previous article introduced F-Droid as a privacy-friendly app store providing privacy friendly apps. This article now addresses advanced users who want to get the most out of F-Droid – as well as developers who wish to provide their apps via F-Droid.

In this series:

• Part 1: The privacy-friendly alternative to Google Play Store
• Part 2: for advanced users and developers
• Part 3: Your own F-Droid Repository with Repomaker
• external, by Nico Alt: Trust is good, control is better: Reproducible builds at F-Droid
• Part 4: Join the F-Droid Team: Tasks of a Reviewer

more F-Droid articles at IzzyOnDroid:

• IzzyOnDroid’s F-Droid Repo with additional functionality (1/2018)
• Unofficial (and incomplete) list of F-Droid repositories (regularly updated)

For advanced users: The F-Droid PrivilegedExtension

The previous article showed that the F-Droid app, if it didnt come pre-installed, cannot install updates by itself: for security reasons, only system apps can do so. That’s also why, if the user manually triggers an install, Android’s own Package Manager intervenes and asks the user for confirmation – which does not happen if you use the Google Play Store app, as that’s a system app.

If you want to grant F-Droid that very same privilege, you can do so using the F-Droid PrivilegedExtension. On devices which shipped with F-Droid pre-installed, it of course is already integrated – and custom ROMs shipping with F-Droid integrated, like LineageOS for microG, also come with it. To manually install it where it’s missing, your device needs to meet some requirements:

• the bootloader needs to be unlocked
• a custom Recovery (like TWRP) either needs to be installed on the device, or at least temporarily loaded via fastboot boot

That given, an installation is not especially hard:

• download the ZIP of the F-Droid PrivilegedOTA installer,
• copy it to the device
• and flash it via the custom Recovery (menu „install from zip“)

The installation completed, you restart the device („reboot system“) – and immediately profit from the advantages a completely system-integrated F-Droid app offers:

• installation of new apps happens immediately (without the Package Manager asking for another confirmation)
• automated updates are now possible: if you set the related options accordingly, new versions of apps you’ve installed from F-Droid are installed automatically as soon as they are available – without your needing to press another key.

For advanced users, developers, companies, organisations and others: 3rd party repositories

The previous article already addressed them when talking about options: repositories (package sources). By default, only the official main repo of F-Droid is enabled – and three more repositories are pre-configured:

• F-Droid Archive: older app versions
• Guardian: Repo of the Guardian Project
• Guardian Archive: older app versions of the Guardian Project

All pre-configured sources solely provide apps conforming to the strong criteria of the F-Droid project (see below). Nevertheless this menu lets you include other repositories. Those are e.g. provided by developers for their testers. Or by other F-Droid users to provide apps not acceptable to the official repo as they do not comply to all the required criteria (like the IzzyOnDroid Repo does, which you can see in the screenshot).

Those sources have been deliberately excluded. If you want to use such a third-party repository, you must be aware of the risks involved: criteria an app must meet to be included are usually much less strict. That doesn’t necessarily mean all apps in those repos are risky – but that theoretically they could be. Lists of available third-party repositories can e.g. be found

• in the F-Droid Forum – with comments and discussion. This article can be edited by any member of the forum.
• in the F-Droid Wiki – this is a list curated by the F-Droid Team.
• at IzzyOnDroid – a list curated by the author of this article.

None of these lists claims completeness. After all, everybody and his little sister can run their own F-Droid repository without the need to „register“ it somewhere – but this fact will be discussed in a later article.

For developers: the process of integrating an app with F-Droid

So you’ve created an app and now want it listed at F-Droid? Great! If your app meets the Inclusion Criteria (also see below), there should be nothing standing in its way.

The first step is creating a requests for packaging – after having checked that hasn‘t already be done by someone else or the app even is already listed. In this process you need to fill a form with details needed to get your app listed. By no means should you simply remove the template and fill in „something informal“, as that would make it impossible to process. Next to filling as much fields as possible you should care to provide a meaningful Description – one enabling users to understand what the app is doing and why it should be this app (s)he must install. Description and screenshots can also be maintained in your app’s repository; more on that below. Additionally, any donation links (Liberapay, Bitcoin etc.) must be verifiable – e.g. by also being mentioned in the app’s repository or on its website. This is to protect against abuse, as otherwise anybody could add his/her own Bitcoin address here.

The request saved, within a few ours the „F-Droid Bot“ will show up and check the provided source repo. Results of its check it then posts as another comment on the request – which ideally will be an „all green“ (ie. no issues found). But often it finds some small things that flew below radar level: some pieces not meeting the inclusion criteria (such as a binary library), or some security issue with the setup (like „insecure gradlews“ using http URLs instead of https). For you that means to make some adjustments fixing the indicated issues. If something’s unclear to you and/or you need help, just call out in another comment on the same request. The F-Droid team will be there to help you.

This step successfully taken, an F-Droid team member will create a „Metadata File“ out of the specifications you made and try to build the app. If this succeeds, the metadata file will be committed to the fdroiddata repository, and the app finally build. Before it becomes visible to other F-Droid users, it will need to be signed. For security reasons, that’s another manual step performed „offline“ – to avoid the risk of the signing keys to „escape to the wild“. Which, as every developer will agree, would be quite fatal.

The developer also can make use of reproducible builds. This requires some additional efforts – but comes with the advantage of making „cross updates“ possible: if successfully „reproduced“, F-Droid won‘t sign the APK itself but use the one signed by the developer. Which means there won‘t be any „signature mismatch“ when the app was originally installed via Google Play Store and then updated from F-Droid (or vice versa).

How long it will take from opening the RFP until the app will finally be available in F-Droid is hard to say. If everything goes right and straight, it might be just a few days – but it could as well be several months if problems arise. Plus, the F-Droid team is permanently understaffed; so it might even take a little until someone can pick it up.

In his blog David Boddy describes this process goes easier than it sounds. That he performed several steps himself usually done by F-Droid team members might have contributed to that – so you are welcome to use that as example

Core F-Droid GitLab Repositories and what they are used for:

Repo	Verwendung
rfp	Request for Packaging: Ask to integrate a new app with the F-Droid catalog
fdroiddata	Maintain Metadata of all apps
fdroidclient	Development and Troubleshooting of the F-Droid Android client
privileged-extension	Development and Troubleshooting of the PrivilegedExtension
fdroidserver	Development and Troubleshooting of the F-Droid Server Applikation
repomaker	Development and Troubleshooting of the RepoMaker Application
fdroid-website	things affecting the F-Droid website

 

For developers: acceptance criteria for apps

For an app to be accepted into the official F-Droid catalogue, it needs to meet certain criteria. It is not sufficient to simply provide the APK file (as you can do with Google Play Store or Aptoide): F-Droid only accepts Open Source apps – i.e. all parts of the app must be available as source code, in a public repository for everyone to investigate. This especially means:

• proprietary components such as Crashlytics, Firebase etc. are absolute show-stoppers. They either must be removed entirely – or you need to provide a separate „build flavor“ excluding those.
• „Blobs“ (standing for „Binary Large OBjects“, though it has little to do with the size)¹ as e.g. JARs are not accepted. If they are open source, you can e.g. include their sources with your app’s repo as Git Submodules, so F-Droid can compile them from their sources while building your app.
• „Maven Repositories“: Only a selection of „trustable repositories“ is supported by F-Droid.
• non-free build tools (toolchains, SDKs) must not be needed to compile the app.
• the app must use a unique Android package ID. Thats also valid if it’s a fork: the ID must differ from the „original“.
• Brands must not be violated, and all related laws is to adhere to. This is also true for the use of media (pictures, icons, fonts, sounds) in the app’s source tree.
• F-Droid doesn’t subscribe for API keys (or other services) – which means that such must not be required to crreate the app. If it’s required at a later point so the app can be used, this will might lead to an AntiFeature.

For developers: descriptions and screenshots in your own hand

„All About Descriptions, Graphics and Screenshots“ is the title of a document provided by F-Droid in its fundus of documentation. It describes different approaches for the integration of these „Metadata“:

• by default, the description is part of the app’s Metadata file, and there are no screenshots or other pictures of the app. Pro: easy to set up. Con: each change to the description requires an issue/merge-request in fdroiddata; without screenshots a potential user only gets a limited idea of the app.
• Description (in multiple languages) and screenshots as well as a FeatureGraphic can be maintained in fdroiddata. Pro: Screenshots help the user to better understand the app description. Con: each change to text or images again requires opening an issue/merge-request against fdroiddata (see previous bullet-point).
• The developer can maintain those data in the source repository of the app itself. If the app is made available in Google Play Store already, the devloper most likely knows the corresponding tools: Fastlane and Triple-T. Details can be found in the linked document. Pro: as with the previous bullet-point; additionally, the developer easily can perform any changes him/herself – which will then be automatically reflected when the next version is published. Con: a one-time additional step is needed to establish the necessary structures in the app’s source repository.

It is definitely a good idea (and highly recommended) to provide screenshots – be it in the app’s repo or in fdroiddata. The corresponding structures allow for different screenshot sizes corresponding to display sizes (phone, tablet). And for descriptions in different languages.

How to make life easier for the F-Droid team – and possibly speed up publication of a new app?

• „Tag“ your app’s releases (e.g. via git tag). That makes it easier to pick the commit that marks the version – and also makes it possible to detect new versions, so updates are published faster as well.
• Use Gradle. This is the standard working best for F-Droid.
• Take care from the very beginning that your app meets the „Inclusion Criteria“ – and has a meaningful description. This reduces „Ping-Pong“ when processing the „RFP“.
• Additional details, tutorials, an FAQ: Descriptions add value to your app. That doesn’t necessarily need a specific website or domain; Github, GitLab, NotABug etc. provide Wiki funktionality for this which you should feel encouraged to use.
• Maintain screenshots and translations per Fastlane/Triple-T in your app’s repo. An appealing presentation in his/her own language is better attracting new users.