7

I would like to know exactly what the debuggable true statement does:

// build.gradle
android
  {         
    buildTypes
      {
        debug
          { debuggable true
          }       
      }
  }

I am able to debug without it using the emulator (genymotion): the breakpoints work; the Log.d(...) statements output to the Android Monitor;

Since the debuggable flag is inside the debug section, it seems redundant anyway. Shouldn't it be outside the buildTypes section, indicating to the ide that the debug buildtype should be used?

It would also be nice to get some simple layperson general background understanding of the difference between the debug and release buildtypes.

user229044
  • 232,980
  • 40
  • 330
  • 338
dsdsdsdsd
  • 2,880
  • 6
  • 41
  • 56
  • Stop putting messages like "downvoters please explain why" in your posts. Downvoters will or will not explain as is their prerogative, you're adding needless clutter to the site by constantly bothering them to do so, and such meta information does not belong in your questions or answers. – user229044 May 13 '16 at 14:17
  • 1
    I agree ... it's pithy ... but at the same time, if I post a question that gets downvoted, other knowledgeable people will tend to avoid looking at it, presuming it is an illegitimate question ... and that affects the integrity of this system – dsdsdsdsd May 13 '16 at 14:51

2 Answers2

6

On Android, debuggers communicate with the virtual machine using JDWP. When debugging is enabled, the VM creates a dedicated thread that listens for JDWP traffic and responds to requests. (It's also possible to use a native debugger, such as gdb, but that's a different kettle of fish.)

On devices sold to consumers, there's generally no need to have the extra thread running, so by default apps are not debuggable. Also, malware could potentially use the debugger interface to examine or manipulate running apps, so it's safest to disable it. On the other hand, anything running on an emulator should be debuggable, so the default behavior there is different. The ro.debuggable system property determines this (adb shell getprop ro.debuggable).

The debuggable flag in the app manifest tells the VM that the app is under development, and connections from debuggers should be allowed whether or not the app is running on a production device.

All of the above relates to the app's runtime behavior, not the build. Debug builds are also different from release builds. Passing the -g flag to javac causes additional information to be output, and there are dx options that will strip or keep additional debug information in the .dex file. (I don't know how the gradle flag interacts with these.)

fadden
  • 51,356
  • 5
  • 116
  • 166
  • thanks .. this is helpful ... but forgive me as I still am unsure of exactly what the `debuggable` flag does ... it doesn't seem to have any effect whether I am testing using the `Run` or `Debug` button (android studio), or whether I am using an emulator (genymotion) or a real android mobile phone. Neither break points nor Log.d(...) seem to be affected ... – dsdsdsdsd May 11 '16 at 02:58
  • When the app is built with `debuggable` set to false, the manifest will indicate that the VM should not listen for debugger activity. So you should not be able to attach a debugger to your app when it's running on a production (non-developer) device. Rooted devices may change `ro.debuggable`, so you may want to confirm the setting with the adb shell command shown in the answer. Nothing in the build configuration will affect `Log.d`; if you want to disable log messages you will have to do that yourself. (Adding a check to `log.d` wouldn't work well -- doesn't skip the argument setup.) – fadden May 11 '16 at 05:17
1

It causes the Android gradle plugin to include the debuggable flag in the application manifest when it is generated. This allows debuggers to attach to the app while running in the emulator or on device.

Larry Schiefer
  • 15,687
  • 2
  • 27
  • 33
  • it sounds stupid, but this creates even more questions for me (I come from a javascript/web app background) ... ... what does "attach to the app" mean ... what are "debuggers" (other than the obvious definition) ... what is an "application manifest" ... why does one need to be generated?? (who will use it??) ... – dsdsdsdsd May 10 '16 at 16:23
  • @dsdsdsdsd that is all a google search away.question of these type are off topic on this form.you are basically looking for a tutorial. – Viral Patel May 10 '16 at 16:44
  • no more so than almost any other question on this site ... since you are "AndroidMechanic", and you apparently use this site, maybe you could offer some meaningful information, such that when future android newbies like me are in search of understanding, and they might use google and land HERE, your wisdom will be valuable to them ... – dsdsdsdsd May 10 '16 at 16:59
  • 1
    @dsdsdsdsd developing outside of the Javascript / web world is quite a bit different. Android development is no exception and is also different than developing for other traditional operating systems. A beginners course on Android development would definitely help you out there. There are plenty of training courses available as paid subscriptions (I have authored 2 on Pluralsight.com) as well as freely available. – Larry Schiefer May 10 '16 at 19:58