NullPointerException: FirebaseCrashlytics component is not present.

[tprochazka]

• Firebase Component: Crashlytics 18.3.2, Common: 20.2.0
• Android 13 only!

Exception java.lang.NullPointerException: FirebaseCrashlytics component is not present.
  at com.google.firebase.crashlytics.FirebaseCrashlytics.getInstance (FirebaseCrashlytics.java:186)
  at com.avast.android.logging.crashlytics.CrashlyticsAlfLogger.logMessage (CrashlyticsAlfLogger.kt:29)

This happen to us based on Google Play reports about 30-50 users per day.
On the line 29 is just this FirebaseCrashlytics.getInstance().log(logMessage)

We even call FirebaseApp.initializeApp(applicationContext) in the Application class.

I found that FirebaseApp do this in the constructor

    componentRuntime =
        ComponentRuntime.builder(UI_EXECUTOR)
            .addLazyComponentRegistrars(registrars)
            .addComponentRegistrar(new FirebaseCommonRegistrar())
            .addComponent(Component.of(applicationContext, Context.class))
            .addComponent(Component.of(this, FirebaseApp.class))
            .addComponent(Component.of(options, FirebaseOptions.class))
            .setProcessor(new ComponentMonitor())
            .build();

It uses UI_EXECUTOR, but it not running this component setup immediately in the constructor, right? So it means that when I run something on a background thread that will call FirebaseCrashlytics.getInstance() it can happen that it will be executed before this constructor initialization which can lead to this error right?

[argzdev]

Hi @tprochazka, according to the docs, there should be no need to invoke FirebaseApp.initializeApp(applicationContext). This is only needed if you need to access another Firebase project. I'm wondering if you're experiencing the same behavior as with the developer in this Stack Overflow link.

but it not running this component setup immediately in the constructor, right?

Yes, you're right. All instantiations are using lazy, so it will only instantiate when needed. However, I don't think there's a possibility for the constructor to not initialize before retrieving the instance.

[tprochazka]

Yes. Adding FirebaseApp.initializeApp(applicationContext) was just an attempt to solve some other weird Firebase crashes, where sometimes Firebase API calls happened before Firebase normal initialization, this solved that issue.

It is not about lazy instantiations it even creates a list of existing services by using UI_EXECUTOR. I did not check the internal code of ComponentRuntime.builder(), but I'm expecting that it will not run immediately, but in the next UI cycle, so I'm expecting that the FirebaseApp constructor will finish before the list of possible services is filled. Inside of FirebaseCrashlytics.getInstance() is already nothing that can prevent to crash, if the list is not initialized yet, it simply crashes. So it is not lazy, it just optimistically assumes that initialization of the possible services magically always happens before FirebaseCrashlytics.getInstance() is called :-(. It should simply do it if not.

We currently fixed it by try...catch all FirebaseCrashlytics.getInstance() calling, better to not log something, than crash the app.

Update:
We also have this

    boolean isMain = isMainProcess(this);
    if (!isMain) {
        // other things
        return;
    }

In application class.
And we init Firebase and everything else just for the main process.

[argzdev]

Ah, I see what you mean. Thanks for the detailed explanation, @tprochazka. I believe your thought process is correct in this case. However, let me get a feedback from our engineer to see if this is how it works, and how we should mitigate the issue.

Also any chance you're able to reproduce this behavior on your side? If yes, could you share with us a minimal reproducible example while were waiting for a response from our engineers? Thanks!

[tprochazka]

Sadly no, we receiving it just from Google Play Console :-(

[argzdev]

Hi @tprochazka, I've received feedback from our engineer. That the line

firebase-android-sdk/firebase-common/src/main/java/com/google/firebase/FirebaseApp.java

Line 424 in f76f697

ComponentRuntime.builder(com.google.firebase.concurrent.UiExecutor.INSTANCE)

that points to the executor passed to the ComponentBuilder is being used by the runtime for message passing

firebase-android-sdk/firebase-components/src/main/java/com/google/firebase/components/ComponentRuntime.java

Line 85 in 63f2071

this.componentRegistrarProcessor = componentRegistrarProcessor;

and it doesn't mean that the runtime is created in that thread. So this might mean that the issue is due to something else entirely.

Also I noticed that you included the version for Firebase Common. Are you importing this dependency as well?

[tprochazka]

We have no direct dependency on Firebase Common, it is a transitive dependency. U put it there just for sure because it is part of Stacktrace.

There is also very interesting that it happens just on A13.

For now, we salved it just by try...catch :-(

[tprochazka]

But with new release and with try...catch it just fail somewhere else

Exception java.lang.ExceptionInInitializerError:
  at com.google.firebase.perf.config.ConfigResolver.<init> (ConfigResolver.java:78)
  at com.google.firebase.perf.config.ConfigResolver.getInstance (ConfigResolver.java:86)
  at com.google.firebase.perf.application.AppStateMonitor.<init> (AppStateMonitor.java:98)
  at com.google.firebase.perf.application.AppStateMonitor.getInstance (AppStateMonitor.java:87)
  at com.google.firebase.perf.metrics.Trace.<init> (Trace.java:106)
  at com.google.firebase.perf.metrics.Trace.create (Trace.java)
  at com.google.firebase.perf.FirebasePerformance.startTrace (FirebasePerformance.java:213)
  at com.avast.android.cleaner.core.ProjectApp.onCreate (ProjectApp.kt:3)
  at android.app.Instrumentation.callApplicationOnCreate (Instrumentation.java:1266)
  at android.app.ActivityThread.handleBindApplication (ActivityThread.java:7614)
  at android.app.ActivityThread.-$$Nest$mhandleBindApplication
  at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2400)
  at android.os.Handler.dispatchMessage (Handler.java:106)
  at android.os.Looper.loopOnce (Looper.java:226)
  at android.os.Looper.loop (Looper.java:313)
  at android.app.ActivityThread.main (ActivityThread.java:8757)
  at java.lang.reflect.Method.invoke
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:571)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1067)
Caused by java.lang.IllegalStateException:
  at com.google.firebase.FirebaseApp.getInstance (FirebaseApp.java:179)
  at com.google.firebase.perf.config.RemoteConfigManager.getInitialStartupMillis (RemoteConfigManager.java:91)
  at com.google.firebase.perf.config.RemoteConfigManager.<init> (RemoteConfigManager.java:85)
  at com.google.firebase.perf.config.RemoteConfigManager.<clinit> (RemoteConfigManager.java:52)

