@copying
This manual is for the F-Droid repository server tools.
-Copyright @copyright{} 2010, 2011, 2012, 2013 Ciaran Gultnieks
+Copyright @copyright{} 2010, 2011, 2012, 2013, 2014, 2015 Ciaran Gultnieks
Copyright @copyright{} 2011 Henrik Tunedal, Michael Haas, John Sullivan
Copyright @copyright{} 2013 David Black
-Copyright @copyright{} 2013, 2014 Daniel MartÃ
+Copyright @copyright{} 2013, 2014, 2015 Daniel MartÃ
+
+Copyright @copyright{} 2015 Boris Kraut
@quotation
Permission is granted to copy, distribute and/or modify this document
GNU/Linux
@item
Python 2.x
+To be sure of being able to process all apk files without error, you need
+2.7.7 or later. See @code{http://bugs.python.org/issue14315}.
@item
The Android SDK Tools and Build-tools.
Note that F-Droid does not assume that you have the Android SDK in your
@item
Vagrant (unpackaged, tested on v1.4.3)
@item
+vagrant-cachier plugin (unpackaged): `vagrant plugin install vagrant-cachier`
+@item
Paramiko (debian package python-paramiko)
@item
Imaging (debian package python-imaging)
-@item
-Magic (debian package python-magic)
@end itemize
On the other hand, if you want to build the apps directly on your system
the metadata files in the metadata directory.
@end enumerate
-The metadata files are simple, easy to edit text files, always named as the
-application's package ID with '.txt' appended.
+The original metadata files are simple, easy to edit text files,
+always named as the application's package ID with '.txt' appended.
+Additionally, you can use JSON, XML, or YAML for app metadata, using
+the same fields as the original '.txt' format.
+
+Note that although the metadata files are designed to be easily read
+and writable by humans, they are also processed and written by various
+scripts. The original '.txt' format can be automatically cleaned up
+when necessary. The structure and comments will be preserved
+correctly, although the order of fields will be standardised. (In the
+event that the original file was in a different order, comments are
+considered as being attached to the field following them). In fact,
+you can standardise all the '.txt' metadata in a single command,
+without changing the functional content, by running:
+
+@example
+fdroid rewritemeta
+@end example
-Note that although the metadata files are designed to be easily read and
-writable by humans, they are also processed and written by various scripts.
-They are capable of rewriting the entire file when necessary. Even so,
-the structure and comments will be preserved correctly, although the order
-of fields will be standardised. (In the event that the original file was
-in a different order, comments are considered as being attached to the field
-following them). In fact, you can standardise all the metadata in a single
-command, without changing the functional content, by running:
+Or just run it on a specific app:
@example
-fdroid rewritemetadata
+fdroid rewritemeta org.adaway
@end example
The following sections describe the fields recognised within the file.
* Web Site::
* Source Code::
* Issue Tracker::
+* Changelog::
* Donate::
* FlattrID::
* Bitcoin::
* Maintainer Notes::
* Repo Type::
* Repo::
+* Binaries::
* Build::
* AntiFeatures::
* Disabled::
This is converted to (@code{<tracker>}) in the public index file.
+@node Changelog
+@section Changelog
+
+@cindex Changelog
+
+The URL for the application's changelog. Optional, since not all
+applications have one.
+
+This is converted to (@code{<changelog>}) in the public index file.
+
@node Donate
@section Donate
@cindex Summary
A brief summary of what the application is. Since the summary is only allowed
-one line on the list of the F-Droid client, keeping it to within 50 characters
+one line on the list of the F-Droid client, keeping it to within 80 characters
will ensure it fits most screens.
@node Description
@item
@samp{srclib}
@end itemize
+
@node Repo
@section Repo
and you want to use this srclib, then you have to set Repo to
@code{FooBar}.
+@node Binaries
+@section Binaries
+
+@cindex Binaries
+
+The location of binaries used in verification process.
+
+If specified, F-Droid will verify the output apk file of a build against the
+one specified. You can use %v and %c to point to the version name and version
+code of the current build. To verify the F-Droid client itself you could use:
+@code{Binaries:https://f-droid.org/repo/org.fdroid.fdroid_%c.apk}
+
+F-Droid will use upstream binaries if the verification succeeded.
+
@node Build
@section Build
takes place.
You can use $$SDK$$, $$NDK$$ and $$MVN3$$ to substitute the paths to the
-android SDK and NDK directories, and maven 3 executable respectively.
+android SDK and NDK directories, and maven 3 executable respectively. The
+following per-build variables are available likewise: $$VERSION$$,
+$$VERCODE$$ and $$COMMIT$$.
@item oldsdkloc=yes
The sdk location in the repo is in an old format, or the build.xml is
For Ant projects, you can optionally append a number with a colon at the
beginning of a srclib item to automatically place it in project.properties as
a library under the specified number. For example, if you specify
-@code{1:somelib@@1.0}, f-droid will automatically do the equivalent of the
+@code{1:somelib@@1.0}, F-Droid will automatically do the equivalent of the
legacy practice @code{prebuild=echo "android.library.reference.1=$$somelib$$"
>> project.properties}.
the init/prebuild/build command to substitute the relative path to the library
directory, but it could need tweaking if you've changed into another directory.
+Currently srclibs are necessary when upstream uses jar files or pulls
+dependencies from non-trusted repositories. While there is no guarantee that
+those binaries are free and correspondent to the source code, F-Droid allows
+the following known repositories until a source-built alternative is available:
+
+@itemize @bullet
+
+@item
+@samp{mavenCentral} - the original repo, hardcoded in Maven and Gradle.
+
+@item
+@samp{jCenter} - hardcoded in Gradle, this repo by Bintray tries to provide
+easier handling. It should sync with mavenCentral from time to time.
+
+@item
+@samp{OSS Sonatype} - maintained by the people behind mavenCentral, this
+repository focuses on hosting services for open source project binaries.
+
+@item
+@samp{JitPack.io} - builds directly from Github repositories. However,
+they do not provide any option to reproduce or verify the resulting
+binaries. Builds pre-release versions in some cases.
+
+@end itemize
+
@item patch=x
Apply patch(es). 'x' names one (or more - comma-seperated) files within a
directory below the metadata, with the same name as the metadata file but
You can use $$SDK$$, $$NDK$$ and $$MVN3$$ to substitute the paths to the
android SDK and NDK directories, and Maven 3 executable respectively e.g.
-for when you need to run @code{android update project} explicitly.
+for when you need to run @code{android update project} explicitly. The
+following per-build variables are available likewise: $$VERSION$$, $$VERCODE$$
+and $$COMMIT$$.
@item scanignore=<path1>[,<path2>,...]
Enables one or more files/paths to be excluded from the scan process.
paths start with any of the paths given here are ignored.
@item scandelete=<path1>[,<path2>,...]
-Similar to scanignore=, but instead of ignoring files under the given paths,
-it tells f-droid to delete the matching files directly.
+When running the scan process, any files that trigger errors - like binaries -
+will be removed. It acts just like scanignore=, but instead of ignoring the
+files, it removes them.
+
+Useful when a source code repository includes binaries or other unwanted files
+which are not needed for the build. Instead of removing them manually via rm=,
+using scandelete= is easier.
@item build=xxxx
As for 'prebuild', but runs during the actual build phase (but before the
build= (or the final build) is run.
You can use $$SDK$$, $$NDK$$ and $$MVN3$$ to substitute the paths to the
-android SDK and NDK directories, and Maven 3 executable respectively.
+android SDK and NDK directories, and maven 3 executable respectively. The
+following per-build variables are available likewise: $$VERSION$$,
+$$VERCODE$$ and $$COMMIT$$.
@item buildjni=[yes|no|<dir list>]
Enables building of native code via the ndk-build script before doing
toolchains no longer included in current versions of the NDK.
The buildserver supports r9b with its legacy toolchains and the latest release
-as of writing this document, r10d. You may add support for more versions by
+as of writing this document, r10e. You may add support for more versions by
adding them to 'ndk_paths' in your config file.
@item gradle=<flavour1>[,<flavour2>,...]
Build with Gradle instead of Ant, specifying what flavours to use. Flavours
are case sensitive since the path to the output apk is as well.
-If only one flavour is given and it is 'yes' or 'main', no flavour will be
-used. Note that for projects with flavours, you must specify at least one
-valid flavour since 'yes' or 'main' will build all of them separately.
+If only one flavour is given and it is 'yes', no flavour will be used.
+Note that for projects with flavours, you must specify at least one
+valid flavour since 'yes' will build all of them separately.
@item maven=yes[@@<dir>]
-Build with Maven instead of Ant. An extra @@<dir> tells f-droid to run Maven
+Build with Maven instead of Ant. An extra @@<dir> tells F-Droid to run Maven
inside that relative subdirectory. Sometimes it is needed to use @@.. so that
builds happen correctly.
List of Gradle tasks to be run before the assemble task in a Gradle project
build.
+@item gradleprops=<prop1>[,<prop2>,...]
+List of Gradle properties to pass via the command line to Gradle. A property
+can be of the form @code{foo} or of the form @code{key=value}.
+
+For example: @code{gradleprops=enableFoo,someSetting=bar} will result in
+@code{gradle -PenableFoo -PsomeSetting=bar}.
+
@item antcommands=<target1>[,<target2>,...]
Specify an alternate set of Ant commands (target) instead of the default
'release'. It can't be given any flags, such as the path to a build.xml.
This is optional - if present, it contains a comma-separated list of any of
the following values, describing an anti-feature the application has.
-Even though such apps won't be displayed unless a settings box is ticked,
-it is a good idea to mention the reasons for the anti-feature(s) in the
+It is a good idea to mention the reasons for the anti-feature(s) in the
description:
@itemize @bullet
without major changes to the app.
@item
-@samp{NonFreeAdd} - the application promotes non-Free add-ons, such that the
+@samp{NonFreeAdd} - the application promotes non-free add-ons, such that the
app is effectively an advert for other non-free software and such software is
not clearly labelled as such.
@item
-@samp{NonFreeDep} - the application depends on a non-Free application (e.g.
+@samp{NonFreeDep} - the application depends on a non-free application (e.g.
Google Maps) - i.e. it requires it to be installed on the device, but does not
include it.
+@item
+@samp{UpstreamNonFree} - the application is or depends on non-free software.
+This does not mean that non-free software is included with the app: Most
+likely, it has been patched in some way to remove the non-free code. However,
+functionality may be missing.
+
@end itemize
@node Disabled
name but change it programmatically in some app flavors, by e.g. appending
".open" or ".free" at the end of the package name.
+You can also use @code{Ignore} to ignore package name searching. This should
+only be used in some specific cases, for example if the app's build.gradle
+file does not contain the package name.
+
@node Update Check Data
@section Update Check Data
This field is normally automatically updated - see Update Check Mode.
+If not set or set to @code{0}, clients will recommend the highest version they
+can, as if the @code{Current Version Code} was infinite.
+
This is converted to (@code{<marketvercode>}) in the public index file.
@node No Source Since
@section Setting up a build server
In addition to the basic setup previously described, you will also need
-a Vagrant-compatible Debian Testing base box called 'testing32' (or testing64
+a Vagrant-compatible Debian Testing base box called 'jessie32' (or jessie64
for a 64-bit VM, if you want it to be much slower, and require more disk
space).
@example
cd /path/to/android-sdk/platforms
tar czf android-19.tar.gz android-19
-mv android-19.tar.gz /path/to/buildserver/addons/cache/platforms/}
+mv android-19.tar.gz /path/to/buildserver/addons/cache/platforms/
@end example
If you have already built a buildserver it is also possible to get this
~ianmdlvl / fdroidserver.git / blobdiff