Fenix crash reporter's Socorro crash reports for Java exceptions have "Platform" = "Unknown" instead of "Android"
Categories
(Socorro :: Processor, defect, P2)
Tracking
(Not tracked)
People
(Reporter: boek, Assigned: willkg)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
From github: https://github.com/mozilla-mobile/fenix/issues/23977.
Steps to reproduce
More than half of the Socorro crash reports from Fenix or Focus have "Platform" == "Unknown" instead of "Android".
The Socorro crash reports with Platform == "Android" are all native code crashes.
The Socorro crash reports with Platform == "Unknown" are all Java exceptions.
Expected behaviour
All Socorro crash reports from Fenix or Focus should have "Platform" == "Android".
Actual behaviour
Socorro crash reports for Java exceptions from Fenix or Focus have "Platform" == "Unknown".
Device name
No response
Android version
Android 10
Firefox release type
Firefox
Firefox version
97.0
Device logs
No response
Additional information
No response
βIssue is synchronized with this Jira Task
Change performed by the Move to Bugzilla add-on.
Updated•2 years ago
|
Updated•1 year ago
|
Assignee | ||
Comment 1•10 months ago
|
||
This should be a Socorro bug. The platform data comes from the minidump. In cases where the crash report doesn't have a minidump, Socorro's processor should intuit the value from somewhere else.
Anyone object if I put this in Socorro::Processor?
Comment 2•10 months ago
|
||
Anyone object if I put this in Socorro::Processor?
SGTM. I'll move the bug now.
Assignee | ||
Updated•10 months ago
|
Assignee | ||
Comment 3•8 months ago
|
||
The crash annotations let me build a processor rule that knows if the os is Android. There's a Android_Version
annotation that includes the API version and the release name. This is a value like 23 (REL)
. I can map sdk versions back to Android os versions using this table:
https://en.wikipedia.org/wiki/Android_version_history
However, it's not a good mapping because it's one-to-many. For example, 23 (REL)
is either Android 6.0 or 6.0.1. There isn't additional information in the Android_*
annotations to determine which os version the crash report is from.
It'd help if we added another annotation that captured the os version. Maybe something from Build.VERSION
gives us the specific Android version?
Alternatively, we can forego the Android os version and use the api version. Then we'd get values like this:
key | val |
---|---|
os_name |
Android |
os_version |
23 |
os_pretty_name |
Android 23 |
Chris: Is that using the api version in the os_version
and os_pretty_name
fields ok?
Assignee | ||
Updated•8 months ago
|
Comment 4•8 months ago
|
||
(In reply to Will Kahn-Greene [:willkg] ET needinfo? me from comment #3)
Chris: Is that using the api version in the
os_version
andos_pretty_name
fields ok?
I think using the API version is fine, especially since we already have the data. Using the API version directly will be more reliable than a version map that needs to be updated. Android engineers will understand that os_version
"Android 23" means "API 23".
I think reporting both Android versions 6.0 and 6.0.1 as API 23 is fine. The platform differences between 6.0 and 6.0.1 are probably small or irrelevant to Firefox Android, definitely smaller than the differences between "23 (REL)" on Google and Samsung devices.
How will you handle API version strings that have a description other than (REL)
? For example, I see crash reports from 34 (REL)
, 34 (VanillaIceCream)
, and 34 (UpsideDownCakePrivacySandbox)
. Would you map them all to os_version
34
?
I only see a couple hundred reports with API version without (REL)
, so maybe this is a corner case we don't care about:
Assignee | ||
Comment 5•8 months ago
|
||
Android_Version
includes the API version and the release name. I was doing to pick out the API version and drop the release name.
So, we've got two cases to think about:
- have minidump
- does not have minidump
When the crash report has a minidump, we get values like this:
os_name
:Android
os_version
:0.0.0 Linux 4.9.227-perfβ¦:46:26 KST 2023 aarch64
os_pretty_version
:Android
Example: bp-5c0ac05f-c501-4d1b-b75f-eefe80240117
When the crash report does not have a minidump, we get values like this:
os_name
:Unknown
os_version
: (empty-string)os_pretty_version
:Unknown
Example: bp-cb1c390f-996f-41ea-a0bd-6dbba0240117
I want to change this to use the first part of Android_Version
. So then in both cases, we'd get something like this:
Android_Version
:23 (REL)
os_name
:Android
os_version
:23
os_pretty_version
:Android 23
We'd add a note in the data dictionary for os_version
and os_pretty_version
that the version for Android devices is the sdk version.
Further, we can reprocess existing crash reports if we want to pick up new values for os_name
, os_version
, and os_pretty_version
. If we decide later that having something like Android 23
isn't helpful and we really want the Android version, then we can fix it and re-reprocess--no biggie.
I'll work on that now.
Assignee | ||
Comment 6•8 months ago
|
||
Assignee | ||
Comment 7•8 months ago
|
||
willkg merged PR [mozilla-services/socorro]: bug-1812771: clean up processor rules for java/android things (#6517) in f16905f.
Assignee | ||
Comment 8•8 months ago
|
||
Assignee | ||
Comment 9•8 months ago
|
||
willkg merged PR [mozilla-services/socorro]: bug-1812771: fix os_name, os_version, and os_pretty_version for Android (#6518) in 32ccc16.
This will radically clean up os_name
, os_version
, and os_pretty_version
for Android crash reports. It'll go out in the next Socorro prod deploy. Then we can figure out if we want to reprocess any crash reports.
Assignee | ||
Comment 10•7 months ago
|
||
This went out just now in bug #1877518. Crash reports from android (C++/Rust and Java) should have the os_name
, os_version
, and os_pretty_version
set correctly now.
Description
•