Preserve the evidence first
Download from the publisher's intended distribution channel where possible. Record the source URL, retrieval date and a cryptographic file hash in your own release notes. A hash is useful only when compared with a trusted expected value; computing a hash of an unknown download does not make it trustworthy.
Do not install an unfamiliar APK merely to learn its package name. Inspect a copy first, and avoid uploading confidential customer builds to third-party services without permission.
Check identity and compatibility
Use the packaged manifest, not the filename:
apkanalyzer apk summary candidate.apk
apkanalyzer manifest min-sdk candidate.apk
apkanalyzer manifest target-sdk candidate.apk
apkanalyzer manifest permissions candidate.apk
Compare the application ID and version with the publisher or your build record. Review native architectures separately if the app includes native code. A plausible name and icon can be copied, so treat identity strings as claims made by the package. Analyzer reference.
Verify integrity with a signing-aware tool
Run a real signature check:
apksigner verify --verbose --print-certs candidate.apk
Read the exit status and verification output, not just whether certificate details printed. Then compare the signing-certificate fingerprint against a known-good release or a trusted publisher record. A correctly signed malicious app is still malicious; valid signing means the signed material passes the verification rules, not that the signer deserves trust. apksigner.
Review risk signals in context
Unexpected exported components, cleartext network access, embedded secrets, obsolete libraries and unnecessary sensitive permissions deserve investigation. However, a permission declaration is not proof of misuse, and a clean static report cannot observe all runtime behavior.
For your own app, reconcile each finding with the feature owner and test configuration. For an untrusted app, use an isolated analysis environment rather than a personal device with real accounts. Do not grant broad accessibility or administrator access to “see what happens.”
Decide what action the evidence supports
| Finding | Reasonable next step |
|---|---|
| Package or version does not match | Obtain the intended artifact before proceeding |
| Signature verification fails | Stop; investigate corruption, tampering or packaging problems |
| Valid signature, unknown publisher | Seek trusted provenance; validity alone is insufficient |
| Risk signal with an explained purpose | Verify the actual implementation and required safeguards |
| No static findings | Continue relevant runtime and release tests |
APKLint's checker can organize release-readiness findings. Its output should be one part of the worksheet, not a universal “safe APK” verdict. Android's security guidance is the baseline for interpreting the app's design choices.
Sources and further reading
- Android Developers: apkanalyzer command-line reference
- Android Developers: apksigner
- Android Developers: Security best practices
Reference review: 22 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.



