Charging: Record the HyperOS 3 candidate mapping from a device contribution - #52
Merged
Conversation
…bution A Redmi Note 14 (tanzanite, Android 16, HyperOS 3) contribution report shows secure/security_pc_secure_protect_mode_key carrying a third value 2 = "Battery protection" alongside the HyperOS 2 values (0 = charge fully, 1 = intelligent). Docs and comments only: a candidate-mapping entry in the qualification ledger's known gaps, and the "no hard-cap mode exists" / "future HyperOS 3" statements scoped to HyperOS 2. No behavior change; HyperOS 3 stays diagnostics-only pending physical qualification.
d4rken
added
documentation
|
Qualification Evidence for HyperOS 3 Battery |
d4rken
added a commit
that referenced
this pull request
Aug 14, 2026
…tion ledger (#61) * Charging: Record the HyperOS 3 cap-percent follow-up in the qualification ledger A GitHub follow-up (PR #52 comment / issue #48) from the tanzanite contributor claims mode 2 hard-caps at 80% with a dumpsys snapshot at the cap. Recorded as a cap-percent candidate (80) only: a single snapshot with status=2 (charging) and no hold/current observation is not hold evidence, and how the mode was set is unstated, so daemon enforcement of external writes stays unproven. The requested follow-up runs (sustained hold, both-direction external-write test) are listed in the issue #48 thread. * Charging: Record the second HyperOS 3 data point (marblein, no hard-cap mode) A Poco F5 contribution report (HyperOS 3.0.2 / Android 15) shows only the two HyperOS-2-style modes on security_pc_secure_protect_mode_key, answering the ledger's open question: the tanzanite hard-cap value 2 is not HyperOS-3-wide but model- and/or Android-16-dependent, so a future HyperOS 3 gate cannot infer it from the version code alone. Caveats recorded: one wizard row withheld by the contributor, prior root with FDE.ai charge-limit control.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
No user-facing behavior change. Documentation only: records the first HyperOS 3 data point — a user-contributed discovery report showing Xiaomi's charge protection on HyperOS 3 carries a third mode ("Battery protection") on the same setting key — in the device-qualification ledger, and scopes the now-outdated "no hard-cap mode exists" / "future HyperOS 3" statements to HyperOS 2.
Technical Context
tanzanite, Android 16,ro.mi.os.version.code=3):secure/security_pc_secure_protect_mode_key= 0/2/1 for Charge fully / Battery protection / Intelligent charging. Values 0/1 match HyperOS 2; value 2 is new..ktchanges are KDoc/comment text only.