출처: http://tekeye.biz/2013/android-debug-vs-release-build
Distinguishing Android Debug Mode Vs Release Mode
Your Android application (App) will execute in debug mode in you development environment (e.g. the Eclipse or Android Studio IDEs),
and it will execute in release mode when installed from Google Play. In release mode any debug logging, StrictMode and the debugging
option must be disabled. You can wrap the logging calls and StrictMode set up in code that checks for debug mode.
To detect Android debug vs release mode there are two objects that expose a debug flag, ApplicationInfo (since API Level 1)
and BuildConfig (recent SDK releases).
Android Debug vs Release Using ApplicationInfo Flags
With ApplicationInfo the flags field has a debug bit. It is set via the android:debuggable attribute on the application element in
AndroidManifest.xml. Usually the android:debuggable attribute does not need to be present, it is set automatically by Eclipse
or Android Studio. The IDEs set it to true to allow the App to be debugged.
It is set to false to turn off debugging when the final APK is generated.
To override the default settings add android:debuggable to the application element. Set it to true or false as required, e.g.:
To use it perform a boolean And on flags with ApplicationInfo.FLAG_DEBUGGABLE, if the result is not zero the App is in debug mode.
Android Debug vs Release Using BuildConfig.DEBUG
BuildConfig.DEBUG is set true when the App is running in the IDE.
It is set false in the released APK unless android:debuggable is present and set true.
Therefore BuildConfig.DEBUG reflects the android:debuggable value unless android:debuggable is set false
and the App is running in the IDE, in which case it will still be true. See the table later in the article.
Code Check for Android Debug Vs Release Mode
The ApplicationInfo instance is read from the App’s context:
However to support Cupcake (API level 3) it needs to be obtained from the PackageManager:
Once the ApplicationInfo instance has be assigned the flags value can be tested for the debug setting.
Here it is being used to update a TextView:
APPLICATION ELEMENT | RELEASED APK | IN IDE |
---|---|---|
No android:debuggable | FLAG_DEBUGGABLE bit is 0 and BuildConfig.DEBUG is false | FLAG_DEBUGGABLE bit is 1 and BuildConfig.DEBUG is true |
android:debuggable=”true” | FLAG_DEBUGGABLE bit is 1 and BuildConfig.DEBUG is true | FLAG_DEBUGGABLE bit is 1 and BuildConfig.DEBUG is true |
android:debuggable=”false” | FLAG_DEBUGGABLE bit is 0 and BuildConfig.DEBUG is false | FLAG_DEBUGGABLE bit is 0 and BuildConfig.DEBUG is true |
Here’s the debugging settings in action. First no android:debuggable attribute is present and the code is running in the IDE,
or android:debuggable=”true” and the code is running in the IDE or in a released APK:
The same code running in a signed APK with no android:debuggable or it is present and set to false:
And now running from the IDE with the flag manually set to falseusing <application android:debuggable=”false”…:
Source Code
Here is the full source code used to generated the above screens. First the screen layout XML (activity_main.xml):
Here’s the associated strings.xml:
And the Java code:
Conclusion
To detect if code is running in the IDE test BuildConfig.DEBUG for true.
To detect if code is configured for debugging, whether running in the IDE or not, test ApplicationInfo flags
usingApplicationInfo.FLAG_DEBUGABBLE.
(See the Android Graphics Resources page for a bug icon.)
'IT_Programming > Android_Java' 카테고리의 다른 글
[Android] MediaPlayer with SurfaceHolder (0) | 2014.08.16 |
---|---|
ListView Header에 Viewpager 추가 (0) | 2014.08.11 |
[Android] activity-alias 태그를 사용하는 좋은 예. (0) | 2014.08.06 |
Android Custom State 만들기. (0) | 2014.08.06 |
Android RenderScript Blur (0) | 2014.08.06 |