Crash reporting in Firebase - Step-by-Step Execution

Process Flow - Crash reporting

App runs on device

↓

Crash occurs?

No→App continues

Yes↓

Crash detected by SDK

↓

Crash data collected

↓

Crash report sent to Firebase

↓

Crash appears in Firebase Console

↓

Developer reviews and fixes crash

The app runs and if a crash happens, the Firebase SDK detects it, collects data, sends it to Firebase, and the developer can then see and fix it.

Execution Sample

Firebase

firebase.crashlytics().log('App started');
// code that might crash:
throw new Error('Simulated crash');

This code logs app start, simulates risky code that causes a crash, and the Firebase Crashlytics SDK automatically detects it, collects data, and reports it.

Process Table

Step	Action	Evaluation	Result
1	App starts	No crash yet	App runs normally
2	Crash occurs in risky code	Crash detected	Crashlytics SDK captures crash
3	Crash data collected	Stack trace and device info gathered	Crash report prepared
4	Crash report sent	Network available	Report sent to Firebase
5	Crash appears in Firebase Console	Report received	Developer notified
6	Developer fixes crash	Code updated	Crash prevented in future runs
7	App runs again	No crash	Normal operation

💡 Crash handled and reported; app continues or developer fixes issue

Status Tracker

Variable	Start	After Crash	After Report Sent	Final
appState	running	crashed	reporting	running
crashData	none	collected	sent	none
networkStatus	available	available	available	available

Key Moments - 2 Insights

Why doesn't the app crash stop immediately when the error happens?

Because the Crashlytics SDK catches the crash event and collects data before the app fully stops, as shown in steps 2 and 3 of the execution table.

What happens if the network is not available when the crash report is sent?

The SDK stores the crash report locally and sends it later when the network is available, ensuring no data loss. This is implied in step 4 where network availability is checked.

Visual Quiz - 3 Questions

Look at the execution table, at which step does the crash data get collected?

A Step 3

B Step 2

C Step 4

D Step 5

💡 Hint

Check the 'Action' and 'Result' columns in the execution table rows.

According to the variable tracker, what is the state of 'appState' after the crash but before the report is sent?

A running

B reporting

C crashed

D none

💡 Hint

Look at the 'After Crash' column for 'appState' in the variable tracker.

If the network was unavailable at step 4, how would the execution table change?

A Crash report would be sent immediately anyway

B Crash report sending would be delayed until network is available

C Crash data would not be collected

D App would crash again

💡 Hint

Refer to the key moment about network availability and step 4 in the execution table.

Concept Snapshot

Crash Reporting with Firebase Crashlytics:
- SDK detects app crashes automatically
- Collects crash data like stack trace and device info
- Sends reports to Firebase Console
- Developer reviews crashes and fixes bugs
- Handles offline by storing reports locally
- Helps improve app stability over time

Full Transcript

Crash reporting in Firebase works by the app running normally until a crash happens. When a crash occurs, the Firebase Crashlytics SDK detects it and collects important data like the error and device details. Then it sends this crash report to the Firebase Console where developers can see it. If the network is down, the SDK saves the report and sends it later. Developers use this information to fix bugs and improve the app. This process helps keep apps stable and reliable.

Practice

1. What is the main purpose of Firebase Crashlytics in an app?

easy

A. To store user data securely

B. To manage user authentication

C. To improve app loading speed

D. To automatically collect and report app crashes

Solution

1. Step 1: Understand Crashlytics role

   Firebase Crashlytics is designed to track and report app crashes automatically.

2. Step 2: Compare with other options

   Storing user data, improving speed, and managing authentication are not Crashlytics functions.

3. Final Answer:

   To automatically collect and report app crashes -> Option D

4. Quick Check:

   Crashlytics = crash reporting [OK]

Hint: Crashlytics = crash reports, not data or speed [OK]

Common Mistakes:

• Confusing Crashlytics with user data storage
• Thinking it speeds up the app
• Mixing it with authentication services

2. Which Firebase Crashlytics method is used to log custom messages before a crash?

easy

A. crashlytics.sendReport()

B. crashlytics.recordError()

C. crashlytics.log()

D. crashlytics.startSession()

Solution

1. Step 1: Identify logging method

   The method to add custom logs before a crash is crashlytics.log().

2. Step 2: Understand other methods

   recordError() reports errors, sendReport() and startSession() are not valid Crashlytics methods.

3. Final Answer:

   crashlytics.log() -> Option C

4. Quick Check:

   Logging = crashlytics.log() [OK]

Hint: Use .log() to add messages before crash [OK]

Common Mistakes:

• Using recordError() to log messages
• Assuming sendReport() exists
• Confusing startSession() with logging

3. Given this code snippet, what will Crashlytics report?

try {
  throw new Error('Test crash');
} catch (e) {
  firebase.crashlytics().recordError(e);
}

medium

A. Crashlytics reports a non-fatal error with message 'Test crash'

B. Crashlytics logs a warning but no error

C. App crashes immediately without reporting

D. No crash reported because error is caught

Solution

1. Step 1: Analyze try-catch behavior

   The error is thrown but caught, so the app does not crash.

2. Step 2: Understand recordError effect

   recordError() sends a non-fatal error report to Crashlytics with the error message.

3. Final Answer:

   Crashlytics reports a non-fatal error with message 'Test crash' -> Option A

4. Quick Check:

   recordError() = non-fatal error report [OK]

Hint: recordError() reports caught errors as non-fatal [OK]

Common Mistakes:

• Thinking caught errors cause app crash
• Assuming no report if error is caught
• Confusing recordError() with crash trigger

4. You added firebase.crashlytics().log('User clicked button'); but no logs appear in Crashlytics dashboard. What is the likely issue?

medium

A. Logs only appear after a crash occurs

B. log() method does not exist in Crashlytics

C. Crashlytics SDK is not initialized properly

D. You must call sendReport() to send logs

Solution

1. Step 1: Check Crashlytics log behavior

   Logs sent by log() appear only when a crash happens afterward.

2. Step 2: Verify other options

   SDK initialization is required but if logs never appear, it's likely due to no crash. log() exists and sendReport() is not a Crashlytics method.

3. Final Answer:

   Logs only appear after a crash occurs -> Option A

4. Quick Check:

   Logs show after crash [OK]

Hint: Logs appear only after crash triggers [OK]

Common Mistakes:

• Assuming logs show immediately
• Thinking log() method is missing
• Trying to send logs manually

5. How can you ensure that a caught error with extra context is reported to Firebase Crashlytics as a non-fatal issue with custom keys?

hard

A. Only use crashlytics().log() with error message

B. Use crashlytics().setCustomKey() before recordError()

C. Throw the error again to trigger a crash

D. Call crashlytics().sendReport() after catching error

Solution

1. Step 1: Add context with custom keys

   Use setCustomKey() to add extra info about the error context.

2. Step 2: Report error as non-fatal

   Call recordError() to send the caught error along with custom keys to Crashlytics.

3. Final Answer:

   Use crashlytics().setCustomKey() before recordError() -> Option B

4. Quick Check:

   Custom keys + recordError() = detailed non-fatal report [OK]

Hint: Set keys before recordError() for context [OK]

Common Mistakes:

• Only logging message without keys
• Throwing error again causes crash
• Using non-existent sendReport() method