Skip to content

False Positives Play Protect

Jump to bottom
Emirhan Uçan edited this page Aug 5, 2026 · 6 revisions

False Positives & Play Protect Warnings

Why Antivirus Apps and Google Play Protect May Flag HydraDragonAV Mobile

HydraDragonAV Mobile requests several sensitive permissions that are required for its security functionality. These same permissions are commonly abused by actual malware, so antivirus engines and Google Play Protect may flag the app as potentially harmful — even though every permission serves a legitimate security purpose.

This does not mean the app is malware. You can verify the app's integrity by building from source (see INSTALL.md or Installation-Setup) and comparing the APK signature.

Permissions That May Trigger Warnings

ACCESSIBILITY_SERVICE

Aspect Details
Why we request it Powering the Dynamic Analysis Engine — runtime behavioral detection for clickjacking, overlay spam, StrandHogg attacks, notification floods, and automated UI manipulation that no static scanner can detect. Also used by the Removal Resistance Guard to catch device-admin screen dismissal patterns.
Why it looks suspicious Malware frequently abuses AccessibilityService to grant itself additional permissions, read screen content (banking trojans), and perform automated clicks without user consent.
What we do differently We never read credentials, never automate clicks outside our own UI, and never exfiltrate screen data. The service is purely a behavioral monitor — it observes UI interaction patterns to detect malicious activity. All detection runs on-device with no cloud transmission.

RECEIVE_SMS

Aspect Details
Why we request it Detecting SMS-based phishing (smishing), premium-rate SMS trojans (e.g. Android.SmsSend family), and malicious URL delivery via text message. Incoming SMS are scanned for embedded malicious URLs and known scam patterns.
Why it looks suspicious SMS permissions are a classic malware vector — malicious apps use them to intercept 2FA codes, subscribe to premium-rate services without user knowledge, and read private conversations.
What we do differently SMS scanning is opt-in (disabled by default, must be enabled in Settings > SMS Scan). We never block or modify SMS messages — detection is read-only. No SMS content is ever transmitted off-device.

QUERY_ALL_PACKAGES

Aspect Details
Why we request it Full-device malware scanning requires enumerating all installed packages — without this permission, the scanner can only see a subset of apps, creating a blind spot for threats that hide their presence.
Why it looks suspicious Rarely needed by legitimate apps; commonly used by malware to enumerate installed security software or find high-value targets (banking apps).
What we do differently Package queries are performed only during active scans (user-initiated or scheduled), never passively in the background. The results are used exclusively for signature matching and whitelist checks — no analytics, no tracking.

SYSTEM_ALERT_WINDOW

Aspect Details
Why we request it Required for emergency threat alerts that must appear above other apps (e.g., root-exploit attempts, ransomware behavior detected in real time). Standard notifications can be ignored or suppressed by malware.
Why it looks suspicious Tapjacking and overlay attacks commonly abuse this permission to draw invisible windows over legitimate apps and intercept user input.
What we do differently Overlay windows are shown only when a verified security threat requires immediate user attention. The app's own UI has setFilterTouchesWhenObscured(true) on every interactive element as a defense against overlay-based tapjacking.

FOREGROUND_SERVICE + FOREGROUND_SERVICE_SPECIAL_USE

Aspect Details
Why we request it Real-time protection requires a persistent background service — the GuardService monitors file system changes, running processes, network connections, and behavioral signals around the clock. Android 14+ requires explicit foreground service type declarations.
Why it looks suspicious Persistent background services drain battery and are a hallmark of both legitimate security software and persistent malware (stalkerware, spyware).
What we do differently The foreground service shows a persistent notification so the user always knows it's running. Protection can be paused at any time from Settings. The service stops when the user disables real-time protection.

MANAGE_EXTERNAL_STORAGE

Aspect Details
Why we request it Required on Android 11+ to scan files across all storage locations (internal storage, Downloads, Documents, etc.) — without it, the scanner can only access app-specific directories, missing malware that may be distributed as APK files in shared storage.
Why it looks suspicious Broad file system access is a hallmark of file-infector malware and data-theft trojans.
What we do differently Storage access is used exclusively for scanning — the app reads files to pass them through the detection engines (YARA-X, ClamAV, ML). No file content is ever modified, copied, or transmitted.

