Search the hash before uploading
Compute the APK's SHA-256 locally and search for an existing report first. This can avoid submitting a confidential build merely to discover that the exact file was already analyzed. Do not use a report for a different version or similarly named package as evidence about your file.
sha256sum app-release.apk
Record the full hash and analysis timestamp in your review. If the report is old, engine definitions and the surrounding intelligence may have changed; a current result still is not a safety guarantee.
Read detections by meaning
Review which engines flagged the sample, their labels, the file's signing identity and any behavioral or relationship information available. Engine labels differ and are not independent scientific measurements. One specific, well-supported finding can matter more than several vague labels; a false positive is also possible.
Write an evidence statement such as “engine X reports category Y for hash Z; the cause remains unconfirmed,” rather than “three engines prove it is a virus.” That wording keeps a preliminary signal separate from a conclusion.
Understand the sharing model
VirusTotal's own description states that reports are shared with its community and submitted file content may be shared with qualified customers and partners. Do not upload internal builds, unreleased product code or customer data without permission and an appropriate handling agreement.
An API key does not by itself make a public submission private. Check the actual service and contract being used.
Investigate a possible false positive
For your own release, retain the reproducible build, signing information, dependency changes and the smallest safe sample demonstrating the issue. Contact the detecting provider through its published process. Do not remove genuine protections or repeatedly rename the package to evade a detection.
Complement the report
APKLint can help inspect manifest flags, permissions and embedded SDK indicators. Compare those observations with the VirusTotal report and the intended app behavior. Neither tool can establish the complete behavior of a server-controlled feature or prove that a third-party application's future updates will remain safe.
Anchor every observation to the report's hash and time
Suppose a support ticket links a report while the developer has since rebuilt the application. Compare the local SHA-256 with the report before discussing detections. A rebuild can change bytes even when the version label remains the same. Save the report time as well, because a later analysis of the same file can contain updated engine results.
The report guide explains the result views and their fields. Distinguish the number of detecting engines from community reputation and from behavioral observations. These are different kinds of information and should remain separate in an engineering issue.
Investigate an unexpected detection in your own release
Compare the affected artifact with a retained earlier release. Review dependency changes, native binaries, packaging transformations and generated configuration. Keep the change list small enough to form a testable hypothesis. A new detection after a large unrelated refactor does not identify which change caused it.
If the evidence suggests a false positive, prepare a concise report for the detecting vendor using its published process. Include the exact hash, label, product ownership context and a safe explanation of the relevant build change. Avoid putting private source or customer data into a public comment merely to accelerate the investigation.
Review submission permissions before uploading another file. The public service description explains sharing, while private scanning is a distinct service with its own terms. Having an API key or being signed in does not by itself establish that an upload is private.
Do not infer that a changed score proves a code repair. The result can change because an engine updated its classification or a scan completed differently. Record whether the artifact hash changed and what independent evidence supports the underlying issue's resolution.
For a release decision, combine the report with provenance, signing identity, dependency review and relevant controlled behavior tests. Keep an unresolved detection visible until it is explained. Equally, avoid presenting a vendor label as a confirmed malicious action when the available evidence only establishes that the vendor classified the file that way.
Sources and further reading
- VirusTotal: How it works
- VirusTotal sharing and submission model
- OWASP: Mobile Application Security Testing Guide
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
