7.23 Update Check Mode

This determines the method using for determining when new releases are available - in other words, the updating of the Current Version and Current Version Code fields in the metadata by the fdroid checkupdates process.

Valid modes are:

• 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 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 changed the package name or version code logic.
• Static - No checking is done - either development has ceased or new versions are not desired. This method is also used when there is no other checking method available and the upstream developer keeps us posted on new versions.
• RepoManifest - At the most recent commit, the AndroidManifest.xml file is looked for in the directory where it was found in the the most recent build. 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. For example, some developers bump the version when commencing development instead of when publishing. It will return an error if the AndroidManifest.xml has moved to a different directory or if the package name has changed. The current version that it gives may not be accurate, since not all versions are fit to be published. Therefore, before building, it is often necessary to check if the current version has been published somewhere by the upstream developers, either by checking for apks that they distribute or for tags in the source code repository.

  It currently works for every repository type to different extents, except the srclib repo type. For git, git-svn and hg repo types, you may use "RepoManifest/yourbranch" as UCM so that "yourbranch" would be the branch used in place of the default one. The default values are "master" for git, "default" for hg and none for git-svn (it stays in the same branch). On the other hand, branch support hasn't been implemented yet in bzr and svn, but RepoManifest may still be used without it.

• RepoTrunk - For svn and git-svn repositories, especially those who don't have a bundled AndroidManifest.xml file, the Tags and RepoManifest checks will not work, since there is no version information to obtain. But, for those apps who automate their build process with the commit ref that HEAD points to, RepoTrunk will set the Current Version and Current Version Code to that number.
• Tags - The AndroidManifest.xml file in all tagged revisions in the 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 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 else no tags will be found.

  Optionally append a regex pattern at the end - separated with a space - to only check the tags matching said pattern. Useful when apps tag non-release versions such as X.X-alpha, so you can filter them out with something like .*[0-9]$ which requires tag names to end with a digit.

• HTTP - HTTP requests are used to determine the current version code and version name. This is controlled by the Update Check Data field, which is of the form urlcode|excode|urlver|exver.

  Firstly, if urlcode is non-empty, the document from that URL is retrieved, and matched against the regular expression excode, with the first group becoming the version code.

  Secondly, if urlver is non-empty, the document from that URL is retrieved, and matched against the regular expression exver, with the first group becoming the version name. The urlver field can be set to simply '.' which says to use the same document returned for the version code again, rather than retrieving a different one.