Device Qualification

Device Qualification & Ledger

Companion to .claude/rules/privileged-access.md, which holds the always-loaded safety boundary and the capability gates themselves. Never widen a gate without adding a row to "Verified devices" below.

Qualifying a new device / OEM

Adding or widening a live adapter requires physical qualification, not just a settings mapping:

1. Characterize — record model/codename, build fingerprint, OS + OEM-component versions, and the native charge-protection options. Diff settings list {secure,system,global} before/after each native UI state to isolate the exact key(s) and value domain. Note whether a key is absent in factory state (absent ≠ off).
2. Validate hardware — drive the raw key transitions unplugged, and charging below/near/above the limit, wired and wireless. The gate passes only if writes move the real charging hardware (battery status / sysfs charging_policy / current), not just the Settings UI.
3. Validate access tiers — WSS-only (writes apply, hidden reads stay truthfully "requested", grant survives reboot), Shizuku-only (authoritative readback, denial + binder-death + restart), and both (WSS write → Shizuku readback). An external native change must never be claimed as verified.
4. Validate sessions — full charge, early disconnect, manual restore, arm + safety timeouts, process death, force-stop, notification denial, real reboot + deferred BOOT_COMPLETED redelivery. Confirm exact restore of the prior value including a previously-absent key, and that an unknown/malformed value refuses the session without mutating the setting. Also confirm the interrupted-session surface both ways: a force-stop that leaves a restore owed must, on next open, restore the limit and show the dashboard interruption card, while a reboot must restore via boot recovery and show no card (the boot-count guard). A device that holds at its limit often reports NOT_CHARGING, which ends a session immediately — drive the lifecycle with adb shell dumpsys battery set status 2 / set level N (then dumpsys battery reset) so the session behaves as it would mid-charge.
5. Minified build — repeat the smoke path on an R8 foss beta (past runs caught R8-only startup/reflection breakage that debug builds hid).

Record every scenario as PASS / FAIL / NOT RUN / BLOCKED — an untestable hardware condition is not a pass. Never commit device serials or user data. Requalify after a relevant OS / OEM-component update.

Go / no-go: Go only if writes reliably control the hardware and restore safely (enable just the tested model/OS row). Shizuku-only if control needs an extra safe op invokable through the typed service. No-go → keep the device diagnostics-only.

The in-app guided run is not a ledger row

charging/core/qualification/ lets a user run the cut → resume → cut challenge on their own device. A pass records EnforcementStatus.SELF_QUALIFIED, which enables control for that user, on that exact build, and produces a report (qualification_schema=1) carrying Build.DEVICE — the codename an allowlist entry needs and the field the contribution wizard omits.

A self-qualified pass never becomes a "Verified devices" row on its own, and never writes into a QUALIFIED_CODENAMES allowlist. It is one run, on one unit, usually unattended, with no wireless leg, no access-tier matrix, no session/boot-recovery coverage and no R8 build — i.e. step 2 of the protocol partially, and none of steps 3-5. What it is good for is the thing that used to take days of email: it settles the does-the-hardware-obey question with a machine-collected, timestamped result instead of contributor prose, so a maintainer row becomes a matter of covering the remaining steps rather than starting from nothing.

Treat an incoming qualification report the way the tanzanite enforcement evidence was treated: strong evidence for one question, explicitly scoped, recorded with its gaps named.

Verified devices (physically tested)

The gate's supported scope (see Capability Gates) is broader than what has been physically tested below. Widen a gate only after adding a row here. Detailed run narratives live in each adapter's landing commit.

Known gaps

