BuildConfig.DEBUG ist immer falsch, wenn Bibliotheksprojekte mit gradle erstellt werden

BuildConfig.DEBUG funktioniert nicht (= logisch auf false gesetzt), wenn ich meine App im Debug-Modus ausführe. Ich benutze Gradle zum Bauen. Ich habe ein Bibliotheksprojekt, in dem ich diese Prüfung durchführe. BuildConfig.java sieht im Build-Debug-Ordner folgendermaßen aus:

/** Automatically generated the file. DO NOT MODIFY */
package common.myProject;

public final class BuildConfig {
    public static final boolean DEBUG = Boolean.parseBoolean("true");

}

und im Release-Ordner:

public static final boolean DEBUG = false;

sowohl im Bibliotheksprojekt als auch im Anwendungsprojekt.

Ich habe versucht, dies zu umgehen, indem ich eine Variable überprüft habe, die eine Klasse meines Projekts ist. Diese Klasse erbt von der Bibliothek und startet beim Start.

<application
        android:name=".MyPrj" ...

Dies führt zu einem weiteren Problem: Ich verwende meine DEBUG-Variable in einem DataBaseProvider, der vor der Anwendungsklasse ausgeführt wird, und sie wird aufgrund dieses Fehlers nicht ordnungsgemäß ausgeführt.

Dies ist das erwartete Verhalten dafür.

Bibliotheksprojekte veröffentlichen ihre Release-Varianten nur zum Verbrauch durch andere Projekte oder Module.

Wir arbeiten daran, dies zu beheben, aber dies ist nicht trivial und erfordert einen erheblichen Arbeitsaufwand.

Sie können das Problem unter https://code.google.com/p/android/issues/detail?id=52962 verfolgen

Mit Android Studio 1.1 und der Gradle-Version 1.1 ist Folgendes möglich:

Bibliothek

android {
    publishNonDefault true
}

App

dependencies {
    releaseCompile project(path: ':library', configuration: 'release')
    debugCompile project(path: ':library', configuration: 'debug')
}

Die vollständige Dokumentation finden Sie hier http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Library-Publication

EDIT :

Das Problem wurde gerade für Android Studio Gradle Version 3.0 als behoben markiert. Dort können Sie einfach verwenden implementation project(path: ':library')und es wird automatisch die richtige Konfiguration ausgewählt.

Überprüfen Sie imports, ob BuildConfig manchmal unbeabsichtigt aus einer beliebigen Bibliotheksklasse importiert wird. Beispielsweise:

import io.fabric.sdk.android.BuildConfig;

In diesem Fall gibt BuildConfig.DEBUG immer false zurück .

import com.yourpackagename.BuildConfig;

In diesem Fall gibt BuildConfig.DEBUG Ihre echte Build-Variante zurück.

Dies ist wie Phils Antwort, außer dass der Kontext nicht benötigt wird:

private static Boolean sDebug;

/**
 * Is {@link BuildConfig#DEBUG} still broken for library projects? If so, use this.</p>
 * 
 * See: https://code.google.com/p/android/issues/detail?id=52962</p>
 * 
 * @return {@code true} if this is a debug build, {@code false} if it is a production build.
 */
public static boolean isDebugBuild() {
    if (sDebug == null) {
        try {
            final Class<?> activityThread = Class.forName("android.app.ActivityThread");
            final Method currentPackage = activityThread.getMethod("currentPackageName");
            final String packageName = (String) currentPackage.invoke(null, (Object[]) null);
            final Class<?> buildConfig = Class.forName(packageName + ".BuildConfig");
            final Field DEBUG = buildConfig.getField("DEBUG");
            DEBUG.setAccessible(true);
            sDebug = DEBUG.getBoolean(null);
        } catch (final Throwable t) {
            final String message = t.getMessage();
            if (message != null && message.contains("BuildConfig")) {
                // Proguard obfuscated build. Most likely a production build.
                sDebug = false;
            } else {
                sDebug = BuildConfig.DEBUG;
            }
        }
    }
    return sDebug;
}

Um dieses Problem zu umgehen, können Sie diese Methode verwenden, bei der mithilfe von Reflektion der Feldwert aus der App (nicht aus der Bibliothek) abgerufen wird:

/**
 * Gets a field from the project's BuildConfig. This is useful when, for example, flavors
 * are used at the project level to set custom fields.
 * @param context       Used to find the correct file
 * @param fieldName     The name of the field-to-access
 * @return              The value of the field, or {@code null} if the field is not found.
 */
public static Object getBuildConfigValue(Context context, String fieldName) {
    try {
        Class<?> clazz = Class.forName(context.getPackageName() + ".BuildConfig");
        Field field = clazz.getField(fieldName);
        return field.get(null);
    } catch (ClassNotFoundException e) {
        e.printStackTrace();
    } catch (NoSuchFieldException e) {
        e.printStackTrace();
    } catch (IllegalAccessException e) {
        e.printStackTrace();
    }
    return null;
}

