=Basic instructions= 1. Copy config.sample.py to config.py and edit the path within accordingly to point to the Android tools 2. Make a repo directory and put APK files in it 3. Run update.py 4. If it reports that any metadata files are missing, you can create them in the metadata directory and run it again. 5. To ease creation of metadata files, run update.py with the -c option. It will create 'skeleton' metadata files that are missing, and you can then just edit them and fill in the details. 6. Then, if you've changed things, run update.py again. 7. Running update.py adds an Icons directory into the repo directory, and also creates the repository index (index.xml). 8. Transfer the repo directory to the appropriate http server. The script in upload.sh is an example of how to do this. =Build System Requirements= To be able to auto-build packages, you're going to need: *Linux *Python *A fully functional Android SDK with all SDK platforms and tools *The Android NDK *Ant *Ant Contrib Tasks (Debian package ant-contrib) *JavaCC (Debian package javacc) *VCS clients: svn, git, hg, bzr *A keystore for holding release keys. (Safe, secure and well backed up!) You then need to create a config.py (copy config.sample.py and follow the instructions) to specify the locations of some of these things. Also make sure the SDK tools - found in $SDK/tools/ - are in your $PATH. =MetaData= Information used by update.py to compile the public index comes from two sources, 1) the APK files in the repo directory, and 2) the metadata files in the metadata directory. The metadata files are simple, easy to edit text files, always named as the application's package ID with '.txt' appended. Within the file, the following fields are recognised: ==License== The license for the application. Common values: GPLv2, GPLv2+, GPLv3, Apache2, MIT, BSD ==Name== The name of the application. Normally, this field should not be present since the application's correct name is retrieved from the APK file. However, in a situation where an APK contains a bad or missing application name, it can be overridden using this. ==Web Site== The URL for the application's web site. ==Source Code== The URL to view or obtain the application's source code. This should be something human-friendly. Machine-readable source-code is covered in the 'Repo' field. ==Issue Tracker== The URL for the application's issue tracker. Optional, since not all applications have one. ==Summary== A brief summary of what the application is. ==Description== A full description of the application. This can span multiple lines, and is terminated by a line containing a single '.'. ==Repo Type== The type of repository - for automatic building from source. If this is not specified, automatic building is disabled for this application. Possible values are: git, svn, hg, bzr ==Repo== The repository location. Usually a git: or svn: URL. Normally the repository is checked out once for the application, then moved to a particular revision/commit/tag for each build version. For an SVN repository though, this behaviour can be changed by appending a * to the repository URL - in this case the repository is checked out once per build version, with the subdir parameter in place of the *. This can be beneficial when dealing with very large SVN repositories. For a Subversion repo that requires authentication, you can precede the repo URL with username:password@ and those parameters will be passed as --username and --password to the SVN checkout command. ==Build Version== Any number of these fields can be present, each specifying a version to automatically build from source. The value is a comma-separated list. For example: Build Version:0.12,3,651696a49be2cd7db5ce6a2fa8185e31f9a20035 The above specifies to build version 0.12, which has a version code of 3. The third parameter specifies the tag, commit or revision number from which to build it in the source repository. In addition to the three, always required, parameters described above, further parameters can be added (in name=value format) to apply further configuration to the build. These are: subdir=<path> - Specifies to build from a subdirectory of the checked out source code. Normally this directory is changed to before building, but there is a special case for SVN repositories where the URL is specified with a * at the end. See the documentation for the Repo field for more information. bindir=<path> - Normally the build output (apk) is expected to be in the bin subdirectory below the ant build files. If the project is configured to put it elsewhere, that can be specified here, relative to the base of the checked out repo.. oldsdkloc=yes - The sdk location in the repo is in an old format, or the build.xml is expecting such. The 'new' format is sdk.dir while the VERY OLD format is sdk-location. Typically, if you get a message along the lines of: "com.android.ant.SetupTask cannot be found" when trying to build, then try enabling this option. target=<target> - Specifies a particular SDK target, when the source doesn't. This is likely to cause the whole build.xml to be rewritten, which is fine if it's a 'standard' android file or doesn't already exist, but not a good idea if it's heavily customised. rm=<relpath> - Specifies the relative path of file to delete before the build is done. The path is relative to the base of the build directory - i.e. the directory that contains AndroidManifest.xml. antcommand=xxx - Specify an alternate ant command (target) instead of the default 'release'. insertversion=x - If specified, the pattern 'x' in the AndroidManifest.xml is replaced with the version number for the build. insertvercode=x - If specified, the pattern 'x' in the AndroidManifest.xml is replaced with the version code for the build. update=no By default, 'android update project' is used to generate or update the build.xml file. Specifying update=no bypasses that. initfun=yes Enables a selection of mad hacks to make com.funambol.android build. Probably not useful for any other application. buildjni=yes Enables building of native code via the ndk-build script before doing the main ant build. submodules=yes Use if the project (git only) has submodules - causes git submodule init and update to be executed after the source is cloned. Another example, using extra parameters: Build Version:1.09.03,10903,45,subdir=Timeriffic,oldsdkloc=yes ==Use Built== Set this to "Yes" to use built versions of the application for the repository. Currently, this just triggers update.py to copy the relevant apks and tarballs from the 'built' directory before updating the repo index. ==AntiFeatures== This is optional - if present, it contains a comma-separated list of any of the following values, describing an AntiFeature the application has: "Ads" - the application contains advertising "Tracking" - the application tracks and reports your activity to somewhere "NonFreeNet" - the application promotes a non-Free network service "NonFreeAdd" - the application promotes non-Free add-ons ==Disabled== If this field is present, the application does not get put into the public index. This allows metadata to be retained while an application is temporarily disabled from being published. The value should be a description of why the application is disabled.