Skip to content

App Inclusion Policy

Criteria for an app to be included with the IzzyOnDroid repository have a huge overlap with the F-Droid Inclusion Policy – as both repositories deal with free/libre open source apps. This page outlines which criteria an app must meet to be included at IzzyOnDroid – and which apps will not be included there.

What are the requirements an app must meet to be included with the repo?

The app …

  • must be free (as in „free beer“ and as in „free speech“) and Open Source (see e.g. Four Freedoms for what this means). This includes using a libre license, approved by OSI/FSF (see SPDX).
  • must be targeted at „end users“ (so no libraries, proof-of-concept demos, etc.)
  • must have its code freely accessible, preferably at Codeberg, GitLab, Github, or a similar platform (self-hosted Forgejo/GitLab instances are supported as well, if they are „permanently“ online and openly accessible). That code repository should have a proper description so it gets clear what it is (if it's not, those details must provided to us for inclusion by other means, e.g. in the issue requesting the app to be included).
  • preferably has no proprietary components. While some of them might be tolerable, trackers (e.g. ads, analytics) are bearable at best but only if there are no more than two such modules. Note that some such modules might be considered as too intrusive, and hence rejected in general.
  • must not download additional executable binary files (e.g. addons, auto-updates, etc.) without explicit user consent. Consent means it needs to be opt-in (it must not be harder to decline than to accept or presented in a way users are likely to press accept without reading) and structured in a way that clearly explains to users that they’re choosing to bypass the checks performed in this repo if they activate it.
  • must have its *.apk files signed by a release key, and not carry the flags android:debuggable or android:testOnly. Rare exceptions are possible e.g. when the APKs provided here are explicitly for testing (with the stable releases at F-Droid or in this repo using a different applicationId). This then needs to be made clear with the app description.
  • must have its .apk files available from the project. Currently, IzzyOnDroid can work with files
    • preferred (as only then it is possible to establish reproducible builds):
      • attached to Gitea/Forgejo tagged releases/ (e.g. at Codeberg, but also self-hosted)
      • attached to GitLab tags/ (at GitLab itself or self-hosted)
      • attached to Github tagged releases/
    • other places (deprecated):
      • uploaded inside a Github/GitLab repository as „part of the code“ (very bad practice!)
      • having fixed URLs (like https://example.com/app-latest.apk) which can be redirects, but the web server must provide a Last Modified header. This would for example also work with Sourceforge using https://sourceforge.net/projects/<projectName>/files/latest/download if maintainers do manually mark the corresponding APK file to be the default „latest“ for all platforms, where it not for Cloudflare (which injects their Captcha every now and then).
  • must have its own unique packageName and should have its own unique displayName
  • if the app is a fork of another app, it must
    • be clearly distinguishable by its display name, icon – and featureGraphic, if such exists
    • have its screenshots as well as short/full description dedicated to the app, and not just use a copy of the original one
    • have at least the intention of being maintained for the foreseeable future
  • if the app processes sensitive data (e.g. health data, passwords), is intended to improve security/privacy, has root permissions, or is targeted at children, it must have no ATS (Advertizing and Tracking Services) elements at all.
  • the android:usesCleartextTraffic flag should be avoided wherever possible and only be set were absolutely necessary (e.g. with a media player intended to access resources in the home network, or for access to a proxy/webserver running locally on the device it is acceptable). In such cases, a proper Network Security Configuration is strongly recommended to be established in the app. If you've never dealt with that before, A Security Analyst’s Guide to Network Security Configuration in Android P might be a good start to dig into that.

Running on private resources (no funding), IzzyOnDroid usually reserves up to 30 megabytes per app (exceptions are being made for some larger apps, so this is considered as rule-of-thumb). That's at the same time the upper size limit for single .apk files. If multiple files can fit in this limit, the repo holds up to 3 versions. Also, certain categories of apps are not accepted (see below). Exceptions are made, but not often.

Are there any app categories which are not acceptable to this repo?

  • Games are unlikely to be accepted (though exceptions are possible, e.g. for educational games). This includes apps mostly focusing on games and gaming.
  • Apps promoting violence, hate, harassment, racism and similar topics will definitely be rejected.
  • „Explicit content“ is not welcome here – mainly for the reason that all age groups incl. „minors“ should have access to this repo.
  • Apps which are loaded with trackers (Analytics, Ads, etc.) are no good, as they pose dangers to poeple's privacy.
  • Also for the reason of tracking, apps for Facebook, WhatsApp & Co won't be accepted.
  • Similarly, we do not accept apps supporting companies making profit based on other people's work obtained without or even against their consent. This includes e.g. apps for accessing most of the big so-called „AI“ platforms, having consumed large amounts of copyrighted work to be built – without compensation for, or even just consent by the respective creators.

This list is not complete (we might add to it if need arises), but should give you a raw idea.

App Removal

Apps no longer meeting above criteria, are subject to be removed. This usually happens in multiple steps, once an „offending update“ showed up:

  1. Said update is removed, and updates for the app are temporarily disabled – while the corresponding developers are informed, and given a chance to fix the problem.
  2. Should the problem be fixed, updates are re-enabled, starting with the latest (fixed) version.
  3. Is the problem not solved in reasonable time, either updates are permanently disabled – or the app is removed entirely.

Apps are also removed, if their author(s) request it. While the Four Freedoms (here: freedom-2) would allow us to keep them listed, we respect the authors' wishes in this regard.