F-Droid Screenshots and Metadata: Where Each File Goes

I read F-Droid's guide to descriptions, graphics and screenshots, its build metadata reference and its Anti-Features page on October 26, 2026. I checked each file name against the two folder trees in the guide.

Here's where each file goes, the limits on each one, and what F-Droid does when two sources disagree.

These are the files in F-Droid's fastlane style layout, for one language.

Only the two descriptions are required. The guide calls every other metadata file completely optional.

Optional doesn't mean unimportant, though. Several of these files decide whether your app appears on the Latest tab.

F-Droid's descriptions and screenshots guide lists three ways to supply metadata.

1. 1In your app's source repository.
2. 2In an fdroiddata collection of build metadata.
3. 3Directly in an F-Droid repo.

For the official F-Droid repository, the guide strongly encourages the first one. You control the files, and F-Droid copies them over automatically, with no merge request.

It's also the only way to provide images there, such as the icon or screenshots. The other two routes are for people who host their own repositories.

One detail matters for timing. F-Droid only uses metadata files from the latest release it knows about. So a new screenshot shows up after F-Droid picks up your next release, not after any commit.

The fastlane style tree has to sit in one of a few places, counted from your repository's root.

Swap locale for a code such as en-US, and buildFlavor or subdir for your real names.

The guide is blunt about everything else. Placing the tree anywhere else, such as in the Gradle module's root, won't work.

It also warns that some setups with build flavors, or several apps in one repository, aren't fully supported yet.

Three text files carry your listing copy.

The title.txt file holds the app name, up to 50 characters. Your summary goes in short_description.txt, up to 80 characters. The build metadata reference says the summary appears in the app list and tile views of the F-Droid client.

That makes the summary your one line pitch. Most people see it before anything else.

The full_description.txt file can run to 4000 characters. A video.txt file can hold one URL to a video that introduces the app.

Write the summary as a plain benefit. Say what the app does for the person reading it.

Phone screenshots go in images/phoneScreenshots, named in order: 1.png, 2.png and so on.

The guide also lists folders for other screens.

The guide says you may add different screenshots for different screen sizes. It doesn't set a pixel size for any of them.

The folders mirror the ones fastlane uses for Google Play, though. So a set built for our Play Store screenshot sizes is a sensible place to start.

The images folder also holds two single files.

Your app icon goes in icon.png. The featureGraphic.png file is a landscape promo banner. According to the guide, the F-Droid client shows it on top of your app's description.

A third file, tvBanner.png, is an icon for TV devices. The guide notes it's currently not used.

For sizes, the guide's Triple-T tree gives a hint. It describes the icon as usually 512 x 512 and the feature graphic as usually 1024 x 500.

Those match common Play Store sizes. The guide says usually, so treat them as a safe default, not a hard rule.

Images may be PNG or JPEG. The file must end in png, jpg or jpeg.

F-Droid also cleans every image before it goes into the repo. It strips metadata it calls dangerous and unneeded. The guide's example is JPEG EXIF data, which can carry security risks and isn't needed to show the image.

That cleaning has a side effect. The guide warns that images may be recompressed.

So start from sharp, uncluttered captures. A busy screenshot loses more detail when it's squeezed again. Our guide to capturing clean screenshots covers status bars, test data and other details to fix first.

Each release can carry its own What's New text. It lives in a changelogs folder, one file per version.

The file name must match the version code exactly. Version code 100100 needs a file called 100100.txt. The guide adds literally, with no padding, so don't add leading zeros.

Each changelog can be up to 500 characters.

A missing changelog doesn't break your listing. But it does matter for the Latest tab, which wants a What's New entry for at least one release.

Write each one for users, not for your commit log. Say what changed for them.

F-Droid also reads a second structure, built for the Triple-T Gradle Play Publisher plugin. It sits at module/src/main/play/, where module is often just the app folder.

The names differ from the fastlane tree.

Listings sit under a listings folder, one subfolder per language. Note that default.txt holds only the latest changelog. Triple-T also adds contact-email.txt and contact-website.txt at the top level.

Pick one structure and stick to it. Mixing names from both is an easy way to lose a file.

The fastlane style tree isn't a coincidence. The guide says it aims to match the fastlane supply tool, which publishes listings to Google Play.

So if you already run fastlane, you're most of the way there. A repo with fastlane/metadata/android/ in place can serve both stores from one set of files.

You don't need fastlane installed to use it, though. The guide says the structure can easily be created by hand.

If you'd like to automate it, our guide to automating screenshots with fastlane walks through screengrab and supply. Those tools fill this folder and upload it to Google Play.

Each language gets its own folder, named by locale code, such as ru or de.

The guide calls en-US the F-Droid fallback language. If a user's language has no folder, the client falls back to it.

When a translation exists, the client prefers it. The guide says localized metadata is always preferred.

Translation also helps on the Latest tab, which needs at least one translated item. Our guide to localizing store listings covers which parts are worth translating first.

The full description can use some HTML. The guide warns that not every tag works in the renderer.

These simple tags are supported: b, big, blockquote, br, cite, em, i, li, ol, small, strike, strong, sub, sup, tt, u and ul.

A link tag with an href is allowed for now. The guide says that might be removed without notice.

Many tags are banned outright. They include img, video, iframe, form, button, script and style.

So you can't embed a screenshot or a video in the description. Images belong in their folders, and the video belongs in video.txt.

Line breaks turn into br tags automatically, and JavaScript isn't allowed.

Since F-Droid client release 1.6, the Latest tab shows only apps that have all of these.

1. 1The app's name.
2. 2An icon.
3. 3A summary.
4. 4The full description.
5. 5A license.
6. 6What's New text for at least one release.
7. 7At least one graphic, a screenshot or a feature graphic.
8. 8At least one of the above translated.

Skip one, and your release won't appear there, even if it installs fine.

That's the real case for the optional files. One screenshot, one changelog and one translated summary clear the last three items.

Sometimes two sources hold the same field. The guide sets the order.

1. 1The app's metadata file in fdroiddata overrides fdroiddata's other files, even localized ones.
2. 2Those fdroiddata files override metadata from your app's source.
3. 3Both override data inside the APK, such as the app name.

The build metadata reference repeats the warning for the Name, Summary and Description fields. It says not to use them, and to keep that text in your source repo instead.

One label comes from F-Droid, not from you. Its Anti-Features page lists flags such as Ads and Tracking, shown on an app's details. The page says apps marked Tracking aren't displayed by default.

F-Droid takes plain PNG or JPEG files from your repo. Its guide doesn't set a style for screenshots.

Raw captures are fine there. If you'd like framed shots instead, our free mockup generator can help.

It places a screenshot in an iPhone, Pixel, Samsung, iPad or MacBook frame, and adds a gradient background and text. It exports at Play Store and App Store sizes.

Save the exports as 1.png, 2.png and onward in phoneScreenshots. Then check them once more after your next release, since F-Droid may recompress them.