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

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

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

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

Solutions Collecting From Web of "Когда ADT устанавливает значение BuildConfig.DEBUG в false?"

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

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

Выпуск 27940 : 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 } 

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

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

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

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

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

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

Это работа в r20

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

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

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

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

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

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

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

 import io.fabric.sdk.android.BuildConfig; 

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

 import com.yourpackagename.BuildConfig; 

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

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

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

У меня были некоторые проблемы с проектом (работа с Eclipse), эта константа не была установлена ​​в true при экспорте подписанного 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/issues/detail?id=182449