Ответы:
Самое простое и лучшее долгосрочное решение - использовать BuildConfig.DEBUG
. Это boolean
значение true
для отладочной сборки, в false
противном случае:
if (BuildConfig.DEBUG) {
// do something for a debug build
}
Поступали сообщения о том, что это значение не является на 100% надежным в сборках на основе Eclipse, хотя лично я не сталкивался с проблемой, поэтому не могу сказать, насколько серьезной является проблема.
Если вы используете Android Studio или Gradle из командной строки, вы можете добавить свои собственные вещи BuildConfig
или иным образом настроить типы debug
и release
сборки, чтобы помочь различать эти ситуации во время выполнения.
Решение от Illegal Argument основано на значении android:debuggable
флага в манифесте. Если именно так вы хотите отличить «отладочную» сборку от «выпускной», то по определению это лучшее решение. Однако имейте в виду, что в будущем debuggable
флаг действительно будет независимой концепцией от того, что Gradle / Android Studio считает «отладочной» сборкой. Любой тип сборки может установить debuggable
флаг в любое значение, которое имеет смысл для этого разработчика и для этого типа сборки.
public static final boolean DEBUG = Boolean.parseBoolean("true");
отладочную сборку. Хотя это странно способ набора DEBUG
к true
, он должен работать. Если вы видите это в одном из тестовых выпусков 1.3.0 или если у вас есть воспроизводимый тестовый пример для 1.2.2, пожалуйста, сообщите об этом . Я не вижу каких-либо нерешенных проблем, сообщающих об этой проблеме.
Попробуйте следующее:
boolean isDebuggable = ( 0 != ( getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE ) );
Котлин:
val isDebuggable = 0 != applicationInfo.flags and ApplicationInfo.FLAG_DEBUGGABLE
Это взято из поста Bundells отсюда
getApplicationInfo().flags
работы?
Да, у вас не будет проблем с использованием:
if (BuildConfig.DEBUG) {
//It's not a release version.
}
Если вы не импортируете неправильный класс BuildConfig. Убедитесь, что вы ссылаетесь на класс BuildConfig вашего проекта, а не на любую из ваших библиотек зависимостей.
Из-за смешанных комментариев о BuildConfig.DEBUG
, я использовал следующее, чтобы отключить сбои (и аналитику) в режиме отладки:
обновить /app/build.gradle
android {
compileSdkVersion 25
buildToolsVersion "25.0.1"
defaultConfig {
applicationId "your.awesome.app"
minSdkVersion 16
targetSdkVersion 25
versionCode 100
versionName "1.0.0"
buildConfigField 'boolean', 'ENABLE_CRASHLYTICS', 'true'
}
buildTypes {
debug {
debuggable true
minifyEnabled false
buildConfigField 'boolean', 'ENABLE_CRASHLYTICS', 'false'
}
release {
debuggable false
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
затем в своем коде вы обнаруживаете ENABLE_CRASHLYTICS
флаг следующим образом:
if (BuildConfig.ENABLE_CRASHLYTICS)
{
// enable crashlytics and answers (Crashlytics by default includes Answers)
Fabric.with(this, new Crashlytics());
}
используйте ту же концепцию в своем приложении и переименуйте ENABLE_CRASHLYTICS
все, что вы хотите. Мне нравится этот подход, потому что я вижу флаг в конфигурации и могу контролировать флаг.
В качестве альтернативы, вы можете различить, используя BuildConfig.BUILD_TYPE;
Если вы используете отладочную сборку,
BuildConfig.BUILD_TYPE.equals("debug");
возвращает true. А для релиза build BuildConfig.BUILD_TYPE.equals("release");
возвращает true.
true
.
Я использую это решение на случай, если узнаю, что мое приложение работает на отладочной версии.
if (BuildConfig.BUILD_TYPE.equals("Debug")){
//Do something
}
if (BuildConfig.DEBUG) {}
в зависимом модуле Gradle, который (конечно) не имел ссылки на файл build.gradle приложения - это вызвало неправильное распознавание режима отладки. if (BuildConfig.BUILD_TYPE.equals("Debug")){ }
Исправлена проблема. Спасибо
Убедитесь, что вы импортируете правильный класс BuildConfig. И да, у вас не будет проблем с использованием:
if (BuildConfig.DEBUG) {
//It's not a release version.
}
BuildConfig
находится в пакете вашего приложения, напримерimport com.mycompany.myapp.BuildConfig;