Crash on app launch at com.google.firebase.sessions.SessionDatastore$Companion.getInstance(SessionDatastore.kt:56)

[jeallybacon]

[REQUIRED] Step 2: Describe your environment

• Android Studio version: Android Studio Ladybug | 2024.2.1 Patch 2
• Firebase Component: firebase-crashlytics
• Component version:19.1.0
  In fact, I integrated using the firebase-bom approach, and the bom version is 33.3.0.

Android version: 14
Device: Samsung Galaxy S23 Ultra or other Samsung devices.

[REQUIRED] Step 3: Describe the problem

My app is multi-process. I initialize Firebase in each process. After the app has been running for some time, the main process crashes, but the other child processes on Samsung devices, such as the Galaxy S23 Ultra, remain active. When I relaunch the app by clicking on it, the main process encounters a crash related to SessionLifecycleService.

I believe the implementation of SessionLifecycleService has issues and doesn't account for multi-process scenarios. If the main process crashes and is restarted, Firebase initialization in the main process might be slow. Meanwhile, the existing child processes, still alive, attempt to bind to SessionLifecycleService, resulting in a crash in the newly restarted main process. The specific crash stack trace is as follows:

12-13 10:16:34.359 26277 26277 D SessionLifecycleService: Service bound to new client on process 14641
12-13 10:16:34.359 14641 14641 D SessionLifecycleClient: Connected to SessionLifecycleService. Queue size 0

--------- beginning of crash
12-13 10:16:34.361 26277 26420 E AndroidRuntime: FATAL EXCEPTION: FirebaseSessions_HandlerThread
12-13 10:16:34.361 26277 26420 E AndroidRuntime: Process: com.demo.camera, PID: 26277
12-13 10:16:34.361 26277 26420 E AndroidRuntime: java.lang.IllegalStateException: Default FirebaseApp is not initialized in this process com.demo.camera. Make sure to call FirebaseApp.initializeApp(Context) first.
12-13 10:16:34.361 26277 26420 E AndroidRuntime: at com.google.firebase.FirebaseApp.getInstance(FirebaseApp.java:179)
12-13 10:16:34.361 26277 26420 E AndroidRuntime: at com.google.firebase.FirebaseKt.getApp(Firebase.kt:42)
12-13 10:16:34.361 26277 26420 E AndroidRuntime: at com.google.firebase.sessions.SessionDatastore$Companion.getInstance(SessionDatastore.kt:56)
12-13 10:16:34.361 26277 26420 E AndroidRuntime: at com.google.firebase.sessions.SessionLifecycleService$MessageHandler.maybeSendSessionToClient(SessionLifecycleService.kt:153)
12-13 10:16:34.361 26277 26420 E AndroidRuntime: at com.google.firebase.sessions.SessionLifecycleService$MessageHandler.handleClientBound(SessionLifecycleService.kt:124)
12-13 10:16:34.361 26277 26420 E AndroidRuntime: at com.google.firebase.sessions.SessionLifecycleService$MessageHandler.handleMessage(SessionLifecycleService.kt:82)
12-13 10:16:34.361 26277 26420 E AndroidRuntime: at android.os.Handler.dispatchMessage(Handler.java:107)
12-13 10:16:34.361 26277 26420 E AndroidRuntime: at android.os.Looper.loopOnce(Looper.java:249)
12-13 10:16:34.361 26277 26420 E AndroidRuntime: at android.os.Looper.loop(Looper.java:337)
12-13 10:16:34.361 26277 26420 E AndroidRuntime: at android.os.HandlerThread.run(HandlerThread.java:85)

Steps to reproduce:

1、Create an app that supports multiple processes, starts multiple processes on launch, and initializes Firebase in each process.
2、Manually trigger a crash in the main process on the app's homepage.
3、Restart the app.
Repeat steps 2 and 3 multiple times to reproduce the issue.

The above steps should be performed on a Samsung device because, on Samsung devices, when the app's main process crashes, the child processes are not terminated.

Relevant Code:

[google-oss-bot]

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

[jeallybacon]

This crash is related to the Crashlytics SDK, specifically to the session functionality within Crashlytics.

[lehcar09]

Hi @jeallybacon, thank you for reaching out. I'm currently looking into this issue. By any chance, can you share an MCVE to help us investigate the issue?

Aside from that, you mentioned from the steps you shared to perform it in Samsung devices. Were you able to check if the issue occurs on other device and/or version? Thanks!

[google-oss-bot]

Hey @jeallybacon. 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!

[jeallybacon]

Thank you for your response. After a thorough analysis of the issue, I now have a clear understanding of why it occurs.

The SessionLifecycleService is, as I understand it, used to manage app session-related tasks. It runs in the main process, and in multi-process architectures, multiple subprocesses initialize Firebase.

When Firebase is initialized on a background thread, this issue arises. The specific reproduction path is as follows: if the app initializes Firebase on a background thread in the onCreate method of the Application class, and a crash is manually triggered on the app's home screen, the connection between the subprocess and the SessionLifecycleService will be severed (though the subprocess itself does not terminate). When the main process restarts due to the crash, the onCreate method of the Application in the main process is executed quickly (but since Firebase is being initialized on a background thread, it hasn’t completed yet). At this point, the subprocess attempts to rebind to the SessionLifecycleService, leading to the aforementioned error.

I believe this indicates a design flaw in the SessionLifecycleService. It relies heavily on Firebase initialization but fails to handle such scenarios properly in a multi-process environment. I hope the developers of SessionLifecycleService can address this issue.

Additionally, this issue is not limited to Samsung devices; it can occur on other devices as well. In summary, the root cause is that the app is multi-process, and Firebase initialization is either slow or performed on a background thread. When a subprocess binds to the SessionLifecycleService, it’s possible that Firebase in the main process hasn’t completed initialization yet.

[mrober]

Since you are initializing Firebase manually, you must call initializeApp before using any other Firebase API in that process. Since you do it in a background thread, you might not be initializing it before calling other APIs. From your stack trace, I cannot tell if you called something too early. It almost looks like it gets called automatically because of how SessionLifecycleService works.

I played with this in a test app and I am able to reproduce it. I will come up with something to mitigate it and let you know.

Also note that Firebase does not support multi-process in general, see FirebaseApp. But Crashlytics specifically does support it. So if you have other Firebase products that don't, I am not sure how they will interact.

[jeallybacon]

Thank you for your response. The reason I moved Firebase initialization to a background thread is that we observed some users encountering ANR issues during Firebase initialization. For our own modules, we ensure that Firebase is initialized before using its APIs. However, the SessionLifecycleService is part of Firebase's internal SDK, so we can't guarantee this for it.

Previously, I tried initializing Firebase in a background thread on a single-process app, and everything seemed to work fine. The app also performed well after being released. However, this time, I attempted the same approach in a multi-process app, and in certain scenarios, we encountered crashes related to the SessionLifecycleService.

We do need Crashlytics-related session functionalities, but it seems that SessionLifecycleService does not handle multi-process scenarios well. I hope you can consider and address this issue promptly. At the very least, ensure that the app does not crash in the scenario I described, or alternatively, simply disable session functionality in child processes if it is unsupported.