Screenshots support/Metadata documentation


#1

Hello there,
I’m trying to find any kind of documentation concerning metadata format. Is there something to add for including app screenshots? I found that Courier by GuardianProject has screenshots, but the metadata file is no different than mine (org.kontalk). What do I have to add?

Thanks


#2

Ok maybe I found something:

https://fdroid.gitlab.io/fdroid-website/docs/All_About_Descriptions_Graphics_and_Screenshots/

I see that the app will consider files for Triple-T Gradle Play publisher. How can I see if that’s working before actually releasing? I’m using F-Droid 0.103.1 (I don’t even know if it’s implemented on the client yet).


#3

Does anyone have information where exactly the screenshots have to be in the app repo? We use Triple-T Gradle Play Publisher for Syncthing, but the screenshots dont show up in F-Droid.

Screenshots are here: https://github.com/syncthing/syncthing-android/tree/master/src/main/play/en-GB/listing


#4

This stuff is in final testing before we roll it out on f-droid.org. We need to make sure our infrastructure can handle a big, new influx of data before this is enabled. The tools fully support this, and there are repos that already have working screenshots and localizations; for example, https://guardianproject.info/fdroid

If you want to help with the f-droid.org testing, you can see a unsigned test copy of the new index file, index-v1.json, which includes all of this info: https://f-droid.org/repo/index-v1.json

Looking at that file, I can see that the localized stuff for org.kontalk is included, but not Syncthing. Currently, the Triple-T scraping is based on the default gradle filesystem layout, so like */src/main/play. Syncthing has it in src/main/play. The best solution would be if fdroid update could read the gradle config files. gradle is ridiculously slow, so calling it in the fdroid update process to get info is not feasible. I looked but didn’t find a groovy/gradle parser for Python. That would be ideal, then fdroid update would just read the gradle config directly, instead of scanning for a directory named “play” at a certain level deep in the filesystem.


#5

About Gradle in Python, I found this:


#6

That’s the other way around: that supports building Python using Gradle, not parsing Gradle from Python.