feat(instrumentation): Add FirstDraw spans to activity instrumentation

[Doohl]

fixes #1143

What is this change?

This PR adds instrumentation to track the initial draw time of Android activities. A new FirstDraw span is created as a child of the activity creation span (e.g., AppStart or Created), measuring the time from activity creation until the first frame is rendered on screen.

The implementation:

• Hooks into Android's ViewTreeObserver.OnDrawListener to detect when the first draw occurs
• Handles Android API < 26 bug where draw listeners weren't properly merged into the view tree observer
• Captures screen complexity metrics (view node count and depth) when the draw completes

What are the points of contention?

1. Screen view complexity attributes

Two new attributes are added to the FirstDraw span to capture screen complexity:

• screen.view.nodes (long): Total count of all View nodes in the view hierarchy
• screen.view.depth (long): Maximum depth of the view hierarchy

We believe these metrics will add some value if users try to debug long FirstDraw spans. Feedback here would be appreciated, though!

2. FirstDraw value

FirstDraw spans aren't a perfect signal for when Activities become 'interactable'. Rather, this can help users identify issues with the UI pipeline. For that, users would have to manually instrument spans or events that fire off when the app or activity enters a state where the end user can actually start interacting with the app.

3. FirstDraw span lifecycle

FirstDraw spans are children of the Created spans. However, FirstDraw span can end long after the parent span has ended. This can create a confusing tracing experience, but we probably don't want to change the definition of the existing Created span.

Does it make sense to keep FirstDraw as a child of Created?

How was this tested?

Tested some scenarios with the demo app (API versions 28 and 30) to validate the correctness of the instrumentation. If you have any ideas how this could be better tested, feel free to opine!

Raw trace: https://www.codebin.cc/code/cmg9yjmxb0001jz037mtuj2v0:HXhjtG6XV3Vhfh8Ewy6r1S6KfapJtmgM1S1beucxBmpG

[codecov]

Codecov Report

❌ Patch coverage is 63.15789% with 28 lines in your changes missing coverage. Please review.
✅ Project coverage is 64.26%. Comparing base (f466e65) to head (5360ece).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
...instrumentation/activity/draw/FirstDrawListener.kt	40.90%	13 Missing ⚠️
...droid/instrumentation/activity/ActivityTracer.java	38.46%	8 Missing ⚠️
...droid/instrumentation/activity/draw/WindowUtils.kt	80.95%	3 Missing and 1 partial ⚠️
...strumentation/activity/Pre29ActivityCallbacks.java	33.33%	2 Missing ⚠️
...roid/instrumentation/activity/ActivityCallbacks.kt	50.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1281      +/-   ##
==========================================
- Coverage   64.30%   64.26%   -0.04%     
==========================================
  Files         142      145       +3     
  Lines        3012     3087      +75     
  Branches      296      307      +11     
==========================================
+ Hits         1937     1984      +47     
- Misses        998     1025      +27     
- 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.

[LikeTheSalad]

Thank you for your contribution. These changes seem to be related to this semconv PR where I've posted some concerns about things such as the type of signal to use for these kinds of events, as well as the utility of certain attributes such as nodes and depth followed by a lot of questions on what to do with them around certain scenarios. I'd like to get to a consensus over there first before moving forward with code changes.