Stats: Show end values and battery/power axes on the charge graph

[d4rken]

What changed

The charge graph on the statistics screen is easier to read at a glance.

• Each curve now ends with its value. The last reading for battery level, power and temperature is printed in the curve's own colour just past the end of the line, connected by a faint dashed leader. Curves stop short of the right edge to make room, so nothing runs into the card border any more.
• The detail chart has real axes. Battery level gets a proper percentage scale on the left with light gridlines behind the curves, and charging power gets a sparse watt scale on the right. Temperature keeps sharing the plot without a scale of its own — it is labelled "Temperature (shape only)" in the legend so its line is never mistaken for a measured value against either axis.
• The small chart on the dashboard stays clean. In the live charge card there are no axes and no time labels — the card header already shows how long the charge has been running — leaving just the compact curves and their end values.
• Screen readers now get a spoken summary of the chart (the values were previously drawn straight onto the canvas, where they were invisible to TalkBack), and the graph keeps its left-to-right time direction in right-to-left languages.

Technical Context

Why the axes work this way. The three series have no common unit, so a single shared scale is meaningless. Series can now be bound to a per-side axis (leftAxis/rightAxis + ChartSeries.axisSide), and each side computes one AxisScale over the union of the series assigned to it — a tick label can therefore never describe a curve it does not belong to. Temperature stays deliberately unbound (self-normalised, shape only) rather than getting a third axis, which is why the legend labels it as such when axes are shown. Scale quality and label density are separate knobs: tickTarget drives the nice-number step, maxLabels only thins which ticks get rendered (the right axis shows two), so a sparse axis never degrades the plotted scale.

The layout maths is pure and tested. ChartMath holds niceScale (a {1,2,5}×10^k axis honouring optional hard bounds and a minimum step) and resolveEndLabels (1-D collision placement). The bounds and min-step arguments exist to stop specific misreadings: a full battery must not produce a 101% tick, power must not go negative, and two watt labels must not format identically at 0.1 W display precision. resolveEndLabels treats input order as priority order and drops the lowest-priority labels entirely rather than overlapping them, which is what keeps the 84dp card legible at large font scales. Both functions are unit-tested on the JVM, including the awkward paths: bounds that are not step-aligned, constant series, Float-precision containment, and label pile-ups.

Non-obvious constraints handled. All drawing is against explicit plot bounds rather than the full canvas width, because the gutters are measured from the actual text. A degradation ladder keeps the plot at least 96dp wide by dropping right-axis labels first and end labels second, so a narrow card degrades deterministically instead of collapsing. The canvas and the x-label row are pinned to LayoutDirection.Ltr and every chart string is measured LTR — without that, RTL locales reversed the time axis against the curves and reordered BiDi-sensitive strings like 32.0 °C. The gridline at the axis minimum is skipped because the existing baseline already draws it.

Review guidance. ChartMath.niceScale is the densest part: it resolves a grid, and if clamping to a non-step-aligned bound would cut the axis below the data it retries with a finer nice step, then falls back to anchoring at the violated bound, then to a two-tick [bound, bound] scale. Coverage and bounds containment are treated as hard guarantees; the nice step and minStep are best-effort and are relaxed in that terminal fallback. Its KDoc still describes coverage in slightly absolute terms while the implementation carries a ~1e-6 relative tolerance and is subject to Float representability past 2²⁴ — a pre-existing imprecision in wording, unreachable with this app's axes (0–100 step ≥ 1; 0–250 000 step ≥ 100, all exactly Float-representable). Flagged rather than silently left.

Verification. New unit tests cover both pure functions. Eight rendered fixtures in the debug source set exercise the degenerate matrix — colliding end labels, constant 100 %, absent power data, trailing-null power, 320dp width, 2× font scale, RTL, and the compact variant — and were inspected visually. fastlane/generate_screenshots.sh is scoped to the Play Store composables so these engineering renders cannot break the store's image-count check. A simulated 20 % → 85 % charge session on an API 36 emulator confirmed both surfaces end to end: the live card renders without axes or time labels, the session detail chart shows the percentage axis with gridlines, the sparse watt labels, the temperature end label without an axis, and time ticks aligned under the plot; no crashes.