Instead of (or as well as) including binary APKs from external sources in a repository, you can build them directly from the source code.
Using this method, it is is possible to verify that the application builds correctly, corresponds to the source code, and contains only free software. Unforunately, in the Android world, it seems to be very common for an application supplied as a binary APK to present itself as Free Software when in fact some or all of the following are true:
For this reason, source-built applications are the preferred method for the main F-Droid repository, although occasionally for technical or historical reasons, exceptions are made to this policy.
When building applications from source, it should be noted that you will be signing them (all APK files must be signed to be installable on Android) with your own key. When an application is already installed on a device, it is not possible to upgrade it in place to a new version signed with a different key without first uninstalling the original. This may present an inconvenience to users, as the process of uninstalling loses any data associated with the previous installation.
The process for managing a repository for built-from-source applications is very similar to that described in the Simple Binary Repository chapter, except now you need to:
fdroid buildto build any applications that are not already built.
fdroid publishto finalise packaging and sign any APKs that have been built.
When run without any parameters,
fdroid build will build any and all
versions of applications that you don't already have in the
directory (or more accurately, the
unsigned directory). There are various
other things you can do. As with all the tools, the
--help option is
your friend, but a few annotated examples and discussion of the more common
usage modes follows:
To build a single version of a single application, you could run the following:
./fdroid build --package=org.fdroid.fdroid --vercode 16
This attempts to build version code 16 (which is version 0.25) of the F-Droid
client. Many of the tools recognise this
--package parameter, allowing
their activity to be limited to just a single package.
If the build above was succesful, two files will have been placed in the
The first is the (unsigned) APK. You could sign this with a debug key and push it direct to your device or an emulator for testing. The second is a source tarball containing exactly the source that was used to generate the binary.
If you were intending to publish these files, you could then run:
The source tarball would move to the
repo directory (which is the
directory you would push to your web server). A signed and zip-aligned version
of the APK would also appear there, and both files would be removed from the
If you're building purely for the purposes of testing, and not intending to
push the results to a repository, at least yet, the
--test option can be
used to direct output to the
tmp directory instead of
A similar effect could by achieved by simply deleting the output files from
unsigned after the build, but with the risk of forgetting to do so!
Along similar lines (and only in conjunction with
--test, you can use
--force to force a build of a Disabled application for test purposes,
where normally it would be completely ignored.
You can also build and install directly to a connected device or emulator using
--install switch. If you do this without using
--vercode then all versions of all packages will be installed (with each
individual version overwriting the previous!). In most cases, this will not be
what you want to do, so execution will stop straight away. However, you can
override this if you're sure that's what you want, by using