fdroiddata/metadata/template

## See http://f-droid.org/manual for details
## Delete fields that are not needed
## Blank lines are customary as they are seen here 
# 
# Only used for making an app disappear from the index
Disabled:
# Only changes the name in the index. Not generally required
Name:
# Hard-coded in the client/web repository. Separate values with a ";"
AntiFeatures:
# Not hard-coded but look at the pre-existing ones. Separate with a ";"
Category:
# The overall license: must be compatible with licenses of components
License:
# Leave blank if the same as Source Code
Web Site:
# Should be http(s)://
Source Code:
# Should be http(s):// 
Issue Tracker:
# A dedicated web page with donation buttons is preferred
Donate:
# See http://flattr.com. Not visible in the client/web repository yet
FlattrID:
# Not visible in the client/web repository yet
Bitcoin:

# Jargon-free description, not longer than 40 characters
Summary:
# A description goes ''under'' this field
# The description is terminated by a line with a single "."
Description:
Blank lines indicate a new paragraph and it is preferrable to make a new
line for a new sentence.
It is applicable to the Recommended Version i.e. the version that's closest
to the Current Version (see below).

* It should be fairly future proof, unless you intend to keep it updated 
* Not be too short 
* The maximum line length is 80 chars, unless the basic MediaWiki markup is used

Requires root: No. The app can reboot the phone if it is allowed root.

Anti-features: Tracking and Network Services. The app uploads usage statistics
periodically to a server whose location is hard-coded into the app.

Status: Last version; still in BETA.

[https://github.com/k9mail/k-9/raw/master/res/raw/changelog.xml Changelog]
.

# Yes is the only possible value
Requires Root:

## These next three only apply to apps with source-built versions
Repo Type:
Repo:
# Version Names and Codes must be distinct
# Any jars or prebuilts should have references, preferably in the README
Build Version:

# Comments on what to watch out for when adding new Build Versions (BVs) go here
# This field is best used at the discretion of the repo maintainers
Auto Update Mode:
# One of Tags, RepoManifest, Static, Market or None (in that order of preference)
# If None, describe how to obtain the Current Version (CV) in a comment 
# Tags and RepoManifest (RM) are automatic but check that the mechanism works
# Use Static if you plan to let the maintainers know in person (so to speak)
Update Check Mode:
# These two are usually in the AndroidManifest.xml, but can be automatically
# updated according to value of the previous field
Current Version:
Current Version Code: