How to Verify an APK Signature Before Installing

Downloading an APK from outside the Play Store is sometimes the right call - for FOSS apps on F-Droid, for beta builds distributed via GitHub Releases, or for apps unavailable in your region. But the moment you bypass the Play Store’s automatic signing checks, verifying the APK signature yourself becomes your responsibility. This guide walks through every practical method, explains what the output actually means, and tells you what to do when something looks wrong.

Why APK Signatures Matter

Every APK published to Android must be signed with a developer certificate before the system will install it. The signature serves two purposes. First, it proves the file was produced by whoever controls the corresponding private key. Second, it acts as a tamper seal: any modification to the APK after signing - even a single byte - invalidates the signature and Android will refuse to install the file.

When you install from the Play Store, Google re-verifies signatures server-side and device-side without your involvement. When you sideload, that verification chain is broken unless you rebuild it manually. A repackaged APK containing injected malware is indistinguishable from the original to the naked eye; only signature verification reveals the difference.

The Android platform currently supports four signing schemes. Understanding them helps you interpret tool output correctly.

Scheme	Introduced	What it signs	Notes
v1 (JAR signing)	Android 1.0	Individual ZIP entries	Vulnerable to zip manipulation (Janus, CVE-2017-13156); legacy
v2	Android 7.0 (API 24)	Entire APK binary	Closes the v1 zip-strip attack; required for Play Store since August 2021
v3	Android 9.0 (API 28)	Entire APK + key rotation block	Supports signing key change with trust continuity; required for new Play apps since 2022
v4	Android 11.0 (API 30)	Merkle tree for incremental install	Requires v2 or v3 to also be present

For any APK you are about to install, you want to see v2 or v3 verified. A v1-only APK should raise your alert level.

Tool Setup: apksigner and keytool

You need two tools. Both are free and do not require a full Android Studio installation.

apksigner ships with Android SDK Build-Tools. If you have Android Studio, it is already on disk at $ANDROID_HOME/build-tools/<version>/apksigner. If not, install only Build-Tools via the SDK command-line tools package from developer.android.com. On Debian/Ubuntu you can also install apksigner directly:

sudo apt install apksigner

keytool is bundled with any JDK. Install OpenJDK if you do not already have it:

# Debian/Ubuntu
sudo apt install default-jdk

# macOS (Homebrew)
brew install openjdk

Verify both are reachable:

apksigner --version
keytool -help

Verifying with apksigner

apksigner verify is the canonical method. It checks the cryptographic integrity of all present signature schemes and tells you which ones passed.

Basic verification:

apksigner verify --verbose path/to/app.apk

A clean result looks like this:

Verifies
Verified using v1 scheme (JAR signing): true
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): true
Number of signers: 1

If Verifies is false, stop. Do not install the file.

Extracting the certificate fingerprint:

Verification tells you the file is internally consistent, but it does not tell you who signed it. For that you need the certificate fingerprint:

apksigner verify --print-certs path/to/app.apk

Example output (Signal APK):

Signer #1 certificate DN: CN=Whisper Systems
Signer #1 certificate SHA-256 digest: 29f34e5f27f211b424c...
Signer #1 certificate SHA-1 digest: ...
Signer #1 certificate MD5 digest: ...

The SHA-256 digest is the value you must compare against the developer’s officially published fingerprint. Signal publishes its fingerprint at signal.org/android/apk/. F-Droid shows the fingerprint on each app’s detail page. If you cannot find an official fingerprint anywhere, treat the APK as untrusted.

Verifying with keytool (Alternative Path)

If apksigner is not available, you can extract the signing certificate manually using unzip and keytool. APKs are ZIP archives; the certificate lives inside META-INF/.

# Extract the signing block
# Filename is CERT.RSA, CERT.DSA, or CERT.EC depending on key algorithm
unzip -p app.apk META-INF/CERT.RSA > cert.der

# Inspect the certificate
keytool -printcert -file cert.der

This gives you the certificate owner, issuer, serial number, validity dates, and fingerprints (MD5, SHA-1, SHA-256). Focus on SHA-256 for comparison. Note that this method only reads the v1 (JAR) signing block; if the APK uses only v2 or v3 signatures, there will be no CERT.RSA file at all. To inspect v2/v3 you still need apksigner.

Checking an Already-Installed App via ADB

If you want to verify the signature of an app that is already installed on a device - perhaps you installed it earlier and want to confirm nothing changed - you can pull the APK over ADB and then run the same checks.

# Find the APK path on device
adb shell pm path com.example.app
# Output: package:/data/app/com.example.app-1/base.apk

# Pull it to your machine
adb pull /data/app/com.example.app-1/base.apk

# Now verify
apksigner verify --print-certs base.apk

For a comprehensive ADB workflow reference, see ADB commands every Android power user should know.

You can also query installed certificate info directly on the device without ADB using a package manager app such as Package Manager (F-Droid), which displays signing hashes per-app. This is useful when you do not have a desktop nearby.

F-Droid and Reproducible Builds: A Stronger Trust Model

