APK & App Bundles

Check an APK File: Identity, Integrity and Risk Are Different Questions

To check an APK file properly, separate three questions: what package is this, has its signed content been modified, and does its behavior create unacceptable risk? Metadata inspection, signature verification and security analysis answer different questions. None can safely stand in for the others.

By Updated 2 min read

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:

BASH · REFERENCE EXAMPLE
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:

BASH · REFERENCE EXAMPLE
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

  1. Android Developers: apkanalyzer command-line reference
  2. Android Developers: apksigner
  3. 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.

APKLint

Android inspection tools and practical release guides. About APKLint · Report a correction