Когда ADT устанавливает BuildConfig.DEBUG в значение false? - PullRequest
107 голосов
/ 25 марта 2012

В новейшей версии ADT (r17) была добавлена ​​сгенерированная константа BuildConfig.DEBUG, которая устанавливается в соответствии с типом сборки.У меня проблема в том, что для него никогда не устанавливается значение false, я ожидал, что оно изменится при выполнении «Инструменты Android -> Экспорт подписанного пакета приложения», но это не для меня.

Так как мне изменить тип сборки?

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

Ответы [ 11 ]

56 голосов
/ 26 апреля 2012

В настоящее время вы можете получить правильное поведение, отключив «Автоматически создавать», очистив проект, а затем экспортировав его через «Инструменты Android -> Экспортировать подписанный пакет приложения».При запуске приложения BuildConfig.DEBUG должно быть ложным.

36 голосов
/ 25 марта 2015

С Eclipse я всегда отключаю опцию «Автоматически создавать» перед экспортом приложения в выпуске.Затем я очищаю проект и экспортирую.В противном случае он начинает компилироваться в режиме отладки, и тогда значение BuildConfig.DEBUG может быть неправильным.

С Android Studio я просто добавляю свою собственную переменную в build.gradle:1007 *

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
}

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

33 голосов
/ 19 мая 2012

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

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

Обидно, что они иногда выпускают ошибочные функции.

10 голосов
/ 26 октября 2012

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

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

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

8 голосов
/ 22 сентября 2016

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

import io.fabric.sdk.android.BuildConfig;

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

import com.yourpackagename.BuildConfig;

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

ps. Я просто скопирую этот ответ из своего ответа здесь: BuildConfig.DEBUG всегда ложь при сборке проектов библиотеки с gradle

5 голосов
/ 03 июля 2012

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

  1. Проект -> Автоматическая сборка
  2. Проект -> Чистый
  3. Проект -> Сборка
  4. Приложение Project Export для Android

Это работа в r20

5 голосов
/ 26 апреля 2012

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

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

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

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

Более подробная информация доступна по ссылке.

3 голосов
/ 09 апреля 2015

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

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

Я бы предпочел использовать это для отключения опции Build Automatically, потому что это не зависит от индивидуальной настройки IDE сборщика, а поддерживается как зафиксированный файл, который используется совместно разработчиками.

1 голос
/ 20 мая 2013

хороший способ создать свой собственный класс:

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

}
1 голос
/ 25 марта 2012

Насколько я понял, работает неправильно ( Android выпуск 22241 )

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

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

...