A 2025 empirical study analyzing more than 500,000 Android APKs found that 92.5% of the top 1,000 Google Play apps in its 2023 dataset used some form of code obfuscation. Among apps ranked outside the top 30,000, that figure was 61.9%.
The findings suggest that widely used applications are more likely to include obfuscation and multiple obfuscation techniques. However, the researchers also caution that developers should not treat obfuscation as a complete security solution.
Android applications are often susceptible to reverse engineering because APKs contain compiled code and resources that attackers can inspect with readily available tools. Decompilers can transform DEX bytecode into a readable approximation of Java or Kotlin source code, though the output is not identical to the original.
Without protection, attackers may be able to inspect proprietary algorithms, licensing logic, application workflows, endpoint information, and security controls. They may also modify the package, bypass client-side restrictions, or repackage the application.
Android app obfuscation makes this analysis more difficult. A layered approach combines basic identifier renaming with control-flow transformations, selected string and resource encryption, and runtime checks.
This article explains why baseline renaming is not enough and how layered application protection addresses both static and runtime analysis.
An Android APK is a ZIP-based package that can contain DEX bytecode, resources, a manifest, certificates, and native libraries.
Attackers can use decompilers, disassemblers, and package-analysis tools to examine these components. Depending on how the application was built and protected, they may be able to:
Obfuscation does not make these activities impossible. Its purpose is to increase the time, expertise, and effort required to understand or modify the application.
Applications that process financial information, health data, proprietary logic, credentials, licensing controls, or premium features may face greater consequences if an attacker successfully analyzes or modifies them. However, any distributed application can be inspected once it reaches a user-controlled device.
Developers should also avoid treating obfuscation as a way to secure permanent API keys or privileged credentials. Secrets embedded in a distributed application should be considered recoverable. Keep privileged credentials and sensitive authorization decisions on a trusted server.
A layered mobile app security strategy combines application hardening with secure coding, server-side authorization, dependency management, signing, testing, and platform security controls.
Android teams often assume that enabling minification in a release build provides all the protection an application needs.
R8 is the optimizer included with the Android build system. Depending on the Android Gradle Plugin version and build configuration, teams enable it through the release build’s optimization or minification settings. R8 uses ProGuard-compatible configuration rules, but R8 and ProGuard are not the same tool.
R8 performs several valuable operations:
These capabilities can reduce application size, improve performance, and make decompiled code less readable. R8 is therefore an important part of a release build.
However, R8 is not intended to prevent every form of static or dynamic analysis. Identifier renaming may replace meaningful class, field, and method names with shorter identifiers, but the application’s behavior must remain executable. Attackers may continue to analyze control flow, data usage, resources, strings, and runtime behavior.
Dynamic instrumentation tools create another challenge. Instead of relying solely on decompiled output, an attacker may observe a running application, hook methods, intercept calls, alter values, or inspect in-memory data. Identifier renaming alone does not address these runtime techniques.
A layered Android protection strategy may therefore include:
Each layer addresses a different analysis or attack technique. No individual layer guarantees that an application cannot be reverse-engineered or modified.
A layered approach combines multiple protections rather than relying on identifier renaming alone.
Identifier renaming replaces meaningful class, method, and field names with shorter or less descriptive names. This removes some of the context that helps an attacker understand what the code does.
In the recommended DashO Android Gradle integration, R8 handles renaming, removal, and optimization. DashO Android Mode works alongside R8 and adds protections that R8 does not provide, including control-flow obfuscation, selected string and resource encryption, and runtime checks.
Control-flow obfuscation changes the structure of compiled methods while preserving their intended behavior. It can make decompiled logic more difficult to follow and reduce the usefulness of automatically reconstructed source code.
DashO protection features include configurable control-flow transformations for compiled Java, Kotlin, and Android code. These transformations are intended to increase the effort required to understand application logic.
Control-flow obfuscation does not make analysis impossible. Teams should treat it as a single layer that delays and complicates reverse engineering, rather than as a guarantee that no attacker can reconstruct the application’s behavior.
Protection strength and compatibility can vary by application, platform, DashO version, and configuration. Teams should test protected builds carefully, especially when applications use reflection, serialization, generated code, dependency injection, or other dynamic behavior.
Attackers frequently search compiled applications for readable strings that reveal useful context. These strings may include:
Readable strings can help an attacker locate relevant code paths even when identifiers have been renamed.
String encryption transforms selected strings in compiled code and injects the logic required to decrypt them at runtime. This makes the protected values more difficult to locate through a basic static search.
DashO applies String Encryption broadly by default, but teams can use include and exclude rules to target specific methods, classes, or packages. Teams should determine where string encryption provides meaningful protection value and test the resulting application. String encryption can interact with reflection and other features that rely on class names stored as strings, so appropriate R8 keep rules or DashO exclusions may be required.
String encryption also does not make an embedded credential permanently secure. If an application can decrypt and use a value, an attacker controlling the device may eventually be able to observe it. Permanent secrets should remain on a trusted server.
DashO also supports encryption for selected Android assets and raw resources through Android Mode and the DashO Gradle Plugin for Android. The application decrypts protected resources when they are accessed at runtime.
Resource Encryption is configurable and disabled by default. Because it may affect resource access and runtime performance, teams should run functional and performance tests after enabling it, particularly on lower-powered supported devices.
A thorough application security risk assessment can help teams determine which strings, resources, and code paths warrant additional protection.
Static obfuscation makes compiled code more difficult to understand, but it does not detect activity that occurs while the application is running.
Runtime checks can identify configured conditions associated with dynamic analysis or unsafe environments. DashO supports checks for conditions, including:
When a check detects a configured condition, the application can respond according to the selected settings. Responses may include notifying application logic, terminating execution, or triggering another configured action.
Runtime checks do not automatically guarantee that every debugger, hook, emulator, rooted device, or modification will be detected. Attackers may attempt to bypass or turn off the checks themselves. For this reason, checks should be distributed thoughtfully and combined with static protections.
Teams should also consider the user impact of defensive responses. For example, legitimate users may run applications on rooted devices or approved emulators. An immediate application exit may not be appropriate for every product or risk level.
Test both the normal and detected conditions before release. Runtime checks may introduce overhead or unexpected behavior depending on their number, placement, frequency, and response configuration.
Together, static obfuscation and runtime checks provide stronger protection than identifier renaming alone. They should still complement—not replace—secure architecture, authentication, authorization, dependency scanning, signing, and security testing.
DashO is an application-hardening and obfuscation tool for Android, Java, and Kotlin applications.
For current Android Gradle projects, the recommended integration is to use DashO Android Mode alongside R8. The responsibilities are divided between the two tools:
| Protection | R8 | DashO Android Mode |
| Identifier renaming | Yes | Handled by R8 |
| Code removal | Yes | Handled by R8 |
| Build optimization | Yes | Handled by R8 |
| Control-flow obfuscation | No | Yes |
| Selected string encryption | No | Yes |
| Selected Android resource encryption | No | Yes |
| Runtime checks | No | Yes |
This division is important. DashO does not replace R8 in the recommended Android Gradle integration. R8 should remain enabled to handle renaming, removal, and optimization, while DashO provides additional layers of protection.
DashO processes compiled code during the build rather than modifying the application’s source files. This allows developers to continue working with readable Java or Kotlin source while generating protected release artifacts.
The DashO Gradle Plugin for Android integrates protection into the Android build process. It manages the inputs and outputs passed to DashO and can apply protection automatically to selected build variants.
DashO can also post-process APKs and Android App Bundles in supported configurations, although PreEmptive recommends integrating DashO directly into the Gradle project when possible. Build integration provides greater control and makes it easier to apply protection consistently.
PreEmptive was founded in 1996 and currently reports more than 5,000 corporate clients across 101 countries. Teams should still evaluate DashO using their own code, supported Android versions, build configuration, performance requirements, and threat model.
Feature availability and behavior may vary by DashO version, integration mode, application type, and configuration. Review the current product documentation before selecting protections for a production build.
The recommended Android workflow integrates DashO with Gradle and keeps R8 enabled.
Confirm that R8 optimization or minification is enabled for the release variant. R8 will handle renaming, removal, and optimization when used with DashO Android Mode.
Review existing ProGuard-compatible rules and remove overly broad keep rules where possible. Broad rules can prevent R8 from renaming, shrinking, or optimizing significant portions of the application.
Use the DashO project wizard or follow PreEmptive’s current integration instructions to add the plugin to the Android project.
The wizard updates the Gradle configuration and creates a DashO project file. It does not overwrite the application’s source files.
Confirm that the versions of DashO, the DashO Gradle Plugin for Android, the Android Gradle Plugin, Gradle, Java, and Kotlin are compatible.
Generate a protected release build using the default Android Mode configuration. Control Flow and String Encryption are enabled by default with relatively conservative settings, while Resource Encryption is disabled.
Test this initial build before changing the protection settings. This establishes a working baseline and helps teams determine whether an issue comes from the integration or a later configuration change.
Based on the application’s risks, review, tune, or enable protections such as:
Not every application needs every protection. Select and configure controls according to the application’s threat model and user requirements, testing after each meaningful change.
Applications that use reflection, generated code, serialization, dependency injection, or string-based class loading may need additional R8 keep rules or DashO exclusions.
Avoid excluding more code than necessary. Excessively broad exclusions reduce the amount of code that can be protected.
Run functional, regression, performance, and security tests against the protected release artifact.
Testing should cover:
Test both normal execution and the configured detection conditions.
Run DashO and R8 as part of the controlled release pipeline so that every production artifact receives the approved protection configuration.
Retain the DashO configuration, R8 rules, mapping information, build logs, and other required release artifacts. Restrict access to files that could make protected builds easier to analyze.
Confirm that the artifact tested by the team is the same artifact signed and published to users.
R8 provides important shrinking, optimization, and baseline obfuscation for Android release builds. Applications with greater exposure may benefit from additional control-flow transformations, selected string and resource encryption, and runtime checks.
DashO Android Mode works alongside R8 to add these protection layers without modifying the original source files. The appropriate configuration depends on the application’s architecture, performance requirements, supported devices, and threat model.
No individual protection makes an application immune to reverse engineering or tampering. A stronger Android security strategy combines application hardening with secure coding, server-side controls, dependency management, signing, and testing.
Start a free DashO trial to test layered Android protection against your own application and build process.
Add layered obfuscation and runtime protection to your .NET, Java, Android, and JavaScript applications. Start a free PreEmptive trial to test the right protection tools against your own code and build process.
Android app obfuscation transforms compiled code and other application components to make them more difficult to understand or modify while preserving the application’s intended behavior.
Yes. R8 can rename classes, fields, and methods in addition to shrinking and optimizing application code. However, R8 does not provide all the protections associated with application hardening, such as DashO’s control-flow obfuscation, selected string and resource encryption, and runtime checks.
No. R8 is a valuable baseline, but it does not prevent every form of static or dynamic analysis. Teams with higher-risk applications may add other protections based on their threat model.
No. Obfuscation increases the time and effort required to analyze an application, but no client-side protection makes reverse engineering impossible. Obfuscation should complement secure design, backend authorization, signing, testing, and dependency management.
In the recommended Android Gradle integration, R8 handles renaming, removal, and optimization. DashO Android Mode adds control-flow obfuscation, selected string and resource encryption, and runtime checks. R8 should remain enabled when using this integration.
No. DashO works with compiled application code during the build process. Developers continue working with readable source files while the build pipeline produces protected release artifacts.