Applications screenshots support

It would be useful to have screenshots of applications available when looking at the details.

This was discussed here: https://f-droid.org/forums/topic/pictures-in-f-droid-client/

I totally agree with that! And it is not so hard to implement! Apps with screenshots are much better! We are not at dialup epoch

Added requires-fdroidserver-changes label

This is the most important feature missing from F-Droid, and the simplest one.

Far, far from being the simplest one.

@shvelo To clarify - I recently added the "requires-fdroidserver-changes" tag to this issue to indicate that it requires changes to the entire F-Droid infrastructure. It is not just a matter of adding a few ImageView's to the Android application (though you are correct that this in itself is not difficult). In addition, there are non-trivial privacy issues with using images hosted elsewhere, and money and infrastructure issues worth considering if we host the images ourselves.

I think we're missing the bigger issue here, which is where the pics will come from themselves. Upstream devs rarely get involved in maintaining their apps on F-Droid. We can't just use the pics from Google Play, that's probably violating some terms, conditions or licensing. And can we trust user-provided pics?

That is all assuming we want pics. I personally don't care, since they would have to be very well maintained to actually mean anything.

+1 what is an appstore without a preview? most app descriptions don't list the features so trying them without an idea what i will get is not convenient.

Wasn't there this idea to get screenshots and maybe other information like up-to-date descriptions from the app's git repo? Why not introduce a new folder called ".fdroid" where the app developer can place these screenshots again with well-known names like "screenshot{1,...,n}.png"

@obama F-Droid is not an app store :)

@dschuermann I worked on something similar to that, but ended up working on different areas of the project. Main reason is I'm not interested in screenshots myself, and I'd rather work on something that is interesting to me.

I like the idea of looking for a folder in the repo first, as the dev should have the ultimate say in how their app is shown. For apps without images though, I suggest that we basically run a script that opens the app, waits a few seconds and then grabs a screenshot automatically. This way we know the image is trustworthy and we have an image for every app. She, there may be some where you get a picture of a setup screen or something, but this is still better than nothing and in many cases, could well motivate the app developers to set up their own images, especially if we have a clear link along the lines of "Update image" that tells users and devs how to get a newer image there.

I do wish we could find some way of accepting user images, as I know if be more than happy helping in this way. I do agree though that trust is an issue here.

PS. I, personally am desperate for this feature especially for games!

If you want to implement a way to automagically grab screenshots from apps, you can implement one and then we'll consider using it. But I myself see tons of issues with that idea. Firstly, I don't even know how you would implement that in a reliable, fast way that didn't mean firing up the emulator hundreds of times just to grab some screenshots.

Moreover, most apps show irrelevant stuff for the first seconds or until the user interacts with the app. Take Telegram for example. Until you register, the only thing it shows is a screen with "sign up". That's useless as a screenshot.

+1 for screenshots. most users would want to see what the app looks like.

Why don't we just add a field screenshots to the app's metadata, that contains a list of image URLs? Then developers can just link pictures on their server, on Github etc. I'm actually surprised this hasn't been suggested yet.

Alternatively, IPFS might be a solution to decentralize the screenshot distribution.

@Nutomic that would work, except for thumbnails. Without thumbnails, you have to download the entire image to just show its thumbnail. This might not be a huge problem since screenshots aren't supposed to be very large, but some devices have very large resolutions and you could have relatively large screenshots.

Right, but we could generate thumbnails on the server during the build process. Bandwidth requirements for that should be acceptable.

Ah, and then serve both original and thumbnail from our server. Makes sense.

I was envisioning something very similar, but limited to images checked into the source repo of the app. Clearly, a list of links is more versatile as it can support those (e.g. github raw links) as well as pictures from imgur or anywhere else.

The only thing left then is how would these be represented in the index and http static dir. I would probably go for:

/repo/screenshots/$appid/ for each app

In that directory, multiple image files of any format that Android can consume (jpg, png).

In the index, in the <application> tag, a <screenshots> tag with a comma-separated list of the filenames mentioned above.

For simplicity, I would make the server rename all files. To avoid re-downloading the same files if the order changes, I would make the filename be some sort of small hash of the file. md5, for example.

If we named the files from 1 to n like 1.png, 2.png etc, if they are reordered the client would redownload them since the etags would not match. If they are named after their content, e.g. md5, that won't happen.

Thoughts, @pserwylo et al?

We could also truncate the md5 to 8 or 16 hex characters, instead of 32.

I actually thought the full size screenshot would be loaded from the original URL on the device, because of the bandwidth concerns mentioned earlier. But putting it on the server would certainly simplify things.

MD5 should be good enough for this purpose, but why not do the right thing and go with SHA-2?