Um das DEBUGFeld zu erhalten, rufen Sie zum Beispiel einfach Folgendes auf Activity:

boolean debug = (Boolean) getBuildConfigValue(this, "DEBUG");

Ich habe diese Lösung auch auf dem AOSP Issue Tracker geteilt .

Nicht wirklich die richtige Methode, um zu überprüfen, ob Sie sich im Debug-Stil befinden, aber Sie können überprüfen, ob die App selbst über Folgendes debuggbar ist:

private static Boolean sIsDebuggable;

public static boolean isDebuggable(Context context) {
    if (sIsDebuggable == null)
        sIsDebuggable = (context.getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE) != 0;
    return sIsDebuggable;
}

Das Standardverhalten von Apps und Bibliotheken passt perfekt dazu.

Wenn Sie eine bessere Problemumgehung benötigen, können Sie diese stattdessen verwenden:

public static boolean isInDebugFlavour(Context context) {
    if (sDebugFlavour == null) {
        try {
            final String packageName = context.getPackageName();
            final Class<?> buildConfig = Class.forName(packageName + ".BuildConfig");
            final Field DEBUG = buildConfig.getField("DEBUG");
            DEBUG.setAccessible(true);
            sDebugFlavour = DEBUG.getBoolean(null);
        } catch (final Throwable t) {
            sDebugFlavour = false;
        }
    }
    return sDebugFlavour;
}

Mit gradle können Sie für jeden Build-Typ eine eigene BuildConfig-Klasse erstellen

public class MyBuildConfig
{
    public static final boolean DEBUG = true;
}

für /src/debug/.../MyBuildConfig.java und ...

public class MyBuildConfig
{
    public static final boolean DEBUG = false;
}

für /src/release/.../MyBuildConfig.java

Dann benutze:

if (MyBuildConfig.DEBUG)
    Log.d(TAG, "Hey! This is debug version!");

Hier ist eine andere Lösung.

1) Erstellen Sie eine Schnittstelle

public interface BuildVariantDetector {

    boolean isDebugVariant();

}

2) Verwenden Sie diese Schnittstelle für die Anwendungsklasse (Anwendungsmodul).

public class MyApplication extends Application implements BuildVariantDetector {

    @Override
    public boolean isDebugVariant() {
        return BuildConfig.DEBUG; //application (main module) Buildonfig
    }

}

3) Und dann im Bibliotheksmodul:

boolean debugVariant = ((BuildVariantDetector)getApplication()).isDebugVariant();

Wir hatten das gleiche Problem. Ich habe mir so etwas ausgedacht:

Wir haben ein SDK (Bibliothek) und ein Demo-Projekt. Die Hierarchie sieht folgendermaßen aus:

Parent
  |
  + SDK (:SDK)
  |
  + DemoApp (:DemoApp)

Für die Demo-App, die wir haben, waren :SDK:jarjarDebugund :SDK:jarjarReleasesind einige spezifische Aufgaben :SDK, die einige nachbearbeitete Gläser produzieren:

dependencies {
    debugCompile tasks.getByPath(":SDK:jarjarDebug").outputs.files
    releaseCompile tasks.getByPath(":SDK:jarjarRelease").outputs.files
    ... more dependencies ...
}

Dies funktioniert auch für mehrere buildTypesgleichzeitig erstellte. Das Debuggen ist allerdings etwas schwierig. Bitte kommentieren.

Dies ist meine Problemumgehung: Reflect BuildConfig des App-Moduls:

`public static boolean debug = isDebug ();

private static boolean isDebug() {
    boolean result = false;
    try {
        Class c = Class.forName("com.example.app.BuildConfig");
        Field f = c.getField("DEBUG");
        f.setAccessible(true);
        result = f.getBoolean(c);
    } catch (ClassNotFoundException e) {
        e.printStackTrace();
    } catch (NoSuchFieldException e) {
        e.printStackTrace();
    } catch (IllegalAccessException e) {
        e.printStackTrace();
    }
    return result;
}`

Sie können dies bei jedem der BuildTypes-Projekte versuchen:

parent.allprojects.each{ project -> android.defaultConfig.debuggable = true}

In meinem Fall habe ich das falsche importiert, BuildConfigda mein Projekt viele Bibliotheksmodule enthält. Das Update bestand darin, das richtige BuildConfigfür mein appModul zu importieren .

Arbeiten mit debuggable true in Gradle-Datei.

buildTypes {
  demo{
 debuggable true
    }
  live{
 debuggable true
    }
}

BuildConfig.DEBUG ist überhaupt nicht zuverlässig. Android hat ein intern verfügbares internes Flag bereitgestellt, das angibt, ob sich ein Build im Debug- oder Nicht-Debug-Modus befindet

(getContext().getApplicationInfo().flags &ApplicationInfo.FLAG_DEBUGGABLE) != 0) 

wird wahr sein, wenn es im Debug ist

Credits: https://medium.com/@elye.project/checking-debug-build-the-right-way-d12da1098120