This is an F-Droid style repository for Android apps, provided by IzzyOnDroid. Applications in this repository are official binaries built by the original application developers, taken from their resp. repositories (mostly Github).

If you are an open-source developer and wish your app(s) included, be welcome to contact us – which is ideally done via the Maintenance Repo at Codeberg; you can find our App Inclusion Policy at our website, along with other ways to reach us, a bunch of documentation, and more. Other tooling we use and maintain, can be found at our presence at Codeberg.Org.

DISCLAIMER: As stated above, all .apk files are directly taken from the repositories of their resp. developers. They are provided under FOSS licenses, without any warranty, though we've taken measures to provide our repository with additional transparency and safety checks (see the Security section below).

If you wish to use this repository with your F-Droid client, this is the URL you should use to add it:

https://apt.izzysoft.de/fdroid/repo

If you want to make sure it's the right one (and nobody played with DNS). you can use additionally enter this fingerprint in the appropriate field of your F-Droid client: 3BF0D6ABFEAE2F401707B6D966BE743BF0EEE49C2561B9BA39073711F628937A. Or, both combined (as the QR code on the main page does it):

https://apt.izzysoft.de/fdroid/repo?fingerprint=3BF0D6ABFEAE2F401707B6D966BE743BF0EEE49C2561B9BA39073711F628937A

If you open that URL with your browser on a mobile device having the F-Droid client installed via scanning of the QR code, you will be asked to open it with the F-Droid app, which then directly offers to add the repo – just asking you to confirm.

How do apps come into this repo?

From time to time, I (Izzy) check on Github, GitLab and Codeberg for repositories featuring Android apps which are not part of the main F-Droid repository, but have .apk files along with the code. If such an app seems useful, has been updated not too long ago (at least within the last 12 month), and seems legit, he takes a raw look at the .apk file (do the permissions look appropriate, are there and „crazy indicators“ making it look strange, does it pass our scanners) – and if it passes, it gets added.

Of course I won't find them all: some serve their .apk files along with the releases/ (which I favor), some simply have them amongst the repository files (acceptable), some do not have any at all, and I'm afraid I've missed a lot. So we are open to suggestions. To be accepted, good candidates must meet the App Inclusion Policy already mentioned above.

If you know an app that would fit those criteria but is not listed in this repo and meets the mentioned inclusion criteria, you're welcome to suggest it for inclusion (please use the matching template for this; you can choose another template if you instead need to file an issue for a problem you experience with this repo), specifying the necessary details.

What about updates?

Read between the lines above: if the .apk files were served in the releases/ resp. tags/ tree and are properly tagged for all versions, there is a script that runs automatically in regular intervalls to check for and download updates. For those apps, it works pretty well. Some other apps must be checked manually, which is not done on a regular base (but those are few).

How many versions are kept?

Usually up to 3 versions per app are kept in the repository, but in sum they shall not exceed the „hard limit“ mentioned with the inclusion criteria. If a newer version is released after that, the oldest version is automatically purged. And no, we currently do not plan keeping a second „Archive Repo“ for older versions.

Do apps get removed from your repo?

This indeed may happen. Apps might get „kicked out“ if it gets obvious something „bad“ slipped in – e.g. by users reporting bad behavior of an app installed from here – or the developers have added too many proprietary libraries, trackers etc., or the inclusion criteria have been broken otherwise with an update. Unfixed security issues which are not being addressed and thus putting people using the app at risk fall into this section, too.

We might also decide to drop an app which hasn't been updated for a long time, no longer provides .apk files despite of new releases, or lost its value for other reasons (e.g. the service behind it went out of business); especially for the latter we must rely on the support of those using the repo to report broken apps. But generally, we plan no „purge actions for dubious reasons“. Especially we don't have the policy of excluding Ad-Blockers and the like ;)

Apart from that, we tend to let those using the repo have a word on that, too. So you can find details e.g. in this poll. We might start more of them in the future.

What about security?

For this, multiple actions are taken:

Permissions requested by apps

The permissions an app requests are made transparent on a per-package base (i.e. they are shown for each version of an app separately, as they might change with each release). Permissions recorded with the IzzyOnDroid app lists are linked there for their resp. background. In addition to that, permissions which are considered to be „sensitive“ are highlighted (bold) and, if their need was clarified, accompanied by a short reason for the need.

