apkeep: APK downloads from 3 sources, with authentication and signature verification

3 sources, 3 distinct permission models

apkeep downloads APK files from 3 sources: Google Play, F-Droid and APKPure. The command-line flag `-d` selects the source; without it, Google Play is the default.

Google Play downloads require authentication via credentials documented in USAGE-google-play.md. No paid or DRM-protected app is reachable through this route. F-Droid is a repository of free and open-source Android apps; no authentication token is needed to download from it. Before apkeep writes any F-Droid download to disk, it runs the file through a signature check against F-Droid's maintainer keys. APKPure is listed as a third-party download source alongside the other 2 sources; the README says it should only be used for research and points to USAGE-apkpure.md for further guidance.

All 3 sources share the same command-line structure, but the obligations they carry differ sharply. Picking the wrong source for a task means either an authentication failure or a possible terms of service problem. The choice deserves a deliberate read before any bulk run.

The simplest example in the README skips a required authentication step

The Examples section of the README opens with this command, called the simplest case:

apkeep -a com.instagram.android .

No source flag is given, so the default is Google Play. A paragraph directly after states: "To download directly from the default source, Google Play, you will first have to obtain an AAS token." Those two examples contradict each other. Running the first command without a token will not produce a downloaded APK, because Google Play authentication is required for every download from that source.

Authentication requires this form:

apkeep -a com.instagram.android -e '[email protected]' -t aas_token .

Both an email address and an AAS token are required for Google Play. USAGE-google-play.md in the repository documents how to obtain that token, but the README body does not reproduce those steps.

4 install paths: cargo, precompiled binaries, Termux and Docker

apkeep is published on crates.io under the same name. With Rust installed, the install command is:

cargo install apkeep

To install from the latest commit rather than the published version:

cargo install --git https://github.com/EFForg/apkeep.git

Precompiled binaries for each platform can be downloaded from the repository's Releases page. Version 1.1.0 was released on 2026-10-01.

On Android with Termux, the README gives 2 paths: install a precompiled binary from the repository, or run `pkg install apkeep` from the Termux package repository after upgrading packages with `pkg update`.

Docker images are in the GitHub Container Registry at `ghcr.io/efforg/apkeep`. 3 floating tags are available: `stable`, `latest` and `edge`. The README marks `stable` as the recommended choice. To download a single APK to a local directory:

docker run --rm -v output_path:/output ghcr.io/efforg/apkeep:stable -a com.instagram.android /output

The `-v output_path:/output` mounts a host directory at `/output` inside the container, where the APK is written.

F-Droid downloads verify APK signatures against F-Droid's signing keys

When the F-Droid source is selected, apkeep checks each downloaded file against the signing keys of F-Droid's maintainers. A file that fails this check triggers an alert. apkeep does not silently accept an unverified download, which matters because F-Droid produces its own builds and signs them with its own keys rather than passing through Play Store packages.

The cryptographic stack for this verification is visible in Cargo.toml: `cryptographic-message-syntax = "0.28"` handles CMS signature parsing, `ring = "0.17"` is the underlying cryptographic library, `x509-certificate = "0.25"` covers certificate handling, and `tokio-dl-stream-to-disk = { version = "1", features = ["sha256sum"] }` adds SHA-256 verification during the download stream itself. Both `sha1 = "0.11"` and `sha2 = "0.11"` appear as dependencies.

For F-Droid mirrors and other F-Droid-compatible repositories, USAGE-fdroid.md in the repository documents download options that the README body does not list.

APKPure carries a research-only restriction with no defined scope

The README says APKPure should be used only for research purposes. What counts as research is not defined, who enforces that boundary is not stated, and what consequences follow from other use is not addressed. APKPure is described as a third-party site that hosts APKs available on the Play Store.

That gap matters for anyone who wants to rely on this source in any sustained or automated way. The word only is emphatic but the README offers no boundary conditions. Anyone using APKPure for anything beyond occasional analysis downloads should read APKPure's own terms of service, since apkeep's documentation does not define the constraint further.

Version pinning with the @version suffix is limited to F-Droid and APKPure

apkeep accepts a version suffix using the `@version` convention. To request a specific version:

apkeep -a [email protected] .

The README specifies that version pinning is possible for APKPure or F-Droid. Google Play is not listed as a source that supports it. Researchers who need a historical APK from the Play Store cannot use this mechanism.

To see which versions are available before specifying one:

apkeep -l -a org.mozilla.fennec_fdroid -d f-droid

The `-l` flag requests a version listing rather than a download. This flag is shown in the F-Droid example only; its availability for APKPure is not spelled out in the README body.

Batch downloads read a CSV file with an optional column selector

Instead of a single app ID, apkeep accepts a CSV file that lists the apps to download. When the app ID is not in the first column of the CSV, the `--field` option specifies which column to use. A file with 1 app ID per line works as a CSV with a single field and needs no `--field` argument.

The README points to the USAGE file at the repository root for complete instructions on downloading multiple APKs in a single run. That file is in the repository but is not reproduced in the README. Anyone planning a bulk job that combines CSV inputs with source-specific flags should read USAGE directly.

Google account termination and parallel fetch limits are documented obligations

Account termination by Google is named as a real risk: their Terms of Service govern what automated access is allowed, and the README asks users to verify those terms and accept the possibility of account loss before running any Google Play downloads. Paid and DRM-protected apps are also out of reach through this route, regardless of the account used.

Batch size and fetch parallelism carry an obligation the README names explicitly. Downloading too many apps at once or running too many requests in parallel can strain the distributor's infrastructure. No specific number is given for what too many means; the user is expected to keep demand proportionate.

Tor use adds another failure mode. The README notes that Tor substantially raises the chance of a failed download when Google Play is the source. Neither a retry count nor a fallback path is documented for Tor-routed connections.

Editorial conclusion

apkeep suits researchers and security analysts who need APK files for static analysis without a physical Android device. F-Droid is the cleanest path: no account risk, signature verification, and version pinning. Google Play requires an AAS token and puts the account at risk; paid and DRM apps are unavailable. APKPure is restricted to research use with no defined scope. Before adopting for bulk work, read USAGE-google-play.md for the full token procedure, read APKPure's own terms, and test with a public F-Droid app first.

Frequently asked questions

Official sources

1. EFForg/apkeep on GitHub
2. Issues
3. License: MIT
4. README
5. Releases