Profiling: color code non-application user code (shared libraries etc).

[realkosty]

Problem Statement

On Android we currently color-code any frame outside of applicationID namespace as "system". This doesn't work well when I have

com.mycompany.android.* // application code
com.mycompany.common.* // general-purpose shared code

Solution Brainstorm

I'd consider the following in this order:

• treat library frames as "Application" - what devs likely care about is whether they have control over the implementation of a function or not, not what namespace it's in.
  • even better color Application Library frames in slightly different shade of purple blue than proper Application frames.
• new option in the dropdown: "By System vs Application + Library Frame"
• add toggle to Settings and hope people will find it

Product Area

Profiling

┆Issue is synchronized with this Jira Improvement by Unito

[getsantry[bot]]

Assigning to @getsentry/support for routing ⏲️

[getsantry[bot]]

Routing to @getsentry/product-owners-profiling for triage ⏲️

[JonasBa]

treat library frames as "Application" - what devs likely care about is whether they have control over the implementation of a function or not, not what namespace it's in.

We need to be careful about how we define control here. For example just because something is a system fn, it does not mean you dont have control over it. In most cases you can still have the ability to not call it regardless if it's a direct or indirect call.

The library option is interesting, but would only work in cases where library code can be somewhat reliably inferred and I dont know how well we can do that. That said, I think it's the correct way forward and would help in other areas.

[Zylphrex]

One possible path forward is to bring stack traces in profiles closer to stack traces in errors by supporting stack trace rules to process the frames and add the in app labels to some frames.