@mvdan: sounds good. I think @Nutomic is right with a SHA-2 hash instead. I'd also just clarify:

In the index, in the <application> tag, a <screenshots> tag with a comma-separated list of the filenames mentioned above.

I presume by "filenames", you mean just the hashes? The metadata for building should have full filenames, but we only need hashes for the filenames (and as you said, only the first so many characters).

Also, perhaps keep in mind some way to specify the "main" image. It seems that many app stores have one main image which shows by default which is treated slightly differently than others (e.g. shown more prominently).

Otherwise sounds great.

I presume by "filenames", you mean just the hashes?

The filename will be used as /repo/screenshots/$appid/$filename. They will be foo.png, bar.jpg, etc. The names are arbitrary, just like the icon names. fdroid update will use hashes, but that's just one way to do it. I can set up my own repo and name them from 1 to n if I want to. The client doens't care.

Also, perhaps keep in mind some way to specify the "main" image.

They come in order, so first is the most important.

I forgot thumbnails. Let's do /repo/screenshots/$appid/$filename-thumb.png. Yes, that will result in weird names like foo.jpg-thumb.png. But I don't want to say foo-thumb.png as that is not as straightforward and will make me specify the difference between name and filename.

mentioned in issue fdroidserver#174 (closed)

Just noting here while we think about it, after a discussion about UX for the Bazaar project, that we should at least leave open the option for specifying specific images that adhere to various specs in the Play Store:

https://support.google.com/googleplay/android-developer/answer/1078870?hl=en

• Promo Graphic
• Feature graphic
• etc.

It is highly likely that app developers who submit to F-Droid have already submitted to another store (likely Play Store if available in their country). If so, they will have these images available. If we make them available to the F-Droid client via our metadata format, then they can be incorporated by @crwinfrey as she works on the newer design for the client. See, e.g. the first layout sketch in #709 (closed).

There's also a gradle plugin called gradle-play-publisher which stores Google Play metadata in the project repository. It might be a good idea to use the same (or a similar) format for the graphics in F-Droid. The folder layout for images is described here.

mentioned in issue #709 (closed)

Thanks @Nutomic! Some questions arise:

• Do we want to tackle images per-locale when the index does not support locales at all yet?
• Do we want to have all of those image categories? I bet we could do with just two or three to start with, keeping the same names.

Right, per-locale images and all kinds of categories sound like overkill at this point. But it sounds like a good inspiration for the file layout.

However, thumbnails aren't included here. Those could probably be stored in separate *-thumbnail folders with the same filename.

First, apologies for writing this all in a code block. It was the only way to get markdown styling to not mess with my formatting. That aside...basically, the core decision that seems to need to be made is  this:

Do we have images:

1. Hosted by FDroid, and if so how we cover the financial requirement of hosting them (how to we handle the hosting costs of the current fdroid apk? Donations only?)

2. Hosted externally, and pulled in directly by the client, in which case do we:
a) Allow them to be hosted anywhere else, just requiring a URL, and if so are remote images on or off by default?
b) Find another host we trust (how do we decide who we trust?) to serve them like, I don't know, the Wikimedia foundation, or the Linux Foundation, or the FSF or similar.
c) Allow external hosting with limitations such as a blacklist (ie, not known, gigantic privacy sucking members of PRISM) or whitelist (similar to b but with a list of trusted, privacy aware hosts). Note that this could be configurable at the client level (eg. I'm happy to fetch images from kde.org and the FSF, but not Facebook). Sane defaults would matter though.
d) Use some form of distributed hosting such as bittorrent, IPFS etc. (Is every client a serving node? Battery consumption?)

3. Not at all, avoiding the issues of options 1+2 but putting Fdroid and it's free software at a disadvantage for creating a user experience that attracts/keeps users over commercial sources.


With option 1+2 there is also whether there's an option to turn them off and whether it's default, so as to minimize bandwidth costs / potential tracking. We also need to consider, whether our chosen option will eventually scale to video as well. Currently, we're already using number 3 just by not having decided yet...

Personally my preferences, in order from most preferred first, are options:

1  Possibly supported by something like the Wikipedia Foundation's annual crowdfunding campaign
2b With a community vetting process for who would be approached in the first place.
2c With a fairly privacy aware set of defaults and a user configurable black/whitelist.

Whichever is chosen though, I'd prefer that images could were on by default, but with the option to turn them off.

Now...It's been 2 years since this was originally opened. Hopefully we can come to some kind of definitive decision to at least finalise a spec (not even code) soon.

screenshots definitely need to have an associated locale with each one, that's standard practice with Android apps stores.

As stated by @Nutomic, per-locale screenshot are not very important at this point since all the other app info (like app description, etc.) is not per-locale. It's not worth over-engineering when the more basic stuff is not there yet anyway.