Sensitive permissions which were not yet clarified receive an additional highlighting (italics and a warning color). Usually we reach out to the corresponding developer(s) and ask for clarification when we see such, but we might not yet have covered all apps. So if you see such, be welcome to help out: check if the app details show an „Issues“ link (leading to the app’s issue tracker), follow it, and search if a corresponding issue already exists. If so, feel welcome to „chime in“ (by adding a thumbs-up to signal you’d like to know that, too, or a comment if useful) – if not, please open one, ask, and if you receive an explanation just leave a comment @mentioning me (I’m „Izzy“ at Codeberg, and „IzzySoft“ at Github/GitLab) so I can include the proper explanation(s) here.

By the way: apps requesting dangerous permissions which are unclear and are not (or cannot be) clarified by their corresponding developer(s) might lead to their removal from this repo. One special case in this regard is REQUEST_INSTALL_PACKAGES with an app that’s not a package manager (e.g. an F-Droid client, APK Updater, Obtainium are examples of apps needing this), as this often indicates an integrated self-updater which would be a violation of this repository’s inclusion criteria. Those are tolerated when they are clearly opt-in (i.e. disabled by default) and before you can enable them, make clear where the APKs are downloaded from and what the implications are. If those updates are downloaded from outside this repository, all the „screening“ described here would be bypassed. We’re not saying you cannot trust the developers, but mistakes can happen to the best, and additional screening helps detecting what might have „accidentally slipped in“. So take extra vigilance with those self-updaters, please. Yes, you might get a new release a few hours earlier, but always ask yourself if it’s worth it.

Manifest checks

Each Android app has an AndroidManifest.xml where its activities, services, permissions and more are defined. Scans extract this file and run several checks on them:

• Flags:
  • Apps flagged for debugging are intended for development. This flag is already checked for by fdroidserver, and the corresponding apps will be marked with the ApplicationDebuggable anti-feature.
  • Apps flagged testOnly are not intended for contribution and thus should not be included with the repo here.
  • The usesCleartextTraffic flag should be avoided wherever possible. There are exceptions (e.g. for local resources), but all „public“ traffic (i.e. connections outside the local environment) should be properly encrypted via HTTPS to minimize the risk for MITM etc.
• Sensitive permissions: Permissions sensitive for your privacy (e.g. access to your contacts, calendar entries, installed apps, media files) are screened. Where justified, they go to a per-app allow-list. The corresponding authors/developers are contacted for clarification/adjustment where needed.
  App details highlight those: bold for sensitive permissions, bold and colored for sensitive permissions which have not yet been verified/allow-listed, and for each permission on hover a short description with what it stands for. Verified sensitive permissions also show a short text with an explanation on what they are needed for by the specific app.
• Sensitive service intent filters: some of them indicate possible risks, so these are screened the same way flags and permissions are:
  • AccessibilityService is to assist users with disabilities in using Android devices and apps. To do this, they allow to automatically perform tasks intentionally designed to be done manually by the person operating the device (think e.g. of applying certain settings or confirmations). So usage of this service must be well justified.
  • VpnService, as its name suggests, is intended for VPN clients. Another group having this justified implicitly are non-root firewalls like NetGuard and non-root ad-blockers, which need this to filter traffic.
  • InputMethod is reserved for, well, apps providing input methods. A keyboard app requires this to work. But there are other types of input methods where this is justified, e.g. barcode readers inside an inventory app (filling the field with the product code).

These checks are performed manually on new apps before they are included with the repo, and automatically for each incoming update.

SigningBlock checks

As the name suggests, these blocks are inserted when the APK is being signed. Signing is done either by the developers themselves, or by Google when the app is listed on Google Play and the developer decided to leave signing to the PlayStore. While one would assume only details of the signing itself (information about the certificate and checksums) to be present here, it turns out other things can enter this area as well. But apart from the APK signature scheme blocks (which cover exactly that), there are others which raise at least some warning flags:

