I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

Internally tracked at b/162031027

Hi carlonzo@,

I think this might help in further debugging we disabled the FirebaseInitProvider and we init manually. This looks to be a strange thread contention problem which may not always reproduce.

Context

Since FirebaseInitProvider initializes Firebase APIs at app startup time, not being able to initialize them properly (considering the inter-dependency) might cause conflicts.

From the logs it looks like com.careem.superapp.core.analytics.impl.firebase.FirebaseInitializer is the place where you are initializing FirebaseApp which is the entry point of Firebase SDKs (usually initialized by FirebaseInitProvider).

My hypothesis is that FirebaseApp initialization is stuck on initializing FirebasePerformance component because of the another thread in which FirebasePerformance.getInstance() seems to be called. As per the documentation of FirebaseApp:

Any FirebaseApp initialization must occur only in the main process of the app. Use of Firebase in processes other than the main process is not supported and will likely cause problems related to resource contention.

Remedies

• Reverting back to use the FirebaseInitProvider (i.e not disabling it) may help to resolve this (but need to get more information before).

Questions

Q1. Is FirebaseInitializer a ContentProvider?

Q2. How and when are you calling FirebasePerformance.getInstance()?

Useful References

• Take Control of Your Firebase Init on Android
• How does Firebase initialize on Android?

Hey @carlonzo. We need more information to resolve this issue but there hasn't been an update in 5 weekdays. I'm marking the issue as stale and if there are no new updates in the next 5 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

Hi @ramanpreetSinghKhinda ,
Thanks for your help and sorry for my late answer.

I think I see what you are trying to say, but I cant find a reason we have this thread contention.

I can copy paste the content of that com.careem.superapp.core.analytics.impl.firebase.FirebaseInitializer

class FirebaseInitializer(
  private val isEnabled: Boolean,
  private val firebaseProjectConfig: FirebaseProjectConfig
) : InitializableAgent {

  private companion object {
    var isInitialized: Boolean = false
  }

  @Synchronized
  override fun initialize(context: Context) {
    if (!isInitialized && isEnabled) {

      val builder: FirebaseOptions.Builder
      with(firebaseProjectConfig) {
        builder = FirebaseOptions.Builder()
          .setApplicationId(googleAppId)
          .setApiKey(googleApiKey)
          .setDatabaseUrl(databaseUrl)
          .setStorageBucket(googleStorageBucket)
          .setProjectId(projectId)
          .setGcmSenderId(gcmDefaultSenderId)

        FirebaseApp.initializeApp(context, builder.build())
      }
      FirebaseAnalytics.getInstance(context).setAnalyticsCollectionEnabled(false)
    }
    isInitialized = true
  }
}

this is called inside the Application.onCreate. not from a Content provider. could that be the issue?

About your questions:
A1: no, FirebaseInitializer encapsulates the init method for FirebaseApp.initializeApp. pasted above.
A2: we are not manually calling FirebasePerformance.getInstance().

Thank you again for your time,
Carlo

Thanks @carlonzo

From the stack trace it does looks like FirebasePerformance.getInstance() is called. Can you instead let me know if you are calling any Fireperf specific API?

• https://firebase.google.com/docs/reference/android/com/google/firebase/perf/package-summary
• https://firebase.google.com/docs/reference/android/com/google/firebase/perf/metrics/package-summary

If yes, how are you calling that API? Any thread (or Synchronized) involved?

Just to rule that case out, your app is not a multi-process app, right?

Also just to clarify, you mentioned;

Looking at the source code, I believe the thread blocks trying to get/create an instance from RemoteConfigComponent.get("fireperf"). that method is access from main thread, is synchronized and internally it executes a few disk accesses

Can you point me out where exactly you looked?

Thanks again @ramanpreetSinghKhinda

No we do not directly call FirebasePerformance.getInstance(). we only apply the plugin. no call is done to any com.google.firebase.perf.*. we just use Firebase Performance to look at the default perfomance reports provided by the sdk (network, rendering by screen, .. ).

No our app is not a multi process app.

the reason I suggested was an issue with RemoteConfigComponent.get("fireperf") is bacause I tried to look at the content fo the class com.google.firebase.perf.zza.create (zza.java:2) (coming from the reported stacktrace) and the create method calls new FirebasePerformance((FirebaseApp)var1.get(FirebaseApp.class), ((RemoteConfigComponent)var1.get(RemoteConfigComponent.class)).get("fireperf")); (this is what I see from my decompiled class) and that RemoteConfigComponent.get("fireperf") is the only synchronized method I see. that methods loads a shared preference which can be blocking on IO. mine is just an hypothesis of course.

Please let me know if I can provide more infos

Hi @carlonzo,

I'm still working on it. However, because of other priorities I am not yet able to spend time on validating this. As a remedy mentioned in #1810 (comment) can you revert to use the default way of Firebase initialization and see if that helps resolve your issue?

The reason for that suggestion (see this) is when an Android app process is first started, there is well-defined order of operations:

1. Each ContentProvider declared in the manifest is created, in priority order.
2. The Application class (or custom subclass) is created.
3. If another component that was invoked via some Intent, that is created.

Since Firebase Initialization (in default case) happens in the ContentProvider, I suspect having it manually initialized is causing a problem in this particular case.

Note: In parallel we'll still keep on looking into why it's ANRing in this specialized use case.

Hi @carlonzo,

I am looking into making a lazy dependency towards the RemoteConfigComponent, that should hopefully help resolve the thread contention problem.

If all goes well we'll release the fix in the upcoming release or next of that.

Hi @ramanpreetSinghKhinda thanks for that. We didn't switch to the initialisation using the content provider, yet, but I'm planning to do so this week. I'll let you know if I see improvements.

Hopefully making making the initialization lazy will fix the thread contention.

@carlonzo

The fix will go in the upcoming release. You can keep an eye on the release notes for Firebase Performance.

Please reopen if the issue still persists with the latest perf sdk version.

Thanks @ramanpreetSinghKhinda. looking forward to trying this.

Is there a public PR I can look at that fixed the issue?

Thanks for checking in @carlonzo

Not currently unfortunately :|

But once firebase-perf SDK gets open sourced you should be able to see the PRs and the code. This is currently in pipeline and will take a while. You can keep an eye on the Firebase Android Open Source Repo.