[antonis]

Description

Android method traces recorded on Android 17 (API 37) are currently dropped with profiling_invalid_sampled_profile. Android 17's ART writes five new keys in the *version header of every method trace (is_streaming, is_precise_trace, end_time, end_tsc, compilation-filter, see TraceWriter::CreateSummary in runtime/trace.cc on android17-release). android_trace_log 0.3.0 rejects any header key it does not know, so the whole profile fails to parse.

This PR removes exactly these five header lines before handing the trace to android_trace_log, for both transaction profiles (legacy.rs) and Android trace chunks (chunk.rs).

• Only the *version section is touched. The binary data section is copied as is, and its data_offset is relative to the SLOW magic, so shortening the text header does not move it.
• Traces without these keys are passed through unchanged, without copying.
• Any other unknown key, and malformed values of known keys, are still rejected as before.

Alternative considered: skip all unknown header keys

Instead of listing the five Android 17 keys, we could skip every header key that android_trace_log does not know. That would keep future Android versions from breaking. We went with the explicit list to stay conservative and keep the change minimal.

Context

Fixes #6517

Testing

• Added tests
• Verified the root cause of the issue and tested on RN with [DO NOT MERGE] Strip Android 17 trace header keys unknown to Relay sentry-react-native#6892

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 5b162ac. Configure here.}

[Dav1dde]

@antonis have you looked into contributing the necessary changes upstream to the android_trace_log crate?

[antonis]

Good call @Dav1dde 👍 Technically making the changes upstream make more sense but the library https://github.com/chayleaf/android-trace-log seems not to be actively maintained. The last source commit is 3y ago.
Happy to try this though if it makes more sense for Relay 🙇

[Dav1dde]

I would suggest trying to contribute upstream first before making such a judgement that something isn't maintained. There simply may have not been a need to make any changes.

If there is no response from upstream we can still run Relay off of a fork and eventually think about vendoring or publishing or an expensive workaround like this.

[antonis]

Thank you for the feedback @Dav1dde 🙇 I'll pursue an upstream fix. Closing this PR for now.