feat(instrumentation-all): introduce aggregate dependency bundling all instrumentation ([#1024](https://github.com/marcschaeferger/opentelemetry-android/issues/1024))

[marcschaeferger]

Pull Request: Add instrumentation:all Gradle Module

Issue: #1024 – Add instrumentation-all package

---

Summary

This PR adds a new Gradle module instrumentation:all that aggregates all end-user Android instrumentation libraries into a single dependency for quick evaluation and experimentation. It is designed to help users explore OpenTelemetry Android's full feature set without having to manage multiple individual dependencies.

Issue requested an "instrumentation-all" package to lower the onboarding friction when evaluating OpenTelemetry Android.
By offering a single aggregate module, developers can quickly test features for demos, Proof-of-Concepts, and exploratory instrumentation without manually tracking individual modules, making adoption and initial evaluation significantly simpler.

All Suggestions and changes are welcome ;-)

---

What's Included

• New module: instrumentation:all
• Dependencies:
  • Instrumentation:
    • activity
    • anr
    • crash
    • fragment
    • network
    • slowrendering
    • sessions
    • startup
    • view-click
    • compose:click
  • Libraries:
    • okhttp3
    • okhttp3-websocket
    • httpurlconnection
    • android-log
  • Foundational:
    • common-api
    • android-instrumentation
• Intentional exclusions: Agent and testing variants (*:agent, *:testing).
• Documentation:
  • New README inside the instrumentation:all module explaining usage, scope, production caveats, and maintenance expectations.
  • Update to root README with a brief mention and pointer to instrumentation:all (full install instructions omitted, per guidance) and also fixing small markdown violation.

---

✅ Closes: #1024

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 64.29%. Comparing base (c1463c0) to head (d339fec).
⚠️ Report is 237 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1254   +/-   ##
=======================================
  Coverage   64.29%   64.29%           
=======================================
  Files         142      142           
  Lines        3011     3011           
  Branches      296      296           
=======================================
  Hits         1936     1936           
  Misses        998      998           
  Partials       77       77           

☔ 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.

[LikeTheSalad]

Thank you for your contribution, @marcschaeferger!

It is designed to help users explore OpenTelemetry Android's full feature set without having to manage multiple individual dependencies.

My understanding is that the goal of this PR is to create a single dependency that users can add to their projects to get all the auto-instrumentations with a single line of code. The idea is great, but I'm afraid that this approach won't work for the instrumentations that rely on byte code weaving, such as okhttp, compose, httpurlconnection, and android-log. As those depend on the ByteBuddy plugin to be present in the target project, as well as their respective byteBuddy dependencies. So by just adding their libraries, as proposed here, the users won't get them to work.

The only way to provide a "one-liner" solution to apply all instrumentations that I'm aware of is to create a Gradle plugin that would apply the ByteBuddy plugin as well as the regular and byteBuddy dependencies for each instrumentation that has both.

[breedx-splk]

Hmmm, do we think that the existing of build-time bytecode instrumentation somehow defeats the utility+convenience of this module, though? Some users will just take the runtime instrumentation or use the wrappers, and it also shouldn't prevent users who want to use the bytebuddy gradle plugin from also adding it, right?

[fractalwrench]

A bit of a tangent, but I think a gradle plugin that performs auto-instrumentation should be a long-term goal of the project. It would make it much simpler to install instrumentation at the appropriate place.

[LikeTheSalad]

Hmmm, do we think that the existing of build-time bytecode instrumentation somehow defeats the utility+convenience of this module, though?

I think it depends on the user's expectations. If they look at the instrumentation-all dependency as a one-liner to get all instrumentations fully working, then I think it does more harm than good, as we'll get a lot of false-positive bug issues opened due to the confusion.

and it also shouldn't prevent users who want to use the bytebuddy gradle plugin from also adding it, right?

That's true, but adding the bytebuddy plugin alone won't make the instrumentations work. To make a single instrumentation work (that relies on bytecode weaving), there has to be a combination of the bytebuddy plugin + agent dependency + runtime dependency. And my understanding is that this instrumentation-all dependency only provides the runtime dependency. So to make everything work, they'll have to add the butebuddy plugin, plus each one of the byteBuddy dependencies from every instrumentation that relies on bytecode weaving.

[github-actions]

This has been automatically marked as stale because it has been marked as needing author feedback and has not had any activity for 21 days. It will be closed automatically if there is no response from the author within 14 additional days from this comment.