My recommended technique for including debugging code is not to try to identify the execution environment, but simply to build differently.
For example, create a class:
Code:
public class Debug {
public static final boolean ON = true;
}
Then...
Code:
if (Debug.ON) {
// do some debug stuff
}
This way, when you build with Debug.ON = false, the сompiler will automatically remove the debug code from the .class files (reducing code size).
If you want something more exotic, extend the technique...
Code:
public class Debug {
// don't change these
public static final int OFF = 0;
public static final int EMULATOR = 1;
public static final int DEVICE = 2;
// change this to select build options
public static final int MODE = OFF;
}
Code:
if (Debug.MODE == Debug.EMULATOR) {
// do some emulator-only debug stuff
}
Rules:
1. If a variable is "static final", has a primitive type (like int or boolean), and is initialized from a literal (like "5" or "true") (or an expression that can be computed at compile time), then it's value will be in-lined by the compiler.
2. Where an "if" expression is a constant "false", then the "if" and its contents will be removed by the compiler.
3. Where an "if" expression is a constant "true", the "if" and its expression will be removed, but the body will be left alone.
4. Unreferenced classes (such as those that contain only constants, like my Debug example classes) will be removed from the build by Proguard. If any debugging code has been excluded by rule (2) above, then any methods (like assertion or debug output methods) that become now unreferenced will be removed by Proguard.
Graham.