There's a security practice which says you should not publish your android application with debug mode enabled.
While an attacker can use apktool to decompile your application, enable the debug flag in AndroidManifest.xml and recompile it, how does not publishing your application in debug mode actually help?

Should it be coupled with anti-decompilation techniques to be useful?

What extra information is put in the application in debug mode if any, that you won't have access to when you later decompile and enable debug flag?


3 Answers 3


This is likely the same reason that you don't want to release a C/C++ program with the -g flags. Unnecessary symbols are likely stripped away or obfuscated. The build system might leave out certain security measures that will make debugging the application significantly easier. Pro-guard build scripts are likely not included in a debug build.

The following are different types of data that can be kept in debug builds depending upon configuration. Hopefully you can see why these would be helpful to someone looking to reverse engineering your application.

Debug Symbols

Debug symbols are select pieces of information that are stored within the debug binary. All function names, file names, sometimes even line numbers are included. This is so that when a program crashes and a debugger is attached all of this information can be included in stack traces. It allows the programmer to pinpoint the line of code that is causing a bug. A debug stack trace might look like the following (taken from this answer):

Exception in thread "main" java.lang.NullPointerException
        at com.example.myproject.Book.getTitle(Book.java:16)
        at com.example.myproject.Author.getBookTitles(Author.java:25)
        at com.example.myproject.Bootstrap.main(Bootstrap.java:14)

A program without debug symbols will only know library definitions. Like the following:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7fd3700 (LWP 22532)]0x00007fffe10002b4 in ?? ()
(gdb) bt
#0  0x00007fffe10002b4 in ?? ()
#1  0x0000000000000202 in ?? ()
#2  0x00007fffe1000160 in ?? ()
#3  0x00007ffff66bd1a9 in execute_internal_vm_tests () at /home/bionix/Openjdk8/hotspot/src/share/vm/prims/jni.cpp:5128
#4  0x00007ffff7fd2550 in ?? ()
#5  0x00007ffff6b08bf8 in VM_Version::get_cpu_info_wrapper () at /home/bionix/Openjdk8/hotspot/src/cpu/x86/vm/vm_version_x86.cpp:395
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

ProGuard in Android

Within the Android build scripts (Gradle) you'll find references to ProGuard. ProGuard is used to optimize, reduce binary size, and obfuscate the code. Because Java can be completely decompiled Android uses ProGuard to obfuscate the code. Here's an example of code that has been obfuscated with ProGruard:

// Before
btnNew = changeButtonLabel(btnNew, language.getText("new"));
btnOpen = changeButtonLabel(btnOpen, language.getText("open"));

// After
d = a(d, n.a("new"));
e = a(e, n.a("open"));

You can view the full tutorial with links to source code.

From the Android documentation linked above:

ProGuard is integrated into the Android build system, so you do not have to invoke it manually. ProGuard runs only when you build your application in release mode, so you do not have to deal with obfuscated code when you build your application in debug mode.

ProGuard is technically optional, but when using Android Studio it is enabled by default for Release builds.

Debug Logging

You should always have some mechanism in your code for removing debug messages from your release application. Debug messages are stored as strings within the binary, and are not obfuscated. Which means if you have a message like Log.d("Key " + super_secrey_key); a person analyzing the binary will now know where "Key " is referenced. You've now provided context, and an interesting place to start analyzing.

There are several ways that you can remove debug logs, and one of them is by configuring ProGuard to strip them out for you. There are also other libraries that you can use, or you can wrap your logging. Either way it is important to make the distinction between debug and release for your log messages.

  • I'm interested in knowing specifically what type of debug information is left in an android application and how it can help reverse engineering or gaining information about the application.
    – Silverfox
    Commented Mar 15, 2016 at 8:10
  • @Silverfox I updated my answer.
    – RoraΖ
    Commented Mar 15, 2016 at 11:52

You don't want to make reverse engineering your app too easy. Especially if it contains sensitive data such as back-end passwords or private key material. I agree that an app shouldn't contain such secrets if it is to be secure, but reality is sometimes hard.

  • 2
    I don't view disabling debugging as protection for passwords in an app. Commented Mar 12, 2016 at 23:57

You mentioned that:

While an attacker can use apktool to decompile your application, enable the debug flag in AndroidManifest.xml and recompile it, how does not publishing your application in debug mode actually help?

If your app has anti-tampering measures in place (e.g., checking its own integrity), an attacker might not be able to get away with doing this.

So they would not be able to run the app in debug mode if you publish it with debug mode disabled, unless they could also defeat your anti-tampering measures.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .