@item
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}.
+Python 3.4 or later
@item
The Android SDK Tools and Build-tools.
Note that F-Droid does not assume that you have the Android SDK in your
@item
Ruby (debian packages ruby and rubygems)
@item
-Vagrant (unpackaged, tested on v1.4.3)
+Vagrant (debian package vagrant - 1.4.x or higher required)
@item
vagrant-cachier plugin (unpackaged): `vagrant plugin install vagrant-cachier`
@item
following:
@example
-./fdroid build org.fdroid.fdroid:16
+fdroid build org.fdroid.fdroid:16
@end example
This attempts to build version code 16 (which is version 0.25) of the F-Droid
If you were intending to publish these files, you could then run:
@example
-./fdroid publish
+fdroid publish
@end example
The source tarball would move to the @code{repo} directory (which is the
party.
+@section Running "fdroid build" in your app's source
+
+Another option for using @code{fdroid build} is to use a metadata file
+that is included in the app's source itself, rather than in a
+@code{metadata/} folder with lots of other apps. This metadata file
+should be in the root of your source repo, and be called
+@code{.fdroid.json}, @code{.fdroid.xml}, @code{.fdroid.yaml}, or
+@code{.fdroid.txt}, depending on your preferred data format: JSON,
+XML, YAML, or F-Droid's @code{.txt} format.
+
+Once you have that setup, you can build the most recent version of
+the app using the whole FDroid stack by running:
+
+@example
+fdroid build
+@end example
+
+If you want to build every single version, then specify @code{--all}.
+
+
@section Direct Installation
You can also build and install directly to a connected device or emulator
@node Importing Applications
@chapter Importing Applications
-To help with starting work on including a new application, @code{fdroid import}
-will take a URL and optionally some other parameters, and attempt to construct
-as much information as possible by analysing the source code. Basic usage is:
+To help with starting work on including a new application, use
+@code{fdroid import} to set up a new template project. It has two
+modes of operation, starting with a cloned git repo:
@example
-./fdroid import --url=http://address.of.project
+git clone https://gitlab.com/fdroid/fdroidclient
+cd fdroidclient
+fdroid import
@end example
-For this to work, the URL must point to a project format that the script
+Or starting with a URL to a project page:
+
+@example
+fdroid import --url=http://address.of.project
+@end example
+
+When a URL is specified using the @code{--url=} flag, @code{fdroid
+import} will use that URL to find out information about the project,
+and if it finds a git repo, it will also clone that. For this to
+work, the URL must point to a project format that the script
understands. Currently this is limited to one of the following:
@enumerate
@item
+GitLab - @code{https://gitlab.com/PROJECTNAME/REPONAME}
+@item
Gitorious - @code{https://gitorious.org/PROJECTNAME/REPONAME}
@item
Github - @code{https://github.com/USER/PROJECT}
they do not provide any option to reproduce or verify the resulting
binaries. Builds pre-release versions in some cases.
+@item
+@samp{Clojars} - Clojure libraries repo.
+
+@item
+@samp{CommonsWare} - repo holding a collection of open-source libs.
+
@end itemize
@item patch=x
that included legacy toolchains, so as to not break builds that require
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, r10e. You may add support for more versions by
-adding them to 'ndk_paths' in your config file.
+The buildserver supports r9b with its legacy toolchains, r10e, r11c and the
+latest release as of writing this document, r12b. 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
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.
-@item output=path/to/output.apk
-To be used when app is built with a tool other than the ones natively
-supported, like GNU Make. The given path will be where the build= set of
-commands should produce the final unsigned release apk.
+@item output=glob/to/output.apk
+Specify a glob path where the resulting unsigned release apk from the
+build should be. This can be used in combination with build methods like
+@code{gradle=yes} or @code{maven=yes}, but if no build method is
+specified, the build is manual. You should run your build commands, such
+as @code{make}, in @code{build=}.
@item novcheck=yes
Don't check that the version name and code in the resulting apk are
archive. This app-specific policy setting can override that.
Currently the only supported format is "n versions", where n is the number
-of versions to keep.
+of versions to keep. Defaults to "3 versions".
@node Update Check Mode
@section Update Check Mode
@item
@code{None} - No checking is done because there's no appropriate automated way
of doing so. Updates should be checked for manually. Use this, for example,
-when deploying betas or patched versions; when builds are done in a directory
+when deploying unstable or patched versions; when builds are done in a directory
different to where the AndroidManifest.xml is; if the developers use the
Gradle build system and store version info in a separate file; if the
developers make a new branch for each release and don't make tags; or if you've
source repository is checked, looking for the highest version code. The
appropriateness of this method depends on the development process used by the
application's developers. You should not specify this method unless you're sure
-it's appropriate. It shouldn't be used if the developers like to tag betas or
-are known to forget to tag releases. Like RepoManifest, it will not return the
-correct value if the directory containing the AndroidManifest.xml has moved.
-Despite these caveats, it is the often the favourite update check mode.
+it's appropriate. It shouldn't be used if the developers like to tag unstable
+versions or are known to forget to tag releases. Like RepoManifest, it will not
+return the correct value if the directory containing the AndroidManifest.xml has
+moved. Despite these caveats, it is the often the favourite update check mode.
It currently only works for git, hg, bzr and git-svn repositories. In the case
of the latter, the repo URL must contain the path to the trunk and tags or
@cindex Current Version
The name of the version that is current. There may be newer versions of the
-application than this (e.g. betas), and there will almost certainly be older
-ones. This should be the one that is recommended for general use.
+application than this (e.g. unstable versions), and there will almost certainly
+be older ones. This should be the one that is recommended for general use.
In the event that there is no source code for the current version, or that
non-free libraries are being used, this would ideally be the latest
version that is still free, though it may still be expedient to
@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 'jessie32' (or jessie64
-for a 64-bit VM, if you want it to be much slower, and require more disk
-space).
+a Vagrant-compatible Debian Testing base box called 'jessie64'.
You can use a different version or distro for the base box, so long as you
don't expect any help making it work. One thing to be aware of is that
~ianmdlvl / fdroidserver.git / blobdiff