KILL_BACKGROUND_PROCESSES

Aspect Details
Why we request it Used prior to uninstalling a confirmed threat to request the OS trim background cached tasks of the malicious package, preventing background receivers from respawning during uninstall dialogs.
Why it looks suspicious Malware may attempt to terminate security tools or competing malware.
What we do differently Regular Android apps cannot force-kill arbitrary active processes. To stop malicious foreground overlays or ransomware windows, HydraDragonAV Mobile dismisses the app screen via the Accessibility Service (GLOBAL_ACTION_BACK) rather than force-killing OS processes. Process trim calls only happen during user-initiated threat uninstallation.

REQUEST_DELETE_PACKAGES

Aspect Details
Why we request it The final step in threat removal — after scanning and confirming a malicious app, the user can uninstall it directly from the HydraDragonAV interface without navigating to system settings.
Why it looks suspicious Malware uses this to silently remove competing malware or security apps.
What we do differently Uninstall is always user-initiated — the app merely opens the system uninstall confirmation dialog. No packages are removed without explicit user action.

BIND_ACCESSIBILITY_SERVICE

Aspect Details
Why we request it Required by Android to declare the DynamicAnalysisService as a system Accessibility Service.
Why it looks suspicious Same as ACCESSIBILITY_SERVICE — this is the manifest declaration that enables accessibility monitoring.
What we do differently The service's configuration (accessibility_service_config.xml) explicitly sets canRetrieveWindowContent="true" only for the behavioral detection use case, and accessibilityEventTypes are filtered to UI interaction events only — not text content for credential harvesting.

Google Play Protect Warnings

Google Play Protect may show warnings such as:

  • "Play Protect doesn't recognize this app's developer" — This is normal for apps not distributed through the Google Play Store. It does not indicate malware.
  • "App may be harmful" — Triggered by the permissions listed above. Google's automated systems flag apps that request sensitive permissions, especially when not widely installed through Play Store.
  • "Unknown sources" warning — Any APK installed outside the Play Store triggers this. It's a platform security measure, not a malware verdict.

How to Respond

  1. Install from source — Build the APK yourself from this repository (see Installation-Setup) and the warning will still appear (Google has no way to recognize self-built APKs).
  2. Use apksigner verify — Verify the APK signature matches the source: 
    apksigner verify --print-certs app/build/outputs/apk/debug/app-debug.apk
  3. Check the manifest — Review AndroidManifest.xml in the source. Every permission is documented with its security purpose.
  4. Submit a false-positive report — If Play Protect blocks installation, you can submit the APK to Google's Safe Browsing False Positive Report with a note that this is an open-source security application.

Third-Party Antivirus False Positives

Some third-party antivirus apps on Android may flag HydraDragonAV Mobile due to:

Trigger Reason
Permission set The combination of ACCESSIBILITY_SERVICE + RECEIVE_SMS + QUERY_ALL_PACKAGES is statistically rare in legitimate apps and common in malware.
Package name Some AVs flag apps not from Google Play with higher suspicion.
Foreground service Persistent background services with sensitive permissions may trigger heuristic rules.
Native code The app bundles native Rust libraries (libhydradragonandroid.so) — some AVs flag apps with native code as higher risk.
Low installation count Apps with few installs are more likely to be flagged by cloud-based AV reputation systems.

If Your AV Flags the App

  1. Submit a false-positive report to the AV vendor with a link to this repository.
  2. Build from source to confirm the APK matches the published code.
  3. Add the app to your AV's whitelist if you are satisfied it is legitimate.

Verifying App Integrity

To verify you are running the genuine HydraDragonAV Mobile:

# Clone the repository
git clone https://github.com/anomalyco/HydraDragonAV-Mobile.git
cd HydraDragonAV-Mobile

# Build the APK
./gradlew assembleDebug

# Verify the APK signature
apksigner verify --print-certs app/build/outputs/apk/debug/app-debug.apk

The certificate fingerprint of your self-built APK should be the same as any APK built from the same source.

Why HydraDragonAV Mobile's APK Is Large (100MB+)

