java - studio - google play developer console

Release-Debug Builds para Android

Question

En C ++, normalmente configuraría 2 compilaciones: depuración y liberación, cada una con DEBUG y RELEASE predefinidas, respectivamente. Luego utilizaría estas definiciones para determinar valores constantes, como el registro habilitado / deshabilitado, el servidor URL, 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 asegurarse de 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) ningún preprocesador para Java, por lo que no hay elementos #ifdef en tiempo de compilación. Pero si no le importa dejar el código de depuración en su aplicación, entonces puede verificar si la aplicación es de lanzamiento o depuración en tiempo de ejecución con este código:

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

que verifica el valor del indicador debuggable . Y dicho flad se establece automáticamente en false para las compilaciones de versiones 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

Normalmente creo una clase de registro separada donde configuro una variable DEBUG estática. 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 3

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

Cuando exporta la aplicación (Herramientas de Android -> Paquete de aplicaciones de exportación (no))

Si quieres saber dinámicamente si está disponible o depurar, puedes usar BuildConfig.DEBUG (Está ubicado en la carpeta gen, no sé si esto es compatible con todos los niveles de la API)

Como sigue:

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

Si observas los bytecodes generados, verás lo siguiente (en 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 bytecodes:

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 BuildConfig.DEBUG es falso

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 4

Estaba enfrentando el mismo problema que cada vez que ejecutaba el proyecto como una 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 su lugar, simplemente seleccione la perspectiva de Java.

Limpia tu aplicación -desinstalar la aplicación desde el dispositivo. -Reinicie su dispositivo (así para que no se almacene el caché) -Exceda su aplicación.

El modo de depuración no aparecerá esta vez. Copie el apk generado en su carpeta bin y pruébelo también en otros dispositivos

Answer 5

Encontré una forma 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, hago 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 al construir una versión de release , Proguard es lo suficientemente inteligente como para determinar que el bloque de debug se puede eliminar ya que es dependiente de un if (false) (que también se elimina del código resultante).

Si llama algunas clases específicas de debug bloque de debug y solo desde allí, se eliminarán de la APK resultante, ya que se consideran no utilizadas , y esto también es un punto interesante: su código no se puede atenuar de una manera que usaría ese código.

Pude determinar todo eso al verificar mi dump , mapping y usage los archivos de salida de Proguard.