Когда ADT устанавливает BuildConfig.Отладка до false?
в последней версии ADT (r17) была добавлена сгенерированная константа BuildConfig.DEBUG
Это устанавливается в соответствии с типом сборки. Проблема у меня есть в том, что он никогда не установлен в false, я ожидал, что он изменится при выполнении "Android Tools -> Export Signed Application Package", но это не для меня.
Итак, как мне изменить тип сборки?
добавлена функция, которая позволяет запускать код только в режиме отладки. Сборки теперь генерируют класс BuildConfig содержащий отладочную константа, которая автоматически устанавливается в соответствии с типом сборки. Вы можно проверить (BuildConfig.DEBUG) константа в коде для запуска отладка-только функции
11 ответов:
В настоящее время вы можете получить правильное поведение, отключив "построить автоматически", очистив проект, а затем экспортировать с помощью "Android Tools -> Export Signed Application Package". При запуске приложения
BuildConfig.DEBUG
должно быть false.
С затмение, Я всегда отключаю опцию "построить автоматически" перед экспортом приложения в релизе. Затем я очищаю проект и экспортирую. В противном случае он начинает компиляции в режиме отладки, а затем значение BuildConfig.Отладка может быть неправильной.
С Android Studio, Я просто добавляю свою собственную пользовательскую переменную в сборку.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 }
Я рекомендую очистить после переключения debug/release build.
Он не работает правильно:
вопрос 27940: BuildConfig.DEBUG-это "true" для экспортированного пакета приложений
Это разочаровывает, что они иногда выпускают багги функции.
он работает, но обратите внимание, что файл кода никогда не изменяется, даже при экспорте подписанного файла. Экспорт процесс изменяет значение этой переменной на false, что может создать ложное впечатление, что она не работает. Я проверил это с помощью операторов регистрации, таких как
if (com.mypackage.BuildConfig.DEBUG) Log.d(TAG, location.getProvider() + " location changed");
при тестировании мои операторы журнала больше не производят никаких выходных данных.
проверить
imports
, иногда BuildConfig импортируется из любого класса библиотеки непреднамеренно. Например:import io.fabric.sdk.android.BuildConfig;
В этом случае BuildConfig.Отладка всегда будет возвращать ложные;
import com.yourpackagename.BuildConfig;
В этом случае BuildConfig.Отладка вернуть реальный вариант сборки.
p. s Я просто копирую это из моего ответа здесь:BuildConfig.Отладка всегда false при построении библиотечные проекты с gradle
отключить ведение журнала и отладку
убедитесь, что вы отключили ведение журнала и отключили параметр отладки перед созданием приложения для выпуска. Вы можете деактивировать ведение журнала путем удаления вызовов методов журнала в исходных файлах. Вы можете отключите отладку, удалив атрибут android: debuggable из тег в файле манифеста, или путем установки android: отладочный атрибут false в файле манифеста. Также, удалите все файлы журналов или статические тестовые файлы, созданные в вашем компьютере. проект.
кроме того, вы должны удалить все вызовы трассировки отладки, которые вы добавили в свой код, например startMethodTracing() и stopMethodTracing () метод звонки.
более подробная информация по ссылке.
решение для меня:
- Проект - > Построить Автоматически
-3-->Очистить -3-->Построить- экспорт проекта 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
при этом вам не нужно беспокоиться о каких-либо ненужных строковых вычислениях, передаваемых в журнал отладки, на который указал @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), эта константа не была установлена в 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 уже оптимизировал ваш код к этому моменту, и у вас есть проблемы.
вот ошибка, которую я создал против Градля. https://code.google.com/p/android/issues/detail?id=182449