Signature Verification Catches What a Checksum Cannot

A checksum answers integrity: did this file arrive intact and unmodified from whatever was published. A signature answers authenticity: which signing key produced this build. They are not substitutes, and a repackaged APK is exactly the case where the difference decides the outcome.

Consider the failure mode. An attacker takes a legitimate APK, injects an ad or tracker SDK, re-signs it with their own key, and publishes it with a fresh checksum. The checksum matches the file perfectly, because they computed it after modifying the file. Nothing about that comparison protects you. The signing certificate is what differs, and it differs permanently.

Android ties app identity to the pair of package name and signing certificate. An update is only accepted when both match the installed copy. This is why a repackaged build cannot quietly replace a legitimate one: the install fails with a signature mismatch rather than succeeding silently.

That failure is a security control doing its job. The common advice to uninstall the original and install the new file works mechanically, and it also discards the exact protection that just fired. Before doing it, the question worth answering is why the certificate changed at all.

Legitimate certificate changes happen. A developer rotates signing keys, or moves to Play App Signing. Those are announced and documented. An unannounced change on a build from an unfamiliar mirror fits a different pattern.

Android build-tools ship apksigner, which reports the certificate digests for an APK without installing it. Run apksigner verify --print-certs file.apk and read the SHA-256 digest of the signing certificate. Keytool on a JDK gives equivalent output.

The digest is only useful compared against something. For an app you already have installed, compare the new file's signer digest against the installed copy. For a first install, the value tells you which signer to expect on every future update of that app, which is when the comparison starts paying off.

Verify the APK signature scheme version too. Modern builds use v2 or later, which signs the whole archive rather than individual entries. A build presenting only the legacy v1 scheme is either old or has been through tooling that stripped the newer block.

Checksums are often skipped on the reasoning that they are the simplest check. The reasoning is sound, and the conclusion is backwards. A checksum answers whether the file is intact and unmodified since the value was published; a signature answers who built it. Only one of those two questions is about trust, and the trust question is the one the checksum cannot address.

The reason is structural. A checksum is a value the publisher computes and the mirror republishes. Anyone who modifies the file can recompute it afterwards and publish the new value alongside, so a checksum match confirms only that the file matches the number printed next to it — not that the number came from the publisher. A signature cannot be reproduced this way: producing a valid signature requires the developer's private key, which is the entire basis of the scheme.

This is also why a repackaged file often passes a checksum check that a signature comparison would catch immediately. Anyone repackaging an app is already decompiling and rebuilding it, and the rebuild step forces a re-sign — so the certificate differs by construction. Android enforces the same rule when it refuses to update an installed app with a differently-signed build, which means the platform is applying exactly the check this guide recommends whenever you install an update.