Incorrect Current/Wattage Parsing and Unread Cycle Counts on Samsung Galaxy A15 5G (MediaTek Dimensity 6100+)

[fishfromph]

On the Samsung Galaxy A15 5G running One UI, Amply reads charging current as 0W (or 1mA), and charge cycles are not displayed.

Inspection via dumpsys battery reveals that the device's MediaTek power management driver outputs current now directly as a 3-digit milliamp integer (441) rather than standard microamps muA, e.g., 441000).

Because the app assumes microamps, dividing 441 by 1,000,000 results in approx 0.0004A, which rounds down to 0W.

Additionally, total cycle usage is logged under Samsung's custom MediaTek key mSavedBatteryUsage: [54327] (representing 543.27% accumulated usage / ~543 cycles) instead of the standard Android HAL cycle_count integer, causing cycle reporting to fail.

Please add MediaTek unit scaling (mA vs muA) and mSavedBatteryUsage fallback parsing for this device model.

[d4rken]

Thanks, this is a good report and the core mechanism is right: a device that returns BATTERY_PROPERTY_CURRENT_NOW in milliamps where the API documents microamps makes every current and power figure 1000x too small.

Two corrections to the details, because they change what the fix has to look like.

The arithmetic is two paths, not one. The current row divides by 1,000, so 441 rounds to "0 mA". The 1,000,000 divisor lives in the power calculation: 4287 mV × 441 / 1e6 = 1 mW, which formats as "0.0 W". That also explains your "0W (or 1mA)": a real 1.0 to 1.5 A arrives as the integer 1000-1499 and rounds to "1 mA". Same field at different charge rates, not two separate bugs.

Amply already has milli-unit correction, and it cannot fire on your device. It was added for a different ROM and deliberately requires two independent conditions: a recognised ROM, and the reading itself showing an implausible implied battery capacity (charge counter × 100 / level). Your numbers give 1760620 × 100 / 94 = 1,872,999 µAh, roughly 19x above the threshold, so that check reads your charge counter as correctly scaled. That behaviour is intentional and pinned by a test.

So on your device the counter looks correct while only the current looks milli-scaled. The ROM the correction was built for had both fields wrong. Adding a MediaTek or per-model entry to the existing list would be inert.

The obvious second signal is not usable either. "Charging but drawing almost nothing" was built and rejected, because that is exactly what a device sitting at a charge limit reports, and Amply creates those holds deliberately. On Samsung, which has a real 80% cap, that rule would risk multiplying a correct reading by 1000 on a perfectly healthy phone.

One thing worth flagging: this looks Samsung-wide rather than MediaTek-specific. It is documented across Samsung devices on different SoCs, including on Samsung's own developer forum, with exactly the split you have (charge counter correct in µAh, CURRENT_NOW in mA).

Cycle count is a different situation. There is no parser to fix: Amply reads the standard EXTRA_CYCLE_COUNT extra and shows whatever the platform delivers. mSavedBatteryUsage only exists in dumpsys battery output, which needs a permission normal apps cannot hold, so reaching it would mean a new privileged operation on the Shizuku boundary, Samsung-only and only while Shizuku is connected. Also, 54327 is accumulated throughput, not a cycle count, so it cannot simply be relabelled as one. That is a feature request rather than a bug fix, and I am not committing to it.

To move the current fix forward I need app-side evidence, which is the bar the previous ROM case was held to (that one was settled by an Amply screenshot, not by dumpsys):

1. Amply's version (Settings → About).
2. A screenshot of Amply's battery details while charging, showing "Current now" and "Charge counter". If the diagnosis holds, those read "0 mA" and about "1761 mAh".
3. What "Current now" reads while discharging with the screen on. A real ~300 mA would arrive as 300 and display "0 mA", which is physically impossible and rules out the competing explanation that you are just seeing a genuine end-of-charge trickle.
4. What the cycle count row shows: an actual number, or "Not reported". Either answer is useful.