A measured record of a case where charging was slow only on the car's wireless pad — and the culprit was heat, not a phone setting. Case: Galaxy S25+ (SM-S936N, Android 16 / One UI 8.5) + Audi A5 factory wireless pad + wireless Android Auto running at the same time.
Key point — nothing was set wrong on the phone. The phone cuts its own charge current from about 38°C.
On a desk, over a cable, in an air-conditioned room, the battery hit 38.5°C and the input limit was cut from 1500 to 1000 mA, the charge limit from 3456 to 1800 mA. When the temperature drops, it all comes back. A car cabin passes that temperature all the time — wireless AA keeps the Wi-Fi radio busy, wireless charging makes heat in the coil, and a dashboard pad gets no airflow.
Every diagnosis command below is read-only. None of them change a device setting.
"Wireless charging is slow" can be two things stacked on each other. One is how many watts the phone and pad agree on. The other is how much of that the phone cuts because of heat. The first is a pad problem; the second is a phone problem. You have to measure them separately to tell them apart.
What got pinned down here is the second one. The first is still open (see "What's still unknown").
One observation set the direction. On home and office wireless chargers, the same phone charges at normal speed. Same phone, same wireless method, slow only in the car — so the difference isn't a phone setting. It's heat or the negotiated power.
Desk / wired (Mac USB) / air-conditioned room / battery at 98%. Parsed from the !@new_battery_dump line the kernel emits every 10 seconds.
| Time | Input limit | Charge limit | Battery temp | Skin temp | What happened |
|---|---|---|---|---|---|
| 09:56:52 | 1500 | 3456 | 38.1 | 37.3 | baseline |
| 09:57:02 | 1500 | 1800 | 38.3 | 39.7 | skin passed 38°C → charge limit cut to under half |
| 09:57:12 | 1200 | 1800 | 38.5 | 39.3 | input limit cut too |
| 09:59:14 | 1000 | 2000 | 38.1 | 37.8 | input limit down 33% in total |
| 10:03:38 | 1000 | 3456 | 37.7 | 36.8 | temp fell → charge limit restored |
| 10:03:48 | 1500 | 3456 | 37.6 | 36.7 | input limit restored |
So:
Those numbers match the thresholds the phone carries.
adb shell dumpsys thermalservice
SKIN mHotThrottlingThresholds = [38.0, 40.0, 42.0, 45.0, 47.0, 60.0, 90.0]
BAT mHotThrottlingThresholds = [NaN, NaN, NaN, NaN, NaN, 55.0, 85.0]
The first skin step is 38.0°C. That is fairly low for a phone surface, and charging already starts getting trimmed there.
A 4-minute wireless charging window got caught during the investigation — from the event ring buffer in dumpsys battery.
| Time | Current | Temp | misc_event |
|---|---|---|---|
| 09:45:50 | about 1.05 A | 37.6 | 0x10000 |
| 09:45:51 | about 1.23 A | 37.7 | 0x10040 |
| 09:45:52 | about 1.24 A | 37.8 | 0x10040 |
| 09:46:02 | about 0.62 A | 38.6 | 0x10040 |
In 12 seconds the current halved, exactly in step with the temperature (37.8 → 38.6°C, 1.24 → 0.62 A). The 38°C line seen on the cable works the same way over the coil. In a car the starting temperature is already higher, so this drop comes faster and goes deeper.
One more thing. Bit 0x40 in misc_event turns on only during wireless charging. It never appeared in any wired sample. It looks like a wireless-only bit in Samsung's sec_battery driver — foreign object detection (FOD) or a coil-detect break — but that is not confirmed. The kernel headers aren't visible and /sys/class/power_supply is permission-blocked.
Read this carefully: the battery was at 99~100% here. Near full, current is low anyway, so don't look at the absolute number (1.2 A ≈ 5 W) and conclude "wireless negotiated 5W." But halving in 12 seconds is not explained by the charge level — it tracks only the temperature.
A car cabin has everything needed to pass 38°C.
| Factor | Effect |
|---|---|
| Wireless Android Auto | Streams the screen over Wi-Fi Direct 5GHz nonstop. The AP and modem never rest. Even on a desk this shows AP 49.7°C / PA 49.1°C |
| Wireless charging itself | The coil makes heat. Efficiency runs around 70~80% against roughly 95% for a cable, and the rest becomes heat |
| July cabin + a dashboard pad with no airflow | Heat has nowhere to go |
Stack all three and 38°C falls right after you pull away. After that it stays pinned at the lowest step.
If the pad also negotiates low power, it gets worse. Negotiate 5W, lose half to heat, and you're at 2~3W for real. Running wireless AA costs about that much — which is how you end up losing charge while sitting on the charger.
Everything people usually suspect for "wireless charging is slow" checked out. You have to clear these before moving to heat.
adb shell dumpsys battery
| Item | Value | Verdict |
|---|---|---|
| Fast wireless charging setting | mWirelessFastChargingSettingsEnable: true |
on |
| Fast wireless charging support | FEATURE_WIRELESS_FAST_CHARGER_CONTROL: true |
supported |
| Wireless PowerShare | ps:false |
off — the phone is not pushing power out |
| Battery wear | mSavedBatteryAsoc: 99, BSOH 100.00 |
good (17 months of use) |
| Learned capacity | 4700 mAh (design value held) | good |
| USB port moisture detection | mIsHiccupState=false |
normal |
If Wireless PowerShare is on, the phone tries to send power out while sitting on the pad and barely charges. That's the first thing to check. Here it was off.
The case is 0.8 mm PC with no metal. That thickness does not get in the way of wireless charging.
We never captured how many watts the phone and the Audi pad actually agree on. So it's still open whether heat explains all of it, or whether a 5W negotiation problem is stacked underneath.
dumpsys batteryreportsMax charging current: 0— it doesn't fill the value in. That leaves the kernel's!@new_battery_dumpas the only path, and getting it is awkward (see below).
Whether bit 0x40 in misc_event means FOD is also unresolved. If it is FOD, the shape of the cause changes.
This is the most reusable part of this document.
Samsung caps the logcat ring buffer at 5 MiB. Asking for more gets refused.
$ adb logcat -b main -G 64M
MAX log buffer size is 5 MiB. So set it to 5 MiB
This phone piles up about 1.5 MiB of log per minute, so the buffer overwrites in roughly 14 minutes. In practice, the oldest battery log still present at the start of the investigation was from the moment the USB cable went in — the drive before it was already gone.
The wireless AA disconnect investigation on this same device hit the same cap. This 5 MiB limit blocks every attempt to capture a drive, whether you're after battery or Wi-Fi.
Filter down to the BatteryDump tag and write it to a file on the phone. After the filter it's one line every 10 seconds (about 200 B), so an hour of driving is 72 KB. Nothing can overwrite.
# Before the drive (run while USB is connected)
adb shell "setsid nohup logcat -v time -s BatteryDump:E \
-f /sdcard/wcharge.log -r 2048 -n 4 >/dev/null 2>&1 &"
# Check it's alive
adb shell 'for p in $(pidof logcat); do \
grep -q BatteryDump /proc/$p/cmdline && echo $p; done'
setsid detaches it from the shell session and reparents it to init (PPID 1), so it survives unplugging the cable. A reboot kills it, so restart it if you rebooted the phone.
# After the drive — terminate it first so buffered lines land in the file
adb shell "kill -TERM $(adb shell pidof logcat)"
adb pull /sdcard/wcharge.log
# Also grab what survives regardless of the ring buffer
adb shell dumpsys battery > battery.txt
logcat -fflushes in 4 KB blocks. That means the last 2~3 minutes are not in the file yet. Sendingkill -TERMbefore you pull it drops the rest into the file.
There's one trap. logcat's -t N is applied before the tag filter.
# Almost always 0 lines — it becomes "whichever of the last 4 lines is BatteryDump"
adb logcat -d -t 4 -s BatteryDump:E
# Do this instead — filter by tag first, then cut at the end
adb logcat -d -v time -s BatteryDump:E | grep new_battery_dump | tail -4
To watch live, repeat that command every few seconds rather than streaming. Pipe it with adb logcat -s ... | while read and logcat applies 4 KB block buffering — with filtered output arriving 200 B at a time, nothing comes through for over 200 seconds.
Measure between 50~70% battery. Above 90% you're in the constant-voltage stage where current is low anyway, so you can't separate out the cause. This investigation ran straight into that limit.
!@new_battery_dump field mapEmitted every 10 seconds under the E/BatteryDump tag. Comma separated, 1-based for awk.
4339,1081,1500,3456,98,372,352,392,372,0,363,386,0,Charging,NO_CHARGING,Normal,Good,PDIC,...
$1 $2 $3 $4 $5 $6 $7 $8 $9 $10 $11 $12 $13 $14 $15 $16 $17 $18
| Index | Meaning | How it was confirmed |
|---|---|---|
$1 |
battery voltage (mV) | matches voltage:4.339 in the BSOHChargingDataCollector log |
$2 |
current now (mA) | matches current:1.084375 in the same log |
$3 |
input current limit (mA) | observed moving 1500→1000 with temperature |
$4 |
charge current limit (mA) | observed moving 3456→1800 |
$5 |
charge level (%) | matches soc:0.98 |
$6 |
battery temp (0.1°C) | temperature:37.2 = 372 |
$7 |
USB temp | matches thermalservice USB 35.2 = 352 |
$8 |
charger IC temp | — |
$11 |
skin temp (inferred) | close to thermalservice SKIN 36.2 ≈ 363 |
$14 |
status | Charging / Full |
$18 |
cable type | PDIC confirmed on wired PD. Wireless value unknown |
$24 |
current_event bits |
wired 0x20008000, wireless 0x40000000 family |
$25 |
misc_event bits |
0x40 turns on only when wireless |
$9 and $11 are inferred from moving in step with thermalservice values — not confirmed.
| What you see in the wireless window | Conclusion |
|---|---|
| Input limit low from the start, flat regardless of temperature | pad negotiated-power limit |
| Input limit starts high, then steps down as temperature rises | heat is cutting it |
| Both | combined |
0x40 in misc_event stays on more than on a good charger |
suspect FOD |
cable_type differs from a good charger |
negotiation protocol difference |
Take one measurement on a home or office charger at the same charge level and the comparison lands immediately.
Highest impact first.
There's no reason to change the case. 0.8 mm with no metal doesn't get in the way.
Battery protection mode (adaptive, 80% ceiling) mostly acts during sleep-charging hours, so it's unlikely to be the main driver of slow charging on a drive. Low priority.
| Item | How it was judged | Result here |
|---|---|---|
| Fast wireless charging off | mWirelessFastChargingSettingsEnable |
no — it's on |
| Wireless PowerShare on | ps: field |
no — it's off |
| Battery wear | ASOC / BSOH | no — 99% / 100% |
| Case interference | material and thickness | no — 0.8 mm, no metal |
| Heat cutting the current | input/charge limit moves in !@new_battery_dump |
measured — at 38°C, input −33%, charge −48% |
| Pad negotiated-power limit | input limit in the wireless window | unresolved — buffer overwrote it |
| FOD (foreign object detection) | misc_event bit 0x40 |
unresolved — on only when wireless, meaning unclear |
Logs pulled off the device can carry account and device identifiers. Check before sharing.