当前位置: 首页 > 知识库问答 >
问题:

是否需要调用firebaseapp.initializeapp()来初始化Firebase?

厉坚
2023-03-14

我将firebase添加到我的android项目中,以使用firebase云消息传递。我按照文档进行了操作,但没有找到调用firebaseapp.initializeapp()的任何说明。

我的应用程序工作很好,除了有一次它崩溃了以下错误。

Caused by: java.lang.IllegalStateException: Default FirebaseApp is not initialized in this process com.my.app. Make sure to call FirebaseApp.initializeApp(Context) first.
at com.google.firebase.FirebaseApp.getInstance(Unknown Source)
at com.google.firebase.iid.FirebaseInstanceId.getInstance(Unknown Source)
at com.my.app.core.ApplicationEx.onCreate(ApplicationEx.java:79)

当我搜索错误时,给出的解决方案是在启动时调用firebaseapp.initializeapp()

我想知道这是否真的有必要,因为文档没有提到它,我的应用程序在没有它的情况下工作(大部分)很好。

有人知道调用firebaseapp.initializeapp()是否真的有必要,还有什么可能导致我上面提到的错误吗?

下面是我的build.gradle

apply plugin: 'com.android.application'

android {
    compileSdkVersion 26
    defaultConfig {
        applicationId "com.my.app"
        minSdkVersion 17
        targetSdkVersion 26
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
        multiDexEnabled true
    }
    flavorDimensions "appType"
    productFlavors {
        passenger {
            dimension "appType"
            applicationId "com.my.app.passenger"
            versionCode 1
            versionName "1"
        }
        driver {
            dimension "appType"
            applicationId "com.my.app.driver"
            versionCode 1
            versionName "1"
        }
        admin {
            dimension "appType"
            applicationId "com.my.app.admin"
            versionCode 1
            versionName "1"
        }
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
        debug {
            testCoverageEnabled true
        }
        packagingOptions {
            exclude 'META-INF/ASL2.0'
            exclude 'META-INF/LICENSE'
            exclude 'META-INF/NOTICE'
            exclude 'META-INF/NOTICE.txt'
            exclude 'META-INF/LICENSE.txt'
            exclude 'META-INF/MANIFEST.MF'
        }
    }
}

repositories {
    maven { url 'https://oss.sonatype.org/content/repositories/snapshots' }
}

dependencies {
    implementation project(path: ':cards')
    implementation fileTree(dir: 'libs', include: ['*.jar'])
    implementation "com.android.support:design:${supportVersion}"
    implementation "com.android.support:support-v4:${supportVersion}"
    implementation "com.android.support:appcompat-v7:${supportVersion}"
    implementation "com.android.support:cardview-v7:${supportVersion}"
    implementation "com.android.support:gridlayout-v7:${supportVersion}"
    implementation "com.google.android.gms:play-services-maps:${googlePlayServicesVersion}"
    implementation "com.google.android.gms:play-services-location:${googlePlayServicesVersion}"
    implementation "com.google.android.gms:play-services-places:${googlePlayServicesVersion}"
    implementation "com.google.android.gms:play-services-gcm:${googlePlayServicesVersion}"
    implementation "com.google.android.gms:play-services-ads:${googlePlayServicesVersion}"
    implementation "com.google.android.gms:play-services-auth:${googlePlayServicesVersion}"
    implementation 'com.google.maps:google-maps-services:0.2.5'
    implementation "com.google.firebase:firebase-messaging:${googlePlayServicesVersion}"
    implementation "com.loopj.android:android-async-http:${asyncHttpVersion}"
    implementation "com.android.support.test.espresso:espresso-idling-resource:${espressoVersion}"
    implementation 'com.android.support:multidex:1.0.2'
    implementation 'com.android.support.constraint:constraint-layout:1.0.2'
    implementation 'org.slf4j:slf4j-api:1.7.25'
    implementation 'com.github.tony19:logback-android-core:1.1.1-6'
    implementation 'ch.acra:acra:4.9.2'
    implementation('com.github.tony19:logback-android-classic:1.1.1-6') {
        exclude group: 'com.google.android', module: 'android'      // workaround issue #73
    }
    testImplementation 'org.testng:testng:6.9.6'
    testImplementation 'org.mockito:mockito-core:1.10.19'
    testImplementation 'org.powermock:powermock-api-mockito:1.6.5'
    testImplementation 'org.powermock:powermock-module-junit4-rule-agent:1.6.5'
    testImplementation 'org.powermock:powermock-module-junit4-rule:1.6.5'
    testImplementation 'org.powermock:powermock-module-junit4:1.6.5'
    androidTestImplementation "com.android.support:support-annotations:${supportVersion}"
    androidTestImplementation 'com.android.support.test:runner:1.0.1'
    androidTestImplementation 'com.android.support.test:rules:1.0.1'
    androidTestImplementation 'org.testng:testng:6.9.6'
    androidTestImplementation 'org.mockito:mockito-core:1.10.19'
    androidTestImplementation 'com.google.dexmaker:dexmaker:1.2'
    androidTestImplementation 'com.google.dexmaker:dexmaker-mockito:1.2'
    androidTestImplementation 'com.android.support.test.uiautomator:uiautomator-v18:2.1.3'
    androidTestImplementation("com.android.support.test.espresso:espresso-core:${espressoVersion}", {
        exclude group: 'com.android.support', module: 'support-annotations'
    })
}