• DEPENDENCY_INFO_BLOCK: This is supposed to contain a binary representation of the app’s build dependencies – but the BLOB is signed by a public key belonging to Google. So only Google can see and read what’s in here – and nobody else can even verify nothing else was included. Which not only makes it useless to anybody except Google, but it’s also intransparent and bears possible danger.
• GOOGLE_PLAY_FROSTING_BLOCK: this BLOB is added by Play Store to prove the particular file was downloaded from Play Store. It includes a rather complex metadata chunk encoded using Protocol Buffers. While protobuf is an open source format, without the definition file it’s hard to decipher – and rather useless for the FOSS world.
• SOURCE_STAMP_V1_BLOCK, SOURCE_STAMP_V2_BLOCK: Details on this can e.g. be found in SourceStampVerifier.java, where a comment describes them as

  SourceStamp improves traceability of apps with respect to unauthorized distribution. The stamp is part of the APK that is protected by the signing block. The APK contents hash is signed using the stamp key, and is saved as part of the signing block.

  In the open source world and with free/libre FOSS licenses, there should be no such thing as „unauthorized distribution“: the licenses make clear that the Four Essential Freedoms of Free Software are guaranteed – which include „The freedom to redistribute copies so you can help your neighbor“ (freedom-2) and „The freedom to distribute copies of your modified versions to others“ (freedom-3). It seems this is intended to ensure that all split APKs are coming from the same source, and the code to check that is public/FOSS, so we don't see why this should raise concerns – except for it being inserted by a 3rd party which is most likely Google.
