BuildConfig.DEBUG हमेशा गलत होता है जब लाइब्रेरी प्रोजेक्ट को ग्रेडेल के साथ बनाया जाता है

Question 1

जब मैं डीबग मोड में अपना ऐप चलाता हूं तो BuildConfig.DEBUG काम नहीं कर रहा है (= तार्किक रूप से गलत पर सेट)। मैं बनाने के लिए ग्रेड का उपयोग करता हूं। मेरे पास एक पुस्तकालय परियोजना है जहां मैं यह जांच करता हूं। BuildConfig.java बिल्ड डीबग फ़ोल्डर में इस तरह दिखता है:

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

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

}

और रिलीज़ फ़ोल्डर में:

public static final boolean DEBUG = false;

दोनों पुस्तकालय परियोजना में और आवेदन परियोजना में।

मैंने एक चर की जाँच करके इसे प्राप्त करने का प्रयास किया जो कि मेरी परियोजना का एक वर्ग है। यह वर्ग लाइब्रेरी से विरासत में मिलता है और स्टार्टअप पर शुरू होता है।

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

यह एक और समस्या की ओर जाता है: यह है कि मैं एक डेटाबेसप्रॉइडर में अपने डेबग चर का उपयोग करता हूं जो कि आवेदन वर्ग से पहले चलता है, और यह इस बग के कारण ठीक से नहीं चलेगा।

Question 2

इसके लिए यह अपेक्षित व्यवहार है।

लाइब्रेरी प्रोजेक्ट केवल अन्य प्रोजेक्ट्स या मॉड्यूल द्वारा खपत के लिए अपने रिलीज़ वेरिएंट प्रकाशित करते हैं।

हम इसे ठीक करने पर काम कर रहे हैं, लेकिन यह गैर तुच्छ है और इसके लिए महत्वपूर्ण मात्रा में काम करना पड़ता है।

आप इस मुद्दे को https://code.google.com/p/android/issues/detail?id=52962 पर ट्रैक कर सकते हैं

Question 3

एंड्रॉइड स्टूडियो 1.1 के साथ और 1.1 पर ग्रेडेल संस्करण होने के साथ यह संभव है:

पुस्तकालय

android {
    publishNonDefault true
}

ऐप

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

पूरा दस्तावेज यहां पाया जा सकता है http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Library-Publication

संपादित करें :

इस मुद्दे को केवल एंड्रॉइड स्टूडियो ग्रैडल संस्करण 3.0 के लिए तय किया गया है। वहाँ आप बस का उपयोग कर सकते हैं implementation project(path: ':library')और यह स्वचालित रूप से सही कॉन्फ़िगरेशन का चयन करेगा।

Question 4

के लिए जाँच करें imports, कभी कभी BuildConfig पुस्तकालय के किसी भी वर्ग से अनजाने आयात किया जाता है। उदाहरण के लिए:

import io.fabric.sdk.android.BuildConfig;

इस मामले में BuildConfig.DEBUG हमेशा गलत लौटेगा ;

import com.yourpackagename.BuildConfig;

इस स्थिति में BuildConfig.DEBUG आपका वास्तविक बिल्ड वैरिएंट लौटाएगा ।

Question 5

यह फिल के जवाब की तरह है सिवाय इसके कि संदर्भ की आवश्यकता नहीं है:

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;
}

Question 6

वर्कअराउंड के रूप में, आप इस पद्धति का उपयोग कर सकते हैं, जो एप्लिकेशन से फ़ील्ड मान प्राप्त करने के लिए प्रतिबिंब का उपयोग करता है (पुस्तकालय नहीं):

/**
 * 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;
}

DEBUGफ़ील्ड प्राप्त करने के लिए, उदाहरण के लिए, बस इसे अपने से कॉल करें Activity:

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

मैंने इस समाधान को AOSP अंक ट्रैकर पर भी साझा किया है ।

Question 7

यदि आप डिबग फ्लेवर में हैं, तो वास्तव में यह जांचने का सही तरीका नहीं है, लेकिन आप यह जांच सकते हैं कि ऐप स्वयं के माध्यम से डीबग करने योग्य है या नहीं:

private static Boolean sIsDebuggable;

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

ऐप्स और लाइब्रेरी का डिफ़ॉल्ट व्यवहार पूरी तरह से मेल खाएगा।

यदि आपको बेहतर वर्कअराउंड की आवश्यकता है, तो आप इसके बजाय इसका उपयोग कर सकते हैं:

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;
}

Question 8

आप ग्रेड का उपयोग करके प्रत्येक बिल्ड प्रकार के लिए अपना स्वयं का BuildConfig वर्ग बना सकते हैं

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

के लिए /src/debug/.../MyBuildConfig.java और ...

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

for /src/release/..//yBuildConfig.java

फिर उपयोग करें:

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

Question 9

यहाँ एक और उपाय है।

1) एक इंटरफ़ेस बनाएँ

public interface BuildVariantDetector {

    boolean isDebugVariant();

}

2) एप्लिकेशन क्लास (एप्लायंस मॉड्यूल) पर इस इंटरफेस का उपयोग करें

public class MyApplication extends Application implements BuildVariantDetector {

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

}

3) और फिर पुस्तकालय मॉड्यूल में:

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

Question 10

हम भी यही समस्या थी। मैं कुछ इस तरह से आया:

हमारे पास एक एसडीके (पुस्तकालय) और एक डेमो प्रोजेक्ट है, पदानुक्रम इस तरह दिखता है:

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

हमारे पास मौजूद डेमो ऐप के लिए, कुछ पोस्ट-प्रोसेस्ड जार बनाने के लिए कुछ विशिष्ट कार्य हैं :SDK:jarjarDebugऔर :SDK:jarjarReleaseहैं :SDK:

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

यह buildTypesएक ही बार में निर्मित कई के लिए भी काम करता है । डिबगिंग हालांकि थोड़ा मुश्किल है। कृपया टिप्पणी करें।

Question 11

यह मेरा काम है: एप्लिकेशन मॉड्यूल के BuildConfig को प्रतिबिंबित करें:

`सार्वजनिक स्थैतिक बूलियन डिबग = इसबग ();

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;
}`

Question 12

आप प्रत्येक प्रोजेक्ट बिल्ड पर यह प्रयास कर सकते हैं:

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

Question 13

मेरे मामले में मैं गलत आयात कर रहा था BuildConfigक्योंकि मेरी परियोजना में कई पुस्तकालय मॉड्यूल हैं। फिक्स BuildConfigमेरे appमॉड्यूल के लिए सही आयात करने के लिए था ।

Question 14

ग्रेडिंग फ़ाइल में डीबग करने योग्य सत्य के साथ कार्य करना।

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

Question 15

BuildConfig.DEBUG बिल्कुल भी विश्वसनीय नहीं है, Android ने एक आंतरिक ध्वज प्रदान किया है जो विश्व स्तर पर उपलब्ध है, यह दर्शाता है कि एक निर्माण डिबग या गैर-डीबग मोड में है

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

यदि यह डिबग में है तो सच होगा

क्रेडिट: https://medium.com/@elye.project/checking-debug-build-the-right-way-d12da1098120