ADT ने BuildConfig.DEBUG को कब सेट किया है?

Question

ADT (r17) के नवीनतम संस्करण में एक उत्पन्न स्थिरांक जोड़ा गया था BuildConfig.DEBUGजो बिल्ड प्रकार के अनुसार सेट किया गया है। मेरे पास जो समस्या है वह यह है कि यह कभी भी गलत नहीं होता है, मुझे उम्मीद थी कि "Android Tools -> Export Signed Application Package" करते समय इसे बदल दिया जाएगा लेकिन यह मेरे लिए नहीं है।

तो मैं बिल्ड प्रकार कैसे बदलूं?

एक सुविधा है कि आप केवल डिबग मोड में कुछ कोड चलाने के लिए अनुमति देता है। बिल्ड अब एक वर्ग उत्पन्न करता है, जिसे बिल्डकॉन्फिग कहा जाता है जिसमें एक डेबग स्थिरांक होता है जो आपके बिल्ड प्रकार के अनुसार स्वचालित रूप से सेट होता है। डिबग-ओनली फ़ंक्शंस को चलाने के लिए आप (BuildConfig.DEBUG) अपने कोड में निरंतर जांच कर सकते हैं

Comments

BuildConfig.java एंड्रॉइड बिल्ड टूल्स द्वारा स्वचालित रूप से उत्पन्न होता है, और इसे जीन फ़ोल्डर में रखा जाता है। हस्ताक्षरित APK में BuildConfig.DEBUG = false होना चाहिए। यह आपके लिए कोई समस्या नहीं होनी चाहिए। आपको मैन्युअल रूप से उस फ़ाइल को नहीं छूना चाहिए ...

— इगोरगानपोलस्की

यदि आप इस झंडे को जारी करने के लिए ग्रेडेल का उपयोग करते हैं तो यह 100% विश्वसनीय है। तो जब आप एक ./gradlew को इकट्ठा करते हैं तो उसके वास्तविक को इकट्ठा करते हैं और जब उसके झूठे को इकट्ठा करते हैं।

— स्लोट

Answer 1

वर्तमान में आप "बिल्ड ऑटोमेटिकली" डिसेबल करके, प्रोजेक्ट को साफ़ करके और फिर "एंड्रॉइड टूल्स -> एक्सपोर्ट साइन एप्लीकेशन एप्लीकेशन पैकेज" के द्वारा सही व्यवहार प्राप्त कर सकते हैं। जब आप एप्लिकेशन चलाते हैं तो BuildConfig.DEBUGगलत होना चाहिए।

Comments

टूट भी गया। जिसमें सभी Log.d संदेश प्रदर्शित करने का परिणाम है, जिसे इस ध्वज द्वारा छोड़ा जाना चाहिए। ps। बग रिपोर्ट कहां दर्ज करें?

— tomi

मेरा हमेशा झूठा होता है, यहां तक ​​कि जब डिबगिंग

— 3

Answer 2

ग्रहण के साथ , मैं हमेशा रिलीज़ में ऐप को निर्यात करने से पहले "बिल्ड ऑटोमेटिकली" विकल्प को निष्क्रिय कर देता हूं। फिर मैं परियोजना और निर्यात को साफ करता हूं। अन्यथा यह डिबग मोड में संकलन करना शुरू कर देता है, और फिर BuildConfig.DEBUG का मान गलत हो सकता है।

Android Studio के साथ , मैं build.gradle में केवल अपना स्वयं का कस्टम चर जोड़ता हूं:

buildTypes {
    debug {
        buildConfigField "Boolean", "DEBUG_MODE", "true"
    }
    release {
        buildConfigField "Boolean", "DEBUG_MODE", "false"
    }
}

जब मैं इस परियोजना का निर्माण, BuildConfig.java निम्नानुसार उत्पन्न होता है:

public final class BuildConfig {
  // Fields from build type: debug
  public static final Boolean DEBUG_MODE = true;
}

