Mobile crash event

[LikeTheSalad]

Changes

Add a new device.crash event for mobile application crashes, which has been used for a while already in the OTel Android crash instrumentaion.

Important

Pull requests acceptance are subject to the triage process as described in Issue and PR Triage Management.
PRs that do not follow the guidance above, may be automatically rejected and closed.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• Links to the prototypes or existing instrumentations (when adding or changing conventions)

[kamphaus]

Why is the event called device.crash and not something like mobile.app.crash?
Does device.crash imply a fatal error of the device OS and not of a mobile app?

[thompson-tomo]

I agree, app.exception would be an even better naming option which would complement #3426 etc

[LikeTheSalad]

Why is the event called device.crash and not something like mobile.app.crash?
Does device.crash imply a fatal error of the device OS and not of a mobile app?

I agree, app.exception would be an even better naming option which would complement #3426 etc

It's a good point. I believe we've used device.crash in OTel Android for a while due to historic reasons, as in the beginning of events there was an "event.domain" attribute, which we set to "device" back then, whereas the "event.name" was only "crash", but then the domain attribute was removed so we merged the 2 and got to "device.crash". But without that context, it certainly sounds as though we say that the whole device has crashed. Events have changed a lot since, so I'm not opposed to changing it. Now, regarding the proposed names in this thread:

• mobile.app.crash
• app.exception

I would like to keep some consistency with existing mobile-related event names, and iiuc none nowadays start with mobile.*. Also, "exception" is a broad term, and a mobile crash is an important event on its own for Android devs, so it should keep reading "crash" in its name.

With that in mind, and after taking a look at existing mobile-related events, I think we have a couple of options:

• device.app.crash (consistent with the current "device.app.lifecycle" one).
• app.crash (consistent with multiple "app.*" events, such as "app.screen.click" and "app.jank").

[kamphaus]

device.app.crash sounds good to me.

For app.crash I'm wondering if it is also applicable to other types of applications (eg. web apps).
Would we also define app.exception (eg. for recording non-fatal errors) and would this cause some duplication for fatal errors?

[LikeTheSalad]

For app.crash I'm wondering if it is also applicable to other types of applications (eg. web apps).

I'm curious about it too. Maybe @martinkuba or @david-luna could help?

Would we also define app.exception (eg. for recording non-fatal errors) and would this cause some duplication for fatal errors?

I'm not sure about it. In my experience so far, non-fatal exceptions have always been part of some bigger task where they were expected, such as an HTTP call that failed, for example, where we set the exception with plain "exception.*" attrs. If no task expects an exception and it reaches the app's exception handler, then we get a crash. Because of it, I cannot see the need to define an event for "standalone-non-fatal" exceptions for mobile apps.

[thompson-tomo]

I much rather use the app namespace instead of device.

Would we also define app.exception (eg. for recording non-fatal errors) and would this cause some duplication for fatal errors?

We Could use an attribute on app.exception to distinguish between fatal & non-fatal exceptions?

[LikeTheSalad]

We Could use an attribute on app.exception to distinguish between fatal & non-fatal exceptions?

Could you mention some use cases where a standalone-non-fatal exception event might be needed for mobile apps?

[thompson-tomo]

An example would be the app passes user input/form data to a third party library which throws a validation exception. Having this as an app.exception allows us to recomend the screen etc which triggered the exception.

[LikeTheSalad]

Thanks for the example. I haven't bumped into a similar use case yet, but it's not unlikely, and if there's no other namespace for the third-party library, then it's feasible.

In that case, and given how important it is in Android development to talk about crashes, I'd prefer to have 2 event names, one "[device.]app.crash" and one "[device.]app.exception", which seem descriptive enough to avoid relying on flags to distinguish similar yet dramatically different events in terms of priorities and the visibility they need.

[LikeTheSalad]

Thank you for your inputs @kamphaus and @thompson-tomo. @bidetofevil has volunteered to create a broader, more precise definition for app crashes across multiple PRs, starting with this one, which covers the basics already covered here and also defines a better name (app.crash) for it. If you're interested in continuing to follow this event, please take a look at that other PR.

[bidetofevil]

@LikeTheSalad Per the SIG meeting today, I've submitted the PR for the basic definition of the crash event in #3448. There's a subsequent PR that includes a more complex payload definition that we previously discussed, but I want to get this in first hoping that what this contains is less controversial

[LikeTheSalad]

@LikeTheSalad Per the SIG meeting today, I've submitted the PR for the basic definition of the crash event in #3448. There's a subsequent PR that includes a more complex payload definition that we previously discussed, but I want to get this in first hoping that what this contains is less controversial

Thanks, @bidetofevil. I'll close this PR, and let's continue over there.