Symptoms (found on-device: Huawei Mate 10 Pro, BLA-L29, Android 10 / API 29, EMUI 12)
- Battery details show an absurd Capacity of "2 mAh" / "3 mAh" / "9 mAh" (fluctuating) instead of the ~4000 mAh real capacity.
- After entering a 4000 mAh design capacity, Battery Health shows "1% — Poor".
Root cause
SystemService.getBatteryCapacity() estimates full capacity as
CHARGE_COUNTER (µAh) ÷ (CAPACITY% × 10). Android's contract says
BATTERY_PROPERTY_CHARGE_COUNTER is µAh (≈4,000,000 for a full 4000 mAh battery), but this
Kirin/HiSilicon device reports it in the low thousands:
$ adb shell dumpsys battery
Charge counter: 9000 # should be ~4,000,000 µAh at 100%
level: 100 scale: 100
So estimateFullCapacityMah(9000, 100) = round(9000 / 1000) = 9 mAh. That 9 mAh is shown as the
capacity, and it also poisons the measured-health figure:
computeMeasuredHealth(9, 4000, 100) = round(9 × 100 / 4000) = 0 → clamped to 1% → "1% Poor".
Locations: SystemService.estimateFullCapacityMah, consumed by the details row and BatteryHealthTracker.getMeasuredHealthPercentage.
Proposed fix
Add a plausibility guard to estimateFullCapacityMah: if the estimate falls outside a sane
phone-battery range (~500–15000 mAh, matching the accepted design-capacity range), return 0
("unknown"). Effects:
- Details Capacity row shows "Unknown" instead of "9 mAh" (already handled for
<= 0).
- The design-capacity dialog no longer prefills garbage.
getMeasuredHealthPercentage returns -1 → UI falls back to the honest Estimated (cycle-based)
health instead of "1% Poor".
Note: on this device a measured health figure is simply not possible (the charge counter is
unusable), so falling back to the labeled Estimated value is the correct, honest behaviour.
Acceptance criteria
Found during on-device testing of #68.
Symptoms (found on-device: Huawei Mate 10 Pro, BLA-L29, Android 10 / API 29, EMUI 12)
Root cause
SystemService.getBatteryCapacity()estimates full capacity asCHARGE_COUNTER (µAh) ÷ (CAPACITY% × 10). Android's contract saysBATTERY_PROPERTY_CHARGE_COUNTERis µAh (≈4,000,000 for a full 4000 mAh battery), but thisKirin/HiSilicon device reports it in the low thousands:
So
estimateFullCapacityMah(9000, 100) = round(9000 / 1000) = 9 mAh. That 9 mAh is shown as thecapacity, and it also poisons the measured-health figure:
computeMeasuredHealth(9, 4000, 100) = round(9 × 100 / 4000) = 0 → clamped to 1%→ "1% Poor".Locations:
SystemService.estimateFullCapacityMah, consumed by the details row andBatteryHealthTracker.getMeasuredHealthPercentage.Proposed fix
Add a plausibility guard to
estimateFullCapacityMah: if the estimate falls outside a sanephone-battery range (~500–15000 mAh, matching the accepted design-capacity range), return
0("unknown"). Effects:
<= 0).getMeasuredHealthPercentagereturns -1 → UI falls back to the honest Estimated (cycle-based)health instead of "1% Poor".
Note: on this device a measured health figure is simply not possible (the charge counter is
unusable), so falling back to the labeled Estimated value is the correct, honest behaviour.
Acceptance criteria
CHARGE_COUNTER = 9000) yield0, surfaced as "Unknown".SystemServiceTestcovers the guard.Found during on-device testing of #68.