Add more device context
Events from iOS have less device context than, for example, events from Android. We can add more.
iOS
"device": {
"family": "iOS",
"model": "iPhone13,2",
"model_id": "D53gAP",
"memory_size": 3883876352,
"free_memory": 88358912,
"usable_memory": 2271002624,
"storage_size": 63870980096,
"boot_time": "2021-07-19T18:15:30Z",
"timezone": "CEST",
"type": "device"
}
Android
"device": {
"name": "Pixel 2 XL",
"family": "Pixel",
"model": "Pixel 2 XL",
"model_id": "RP1A.201005.004.A1",
"battery_level": 100.0,
"orientation": "portrait",
"manufacturer": "Google",
"brand": "google",
"screen_density": 3.5,
"screen_dpi": 560,
"online": true,
"charging": true,
"low_memory": false,
"simulator": false,
"memory_size": 3839954944,
"free_memory": 2134429696,
"storage_size": 55782412288,
"free_storage": 46677245952,
"boot_time": "2021-07-19T11:13:52.575Z",
"timezone": "Europe/Vienna",
"archs": [
"arm64-v8a",
"armeabi-v7a",
"armeabi"
],
"battery_temperature": 30.6,
"connection_type": "wifi",
"id": "9cd59ebb-583b-474b-8ad1-15af30ba62d1",
"language": "en_US",
"screen_height_pixels": 2712,
"screen_width_pixels": 1440,
"type": "device"
}
Unity also has some things that might be unique to that SDK. Ultimately we try to keep those documented/aligned here:
https://develop.sentry.dev/sdk/event-payloads/contexts/#device-context
We could benefit from a table SDK x Spec so we can spot anything we're missing in the spec and opportunities for new info in SDKs.
Some potential reference (cross platform libs):
https://github.com/xamarin/Essentials/tree/main/Xamarin.Essentials
https://github.com/fluttercommunity/plus_plugins
The following repo might be helpful for getting the connection type https://github.com/Isuru-Nanayakkara/Reach
Connection Type came up again in the context of React Native, a work around there was:
Use a library such as: https://github.com/react-native-netinfo/react-native-netinfo and use our SDK to add the data. Like:
NetInfo.addEventListener(state => {
Sentry.setTag("connection_type", state.type);
Sentry.setTag("is_connected", state.isConnected);
});
When we add a built-in support, we need to make sure the values are tagged aligned beteween iOS and Android so hybrid SDKs can rely on it to group issues. It is likely going to surface on transactions too to segment those based on connection quality
iOS:
"device": {
"family": "iOS",
"model": "iPhone13,1",
"model_id": "D52gAP",
"arch": "arm64",
"memory_size": 3863298048,
"free_memory": 84934656,
"usable_memory": 2587443200,
"storage_size": 63870980096,
"boot_time": "2022-09-12T05:45:21Z",
"locale": "en_NL",
"type": "device"
},
But we also have this:
"culture": {
"calendar": "Gregorian Calendar",
"display_name": "English (Netherlands)",
"is_24_hour_format": true,
"locale": "en_NL",
"timezone": "Europe/Amsterdam",
"type": "culture"
},
Most interesting to add:
- battery_level
- orientation
- charging
- screen_height_pixels
- screen_width_pixels
- free_storage
Not so useful:
- name: do you really need to know the name of the device? Plus that usually has PII, like "Kevin Renskers' iPhone"
- manufacturer and brand: always Apple anyway
Not sure about usefulness or feasibility:
- low_memory: we report the available memory, but how would we know if that's low or not?
- online / connection_type: do we want to use Apple's Reachability class for this? It's quite low level code, and not the most reliable in my experience. Most people use a third-party ObjC wrapper for this stuff.
- screen_density: there is no API for this for iOS, so we'd have to hardcode them based on device type
- battery_temperature: impossible, there is no public API for this, and since iOS 10 beta 1 access to raw data is removed as well
- screen_dpi: we can get the scale (1x, 2x, 3x), but not the DPI without hardcoding them based on device type. There is no documented property for a device scale like this though.
online / connection_type: do we want to use Apple's Reachability class for this? We definitely don't want to add a third party library for such a small feature. Either we use their approach and give them
credit, or we use the Apple's Reachability class, or we don't do it.
screen_density
I think it's not that important on iOS as the variety of devices is not so big. You usually know what the density is.
battery_temperature
Let's drop it then.
screen_dpi
See screen_density.
Hi @kevinrenskers, I saw your pr was merged. I'm specifically interested in the device properties for iOS.
I am particularly interested in free_memory and usable_memory from this blob you added above:
"device": {
"family": "iOS",
"model": "iPhone13,1",
"model_id": "D52gAP",
"arch": "arm64",
"memory_size": 3863298048,
"free_memory": 84934656,
"usable_memory": 2587443200,
"storage_size": 63870980096,
"boot_time": "2022-09-12T05:45:21Z",
"locale": "en_NL",
"type": "device"
},
When I look at a Sentry issue (see screenshot below), I do see usable memory, but I do not see free memory. Do we have access to free memory? Perhaps free memory in the json blob maps to memory size?
cc: @philipphofmann
I see free_memory being displayed as Free Memory in the screenshot below.
It should be displayed, @chaseklingelzen. FYI, @kevinrenskers is not working anymore on this repo.
I see free_memory being displayed as
Free Memoryin the screenshot below.
It should be displayed, @chaseklingelzen. FYI, @kevinrenskers is not working anymore on this repo.
Hi @philipphofmann thanks for letting me know about Kevin. Interesting... I do see Free Memory on Sentry issues that are not watchdog termination issues. I suppose it would make sense that free memory doesn't show on watchdog termination issues because the issue is related to being out of memory. Does that seem reasonable as to why it isn't showing up on watchdog termination issues?
I suppose it would make sense that free memory doesn't show on watchdog termination issues because the issue is related to being out of memory. Does that seem reasonable as to why it isn't showing up on watchdog termination issues?
Yes, exactly. I opened a PR to clarify that in the docs https://github.com/getsentry/sentry-docs/pull/8847.
