Коли ADT встановлює BuildConfig.DEBUG на значення false?

У новітній версії ADT (r17) додається створена константа, BuildConfig.DEBUGяка встановлюється відповідно до типу збірки. Проблема в тому, що вона ніколи не встановлена ​​на помилку, я очікував, що вона зміниться, виконуючи "Інструменти Android -> Експортний підписаний пакет програм", але це не для мене.

Тож як я можу змінити тип збірки?

Додана функція, яка дозволяє запускати деякий код лише в режимі налагодження. Тепер збірки генерують клас під назвою BuildConfig, що містить константу DEBUG, яка автоматично встановлюється відповідно до типу складання. Ви можете перевірити константу (BuildConfig.DEBUG) у своєму коді для запуску функцій лише для налагодження

В даний час ви можете отримати правильну поведінку, відключивши функцію "Будувати автоматично", очистити проект і потім експортувати через "Інструменти Android -> Експортувати підписаний пакет програм". При запуску програма BuildConfig.DEBUGповинна бути помилковою.

З програмою Eclipse я завжди відключаю опцію "Створювати автоматично" перед експортом програми у випуску. Потім я прибираю проект і експортую. Інакше він починає компілювати в режимі налагодження, і тоді значення 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
}

Рекомендую очистити після переключення збірки налагодження / випуску.

Не працює належним чином:

Випуск 27940 : BuildConfig.DEBUG "true" для експортованого пакету додатків

Розчаровує те, що вони іноді випускають функції баггі.

Це працює, але зауважте, що файл коду ніколи не змінюється, навіть при експорті підписаного файлу. Експортний процес змінює значення цієї змінної в БРЕХНЯ, що може дати вам помилкове враження , що він не працює. Я перевірив це за допомогою операторів реєстрації на зразок

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

Під час тестування мої записи журналів більше не дають результатів.

Перевірте imports, інколи BuildConfig ненавмисно імпортується з будь-якого класу бібліотеки. Наприклад:

import io.fabric.sdk.android.BuildConfig;

У цьому випадку BuildConfig.DEBUG завжди поверне помилкове значення ;

import com.yourpackagename.BuildConfig;

У цьому випадку BuildConfig.DEBUG поверне ваш реальний варіант збірки .

ps Я просто копіюю це з моєї відповіді тут: BuildConfig.DEBUG завжди помилковий, коли створює бібліотечні проекти з gradle

З підготовки до випуску :

Вимкніть журнал та налагодження

Переконайтеся, що ви відключили ведення журналу та відключили параметр налагодження перед тим, як створити програму для випуску. Ви можете відключити ведення журналу, видаливши дзвінки до методів журналу у вихідних файлах. Ви можете відключити налагодження, видаливши атрибут android: debuggable з тегу у вашому файлі маніфесту, або встановивши атрибут android: debuggable на значення false у вашому файлі маніфесту. Також видаліть будь-які файли журналу або статичні тестові файли, створені у вашому проекті.

Також слід видалити всі виклики відстеження налагодження, які ви додали до свого коду, такі як виклики методу startMethodTracing () та stopMethodTracing ().

Більше інформації - за посиланням.

Рішення для мене:

1. Проект -> Будувати автоматично
2. Проект -> Очистити
3. Проект -> Побудувати
4. Експорт програми Android

Це робота в r20

Я хотів би запропонувати просте вирішення, якщо ви використовуєте proguard під час експорту APK.

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

З цим вам не потрібно стосуватися жодних непотрібних обчислень String, що переходять до журналу налагодження, на який @Jeremyfa вказував. Обчислення просто видаляються при складанні випусків.

Таким чином, вирішення для BuildConfig.DEBUG використовує таку ж функцію proguard, як наступна.

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опції, оскільки це не залежить від індивідуального налаштування IDE розробника, але зберігається як закріплений файл, який спільним для розробників.

Не працює належним чином, наскільки я зрозумів ( випуск Android 22241 )

У мене виникли проблеми з проектом (робота з Eclipse), що ця константа не була встановлена ​​на істину під час експорту підписаного APK мого проекту :(

Хочеться почути, що це працює, хоча

хороший спосіб - це створити власний клас:

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

}

Я бачив якусь дивну поведінку, пов'язану з тим, коли значення в BuildConfig встановлюються на їх кінцеві значення. Це може мати щось спільне з вашою проблемою.

Просте пояснення полягає в тому, що значення за замовчуванням встановлюються спочатку перед запуском Proguard, потім після запуску Proguard файл BuildConfig відновлюється з відповідними значеннями. Однак Proguard вже оптимізував ваш код до цього моменту, і у вас є проблеми.

Ось помилка, яку я створив проти Gradle. https://code.google.com/p/android/isissue/detail?id=182449