feat(android): Parse memory and GC info from ANR thread dumps

[markushi]

📜 Description

Parses memory and GC metrics from ANRv2 thread dumps (ApplicationExitInfo traces) and enriches the Device context on ANR events.

New classes:

• ThreadDumpMemoryInfo — data holder for parsed memory/GC fields (bytes and milliseconds)
• ThreadDumpMemoryInfoParser — parses lines like Free memory 3107KB, Total GC time: 11.807ms using simple suffix-based parsing (counterpart to Android's PrettySize output)

The parsed memory info flows through ThreadDumpParser → ParseResult → AnrV2Hint → ApplicationExitInfoEventProcessor, which sets:

• device.freeMemory ← freeMemoryUntilOOMEBytes
• device.usableMemory ← freeMemoryBytes
• device.memorySize ← maxMemoryBytes

Resolves: #2801

💡 Motivation and Context

ANR thread dumps from ART contain memory and GC statistics that are currently ignored. This information is valuable for diagnosing memory pressure-related ANRs.

💚 How did you test it?

• Unit tests for ThreadDumpMemoryInfoParser (all size units, invalid input, time parsing, all fields, unrelated lines)
• Integration tests in ThreadDumpParserTest using real thread dump fixtures
• Negative test: garbage thread dump produces no memory info

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps

• Determine where to surface GC statistics (e.g. a dedicated "memory" context)

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against 9cb9fdf

[sentry]

📲 Install Builds

Android

🔗 App Name	App ID	Version	Configuration
SDK Size	io.sentry.tests.size	8.41.0 (1)	release

⚙️ sentry-android Build Distribution Settings

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	315.40 ms	352.60 ms	37.20 ms
Size	0 B	0 B	0 B

Baseline results on branch: main

Startup times

Revision	Plain	With Sentry	Diff
319f256	317.53 ms	370.83 ms	53.29 ms
ab8a72d	316.24 ms	356.38 ms	40.14 ms
cf708bd	434.73 ms	502.96 ms	68.22 ms
91bb874	310.68 ms	359.24 ms	48.56 ms
f634d01	375.06 ms	420.04 ms	44.98 ms
62b579c	299.75 ms	364.84 ms	65.09 ms
6b019b7	403.90 ms	546.09 ms	142.19 ms
d364ace	384.53 ms	453.51 ms	68.98 ms
5b66efd	308.67 ms	363.85 ms	55.18 ms
ee35ac3	346.83 ms	435.48 ms	88.65 ms

App size

Revision	Plain	With Sentry	Diff
319f256	1.58 MiB	2.19 MiB	619.79 KiB
ab8a72d	1.58 MiB	2.12 MiB	551.55 KiB
cf708bd	1.58 MiB	2.11 MiB	539.71 KiB
91bb874	1.58 MiB	2.13 MiB	559.07 KiB
f634d01	1.58 MiB	2.10 MiB	533.40 KiB
62b579c	0 B	0 B	0 B
6b019b7	0 B	0 B	0 B
d364ace	1.58 MiB	2.11 MiB	539.75 KiB
5b66efd	1.58 MiB	2.13 MiB	559.07 KiB
ee35ac3	1.58 MiB	2.13 MiB	558.77 KiB

[markushi]

@sentry review

[sentry]

Bug: The device's total physical RAM (device.memorySize) is incorrectly overwritten with the app's maximum heap size from the ANR thread dump, leading to inaccurate memory reporting.
_{Severity: MEDIUM}

Suggested Fix

Remove the logic that overwrites the device.memorySize. The value from maxMemoryBytes parsed from the thread dump should not replace the device's total physical RAM. Consider storing the JVM heap max in a separate field or only setting the memory size if it hasn't been set already from ActivityManager.MemoryInfo.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location:
sentry-android-core/src/main/java/io/sentry/android/core/ApplicationExitInfoEventProcessor.java#L754-L756

Potential issue: In Sentry ANR events, the `device.memorySize` field, which should
represent the device's total physical RAM, is being incorrectly overwritten. Initially,
it is set correctly using `ActivityManager.MemoryInfo.totalMem`. However, the
`applyPostEnrichment` method later overwrites this value with the JVM maximum heap size
(`-Xmx`) parsed from the ART thread dump's "Max memory" line. This causes the reported
device memory to be drastically smaller than the actual physical RAM (e.g., reporting
192MB instead of 4GB), leading to significantly inaccurate device data associated with
ANR events.

_{Did we get this right? 👍 / 👎 to inform future reviews.}