Release-Debug Builds para la aplicación de Android

Question

En C++ normalmente configuraría 2 compilaciones - depuración y lanzamiento con cada uno teniendo DEBUG y RELEASE predefinidos respectivamente. Luego usaría estas definiciones para determinar valores constantes, como el registro habilitado/deshabilitado, el servidor URL y etc.

En este momento, en Java/Android comente algunas cosas antes de compilar la versión. Esa no es una buena manera, puedo decir. Puedo olvidar algo

¿Cuál es una práctica común para garantizar que no se olvide nada al crear una versión de lanzamiento (firmada) o una versión de depuración (sin firmar)?

Answer 1

No hay (por defecto) cualquier preprocesador para Java, por lo que no #ifdef cosas en tiempo de compilación. Pero si no le importa dejar depurar código en su aplicación, a continuación, se puede comprobar si la aplicación es la liberación o de depuración en tiempo de ejecución con este código:

Boolean release = (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE); 

que comprueba debuggable valor del indicador. Y dicha imagen se establece automáticamente en false para compilaciones de versión y true para compilaciones de depuración.

Si desea deshacerse de algún código de depuración, puede intentar usar ProGuard para eliminar ciertas clases o métodos. Y, por defecto, ProGuard está involucrado en el proceso de construcción solo para compilaciones de lanzamiento.

Answer 2

Si ejecuta la aplicación desde Eclipse, siempre será una depuración.

Al exportar la aplicación (Android Herramientas -> Exportar (ONU) firmaron paquete de aplicaciones)

Si desea saber si su lanzamiento de forma dinámica o de depuración, puede utilizar BuildConfig.DEBUG (Está ubicado en el gen carpeta, no sé si esto es compatible con todos los niveles de la API)

al igual que la siguiente manera:

if (BuildConfig.DEBUG) { 
    Log.d(TAG, "Text"); 
} 

Si nos fijamos en el código de bytes generados verá lo siguiente (en el modo de depuración):

public class Sample{ 

    private static final boolean LOG_ENABLED = true; 

    public static void main(String args[]){ 
     if (BuildConfig.DEBUG){ 
      System.out.println("Hello World"); 
     } 
    } 
} 

produce los siguientes códigos de bytes:

public class Sample extends java.lang.Object{ 
    public Sample(); 
     Code: 
     0: aload_0 
     1: invokespecial #1; //Method java/lang/Object."<init>":()V 
     4: return 

    public static void main(java.lang.String[]); 
     Code: 
     0: getstatic #2; //Field java/lang/System.out:Ljava/io/PrintStream; 
     3: ldC#3; //String Hello World 
     5: invokevirtual #4; //Method Java/io/PrintStream.println(Ljava/lang/String;)V 
     8: return 

} 

Y si el BuildConfig.DEBUG es falsa

public class Sample extends java.lang.Object{ 
    public Sample(); 
     Code: 
     0: aload_0 
     1: invokespecial #1; //Method java/lang/Object."<init>":()V 
     4: return 

    public static void main(java.lang.String[]); 
     Code: 
     0: return 
} 

Answer 3

que normalmente crean una clase de registro separado donde hice una variable estática de depuración. Ahora todo lo que necesito para obtener una compilación de producción es establecer esa variable DEBUG en falso.

public class Log { 
    public final static String LOGTAG = "APP NAME"; 

     public static final boolean DEBUG = true; 

     public static void v(String msg) { 
     android.util.Log.v(LOGTAG, msg); 
     } 

     public static void e(String msg) { 
     android.util.Log.e(LOGTAG, msg); 
     } 

     public static void d(String msg) { 
      android.util.Log.d(LOGTAG, msg); 
     } 
} 

Para el registro -

if(Log.DEBUG) Log.v("In some function x. Doing y."); 

Answer 4

Me enfrentaba al mismo problema que cada vez que ejecutaba el proyecto como aplicación de Android que solía abrir en el modo de depuración, pero luego el problema se solucionó.

-Si está trabajando en eclipse, debe utilizar la perspectiva de Java EE , en lugar de seleccionar la perspectiva de Java.

-Clean su aplicación. -instale la aplicación desde el dispositivo. -Reinicie su dispositivo (así para que no se almacene el caché) -Ejecutar su aplicación.

El modo de depuración no se mostrará esta vez. Copiar el apk generada en la carpeta bin y probarlo en otros dispositivos, así

Answer 5

he encontrado una manera de emular decentemente una directiva de preprocesamiento:

En mi Gradle buildTypes defino:

release { 
    buildConfigField "boolean", "isDebug", "false" 
    ... 
} 

debug { 
    buildConfigField "boolean", "isDebug", "true" 
    ... 
} 

Luego, en mi código, haga lo siguiente:

if (BuildConfig.isDebug) { 
    ... do debug stuff ... 
} 

y si es necesario, por supuesto:

else { 
    ... do release stuff ... 
} 

Ambos bloques están presentes en la debug APK, pero cuando la construcción de una versión release, Proguard es lo suficientemente inteligente como para determinar que el bloque debug se puede quitar, ya que es dependiente de un if (false) (que también se elimina de la código resultante).

debe llamar algunas clases de depuración específica del bloque debug y sólo a partir de ahí, que se quitará de la APK resultante ya que se consideran sin usar, y esto también es un punto interesante: el código no puede ser templado de alguna manera usaría ese código.

Pude determinar todo eso al consultar mis archivos de salida Proguard dump, mapping y usage.