[Device support] Xiaomi 24117RN76G — settings discovery

[kreza6173-pixel]

Thanks for helping add support for your device. Everything below was collected on-device and reviewed by you before sending.

This is candidate discovery to help a maintainer reproduce the mapping — not a guarantee of support.

contribution_schema=2
created_epoch_ms=1786134770259
app_version=0.3.0-beta0 (300000)
manufacturer=Xiaomi
model=24117RN76G
android_sdk=36
fingerprint=Redmi/tanzanite_global/tanzanite:16/BP2A.250605.031.A3/OS3.0.302.0.WOGMIXM:user/release-keys
one_ui_version=none
hyperos_version=3
adapter=xiaomi-lab
rom_version=Redmi note14,3.0.302.0.WOGMIXM.C08
feature_name=Battery protection
modes=Charge fully | Battery protection | Intelligent charging
captured_mode_count=3
scanned_namespaces=secure,global,system
changed_rows=1

# changed settings (value per mode, in the order above)
secure/security_pc_secure_protect_mode_key = 0 | 2 | 1

# notes
Android 16 HyperOS 3
Battery Protection 

[kreza6173-pixel]

The physical test was conducted and attached alongside the complete logs:

#52 (comment)

[d4rken]

Thanks, that snapshot gives us the missing cap percentage for mode 2: 80%.

It's not enough to qualify HyperOS 3 yet. The dump is a single moment in time: a battery at 80% while plugged looks the same whether it's holding there or just passing through, and the dump itself still reports status: 2 (charging). To show the cap holds, keep the phone plugged at 80% for 30–60 minutes and capture either a few dumpsys battery samples over that period, or a current reading while it sits at 80:

adb shell cat /sys/class/power_supply/battery/current_now

That should be near zero while holding.

The bigger question is how you enabled Battery Protection: through the Settings UI, or by writing the key over adb? Amply can only write the setting key, and Xiaomi's charging daemon might only react to changes made through its own UI. What we need to see is that an external write moves the hardware in both directions:

1. Key at 0, phone plugged, battery below 80%. Set the mode without opening the Settings app:

   adb shell settings put secure security_pc_secure_protect_mode_key 2
   

   Confirm charging stops at 80 and holds (sustained, as above).
2. While it holds at 80, switch back:

   adb shell settings put secure security_pc_secure_protect_mode_key 0
   

   Confirm charging resumes past 80.

A note on whether the Settings toggle follows each adb write would also help. If both directions work, that's the core evidence needed to add HyperOS 3 support.

[kreza6173-pixel]

Hello, @d4rken

Thank you for reviewing and taking the time to provide these additional details. 🙏
I tried to follow all the steps carefully step-by-step. If anything is missing, please let me know and I'll be happy to help.

Regarding your first question: My battery supports fast charging automatically. Once it hit 80%, it remained plugged in for about 10 to 15 minutes. The previous dump was also taken after reaching the 80% cap while set to full charge mode, so I can definitely confirm that it didn't gain even a single percentage point. That said, I ran the full test suite again from scratch, and here are the complete results:

---

Step 1: Writing the key via ADB (Battery below 80%)

While charging below 80%, I executed the command directly via on-device ADB shell:

bash
adb shell settings put secure security_pc_secure_protect_mode_key 2

Terminal output: Command completed with no output. ✅
Before running this, I had manually set the charging mode back to the default "Full Charge" in the system settings UI. Upon executing the ADB command, Battery Protection (capped at 80%) was fully activated—I checked immediately, and the change reflected in the Settings UI right away. ✅

///

Step 2: Holding at 80% while plugged in
After reaching 80% while still on the charger, I ran:

adb shell cat /sys/class/power_supply/battery/current_now

This command returned a Permission denied error.
So I grabbed a full log using dumpsys battery. Based on both the log output and practical observation, I can fully confirm that even after leaving the phone plugged in for 20 minutes while actively using it, the charging process was completely halted. ✅

Current Battery Service state:
  AC powered: true
  USB powered: false
  Wireless powered: false
  Dock powered: false
  Max charging current: 12400000
 Time when the latest updated value of the Max charging current was sent via battery changed broadcast: +13h52m17s3ms
  Max charging voltage: 11000000
  Charge counter: 4283
  status: 2
  health: 2
  present: true
  level: 80
  scale: 100
  voltage: 4228
 Time when the latest updated value of the voltage was sent via battery changed broadcast: +14h2m23s878ms
 The last voltage value sent via the battery changed broadcast: 4226
  temperature: 330
  technology: Li-poly
  Charging state: 0
  Charging policy: 0
  Capacity level: 4
MiuiBatteryService first usage time:
  mSetBatteryUsageTimeCount=56
  mNtpTime=1779945046315
  mParseNtpTime=20260516

///

Step 3: Resuming full charge via ADB
After 20 minutes of confirming zero power intake, I executed the final command:

adb shell settings put secure security_pc_secure_protect_mode_key 0

The charging process immediately reverted to default (Full Charge). This was reflected in the Settings UI right away, the battery level started increasing, and it successfully passed 80%:

Current Battery Service state:
  AC powered: true
  USB powered: false
  Wireless powered: false
  Dock powered: false
  Max charging current: 12400000
 Time when the latest updated value of the Max charging current was sent via battery changed broadcast: +13h52m17s3ms
  Max charging voltage: 11000000
  Charge counter: 4341
  status: 2
  health: 2
  present: true
  level: 81
  scale: 100
  voltage: 4391
 Time when the latest updated value of the voltage was sent via battery changed broadcast: +14h19m6s536ms
 The last voltage value sent via the battery changed broadcast: 4385
  temperature: 335
  technology: Li-poly
  Charging state: 0
  Charging policy: 0
  Capacity level: 4
MiuiBatteryService first usage time:
  mSetBatteryUsageTimeCount=56
  mNtpTime=1779945046315
  mParseNtpTime=20260516

[d4rken]

That's the evidence we needed. Your run confirms that an external write of the key moves the actual charging behavior in both directions, and that the Settings UI follows each write. The missing current reading isn't a problem: the 20-minute hold plus the voltage difference between your two dumps (4228 mV while holding vs 4391 mV while charging) is convincing.

On what happens next: support won't be a quick flip. Another HyperOS 3 report (a Poco F5 on HyperOS 3.0.2 / Android 15) shows only the two old modes on the same key, with no Battery Protection option at all. So the app can't assume mode 2 exists on every HyperOS 3 build and needs a more careful capability check, plus a reviewed change to its internal write allowlist.

One more question: in your Battery Protection settings screen, is the cap fixed at 80%, or can you pick a different percentage?

Once a test build with HyperOS 3 support exists, I'd like to come back to you for a verification run on your device, if you're up for it. I'll post it in this thread.