Kirin (Mate 10 Pro): ongoing notification shows nonsense "Discharging −1 mA" — CURRENT_NOW reported in mA, not µA

[almothafar]

Symptom (observed on the Kirin Mate 10 Pro)

The ongoing status notification intermittently shows "Discharging −1 mA", while the details table correctly shows no Current row at all. Reported 2026-07-12.

Diagnosis

The Kirin/HiSilicon fuel gauge reports BATTERY_PROPERTY_CURRENT_NOW in mA instead of µA — the sibling of its charge-counter unit bug (#69/#94). A real draw of ~800 mA arrives as raw -800, which we interpret as −800 µA = −0.8 mA.

The gates in BatteryRateTracker.computeRate then behave exactly as written, on garbage input:

• isPlausibleCurrentMicroAmps only rejects too-large readings (wrong unit in the other direction); a 1000×-too-small value looks perfectly plausible.
• hasCurrent requires Math.round(|µA|/1000f) >= 1, i.e. raw ≥ 500. Under load (real 0.5–1.5 A) raw lands in 500–1499 → the display shows "−1 mA".

Why the notification shows it but the table doesn't

1. NotificationService.statusWithRate falls back to mA whenever no %/h is available — notably during the source-B warm-up (~3 min after unplug / any window reset), exactly when the user tends to glance at the notification. On this device source A never runs (capacity reads 0), so every warm-up exposes the mA fallback.
2. The notification refreshes on every broadcast (including screen-off/under-load moments where raw ≥ 500); the table only samples at app-open instants, where the reading is usually < 500 → hasCurrent false → row hidden. Same gates, different sampling moments around a borderline value.

Not affected

The %/h rate itself on this device: capacity is 0 there, so source A (current ÷ capacity) is already skipped and the rate comes from level-over-time (source B), which is unit-independent. Only the Current row and the notification's mA fallback are wrong.

Also note the general-device implication: on any device, a genuine sub-1.5 mA reading displayed as "−1 mA" is glance-noise, not information.

Fix

v1 — display floor (small, safe, do first)

Treat currents below a minimum display magnitude as "not worth showing": add MIN_DISPLAY_CURRENT_MA = 10 (constant in BatteryRateTracker) and require Math.round(|µA|/1000f) >= MIN_DISPLAY_CURRENT_MA in the hasCurrent gate.

• Hides the Kirin nonsense entirely (misread values cap out at ~1–3 "mA").
• Negligible loss on genuine-µA devices: sub-10 mA discharge happens only in deep sleep, when nobody is reading the notification anyway.
• Update BatteryRateTrackerTest accordingly (the negligibleRate_roundsToZeroAndHides / currentZero_isHiddenWhileRateStillShown neighborhood; add a boundary case at 9/10 mA).

v2 — unit auto-calibration (optional follow-up; needs on-device verification)

Persistently track the maximum |raw| ever observed (across sessions, including while charging). If after meaningful observation it stays below ~20,000, the device cannot be reporting µA (that would mean it never exceeded 20 mA even while charging) → conclude mA units, scale readings ×1000, and show the real current on Kirin instead of hiding it. Genuine µA devices routinely exceed 100,000+.

• Store the calibration flag + observed max in SharedPreferences; pure decision helper + tests.
• Verify on the Mate 10 Pro before merging (confirm raw magnitudes: expect ~200–2000 discharging, ~1000–2000 charging).
• If v2 lands, source A could also be enabled with scaled current on such devices where capacity is known — out of scope unless trivially free.

Affected code

• service/BatteryRateTracker.java — computeRate hasCurrent gate + new constant (v1); calibration state (v2)
• service/BatteryRateTrackerTest.java — gate boundaries (v1); calibration decision helper (v2)
• No string/UI changes needed for v1 (the row/segment simply hides, which is the designed behavior for untrustworthy readings, per Battery health: show 'Unknown' + tappable info when the charge gauge is unreliable (vs design capacity) #94)

Acceptance criteria (v1)

• "−1/−2 mA" can no longer appear in the ongoing notification or the details table
• Currents ≥ 10 mA display exactly as before
• Boundary unit tests at the new floor
• Verified on the Mate 10 Pro: notification falls back to the plain status label during warm-up instead of showing mA nonsense

[almothafar]

Code re-review 2026-07-15 (maintainer asked whether this is outdated after #148–#151 merged): not outdated — the merges made it more urgent. The same misread CURRENT_NOW now feeds three surfaces:

1. The original symptom stands. BatteryRateTracker.computeRate still gates hasCurrent at ≥ 1 mA with no display floor, and NotificationService.statusWithRate's discharging path still falls back to mA when no %/h is available — "Discharging −1 mA" can still appear during warm-up. v1 (display floor) is unimplemented and still correct as written.

2. New since filing — wrong charging tier everywhere (Redesign charger notification: charging speed (tier + wattage), wired/wireless, and 3 notification modes #122/Charging: show tier + wattage (not %/h) in the ongoing notification while charging (shrunk scope) #125). ChargeSpeed.powerMilliwatts computes µA × mV / 1e6; Kirin's mA-unit raw (~1000 while fast charging) yields ~3–4 mW — which passes the > 0 check and classifies as known, Trickle. So on this device the charge-connected announcement and the ongoing notification's charging segment will show "Slow charging" regardless of the real speed.

3. New since filing — guaranteed false slow-charge alarm (Charging: slow / bad-cable warning #123/Slow-charge warning: detect frayed cable / dying charger (#123) #150). SlowChargeDetector.decide trusts any known power; a "known" 3 mW sits permanently below the 2.5 W floor, so every wired charge session below 80% on the Mate 10 Pro will fire "Charging slowly — check the cable and port" after the 3-minute window. This is a user-facing false alert, not cosmetic.

Updated fix recommendation

• v1a (this issue's original v1): MIN_DISPLAY_CURRENT_MA = 10 floor in hasCurrent — fixes surface 1 only.
• v1b (new, fixes surfaces 2–3 at the source): add a minimum plausible power to ChargeSpeed.powerMilliwatts — a phone that reports CHARGING is never genuinely drawing <~100 mW, so treat sub-floor results as unknown (mirror of the existing MAX_PLAUSIBLE_MW guard). Unknown power ⇒ tier displays fall back to the plain label, and SlowChargeDetector stays silent (its powerKnown gate). One constant + boundary tests in ChargeSpeedTest/SlowChargeDetectorTest.
• v2 (unit auto-calibration) unchanged — the only path that shows correct values on Kirin instead of hiding them; still needs on-device raw-magnitude verification first.

To the "what's the point of guards" question: these aren't defensive clutter — on this device the raw number is wrong by 1000×, so every guard is just "don't present garbage as data". v1a stops a meaningless "−1 mA" being displayed; v1b stops a false "bad cable" warning firing on every charge.

---

Generated by Claude Code

[almothafar]

New field observation (maintainer, 2026-07-16), Kirin Mate 10 Pro: on charger connect, the ±1 mA reading appeared in the details table this time — flipping −1 → +1 as the direction changed — while the notification did not show it. That's the mirror image of the original report ("notification shows it, table doesn't").

This fits the existing diagnosis rather than changing it:

• Which surface shows it is a coin flip. The table and the notification sample CURRENT_NOW at different instants around the same borderline raw value (≥ 500 → passes the hasCurrent ≥ 1 mA gate; < 500 → hidden). At plug-in the current is exactly in its noisy/settling phase, so whichever surface happens to read a ≥ 500 instant wins — "same gates, different sampling moments", now observed in both directions.
• The − → + flip is expected, not extra breakage: signedCurrentMilliAmps takes its sign from the charging state, so the same garbage magnitude legitimately flips sign the moment the status becomes charging.

Implications for the planned fixes:

• v1a (display floor MIN_DISPLAY_CURRENT_MA = 10) kills this symptom on both surfaces — the misread values cap out at ~1–3 "mA", below any sensible floor. Still the right first move.
• New issue One snapshot per broadcast: derive ChargeSpeed from the BatteryDO in hand instead of fresh hardware reads #157 (derive ChargeSpeed/current judgments from the one BatteryDO snapshot per broadcast instead of fresh reads) removes the table-vs-notification disagreement that makes this look random — but it does not fix the garbage values themselves; the floors here (v1a/v1b) remain the actual fix.
• The "random behavior" wording is worth keeping in mind when verifying on-device: acceptance should check both surfaces across several plug/unplug cycles, not a single glance.

---

Generated by Claude Code