Protecting an Android application from copying: effective methods and tools

Android application developers lose billions of dollars every year due to illegal copying and distribution of their products. According to data App Annieup to 25% of all installations of mobile applications are from pirated versions, and in some regions (for example, in Southeast Asia) this figure reaches 60%. Protecting an application from copying is not just a matter of preserving revenue, but also a matter of brand reputation, security of user data and compliance with license agreements.

In this article we will look at 7 proven protection methodsfrom basic (code obfuscation) to advanced (server-based license validation), and also consider tools that will help automate the process. We will pay special attention practical nuances: how to bypass restrictions Google Play, why some methods only work on rooted devices, and how not to lose legitimate users, strengthening protection. If you are the owner of a startup, an indie developer or a representative of a large company, here you will find a solution to suit your needs.

1. Code obfuscation: the first barrier for hackers

Obfuscation is the process of converting source code into a hard-to-read form without changing its functionality. In the context of Android, it solves two problems: it complicates reverse engineering (APK decompilation) and hides the logic of the application, including licensing or authentication algorithms.

The most popular tool for obfuscation of Android applications is ProGuard. built in Android Studio. It removes unused code, renames classes and methods into meaningless sequences of characters (for example, a.b() instead of LicenseChecker.verify()). However, ProGuard has limitations:

• 🔹 Does not encrypt string resources (they can be extracted from resources.arsc).
• 🔹 Does not protect against dynamic analysis (for example, through Frida or Xposed).
• 🔹 Requires manual configuration proguard-rules.pro for libraries (for example, Retrofit or Firebase).

For enhanced protection, use DexGuard (commercial version of ProGuard) or Obfuscator-LLVM —they add string encryption, code integrity control and debugging protection. Example configuration for DexGuard:

-keep class com.example.license.** { *; }
-renamesourcefileattribute SourceFile
-optimizationpasses 5
-dontshrink

⚠️ Attention: Obfuscation does not protect against copying of an APK file from the user's device. It only complicates code modification. Additional methods are required for full protection.

2. APK integrity check: detecting changes

Pirates often modify APK files by removing checks. licenses or introducing advertising. To detect such changes, use checksums (hashes) or digital signatures. Working algorithm:

1. When building the application, calculate the hash of the original APK (for example, SHA-256).
2. Embed this hash into the application code (for example, in AndroidManifest.xml as metadata).
3. At each launch, compare the hash of the current APK with the reference one.

Example code in Kotlin for checking the hash:

fun verifyApkIntegrity(context: Context): Boolean {
val packageInfo = context.packageManager.getPackageInfo(context.packageName, 0)
val apkPath = packageInfo.applicationInfo.sourceDir
val expectedHash = "YOUR_EXPECTED_SHA256_HASH" // Hash of the original APK

val actualHash = File(apkPath).inputStream().use { input ->
MessageDigest.getInstance("SHA-256").digest(input.readBytes()).joinToString("") {
"%02x".format(it)
}
}

return actualHash == expectedHash
}

If the hashes do not match, the application can:

• 🛑 Block the launch with a notification to the user.
• 🔄 Send a report to the server (with IP and device data).
• 🔒 Go to "demo mode" with limited functionality.

⚠️ Attention: The APK hash will change after any update. Do not forget to update the reference value in the code with each release.

3. data-i="82">(LVL) is an official mechanism for checking the legality of installing an application. It works on the principle of a request to Google servers: the application sends

Google Play Licensing (LVL) is the official mechanism for verifying the legality of an application installation. It works on the principle of a request to Google servers: the application sends unique device identifier and receives a response about the license status (LICENSED, NOT_LICENSED or RETRY).

Advantages of LVL:

• 🔐 Integration with Google infrastructure (no need to deploy your own server).
• 📱 Support for offline mode (response caching for 1–7 days).
• 🛡️ Protection against response substitution via certificates.

How to configure LVL:

1. Add the library to build.gradle:

   implementation 'com.google.android.vending:license:8.3.0'

2. Generate a license key in Google Play Console (Settings → Licensing and in-app purchases).
3. Implement a response handler:

   class LicenseCheckerCallback : LicenseCheckerCallback {
   override fun allow() { / Allow access / }
   override fun dontAllow() { / Block / }
   override fun applicationError(errorCode: Int) { / Handle error / }
   }

LVL restrictions:

• ❌ Does not work for applications distributed outside Google Play.
• ❌ Pirates can block requests to Google servers via hosts or VPN.
• ❌ Requires an Internet connection (albeit with caching).

Add dependency to build.gradle|

Generate a key in Google Play Console|

Implement LicenseCheckerCallback|

Test on an emulator with a fake response (RESPONSE_NORMAL)|

Configure offline mode processing-->

4. Server validation: maximum protection

The most reliable, but also the most complex method is checking the license on your server. Operating principle:

