You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For AOT-compiled apps, it's currently not possible to symbolicate class types because debug files don't contain the minified name to associate with the symbolicated name.
The very same problem exists with Flutter Web and source maps, the source maps contain the minified name but not the symbolicated name.
When compiling your Fluter app with obfuscation enabled, you can combine it with an extra parameter that spits out a mapping file (--save-obfuscation-map).
The mapping.json file contains the information we need to symbolicate class types.
This file should be uploaded to Sentry via the Dart plugin and Sentry CLI, then the Sentry symbolication process should take that into consideration, it's somehow similar to a proguard mapping file.
The first thing that should be symbolicated is the exception.type which is responsible for building the issue's titles as well.
We can expand that later on for VH, breadcrumbs, etc.
For Flutter Web, there's no way to associate the mapping file via a buildId of sorts, the current way is only possible via release and dist similar to source maps which is problematic, hence asking support for that natively (Also on Web) dart-lang/sdk#51941.
For Flutter AOT apps, Flutter's beta channel already supports reading the buildId at runtime, via dart-lang/sdk#51941
It'd be possible to associate the mapping file with this Id, most likely we need to associate the mapping file with multiple Ids since the apps can be compiled with different architectures/bundles/etc, most likely generating multiple buildIds, but still a single mapping file.
Sentry-CLI/or tools like readelf could read the buildIds (code id section) of the compiled binaries and upload the mapping file making the association with such Ids.
Sentry SDK sets the buildId at runtime in the event.debug_meta similar to proguard, so the only process left is to do the symbolication during event ingestion.
The text was updated successfully, but these errors were encountered:
Description
Depends on getsentry/sentry#48334, dart-lang/sdk#51941
For AOT-compiled apps, it's currently not possible to symbolicate class types because debug files don't contain the minified name to associate with the symbolicated name.
The very same problem exists with Flutter Web and source maps, the source maps contain the minified name but not the symbolicated name.
When compiling your Fluter app with obfuscation enabled, you can combine it with an extra parameter that spits out a mapping file (
--save-obfuscation-map
).flutter build ios --split-debug-info=symbols --obfuscate --extra-gen-snapshot-options=--save-obfuscation-map=mapping.json
The
mapping.json
file contains the information we need to symbolicate class types.This file should be uploaded to Sentry via the Dart plugin and Sentry CLI, then the Sentry symbolication process should take that into consideration, it's somehow similar to a proguard mapping file.
The first thing that should be symbolicated is the
exception.type
which is responsible for building the issue's titles as well.We can expand that later on for VH, breadcrumbs, etc.
For Flutter Web, there's no way to associate the mapping file via a
buildId
of sorts, the current way is only possible viarelease
anddist
similar to source maps which is problematic, hence asking support for that natively (Also on Web) dart-lang/sdk#51941.For Flutter AOT apps, Flutter's beta channel already supports reading the
buildId
at runtime, via dart-lang/sdk#51941It'd be possible to associate the mapping file with this Id, most likely we need to associate the mapping file with multiple Ids since the apps can be compiled with different architectures/bundles/etc, most likely generating multiple
buildId
s, but still a single mapping file.Sentry-CLI/or tools like
readelf
could read thebuildId
s (code id
section) of the compiled binaries and upload the mapping file making the association with such Ids.Sentry SDK sets the
buildId
at runtime in theevent.debug_meta
similar to proguard, so the only process left is to do the symbolication during event ingestion.The text was updated successfully, but these errors were encountered: