Closed Bug 1812771 Opened 1 year ago Closed 4 months ago

Fenix crash reporter's Socorro crash reports for Java exceptions have "Platform" = "Unknown" instead of "Android"

Categories

(Socorro :: Processor, defect, P2)

All
Android

Tracking

(Not tracked)

RESOLVED FIXED

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.

Severity: -- → N/A
Priority: -- → P3
Severity: N/A → S3

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?

Anyone object if I put this in Socorro::Processor?

SGTM. I'll move the bug now.

Component: Crash Reporting → Processor
Priority: P3 → --
Product: Fenix → Socorro
Assignee: nobody → willkg
Severity: S3 → --
Status: NEW → ASSIGNED
Priority: -- → P2

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?

Flags: needinfo?(cpeterson)

(In reply to Will Kahn-Greene [:willkg] ET needinfo? me from comment #3)

Chris: Is that using the api version in the os_version and os_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:

https://crash-stats.mozilla.org/search/?android_version=%21~%28REL%29&product=Fenix&product=Focus&process_type=parent&date=%3E%3D2023-07-12T20%3A49%3A00.000Z&date=%3C2024-01-12T20%3A49%3A00.000Z&_facets=product&_facets=version&_facets=signature&_facets=android_version&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-android_version

Flags: needinfo?(cpeterson) → needinfo?(willkg)

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:

  1. have minidump
  2. 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.

Flags: needinfo?(willkg)

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.

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.

Status: ASSIGNED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: