Когда ADT устанавливает значение BuildConfig.DEBUG в false?

Ответ 1

В настоящее время вы можете получить правильное поведение, отключив "Build Automatically", очистив проект, а затем экспортировав его через "Android Tools → Export Signed Application Package". При запуске приложения BuildConfig.DEBUG должно быть ложным.

Ответ 2

Это не работает должным образом:

Проблема 27940: BuildConfig.DEBUG является "истинным" для экспортированного пакета приложений

Это разочаровывает, что они иногда выпускают багги.

Ответ 3

С Eclipse я всегда отключу опцию "Build Automatically" перед экспортом приложения в выпуске. Затем я очищаю проект и экспортирую. В противном случае он начинает компиляцию в режиме отладки, а затем значение 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
}

Я рекомендую очищать после переключения сборки отладки/выпуска.

Ответ 4

Это действительно работает, но обратите внимание, что файл кода никогда не изменяется даже при экспорте подписанного файла. Процесс экспорта изменяет значение этой переменной на false, что может дать ложное впечатление, что оно не работает. Я тестировал это с помощью протоколирующих операторов, например

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

При тестировании мои операторы Log больше не производят никакого вывода.

Ответ 5

От Подготовка к выпуску:

Отключить ведение журнала и отладки

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

Кроме того, вы должны удалить все вызовы трассировки Debug, которые вы добавили в свой кода, например метод startMethodTracing() и stopMethodTracing() вызовы.

Дополнительная информация по ссылке.

Ответ 6

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

• Проект → Автоматическая сборка
• Проект → Очистка
• Project → Build
• Проект Экспорт приложений для Android

Работает в r20

Ответ 7

Я хотел бы предложить простой обходной путь, если вы используете 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-объекта компоновщика, но поддерживается как преданный файл, который совместно используется разработчиками.

Ответ 8

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

import io.fabric.sdk.android.BuildConfig;

В этом случае BuildConfig.DEBUG всегда будет возвращать false;

import com.yourpackagename.BuildConfig;

В этом случае BuildConfig.DEBUG вернет ваш вариант реальной сборки.

p.s Я просто копирую это из моего ответа здесь: BuildConfig.DEBUG всегда false при создании проектов библиотеки с помощью gradle

Ответ 9

Не работает должным образом, насколько я понял (Android-вопрос 22241)

У меня были некоторые проблемы с проектом (работа с Eclipse), эта константа не была установлена ​​в true при экспорте подписанного APK моего проекта: (

Хотелось бы услышать, что это работает, хотя

Ответ 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
        );
}

}

Ответ 11

Я видел странное поведение, связанное с тем, когда значения в BuildConfig установлены в их окончательные значения. Это может иметь какое-то отношение к вашей проблеме.

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

Вот ошибка, которую я создал против Gradle. https://code.google.com/p/android/issues/detail?id=182449