Use Context rather than Application

[fractalwrench]

Goal

Uses Context rather than Application for initializing the SDK as originally discussed in #1257.

Context is a less specific type than Application which allows folks to initialize the SDK from places other than the Application subclass. Potential use-cases include:

• Jetpack Startup library
• ContentProvider initialization
• Initializing telemetry in an activity after explicit user opt-in

I do think that initializing from an Application subclass remains a sensible default & should be the recommended installation approach, but using Context gives the option for users to initialize in those use-cases if they wish.

[codecov]

Codecov Report

❌ Patch coverage is 90.69767% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 63.56%. Comparing base (80924e2) to head (175d839).

Files with missing lines	Patch %	Lines
...metry/android/agent/OpenTelemetryRumInitializer.kt	71.42%	1 Missing and 1 partial ⚠️
...ava/io/opentelemetry/android/OpenTelemetryRum.java	33.33%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1284      +/-   ##
==========================================
- Coverage   63.59%   63.56%   -0.03%     
==========================================
  Files         142      142              
  Lines        3046     3049       +3     
  Branches      302      303       +1     
==========================================
+ Hits         1937     1938       +1     
- Misses       1032     1033       +1     
- Partials       77       78       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[marandaneto]

Suggested change

	else -> context.applicationContext
	else -> context.applicationContext ?: context

applicationContext can be nullable in very specific cases

[fractalwrench]

@marandaneto out of curiosity, what are those specific cases?

[marandaneto]

if you init the SDK from a very specific lifecycle that is before the applicationContext is fully initialized.
i dont recall the name of the lifeyccle method, but the context instance type is ContextImpl and then the applicationContext is still null

[marandaneto]

found it, if you init the SDK from attachBaseContext, this will happen

[LikeTheSalad]

I think this relates to my comment here, where I was suggesting using Context.getApplicationContext() for cases where we might need an Application-specific functionality, such as listening to activities' lifecycle callbacks.

The fact that there's a risk of users initializing the agent using a Context object that won't provide the application context could mean that some specific features won't be able to initialize.

[fractalwrench]

IMO it is reasonable to document that as a caveat of this approach, specifically that if you attempt to initialize within attachBaseContext that lifecycle callbacks won't work. At Embrace we cast applicationContext to Application when setting lifecycle callbacks & anecdotally haven't experienced customers running into this issue. I do know that some folks want to initialize their SDK earlier than the Application lifecycle and I view it as a tradeoff that allows them to capture early telemetry that might be more important to them than other telemetry that might become harder to capture because of the change.

[marandaneto]

+1 on documenting but there's no reason not to fallback to context if applicationContext is null
if later on ctx isnt castable to Application, you just skip installing the features that wont work without it, thats how i've done many times before.

[marandaneto]

the current approach will assign null to ctx and then you cannot do almost anything if the SDK is init in the eg attachBaseContext lifecycle, so no telemetry at all.