RUM-7005: updating dependencies, adjusting detekt rules, fix tests

[satween]

What does this PR do?

We’re updating androidx.navigation to 2.8.0. Our goal is to maintain a balance between using stable library versions and minimizing disruptive changes to our customers’ codebases.

Motivation

This update motivated by contributor request

Additional Notes

Anything else we should know when reviewing?

Review checklist (to be filled by reviewers)

• Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
• Make sure you discussed the feature or bugfix with the maintaining team in an Issue
• Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)

[xgouchet]

Note

Nice work, one question I have is, do we need to upgrade other AndroidX dependencies?
As a rule of thumb, I'd suggest upgrading our dependencies to the other AndroidX dependencies to versions released around the same time as 2.7.7 (i.e.: February 2024).

[satween]

Note

Nice work, one question I have is, do we need to upgrade other AndroidX dependencies? As a rule of thumb, I'd suggest upgrading our dependencies to the other AndroidX dependencies to versions released around the same time as 2.7.7 (i.e.: February 2024).

I've updated rest of the android libs to be aligned to the navigation. navigation lib upgraded to 2.8.0 as it contains few leaks fixes

[0xnm]

what brings this to the list? lifecycle libs update?

[satween]

Answered above, many of androidx libs depends on that

[0xnm]

looks like it is coming from work-runtime update originally in the core module?

[satween]

not only work-runtime, but also some of the androidx libs as well. As described below, seems like I found combination of libs that not brings coroutines as a dependency. But in a future updates they will be added anyway

[0xnm]

So maybe we should stay with 2.8.1 to avoid bringing coroutines? or maybe we can exclude them if they are not used in our code paths?

This is just an idea, I'm curious to see more opinions.

[satween]

I dont want to exclude any of dependencies, because we could create unstable build this way. Rolled back all androidX libs that could add coroutines as a transitive dependency. But we will face this problem in a future anyway

[0xnm]

yes, staying with work-runtime:2.8.1 seems safest, I don't see any fixes/changes that would impact our usage flows in 2.9.1.

[0xnm]

looks like it is coming from work-runtime update originally in the core module?

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 83.33333% with 3 lines in your changes missing coverage. Please review.

Project coverage is 69.92%. Comparing base (c29bc1f) to head (a5709c3).
Report is 11 commits behind head on develop.

Files with missing lines	Patch %	Lines
...nal/tracking/AndroidXFragmentLifecycleCallbacks.kt	50.00%	0 Missing and 3 partials ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #2463      +/-   ##
===========================================
+ Coverage    69.91%   69.92%   +0.01%     
===========================================
  Files          787      787              
  Lines        29347    29349       +2     
  Branches      4895     4898       +3     
===========================================
+ Hits         20516    20520       +4     
  Misses        7470     7470              
+ Partials      1361     1359       -2     

Files with missing lines	Coverage Δ
...lin/com/datadog/android/compose/InteractionType.kt	100.00% <100.00%> (ø)
...id/compose/internal/InternalInteractionTracking.kt	91.43% <100.00%> (-0.16%)	⬇️
...nal/tracking/AndroidXFragmentLifecycleCallbacks.kt	91.89% <50.00%> (-2.70%)	⬇️

... and 35 files with indirect coverage changes

[0xnm]

having coroutines as a part of Compose is fine I think, it is an essential part of the apps using Compose in most cases, so we can go higher here. The total size of transitive dependencies for dd-sdk-android-compose is big already anyway.