feat(attributes): Add Android Runtime (ART) GC and memory attributes

[markushi]

Summary

Adds Android Runtime (ART) garbage collection and memory attributes for tracking GC activity and memory usage on Android. Similar to the existing jvm and dotnet top-level event context attributes.

GC attributes (art.gc.*)

• art.gc.blocking_count / art.gc.blocking_time — blocking (stop-the-world) GC
• art.gc.total_count / art.gc.total_time — all GC activity
• art.gc.waiting_time — time threads spent waiting for GC
• art.gc.pre_oome_count — last-resort GCs before OutOfMemoryError

Memory attributes (art.memory.*)

• art.memory.free — free memory available to the process
• art.memory.free_until_gc — free memory before GC would trigger
• art.memory.free_until_oome — free memory before OOM
• art.memory.total / art.memory.max — allocated and max memory

[github-actions]

Semver Impact of This PR

🟡 Minor (new features)

📋 Changelog Preview

This is how your changes will appear in the changelog.
Entries from this PR are highlighted with a left border (blockquote style).

---

New Features ✨

Docs

• Add links to deprecated and aliased attributes by Lms24 in #396
• Add filtering capability by nsdeschenes in #395

Other

• (attributes) Add Android Runtime (ART) GC and memory attributes by markushi in #382

Bug Fixes 🐛

• Change type of sentry.dsc.project_id to string by elramen in #400

---

_{🤖 This preview updates automatically when you update the PR.}

[buenaflor]

I wonder if we should further split it into sub namespaces e.g

art.gc_blocking.count vs art.gc.blocking.count

[markushi]

I wonder if we should further split it into sub namespaces e.g

art.gc_blocking.count vs art.gc.blocking.count

I've split them into art.gc and art.memory

[markushi]

Moving back to draft for now, as we need to sort out the "runtime" vs. "process.runtime" discussion first.

[buenaflor]

From what I can tell otel also prefers setting runtime specifics into its own namespace e.g

dotnet.gc.heap.total_allocated, jvm.gc.duration (and we also follow this with jvm)

It looks like art.gc.xyz fits as well

[buenaflor]

what do you think of this, I had 🤖 run through the GC and Memory attributes of OTEL runtime conventions to check how we can align with naming:

Key	Description	OTel alignment
art.memory.free	Free heap memory available to the process	ART-specific; V8 has available_size
art.memory.free_until_gc	Free memory before next GC triggers	ART-specific; Go has go.memory.gc.goal (target, not headroom)
art.memory.free_until_oome	Free memory before OutOfMemoryError	ART-specific
art.memory.committed	Heap currently allocated to the process	Matches jvm.memory.committed, .NET committed_size
art.memory.limit	Maximum heap size the process can grow to	Matches jvm.memory.limit, go.memory.limit
art.gc.collections	Total GC collections since process start	Matches dotnet.gc.collections, go.memory.gc.cycles
art.gc.duration	Cumulative GC time since process start	Matches jvm.gc.duration, v8js.gc.duration (leaf name)
art.gc.blocking_collections	Stop-the-world GC collections since process start	ART-specific; JVM uses jvm.gc.action attribute instead
art.gc.blocking_duration	Cumulative stop-the-world GC time since process start	ART-specific; closest to go.memory.gc.pause.duration
art.gc.pre_oome_collections	Last-resort GC attempts to prevent OOM	ART-specific
art.gc.wait_duration	Cumulative thread wait time due to GC	ART-specific

[markushi]

I decided to move these new attributes into a top-level art namespace, similar to existing platform specific attributes (go.*, jvm.*, dotnet.*). It's worth pointing out that these attributes will be used within the event.contexts protocol (as opposed to the span.data bag)

[romtsn]

do we need to mention hybrid SDKs for all these, too?