Are F-Droids apps in general considered adware-free/without trackers?

I would like to know more about requirements for apps to be included in the store:

Do apps mainly need to be opensource/libre, with the ability to be built separately
or in addition
do they need to be free of adware/trackers etc. ?

If the former is true, an app just needs to be open source and could still include trackers, even if publicly visible in the code. Given this case, does F-Droid display any warnings?

What lead me to this question:
QuickLyric is an app available on F-Droid that fetches lyrics and detects played songs on the device.

Though if I search for this app on, 14 trackers are reported for the Google Play version.

Can I rely on the fact, that all these trackers are ensured to be removed in the F-Droid version? TIA

Maybe my new article (from yesterday) can help you out, as it describes the steps taken at review?

That could happen, if the ad library as well as the tracking library are open source, yes. In that case we’d add the AntiFeatures Ads and Tracking, so you’ll clearly see it along the app’s description on the website as well as in the client, before you install such an app.

Yes, see our list of AntiFeatures.

Which is not identical to ours. The version on Play was built by the developer, ours was built by us. Now let’s look at our build recipe for QuickLyric (I’ve picked an older build as it’s simpler and still shows what we need here):

  - versionName: 1.5.3
    versionCode: 6
    commit: 1.5.3
    subdir: QuickLyric
      - fdroid

The relevant part here is gradle: fdroid. This means the authors provided a special build flavor for F-Droid, which builds the app without any proprietary dependencies – so those 14 trackers won’t show up here. You can cross-check that at Exodus: Go to this page, enter the packageName com.geecko.QuickLyric, make sure to select the “F-Droid” radio button, and hit “submit” – Exodus then will scan the APK from F-Droid and show you the results.

We might have missed some (if there was an yet-unknown/knew one), but in general, as I wrote: no Tracking AntiFeature, no trackers.


Maybe this link to yesterday’s article works better for non site admins.


@Izzy Thank you, much appreciated. Things are clear now.

Maybe this link to yesterday’s article works better for non site admins.

I was about to ask :slight_smile: - this link works.

Have you thought to put the content as part of the Contribute front page or similar? This information puts transparency and trust even to another level.

1 Like

Yuck, it happened again… Thanks! Fixed it in my answer as well.

Thanks! :green_heart: :heart_eyes: And yes, once it’s mature enough. Currently I still consider it “work in progress”. Give it a few weeks, with some new contributors having tried it and reported back. Once other team-members consider it “production ready”, I’ll happily hand over the Markdown code of the page so it can be integrated with the official docs.


It is also worth noting that, in some cases (e.g. Fennec F-Droid), the trackers present in the upstream version are replaced with stubs that do not do anything, but have the same class names as the actual trackers. Thus, some tools like Exodus may report there are trackers in such apps even when they are stubbed out. You can see the patch that does this for Fennec here.

I like to assume by default that everyone in the free software or “FOSS” community (the “good guys” so to speak) are on the same team. So, if there are reports of trackers or other bad behavior in a free/libre app, it should not be taken at face value but merely as a suggestion to investigate further.

1 Like

@adrianmalacoda this is interesting to hear. I am almost sure to have read about Fennec F-Droid still containing trackers in a forum a couple days ago (I guess you mean this report?)

Is there a compelling reason to do it this way? Wouldn’t it better to remove trackers instead of stubbing them out to increase trust in F-Droid? I would naively have thought, these trackers shouldn’t have any side effect or dependencies/dependent programs.

@Izzy @adrianmalacoda One more thing bothers me: Currently, is the application name / package name / upstream version of an app somewhere shown on the F-Droid website to easily look it up on εxodus?

With QuickLyric, I could go to Google Play Store and copy the id query parameter from the URL.

But I cannot find “Fennec” in the Play Store. And typing “Fennec” in the “URL of the application” field of εxodus gives me “Fennec is not a valid application handle”.

Regarding Fennec, I imagine it’s because the codebase is so large that stripping out calls to those trackers is non-trivial and it would be far simpler to just stub the trackers out. Keep in mind that the more patches are added to the F-Droid variant, the more that can potentially break when Mozilla pushes an update. It is desirable to keep as few patches as possible.

Yes. You can copy it from the URL:<packageName>/. Then paste the <packageName> into the form at Exodus, check the “F-Droid” radio box, and submit. You should then get a report on it.

Similar here, as shown :smiley:

That’s my guess as well.

@Izzy oh my gosh, I thought I’d have eyes :joy: .

Concerning stubbing out: makes absolutely sense then. Would have been nice, if exodus can recognize empty stubs, but that is outside scope.

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.