फिर मेरे कोड में मैं उपयोग कर सकता हूं:

if (BuildConfig.DEBUG_MODE) {
    // do something
}

मैं डिबग / रिलीज़ बिल्ड स्विच करने के बाद सफाई करने की सलाह देता हूं।

Comments

यह समाधान सबसे अच्छा है अगर आप प्रूफ़ का उपयोग करते हैं क्योंकि यह एक शाब्दिक मूल्य के साथ एक निरंतर उत्पन्न करेगा, इसलिए आपका डिबग कोड पूरी तरह से रिलीज़ मोड में बाइनरी से हटा दिया जाएगा।

— विक्टर लेरटे

Answer 3

यह ठीक से काम नहीं करता है:

जारी 27,940 : BuildConfig.DEBUG निर्यात आवेदन पैकेज के लिए "सही" है

यह निराशाजनक है कि वे कभी-कभी छोटी सुविधाओं को जारी करते हैं।

Comments

कृपया ऊपर बताए गए मुद्दे के लिंक पर जाएं और यदि आप चाहते हैं कि इसे ठीक कर दिया जाए।

— गय

Answer 4

यह काम करता है, लेकिन ध्यान दें कि कोड फ़ाइल कभी नहीं बदलती है, यहां तक ​​कि हस्ताक्षरित फ़ाइल को निर्यात करते समय भी। निर्यात प्रक्रिया इस चर के मूल्य को असत्य में बदल देती है, जिससे आपको गलत धारणा मिल सकती है कि यह काम नहीं कर रहा है। मैंने जैसे लॉगिंग स्टेटमेंट के साथ यह परीक्षण किया

if (com.mypackage.BuildConfig.DEBUG)
            Log.d(TAG, location.getProvider() + " location changed");

परीक्षण करते समय, मेरे लॉग स्टेटमेंट अब कोई आउटपुट नहीं देते हैं।

Comments

आपने वास्तव में क्या किया?

— pbhowmick

मैंने BuildConfig.DEBUG के उदाहरणों को com.mypackage.BuildConfig.DEBUG में बदल दिया, फिर ऐप को फिर से चालू करें ... और यह अभी भी हर समय सच है। शायद मैंने आपके सुझाव को गलत समझा।

— क्रिस रे

मैं जो कह रहा हूं वह यह है कि कोड नहीं बदलेगा। हालाँकि, com.mypackage.BuildConfig.DEBUG झूठी पोस्ट संकलन के लिए सेट किया जाएगा। ऊपर के रूप में एक परीक्षण लॉगिंग स्टेटमेंट का प्रयास करें (लॉग करने के लिए एक मनमाना स्ट्रिंग चुनें), निर्यात करें और फिर इसे चलाएं। देखें कि क्या adb लॉगिंग स्टेटमेंट प्रदर्शित करता है। मुझे एक शर्त लेनी होगी कि adb उस लॉगिंग स्टेटमेंट को रिपोर्ट नहीं करेगा, यह दर्शाता है कि DEUBUG को झूठा सेट किया गया है।

— pbhowmick

मुझे यकीन नहीं है कि मुझे पता है कि "कोड" के बारे में आपका क्या मतलब है ... हालांकि, मैं कहूंगा कि एपीके को निर्यात करने से पहले एक साफ-सुथरा काम करना (जैसा कि स्वीकृत उत्तर में सुझाव दिया गया है) दोनों बिल्डकॉन्फ़िग डीबग और com.mypackage.BuildChffig बनाया .DEBUG रिपोर्ट अपेक्षा के अनुरूप झूठी है।

— क्रिस राय

आपको यह मिला। यही अपेक्षित व्यवहार है।

— pbhowmick

Answer 5

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

import io.fabric.sdk.android.BuildConfig;

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

import com.yourpackagename.BuildConfig;

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

पी एस मैं सिर्फ अपने जवाब में से एक को यहां कॉपी करता हूं: बिल्डकॉनफिग डीबीबग हमेशा गलत होता है जब लाइब्रेरी प्रोजेक्ट को ग्रेडेल के साथ बनाया जाता है

Comments

हाँ, मेरे लिए यह गलती से आयात किया गया था android.support.compat। मुझे लगता है कि सिर्फ एक अलग नाम के साथ अपने स्वयं के क्षेत्र को परिभाषित करने का एक और कारण है।

— arekolek

Answer 6

रिलीज की तैयारी से :

लॉगिंग और डीबगिंग को बंद करें

रिलीज से पहले अपने आवेदन को बनाने से पहले सुनिश्चित करें कि आप लॉगिंग को निष्क्रिय कर दें और डिबगिंग विकल्प को निष्क्रिय कर दें। आप अपने स्रोत फ़ाइलों में लॉग विधियों में कॉल हटाकर लॉगिंग को निष्क्रिय कर सकते हैं। आप डिबगिंग को अक्षम कर सकते हैं: अपनी प्रकट फ़ाइल में टैग से डीबग करने योग्य विशेषता, या एंड्रॉइड सेट करके: डिबग करने योग्य विशेषता को अपनी मैनिफ़ेस्ट फ़ाइल में गलत करने के लिए। इसके अलावा, अपने प्रोजेक्ट में बनाई गई किसी भी लॉग फाइल या स्टेटिक टेस्ट फाइल को हटा दें।

इसके अलावा, आपको सभी डीबग ट्रेसिंग कॉल्स को हटा देना चाहिए जिन्हें आपने अपने कोड में जोड़ा था, जैसे कि startMethodTracing () और stopMethodTracing () मेथड कॉल्स।

अधिक जानकारी लिंक का अनुसरण कर रही है।

Comments

मैंने सोचा था कि यह प्रक्रिया अब बिल्ड टाइम पर स्वचालित रूप से होती है: developer.android.com/tools/sdk/tools-notes.html

— IgGanapolsky

संकलन-समय त्रुटि के कारण: «डीबग मोड को हार्डकोड करने से बचें; इसे छोड़ने से डिबग और रिलीज को स्वचालित रूप से एक »असाइन करने की अनुमति मिलती है

— निकिता बोसिक

Answer 7

मेरे लिए समाधान:

1. परियोजना -> स्वचालित रूप से बनाएँ
2. प्रोजेक्ट -> स्वच्छ
3. प्रोजेक्ट -> बिल्ड
4. परियोजना निर्यात Android आवेदन

यह r20 में काम करता है

Comments

यह मेरे लिए अभी काम कर रहा है (नवीनतम ADT मुझे लगता है का उपयोग करके)। शायद सफाई ने इसे ठीक कर दिया, निश्चित नहीं।

— जॉनी

Answer 8

अगर आप एपीके एक्सपोर्ट के दौरान प्रोगार्ड का इस्तेमाल करते हैं तो मैं एक साधारण वर्क प्रपोज करना चाहूंगा।

रिलीज़ मोड में विशिष्ट कार्यों के लिए कॉल को हटाने का एक तरीका Proguard प्रदान करता है। डिबगिंग लॉग के लिए किसी भी कॉल को निम्नलिखित सेटिंग के साथ हटाया जा सकता है proguard-project.txt।

# Remove debug logs
-assumenosideeffects class android.util.Log {
    public static *** d(...);
    public static *** v(...);
}

और अनुकूलन सेटिंग में project.properties।

proguard.config=${sdk.dir}/tools/proguard/proguard-android-optimize.txt:proguard-project.txt

इसके साथ, आपको किसी भी अनावश्यक स्ट्रिंग संगणना को डिबग लॉग में भेजने की चिंता करने की आवश्यकता नहीं है, जिस पर @Jeremyfa ने बताया। रिलीज बिल्ड में कम्प्यूटेशंस को हटा दिया गया है।

तो BuildConfig.DEBUG के लिए वर्कअराउंड निम्नलिखित की तरह एक ही सुविधा का उपयोग करता है।