• MEITUAN_APK_CHANNEL_BLOCK: this block includes JSON with some metadata, used by Chinese company Meituan. While „JSON metadata“ at first glance might sound harmless and innocent, it can also be used to inject payload (which Meituan in fact does, so this must be considered a risky one.

There might be other blocks which are not (yet) covered here. As the Meituan example shows, there might be other risky ones using this for payload; should we become aware of any such, they will of course be added to this check.

Signature verification

APKs in this repository are signed by their respective developers/authors. To ensure nobody placed a malicious APK into their realm which this repository here then would distribute, the signature of their signing key is recorded when the app is first added – and then compared to each update fetched. Should the signature check fail, that APK will not be included with the index, but a warning is sent to its administrator (Izzy) to check what happened (who will then contact the respective developer(s) to find out).

For some background: what would cause the check to fail? The check would fail when a different signing key was used to sign the APK. This could e.g. be the case if a developer lost their key (and thus had to create a new one), which unfortunately happens (and is the most usual reason for this mess). But it could also indicate that someone else signed the APK, somehow got access to the developer's account, and placed it there. So we're better safe than sorry.

So what if that check would not be in place? If you already had the app installed before, your Android system would do exactly the same: reject an APK if the signature doesn't match that of the installed version. But if this were the first time you'd install an app, Android would permit the installation (it has no records of a previously used key), and thus potentially put you in danger. We don't want that, right?

Malware scan

Apps in this repo are scanned for malware, using the services of VirusTotal. VirusTotal currently runs more than 60 engines to check files, which is quite some coverage. However, results differ between engines: some are more prone to „false positives“ than others, and some even report ads as malware (we might tend to agree on that). So results might look different – and here's how they are presented for each file in this repo (for other repos supported by this repo browsers, no such shield is available):

• Pending: This file was just added to the repo, and currently is enqueued for the scan. You should rarely see this, and usually it will be replaced within hours.
  
• Passed: This file has passed all scans, and no malware has been reported. That's what you should see in most cases.
• Notif: One scanner has reported a finding. As this means that 60+ others did not report anything, this can be given the doubt of a „false positive“ (in dubio pro reo). If you want to make sure, click the term to visit the VirusTotal result page for details. In many cases, you will just „roll your eyes“ then (as usually this is something reporting a „PUA“, Potentially Unwanted Addon).
• Warning: More than one, but less than five scanners reported they've found something. Please click the term to go to the result page and check. Again, these are mostly (and hopefully) just „false positives“.
• Alert!: This one you should see almost never. It means that five or more scanners reported findings. Such a file will usually be quarantined ASAP (the app might be unlisted for that), and the case investigated. In very rare cases, the file might still stay, and an explanation be added: after all, we cannot do anything about failing scanners. But for that to happen, a good foundation must be there which can be trusted. A good example for such a case would be an app testing your device for vulnerabilities: as it imitates malware, scanners are bound to fire.

Except for the „pending“ shield, the label will always link to the corresponding detail page at the VirusTotal website. Feel encouraged to check that. If a file is marked by a yellow or red shield, also check the app's description, which might hold further hints. Sometimes a finding might be „normal“ (e.g. a vulnerability test suite could easily trigger a „false alert“, as described above). Moreover, some scanners thread a „PUA“ (potentially unwanted addon/application) as alert – as indicated above.

Library scan

APK files are also checked for libraries they are using. This is done locally, using our own LibraryScanner (also including LibRadar). Findings are grouped into three categories:

• Libraries: These are usually development tools and libraries for „common tasks“ like parsing structures or dealing with network connections. Maps and social networking also fall into this category.
• Payment Modules: Basically, „all things money“. This is usually for in-app purchases, but could also be for „money transfers“.
• Ads & Analytics: Our favorites. Software being free and open source doesn't mean the compiled app cannot have some extras. Usually, if there are ad or analytics modules, that's also pointed out in the „AntiFeatures“ in the app description.

You will not only find the categories and names of libraries, but also some additional details: which permissions are found accessed by them is the most interesting part here. Where available, a link is given to their resp. websites/pages. Additionally, for most of the libraries there're additional details available, indicated by an icon and revealed by clicking on it:

• 👁 Image
  a short description is displayed inline (below the library's entry). Requires Javascript to be enabled.
• 👁 Image
  this library is considered intrusive to your privacy. Details are shown in a popup (with Javascript enabled), or a link will be opened in the same tab (if Javascript is disabled in your browser); alternatively you can tell your browser explicitly to open it in a new tab (usually middle-click or via the right-click menu.
• To not „get lost“ in long lists (some apps integrate 60 libraries or more), those you probably want to take a closer look on are emphasized.

Reproducible Builds

How can you be sure an app was really built from the source indicated? That's where Reproducible Builds come into play. As the IzzyOnDroid repository does not build apps itself, it utilizes verification builders for this, which are based on rbtlog. Results might not be available for all apps or even all releases of an app. To find out if the app you're interested in is covered, scroll down to its „Packages“ section, where you will find a shield icon next to the version information. Hold your mouse over that shield to see what it means. As on touch-screens this „mouse-over“ is hard to achieve, let me outline it here:

• 👁 no RB details yet
  means there are no results available because no verification builder has this app covered yet.
• 👁 RB verification attempted at obfusk
  means at least one verification server attempted to build, but there are no results available yet.
• 👁 RB verified
  means this app was successfully built by at least one verification server and proved to be reproducible. Which verification server confirmed this is part of the title attribute of the link the shield points to. Following the link will bring you to that server and the results of its build.
• 👁 RB verification failed
  means at least one verification server attempted to build, but did not succeed with a reproducible build. This does not necessarily mean the app was „tainted“; the reason could be a simple thing like the dev having built the APK from a different commit. Wherever possible, in such cases we reach out to the corresponding developer(s) to find and fix the cause.

A globe icon on a shield 👁 RB verified by independent builder
indicates an independent builder, i.e. a builder operated by someone not on the IzzyOnDroid team. These are especially valuable: if both, team and external builders, agree on their results, it means they confirmed that our confirmation of the developer's build could be reproduced.

Talking about Javascript: How safe is your site?

There's no such thing as „absolute safety“ or „100% security“, but we did our best also in this regard. No 3rd party sources, especially no Javascript. But don't decide on my word alone, check the following sources which checked this site:

• Webbkoll tells you how privacy-friendly the site is
• so does Blacklight
• SSL Labs tell you about the HTTPS security measures taken (spoiler: as of this writing, it got an A+ rating).
• Mozilla Observatory tells you how secure a site is set up. Spoiler again: as of this writing, we get 110 out of 100 points here, another A+ rating.

Binary Transparency Log

Those logs allow you e.g. to verify that the APK you got from this repo wasn't specifically tailored for you (aka „Bundestrojaner“ or „targeted backdoors“) but indeed was regularly published. This repo publishes its transparency logs via a git repo – a step happening automatically whenever a new index is being deployed. For more details on this, see e.g.:

• F-Droid's short description
• Transparent Logs for Skeptical Clients (an article explaining it in detail)
• Mozilla's description

You can find similar transparency logs in use by the Guardian Project (which also maintains one for F-Droid.org), Debian, and others.

I really like this repo and want to give something back!

👁 Image
You can support us at OpenCollective and Liberapay or find some details here on how to reach us with „goods“ e.g. via SEPA payment or Bitcoin. If you use a mobile wallet (e.g. „Bitcoin Wallet”, which you can find at F-Droid), it's as simple as scanning the QR Code next to this paragraph, enter a value, and send the transaction. Should the image be too small, just click it for a larger one.