36

The golden rule is to set debuggable option to off prior to releasing your Android application to the public.

What would happen if I leave (forget to turn off) this option on? I mean, how would it manifest to a user?

I tested and saw no difference.

sandalone
  • 41,141
  • 63
  • 222
  • 338

5 Answers5

76

how would it manifest to a user?

A normal user won't notice the difference.

By the way:

Support for a true debug build. Developers no longer need to add the android:debuggable attribute to the tag in the manifest — the build tools add the attribute automatically. In Eclipse/ADT, all incremental builds are assumed to be debug builds, so the tools insert android:debuggable="true". When exporting a signed release build, the tools do not add the attribute. In Ant, a ant debug command automatically inserts the android:debuggable="true" attribute, while ant release does not. If android:debuggable="true" is manually set, then ant release will actually do a debug build, rather than a release build.

Cristian
  • 198,401
  • 62
  • 356
  • 264
  • Are you saying that as of SDK 8.0.1 I do not need to set debuggable on/off but Eclipse plug-in will rather do it automatically? – sandalone Jan 02 '11 at 21:46
  • 2
    Yes. Eclipse uses the android build tools in the background; thus, you won't have to explicitly add the `android:debuggable` attribute; also when you use the Eclipse's plugin to generate the production APK, it will remove the attribute for you. – Cristian Jan 02 '11 at 21:48
  • 2
    How can I see if an app I transfer to a mobile device has debuggable set to on or off? I mean, how can I be sure that plugin is doing its job properly. Since long time ago I am used not to trust any action which result I can't visually verify. – sandalone Jan 02 '11 at 21:59
  • @sandalone this question covers the topic http://stackoverflow.com/questions/7085644/how-to-check-if-apk-is-signed-or-debug-build – Moog May 27 '12 at 12:30
19

On a standard phone with USB debugging disabled, it will allow any application to debug the App. This will effectively allow any malicious application to gain full access to the App.

See https://labs.mwrinfosecurity.com/blog/2011/07/07/debuggable-apps-in-android-market/ for a detailed description of this problem.

Bhavin Nattar
  • 3,189
  • 2
  • 22
  • 30
nils
  • 191
  • 1
  • 2
  • The linked article is an excellent technical explanation of the problem, and I think it best answers the original poster's question. Thank you. – Goffredo Dec 14 '11 at 03:14
  • 5
    Sadly, the link is dead. Perhaps this is the same page? http://labs.mwrinfosecurity.com/blog/2011/07/07/debuggable-apps-in-android-market/ –  Aug 13 '12 at 12:02
7

It's possible that it could slow down their mobile device, especially if you have a lot of debug statements in your application. It's also possible that a malicious user could learn more about the inner-workings of your app then you'd like them to.

Regarding the golden rule, you're absolutely right. It's a good idea to turn that off, just to be safe.

jamesmortensen
  • 33,636
  • 11
  • 99
  • 120
  • That's something I couldn't think of. It's a thing one should always consider. Thanks – sandalone Jan 02 '11 at 21:56
  • I believe that Android adds more code to the source code in order to allow debugs but which has a performance impact. It is better remove debug statements in any language though. – Tarik Dec 31 '13 at 00:21
  • I don't see how examining (or even altering) the app's inner functioning *done by the owner of the device himself* could be considered malicious. – flarn2006 Nov 30 '17 at 20:35
  • @flarn2006 - My thought was that it might be possible for a hacker to learn about the inner workings in order to launch some kind of attack against other users of that same app. For instance, we wouldn't want someone to see the inner workings of the Citibank app and then figure out how to write some kind of exploit that would capture information of other Citibank app users and send that off to the hacker's server. I'm not an expert on security, but that was my original thought back then. Hope this helps! – jamesmortensen Dec 01 '17 at 08:45
  • @jmort253 I certainly wouldn't want to use the Citibank app if its security was at all dependent on people not knowing the inner workings of an app on their own phone. That's security through obscurity, and it's unreliable. You may say it's better than no protection from that, just in case there *are* any such bugs that could be found that way, but then that increases the temptation for the devs to ignore bugs that could only be found that way (making the false assumption no one will) and also makes it more difficult for independent *white hats* to find bugs to report to the developers. – flarn2006 Dec 04 '17 at 23:00
  • @flarn2006 Oh no, I'm not advocating for security through obscurity. I'm saying don't make it easier for people to reverse engineer things by giving them more info. Example: Google Earth and Google Maps don't show the map of some government locations on the planet. Those places are likely very secure and well guarded, but they're not going to make it any easier for people to figure out a plan to break into them by giving them the building plans or layout. – jamesmortensen Dec 05 '17 at 10:30
6

It's also possible that a malicious user could learn more about the inner-workings of your app then you'd like them to.

One good practice is to link debugging mode specifically to your unique device id.

Team Pannous
  • 1,074
  • 1
  • 8
  • 11
4

@askmo: you can use some tools in the SDK to check if an APK has the debug value. Check the following link:

http://lulachronicles.blogspot.com/2011/04/how-to-check-if-apk-has-flag.html

BR,

Ignacio

Ignacio
  • 41
  • 1