Submitting to F-Droid Quick Start Guide Doing this is apparently the best way to get your own package into the repository, since you can provide a direct merge request for the metadata about your package, making it easy for the maintainers. To understand the overview of the process, read the Proposal by Metadata Merge Request section of the Inclusion How-To. First steps In the source of the application you want to include, find all the AndroidManifest.xml and build.gradle files, and write down in which subdir the most detailed of them happen to be. Register on GitLab and fork the fdroiddata repository. Upstream metadata Each official release commit in the application’s upstream Git repository should have a tag. For example, if its AndroidManifest contains versionName: '1.0', the commit needs a v1.0 tag. It is strongly encouraged to add metadata in the application’s source repo, too: metadata/en-US/short_description.txt (30-50 chars, no trailing dot) metadata/en-US/full_description.txt metadata/en-US/images/icon.png metadata/en-US/images/phoneScreenshots/screenshot.png If the AndroidManifest contains versionCode: 123, there should be a corresponding explanation of what’s new in this version: metadata/en-US/changelogs/123.txt (max 500 characters) Browse the F-Droid client metadata directory to see a real-world example. Other formats and locations of the description, graphics, and screenshots are supported, too. For example, the metadata/en-US directory can instead be fastlane/metadata/android/en-US. Send the application’s development team a merge request if the repository doesn’t have those files, and open an issue if it has no version tags. Having this metadata in place lets it be under direct control of the developer, and their updates and future translations will be pulled automatically. Build environment On a laptop with Ubuntu 21.10 in February 2022, it took 2 GB of traffic and 5 GB of disk space to set up an F-Droid build environment. Network requirements: 60 MB: shallow-clone fdroiddata and fdroidserver 75 MB: install docker.io 1000 MB: load the container 800 MB: build Storage requirements: 1000 MB: clone the repos and install docker.io 4000 MB: load the container and build Download your fork, then create a new branch and a metadata file. For example, if the application’s build.gradle says applicationId "com.example": git clone --depth=1 https://gitlab.com/YOUR_ACCOUNT/fdroiddata ~/fdroiddata cd ~/fdroiddata git checkout -b com.example cp templates/build-gradle.yml metadata/com.example.yml Fill ~/fdroiddata/metadata/com.example.yml according to the build metadata reference. If you have convinced the application’s development team to include the descriptions and use version tags in their repository as explained above, the file will be very concise: Categories: - Internet - Navigation License: GPL-3.0-or-later SourceCode: https://gitlab.com/APPLICATION_UPSTREAM/ExampleCom RepoType: git Repo: https://gitlab.com/APPLICATION_UPSTREAM/ExampleCom Builds: - versionName: '1.0' versionCode: 123 commit: v1.0 # Where build.gradle is: subdir: app sudo: - apt-get update # see text below - apt-get install -y librsvg2-bin - update-alternatives --auto java gradle: - yes AutoUpdateMode: Version UpdateCheckMode: Tags CurrentVersion: '1.0' CurrentVersionCode: 123 Adjust or remove the relevant sudo lines if needed, eg: The example application’s build.gradle executes rsvg-convert to rasterize its vector icons, so we install librsvg2-bin from the official Debian repositories. All such dependencies should be specified in the app’s README. Download and launch the latest version of the server tools container: git clone --depth=1 https://gitlab.com/fdroid/fdroidserver ~/fdroidserver sudo sh -c 'apt-get update &&apt-get install -y docker.io' sudo docker run --rm -itu vagrant --entrypoint /bin/bash \ -v ~/fdroiddata:/build:z \ -v ~/fdroidserver:/home/vagrant/fdroidserver:Z \ registry.gitlab.com/fdroid/fdroidserver:buildserver In the container: . /etc/profile export PATH="$fdroidserver:$PATH" PYTHONPATH="$fdroidserver" export JAVA_HOME=$(java -XshowSettings:properties -version 2>&1 > /dev/null | grep 'java.home' | awk -F'=' '{print $2}' | tr -d ' ') cd /build fdroid readmeta fdroid rewritemeta com.example fdroid checkupdates --allow-dirty com.example fdroid lint com.example fdroid build com.example If any command, such as fdroid readmeta, returns an error, edit ~/fdroiddata/metadata/com.example.yml accordingly and try running the command again. After a successful build, exit the container, commit your metadata file with a New App label, and push it to your fork: exit cd ~/fdroiddata git add metadata/com.example.yml git commit -m "New App: com.example" git push origin com.example Create a merge request at the fdroiddata repository, selecting your com.example source branch. Wait for the packagers to pick up your merge request. Please keep track if they asked any questions and reply to them as soon as possible.

https://f-droid.org/docs/Submitting_to_F-Droid_Quick_Start_Guide/

