bug / feature-request: instead of "Unhandled Exception" give actual exception's name in ERA Viewer

We're getting lots of "Unhandled Exceptions" in ERA, but there's no such exception. I don't see any reason why Garmin would intentionally hide the real exception form the developers (especially that the documentation mentions some possible exceptions)

Note that the exception message see you see in a normal crash log [e.g. when debugging locally or via debug sideload] is not literally the class name of the exception, but it's the error message returned by Exception.getErrorMessage (which is usually close enough to the class name that you can guess which exception class it refers to).

It's been mentioned in the past that the exception message is omitted from ERA logs to prevent apps from covertly smuggling out user data via exceptions.

Source:

https://forums.garmin.com/developer/connect-iq/f/discussion/193579/era-crash-log-viewer---check-it-out-if-you-haven-t/942192#942192

Travis.ConnectIQ said:

can a developer change the debug.xml content , provoke a crash and get this data via ERA ?

No.

We don't send exception strings or error messages that the developer may manipulate to smuggle data off of the device. We sell these devices in Europe, so we are bound by GPRD to not send anything that could be used to personally identify anyone.

We currently capture the following data when a crash occurs:

• time/date of the crash
• device part number (this tells us what device model was used, this is not the unique device id)
• device firmware version
• active language
• ConnectIQ SDK version used to build the app
• ConnectIQ app store id (to identify the crashing app)
• ConnectIQ app store app version
• name of the .PRG file that crashed
• name of the app that crashed
• stack trace of the crash
• the crash type (out-of-memory, symbol not found, ...)

The entire crash log is uploaded, but some of this data is not used by the ERA system. For example, the PRG and app name are there to help users locate and eliminate problem apps on the device and is not useful in reporting crashes via the ERA service.

With regards to the actual exception class name, Travis.ConnectIQ said this 7 months ago:

https://forums.garmin.com/developer/connect-iq/f/discussion/388311/array-data-size-limit/1849875#1849875

We can get the exception class name in a debug build pretty easily. In a release build that requires access to debug.xml and post-processing as is done with the ERA service.

I'll file a ticket to add the exception class id to the log and some lookup mechanism on the backend for the ERA service.

So it seems there is already an internal ticket to address what you are asking for.

We're getting lots of "Unhandled Exceptions" in ERA, but there's no such exception. I don't see any reason why Garmin would intentionally hide the real exception form the developers (especially that the documentation mentions some possible exceptions)

Note that the exception message see you see in a normal crash log [e.g. when debugging locally or via debug sideload] is not literally the class name of the exception, but it's the error message returned by Exception.getErrorMessage (which is usually close enough to the class name that you can guess which exception class it refers to).

It's been mentioned in the past that the exception message is omitted from ERA logs to prevent apps from covertly smuggling out user data via exceptions.

Source:

https://forums.garmin.com/developer/connect-iq/f/discussion/193579/era-crash-log-viewer---check-it-out-if-you-haven-t/942192#942192

Travis.ConnectIQ said:

can a developer change the debug.xml content , provoke a crash and get this data via ERA ?

No.

We don't send exception strings or error messages that the developer may manipulate to smuggle data off of the device. We sell these devices in Europe, so we are bound by GPRD to not send anything that could be used to personally identify anyone.

We currently capture the following data when a crash occurs:

• time/date of the crash
• device part number (this tells us what device model was used, this is not the unique device id)
• device firmware version
• active language
• ConnectIQ SDK version used to build the app
• ConnectIQ app store id (to identify the crashing app)
• ConnectIQ app store app version
• name of the .PRG file that crashed
• name of the app that crashed
• stack trace of the crash
• the crash type (out-of-memory, symbol not found, ...)

The entire crash log is uploaded, but some of this data is not used by the ERA system. For example, the PRG and app name are there to help users locate and eliminate problem apps on the device and is not useful in reporting crashes via the ERA service.

With regards to the actual exception class name, Travis.ConnectIQ said this 7 months ago:

https://forums.garmin.com/developer/connect-iq/f/discussion/388311/array-data-size-limit/1849875#1849875

We can get the exception class name in a debug build pretty easily. In a release build that requires access to debug.xml and post-processing as is done with the ERA service.

I'll file a ticket to add the exception class id to the log and some lookup mechanism on the backend for the ERA service.

So it seems there is already an internal ticket to address what you are asking for.