I agree with that approach, but for the record, per-locale app descriptions are coming within the next 6 months.

mentioned in issue #759 (closed)

Would the appdata format be relevant? Could it be extended for f-droid purpose?

@yes yeah, that looks like a good format for us to at least learn from

Looking at the appdata spec, they've basically gone with option 2a. Thinking about it, I think the balance point between functionality, privacy and cost may be:

1. A list of screenshot urls can be created in a file (appdata spec?) in the application source code by the dev(s)
2. The FDroid app keeps a blacklist of known privacy controversial sources (eg Facebook,Twitter,Flickr etc). I suggest we look at where current app repos are hosted for ideas. Later we could let people add/delete their own.
3. Images are turned on by default, unless they are from a blacklisted source. If they are from a blacklisted source, we show a message such as "Tap to view this screenshot from $BLACKLISTED_SERVER". There is also an "Information" icon in the corner (or the ! warning icon if we really wanted their attention). Tapping the info icon explains that viewing the screenshot allows $BLACKLISTED_SERVER to see some privacy-related information about you such as your IP address. It also explains that you can turn off blacklisting in the settings.
4. Provide an option in the settings to turn off blacklisting, and to turn off screenshots altogether.

This proposal would make sure that screenshots were developer approved, require no hosting from Fdroid, eliminate the largest privacy concerns by default, and all of them for people who preferred to have no images and would also subtly encourage developers to host their images on non-blacklisted, presumably more privacy-friendly sites, while also letting the majority of users see the screenshots for the majority of apps which supplied them, without having to change any settings.

I wouldn't underestimate just how powerful having average users see screenshots for apps, turned on by default could be for helping to spread libre software via FDroid.

I like your proposal, but the blacklisting should be simplified. Instead of a blacklist + option to ignore it, we should just require that images are hosted in the git repo (which means either Github or Gitlab for 99% of projects).

Milestone changed to %0.103 - UX Overhaul

I think @Bugsbane's propose exposes far to much complexity to the user, we can make screenshots work privately without the user knowing anything differently. The one thing I could see exposing is a "Full Private Mode" which does not load screenshots or any other data that would tell the server which app the user is looking at.

I've started implementing this. On the server-side, I think we can follow fastlane's directory layout: https://github.com/fastlane/fastlane/blob/master/supply/README.md

So then fdroid update will look for screenshots in repo/screenshots as well as build/packageName/metadata.

assigned to @eighthave

@eighthave: Adding you as assignee primarily so that the %0.103 - UX Overhaul milestone board correctly shows that this is in progress. I suspect this will be able to be closed when !422 (merged) is merged anyway (not up to date with any other details in this issue which may not be covered by that though).

Okay, to all those who are following this: F-Droid now has screenshot support! To check it out, enable the Guardian Project repo and then look at any of the apps from there. Screenshots for apps in the main F-Droid repository will come as upstream and maintainers start to add screenshots to the relevant metadata. If you run your own repository, now is the time to start doing this too so users will get screenshots of your apps.

closed

This is good to hear. Are there instructions for adding screenshots to apps? I couldn't find any in the manual. https://f-droid.org/manual/fdroid.html

The manual you linked to is out-dated but even the new manual has the info you need. Basically we follow fastlane, see https://github.com/fastlane/fastlane/blob/1.109.0/supply/README.md#images-and-screenshots

Ref: https://gitlab.com/fdroid/fdroid-website/merge_requests/49

Just want to say: Awesome work guys!

I just enabled fastline for OpenKeychain: https://github.com/open-keychain/open-keychain/tree/master/fastlane/metadata/android/en-US/images Let's see how this looks in the next update.

A few questions:

1. My understanding is that localizations in the F-Droid client are not yet implemented. Therefore, I am assuming you are currently pulling from one hardcoded locale. Is that en, en-US, or something else?

2. Are you using featureGraphic, icon, and promoGraphic for anything?

3. Do you support the phoneScreenshots, sevenInchScreenshots, and tenInchScreenshots directories?

4. How does one specify the order of the screenshots?

5. What is the recommended/supported resolutions for the screenshots?

mentioned in merge request fdroiddata!2224 (merged)

@dschuermann looks like you have an extra directory level "images" in your fastlane setup, see:

• https://fdroid.gitlab.io/fdroid-website/docs/All_About_Descriptions_Graphics_and_Screenshots/
• https://github.com/fastlane/fastlane/blob/1.109.0/supply/README.md#images-and-screenshots

@sorenstoutner F-Droid client 0.103 has full support for localized screenshots, graphics, and descriptive material.

@dschuermann arg, fastlane changed their layout. I'll have to fix that.

mentioned in issue fdroidserver#357