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.