public class DebugConfig {

    private static boolean debug = false;

    static {
        setDebug(); // This line will be removed by proguard in release.
    }

    private static void setDebug() {
        debug = true;
    }

    public static boolean isDebug() {
        return debug;
    }
}

और में सेटिंग के बाद proguard-project.txt।

-assumenosideeffects class com.neofect.rapael.client.DebugConfig {
    private static *** setDebug();
}

मैं इस Build Automaticallyविकल्प को अक्षम करने के लिए इसका उपयोग करना पसंद करूंगा , क्योंकि यह बिल्डर की व्यक्तिगत आईडीई सेटिंग पर निर्भर नहीं करता है, लेकिन इसे प्रतिबद्ध फ़ाइल के रूप में बनाए रखा जाता है जो डेवलपर्स के बीच साझा की जाती हैं।

Answer 9

जहां तक ​​मुझे समझ में नहीं आया ठीक से काम नहीं करता है ( एंड्रॉइड इश्यू 22241 )

मुझे एक प्रोजेक्ट (एक्लिप्स के साथ काम करना) पर कुछ परेशानी हुई, जब मेरी परियोजना के एक हस्ताक्षरित APK को निर्यात करते समय निरंतर सही नहीं था ...

हालांकि यह काम करता है सुनने के लिए प्यार करता हूँ

Comments

यह r17 में तय किया जाना चाहिए था, इसके बग ट्रैकर में चिह्नित किया गया था।

— २२:०२ पर smith324

वास्तव में जब निर्यात (चींटी में काम करता है) में एडीटी में रिलीज मोड में लिबास संकलित नहीं किया जाता है। मैंने code.google.com/p/android/issues/detail?id=27940

— Xavier Ducrohet

@ Xav इसे देखने के लिए धन्यवाद, मैं आपको अब वादा करना बंद कर दूंगा। यह वास्तव में मुख्य परियोजना थी जिसके साथ मुझे समस्या थी (आश्रित पुस्तकालय को नहीं देखें)। अगर मैं एक ठोस परीक्षण मामला बना सकता हूँ तो मैं इसे उसी मुद्दे के तहत बग ट्रैकर में पोस्ट करूँगा।

— smith324

Answer 10

एक अच्छा तरीका अपनी कक्षा बना रहा है:

public class Log {

public static void d(String message) {
    if (BuildConfig.DEBUG)
        android.util.Log.d(
            "[" + (new Exception().getStackTrace()[1].getClassName()) + "]",
            "{" + (new Exception().getStackTrace()[1].getMethodName()) + "} "
            + message
        );
}

}

Comments

इस पद्धति के साथ समस्या यह है कि, जब DEBUG गलत है, तो घटना, java अभी भी प्रत्येक स्ट्रिंग को आपके कस्टम वर्ग में इसे पास करने के लिए गणना करेगा। अगर (DEBUG) Log.d (...) कम सुरुचिपूर्ण है, लेकिन अधिक कुशल है।

— जेरेमीफा

Answer 11

मैंने कुछ अजीब व्यवहार देखे हैं, जब BuildConfig के मूल्यों को उनके अंतिम मूल्यों पर सेट किया जाता है। यह आपके मुद्दे के साथ कुछ करने के लिए हो सकता है।

सरल व्याख्या यह है कि डिफ़ॉल्ट मान शुरू में प्रागार्ड चलाने से पहले सेट किए जाते हैं, फिर प्रोगार्ड के चलने के बाद, बिल्डकॉन्फिग फ़ाइल को उचित मूल्यों के साथ पुनर्जीवित किया जाता है। हालाँकि, प्रागार्ड ने पहले ही इस बिंदु से आपके कोड को अनुकूलित कर लिया है और आपके पास मुद्दे हैं।

यहाँ एक बग है जिसे मैंने ग्रैडल के खिलाफ बनाया है। https://code.google.com/p/android/issues/detail?id=182449