Use App Startup library instead of ContentProvider

[minyushov]

Could you please consider using androidx.startup:startup-runtime instead of ContentProvider introduced in #1487?

Jetpack libraries (e.g. WorkManager) are migrating from ContentProvider to App Startup library in order to improve app startup performance and to achieve predictable order of initialization. It would be very nice if Sentry does the same.

Documentation: https://developer.android.com/topic/libraries/app-startup

[bruno-garcia]

I'm not sure we can be adding a dependency to androidx.startup:startup-runtime directly anytime soon but perhaps there's a way to check at runtime if it's available, or have install instructions for users to avoid the content provider and use this approach instead.

@marandaneto thoughts?

[marandaneto]

yep, the problem is depending on the library, when startup-runtime gets popular and implemented by all the android libs, could be possible, not yet.

you can always go for the manual init. https://docs.sentry.io/platforms/android/configuration/manual-init/ and remove the merging of the ContentProvider

[androideveloper]

This is indeed a nice improvement.

With the current setup, what would be the best way to initialize Sentry first? I'm thinking about increasing the initOrder of the content provider SentryInitProvider. But also curious, why you don't have it in the code similar to SentryPerformanceProvider that is set to 200? Firebase crashlytics has 100 for their content provider.

[romtsn]

I'm not sure why we didn't set the priority, @marandaneto knows probably

[marandaneto]

It is set, p2

[romtsn]

I meant for the SentryInitProvider the initOrder is not set, do you know why?

[androideveloper]

I tried that and it it indeed helps init Sentry provider a bit early. But if we have an app start crash in the next content providers, Sentry doesn't have time to upload the logs. See #1643

[lukehutch]

The androidx.startup library uses ContentProvider under the hood:

https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:startup/startup-runtime/src/main/java/androidx/startup/InitializationProvider.java;drc=2f9dd0f2fe4642438ed3f657dc7f901241a16ca8

[marandaneto]

The androidx.startup library uses ContentProvider under the hood:

cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:startup/startup-runtime/src/main/java/androidx/startup/InitializationProvider.java;drc=2f9dd0f2fe4642438ed3f657dc7f901241a16ca8

Yes, but only one instead of N, that's the difference.

[Angelodaniel]

Hey @kahest is there any progress on this?

[markushi]

Quick update on this topic, as we recently discussed it.
We'll keep on using a ContentProvider for now, as it allows us to init the SDK early (potentially capturing app start crashes) as well as measuring the app start time.

#1643 has been implemented for a while, meaning if the SDK detects and app start crash it will block execution (even on the main thread) to ensure there's enough time to send the crash report to sentry.io

However, in the long run we plan to move away from using ContentProvider and instead provide our own AppComponentFactory (see #3149)

cc @Angelodaniel

[markushi]

Thanks everyone for voting, this helps us re-priortize issues like this one!