Security Validation · Quality

This page explains how we guarantee that protection actually works without breaking healthy apps. For a security product, stability matters just as much as raw strength — if protection breaks a legitimate user's app, that isn't protection, it's an outage. And trust is grounded not in marketing copy, but in publishing validation results and limitations.

1. Real-Device Validation — 1,800+ Device Runs#

Emulators alone aren't enough. Appsolid automatically tests its protected output on 102 real device models (Samsung · Google · Xiaomi · LG, Android 8–16, API 26–36), and has performed over 1,800 cumulative device runs across combinations of protection variants.

• Form factors: 93 phones · 9 tablets — full list: Test Devices
• Includes 32-bit (armeabi-v7a) devices — confirmed zero O-MVLL 32-bit miscompilations and zero anti-Frida 32-bit false positives
• Behavioral differences across manufacturer ROMs (Samsung One UI, Xiaomi HyperOS, etc.) are validated before release

2. Functional Equivalence · No Bricks#

We run the protected build and the original side by side on the same device to confirm an identical entry screen, a normal boot, and zero packing failures. We validated correct operation against a real customer app corpus, covering early ContentProvider loading, native loadLibrary, Firebase initialization, AAB resource preservation, SPI (META-INF/services) preservation, and more.

3. RASP — End-to-End Validation of 7 Threats#

We actually triggered all 7 threat types and validated them end to end, from detection → report → arrival on the dashboard (events genuinely reaching Convex).

4. Red-Team Field Test (Attacker-Perspective Penetration)#

We protected, signed, and installed a real customer app with the engine, then attempted penetration from an attacker's point of view to measure the defense level actually achieved and its ceiling.

5. The Honest Ceiling (Validated Limits)#

In the red-team exercise above, all automated, non-root, and spawn-based paths were fully blocked; only a high-cost, fully-controlled rooted environment (manual) could observe code in memory while it runs. This is a structural limitation shared by every client-side protection.

Why it can't be prevented — for ART to execute code, the DEX must be resident in memory. We defend the state before decryption with entanglement, but in-memory residency after decryption cannot be prevented in principle. This is a structural limit of all client-side protection, and rather than hiding it, we measure and disclose it.

• Entanglement blocks common automated attacks and forces the attacker onto a high-cost manual path.

6. ART Verifier Release Gate#

The biggest risk in code transformation is the gap where a dev build (d8) passes but the real device (ART verifier) rejects it, so the app won't launch. Appsolid applies an ART verifier gate to every release, ensuring that any artifact failing verification is never deployed.

In fact, for the sake of stability we intentionally disabled some aggressive obfuscation (arithmetic and control-flow transforms) in production. We prioritize proven stability over transforms that "look stronger but occasionally cause bricks."

7. Zero-False-Positive Design · Safety Nets#

• Zero false positives — every RASP detection inspects only its own process. When a judgment is ambiguous, the app runs normally.
• d8 verification + fallback — if a code transformation fails verification, that portion falls back to the original.
• minSdk below 26 fallback — a file+JAR fallback path for older versions that lack the in-memory loading API (protection is applied identically).
• fail-safe telemetry — a failed monitoring transmission does not affect app behavior (non-blocking).

Summary#

Next#

• Test Devices — full list of 102 devices
• Threat Model — defense scope and ceiling