[Device support] realme RMX3988

[aledalovers]

Thanks for helping add support for your device. The details below were collected on-device.

Device

Amply device-support request
report_schema=10
app_version=0.5.0-beta0 (500000)
distribution=foss/beta
manufacturer=realme
brand=realme
model=RMX3988
device=RE5CA3L1
product=RMX3988
fingerprint=realme/RMX3988/RE5CA3L1:16/BP2A.250605.015/U.R4T2.4027c0c-1b96b9b-1ba9cca:user/release-keys
android_sdk=36
android_release=16
is_phone=true
has_charging_optimization=false
one_ui_version=none
hyperos_version=none
oplus_rom_version=16
is_lineageos=false
lineageos_version=none
is_grapheneos=false
lineage_cc_provider=unknown
lineage_cc_mode=unknown
lineage_cc_limit_mechanism=UNKNOWN
probe_protect_battery=absent
probe_battery_charge_limit=absent
probe_regular_charge_protection=present
probe_smart_charge_protection=present
has_lineage_settings_provider=false
adapter=oneplus-lab
adapter_matched=true
adapter_control_enabled=false
contribution_wanted=true
battery_charging_status=0
battery_plugged=false

What is the manufacturer's battery-protection feature called on this device? (optional)

[d4rken]

Amply can see the two ColorOS charge-protection keys on your phone, but its controls stay off because ColorOS 16 isn't a version that's been verified yet. The check is a strict match on ro.build.version.oplusrom against 15, your build reports 16, so the device falls through to the diagnostics-only path. That's deliberate rather than a bug, and there's a test in the codebase pinning exactly this case: an unverified ROM generation doesn't get control until someone has physically shown the hardware obeys it.

Yours is the first ColorOS 16 report we have, and the useful part of it is these two lines:

probe_regular_charge_protection=present
probe_smart_charge_protection=present

That's a precondition, not an answer. It proves rows by those names exist in the system namespace and can be read. It says nothing about which values ColorOS 16 uses for each mode, whether the cap is still 80%, or the one that actually matters: whether the charging hardware reacts when something other than the Settings app writes those keys. A ROM can store a value its charging daemon quietly ignores, and then the app would be claiming protection that isn't there.

What settles it is watching an external write move the charging behaviour in both directions. The keys live in the system namespace, so an ordinary app can't write them and this needs shell access (a Shizuku-backed terminal app on the phone works just as well as a cable).

First note your current values, so you can put them back afterwards:

adb shell settings get system regular_charge_protection_switch_state
adb shell settings get system smart_charge_protection_switch_state

Then, with the phone plugged in and the battery below the cap (80% on ColorOS 15), and without touching the Settings app:

adb shell settings put system regular_charge_protection_switch_state 1

Charging should stop at the cap and stay there. A single reading at 80% can't tell a real hold from an ordinary pause, so leave it plugged for 20 to 30 minutes and capture a couple of adb shell dumpsys battery dumps across that window. If /sys/class/power_supply/battery/current_now is readable on your device it's a clearer signal still (near zero while holding), though on plenty of phones it comes back permission-denied.

Then, while it's holding:

adb shell settings put system regular_charge_protection_switch_state 0

Charging should resume and climb past the cap.

Two things worth reporting alongside that, whether or not you run the test:

• Does ColorOS 16's own battery settings screen follow each of those writes, in both directions?
• What are the options on that screen called, and is the cap fixed at 80% or can you choose a percentage? You left the feature-name question blank, and ColorOS 16 may have reorganised this since 15.

If the writes move the hardware both ways, that's the evidence needed to extend support to ColorOS 16.