• LineageOS — the live adapter now matches every LineageOS build that ships the lineagesettings provider; QUALIFIED_CODENAMES still ships empty but is only a maintainer fast path, no longer what makes the adapter reachable. Control is gated on per-build enforcement evidence instead: a device is a candidate with controls off until the user explicitly enables control on an unconfirmed build, and loses control permanently for that build if the battery is observed charging past the cap. A codename still goes into QUALIFIED_CODENAMES only after full qualification (real charging cessation at the limit, wired + wireless, below/at/above threshold) plus a "Verified devices" row — that list now buys skipping the opt-in, not access itself.
  • Observation can only refute, never confirm (established 2026-08-17, see the oriole re-observation below): no passively observable signal distinguishes a cap hold from a thermal or weak-supply pause. Both present as plugged + BATTERY_STATUS_NOT_CHARGING + a static level. EXTRA_CHARGING_STATUS does not break the tie — it is session-scoped, measured still reading 4 while the device charged ten points below its cap. A guided two-cap cut/resume/cut challenge (raise the cap, verify charging resumes and re-stops at the new threshold) is the known way to earn real confirmation and is deliberately not implemented.
  • Pixel 6 (oriole) on LineageOS 23.2 / Android build BP4A.251205.006 — re-observed 2026-08-17. The 2026-07-22 LOS 23.2 NO-GO below does NOT hold on this build. dumpsys lineagehealth binds ccprovider.Limit (so the HAL does advertise the LIMIT mode bit again), charging_control_mode reads back as 3 and is not coerced to 1, and with enabled=1 / mode=3 / limit=70 the device sat at exactly 70 % on AC for ~4 h: status: 4 (NOT_CHARGING), Charging state: 4, Charging policy: 1, voltage 4072 mV. Causal check: raising charging_control_charging_limit to 80 resumed charging within 20 s — status: 2, voltage 4072 → 4183 mV, temperature 294 → 311, charge counter 2908000 → 2910000 — i.e. the setting demonstrably drives the charging hardware, which is stronger evidence than an observed plateau. The limit was restored to 70 and re-verified by read-back; enabled/mode were never written. This is NOT a GO and oriole is NOT in QUALIFIED_CODENAMES: only part of step 2 was run — wired only, no wireless, no below/at/above sweep, no hold observed at the raised cap, and none of steps 3-5 (access tiers, sessions, boot recovery, R8). It supersedes the "HAL dropped LIMIT" claim for this build only. Unexplained later observation, recorded so this row does not overclaim: a few hours after the run above, the device was found at 78 % with charging_control_charging_limit still reading 70 — i.e. a level above the cap. It is not attributable and must not be read either as enforcement failing or as anything else: by then the phone had left this run's control entirely — physically unplugged and moved, and its system clock force-set to Tue Jul 21 02:01 CEST (a month in the past, at 02:00) by another workflow, which is a scheduled/night-charge experiment signature. Any of that could produce the rise. The controlled observations above stand as recorded; this one is logged only so a later reader does not find it and conclude the row was written selectively. Re-check under controlled conditions before treating either as settled. Why it matters beyond oriole: same device, same Lineage major version, different build, opposite HAL capability. That is the concrete case for HAL capability being build-scoped, not codename-scoped, and it is why enforcement evidence is keyed on a composite build identity (fingerprint + incremental + build time + provider package version) rather than a codename — LineageOS spoofs Build.FINGERPRINT to stock, so the fingerprint alone cannot carry it.
  • Pixel 6 (oriole) on LineageOS 20.0 / Android 13 — tested 2026-07-22, result NO-GO (no hardware enforcement). The software chain is fully validated — both raw (shell-UID content query/content insert) and through the app's real Shizuku backend end-to-end (R8 debug build + Shizuku granted): tapping 80 % wrote the trio via writeLineageSetting and read back Verified(FixedLimit(80), SHIZUKU). LineageOS's ChargingControlController observes the external write and updates its live config (dumpsys lineagehealth → mConfigEnabled:true, mConfigMode:3, mConfigLimit:80); the vendor.lineage.health.IChargingControl/default HAL is registered and its service runs. The refuse-don't-clobber decode was also confirmed live: a native mode=2 (CUSTOM) state read as Unknown(unrecognized) ("Policy not verified"), never overwritten. And the diagnostics-only path was smoke-tested (empty allowlist → lineageos-lab → "Detected for diagnostics only", no crash). But the hard percent limit did not cut charging — with limit=80 set, the battery charged 92→95 %+ at ~1.2 A (charge_stage=Inactive, charge_limit sysfs empty, mChargingStopReason:0). On Pixel the charge hardware is driven by Google's adaptive/charge_deadline mechanism, and this Lineage build's HAL does not map the %-cap to a real cutoff — the mIsLimitSet:false device-dependent class of gap. So oriole stays out of the allowlist. This is a clean validation of the conservative gate: an "any LineageOS device" gate would have claimed 80 % protection while the phone charged to 100 %. (Qualifying a device with a working charge-control HAL remains open; the adapter's provider/observer mechanism is proven, only per-device HAL enforcement varies.)
  • Also confirmed on oriole: charging_control_* keys are absent in factory state (validates the conservative "absent → unrecognized" decode). Still open: the provider's change-notification URI form (per-key vs table) against the registered observedSettingUris, to be checked on a HAL-enforcing device.
  • Pixel 6 (oriole) on LineageOS 23.2 / Android 16 — retested 2026-07-22 after an anti-rollback firmware bump, result NO-GO (HAL no longer offers LIMIT mode at all). A sharper root cause than the LOS 20 run: the vendor.lineage.health.IChargingControl HAL reports getSupportedMode() without the LIMIT bit, so ChargingControlController.isChargingModeSupported(LIMIT) is false and LineageOS coerces charging_control_mode=3 → 1 (AUTO) — verified live: every raw shell-UID content insert of mode=3 (even while enabled=0) read back as 1. Enabling then logs LineageHealth: No alarm found, auto charging control has no effect and Setting charge deadline: … 73353; the active provider is ccprovider.Deadline (Google Adaptive Charging — time/alarm-based, no fixed-percent cap). charging_policy/charge_stage sysfs never changed. So oriole is NO-GO on both builds for different reasons: LOS 20 accepted LIMIT but the HAL silently didn't cut; LOS 23.2's HAL dropped LIMIT and falls back to the Deadline mechanism. Consequence for the adapter (unchanged — correct by design): SYNC_READBACK apply(FixedLimit) writes mode=3, reads back mode=1 ≠ 3 → decodes Unknown(unrecognizedValue=true) → apply returns false, so it refuses without a false claim of control. Reinforces the allowlist bar: a device must both expose the LIMIT mode bit and actually cut charging. charging_control_* again absent in factory state.
  • Pixel 6 (oriole) on LineageOS 23.2-20260720-NIGHTLY / Android 16 — app-level compatibility pass 2026-08-03. HAL qualification not re-run (same build as the run above, verdict stands). This pass found a defect that made the whole Lineage path unreachable in production: Amply never detected LineageOS at all. All five ro.lineage.* properties are labelled u:object_r:custom_version_prop:s0, which SELinux denies to untrusted_app (avc: denied { read } … tcontext=custom_version_prop … app=eu.darken.amply). SystemProperties.get returns "" on denial instead of throwing, so SystemPropertyReader's runCatching never fired, nothing was logged, and LineageOsDetector.detect() silently returned null — getprop over adb had always worked because it runs as shell. Both Lineage adapters skipped and selection fell through to google-pixel-lab-v1, which (a) made QUALIFIED_CODENAMES dead — a qualified codename could never activate, (b) hid the "Help add support" wizard (contributionWanted defaults false on the Pixel adapter, true on the lab adapter), and (c) pointed "open battery settings" at Battery Saver, since the Pixel intent targets the absent Google Settings-Intelligence component and never tries POWER_USAGE_SUMMARY (which does resolve on LOS). Fixed by gating on the app-readable org.lineageos.android system feature (DeviceInfo.isLineageOs); the version property is kept as a secondary identity signal (OR-ed in, normally null on real hardware). The same run added a dumpsys lineagehealth probe to the device-support report. It is an observation, never a verdict, and never qualifies a device. Two reasons: selection is mode-dependent (upstream picks Deadline before Limit for MODE_AUTO/MODE_MANUAL, so this device's Provider: Deadline at Mode: 1 merely means nothing was learned), and there is no negative case at all — Toggle also accepts MODE_LIMIT and enforces the cap itself, so binding it is a capable mechanism rather than a rejection. Even NATIVE_LIMIT proves nothing: oriole bound Limit on LOS 20 and still charged past the cap. Only physical observation of the charge current qualifies a device. Oriole's NO-GO rests on the mode=3 write reading back as 1 plus the LOS 20 charge-past observation — both separate evidence from this probe. Note LineageOS spoofs Build.FINGERPRINT to stock (google/oriole/oriole:16/…/release-keys), so fingerprint sniffing is not a fallback. Otherwise clean on this ROM: install/launch/onboarding/dashboard/settings with no crashes, honest "Unsupported device" reporting, live battery monitoring across simulated plug/level transitions, and the charge alarm firing at threshold.
