RELEASE DIAGNOSTIC · FALSE-POSITIVE WORKFLOW
False-positive reduction is not the removal of one suspicious string or a sequence of random rebuilds. It is control of release variables: identify the exact sample, review genuine behavior, create an unhardened same-source control, isolate signing, permissions, dependencies, and protection changes, and then retest or appeal with the specific detecting product. This workflow can reveal a mistaken label without misrepresenting a real risk as a false positive.
01 / BASELINE
Preserve the candidate APK, source revision, build parameters, dependency lock, and hardening configuration. Calculate APK SHA-256 and signing-certificate SHA-256, and record package name, versionCode, build time, channel, and download source. Archive the original, unhardened control, and protected candidates separately.
Before scanning, verify archive integrity, expected signing, clean installation, upgrade installation, startup, and critical flows. A failed baseline is a build or release problem that should be corrected first; otherwise later detection differences cannot be interpreted reliably.
02 / REVIEW
Check whether sensitive permissions are necessary, third-party SDKs come from trusted sources, dynamic downloads are server-authorized, network endpoints belong to the product, and debug residue, test keys, or unfamiliar native libraries are absent. Map the detection label to actual behavior and product requirements.
Upgrade, replace, or remove dependencies with unclear provenance, unnecessary permissions, and SDK behavior the team cannot explain. Hardening raises analysis cost; it does not repair unsafe product design and cannot make malicious behavior legitimate.
03 / ISOLATE
When the unhardened control is stable but the protected candidate warns, return to the minimum profile. Enable DEX, strings and resources, native, anti-debug, and runtime checks in separate groups. After every change, repeat signing, installation, functional, and detection validation.
If both artifacts warn, return to source, dependencies, permissions, certificate, and provenance. If only a channel or device differs, keep the APK hash fixed while comparing security-component version, source reputation, transport, and whether the delivered file was modified or resigned.
| Result | Primary variable | Next step |
|---|---|---|
| Both artifacts warn | Behavior, dependency, permission, signing, provenance | Security review and smaller controls |
| Only protected artifact warns | Protection group and packaging delta | Roll back and enable groups individually |
| Only certificate change alters result | Certificate history and upgrade identity | Audit signing; do not rotate randomly |
| Only channel result differs | Delivered artifact and channel rule | Compare hashes and final certificate |
04 / VALIDATE
Sign every candidate with application-owner material and test clean installation, upgrade from the previous release, authentication, networking, payments, push, background tasks, and critical native flows. Observe startup time, crashes, ANRs, and package-size changes.
For external scanning, record engine, label, timestamp, and exact file hash rather than using detection count as the only metric. Review retention and sharing policies before uploading a confidential unreleased package. These public pages do not provide an online VirusTotal service.
05 / RELEASE
When a candidate is stable and the warning is resolved, retain the minimum change that produced the evidence. Avoid combining unrelated dependency, signing, and product changes. Store the artifact hash, configuration, test matrix, and detection results with the release record.
If behavior is legitimate and the warning remains vendor-specific, submit the original hash, certificate, label, reproduction steps, and control result. Retest unchanged bytes after the vendor update. Run the gate again whenever dependencies, signing, core behavior, or protection configuration changes materially.
QUESTIONS
No. Rules and reputation change. The workflow rules out genuine risk, isolates variables, and produces reproducible evidence; it cannot permanently guarantee every future product result.
It separates source and dependency behavior from the protection-layer change. Without a same-source control, simultaneous changes are easily attributed to the wrong cause.
That approach is not explainable or reproducible and can break signing, upgrades, behavior, and review. It also leaves genuine security issues unresolved.
The artifact still needs owner-controlled signing and installation, upgrade, critical-flow, permission, privacy, and channel validation.
When sample identity is fixed, behavior review passes, the warning is reproducible, the variable is isolated, and further changes only add compatibility risk.
RELATED GUIDES
Use five signal classes to select the correct investigation layer.
APK-SIGNATURE-FALSE-POSITIVERule out shared certificates, broken continuity, and channel resigning.
APK-FALSE-POSITIVE-APPEAL-GUIDETurn baselines, hashes, and control results into a traceable ticket.
NEXT ACTION
Upload a security-reviewed APK, then sign the unsigned result with your own certificate and complete device and product regression.