Performance · Compatibility

We disclose the trade-offs of a security product—supported scope, size, and startup time—transparently. Experts look not only at "how strong it is" but also at "how far it goes and what you give up."

Supported Scope#

Per-Version Loading and ARM-Only#

• minSdk 26 and above — in-memory only — InMemoryDexClassLoader (memory-only DEX loading) has been available since Android 8.0 (API 26). In this case the decrypted DEX is never written to disk at all. Furthermore, the fallback paths below are excluded from the build entirely for such apps, leaving no attack surface for a downgrade attempt.
• minSdk below 26 — file + JAR fallback — Apps that must support pre–Android 8.0 (below API 26) are protected as well. The segment where the in-memory loading API is unavailable is handled by a file + JAR fallback path. Protections such as packing, obfuscation, and string encryption are applied identically (code transformations stay compatible with the target version via forApi); the only difference is from in-memory-only mode.
• ARM only — Native protection (.so) targets ARM (arm64-v8a/armeabi-v7a). The overwhelming majority of real user devices are ARM, while x86 is mostly used by emulators. During protection the x86 native libraries are removed, which also reduces the analysis surface on emulators.

Framework Compatibility#

⚠️ Important — Appsolid's core protection is DEX (Java/Kotlin bytecode) packing. As a result, the scope of protection depends on whether the code is compiled to DEX.

For Flutter, React Native, and Unity apps, we recommend validating the protection scope and behavior in advance via sample protection + real-device testing. If protecting JS/Dart code is a core requirement, please contact us before adoption.

Size Impact#

Protection adds an encrypted DEX + a native loader (.so), so the output grows in size. The increase varies with the original DEX size and the options chosen, and is typically in the range of single digits to the low teens percent of the original (e.g., about +12% for a large multi-DEX app). For AAB, Play's split delivery mitigates the impact on user downloads.

Startup Time Impact (Measured)#

Core protection decrypts and loads the DEX once, on the app's first launch. Based on real-device measurements:

We monitor decrypt_ms via internal diagnostics, and a parallel decryption optimization has further shortened cold-start for large apps (e.g., −16–22%). Subsequent execution flows are identical to a regular app.

Note on NFC/HCE Payment Apps#

For NFC tap-to-pay (HCE) apps, the OS starts the process when a tag is presented while the app is not running, so if cold-start latency exceeds the NFC timing budget, the payment may fail.

• Integrity verification (selfChecksum) runs on a background detached thread and therefore does not block the NFC tap path (detection fires roughly 200ms–1s later, while termination on tampering is retained).
• String encryption can add latency when invoked on hot paths, so exclude NFC/payment-critical classes or review caching.
• Required — Payment and NFC apps must measure cold-start time after protection and validate tap-critical flows. Provide a test login and we will run the regression verification on your behalf.

Deployment Compatibility#

• zipalign — Including 16KB page alignment (Android 15+), applied automatically (you don't need to do it yourself).
• SPI preservation — META-INF/services is preserved.
• Signing — The output is unsigned. Re-sign with your own keystore (Quick Start). Also compatible with Play App Signing (sign with the upload key, then submit).
• Re-protection — Runtime security updates (such as enhanced detection) take effect from newly protected builds onward, so applying the latest protection requires re-protecting.

Next#

• Test devices — the full list of verified devices
• Security Assurance · Quality — verification procedures and performance evidence