菜单
Amply's physical qualification protocol for OEM charge-control adapters, the ledger of verified devices (Pixel/Samsung/Xiaomi/OnePlus), and known gaps per OEM. Use when qualifying a new device or ROM, widening a capability gate, adding a codename to an allowlist, or recording device test results.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/d4rken-org/amply --skill device-qualification命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Per-OEM charge-control adapter detail for Amply — the exact settings keys, value domains, write ordering, verification strategy, and session override of the Samsung, Xiaomi, OnePlus/ColorOS, LineageOS, and Pixel adapters. Use when reading or changing anything under charging/core/adapter, adding an adapter, or reasoning about how a policy maps to real settings values.
Amply's release process — versioning via version.properties/bump.sh, signing material, the release-prepare/release-tag workflows, store-listing metadata, Play Store screenshot generation, and the Google Play publication gate. Use when cutting a release, bumping a version, regenerating store screenshots, or touching signing/release CI.
正在显示 SKILL.md
基于 SOC 职业分类
| name | device-qualification |
| description | Amply's physical qualification protocol for OEM charge-control adapters, the ledger of verified devices (Pixel/Samsung/Xiaomi/OnePlus), and known gaps per OEM. Use when qualifying a new device or ROM, widening a capability gate, adding a codename to an allowlist, or recording device test results. |
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.
Adding or widening a live adapter requires physical qualification, not just a settings mapping:
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).charging_policy / current), not just the Settings UI.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.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 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.
| OEM | Tested device / build | Hardware evidence | Coverage | Landed |
|---|---|---|---|---|
| Pixel | Pixel 8 shiba A17/API37; Pixel 9 Pro caiman A16/API36; Pixel 7a lynx A16/API36 | Full — sysfs charging_policy follows writes (~11–12s) | Access tiers, sessions, boot recovery, wireless hold, at-threshold, reconnect gesture, natural 100%, interrupted-session detection (7a) | 2026-07-15/-19/-20/-25 |
| Samsung | Galaxy Tab A9+ SM-X210 One UI 8.0; Galaxy S20 FE SM-G781B One UI 4.1 | Full — sync readback + HAL enforcement | Modern multi-mode + legacy toggle, session E2E, native-change cancel, reboot recovery, R8 beta | 2026-07-21 |
| Xiaomi | Xiaomi 13T 2306EPN60G (aristotle) HyperOS 2.0 (ro.mi.os.version.code=2); 2026-08-16 re-run on OS2.0.216.0.VMFEUXM / Android 15 | Partial, now characterized — external shell-UID writes provably drive the daemon identically to native UI taps (getProtectMode → checkUiModeProtect → setEnable, ~80 ms, both directions, no hidden UI-only flag). The adaptive 80% hold is still unobserved: charged 59→100% with no plateau, getNightChargingState = 0 on all 140 evaluations. Cause identified — the gate is a learned charging-routine model (key_ave_night_charge_start_minutes, …_sd, key_enter_night_charge_times), not a clock window (forced clock to 02:30 did not open it). BLOCKED on an unused test device, not FAILED. No hardware hold signal (Charging state/policy = 0/0) | Read matrix, both-direction writes, session at 100%, unknown-value refusal, R8 beta (2026-07-21). Added 2026-08-16: external-vs-UI write-path equivalence, native UI reflects external key, learned-schedule root cause, clock-forcing negative | 2026-07-21 / 2026-08-16 |
| OnePlus (Oplus) | OnePlus Nord CE4 Lite CPH2621 ColorOS 15 (ro.build.version.oplusrom=V15.0.0) | Full — enforcement directly observable (device holds at 80%); external writes stick | Two mutually-exclusive system keys (Charging limit / Smart charging), WSS-only write rejected + Shizuku write succeeds for all three policies, WSS-only UX (controls disabled + Shizuku-required banner) |
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.
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.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 and re-verified by read-back; / were never written.
: 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 .
: a few hours after the run above,
the device was found at with still reading — i.e. a level
above the cap. It is 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 (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.
: same device, same Lineage major version, different build, opposite HAL
capability. That is the concrete case for HAL capability being , 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 to stock, so the
fingerprint alone cannot carry it.| 2026-07-21 |
| GrapheneOS | Pixel 9 Pro XL komodo, GrapheneOS 2026080501 / Android 17 — REMOTE qualification via issue #49 (tester-run protocol, not maintainer hardware) | Enforcement observed: held at 80% with shield, dumpsys battery status=4/Charging state=4/policy=2 (limit on) vs 2/1/1 (off); shell-UID writes move the Settings UI live, latch at plug-session start — mid-session writes have no hardware effect until unplug→replug, replug reliably applies the current value | Key isolation (settings list diff → single global battery_charge_limit 0/1), write→UI both directions, mid-session no-op both directions, replug latch both directions, hardware signal both states. NOT run: app-context access tiers (WSS write from Amply, app.grapheneos.* package visibility), sessions/boot recovery, wireless, factory-absent key state, secondary user | 2026-08-12 |
| Xiaomi (HyperOS 3) | Redmi Note 14 24117RN76G (tanzanite), HyperOS 3.0.302 / Android 16 (ro.mi.os.version.code=3) — REMOTE qualification via issue #48 (contributor-run protocol, not maintainer hardware) | Both-direction enforcement of EXTERNAL shell-UID writes observed (the same write path as Amply's Shizuku service): settings put … 2 below the cap → Battery protection active, Settings UI follows immediately, held at 80% for ~20 min under active use (voltage 4228 mV holding vs 4391 mV charging, charge counter 4283 vs 4341 corroborate; sysfs current_now permission-denied, so no current reading); settings put … 0 mid-hold → charging resumes past 80 immediately. No hardware hold signal: dumpsys battery reports status: 2 / Charging state: 0 / Charging policy: 0 in both states → read-back-only verification | Key mapping (three modes incl. 2 = Battery protection @80, cap fixed — no percent picker), external write → UI both directions, sustained hold, mid-hold release. Beta run 2026-08-14 added: app-context three-mode control (direct WSS), factory-absent key = Intelligent (confirmed). Session restore FAILED in that run (observer noise cancel — app bug, fixed in #65). Re-verified 2026-08-16 on v0.3.4-beta0: session restore PASSES — full-charge session ran to 100% and Battery protection was re-written automatically while still plugged. NOT run: Shizuku tier, boot recovery, wireless, R8, unplug-early restore | 2026-08-16 |
| GrapheneOS (follow-up) | Same device, 0.3.2-beta0 on-device report via issue #49 | Package detection VERIFIED from app context (is_grapheneos=true with the FLAG_SYSTEM check); unprivileged key read DENIED — has_battery_charge_limit=false while the very same report showed battery_charging_status=4 (limit enforcing). Root cause in GrapheneOS source: the key is @Protected(read = SYSTEM_UI, readWrite = SETTINGS) (frameworks_base c30c6393); SettingsProvider throws SecurityException for all other packages including WSS holders, with the shell UID explicitly exempt ("ADB is used for testing", e87c93a2) — so the tester's earlier adb runs ARE the Shizuku-path evidence. Factory-absent semantics resolved from source: BoolSetting(..., default false) → absent = off | Detection + fail-closed probe verified live; adapter re-gated to Shizuku-only in response | 2026-08-13 |
70enabledmodeQUALIFIED_CODENAMEScharging_control_charging_limit70Tue Jul 21 02:01 CESTBuild.FINGERPRINTcontent 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.)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.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.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.@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:
settings get/put mechanism is proven (the
tester's adb runs), but Amply's own Shizuku service driving it, plus sessions/boot recovery/R8 smoke, await the
next beta report on issue #49.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.
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.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.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.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.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.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.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.
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 was set (native UI vs external write) is unstated — so daemon enforcement of
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 , and
the both-direction external-write test (adb to below the cap → hold; back to
mid-hold → charging resumes past 80). Delivered 2026-08-14 — see the enforcement bullet below.AdapterRegistry and adapter=none is a genuine registry miss. There is no
HONOR-related read anywhere in the codebase: no property, no system feature, no package lookup.
First HONOR mapping candidate (support mail, 2026-08-14): HONOR Magic8 Pro BKQ-N49 (codename HNBKQ
from the fingerprint, MagicOS 10.0.0.193, Android 16 / SDK 36, contribution schema 2, app 0.3.2-beta0). The
three earlier HONOR reports produced nothing: #35 (MTN-NX1M, Magic8 Lite) captured changed_rows=0 across
all three namespaces, #40 and #47 carried no capture at all.
The contributor captured the full 2×2 factorial of two independent features, which is the only capture
design that can attribute two keys to two features. Both changed rows are in the system namespace:
| Mode | Smart battery capacity | smart charge | UserSmartPeakCap | asw_ui_state |
|---|---|---|---|---|
| off | off | off | 1 | 1 |
| Smart battery capacity | on | off | 0 | 1 |
| smart charge | off | on | 1 | 0 |
| both | on | on | 0 | 0 |
UserSmartPeakCap anti-correlates perfectly with Smart battery capacity, asw_ui_state with smart charge;
both are 1-when-disabled. Inverted polarity is not itself a problem (every adapter owns its decode), and
"peak capacity 1 = uncapped" fits the name equally well.
Blocker 1 — no behavioral evidence. All four user_reported_effect values are unsure, so nothing
here distinguishes a real control from a mirror. asw_ui_state is specifically suspect: a _ui_-named key
is the same class as the Oplus _status mirrors that OnePlusChargingAdapter deliberately never writes.
If it is a mirror, the real smart-charge control produced no diff row at all and lives outside the settings
providers. Next step is the both-direction external-write test (settings put system <key> <value> from
the shell UID, then check whether HONOR's own battery screen and the charging hardware follow), the same
test that settled tanzanite. The contributor completed the Shizuku-gated wizard, so they have a working
Shizuku setup and are a strong candidate to run it.
Blocker 1, HALF resolved (support mail, 2026-08-16). The contributor ran the external-write test from
Termux via Shizuku/rish. Both keys accept the write and HONOR's own battery screen follows the value in
both directions, for UserSmartPeakCap/Smart battery capacity and for asw_ui_state/Smart charge alike.
That rules out the read-only-mirror class the Oplus comparison pointed at — the ColorOS _status keys
are read-only (95618cc: "The OEM enforces exclusion and mirrors a read-only _status"), and these are
not. The _ui_ name is no longer a reason to distrust asw_ui_state specifically.
It does NOT satisfy step 2 of the protocol, which passes only when writes move the real charging
hardware, "not just the Settings UI". The surviving failure mode is a key the Settings UI genuinely reads
and writes while a separate mechanism drives the charger — precisely the oriole/LineageOS 20 result
(write accepted, ChargingControlController picked it up and reported the new config back, battery charged
92→95% at ~1.2 A). Treat UI-follows-write as a precondition met, never as qualification.
Smart charge is adaptive, not a cap (same mail). Overnight the device reaches 100% by morning, matching
HONOR's described hold-then-top-off behaviour. So the feature maps to ChargePolicy.Adaptive, not a
FixedLimit, and there is no plateau for the step-2 hardware test to observe — only Smart battery
capacity is hardware-testable here, and it is also the key carrying the level hazard below. Note the
Adaptive honesty gap recorded for Xiaomi above applies identically: allowsFullCharge
(ChargePolicy.kt:12-13) excludes Adaptive, so Amply would call this "protective" for a mode that reaches
full on its own.
Blocker 2 — no gate signal identified. The fingerprint is stock-shaped
(HONOR/BKQ-N49/HNBKQ:16/HONORBKQ-N49/10.0.0.193C636E4R106P1:user/release-keys), so fingerprint sniffing
is out for the same reason it was for LineageOS. Whether a MagicOS-exclusive property analogous to
ro.mi.os.version.code exists and is readable from an untrusted_app process is unknown and cannot be
settled by adb getprop (adb runs as shell — see the SELinux trap above). Build.MANUFACTURER == "HONOR"
alone is a manufacturer gate with no ROM scoping, weaker than every existing OEM gate.
Unchanged by the 2026-08-16 follow-up, and it outlives the mapping: even a clean hardware result leaves
no safe way to switch an adapter on only where it applies. Asked the contributor for pm list features and
pm list packages -s filtered on honor/magic, i.e. the two mechanisms that are app-readable and already
carry LineageOS (org.lineageos.android system feature) and GrapheneOS (app.grapheneos.* core packages).
A property would not do, for the reason above. Also note the app itself cannot answer this: property names
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:
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.FLAG_SYSTEM — the GrapheneOS pattern):
com.hihonor.systemserver, com.hihonor.systemmanager, com.hihonor.powergenie,
com.hihonor.controlcenter, com.hihonor.android.launcher.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
early via RESTORE_FULL, and would corrupt StatsLimitHitDetector. Verify before any adapter ships.
Three sharpenings (2026-08-16), because the phrasing above understates it:
BATTERY_STATUS_FULL alone trips it
(ChargeSessionService.kt:374). Guarding only percent >= 100 would close nothing: a ROM that fakes
the level almost certainly drives EXTRA_STATUS through the same platform path. full is also the
first branch of SessionDecisionEngine.decide (SessionDecision.kt:122), outranking the safety
timeout, the disconnect path and the replug grace window, and the resulting RESTORE_FULL is silent —
Amply re-applies the protective policy and believes it finished the job.dumpsys battery (level/status/voltage/charge counter), not
the status bar.BatteryReadoutFactory.kt:54-57 rejects only a malformed level/scale
pair. Tolerating a lying ROM would be new work with no existing seam, so do not describe it as a
compatibility tweak. Blast radius beyond sessions: StatsLimitHitDetector.kt:44 returns false
unconditionally at ≥100 (the "limit reached" signal would never fire on exactly this device class), and
ChargeAlarmEngine.kt:39 would fire at any configured target outside a session (inside one,
sessionActive suppresses it).
Measurement asked for (2026-08-16): charge to a displayed 100% with Smart battery capacity ON, record
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 .
Contributor-run, :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
codebase mention is a KDoc line in GrapheneOsChargingAdapter.kt:25 describing what GrapheneOS's key does
underneath), and ChargePolicy cannot express a bypass-only state. Not a candidate for the write allowlist.
rom_version=magicos 10.0.0.193 in the report is free text typed by the contributor, not a detector
output; one_ui_version=none / hyperos_version=none are the real detectors correctly returning null.
Note also that contribution reports carry no codename field (unlike the direct device-support report),
so an allowlist entry can only come from the fingerprint or a follow-up. Asked the contributor to run the
"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.
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.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.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 ).
(, EXIF ,
): Amply's own "Charge counter" row reads , which is
— the same raw the contributor's showed, so both read one source
and it is scaled by 1000 on a 7100 mAh cell. Second, unprompted corroboration in the same screenshot:
, which is impossible; a real
~300 mA arrives as and is 0. The competing "genuine end-of-charge trickle"
explanation is dead.
( +
). MagicOS is recognised by system feature
( / , either suffices, no
and no permission), and the reading must show an implied full-charge capacity below 100_000 µAh
— , which normalizes out the charge level, separating a correct phone
(≥ ~1_000_000 µAh at any level) from a milli device (single-digit thousands) by an order of magnitude
on both sides. So a correctly-reporting MagicOS build is left alone, and no other ROM can ever be
touched.
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.
2current_nowsettings put20tanzanite
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.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 rooted with
FDE.ai driving the charge limit. Thread: support mail "Amply device-support discovery", 2026-08-13.
Confirmed by native-UI screenshot (2026-08-14, same thread): the F5's Battery protection screen
shows a "Charging protection" group with exactly two entries — "Charge fully" and "Intelligent charging"
(described as stopping at 80% "in applicable situations", i.e. the adaptive mode) — and no hard-cap
option anywhere. This upgrades the finding from a wizard-capture inference to a direct observation of
the OEM UI. It does not resolve the cause: tanzanite differs from marblein in both model and
Android 16 / ROM 3.0.3, so model-dependence vs Android-16/OS-3.0.3-dependence remain confounded, and
the codename gate stays the only sound design either way.
Support status for marblein: correctly diagnostics-only, and NOT a candidate for
xiaomi-hyperos3-v1. That adapter's protective default is FixedLimit(80) = mode 2, which this
device lacks; allowlisting the codename would let apply() write "2", read it back from the settings
row, and decode Verified(FixedLimit(80)) while the daemon ignores it — a false claim of an active cap.
The device's real surface is the two-mode HyperOS 2 one (1/0), reachable only by widening
QUALIFIED_HYPEROS_VERSION from 2, whose sole protective mode is Adaptive — blocked on the
project-wide open item above (adaptive enforcement unobserved on both HyperOS generations), not on
anything specific to this device.xiaomi-hyperos3-v1, gated to a qualified-codename allowlist (tanzanite only) —
GrapheneOS-precedent landing (remote enforcement qualification via issue #48, see the Verified devices
row). First on-device verification run (2026-08-14, issue #48; contributor-run, presumably on
v0.3.3-beta0 — the first release carrying the adapter):
settings delete → settings get returns null, and both the native
battery settings and Amply fall back to Intelligent charging. Absent = Intelligent is the real factory
semantic; the shipped decode is correct.settings get per switch). Access tier in the run: direct WSS (dashboard showed
"Read back through direct wss"); the Shizuku tier remains unexercised on this device.NativeChangeGuard (readback-verified cancellation, see
rules/architecture.md).RESTORE_FULL path fires without needing
a disconnect, and NativeChangeGuard no longer eats the session on this device's notification
pattern — the guard fix is now confirmed against the exact device that produced the bug. This closes
the only failing item from the 2026-08-14 run; tanzanite becomes the second remote-qualified device
with a verified session lifecycle. Still NOT run here: the disconnect-early restore path
(RESTORE_DISCONNECTED), the Shizuku access tier, boot recovery, and an R8 beta/release smoke.2's own
description says the device will "charge fully only when scheduled" — HyperOS reserves an OEM-side
scheduled full charge while in Battery protection. No code impact (verification is settings readback;
sessions override with 0), but a future "charged to 100% while protected" report may be this OEM
behavior rather than a bug.1) enforcement undemonstrated — identical provisional status as HyperOS 2 (the
top-level Xiaomi gap above); only mode 2 has demonstrated hardware enforcement.XiaomiHyperOs3ChargingAdapter.QUALIFIED_CODENAMES.tanzaniteHNBKQ| 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 |
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.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.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.StatsPowerCalculatorTestScreenshot_…_MainActivity.jpgmodel=BKQ-N4910.0.0.193(C636E4R106P1)round(6978 / 1000)6978dumpsysCurrent now = 0 mA while Status = Discharging with the screen on300round(300/1000)BatteryUnitCalibration.romMisreportsUnitsBatteryReadoutFactory.chargeCounterLooksMilliScaledcom.hihonor.software.features.honorcom.hihonor.system.feature<queries>counter × 100 / percentCURRENT_NOW and
CHARGE_COUNTER are independent HAL fields, so an impossible counter proves nothing about
current. A device with a broken, stale or freshly-reset counter but healthy current would have
had a real 50 mA turned into 50 A, computing to ~200 W, which slips under
StatsPowerCalculator's 250 W ceiling and lands in recorded stats as a believable lie.BATTERY_STATUS_CHARGING
while drawing under 5 mA), latched because that evidence only exists while charging. Also
refuted, and by Amply's own domain: a device at a charge-limit hold reports exactly that —
StatsLimitHitDetector uses abs(current) < 50_000 µA while CHARGING as its hold signal.
Amply creates holds deliberately, so a healthy phone holding at 80% with a broken counter
satisfied the conjunction and latched. There is no impossibility boundary here to build on.
The lesson generalizes: the states that look like this defect are states this app manufactures, so
a purely data-driven unit inference is unsound in this codebase specifically. Being wrong about a ROM's
units shows wrong numbers; being wrong about a healthy device corrupts good ones — the gate can only
ever do the former. Generalizing "all MagicOS" from one device is a deliberate bounded bet, far cheaper
than the adapter equivalent because the failure mode is a wrong battery figure, not a false claim that
a battery is protected. Other affected ROMs stay uncorrected until one is confirmed and added.
Other accepted limits: a device reporting no counter is undetectable, and the charger-advertised
max_charging_* extras are deliberately not rescaled, being separate extras never observed populated
on such a device.
Known wart, accepted: ChargeStatsRecorder persists the readout, so history recorded before the fix
keeps the uncorrected values and a chart spanning the upgrade shows a 1000× step. Only affects devices
that were already reporting garbage, and no migration can identify which stored rows came from a
milli-reporting device.