Contributing to F-Droid Data For information about all aspects of F-Droid, check out the documentation. Issue Tracker Inclusion of new apps If you are a "first time" contributor, consider opening an issue at RFP (Request for Packaging). Don't forget to fill in the issue template. Updating apps already in F-Droid You may use the issue tracker to report issues on app metadata or issues with the packages distributed through our repository. For instance: an app is outdated an app has Antifeatures, but they are not listed in the app or on the website. Before opening an issue about an outdated app, have a look at its metadata file and make sure that updating the app is actually possible. For example, MaintainerNotes might contain a hint on why it's impossible to further update an app (e.g. proprietary dependencies were added, essential parts of the code are no longer available). Also make sure having checked with already existing issues (including closed ones) which might give similar explanations. Merge Requests Setting up fdroiddata for merge requests Register on GitLab. Visit and fork the fdroiddata repository. App metadata for a merge request can be created without or with the use of fdroidserver. The latter is only recommended for really advanced users. Metadata preparation without fdroidserver You can either write the metadata file locally, on your machine, or directly on the GitLab website. Please read the General Recommendations before you start. On the GitLab website Visit your fork. Create a new branch. Naming it like the app name or, much better, the app id makes it easier to keep track of your contributions. Visit the metadata directory of your fork. Add a new file by clicking on the plus sign and choosing "New file". Set the file name in the following schema: <application_id>.yml. So an example would be "com.app.example.yml". Write down the metadata. The Build Metadata Reference as well as the templates will help you. Choose a smart commit message and commit your changes. Continue with the Common steps for both methods On your local machine Clone your fork. Create and checkout a new branch. Naming it like the app name or, much better, the app id makes it easier to keep track of your contributions. Create a new file in the the metadata directory named after the following schema: <application_id>.yml. So an example would be "com.app.example.yml". Write down the metadata in that file. The Build Metadata Reference as well as the templates will help you. Commit and push to your upstream fork. Continue with the Common steps for both methods Common steps for both methods Go to the CI/CD menu in the GitLab project of your fork. Check if the pipeline for your commit(s) succeed. If not, take a look into the logs and try to fix the error by editing the metadata file again. If everything went fine, you can create a new merge request at the fdroiddata repository. Now wait for the packagers to pick up your Merge Request. Please keep track if they asked any questions and reply to them as soon as possible. Metadata preparation with fdroidserver Please read the General Recommendations before you start. Setting up fdroidserver Install F-Droid Server: pip install git+https://gitlab.com/fdroid/fdroidserver.git Clone your fork of F-Droid Data and enter it: git clone https://gitlab.com/YOUR_USERNAME/fdroiddata.git cd fdroiddata Make sure fdroid works and reads the metadata files properly: fdroid readmeta Adding a new app If you want to add a new app you will have to add a new metadata file to the repository, like metadata/app.id.yml. Here is how to write that file. If the app is on GitHub or any GitLab or Gitea/Gogs instance, you can use fdroid import. However, the metadata fields IssueTracker and SourceCode will only be generated, if the source code is hosted on one of the following platforms: GitHub GitLab FramaGit NotABug Bitbucket Codeberg If the source code is not on one of those you must add .git to the end of the URL. fdroid import --url https://github.com/foo/bar --subdir app Alternatively, start the metadata file from scratch, see the templates: cp templates/general.yml metadata/app.id.yml Or by download: wget -O metadata/app.id.yml https://gitlab.com/fdroid/fdroiddata/raw/master/templates/general.yml Now that the file is created, you need to fill up all the app information and add a working build recipe. You can use the metadata section in the documentation for reference, or the full template at templates/general.yml for some suggestions. Once you're done, see if fdroid readmeta runs without any errors. If it doesn't, there are syntax errors in your metadata file. Building it We build apps from source, so a new app must have at least one working build. You can have a look at the build templates at templates/build-* for some quick suggestions. You may also follow the documentation or look at how other apps are built for working examples. Run fdroid readmeta again to make sure there still aren't any syntax errors Run fdroid rewritemeta app.id to clean up your file Run fdroid checkupdates app.id to fill automated fields like Auto Name and Current Version Make sure that fdroid lint app.id doesn't report any warnings. If it does, fix them. Test your build recipe with fdroid build -v -l app.id Congratulations! You can now open a merge request to add your app. General recommendations Keep a separate branch for every app you want to submit. Keep your forks master branch up-to-date. For more information see here: https://about.gitlab.com/blog/2016/12/01/how-to-keep-your-fork-up-to-date-with-its-origin As a result of the two tips above, you should not commit to your master branch. This will also trigger new pipelines at the right time. Do not open a Merge Request from a protected branch. The master branch is protected by default, but other branches can also be protected. Fill the template when opening a new Merge Request. Squash your commits. (enabled by default) After You Added Your App "How long does it take for my app to show up in the F-Droid repository?" is a very frequently asked question. Please take a look at the wiki for the answer. If you have enabled auto-updates, F-Droid will build new versions from tags automatically. AutoUpdateMode: Version UpdateCheckMode: Tags You may like to add localization and screenshots, so users can have a glance at the app in pictures and in their preferred language. You can advertise the download of your app in this app store using the official badge. See the instructions at https://f-droid.org/docs/Badges/. You can add a badge of your apps F-Droid version from shields.io. https://img.shields.io/f-droid/v/APP.ID.svg?logo=F-Droid You can also include a GitHub release badge to know if your version is up to date. https://img.shields.io/github/release/USER/REPO.svg?logo=github 03.07.25

https://gitlab.com/fdroid/fdroiddata/blob/master/CONTRIBUTING.md#merge-requests

• Home
• Notebook
• Contact us

• Privacy Statement
• 

Copyleft ☠ 2025