HydraDragonAV Mobile's APK size exceeds 100MB because it bundles everything needed for fully on-device, offline detection — no cloud, no downloads:

Component Approx. Size Why It's Bundled
Native Rust engines (libhydradragonandroid.so) ~40–50 MB Compiled Rust code for YARA-X, ClamAV parser, Burn ML, Unicorn emulator, XOR-filters — all statically linked for performance
YARA-X rules + ClamAV signatures ~20–30 MB Thousands of Android-relevant detection rules compiled into the APK as assets/
NSRL whitelist (XOR filter) ~15–25 MB Dual-layer whitelist of known-good software (~300M+ hashes compressed into a binary-fuse XOR filter)
URL/IP/domain XOR filters ~5–10 MB Pre-compiled XOR filters for malicious network indicator matching
ML model (model.mpk + vocab.json + features.json) ~1–3 MB Burn (ndarray) binary APK classifier — vocabulary-mapped subword tokenizer (vocab.json, <UNK> = id 0) + 11 corpus-percentile-normalized engine features
Android Java/Kotlin bytecode ~5–8 MB The app's own UI, services, and engine wrappers

Note: The ML model is a pure-Rust Burn neural network running fully on-device using the bundled model.mpk weights. The accompanying vocab.json ships alongside it — the tokenizer maps string fragments through that vocabulary (<UNK> → id 0) at inference time.

These are not encrypted payloads or hidden blobs — they are the detection engines themselves. A security app that detects malware entirely on-device must ship its detection databases with the APK.

Verifying the Contents Yourself

You can inspect exactly what makes up the APK using JADX:

# Decompile the APK
jadx-gui app/build/outputs/apk/debug/app-debug.apk

What you will see:

  1. assets/ — Detection databases: YARA rules (.yrc), XOR filters (.xf), NSRL whitelist (whitelist.xf + whitelist_packages.csv), ML model (model.mpk + vocab.json + features.json)
  2. lib/ — Native Rust libraries for arm64-v8a, armeabi-v7a, x86_64
  3. res/raw/ — Any additional bundled signature or config files
  4. classes.dex — The Android Java/Kotlin code (decompiled to readable Java via JADX)
  5. AndroidManifest.xml — Full permission declarations with inline documentation

To confirm no hidden payloads exist:

# Extract and list everything
unzip app-debug.apk -d apk_out/
du -sh apk_out/assets/* apk_out/lib/* apk_out/res/raw/*

# Every large file's purpose is documented in this wiki and the source repository
# Compare against the source at https://github.com/anomalyco/HydraDragonAV-Mobile

How This Differs from Malware Hiding in Resources

HydraDragonAV Mobile Malware Hiding Payloads
Large files Detection databases (YARA rules, NSRL hashes, ML models) — documented, open-source Encrypted DEX/Native payloads — undocumented, no source
File names Descriptive (yara_rules/, nsrl_filter.xor) Obfuscated (random hex, single-letter, no extension)
Code loading JNI calls to documented native engine APIs (NativeScanner.scan(), NativeScanner.init()) DexClassLoader on extracted blobs from assets
Verification Build from source, compare checksums, review the code No source to compare against

For Third-Party Security Researchers

If you are analyzing HydraDragonAV Mobile and want to verify there is no hidden behavior:

  1. Build from source — git clone + ./gradlew assembleDebug produces an APK with identical structure
  2. Compare with JADX — Decompile both the pre-built and self-built APK; the code and resources should match
  3. Monitor runtime behavior — The app makes no network connections (except the optional DNS-filtering VPN which routes only DNS traffic), creates no hidden files, and spawns no hidden processes
  4. Check the native library symbols — nm -D libhydradragonandroid.so lists all exported Rust functions; every symbol maps to a documented detection engine

Transparency

We believe in full transparency about every permission the app uses:

  • Every permission is declared in AndroidManifest.xml with inline comments explaining its purpose.
  • The app is 100% open source — review the code yourself.
  • No data leaves the device — all detection, analysis, and decision-making is on-device.
  • The app uses no analytics SDKs, no tracking frameworks, no telemetry, and no cloud services.
  • All source code is auditable, buildable, and verifiable.

If you have concerns about a specific permission or behavior, please open an issue on the repository.

Clone this wiki locally