APPEAL TICKET · EVIDENCE PACK

How to submit an APK false-positive appeal

A useful false-positive appeal is not a statement that “my application has no virus.” It is verifiable release evidence: the exact file, signing identity, product and rule version, complete label, reproduction procedure, differences from a control, and the engineering reason the associated behavior is legitimate. Precise evidence helps a vendor route the ticket to the correct analysis process.

Upload an APK to build evidenceUpdated August 18, 2026

Use this guide when

A stable release candidate consistently detected by one or a small number of products
Teams with a same-source control, signing evidence, and real-device regression results
Release owners explaining sample behavior to a device vendor, security product, or app store
Organizations that need a closed loop across ticket ID, rule update, and unchanged-sample retest

Do not use it for

Applications with unexplained dynamic behavior, excessive permissions, or untrusted SDKs still under investigation
Requests for every vendor to remove unrelated labels without product-specific evidence
Tickets containing signing keys, passwords, user data, or irrelevant production logs

01 / READINESS

Prove that the sample is ready for false-positive review

Preserve the warned APK, calculate its SHA-256, verify the signing-certificate SHA-256, and confirm package name, versionName, and versionCode against release records. Complete clean installation, upgrade from the prior production version, first launch, and critical product regression.

Review sensitive permissions, third-party SDKs, dynamic code, network endpoints, and behavior related to the detection label. If a genuine issue exists or a feature cannot be explained, remediate it and establish a new baseline. An appeal is not a shortcut around security review.

01Freeze the original APK; do not repackage it before submission
02Confirm code review, dependency provenance, and permission necessity
03Validate signing, clean installation, upgrade, and critical functions
04Reproduce the warning in a recorded environment
05Locate the detecting vendor’s official sample or false-positive channel

02 / EVIDENCE

Give the analyst enough information to identify and reproduce one sample

Identity fields include application name, package name, version, APK SHA-256, certificate SHA-256, file size, build time, and official download location. Detection evidence includes product and component version, complete family or label, screenshot, and first and most recent observation times.

The technical explanation should briefly describe the application, the legitimate feature that may correspond to the label, permission rationale, and dependency provenance. Include device and Android versions, download and installation steps, and the result for a same-source unhardened control or previous stable release.

Do not rely on a filename; it does not uniquely identify a sample
Do not replace behavior evidence with “all other engines are clean”
Do not attach unrelated user, payment, or server logs
Never submit a keystore, private key, password, or access token

03 / TICKET

A short, complete case is better than an unstructured screenshot collection

Use a title such as “False positive review request” followed by package, version, and label. List sample identity first, then environment and reproduction steps, explain the application and relevant legitimate behavior, and close with control, code-review, signing, and installation results.

When the submission portal accepts samples, review its confidentiality and retention terms. Ask for a private transfer method when a commercial unreleased package cannot be shared publicly. Identify every attachment by hash so the analyst never receives several different files with the same name.

Ticket section	Required evidence	Common failure
Sample identity	Package, version, APK and certificate SHA-256	Filename or generic storage link only
Detection incident	Product version, label, time, device, screenshot	Only “detected as virus”
Legitimate behavior	Rationale for permissions, SDKs, network, or protection	Unsupported claim of absolute safety
Reproduction and control	Delivery path, steps, and control difference	Rebuilding before submission changes the hash

04 / TRACK

Maintain a separate timeline for every vendor

Record vendor, official channel, ticket number, submission time, sample hash, replies, rule-update time, and stated scope. Products do not share one universal rule database. A correction by one provider does not demonstrate that any other provider has changed.

Reference the existing ticket when following up instead of opening many duplicates. If more information is requested, provide the minimum relevant data and repeat the privacy check. The release owner should decide whether the candidate is paused, staged, or continued while analysis is pending.

01Register the ticket number and submitted hash
02Version every supplemental evidence package
03Record the vendor’s stated rule publication time
04Retest the original sample in the same environment
05Archive the recovery result in the release evidence sheet

05 / RETEST

Use unchanged bytes to confirm that a rule actually changed

After a vendor reports completion, retest the original APK with its original hash. A freshly rebuilt file cannot distinguish a vendor correction from an artifact change. Record time, product version, cloud connectivity, and screenshots for the retest.

Ticket closure is not a permanent guarantee. Archive the result with the release version, and establish a new baseline when dependencies, signing, hardening configuration, or core behavior changes materially. If the warning returns, use the existing case and evidence to document the regression timeline.

QUESTIONS

Confirm the boundary before acting

Where should an appeal be submitted?

Submit to the device vendor, security product, or store that actually produced the label. A multi-engine portal may display results, but the underlying vendor controls its rule.

Does an appeal require source code?

Begin with the minimum evidence package. Additional private material depends on vendor process and should be shared only under reviewed confidentiality terms and organizational authorization.

Can I submit a newly resigned package?

Prioritize the exact warned sample. Resigning changes the file hash and identity signals and cannot demonstrate that the original sample was corrected.

How long does review take?

Timelines and rule-publication cycles vary by vendor, so no fixed duration can be promised. Track the case number and stated release time when managing launch risk.

Why does a warning remain after the vendor says it is fixed?

Device caches, component versions, cloud synchronization, or a changed test file may be involved. Confirm the original hash, connectivity, product version, and effective time.

RELATED GUIDES

Continue the release evidence chain

All guides

APK-VIRUS-WARNING-CAUSES

Create a verifiable protected candidate first

Upload the frozen sample and retain a control. Sign the unsigned output with your own material and complete regression before deciding to appeal.

Upload an APK to build evidence