apply plugin: 'com.google.gms.google-services'

共有1个答案

连厉刚
2023-03-14

Firebase SDK通常不支持使用主进程以外的进程。如果ACRA启动并启动另一个进程,它自己的进程将为该进程创建一个新的应用程序子类。这是因为每个应用程序进程都必须实例化一个应用程序对象

这对您的应用程序意味着其他进程永远不要使用Firebase API。这意味着您需要另找一个地方来获得该IID令牌。

(请注意,Firebase SDK是由默认情况下合并到应用程序中的ContentProvider自动初始化的--除非您已经删除了这个ContentProvider,或者您没有使用谷歌服务插件,否则您永远不必调用FirebaseApp.initializeApp()。)

通常,当应用程序需要获得IID令牌时,它们会创建FirebaseInstanceIdService的子类,如文档中所述。每次知道新令牌时都会通知此服务。这是您应该检索它并将其发送到服务器的地方。

 类似资料:
  • 我正在使用mockito作为junit。在创建对象的模拟时,我有疑问。我有一个名为DBConnect的类。我需要数据库属性,如dbname、凭据等。PatientDetails使用这个类。现在,当我为PatientDetails编写junit时。所以我使用以下代码。 用这个我不能得到正确的结果。

  • 问题内容: 我们的团队正在使用SecureRandom生成密钥对列表(将SecureRandom传递给KeyPairGenerator)。对于以下两种选择中的哪一种,我们无法达成共识: 每次需要生成密钥对时都创建一个新实例 初始化静态实例并将其用于所有密钥对 通常哪种方法更好, 为什么 ? 添加:我的直觉是第二种选择更安全。但我唯一的论点是基于以下假设的理论攻击:假随机性是从当前时间戳派生的:某人

  • C++标准在3.3.2“声明点”中包含了一个半著名的“令人惊讶的”名称查找示例: 这会用它自己初始化,它(作为一个基元类型)是未初始化的,因此具有一个不确定的值(假设它是一个自动变量)。

  • 问题内容: 在一对多JPA关联中,将空关系初始化为空集合是否被视为最佳实践?例如。 在上面的示例中,最好将默认值定义为空吗?优缺点都有什么? 问题答案: JPA本身并不关心集合是否已初始化。当使用JPA从数据库中检索订单时,JPA将 始终 返回带有非空OrderLine列表的Order。 原因:因为一个订单可以有0行,1行或N行,并且最好用一个空的,一个大小或N个大小的集合进行建模。如果集合为空,

  • 我的模块应用程序如下: 而gradle项目是 下面是我的活动

  • 默认FirebaseApp未在此进程中初始化。确保首先调用FirebaseApp.InitializeApp(上下文)。 我已经尝试了许多东西,但我无法在设备中获得通知。 我也用下面的东西试过了。 通知以前是有效的,但是在我将xamarin表单更新到2.5.0.280555和xamarin.firebase.messaging.42.1021.1之后,它停止工作了。