How to Verify an Android APK Version When Different Websites Show Conflicting Numbers

You've seen it before: three different websites all say an app is at "v2.1.0" — but the APK files they point to have different sizes, different dates, and sometimes even different package names. Which one is telling the truth?

Here's the uncomfortable answer: repetition is not verification. A version number printed on a webpage is a claim. The metadata inside the APK file is evidence. And checking the evidence takes about ten minutes once you know which fields to read.

This article teaches you the method: which fields actually identify an APK, how to read them, and how to tell when a version number has been copied from somewhere it doesn't belong. I'll use a real-world case study — conflicting version claims around an anime app's APK — to show the method working end to end.

Start With the APK Itself, Not the Webpage

For practical APK identification, three manifest fields are especially important (AndroidManifest.xml). These are the primary identity fields; information on a download page should be treated as a claim until it matches the APK.

• package — the app's unique identity on Android, e.g. com.example.app. Two different package names means two different apps, full stop. Similar names don't count.
• versionName — the human-readable version string shown to users, e.g. 1.2.9. This is just a label; nothing stops anyone from typing any string here.
• versionCode — an integer that Android itself uses to decide which version is newer, e.g. 82. Unlike versionName, this one has to increase for an update to install over an older copy. When a page claims "v1.4.3" but won't tell you the versionCode, that's a red flag — the most machine-meaningful version identifier is being withheld.

You can read all three without installing anything. With Android's build tools:

aapt dump badging app.apk | head -5

Typical output:

package: name='com.tomatos.appclient' versionCode='82' versionName='1.2.9' platformBuildVersionName='14'
sdkVersion:'24'
targetSdkVersion:'34'

That single line already answers the three most important questions: which app is this, what version does it claim to be, and which one does Android consider newer? (Tools like apktool or an online APK analyzer give you the same fields if you prefer not to use the command line.)

Check the Compatibility Metadata

Two more manifest fields tell you what the file expects from a device:

• minSdkVersion — the oldest Android version the app will install on. 24 means Android 7.0+.
• targetSdkVersion / compileSdkVersion — which Android API level the app was built against. Useful context, not identity.

Why does this matter for verification? Because download pages routinely get these wrong. If a page claims an APK "requires Android 4.1+" but the manifest says minSdkVersion 24, the page wasn't written from the file — it was written from someone else's page. Small inconsistencies like this are often the first crack in a copied spec table.

Check the File's Identity: Size and Hashes

Filenames lie. Hashes don't — or at least, they lie far less convincingly.

• Exact file size in bytes. Not "≈ 196 MB" — the precise byte count. Two builds of the "same version" with wildly different sizes deserve an explanation.
• SHA-256. This is the current standard for file identity. If two files have the same SHA-256, they are byte-for-byte identical. If a download page publishes a SHA-256 and your downloaded file matches it, you have the exact file the page is describing. If the page publishes no hash at all, you have no way to confirm that — and that's worth noticing.
• SHA-1. Still useful as corroborating evidence (many APK databases publish SHA-1 checksums), but SHA-256 is the one to rely on.

sha256sum app.apk
# 4e8fde3e314920413f4de682c476b9fbe206e7868dc8538d4dcea9b381270f11

A page that announces a version number but publishes no filename, no hash, and no versionCode is asking you to take the number on faith. Faith is not a verification method.

Check the Signature — Carefully

Every APK is signed. The signing certificate tells you something, but usually less than people assume:

• A certificate issued to a named developer identifies the signer — for that specific signing key.
• A generic debug certificate (e.g. the AOSP test key with CN=Android) identifies nobody. It's the default key the Android build tools ship with. Its presence tells you the app wasn't signed with a production key, and nothing more.

Two things a signature alone never proves: that an APK is safe, and that it is official. Those are separate questions requiring separate evidence (audits, dynamic analysis, provenance chains). Don't let anyone — including me — use signature metadata to make safety claims it can't support.

You can inspect the certificate with:

apksigner verify --print-certs app.apk

Compare Against Independent Sources

Once you have the package name, versionCode, and hashes from the file, cross-check them against independent APK databases (APKPure, APKFab, APKCombo, Uptodown, APKMirror). You're looking for agreement on the identifiers, not the marketing text:

• Does the database list this exact package?
• Does its versionCode sequence make sense (each release higher than the last)?
• Do published hashes match the file you have?
• Do the release dates form a coherent timeline?

And the critical trap: make sure the database entry is for the same package. Databases list apps by package name, and similarly-named apps are routinely conflated. A version 2.0 listed under com.example.appclient says absolutely nothing about the latest version of com.example.app — different package, different app, independent version history. This single mistake accounts for a remarkable amount of version confusion online.

How Version Claims Become "Facts"

Here's the pattern I keep seeing. A version number appears in one database listing — legitimately, for a real app. Then:

1. Copied spec tables. Download sites publish "specification" tables that match each other word for word — including the same package name, which sometimes doesn't even match the app the page is about. One page I examined kept "v1.2.8" in its title while its copied table said "v1.4.3."
2. Shared changelogs. Multiple sites publish an identical "What's new in vX.Y" list, sometimes including features (like "augmented reality") that trace back to ancient promotional copy. None of them publish build evidence alongside it.
3. Divergent filler. The sites agree on the version token but disagree on everything else: file sizes ranging from 13 MB to 198 MB, Android requirements from 4.1 to 8.0, dates from "1 day ago" to months in the future. Shared number + divergent facts = shared rumor, not independent verification.
4. Zero artifacts. Not one of the pages making the claim publishes a filename, a hash, a versionCode, or a build screenshot. Exact-filename searches return nothing.

None of this proves anyone acted in bad faith — copying is often just how low-effort content gets made. But it does prove something important: ten pages repeating a number is one claim repeated ten times, not ten independent confirmations. Only the artifact — package, versionCode, hash — can confirm it.

Case Study: Conflicting Tomato Animes Version Claims

Update — October 2026: The APK originally analyzed in this case study has been superseded. A fresh verification of the file currently distributed through the GitHub V1.4.3 release found versionName 1.4.3, versionCode 99, package com.tomatos.clientapp, 203,631,246 bytes (≈196 MB), SHA-256 96262e44e0f19fb609a3214adc71d13b2ea9864735980e7da10bde9c428801ab. The historical file (com.tomatos.appclient, 1.2.9/vc82) and the current file are different packages and different binaries. The full side-by-side evidence is documented in the updated Tomato Animes APK verification case study. The verification method taught in this article is unchanged — and it is the same method that caught the change.

Evidence labels used below: **VERIFIED FACT* = extracted directly from the analyzed artifact or a primary source. OBSERVED = found in a survey of pages/databases (October 2026). THIRD-PARTY CLAIM = published by other sites, recorded as a claim, not proof. HYPOTHESIS = best-fit interpretation, not established fact.*

VERIFIED FACT (historical artifact): The APK analyzed in October 2026 — a file that has since been superseded — contained versionName 1.2.9 and versionCode 82 under the package com.tomatos.appclient (196,506,659 bytes; minSdkVersion 24; SHA-256 4e8fde3e314920413f4de682c476b9fbe206e7868dc8538d4dcea9b381270f11). Its SHA-1 was identical to the hash APKFab published for version 1.2.9. The signing certificate was the generic AOSP debug key (CN=Android) — it identifies no developer and attests nothing about safety.

VERIFIED FACT (current artifact): A fresh verification of the currently distributed file (GitHub release V1.4.3, October 2026) found versionName 1.4.3, versionCode 99, package com.tomatos.clientapp, 203,631,246 bytes (≈196 MB), SHA-256 96262e44e0f19fb609a3214adc71d13b2ea9864735980e7da10bde9c428801ab. The two files are different binaries, different packages, and different signatures — for Android, two different apps.

OBSERVED: Three independent APK databases (APKPure, Uptodown, APKCombo) list version 1.4.3 under the package com.tomatos.clientapp ("Tomato - A&M"), versionCode 99, dated February 3, 2025 — and that identity triple is now independently corroborated by the currently distributed file's own metadata. The same databases show the com.tomatos.appclient release line ending at 1.2.9.

THIRD-PARTY CLAIM: Multiple download sites label the com.tomatos.appclient app as "v1.4.3" — without publishing filenames, hashes, versionCodes, or build evidence.

HYPOTHESIS (rebuilt): The most parsimonious reading is that the distributed file changed packages between the historical and current artifacts — and the databases' com.tomatos.clientapp / 1.4.3 / vc99 identity, once only observed, is now corroborated by the distributed file itself. Why the package changed has not been established and is not asserted here.

Notice what the method gives you here: not an accusation, just evidence. The number "1.4.3" turned out to be real — and re-running the checklist on the current file is what revealed the package change the old conclusion had missed. That is the method working as designed: verify the file, not the headline.

The complete methodology, evidence tables, and source map are documented in the full Tomato Animes APK verification case study.

Disclosure: the Tomato Animes investigation used as this article's case study was published by tomateanimes.com, a site I contribute to. It's cited here as a worked example of the verification method — the method itself stands on its own with any APK.

A Practical APK Verification Checklist

Before trusting any APK version claim, run these ten checks:

1. Package name — does the file's package match the app you're looking for? Similar names don't count.
2. versionName — does the in-file version string match what the page advertises?
3. versionCode — is the internal version number present and coherent with the claimed release?
4. File size — does the exact byte count roughly match what's advertised? Large divergences need explanations.
5. SHA-256 — compute it; compare against any published hash. Equal hashes mean byte-identical files.
6. Signature — inspect the signing certificate. A generic debug key identifies no developer and proves nothing about safety.
7. Source quality — prefer channels that publish technical data (hashes, versionCodes); distrust pages that publish only claims.
8. Permissions — at install time, check that requested permissions make sense for what the app claims to do.
9. Independent analysis — run the file through a multi-engine scanner before installing.
10. The coherence test — the final question: does the versionName inside the file equal the number on the page? If not, something is wrong — regardless of what the page says.

Final Takeaway

A version number on a webpage is cheap to copy. Package identity, versionCode, cryptographic hashes, and signatures are not — they require the actual file. When websites disagree, don't count the votes. Read the artifact.

Verify the file, not the headline.