Protecting an SDK Is Harder Than Protecting an App.
Here's How to Do It.
If you develop a payments SDK, an authentication library, a SoftPOS kernel, or any commercial Android AAR or iOS framework, you face a security problem SDK integrators never will: your code ships inside binaries you don't control, on devices you'll never see, integrated by development teams working across different environments, toolchains, and security practices.
The application’s build process and security measures are outside your control. You cannot assume that the application will be properly obfuscated or signed. And yet your SDK often contains exactly what attackers want; payment logic, cryptographic key handling, fraud-detection heuristics, proprietary algorithms, licensing checks. One published bypass of your SDK affects every customer who embedded it.
This is why protecting an Android SDK or iOS framework is often more difficult than protecting a standalone application, even when the same security requirements apply.
What makes SDK protection different
1. An SDK is not the final container.
An SDK is incorporated into a host application. Any protections it implements must coexist with the app's own security controls and any other integrated SDKs. At the same time, an embedded SDK cannot provide static protections for the application that integrates it: it cannot guarantee that the app is resistant to static analysis or prevent the app from being modified. That also means an SDK can be removed, replaced, or bypassed by an attacker who repackages the application integrating it.
2. Integration friction must be zero.
Your customers integrate your SDK through Gradle, CocoaPods, or Swift Package Manager. If protection changes the public API surface, breaks ProGuard/R8 consumer rules, or requires the host app to add initialization calls and configuration, adoption suffers; and engineers under deadline pressure will ask you for an unprotected build. The protected artifact must be a drop-in replacement for the unprotected one.
3. Runtime defense can't assume a friendly host.
An attacker doesn't need to attack your SDK through a real customer app. They build a minimal harness app, drop your AAR or iOS framework in, and instrument it at leisure with Frida or a debugger. An Android AAR obfuscator or iOS obfuscator that depends on the host app's protections protects nothing.
How DexProtector protects AAR libraries and iOS frameworks
DexProtector applies protection directly to the SDK artifact intended for distribution. You provide the release Android AAR, XCFramework, or static or dynamic iOS framework, and receive a hardened version that preserves the existing integration process. You hand DexProtector the artifact you would publish; it returns a protected SDK.
- Code obfuscation and encryption of the SDK's classes, native libraries, and resources, with the public API preserved exactly, so customer integration is unchanged.
- Class encryption, string encryption, and hide access so that decompiling the host app reveals nothing usable about your SDK's internals.
- Resource encryption. Sensitive assets, such as embedded databases, AI models, and media, are encrypted and not exposed in plaintext to the host application or attackers.
- RASP (DexProtector Runtime Engine). During protection, DexProtector embeds the DexProtector Runtime Engine (DRE), its RASP component, directly into the SDK. This enables the protected library to detect hooking frameworks, debuggers, emulators, root or jailbreak, and tampering independently, including when it is integrated into an untrusted host application. This capability distinguishes basic SDK obfuscation from comprehensive Android SDK or iOS framework protection.
- Secure communication hardening for the SDK's own network channels; pinning and certificate transparency enforced from inside the library, independent of the host application.
- Integrity control DexProtector’s core anti-tampering mechanisms are built into the protected SDK, with cryptographic binding between protected code and assets and the DexProtector Runtime Engine responsible for decrypting and loading them during runtime. This enables DexProtector to enforce a robust chain of trust from build-time to runtime, with RASP and security capabilities locked to the SDK's core functionalities. Any attempt at tampering instantly breaks this bond, keeping code and assets encrypted, restricting the SDK's operations, and stopping the attacker in their tracks.
The same pipeline covers Android (AAR, including SDKs with substantial native code) and iOS (frameworks and XCFrameworks), so a cross-platform SDK vendor ships consistent protection from a single workflow.
And critically for an SDK vendor, the entire protection process runs on-premises, in your own environment, with no cloud dependency and no remote processing; for Android and iOS alike. Your unprotected SDK is your company's most sensitive IP in its most exposed form; with DexProtector it never leaves your infrastructure. No third party sees your unreleased code, and your release pipeline never depends on an external service being up. If your build environment is air-gapped, protection runs there too.
Telemetry: knowing when your SDK is under attack
Alice Threat Intelligence
Because the DRE is already inside every protected instance of your SDK, enabling Alice Threat Intelligence is a configuration step, not an engineering project. You gain real-time visibility into attacks against your SDK across your entire customer base: which environments are instrumented, where repackaging attempts originate, which attack tools are trending. For SDK vendors this is uniquely valuable, because while your customers see only their own app, you get to see the aggregate threat picture against your product. Alice RDA, our forthcoming real-time device attestation service, will extend this into per-device trust signals your backend can act on.
Licel vTEE
For SDKs handling the most sensitive operations such as payment credentials, PIN entry, and key management in SoftPOS kernels, the Licel vTEE provides a virtual trusted execution environment: the highest level of software isolation achievable, evaluated under EMVCo's TEE security program.
Proven where it matters most
SDK vendors carry their customers' risk, so the bar for evidence is higher.
DexProtector has been independently evaluated and approved for six consecutive years under EMVCo's software-based mobile payment security program (SBMP SPT), protects SDKs embedded by major digital banks and payment providers, and runs on 12 billion+ protected app and SDK instances worldwide. Some clients have shipped DexProtector-protected products for thirteen years. Stability at that scale is a design requirement: an SDK that crashes inside a customer's app is a support escalation for them, so our protection is engineered to run fast and remain stable, with overhead your customers won't notice.
A practical checklist for SDK vendors
When evaluating an AAR obfuscator or iOS SDK obfuscator, verify:
1. Drop-in output.
Protected AAR/framework integrates identically to the unprotected one; same API, same dependency declaration, no host-side changes.
2. Self-contained RASP.
The SDK defends itself inside an attacker's harness app, not just inside well-behaved customer apps.
3. Native code coverage.
If your SDK ships .so libraries or native iOS code, protection must cover them, not just managed code.
4. On-premises protection.
The process runs entirely in your environment, so your unprotected SDK is never uploaded to a vendor cloud or touched by a remote service.
5. No consumer-rule conflicts.
Protection must coexist with a customer’s own R8/ProGuard configurations and protection tools.
6. Evidence.
Independent lab evaluations, named industries, and production scale.
Does your SDK protect payments, identity, or anything else attackers monetize?
FAQs
Can you obfuscate an AAR without breaking the public API?
Yes. DexProtector preserves the SDK's public interface exactly while obfuscating and encrypting internals, so the protected AAR is a drop-in replacement.
Does an SDK need its own RASP if the host app has protection?
Yes. You can't rely on hosts being protected because attackers analyze SDKs inside minimal harness apps. Self-contained runtime protection is the only defense you control.
How do you protect an iOS SDK distributed as an XCFramework?
DexProtector protects the framework binary itself – obfuscation, encryption, integrity control, and embedded RASP – producing an artifact your customers integrate exactly as before.
Will SDK protection conflict with the host app's ProGuard/R8 rules?
A properly engineered Android SDK protector ships with correct consumer rules and self-contained protection, so it coexists with host-side shrinking, obfuscation, and even other protection products.
Does protecting an SDK require uploading it to the protection vendor?
No. DexProtector runs the full protection process on-premises in your own infrastructure, for both Android and iOS SDKs, so your unreleased library never leaves your environment.