• GrapheneOS — landed live on remote qualification (issue #49; the only OEM row not tested on maintainer hardware), then re-gated to Shizuku-only after the 0.3.2-beta0 on-device report (see the follow-up ledger row). Resolved since the landing PR: package visibility ✔ verified from app context; app-context WSS access ✘ resolved as DENIED (@Protected — the reason for the re-gate, not a bug in Amply); factory-absent key state ✔ resolved from upstream source (BoolSetting default false → absent decodes as Unrestricted). Still open, all failing closed or cosmetic:
  • Shizuku read path verified, session behaviour still not — the 0.5.0-beta0 report on frankel (see the 2nd-device ledger row) shows Amply's own Shizuku service reading the key and offering the control on real hardware, under R8, so those two are closed. What that report does not cover, because the reporter did not run them: an 80% hold observed through the app rather than over adb, a full-charge session and its restore, and boot recovery. Every enforcement claim on this ROM still rests on the komodo adb runs, and one of them (the replug latch) is refuted on frankel — see the next entry.
  • External writes are not honoured on every build — REFUTED on frankel (Pixel 10, GrapheneOS 2026081301 / Android 17; issue #49, 2026-08-25). With Amply out of the loop entirely, a bare settings put global battery_charge_limit 0 made while unplugged, and confirmed off in the ROM's own Settings UI, was still ignored at the next plug-in: the device held at exactly 80% (level climbed 74→80, then NOT_CHARGING at 80 with power connected, no level above 80 all day, thermals ~33 °C so not a throttle; the app's package appears nowhere in the 52k-line capture). The same device's native Settings toggle works normally, so the divergence is the external-write channel, not the cap. Cause undetermined: komodo was qualified on 2026080501 and frankel observed on 2026081301, neither device tested on the other's build, so a ROM release change and a Pixel 10 generation difference fit the evidence equally. No public upstream report matches this direction (the known ones are the inverse — charging past the cap while the limit is on). One caveat on the evidence: the capture carries no settings-provider logging, so "the key read 0 at plug time" rests on the reporter's statement plus the ROM's UI, not on instrumentation.
    • Blast radius: every write on this adapter shares one path, so on a device behaving like this the dashboard/widget/tile persistent writes, session restore, and boot recovery are all hardware-level no-ops that read back as verified. Boot recovery's convergence loop returns DONE on the first tick for the same reason (a matching settings readback is treated as convergence). Nothing in the app can notice: this adapter does not set enforcementEvidenceRequired, and the passive verdict engine only detects a climb past a cap, which is the opposite direction from a ROM enforcing a cap that is configured off.
      • Do not answer this by setting enforcementEvidenceRequired on the adapter. Beyond the direction mismatch above, GrapheneOS deliberately runs a periodic recalibration charge to 100% with the limit still on. EnforcementVerdictEngine refutes on climbRose && percent >= cap + OVERSHOOT_ALLOWANCE, and its only suppressors are unplugged samples, a running Amply full-charge session, and a guided run — a ROM charging past a cap it still honours is none of those. A refutation is terminal for the build identity, so the first recalibration would switch the controls off on a device whose cap works, permanently.
    • The protective direction is UNRESOLVED, and it is the open safety question. Both observed failures wrote the limit off while the ROM kept enforcing, which leaves the battery protected and merely makes the UI dishonest. Whether a write turning the limit on is equally ignored — which would mean Amply claims protection that is not enforced — was asked of the reporter 2026-08-25 and run on 2026-08-27: the battery charged past a cap that had been written externally moments earlier. That settles nothing. The result is equally consistent with the ROM ignoring the external write and with the periodic recalibration charge to 100% described above, which climbs past a cap the ROM is honouring, and no signal in the run separates the two. Treat the question as open. Do not widen, re-qualify, or relax anything on this ROM until it is answered.
  • State 4 below the limit unverified — evidence was sampled at the 80% hold; if the ROM reports 4 only while holding, a FixedLimit pending clears late (at the hold) instead of instantly. Cosmetic.
  • A plugged restore configures but cannot enforce — restore-at-100%, the 24h safety timeout, manual restore, and a plugged boot recovery all write the protective value while a plug session is running; the ROM won't enforce it until the next replug, and no code path can change that (mid-session writes are ignored by design). Amply's state is correct — config protective, session/recovery closed, pending-until-replug hint shown — and the exposure is one charge cycle, bounded by the plug session the user is already in. Deliberately NOT treated as a defect.
  • A write made while unplugged had no honest state either — the entry above is about writes made during a plug session, which do get the pending-until-replug hint (settled requires a hardware confirmation whenever the write was not demonstrably made unplugged). A write made unplugged counts as settled, so the replug that follows produced a plain settings read-back and the app called that verified — exactly the claim frankel refutes. Now a configured cap that the hardware has not confirmed is shown as set rather than in effect, and the apply message says the value was saved instead of verified. This is a presentation fix only: nothing here can tell the two ROM behaviours apart, so the honest state is "unconfirmed" on both.
  • Wireless charging and secondary users: NOT RUN (gated to system user).
• Oplus (OnePlus/Oppo/Realme) — the live gate reads ro.build.version.oplusrom, which does not exist on pre-rebrand ColorOS, so every ColorOS 11-era build is invisible to it and lands on OnePlusLabAdapter. This is correct behaviour (those builds are unqualified either way), but it made reports from them uninformative.
  • Oppo F11 Pro CPH1969 (OP4863), Android 11 / ColorOS 11 — device-support report only, 2026-08-15. NOT a qualification run: no physical test, no Shizuku, no settings capture. The report carried oplus_rom_version=none and nothing else about the family, because the report probed only the Samsung, GrapheneOS, and LineageOS keys — the two ColorOS keys Amply already knows were never read. Absence of the property could not be distinguished from an SELinux-denied read either (SystemPropertyReader returns "" on denial). Prompted two report changes: an unprivileged presence probe of the two system keys, and tri-state probe results (present|absent|read_denied) so a refused read stops rendering as a proven negative. Still open: whether pre-rebrand ColorOS carries those keys under any name is unknown, and no legacy property (ro.build.version.opporom) is read, so pre-ColorOS-12 builds remain undetectable as Oplus by ROM version. A device with a working pre-15 ColorOS charge-protection feature would need a new gate signal, not a widened version constant — and the usual bar applies: physically observed charging cessation, not a settings mapping.
• Xiaomi — external-write handling RESOLVED (2026-08-16); the adaptive 80% hold remains unobserved and is now believed UNQUALIFIABLE on an unused test device. Split the old "adaptive enforcement unconfirmed" gap into its two halves — one is now closed, the other is characterized rather than merely open.
  • Closed: external shell-UID writes are functionally identical to native UI taps (Xiaomi 13T aristotle, HyperOS 2 OS2.0.216.0.VMFEUXM, Android 15, maintainer hardware). Both paths produce the same daemon chain with the same values, within ~80 ms of the write: ChargeProtectionUtils: getProtectMode mode:N → SmartChargeProtectManager: checkUiModeProtect:N → BaseChargeProtect_: MODE_NIGHT,setEnable fromShouldWork:false,to:false,enable:{true|false}. Verified in both directions and both origins (UI tap to Charge fully / Intelligent, external settings put … 0 / … 1). There is no hidden internal flag that only the Settings UI sets — an explicitly tested hypothesis, refuted. The native UI also reflects an externally-written key on next open. So Amply's write mechanism is complete and correct on HyperOS 2; nothing in the adapter needs changing for the write path.
  • Still unobserved: the hold itself. With the key at 1 (Intelligent, written externally), the device charged 59% → 100% continuously with no plateau at any level — uniform ~4 min per point, voltage and charge counter rising monotonically through 80 (4265→4293 mV, counter 3390000→3493000), status: 2 throughout. getNightChargingState was evaluated 140 times across the run and returned 0 every time (60 s cadence while charging). No hardware hold signal exists — Charging state: 0 / Charging policy: 0 in all states, same as HyperOS 3.
  • Root cause of the non-engagement: the gate is a LEARNED schedule, not a clock window. Strings in com.miui.securitycenter (com.miui.powercenter.nightcharge) show the feature keeps a statistical model of habitual overnight charging: key_ave_night_charge_start_minutes, key_night_charge_start_minutes_sd, key_night_charge_end_minutes_sd (standard deviations), key_enter_night_charge_times (occurrence count), key_earliest_night_charge_end_minutes, key_night_charge_record, plus four distinct isNeedNightChargeProtection return false case 1..4 rejection paths. Directly corroborated: forcing the device clock to 02:30 (via cmd time_detector set_time_state_for_tests; shell UID lacks both SET_TIME and SUGGEST_MANUAL_TIME_AND_ZONE) did not open the window — isNightChargeProtectionOpen stayed false. Time of day alone is insufficient; the daemon wants a low-variance charging history the device does not have.
  • Consequence for qualification: this device cannot settle it. The 13T is a maintainer test device with no normal daily use, so it can never accumulate the routine the model requires. Qualifying Adaptive would need either weeks of genuine (or convincingly simulated) nightly charging at a consistent time, or root to seed SecurityCenter's private prefs. Record the July "could not be triggered" and this run as the same result with a now-known cause, not as two independent failures. Adaptive on Xiaomi is therefore BLOCKED, not FAILED — no evidence exists that it fails to hold, only that its precondition never became true.
  • Consequence for the adapter, RESOLVED in the same change (see XiaomiChargingAdapter.kt, defaultProtectivePolicy = Adaptive): Amply's protective policy on HyperOS 2 is a mode that, by the OEM's own design, only acts inside a learned overnight window, so a device with Adaptive configured charges to 100% outside it. The read was never wrong (the mode genuinely is configured) but "protected" overstated it. The default stays — HyperOS 2 offers no unconditional protective mode — and the honesty moved to presentation: ChargePolicy.enforcementIsConditional + ChargeObservation.provesPolicyInEffect() withhold the confirmed checkmark from a conditional policy that only settings can vouch for. Verified on aristotle itself (2026-08-16, foss debug + direct WSS): Adaptive renders with the neutral shield and "the system chooses when it applies", 100% still renders with the green check and the plain readback line, and both apply without a settling spinner — the last point being the visible symptom if the predicate ever leaks into pending logic. Note HyperOS blocks adb installs behind an on-device "Install via USB" dialog with a 5s auto-deny, so an install must be confirmed on screen while it is awake.
  • Dead end, do not re-investigate: global battery_charging_state_enforce_level and battery_charging_state_update_delay (both -1 on this device) look like an enforcement lever from their names — they are not. Resolved 2026-08-16 by disassembling the device's own /system/framework/services.jar (dexdump): both are read by com.android.server.power.stats.BatteryStatsImpl$Constants, alongside KEY_BATTERY_CHARGED_DELAY_MS, KEY_MAX_HISTORY_FILES, and KEY_KERNEL_UID_READERS_THROTTLE_TIME. This is stock AOSP battery-statistics bookkeeping (when batterystats treats the device as charged, for history reset), not Xiaomi charge control, and it cannot cap charging current. Never written to. Recorded here specifically so the plausible-sounding name does not cost anyone a second investigation.
  • HyperOS 3 candidate mapping (contribution report, 2026-08-07 — unqualified at the time; since landed, see the LANDED bullet below). A Redmi Note 14 24117RN76G (tanzanite, Android 16 / SDK 36, ro.mi.os.version.code=3, ROM 3.0.302.0.WOGMIXM.C08) reported via the contribution wizard that the same key secure/security_pc_secure_protect_mode_key now carries three modes: 0 = Charge fully and 1 = Intelligent charging (labels matching HyperOS 2), plus a new 2 = Battery protection — apparently a hard-cap mode, which HyperOS 2 lacks entirely. The device correctly fell through to XiaomiLabAdapter, and the existing decode treats 2 as Unknown(unrecognizedValue=true) (refuse-don't-clobber — the test that pins this was written as a garbage-value guard; 2 is now known to be a real, named OEM mode). This is a settings mapping only: no behavioral evidence (the optional effect prompts were skipped), the cap percentage is unknown (modeling mode 2 needs a concrete FixedLimit percent), factory/absent-key semantics on HyperOS 3 are unknown, and whether value 2 is HyperOS-3-wide or model-specific was initially unconfirmed (answered 2026-08-13: not HyperOS-3-wide — see the marblein data point below). A full qualification would also need the boundary write domain widened from {"0","1"} (ChargingControlUserService). The contributor has a working Shizuku setup (clean three-namespace, three-mode capture) — a strong candidate for a follow-up qualification run; the report thread is in support mail ("Amply device-support discovery", 2026-08-07) and GitHub issue #48.
    • Follow-up (2026-08-13, comment on PR #52, same tanzanite device): cap-percent candidate 80 — still unqualified. The contributor claims mode 2 hard-caps at 80% and attached a dumpsys battery snapshot at the cap (level: 80, AC powered: true). Not accepted as hold evidence: it is a single snapshot (no sustained-hold observation, no current reading — a battery passing through 80 looks identical), the dump itself reports status: 2 (= CHARGING) with Charging state: 0 / Charging policy: 0 (no hardware hold signal), and how mode 2 was set (native UI vs external write) is unstated — so daemon enforcement of external writes, the decisive question for Amply and open even on qualified HyperOS 2, remains unproven. Follow-up runs requested in the issue #48 thread: sustained hold at 80 with current_now, and the both-direction external-write test (adb settings put to 2 below the cap → hold; back to 0 mid-hold → charging resumes past 80). Delivered 2026-08-14 — see the enforcement bullet below.
    • Both-direction external-write enforcement DEMONSTRATED (2026-08-14, issue #48, same tanzanite device). The contributor ran the requested protocol via on-device adb shell — the shell UID, the same write path Amply's Shizuku service uses. (1) Below 80% plugged, UI manually set to "Charge fully", settings put secure security_pc_secure_protect_mode_key 2 → Battery Protection activated and the Settings UI reflected it immediately, so the daemon reacts to external key writes, not just its own UI. (2) Held at 80% for ~20 minutes plugged under active use without gaining a point; sysfs current_now was permission-denied so there is no current reading, but the dumps corroborate the hold indirectly (voltage 4228 mV at the hold vs 4391 mV after resume; charge counter 4283 vs 4341). (3) settings put … 0 mid-hold → charging resumed immediately, UI followed, level passed 80. Caveats: hold evidence is level observation plus voltage/counter deltas, not a current measurement, and both dumps show status: 2 / Charging state: 0 / Charging policy: 0 — HyperOS 3 exposes no hardware hold signal, so a future adapter gets readback-only verification (like Samsung, unlike Pixel/GrapheneOS). This answers the decisive daemon-enforcement question for tanzanite mode 2; the remaining items (gate design, boundary widening, factory/absent-key semantics, sessions/access-tiers/R8) are tracked in the landing bullet below.
    • Second HyperOS 3 data point (support mail, 2026-08-13): the hard-cap mode is NOT HyperOS-3-wide. A Poco F5 23049PCD8I (marblein, Android 15 / SDK 35, HyperOS 3.0.2, ROM OS3.0.2.0.VMRINXM) reported via the contribution wizard only the two HyperOS-2-style modes on the same key (1 = Intelligent charging, 0 = Charge fully) — no value 2 and no hard-cap option captured. So mode 2 is model- and/or Android-16/OS-3.0.3-dependent, and a future HyperOS 3 gate cannot infer the hard-cap mode from ro.mi.os.version.code == 3 alone. Caveats: the wizard saw changed_rows=2 but the contributor withheld one row in the privacy review (mapping possibly incomplete), and the device was previously

…(truncated)