Checking who signed an APK, the practical way
Every Android app is signed with a developer's private key, and Android records that key when the app is installed. From then on, only builds signed with the same key can update it. That mechanism gives you a verification method that requires no tools at all, and it answers the practical question better than reading a certificate fingerprint would.
The check that works on a phone
Install the app once from a source you trust. From then on, any file that installs over it cleanly was signed with the same key, and any file that Android refuses was not. That is a cryptographic comparison performed by the operating system, and it needs nothing from you but attention to whether the install succeeded.
- Establish the reference install From the Play Store, the developer's own site, or a source you have decided to trust.
- Take later builds from anywhere Try to install as an update, never uninstall first.
- Read the outcome It installed: same key, same publisher. It refused: different key, and worth understanding why before going further.
- Do not uninstall to force it That discards the reference and the check with it. Uninstalling is how people talk themselves past the warning.
โฆษณา
When you want the actual fingerprint
For a stronger check, the signing certificate's SHA-256 fingerprint can be compared against one the developer publishes. Open source projects often do publish theirs, and it is the right check when you are installing something for the first time with no reference copy.
| Where to compare against | How reliable |
|---|---|
| The developer's own site over HTTPS | Good |
| The project's release notes or repository | Good |
| A forum post | Not a source |
| The download page you got the file from | Only as trustworthy as that page |
The weakness of the fingerprint approach is circular trust: a fingerprint published on the same page as the file proves only that the page is internally consistent. It has to come from somewhere you already trust for the check to mean anything.
Why the same app can have two keys
Google Play re-signs uploads with a key Google holds, so the Play build and the developer's own build of the same version are signed differently. Both are genuine. Neither will install over the other.
- Play build versus the developer's own site
- A regional or carrier variant
- A separate build for a different store
- The developer announced a key rotation
- A copy of a mainstream app from an unfamiliar site
- A build promising unlocked paid features
- Anything where the source cannot say why
Keep a copy of what you trust
Once you have an app installed from a source you trust, the APK on the device can be extracted and kept. That archived file is a reference: it is known good, it is the right key, and it will still install years later when the current version has dropped support for your phone.
For anything important, that archive is worth more than any verification procedure, because it removes the need to verify a new file at all.
Install once from a trusted source and never uninstall to force a later file. That habit is the whole verification method.
Frequently asked questions
Can I see the signature on the phone?
Not in system settings. Some file managers and app-info tools show the certificate fingerprint, and the install-over test needs none of them.
Does a valid signature mean the app is safe?
No. It means the file came from whoever holds that key. Whether you trust them is a separate question.
What if I have no reference copy?
Then compare the published fingerprint from a source you already trust, and be more careful about permissions on first launch.
Read next
This is not a rivalry. Each does something the other cannot.
You are not buying encryption. You are buying an operator whose income does not depend on you.
For a plain ZIP either works. For a split, password-protected archive, only one does.
