这里是Crashlytics的Marc。这里有几个方法来禁用Crashlytics，而你正在做你的调试构建!

使用不同的android:versionString进行调试和发布构建，然后从Crashlytics web仪表板禁用调试版本的崩溃报告。 将对Crashlytics.start()的调用包装在检查调试标志的if语句中。您可以使用自定义标志或类似于这里提出的方法:如何检查APK是否有签名或“调试构建”?

如果您的应用程序中还没有一个类，请创建一个从Application扩展而来的类。

然后执行以下步骤:

public class BaseApplication extends Application { // extend from MultidexApplication if multidex is required by your application 

    @Override
    public void onCreate() {
        super.onCreate();

        /*
         *  Crashlytics is enabled by default,
         *  Disable it for debug builds & USB Debugging
         * */

        if(BuildConfig.DEBUG){ 
            FirebaseCrashlytics.getInstance().setCrashlyticsCollectionEnabled(false);
        }
  }
}

不要忘记在AndroidManifest.xml中添加该类

 <application
        android:name=".BaseApplication"
        android:icon="@mipmap/ic_launcher"
        android:label="@string/app_name"
        ........>

2019的答案

我一直在尝试只在发行版中启用Crashlytics，在调试中禁用2小时，检查Firebase控制台，看看异常是否上传。

有两种可能的方法。

选项1

它工作，但如果你在调试构建调用任何Crashlytics方法，应用程序将崩溃。

app / build.gradle

android {
    buildTypes {
        release {
            manifestPlaceholders = [crashlyticsEnabled: true]
        }
        debug {
            manifestPlaceholders = [crashlyticsEnabled: false]
        }

AndroidManifest.xml

<manifest
    <application
        <meta-data
            android:name="firebase_crashlytics_collection_enabled"
            android:value="${crashlyticsEnabled}" />

选项2

如果允许您调用Crashlytics方法而不检查BuildConfig，则可以选择此方法。调试。有了这个设置，你可以安全地调用Crashlytics.logException()这样的方法——它们在调试版本中什么都不做。我在调试中没有看到报告被上传。

app / build.gradle

android {
    buildTypes {
        release {
            ext.enableCrashlytics = true
        }
        debug {
            ext.enableCrashlytics = false
        }

AndroidManifest.xml

<manifest
    <application
        <meta-data
            android:name="firebase_crashlytics_collection_enabled"
            android:value="false" />

应用程序onCreate ()

val crashlytics = Crashlytics.Builder()
    .core(CrashlyticsCore.Builder().disabled(BuildConfig.DEBUG).build())
    .build()
Fabric.with(this, crashlytics)

我发现这是最简单的解决方案:

    release {
        ...
        buildConfigField 'Boolean', 'enableCrashlytics', 'true'
    }
    debug {
        buildConfigField 'Boolean', 'enableCrashlytics', 'false'
    }

上面的代码行将在BuildConfig文件中创建一个名为enableCrashlytics的静态布尔字段，你可以用它来决定是否初始化Fabric:

    if (BuildConfig.enableCrashlytics)
        Fabric.with(this, new Crashlytics());

注意:使用这种方法，fabric只在发布版本中初始化(如上面的代码所示)。这意味着你需要在一个if块中调用Crashlytics类中的静态方法，该块检查fabric是否已经初始化，如下所示。

if (Fabric.isInitialized())
    Crashlytics.logException(e);

否则，当在模拟器上测试时，在使用singleton()错误之前，应用程序将崩溃。

如果你想捕获所有的崩溃(用于调试和发布版本)，但想在Crashlytics仪表板中分离它们，你可以添加这行代码到build.gradle:

debug {
    versionNameSuffix "-DEBUG"
}

例如，如果你的应用程序的versionName是1.0.0，你的发布版本将被标记为1.0.0，而调试版本将被标记为1.0.0- debug

答:更新 从gradle配置中禁用crlytics以提高构建速度。

android {
    ...
    buildTypes {
        debug {
            ext.enableCrashlytics = false
        }
    }
}

或者kotlin公里:

android {
    ...
    buildTypes {
        getByName("debug") {
            extra["enableCrashlytics"] = false
        }
    }
}

然后编程地:

// Initializes Fabric for builds that don't use the debug build type.
Crashlytics.Builder()
        .core(CrashlyticsCore.Builder().disabled(BuildConfig.DEBUG).build())
        .build()
        .also { crashlyticsKit ->
            Fabric.with(this, crashlyticsKit)
        }

你也可以继续在调试构建中使用crashlytics，但仍然可以通过防止crashlytics为每个构建生成一个新ID来提高构建速度:

android {
    ...
    buildTypes {
        getByName("debug") {
            extra["alwaysUpdateBuildId"] = false
        }
    }
}

或groovy:

android {
    ...
    buildTypes {
        debug {
            ext.alwaysUpdateBuildId = false
        }
    }
}

查看下面的文档链接: https://developer.android.com/studio/build/optimize-your-build#disable_crashlytics