Otukan fits into your Android build and release process without changing how you ship. It protects what your build actually produces: app bundles and APKs, DEX compiled from Kotlin and Java, native libraries for each ABI, and the code inside Flutter and React Native apps. Integrity checks are bound to the certificate your users receive, including under Play App Signing, and your signing keys stay with your team. While the app runs, Otukan detects rooted devices, hooking, debuggers, emulators and repackaged copies, and applies the response you set for each flow. iOS is protected on its own terms and has its own page, iOS app security.
Build inputs Otukan protects
Android apps differ more in their build output than in their source language. Otukan protects the artefacts your pipeline really ships, including code your team did not write.
| Input | What it is | How Otukan handles it |
|---|---|---|
| Package format | Google Play requires new apps as Android App Bundles; other channels often still take APKs | Protects the release artefact each channel needs, bundle or APK |
| Kotlin and Java code | Compiled to DEX, usually after R8 shrinking and renaming | Adds obfuscation, string encryption and integrity checks alongside R8, and keeps your mapping workflow intact |
| Native libraries | NDK code shipped as shared libraries, one set per ABI (for example arm64-v8a, armeabi-v7a, x86_64) | Protects your native code for every ABI you ship |
| Cross-platform frameworks | Flutter ships compiled Dart in a native library; React Native ships a JavaScript or Hermes bytecode bundle | Protects the framework’s own code, not only the Android shell around it |
| Third-party SDKs | Analytics, payments and identity SDKs run in the same process | Tunes runtime checks so that SDKs which inspect the app do not trip your policy |
| Build variants | Flavours and build types produce several release artefacts from one codebase | Applies one consistent protection profile to every artefact you release |
| API levels | minSdk and targetSdk decide which platform features and restrictions apply | Validates each control per API level on physical devices |
Framework-specific detail is on Flutter app security, React Native app security and .NET MAUI app security.
Release workflow
Signing that stays yours
Android signing decides which certificate the installed app carries, and that is what a re-signing check must verify. With Play App Signing, Google holds the app signing key and you hold an upload key, so the certificate on users’ devices is Google’s app signing certificate, not your upload certificate. Otukan binds its integrity checks to the certificate your users actually receive. If you also sign builds yourself for other channels, Otukan accepts each valid certificate, so legitimate installs pass and repackaged copies do not.
You sign every release with your own keys, in your own pipeline. Otukan does not need them.
Step-by-step guidance is in how to sign a protected Android app, and key handling is covered on app signing security.
Every delivery channel
The same app often reaches users through Google Play, a managed enterprise channel and a device maker’s own store. Each channel processes and signs releases differently. Otukan verifies the protected build for each channel you use, so the checks that protect your app on one store do not break it on another.
Protected-build testing
Otukan works with your team on a test plan for the protected artefact, not only the unprotected one:
- a clean install and an update from the previous release
- sign-in and your most sensitive flows, such as payments or account changes
- the same journeys on physical devices from several manufacturers and OS versions
- the same journeys on a legitimate device with developer options enabled, to confirm your customers see no false alarms
Coverage on Android
Each protection family has its own page. On Android, each is validated per API level on physical devices.
| Protection family | What Otukan does on Android |
|---|---|
| Code obfuscation | Hardens DEX, native libraries and framework bundles against reverse engineering |
| Anti-tampering | Checks code, resources and the signing certificate your users receive |
| Root detection | Combines independent signals and feeds them to your response policy |
| Runtime protection (RASP) | Detects hooking, debugging and emulators while the app runs, and responds per flow |
| App attestation | Gives your server evidence of a genuine app, complementing Google’s Play Integrity verdicts |
| Malware detection | Reports signs of malware and fraud tooling on the device to your backend |
Android runs on a very wide range of hardware, and manufacturers change system behaviour. A check that behaves well on one manufacturer’s build can behave differently on another. That is why Otukan validates on devices from several manufacturers, and why your policy can treat each signal differently for each flow. How to judge where protection works across OS versions, devices and distribution channels is covered on supported environments.
For how Android fits the wider protection model, return to mobile app security. If your Android app is already on Google Play, a free App Exposure Check reviews the public store release.