1. The application sends unique device data (IMEI, Android ID, MAC address, etc.) to the server.
2. The server checks whether this ID is associated with a legal purchase.
3. Returns the access token that the application caches.

Advantages:

• 🌍 Works for any distribution channels (including third-party stores).
• 🔧 Flexible logic (you can block devices suspected of piracy).
• 📊 Ability to collect statistics on illegal installations.

Architecture example:

Key points of implementation:

• 🔑 Use JWT tokens with a short lifetime (1–24 hours).
• 🔄 Implement a mechanism for updating the token without re-validation.
• 🛡️ Encrypt traffic (HTTPS + certificate pinning).

⚠️ Attention: Collection of unique device identifiers (IMEI, MAC) may conflict with privacy policy (for example GDPR in the EU Use anonymized hashes or request explicit consent). user.

5. Protection against debugging and reverse engineering

Even if the code is obfuscated, attackers can analyze the behavior of the application at runtime using debuggers (JDB, IDA Pro) or frameworks like Frida. To complicate their task:

• 🛠️ Disable debugging in the release build:

  android:debuggable="false"

  in AndroidManifest.xml.

• 🔍 Check for the presence of a debugger:

  if (Debug.isDebuggerConnected() || Debug.waitingForDebugger()) {
  // Blocking or false data
  }

• 🔒 Use Native Code (C/C++): Move critical checks (for example, licensing) to native-libraries (.so files). They are more difficult to decompile.
• 🚫 Block tools like Frida:

  if (checkFrida()) {
  throw SecurityException("Tampering detected")
  }

For detection Frida you can check:

• Presence of processes (frida-server).
• Loaded libraries (libfrida-gadget.so).
• Open ports (27042–27047).

Example code for checking Frida on Kotlin:

fun checkFrida(): Boolean {
return try {
System.loadLibrary("frida-gadget") // Attempting to load the Frida library
true
} catch (e: UnsatisfiedLinkError) {
false
}
}

6. Linking to the device and hardware keys

One of the radical methods is binding the application to the unique characteristics of the device. complicates the transfer of a pirated copy to other gadgets. Implementation options:

• 📱 IMEI/MEID: Unique device identifier (requires permission READ_PHONE_STATE).
• 🔑 Android ID: Identifier reset only after resetting the device (Settings.Secure.ANDROID_ID).
• 💾 Serial Number: Device serial number (Build.SERIAL).
• 🔐 Hardware Fingerprint: Combination of several parameters (model, manufacturer, OS version, etc.).

Example of generating a hardware fingerprint:

fun getDeviceFingerprint(context: Context): String {
val telephonyManager = context.getSystemService(TELEPHONY_SERVICE) as TelephonyManager
val androidId = Settings.Secure.getString(context.contentResolver, Settings.Secure.ANDROID_ID)
val serial = Build.SERIAL ?: "unknown"
val imei = if (Build.VERSION.SDK_INT >= 26) {
telephonyManager.imei ?: "unknown"
} else {
telephonyManager.deviceId ?: "unknown"
}

return "$androidId|$serial|$imei|${Build.MODEL}".hashCode().toString()
}

How to use binding:

1. When you first start, send a fingerprint to the server and link it to your account the user.
2. At subsequent launches, compare the current fingerprint with the saved one.
3. If there is a mismatch, request re-authentication or block access.

⚠️ Attention: Binding to a device may cause problems for legitimate users:

• After resetting the settings (factory reset), the Android ID will change.
• On some devices (for example, Xiaomi) Build.SERIAL returns unknown.
• In Android 10+ access to IMEI is limited (requires permission READ_PRIVILEGED_PHONE_STATE, which is not available to regular applications).

We recommend combining several identifiers and providing the user with a way to restore access (for example, via email).

7. Alternative methods: from DRM to social protection

In addition to technical solutions, consider non-standard approachesthat will make life more difficult for pirates or make piracy less profitable:

• 🎮 DRM for content: If your application distributes media files (video, music), use Widevine or PlayReady to encrypt them. Even if the APK is copied, the content will remain protected.
• 📧 Account linking: Require registration via email/social networks and link the license to the account, not the device.
• 💰 Subscription model: Piracy is less profitable for applications with monthly payment (for example, Netflix or Spotify\)) than for one-time purchases.
• 🤝 Partnerships with manufacturers: Some brands (for example, Samsung or Huawei) offer built-in protection mechanisms for applications in their branded stores.
• 📢 Social pressure: Show risk notifications to users of pirated versions (viruses, data theft) or offer a discount on the legal version.

To: abuse@example.com
Subject: DMCA Takedown Request

I am the copyright owner of the Android application "[App Name]" (package: com.example.app). The following URL hosts an unauthorized copy of my work:
[Link to pirated version]

This letter is an official notification under the Digital Millennium Copyright Act (DMCA). I request the immediate removal of this content.

Contact me at: your@email.com
[Your name/company]