ADFA-5574: read each watched process the cheapest correct way

[davidschachterADFA]

PR 16 on the carousel stack. Base is feature/ADFA-5542-cancel-by-build-id (#1807); review that first.

Split out of ADFA-5570 as the one part of that plan which stands alone — it changes how a sample is taken, not when or how often, so it needs no change to the chart's x axis and introduces no gaps.

The two kinds of process are not alike

The carousel plots three processes and read all three with Debug.getMemoryInfo, which walks every mapping in /proc/pid/smaps. But the IDE is a Zygote fork with GPU memory, while the tooling server and the Gradle daemon are plain OpenJDK processes exec'd from the app's Termux prefix — parented to the IDE, with no boot.art, no libandroid_runtime, no libart mapped at all.

Measured on a Pixel 6 Pro, in-process, 200 iterations, median:

Read	Median	Value vs Debug.getMemoryInfo
Debug.getMemoryInfo	31.4 ms	the reference
/proc/pid/smaps_rollup	13.4 ms	JVM: 66,018 vs 66,012 kB — 0.009%, stable ×3. IDE: ~124 MB low
/proc/pid/status VmRSS	0.1 ms	~4% high on the JVMs, wrong for the IDE. Not used

The IDE keeps the expensive read because it is the only source that sees graphics memory: dumpsys meminfo accounts EGL mtrack 89 MB + GL mtrack 36 MB through the memtrack HAL rather than through smaps, where a rollup cannot see them. That is 23% of the IDE's total. The JVMs have no mtrack/EGL/GL lines at all, which is exactly why they agree to 0.009%.

pid == Process.myPid() is the whole test, and it costs nothing: the only Zygote-forked process the carousel plots is the app itself. Nothing inspects /proc to decide.

Measured on a production build — and it is smaller than I predicted

Release build type, non-debuggable (flags=[ HAS_CODE ALLOW_CLEAR_USER_DATA LARGE_HEAP ], no DEBUGGABLE), debug-key-signed so it upgrades in place. Same device, same fresh-launch state, editor idle, two 20 s windows each:

	Total	MemoryUsageWatc
Before	16.1, 16.1 → 16.1 /s	131, 129 → 6.5 /s
After	16.0, 15.5 → 15.8 /s	123, 123 → 6.15 /s

A 5.4% reduction in the memory sampler, about 2% of the app's idle CPU. I predicted ~40%, and that prediction was wrong: I derived 94 ms/sec from 3 × 31.4 ms, which assumed every watched process costs what the IDE costs. It does not — the expensive read is expensive in proportion to a process's mapping count, and the IDE has 3,880 of them against a 66 MB JVM's few hundred. The process that must keep the expensive read is the one that dominates it.

Two honest consequences:

• The idle case measured here is the least favourable one. Only the IDE and the tooling server are watched with no build running. The Gradle daemon — a large JVM, 781 MB in an earlier capture — exists only during a build, which is also when the chart matters most and when two of three processes would take the cheap read. That case is not measured, and it is where this should pay more.
• The ceiling stands regardless: the IDE's own read is most of what remains, so no read strategy gets far below it while the IDE is sampled at 1 Hz. Taking it to zero when nobody is looking is ADFA-5570's visibility gate, not this.

I am not going to dress 5.4% up as more than it is. It is a correct change that removes waste with no accuracy loss, and the debug-build numbers oversold it.

Also removed

The ActivityManager lookup in readUsages(). Dead since the switch to the reflective read — the constructor's own comment explains why that read exists — but its null check was not: had getSystemService returned null, the sampler would have taken no sample at all, for a service it does not use.

Tests

Test	Fails without the fix
the rule: Debug for own pid, rollup for another, Debug for all when unsupported	pins the decision
the rollup's own Pss is read, not one of the fields that start like it	yes — loosening the prefix to "Pss" gives 379,731 (Pss_Dirty) instead of 441,070
a read that fails latches the process onto the reflective one	yes — removing the latch gives two cheap attempts instead of one
missing file, missing Pss line, Pss line with no number	all UNAVAILABLE, never 0 — zero is a measurement, absence is not

The first draft of the parse test did its own line-picking and so pinned only the number extraction — loosening the prefix left it green. That is why the reader now exposes pssKbFrom, and why the test routes through it.

Not tested: that the two reads agree. Debug.getMemoryInfo is not meaningfully callable under Robolectric, so the equivalence rests on the device measurement above and is recorded as such rather than implied. A debug-only check warns if a process given the cheap read turns out to map libandroid_runtime.so, so a future fourth watched process that does use graphics fails loudly instead of quietly reading a quarter low.

Caveats

One device only. smaps_rollup needs a Linux 4.14 kernel — Android 10 in practice — and minSdk here is 28, so the fallback matters; it is exercised by forcing rollupSupported = false. Wants a low-end device check: a slower core makes sampling a larger share of the whole, so the Pixel 6 Pro may understate the benefit. That is in the ticket's Steps to QA.

Also in this PR: a cross-cutting strings change

Commit 37a2a80c9 is not part of ADFA-5574. It is the result of auditing every user-visible string the carousel produces (ADFA-5603), and it sits here because it spans four renderers owned by four different tickets:

file	ticket that owns it
MetricsChartRenderer.kt	ADFA-5486
MemoryUsageChartRenderer.kt	ADFA-5486
NetworkUsageChartRenderer.kt	ADFA-5489
PowerUsageChartRenderer.kt	ADFA-5499

What it changes: "now" and "n/a" were literals in Kotlin and are now string resources; the legend composed itself in code as "%s - %.2fMB" and now goes through metrics_legend_entry, so the separator and ordering are translatable and an RTL locale can reorder them; NetworkUsageChartRenderer pinned Locale.US on four byte formats while the other two pages followed the device, so one screen showed 1.5 MB beside 27,0C — the byte formats follow the device now; and temperature reads 27° rather than 27C.

Why it is not on a lower branch. ADFA-5486 cannot host it: PowerUsageChartRenderer.kt does not exist there, arriving with ADFA-5499. The lowest branch holding all four files and on the path to this one is ADFA-5510, which owns none of them — a convenient host, not a correct one. Splitting the change four ways would leave the legend format externalised on some pages and not others at each intermediate commit. It is here as one coherent change instead, deliberately.

Unit symbols stay in code: MB, kB, GB, B, W, mW, %, /s and the degree symbol are international, and a resource per unit would be ceremony with no reader.

Reviewing it separately is easy — git show 37a2a80c9 is the whole of it, five files.

🤖 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.}

[davidschachterADFA]

Superseded by #1812, which merges all of the carousel work onto current stage as a single change.

Closing rather than leaving open so review effort is not split: stage moved twice today (ADFA-5514 squash-merged, plus seven other commits), the stack's lower branches had diverged from it, and reviewing these individually meant reviewing against a base that no longer exists.

Nothing is lost. This branch is untouched, the commits and their messages are in #1812's history, and reopening is a click if that turns out to be the wrong call.

#1812 carries the ticket-by-ticket detail, the five conflict resolutions the ADFA-5514 squash forced — those compile either way, so they are the part worth reviewing hardest — and a device pass on a Pixel 6 Pro covering the daemon plot, the build markers and all three chart pages.