当我在调试模式下运行我的应用程序时,BuildConfig.DEBUG 不起作用(= 逻辑上设置为 false)。我使用 Gradle 来构建。我有一个图书馆项目,我在其中进行检查。 BuildConfig.java 在构建调试文件夹中如下所示:
/** Automatically generated the file. DO NOT MODIFY */
package common.myProject;
public final class BuildConfig {
public static final boolean DEBUG = Boolean.parseBoolean("true");
}
并在发布文件夹中:
public static final boolean DEBUG = false;
在库项目和应用程序项目中。
我试图通过检查一个设置为我的项目类的变量来解决这个问题。此类从库继承并在启动时启动。
<application
android:name=".MyPrj" ...
这导致了另一个问题:我在 DataBaseProvider 中使用了我的 DEBUG 变量,该变量在应用程序类之前运行,并且由于此错误而无法正常运行。
使用 Android Studio 1.1 以及 1.1 的 gradle 版本,可以:
图书馆
android {
publishNonDefault true
}
应用程序
dependencies {
releaseCompile project(path: ':library', configuration: 'release')
debugCompile project(path: ':library', configuration: 'debug')
}
完整的文档可在此处找到 http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Library-Publication
编辑:
对于 Android Studio Gradle 版本 3.0,issue 刚刚被标记为已修复。您可以在此处使用 implementation project(path: ':library')
,它会自动选择正确的配置。
这是预期的行为。
库项目仅发布其发布变体以供其他项目或模块使用。
我们正在努力解决这个问题,但这并非易事,需要大量工作。
您可以在 https://code.google.com/p/android/issues/detail?id=52962 跟踪问题
检查 imports
,有时 BuildConfig 会无意中从任何类库中导入。例如:
import io.fabric.sdk.android.BuildConfig;
在这种情况下,BuildConfig.DEBUG 将始终返回 false;
import com.yourpackagename.BuildConfig;
在这种情况下,BuildConfig.DEBUG 将返回您真正的构建变体。
这就像菲尔的答案,除了它不需要上下文:
private static Boolean sDebug;
/**
* Is {@link BuildConfig#DEBUG} still broken for library projects? If so, use this.</p>
*
* See: https://code.google.com/p/android/issues/detail?id=52962</p>
*
* @return {@code true} if this is a debug build, {@code false} if it is a production build.
*/
public static boolean isDebugBuild() {
if (sDebug == null) {
try {
final Class<?> activityThread = Class.forName("android.app.ActivityThread");
final Method currentPackage = activityThread.getMethod("currentPackageName");
final String packageName = (String) currentPackage.invoke(null, (Object[]) null);
final Class<?> buildConfig = Class.forName(packageName + ".BuildConfig");
final Field DEBUG = buildConfig.getField("DEBUG");
DEBUG.setAccessible(true);
sDebug = DEBUG.getBoolean(null);
} catch (final Throwable t) {
final String message = t.getMessage();
if (message != null && message.contains("BuildConfig")) {
// Proguard obfuscated build. Most likely a production build.
sDebug = false;
} else {
sDebug = BuildConfig.DEBUG;
}
}
}
return sDebug;
}
作为一种解决方法,您可以使用此方法,该方法使用反射从应用程序(而不是库)获取字段值:
/**
* Gets a field from the project's BuildConfig. This is useful when, for example, flavors
* are used at the project level to set custom fields.
* @param context Used to find the correct file
* @param fieldName The name of the field-to-access
* @return The value of the field, or {@code null} if the field is not found.
*/
public static Object getBuildConfigValue(Context context, String fieldName) {
try {
Class<?> clazz = Class.forName(context.getPackageName() + ".BuildConfig");
Field field = clazz.getField(fieldName);
return field.get(null);
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (NoSuchFieldException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
}
return null;
}
例如,要获取 DEBUG
字段,只需从 Activity
调用它:
boolean debug = (Boolean) getBuildConfigValue(this, "DEBUG");
我还在 AOSP Issue Tracker 上分享了这个解决方案。
applicationIdSuffix
会使上述代码无法访问 .BuildConfig
类。
检查您是否处于调试模式并不是真正正确的方法,但您可以通过以下方式检查应用程序本身是否可调试:
private static Boolean sIsDebuggable;
public static boolean isDebuggable(Context context) {
if (sIsDebuggable == null)
sIsDebuggable = (context.getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE) != 0;
return sIsDebuggable;
}
应用程序和库的默认行为将完美匹配。
如果您需要更好的解决方法,可以改用它:
public static boolean isInDebugFlavour(Context context) {
if (sDebugFlavour == null) {
try {
final String packageName = context.getPackageName();
final Class<?> buildConfig = Class.forName(packageName + ".BuildConfig");
final Field DEBUG = buildConfig.getField("DEBUG");
DEBUG.setAccessible(true);
sDebugFlavour = DEBUG.getBoolean(null);
} catch (final Throwable t) {
sDebugFlavour = false;
}
}
return sDebugFlavour;
}
您可以使用 gradle 为每种构建类型创建自己的 BuildConfig 类
public class MyBuildConfig
{
public static final boolean DEBUG = true;
}
对于 /src/debug/.../MyBuildConfig.java 和...
public class MyBuildConfig
{
public static final boolean DEBUG = false;
}
对于 /src/release/.../MyBuildConfig.java
然后使用:
if (MyBuildConfig.DEBUG)
Log.d(TAG, "Hey! This is debug version!");
这是另一个解决方案。
1) 创建接口
public interface BuildVariantDetector {
boolean isDebugVariant();
}
2)在应用程序类(应用程序模块)上使用此接口
public class MyApplication extends Application implements BuildVariantDetector {
@Override
public boolean isDebugVariant() {
return BuildConfig.DEBUG; //application (main module) Buildonfig
}
}
3)然后在库模块中:
boolean debugVariant = ((BuildVariantDetector)getApplication()).isDebugVariant();
我们遇到了同样的问题。我想出了这样的事情:
我们有一个 SDK(库)和一个演示项目,层次结构如下所示:
Parent
|
+ SDK (:SDK)
|
+ DemoApp (:DemoApp)
对于我们的演示应用程序,:SDK:jarjarDebug
和 :SDK:jarjarRelease
是 :SDK
的一些特定任务,它们会生成一些后处理的 jar:
dependencies {
debugCompile tasks.getByPath(":SDK:jarjarDebug").outputs.files
releaseCompile tasks.getByPath(":SDK:jarjarRelease").outputs.files
... more dependencies ...
}
这甚至适用于一次构建的多个 buildTypes
。不过调试有点困难。请评论。
在我的情况下,我导入了错误的 BuildConfig
,因为我的项目有很多库模块。解决方法是为我的 app
模块导入正确的 BuildConfig
。
这是我的解决方法:反映应用模块的 BuildConfig:
`public static boolean debug = isDebug();
private static boolean isDebug() {
boolean result = false;
try {
Class c = Class.forName("com.example.app.BuildConfig");
Field f = c.getField("DEBUG");
f.setAccessible(true);
result = f.getBoolean(c);
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (NoSuchFieldException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
}
return result;
}`
您可以在每个项目 buildTypes 上尝试此操作:
parent.allprojects.each{ project -> android.defaultConfig.debuggable = true}
buildType
而不是构建配置。我理论上设置调试签名应该做同样的伎俩
在 gradle 文件中使用 debuggable true。
buildTypes {
demo{
debuggable true
}
live{
debuggable true
}
}
BuildConfig.DEBUG 根本不可靠,Android 提供了一个全局可用的内部标志,指示构建是处于调试模式还是非调试模式
(getContext().getApplicationInfo().flags &ApplicationInfo.FLAG_DEBUGGABLE) != 0)
如果它在调试中将是真的
学分:https://medium.com/@elye.project/checking-debug-build-the-right-way-d12da1098120
不定期副业成功案例分享