Content policy

A file may be listed on APKBrowse only if we can say who made it and confirm they permitted its distribution. Every specific rule below follows from that one test. If provenance cannot be established, the listing does not happen — regardless of how popular the app is, how many people ask for it, or how obviously harmless it appears.

This makes us less useful than an unfiltered mirror. That is the intended trade. An archive whose contents are unverifiable is not an archive; it is a pile of files with a search box.

Three categories of entry, in descending order of the guarantee we can offer:

Strongest guaranteeOfficial store links

A pointer to Google Play or another first-party storefront. We host nothing and guarantee nothing beyond the link being correct. Always listed first when it exists, because the store's protections beat ours.

We hold the fileVerified publisher builds

An APK uploaded by an account that has demonstrated control of the package name and declared its right to distribute the file. We hold the binary, publish its SHA-256, and check its signing certificate against every prior version of that package.

Link onlyAuthorised mirrors

A link to a third-party host where the publisher's licence permits redistribution — most open-source licences do. We link; we do not proxy the binary. If the licence is unclear, we treat it as unauthorised.

These are removed on sight, without warning, and are not subject to the usual notice period. This list is not exhaustive; the test in section 1 governs.

• Pirated applications.Any paid app distributed without the rights holder's permission, whatever the justification offered.
• Cracked, patched, or modded builds. Anything altered to bypass licence checks, remove advertising, unlock paid features, or defeat DRM. These are also, in practice, the single largest source of Android malware: the modification requires re-signing, which destroys the only certificate chain that could tell you the file is what it claims to be.
• Malware, spyware, and stalkerware. Including apps that hide their icon, monitor another person without their knowledge, or ship a payload downloaded after installation.
• Repackaged apps. A known package re-signed with a different certificate. We block these automatically at upload — see the explanation of signing certificates.
• Packages banned in the jurisdictions we serve, and apps whose primary purpose is unlawful.
• Deceptive listings. Impersonating another developer, misrepresenting what the app does, or padding metadata with terms unrelated to the software.

Every upload must arrive with:

• An ownership declaration — a statement that you hold the rights to distribute this build, or that its licence permits you to.
• Source attribution— where the binary came from. "Found online" is not attribution and will be rejected.
• Accurate metadata — package name, version name and code, and SDK range matching the manifest. We read these from the file; disagreement between your entry and the binary is treated as a signal, not a typo.
• A v2 or v3 signature block. We cannot verify continuity for v1-only or unsigned files, so they enter review flagged as unverifiable and are rarely approved.

We compute the SHA-256 of the file and the fingerprint of its signing certificate on receipt. Both are published on the listing. Neither is supplied by the uploader.

Submissions are reviewed by a human moderator before publication. A moderator can approve, reject with a reason sent to the uploader, or hold a submission for more information. Approval is blocked by the system — not merely discouraged — when a build's signing certificate differs from the one already trusted for that package. A moderator can override that block only by explicitly confirming a verified key rotation, and the override is recorded against their account.

Live listings can be delisted at any time by a moderator, on a user report, or on a rights holder's notice. Delisting removes the app from search, categories, and its own page, and disables every download source immediately. The record and its history are retained so a listing can be restored if the removal turns out to have been wrong.

Every action — approval, rejection, delisting, relisting, override — is written to an append-only audit log with the actor, the reason, and a timestamp. We keep it so that decisions can be reviewed after the fact, including our own.

If your submission was rejected or your app was delisted, you may appeal once per decision. Reply to the notification with the submission or package identifier and the specific reason you believe the decision was wrong — new evidence, not a restatement. Appeals are read by a moderator who was not involved in the original decision.

We aim to answer within five working days. Where the dispute is about ownership rather than policy — you say the app is yours and someone else says otherwise — the app stays delisted while it is resolved. Ambiguity resolves towards not listing.

Copyright complaints follow a separate statutory process. See the DMCA and copyright page.

Uploading pirated, cracked, or malicious software costs upload access on the first offence. There is no strike count for these; the submission proves the intent. For lesser breaches — inaccurate metadata, thin attribution, missing declarations — we warn, then suspend on repetition.

Packages removed for infringement stay blocked from re-publication, including under a different account or a renamed package, until the rights holder tells us otherwise.