[argzdev]

Thanks for the updates, @tprochazka. That's odd, so these calls are being made prior to Firebase initialization. To fully grasp the issue. May I ask if you are perhaps using any dependency injection? If so, could you share some code snippets, perhaps that'll give us an idea. Also is your app typically running on the background? I'm imagining that the trigger is when the device is in sleep or doze state, or it could be due to the behavior changes for Android 13 on Battery Resource Utilization.

[tprochazka]

Our app uses WorkManager to do some work in the background, but not run in the background for a long period of time.
All crashes have one common thing, except A13, which all happened inside of the Application class, so before any user UI is displayed, except the splash screen. But hard to say what happens if we try....catch all Firebase calls there...

And as I already wrote here, we even call FirebaseApp.initializeApp(applicationContext) in the Application class, directly in onCreate() method.

We are using simple custom service locator-based DI, not Hilt/Dagger

It is sad that both Play console and Firebase has some issue with the deobfuscation of the stack trace for some unknown reason and we sometimes don't see the correct line number like in stack trace before where is ProjectApp.kt:3, on line 3 is just import. We don't found a solution for that. So I basically don't know on which line this was happening directly, because we don't call

[scakshit]

Hi @argzdev, we are also facing the exact same crash in our app (stack trace below):

Exception java.lang.RuntimeException: Unable to create application com.xxx.android.app.RealXXXApplication: java.lang.NullPointerException: FirebaseCrashlytics component is not present.
  at android.app.ActivityThread.handleBindApplication (ActivityThread.java:7619)
  at android.app.ActivityThread.-$$Nest$mhandleBindApplication
  at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2400)
  at android.os.Handler.dispatchMessage (Handler.java:106)
  at android.os.Looper.loopOnce (Looper.java:226)
  at android.os.Looper.loop (Looper.java:313)
  at android.app.ActivityThread.main (ActivityThread.java:8757)
  at java.lang.reflect.Method.invoke
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:571)
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1067)
Caused by java.lang.NullPointerException: FirebaseCrashlytics component is not present.
  at com.google.firebase.crashlytics.FirebaseCrashlytics.getInstance (FirebaseCrashlytics.java:202)

And this is happening for old Android versions as well like Android 11, 12 and not just 13 like shared by @tprochazka and also happening in foreground and not just background.

I came across this issue, so I want to highlight it. We are also trying the solution to put the Firebase.getInstance() inside a try catch to not have a crash there for the time being. But would love to have proper solution if any or if we can debug it on the Firebase sdk side to find the root cause of this.

If you need more information for me, I can also share that.

[argzdev]

Hi @scakshit, thanks for the extra details. I'm wondering if this issue might actually be related to #4693. Could you confirm if you're also using Firebase performance? Thanks!