ADFA-5526: include carousel metrics in crash reports

[davidschachterADFA]

Every report the IDE sends now carries what the machine was doing in the minutes before it. A crash arrives with a stack and no idea whether memory was climbing, the daemon was thrashing, or the device was thermally throttled — and for an out-of-memory kill that history is most of the answer.

Four commits: a pruning fix, the buffer work, the pre-allocated destinations, then the attachment.

It did not need its blocker

This was marked blocked by ADFA-5494. It isn't. A crash is the one loss cause with a hookable moment — IDEApplication already installs an UncaughtExceptionHandler — which is exactly why it can be served on its own. The low-memory kill that 5494 exists for produces no report at all, because nothing runs on a SIGKILL, so it was never this ticket's case. The two tickets had been conflated.

Not allocating while dying

A crash handler is the wrong place to ask for memory: the crash being reported may be the heap running out, and a handler that throws replaces a useful report with no report. So the eleven destinations a snapshot needs are taken at startup, where failing to get them is survivable and obvious.

• copyInto writes a ring buffer into an array the caller already owns; toLongArray delegates to it. It requires an exact-length destination — a short one truncates the history and a long one leaves a stale tail, and both read as data.
• MetricsScratch is single-use at a time rather than thread-confined. claim hands it to one caller, release gives it back, and a caller that cannot claim it allocates for itself instead of waiting — two writers into one array is a scrambled file, and a crash must not block on an export. withSnapshot scopes the claim to a block, because the snapshot points into the scratch, so the scratch must outlive whatever reads it, which is a file write rather than the call that assembled it.
• Everything is inside runCatching, which in Kotlin catches Throwable. That is deliberate: an OutOfMemoryError raised in here would cost the whole report. Losing the attachment is the right way to fail.

And it costs less memory than before

	Held for the life of the process
Before	859 KB (11 buffers × 10,000 × 8B)
Naive: add a scratch	1,719 KB
This PR: scratch + 3,600 entries	619 KB

MAX_USAGE_ENTRIES drops from 10,000 to 3,600. Ten thousand is nearly three hours at the default rate, of which the chart shows sixty samples at a time.

One thing to check rather than take from me: the constant counts samples, not time, so at the fastest offered rate of 100 ms it is six minutes rather than an hour. If the fast rates are meant to give hours of history, 3,600 is the wrong number — it is one constant, and I would rather change it now than have it noticed later.

ADFA-5536 is filed for the follow-on: storing each series in a type and unit appropriate to it, which would save a further ~310 KB. Not done here — it makes the storage layer mixed-unit, which is the shape that produces a double-multiply bug in the numbers the feature exists to report, and the cheaper lever above saves more.

Reaching the watchers from a crash

They live in an activity-scoped ViewModel, which is right for the carousel and no use to a handler with no activity that arrives on whatever thread threw. MetricsSource is the one indirection; the ViewModel registers itself and clears on onCleared, conditionally, since an activity recreation can register the replacement before the outgoing one is cleared.

The assembler's @UiThread comes off. Every read it makes already takes the watcher's own history lock, so it was always safe from any thread — the annotation was conservative rather than load-bearing.

A pruning bug found on the way

pruneTo chose "the oldest n" across every file and then skipped the one just written, so whenever that one sorted into the set it deleted one file too few. Two exports inside a single filesystem timestamp make that routine, and the directory crept one over the limit per collision. Pre-existing in the chart snapshots; reusing pruneTo for the CSV exports is what surfaced it, as a bounded-directory test finding four files where three were allowed. Fixed, with a test that ties the timestamps deliberately rather than relying on the collision happening.

Verification, including what is not verified

Unit tests: an attachment appears when there is history and gunzips to a valid CSV with the expected header; nothing is attached without a source, or without samples; the event comes back unchanged when the attachment throws. Plus the scratch's claim semantics, its destination sizes against MAX_USAGE_ENTRIES, install being idempotent, copyInto's ordering, identity and length check, and the stale-tail case. Full :app unit suite (689 tests) and spotlessCheck green.

The device leg is open, and I want that on the record rather than buried. adb shell am crash aborts the WebView renderer natively, which never reaches the Java uncaught handler — so it exercised nothing, and produced no attachment, correctly. I did not find another reachable path that raises a reported Java exception in the main process, and stopped hunting rather than spend more time on it. What that leaves unproven is only the last hop — that Sentry carries the Hint attachment into the envelope — since the file production and the decision logic are covered above. The cheapest way to close it is a debug-only crash trigger; say if that is wanted and I will add one behind BuildConfig.DEBUG.

Font scale

No UI.

Review fixes

The pruning fix has moved down to ADFA-5534, where the test that catches it lives — that PR was red on its own both directories stay bounded without it. Nothing is lost here; the tie-case test that shipped with it was vacuous and has been rewritten there. See #1800.

The scratch path carries the sample times. ADFA-5531 now reads each watcher's times and values in one critical section, so copyUsageInto and copyHistoryInto take a times destination alongside the value destinations and hand both back together. MetricsScratch already pre-allocated the three times arrays; they are filled through the same call as the values now rather than through a separate locked read, so the pre-allocated path has the same guarantee as the allocating one — a row of the crash attachment is one moment.

🤖 Generated with Claude Code

https://claude.ai/code/session_017CCQUU7tBzZL61EmQhJP8j

[claude]

Claude Code Review

This repository is configured for manual code reviews. Comment @claude review for a one-time review, or @claude review always to subscribe this PR to a review on every future push.

_{Tip: disable this comment in your organization's Code Review settings.}