@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.
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
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.
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