For FOSS apps, F-Droid offers a stronger guarantee than raw signature checking. F-Droid builds apps from source and signs them with its own key (displayed on every app page). For apps that support reproducible builds, F-Droid additionally verifies that its own build output matches the developer’s Play Store binary bit-for-bit before publishing - meaning you get both the developer’s code and an independent build attestation.

When using F-Droid:

1. Download the APK from the official F-Droid repository or client.
2. Compare the SHA-256 fingerprint shown on the app’s F-Droid page against apksigner verify --print-certs output.
3. For reproducible-build apps, the fingerprint should also match the Play Store version.

This is meaningfully more trustworthy than verifying a random APK from a file hosting site because you have an independent party (F-Droid’s build infrastructure) attesting to source code correspondence. The F-Droid vs Play Store security comparison covers the full trust model in detail.

Red Flags and What to Do About Them

Not every problem is a binary pass/fail. Here is how to interpret common warning signs:

Verifies: false - The file has been modified after signing or the signature block is corrupt. Do not install. Delete the file and obtain a fresh copy from the official source.

v1-only, no v2 or v3 - Possible on very old APKs (pre-Android 7 targets). Acceptable for truly legacy apps, but for any modern app this is suspicious. A legitimate developer targeting Android 7+ should be signing with v2 at minimum.

Certificate CN is empty or generic - Legitimate developers typically include a recognizable organization name or email in the certificate DN. A certificate with CN=Android Debug, CN=Unknown, or an empty field was almost certainly not produced by a professional release pipeline. This is a strong signal that the APK is a debug build or a repackaged fake.

Fingerprint does not match the published value - This is the most important check. Even if the signature itself verifies, a mismatched fingerprint means the file was signed by someone other than the expected developer. The APK may be a repackaged version containing modifications. Do not install.

Short validity window or already-expired certificate - Not automatically malicious (self-signed certs for sideloaded apps are common), but worth noting. If the certificate expired years before the APK’s supposed release date, something is wrong.

Multiple signers unexpectedly - Most legitimate apps have exactly one signer. Multiple signers are normal only in specific enterprise or OEM scenarios. If you are installing a standard consumer app and see two or more unexpected signers, investigate before proceeding.

If you are unsure whether a result is safe, the right decision is always to wait, seek a second source, or ask in a community like the GrapheneOS forums. The sideloading security guide covers the broader risk surface beyond signatures, including permission review and network behavior monitoring.

Building a Verification Habit

Signature verification takes under 60 seconds once apksigner is installed, but most users never do it because the friction feels high. Reducing that friction makes the habit stick.

Keep a small shell function in your .bashrc or .zshrc:

apk_verify() {
 apksigner verify --verbose --print-certs "$1" 2>&1 | \
 grep -E "Verifies|SHA-256|DN:"
}

Then verifying any download is just:

apk_verify ~/Downloads/signal-universal-release.apk

For regular users who install from F-Droid exclusively, the client handles verification automatically - but knowing how to check manually remains valuable when something behaves unexpectedly or you need to verify a build outside F-Droid’s catalog.

On hardened Android distributions like GrapheneOS, you have the additional option of using the built-in sandboxed Google Play or verifying apps against the Auditor app’s attestation chain. The GrapheneOS vs LineageOS comparison explains how each ROM approaches the verification and trust problem at the OS level.

Signature verification is one layer in a defense-in-depth approach to Android security. It eliminates the risk of installing a tampered binary, but reviewing permissions, using a VPN on untrusted networks, and keeping the OS patched are equally important layers. Treating verification as a mandatory first step - not an optional one - is the baseline for responsible sideloading.

FAQ

Does `apksigner verify` passing mean the APK is safe to install?

Not on its own. A passing verification only confirms that the file has not been altered since it was signed and that the signature block is cryptographically valid. You still need to compare the SHA-256 certificate fingerprint against the developer's officially published value. An attacker can sign a malicious APK with their own key and it will 'verify' fine - the fingerprint check is what catches the substitution.

What file do I extract with keytool if CERT.RSA does not exist in META-INF?

The certificate filename depends on the signing key algorithm. It will be CERT.RSA for RSA keys, CERT.DSA for DSA keys, or CERT.EC for elliptic-curve keys. If none of those are present, the APK may only carry a v2/v3 block with no v1 JAR signature, in which case you need apksigner to inspect it - keytool cannot read v2 or v3 signature blocks at all.

Where do I find the official SHA-256 fingerprint to compare against?

Check the developer's own website first (Signal publishes at signal.org/android/apk/). For F-Droid apps, the fingerprint is shown on the app's detail page in the F-Droid client and on the website. For GitHub Releases, look for a checksums or VERIFICATION file in the release assets. If no fingerprint is published anywhere through an official channel, treat the APK as untrusted regardless of whether the signature validates.

Can I verify an APK on Android without a desktop or ADB?

Yes. Apps like Package Manager (available on F-Droid) can display the signing certificate details and SHA-256 fingerprint for any installed app directly on the device. This is useful when you are away from a desktop. The limitation is that you can only inspect already-installed apps, not an APK file before installation, so you would need to install to a secondary profile or use ADB if you want pre-install verification.