Hi @jaygr,
Crashes are part of the Mobile LifeCycle metrics.
I am not sure if you are aware of the normal Lifecycle behaviour, so I am going to start with that, then show where the Crash logic fits in.
- User Opens App
- Lifecycle Events are fired, including
- Launches, DaysSinceLastLaunch, Upgrades, DaysSinceLastUpgrades, etc
- Page 1 Loaded (tracking for the page)
- Page 2 Loaded (tracking for the page)
- App Sent to the Background
- (Lifecycle Metrics Paused)
- App Brought Back to the Foreground
- (Lifecycle Metrics Resumed - this may or may not trigger lifecycle tracking, depending on how long the app has been in the background)
- App Sent to the Background
- (Lifecycle Metrics Paused)
- User "Swipes Off" (i.e. closes the application)
Now, the Crashes Metric is fired along with the other Lifecycle metrics... however, this only triggers if the app closes "unexpectedly"
Now, what that means is that, if the app closes while the lifecycle metrics are not paused, then Adobe will treat this as a crash.
So in the above scenario, if the app is sent to the background and the lifecycle metrics are not paused and the user swipes the app out of the background to close it... then Adobe will treat this as a crash... Likewise, I suspect if your app has a specific "close app" option for the user, I believe that the developers will need to pause the lifecycle metrics, then close the app.
As much as it would be amazing for the Crash metrics to really integrate into the app and detect proper crash data, it's really just a simplified method to detect when the app "closes while Lifecycle is running".
Improper Lifecycle implementation can lead to inflated "crashes" (we had that initially on our mobile apps when our developers didn't pause lifecycle metrics when the app was sent to the background... it resulted in almost 100% crash rate, lol.