14

I'm looking for a simple way to make sure my static final boolean DEBUG flag is set to false when exporting my Android project to APK.

I've tried using the "STOPSHIP" comment marker mentioned here, but it doesn't seem to have any effect on apk export, or I'm using it wrong.

Building a lint extension seem an overkill for such purpose, is there a simpler way to do it?

Edit

Using the auto generated BuildConfig.DEBUG flag, combined with some hard to miss on-screen indication that you're running in debug mode (plus a mental note never to upload apk's at 4am after a quick fix) - will probably have you covered.
BUT it is still not the 100% fool proof method I posted this question for.

There are still complaints about BuildConfig.DEBUG randomly not functioning as expected. So This question is still open - is there a lint trick, or similar trick to do it?

azizbekian
  • 60,783
  • 13
  • 169
  • 249
Amir Uval
  • 14,425
  • 4
  • 50
  • 74
  • 3
    Is there a particular reason you are not using the `BuildConfig.DEBUG` flag that is automatically code-generated for you? – CommonsWare Jul 15 '13 at 20:27
  • Is it reliable? http://www.digipom.com/be-careful-with-buildconfig-debug/ – Amir Uval Jul 15 '13 at 20:31
  • @uval Yes it is now. That article is from 2012. – Ahmad Jul 15 '13 at 20:34
  • 2
    @Ahmad I want to believe that, but it still not a proof :) – Amir Uval Jul 15 '13 at 20:37
  • You could always just make the flag do something *really* obvious when the app starts up, like a bright red dialog, etc. I'm assuming you run/test your signed APK at least once before it goes wild, of course. I'm pretty sure `BuildConfig.DEBUG` is working now, or it hasn't failed for me, anyway. All depends on how paranoid you want to be. – Geobits Jul 15 '13 at 21:21
  • @Geobits I'm doing what you suggest to some extent - writing "debug" on the screen, but I had a near accident once even with that, so I'm looking for a "fool proof" solution, if there is one. If something *can* go wrong - it will. – Amir Uval Jul 15 '13 at 21:35
  • 1
    Bug report [here.](https://code.google.com/p/android/issues/detail?id=27940) Apparently this was fixed in march last year. I did notice there are still some people claiming it's not fixed though, so I don't know. Never had a problem with it myself. – Kraiden Jul 16 '13 at 23:32
  • @Kraiden thanks! So there's still reason to be paranoid. I hope someone can suggest on idea to solve this using Lint or some other trick. – Amir Uval Jul 17 '13 at 07:20
  • The confusion around BuildConfig.DEBUG may be related to the fact that it is set depending on whether your build is _debuggable_, not whether or not it is the debug build type. So a release build with debuggable set to true would have BuildConfig.DEBUG = true. – Damien Diehl Apr 25 '16 at 18:46
  • Alternatively you can create a boolean flag for debug mode `app/src/debug/res/values/bools.xml` and for release mode `app/src/main/res/values/bools.xml` – TheRealChx101 Aug 29 '19 at 12:54

4 Answers4

10

Starting from Android Gradle Plugin 3.0 you can make following configuration in build.gradle file: 


    android { 
        lintOptions {
            fatal 'StopShip' 
        } 
    }
This will break the build as long as there exists a StopShip comment in codebase.

Watch the exact minute of Tor Norbye's "Kotlin Static Analysis with Android Lint" talk, where he talks about the feature.

azizbekian
  • 60,783
  • 13
  • 169
  • 249
3

Have you solved this? I know 2 years have passed, but I just found this while searching what was STOPSHIP after finding it by accident while commenting.

StopShip
--------
Summary: Code contains STOPSHIP marker

Priority: 10 / 10
Severity: Warning
Category: Correctness
NOTE: This issue is disabled by default!
You can enable it by adding --enable StopShip

So I would say you should have executed the command in order to enable it.

Edison Spencer
  • 491
  • 1
  • 9
  • 24
2

I've been using this flag reliably for several years now:

BuildConfig.DEBUG

It doesn't have the issues that occurred long ago, when I posted this question.

Amir Uval
  • 14,425
  • 4
  • 50
  • 74
1

You could modify the build.xml, have it read your DEBUG flag from the source and simply change the file name of the APK depending on the value. Make that name explicit enough and you will never distribute or upload the wrong APK (and you can also make it a condition for other following automated processes).

Community
  • 1
  • 1
Bananeweizen
  • 21,797
  • 8
  • 68
  • 88
  • Nice idea. The link you've sent shows how to extract value from a property file. Is it possible to extract from code? If the export script can check the auto generated 'BuildConfig.DEBUG' flag, and add a DEBUG_... to the apk name, it can be that extra layer of fool proof protection. – Amir Uval Jul 24 '13 at 11:33
  • Indeed, for non property files it becomes a bit more complicated, but still can be done: http://stackoverflow.com/questions/4302019/how-to-search-for-a-string-in-files-with-ant-make-sure-certain-string-isnt-fou. If you are on a unix based machine, you might find it easier to call sed instead from Ant. – Bananeweizen Jul 24 '13 at 12:14