Extract the identity fields
The following Android SDK commands work without installing the application:
apkanalyzer manifest application-id app.apk
apkanalyzer manifest version-code app.apk
apkanalyzer manifest version-name app.apk
apkanalyzer manifest min-sdk app.apk
apkanalyzer manifest target-sdk app.apk
Use an explicit path to the SDK's apkanalyzer executable when it is not on your PATH. Keep the output attached to the same file hash or release identifier so results from two builds are not mixed. Command reference.
Interpret each field correctly
applicationId is the installation and Google Play identity. versionCode is the increasing integer used to distinguish releases. versionName is the human-readable label; it is not required to follow semantic versioning, and its lexical order does not control Android updates.
minSdk describes the minimum platform level declared by the build. targetSdk opts the app into platform behavior associated with that target. Neither field is a direct measurement of quality or a complete device-support promise. Native ABI requirements, declared hardware features and distribution settings can still exclude devices.
Do not infer compileSdk from targetSdk
A common metadata error is reporting the target SDK as the compile SDK. They are different build settings. If the inspection method does not reliably expose compile-time metadata, record compileSdk as unavailable and obtain it from the build configuration instead.
Similarly, a label resource may be localized. The visible app name in one resource configuration should not be treated as the only possible name users see. Android versioning.
Build a release-friendly record
A practical record looks like this:
| Field | Example interpretation |
|---|---|
| Application ID | com.example.notes, the installed identity |
| Version code | 42, the build's release number |
| Version name | 2.3, the user-facing label |
| Minimum SDK | Declared platform floor, not a full compatibility test |
| Target SDK | Behavior target requiring version-aware testing |
| Certificate fingerprint | Signing metadata to compare with a trusted record |
The values above are illustrative, not results from an analyzed customer APK.
Resolve mismatches before uploading
If an app's displayed name is correct but its application ID is wrong, rebuilding or uploading more screenshots will not fix the identity mismatch. Check product flavors and applicationIdSuffix. If the version code is reused, create a legitimate new release build rather than renaming the existing file.
APKLint's inspector is useful for a readable overview. When you need authoritative build settings, consult the release configuration; when you need integrity assurance, run a separate signature verification. An “APK info” utility is not necessarily an antivirus or a store-eligibility checker.
Diagnose a flavor mismatch with actual fields
A development team expects com.example.notes, version code 42, version name 2.3. An inspected APK instead reports com.example.notes.staging, code 42 and the same visible version name. The version label does not cancel the different installation identity. Inspect the chosen flavor and any application ID suffix before rebuilding; trying to upload this artifact to the production app entry is the wrong next step.
Write the expected and observed fields side by side. Include the selected build task and the artifact hash. If a CI job published the wrong output, repair the task or artifact-selection step and confirm that the replacement's packaged identity changes. Renaming the staging file to production.apk would leave every relevant manifest value unchanged.
Compare versions using the right field
Human labels such as 2.9 and 2.10 illustrate why ordinary text sorting is a poor release-order test. Your release system should track the actual integer version code and the release lineage, with the display label retained for support conversations. The Android versioning documentation describes the roles of these values. Do not infer a downgrade solely from which display string sorts first.
A useful compatibility record also distinguishes a declared minimum SDK from observed support. For example, if a package declares a platform floor and includes only one native ABI, a device above that floor may still be unable to install it. Capture the ABI inventory and any required hardware features before promising support. An analyzer that reports only SDK numbers has not tested these other constraints.
When different tools disagree, compare the same artifact, field and decoding method. An app label selected for English is not the package ID, and a value shown from a source manifest may differ from the merged release manifest. Preserve the raw packaged value in the record and explain the transformation used for a human-readable display.
Sources and further reading
Reference review: 29 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.
Android inspection tools and practical release guides. About APKLint · Report a correction
