Charging: Record the HONOR hardware measurement in the ledger

The Magic8 Pro contributor (issue #66) ran the dumpsys measurement, and
the result is unfavourable in a way the mapping alone could not show.

The cap is real: 278 mAh went into the cell after the feature was
disabled, at a point where the broadcast had reported level 100 for over
a minute. That confirms the synthetic 100% against the broadcast rather
than the status bar, so the session-engine hazard recorded earlier is now
evidenced instead of inferred.

But it is only ~4%. The C636 variant is the 7100 mAh model, corroborated
by the contributor's own ~7121 mAh reading, so Smart battery capacity is
a top-of-charge voltage trim, not an 80%-cap equivalent, which would have
plateaued near 5800 mAh. Combined with Smart charge reaching 100%
overnight, neither HONOR key is a hard cap. An adapter here could offer
Adaptive on and off with no percentage at all, carrying the
allowsFullCharge honesty gap already recorded for Xiaomi. The open
question is therefore no longer whether the mapping works but whether
that adapter is worth building. Noted that the ~4% figure is a ratio, so
it survives the charge-counter unit question.

policyLatchesAtPlug behaviour observed: disabling the feature with the
cable connected moved nothing, and the charge only went in after a
replug. Same family as GrapheneOS, so an adapter would reuse the existing
pending-until-replug handling and could not support the reconnect
gesture.

Blocker 2's identity mechanism is resolved. MagicOS exposes app-readable
system features and core com.hihonor.* system packages, the same two
mechanisms that already carry LineageOS and GrapheneOS, so no property
read is needed. Version scoping is still unsolved: com.hihonor.magic.api.23
does not line up with ro.build.magic_api_level=42, so the features answer
"is this MagicOS" and not "is this MagicOS 10", and a features-only gate
would be the first unscoped one in the project.

Records the three app defects the device exposed, one fixed here, one
deferred by decision (the hasSupportLead gate hides the metadata report
on exactly the unrecognized ROMs whose codename it would carry), and one
awaiting a single contributor reading.

Author: d4rken

.claude/skills/device-qualification/SKILL.md

@@ -367,6 +367,24 @@ only after adding a row here. Detailed run narratives live in each adapter's lan
       are compile-time constants, the AIDL has no property op
       (`IChargingControlService.aidl`), and `SystemPropertyReader` structurally cannot distinguish denial from
       absence — so probing a candidate MagicOS property needs a code change, not a contributor run.
+    - **Blocker 2, IDENTITY MECHANISM RESOLVED (support mail, 2026-08-17); version scoping still open.** The
+      contributor supplied both lists from `HNBKQ`. App-readable signals now known to exist on MagicOS 10:
+        - **System features** (`hasSystemFeature`, no permission, no `<queries>` entry — the LineageOS pattern):
+          `com.hihonor.software.features.honor`, `com.hihonor.system.feature`,
+          `com.hihonor.software.features.full`, `com.hihonor.software.features.handset`,
+          `com.hihonor.software.features.oversea`, `com.hihonor.magic.api.23`.
+        - **Core system packages** (PackageManager + `FLAG_SYSTEM` — the GrapheneOS pattern):
+          `com.hihonor.systemserver`, `com.hihonor.systemmanager`, `com.hihonor.powergenie`,
+          `com.hihonor.controlcenter`, `com.hihonor.android.launcher`.
+        - Properties exist too (`ro.build.version.magic=MagicOS_10.0.0`, `ro.build.magic_api_level=42`,
+          `ro.magic.cversion=C636`) but stay the **wrong** route for the SELinux reason above; they are recorded
+          only as corroboration. `ro.product.device=HNBKQ` confirms the fingerprint-derived codename.
+      **What is still missing is ROM-generation scoping.** `com.hihonor.magic.api.23` does not line up with
+      `ro.build.magic_api_level=42`, so that feature reads as a fixed namespace marker rather than a version
+      discriminator — i.e. the features answer "is this MagicOS", not "is this MagicOS 10". Every existing OEM
+      gate is version-scoped (One UI range, `ro.mi.os.version.code`, `oplusrom == 15`); a features-only HONOR gate
+      would be the first that is not, which is exactly the weakness called out above for `Build.MANUFACTURER`.
+      Resolve that before any gate is written, not after.
     - **Level-reporting hazard to test at qualification.** The reporter states Smart battery capacity "still
       displays 100% when fully charged" while capping. A ROM reporting a synthetic 100% at a real ~80% would
       trip `full = status == BATTERY_STATUS_FULL || percent >= 100` in `ChargeSessionService`, ending a session
@@ -393,6 +411,34 @@ only after adding a row here. Detailed run narratives live in each adapter's lan
       `dumpsys battery`, then switch the feature OFF with the cable in and re-record. Voltage and charge counter
       climbing afterwards proves the cap is real and the 100% cosmetic; unchanged means the cell was already full
       and the mode caps nothing. Same evidence shape that settled `tanzanite`.
+      **RESULT (2026-08-17), and it reframes the feature.** Contributor-run, `HNBKQ`:
+
+      | State | Charge counter | status | level | voltage |
+      | --- | --- | --- | --- | --- |
+      | Smart battery capacity ON, plugged, HONOR showing 100% (stable ≥1 min) | 6978 | 2 | 100 | 4551 |
+      | Feature OFF, cable never removed | 6978 (unchanged) | — | — | — |
+      | Feature OFF, after unplug→replug | 7256 | 5 | 100 | 4421 → 4472 |
+
+        - **The synthetic 100% is CONFIRMED in the broadcast, not just the status bar.** `level: 100` with 278 mAh
+          of real headroom, so the sharpenings above are now evidenced rather than inferred. The dumpsys `status: 2`
+          alongside a flat counter also means the ROM reports "charging" while holding.
+        - **But the cap is only ~4%, so Smart battery capacity is NOT an 80%-cap equivalent.** The C636/Singapore
+          variant is the 7100 mAh model (China 7200, Europe 6270; the contributor's own AIDA64 reading of ~7121 mAh
+          corroborates), so 278 mAh ≈ 3.8%. An 80% cap would have plateaued near 5800 mAh. This is a
+          top-of-charge voltage trim, a different class of feature from every currently supported adapter.
+          Consequence: **neither HONOR key is a hard cap** — Smart charge is adaptive (reaches 100% overnight),
+          Smart battery capacity trims ~4% — so an adapter here could offer Adaptive on/off and no percentage at
+          all, with the `allowsFullCharge` honesty gap applying. Weigh that against the build cost before
+          committing to a MagicOS adapter; the mapping being correct is no longer the deciding question.
+        - **`policyLatchesAtPlug` behaviour OBSERVED.** Disabling the feature with the cable in moved nothing; the
+          278 mAh only went in after unplug→replug. Same latch-at-plug-session-start family as GrapheneOS, so an
+          adapter would need `policyLatchesAtPlug = true`, the pending-until-replug state, and the replug grace
+          window rather than anything new. The reconnect gesture would be unsupported for the same timing reason.
+        - Caveats: single run, one sample per state, and the voltage column is not interpretable across rows
+          (4551 was measured under charge, 4421 at `status: 5` resting). The charge counter is the load-bearing
+          number. Note the ~4% figure is a **ratio** (6978/7256), so it survives the charge-counter unit question
+          raised by the telemetry defect below — a uniform 1000× scaling cancels. Only the absolute
+          "278 mAh" framing depends on the unit, and the nominal-capacity cross-check independently supports mAh.
     - **Third key, out of scope: `secure/charge_separation_all_scenarios_switch`** (bypass charging, `1`/`0`,
       reported 2026-08-16). Contributor observation: bypass engages while the screen is on and normal charging
       resumes with the screen off. Recorded as context only — Amply has **no bypass concept at all** (the sole
@@ -405,7 +451,42 @@ only after adding a row here. Detailed run narratives live in each adapter's lan
       "Just send device info" action on the unsupported-device card (`DeviceSupportReporter` emits `device=`
       from `Build.DEVICE`, plus `brand`/`product` and the tri-state key probes; no Shizuku needed) rather than
       another wizard pass, which would omit the codename again.
-    - **Status after the 2026-08-16 follow-up: still NOT qualified, and the gate is unchanged.** One of Blocker
-      1's two halves is closed (keys drive the OEM UI both ways, mirror class excluded); the hardware half and
-      all of Blocker 2 are open. Nothing here justifies an adapter, a lab adapter, or a manufacturer read.
+    - **Three app defects this device exposed (2026-08-17), two of them not HONOR-specific.**
+        - **`FIXED`: "Open battery settings" landed on Battery Saver on every unmapped device.**
+          `ChargingRepository.nativeSettingsIntent()` returned null for `adapter == null` and its only caller
+          substituted `ACTION_BATTERY_SAVER_SETTINGS` outright, so `ACTION_POWER_USAGE_SUMMARY` was never tried —
+          despite every lab adapter preferring it, and despite the manifest already declaring its `<queries>`
+          visibility. Same user-visible symptom as the LineageOS case above, reached by a different path (that one
+          fell through to the Pixel component intent; this one had no adapter object to ask). Affected HONOR,
+          Motorola, Nothing, Sony, Fairphone, Vivo, Tecno — anything without an adapter. Fixed by making the
+          repository fall back to `OemChargingShortcuts.genericBatterySettings`, with the chain extracted so the
+          lab adapters and the null path share one implementation. **Not confirmed to change what this contributor
+          sees**: whether `POWER_USAGE_SUMMARY` resolves on MagicOS 10 is still unverified.
+        - **OPEN (deferred, deliberate): "Just send device info" cannot appear on an unrecognized ROM.**
+          `UnsupportedDeviceCard.kt` gates it on `hasSupportLead` (`ChargingRepository.kt`), a ten-way disjunction
+          of known-ROM markers, every one of which is structurally false for HONOR. Shipped in `v0.3.2-beta0`
+          (`bc55ceb`, PR #44) with a pinning test, so this contributor's build could never have shown it. The gate
+          is defensible (it exists to avoid dead-end reports) but perverse here: the less Amply recognizes a
+          device, the less it lets the user report it — and the report being withheld is the only one carrying
+          `Build.DEVICE`, which is exactly what an allowlist entry needs. This contributor hand-dumped properties
+          because of it. Held rather than changed: reversing a deliberate decision on one data point is thin, and
+          the Shizuku wizard path was still open to them. Revisit if another unknown-ROM contributor hits it.
+        - **OPEN (needs one device reading): charge power renders `0.0 W` / `4 mA` while charging.** Both figures
+          come from one field, `BATTERY_PROPERTY_CURRENT_NOW`. A ROM reporting mA where Android documents µA turns
+          a real 4 A into the integer `4000`, which formats as "4 mA" and computes to
+          `4551 mV × 4000 µA / 1e6 = 18 mW`, printing as "0.0 W" — reproduced exactly in
+          `StatsPowerCalculatorTest`. `Charge counter: 6978` points the same way (documented µAh; 6978 µAh would be
+          6.98 mAh). **But an end-of-charge trickle at level 100 produces the identical value**, so the number
+          alone cannot decide, and a low-side clamp would break correct readings on healthy devices — the
+          `MAX_PLAUSIBLE_MILLIWATTS` guard only ever caught the *over*-reporting direction, and its test comment
+          asserted the wrong direction outright (both corrected). Deciding reading requested: Amply's own
+          "Charge counter" row should render **~7 mAh** if the ROM scales that property, independent of charging
+          state. No per-device telemetry seam exists (`ChargingAdapter` carries no unit capability and
+          `BatteryReader` never sees a `DeviceInfo`), so a fix is new work — and it is adapter-independent, since
+          this device has no adapter to hang it on.
+    - **Status after the 2026-08-17 follow-up: still NOT qualified.** Blocker 1's hardware half is now ANSWERED
+      but the answer is unfavourable — the cap is real yet only ~4%, and neither key is a hard limit, so the open
+      question is no longer "does it work" but "is an Adaptive-only MagicOS adapter worth building". Blocker 2's
+      identity mechanism is resolved; its version scoping is not. Nothing here justifies an adapter, a lab
+      adapter, or a manufacturer read yet.
     - Tracking: GitHub issue #66.