bugsnag / bugsnag-android-performance

Monitor the start-up, screen loading and network requests of your Android app and see the results in your BugSnag dashboard.

Performance monitoring for Android

Monitor the start-up, screen loading and network requests of your app and see the results in your BugSnag dashboard.

Features

• Reporting of app startup time
• Automatic measurement of Activity loading times
• Report OkHttp request times

Getting started

For integration instructions, see our online docs: docs.bugsnag.com/performance/android

Support

• Read the integration guide
• Search open and closed issues for similar problems
• Report a bug or request a feature

License

The BugSnag Android Performance SDK is free software released under the MIT License. See the LICENSE for details.

bugsnag-android-performance's Issues

AppCompat: Ignore specific Activities/Fragments when instrumenting screen loads

Description

We use a headless Fragment to facilitate some custom Activity-related UI stuff and that Fragment gets picked up automatically by the FragmentActivityLifecycleCallbacks observer.
We don't really care about seeing Screen Load data for that specific Fragment class.

Describe the solution you'd like

It'd be great if there was a way to modify the configuration with a list of Fragment names/classes to ignore during that screen load instrumentation. I suspect the same strategy could apply to ignoring specific Activities from the Scree Loads instrumentation as well

Describe alternatives you've considered

No alternatives considered.
It's not that big of a deal having those headless Fragments show up in our Screen Loads page; would just be a nice-to-have feature.

Additional context

N/A

Ignore specific Activities when automatically instrumenting app starts

Description

App Start measurements don't align with anecdotal/real-world performance and average app start time seems to be lower than we expect it to be. Our app uses a separate activity as a loading screen before our main Activity is shown, and we suspect that automated Activity tracking for the first Activity is prematurely ending the App Start span, resulting in an inaccurate measurement.

Describe the solution you'd like

• I'd like to have a way to specify which Activity should be used when determining the end of the App Start span.
• I'd like to continue to use automatic Activity tracking.
• I'd like to continue to see View Load spans for all Activities.

Describe alternatives you've considered

Refactoring our app loading sequence to remove the loading screen Activity and move to a truly single Activity architecture.

Additional context

I'm making assumptions around the behavior of the SDK and the results we're seeing here.
If there's a way for me to confirm which Activity instance is being used to determine my App Start "end" time, I'd be happy to help triage this (as there's a chance that this might be working correctly from the start)