APK Verification Policy

What should be recorded whenever an APK is checked.

APK Verification Policy

When this site publishes a verification result for an APK, the result should be tied to one exact file. Repeating the same green badge across multiple versions without checking each file would make the result meaningless.

Record for Each Checked File

  • File name and byte size.
  • Version and Android package identifier.
  • SHA-256 checksum.
  • Signing certificate or signer details when available.
  • Source from which the file was obtained.
  • Date of the check.
  • Malware-scan result and the scanner used.
  • Android version/device or test environment when installation is tested.
  • Any Play Protect, installer or permission warnings observed.

What We Do Not Claim

A matching checksum proves identity, not safety. A multi-engine scan can miss unknown or behavior-triggered threats. A successful installation proves compatibility on that test environment, not every Android phone. Verification results should state those limits instead of hiding them.

MOD Files Need Their Own Checks

The HappyMod installer can be checked independently, but that result does not validate MODs downloaded later through the app. Each individual package can have a different uploader, signer, hash and risk profile.

A Verification Record Can Become Outdated

If a download host replaces a file while keeping the same visible version number, an older checksum no longer identifies the new file. Verification therefore needs both a checksum and the date/source of the check. When a file changes, the old record should remain historical rather than being silently reused for the replacement.

Warnings Are Part of the Record

If Android, Play Protect or a malware scanner displays a warning, the warning should be recorded rather than hidden because it makes the download look less reassuring. A verification page is useful only when it includes inconvenient evidence as well as successful checks.

Retention of Verification Records

Older verification records can remain useful when they clearly identify the historical file and date checked. They should not be overwritten to make an older test look current. Keeping the previous hash and signer record can also help explain why Android accepts one update path and rejects another.