Agent transitively upgrades androidx.core / androidx.navigation in consuming apps

[SenNeonoveNoci]

android-agent currently brings AndroidX dependencies into consuming applications transitively, including at least:

• androidx.core
• androidx.navigation-runtime-ktx
• androidx.navigation-fragment

From inspecting the repository and generated publication metadata, this appears to come from:

• android-agent depending on core, services, and instrumentation:fragment
• core publishing androidx.core
• services publishing androidx.navigation-runtime-ktx
• instrumentation:fragment publishing androidx.navigation-fragment

The main concern is that adding android-agent can affect dependency resolution in host applications and potentially change application behavior, even when the app is not explicitly trying to change its AndroidX versions.

Could you confirm whether it is intentional for android-agent to export these AndroidX dependencies transitively?

If not, it might be worth trimming down the transitive dependency surface a bit, especially around androidx.core and navigation-related artifacts.

Example impact we saw

In one of our client applications, after adding our Agent (splunk-otel-android) that uses opentelemetry-android, dependency resolution changed as follows:

• androidx.core: 1.15.0 -> 1.16.0
• androidx.navigation: 2.7.5 -> 2.7.7

In that app, this correlated with a different startup execution path that caused flickering / periodic recomposition during startup. Forcing those dependencies back to their previous versions removed the issue.

I understand that the application-side behavior is specific to clients app, but the transitive dependency upgrade itself appears to be reproducible and comes from android-agent.

[fractalwrench]

Thanks for reporting this @SenNeonoveNoci. I think there is work we can do to minimise the amount of transitive dependencies. For :core at least I don't see why the androidx.core dependency is required; we could remove that.

services probably needs splitting out into other modules generally. That's something we should work on before stabilising that module.

For instrumentation, it's a bit harder to avoid bringing in transitive dependencies. I believe it should be possible to exclude the instrumentation:fragment module (although I haven't tested that). Or alternatively, just downgrading the transitive dependency should generally be fine.

[surbhiia]

1. Use minimum needed version - Some dependencies might be difficult to get rid of (like androidx.core, androidx.annotation, androidx.lifecycle) but there's a strategy that can work:

• It's only a problem when we upgrade the host app's dependency to a higher version, it's not a problem when host app's version is already higher than ours as Gradle resolves it to that higher version itself.
• So, our SDK should keep the versions to the minimum needed instead of upgrading to the highest available:
  • That way the host app's version would come into effect most often as it would be higher
  • If host app uses a lower version, then that feature from our SDK won't work for them anyway.

(androidx.core is added to almost all modules in our SDK but that is probably not needed, but it is sort of a base androidx dependency that could be required more often that's why included it as an example above but we can probably limit it's usage in our SDK and lower the version too. )

2. Keep as compileOnly - Another solution where possible is to keep dependencies compileOnly when they're used at compile time only, this makes them invisible to host apps. Good contenders for this is:

• com.google.code.findbugs:jsr305:3.0.2
• com.google.auto.service:auto-service-annotations:1.1.1
  (These dependencies are there in almost all modules)

3. Isolate into a separate module - Another solution is to isolate those specific dependency containing code files to their own module to prevent spilling those dependencies to places where they're not needed. A good contender for this is visible screen service to exclude androidx.fragment.

4. Use reflection (where possible) - Could be a good strategy (or good interim strategy) at some places. Example PR.

---

androidx.lifecycle is used for app lifecycle service which is used in session management, ANR and network instrumentations, it is potentially part of solution 1 (use lower version) here but should it be instead part of solution 3 (separate module)?

[surbhiia]

Based on the discussion in the last Android SIG meeting:

• Reflection is fragile and shouldn't be used.
• We have to be careful while deciding to go with minimum needed versions as there could be an inverse problem of those APIs/functionalities not behaving exactly how we want it, in latest versions as all libraries are not always fully backward compatible. So, carefully analyze when going with option 1.
• 2 and 3 are favorable solutions where possible.