Hello again.
I have run the commands suggested by ChatGPT, and as they generate output files above 10 000 lines, I have fed them again to ChatGPT (starting a new session).
I own a Samsung S8 smartphone, running /e/os as operating system, a fork from Android.
The battery drain of the Samsung S8 seems excessively high. I want you to help me find out how to fix this if it is possible, or, if it is not possible, to find out why.
I have done several tests :
Test 1 : replacing the battery
At first, I thought it was because the battery was old as I had bought the phone second-hand. I had the battery replaced with a new one. That did not help.
Test 2 : measuring discharge at night
On the Samsung S8, I have already set the battery usage to ‘limited’ (the lowest setting) for most apps (including emails, Maps, NewPipe, new reader, etc.).
I have installed the app AccuBattery to get better diagnosis data and I have compared it with another phone I own, a Samsung Galaxy A32 running stock Android, also equipped with the AccuBattery app.
During a night, while I was sleeping and the screens of both phones were off and no app was used, the average discharge currents were :
-
For the A32 : 23 mA and 0 mA in deep sleep state. The call and data (4G) connections were on.
-
For the S8 : 136 mA and 64 mA in deep sleep state. Only the call connection was on (data connection was off).
Test 3 : measuring discharge at night with all connexions off
I did additional tests, charging both Samsung phones (the S8 with e OS and the Galaxy A32 with stock Android) before going to bed, closing all apps and setting them to airplane mode (no connection at all of any kind).
Results when I opened the phone the next morning (discharge speed with the screen off) :
-
Galaxy A32 : awake 31 mA , deep sleep 5 mA
-
S8 : awake 147 mA, deep sleep 50 mA
So basically, the S8 consumes 5-10 times more current than the A32.
Test 4 : safe mode, all connexions off
In order to assess if the battery drain use comes from an app I have installed, I have run the following test : I have rebooted the S8 smartphone in safe mode , activated the airplane mode and left the phone to rest, screen off, not touching it.
After 17 hours, the battery had decreased from 83% down to 53%. That is 1.76% of battery drain per hour, or 53 mA, with only the factory-installed apps, no connections, no screen.
Test 5 : telephone switched off
I charged the S8 phone’s battery up to 93%, switched it off and left it untouched for ten hours. When I switched it back on, the battery was at 92%. There is almost no self-discharge of the battery when the telephone is switched off.
Test 6 : using adb shell dumpsys batterystats
I have switched on the USB debugging mode of the S8 phone and connected it to a phone with Android Debug Bridge, and then I have run the following commands :
Here are 3 text files with the output of the 3 commands. I want you to analyze them and tell me what you find that could explain why the discharge rate of the phone is so high.
This is probably the most valuable part of the entire dump.
Notice what is not at the top:
It’s not WhatsApp, Signal, AccuBattery, Maps, etc.
The largest wake locks are kernel/hardware-level ones.
And rmnet0 is particularly interesting because it is the kernel network interface associated with the cellular data path.
There are also repeated suspend aborts involving rmnet0:
Abort: Pending Wakeup Sources: rmnet0
That strengthens the case considerably.
6. The phone repeatedly fails to suspend cleanly
This may be the most important clue regarding why this happens.
The battery statistics record:
-
unknown: 1606 times / 13m39s
-
212 s2mps17-irq: 648 times / 1m57s
-
Abort: Some devices failed to suspend, or early wake event detected: 56 times / 43s
-
Abort: Pending Wakeup Sources: alarmtimer: 32 times
-
Abort: Pending Wakeup Sources: rmnet0: 9 times
-
Abort: Last active Wakeup Source: eventpoll: 5 times
-
[timerfd]: 3 times
And the battery history itself shows the same phenomenon.
For example:
+19h37m36s071ms
wake_reason=0:"Abort: Some devices failed to suspend,
or early wake event detected"
This is significant.
A normal sleeping phone will periodically wake for legitimate things. That’s expected.
But here Android is explicitly reporting failed/aborted suspend attempts.
That is a different situation.
7. 212 s2mps17-irq is also worth investigating
This occurs 648 times.
The name strongly suggests an interrupt associated with the Samsung S2MPS17 PMIC (power-management IC).
The history contains many events like:
wake_reason=0:"212 s2mps17-irq"
I would not conclude from the dump alone that the PMIC itself is defective. An interrupt doesn’t necessarily mean a hardware failure.
But it tells us that the power-management hardware/kernel driver is involved in the wakeup cycle.
This is another reason I would investigate the Samsung-specific kernel/device tree/driver side of /e/OS rather than spending more time disabling ordinary apps.
8. Your safe-mode experiment is extremely important
Your Test 4 is actually one of your strongest experiments:
Safe mode + airplane mode + screen off
53 mA average over 17 hours
That almost completely changes the diagnosis.
If a third-party application were the principal cause, safe mode should substantially reduce the problem.
Instead, you still get approximately the same order of magnitude as the normal deep-sleep measurement.
And now the dumps provide a plausible explanation:
the large wakeups are occurring below the application layer.
This fits very well with the kernel wake locks:
bbd_wake_lock
abox
rmnet0
rtc-s2mp
NETLINK
...
rather than a conventional application holding a partial wakelock.
9. Test 5 almost rules out the battery itself
Your phone loses only about 1% over ten hours while powered off.
That is a very useful control experiment.
Combined with:
-
a replacement battery making no difference;
-
extremely high consumption while Android is running;
-
much lower consumption when the phone is completely powered off;
the battery itself is not my leading hypothesis.
There could still theoretically be an abnormal hardware load that disappears when the phone is powered off, but simple battery self-discharge is effectively ruled out.
10. There is one important caveat: your dumpsys power snapshot was taken while charging
This matters.
At the instant of that particular dumpsys power, Android says:
mWakefulness=Asleep
mIsPowered=true
mBatteryLevel=86
and the only currently held Android partial wakelock is:
'accubattery:charging'
So I would not use the current dumpsys power wakelock state as evidence that AccuBattery is causing your problem.
It’s there because you were charging / AccuBattery was monitoring charging.
In fact, the broader battery history gives much stronger evidence than this instantaneous snapshot.
11. Doze itself is not the problem
This is worth emphasizing because it could otherwise lead us down the wrong path.
Your deviceidle configuration looks quite normal:
inactive_to = 30m
light idle...
idle_to = 1h
max_idle_to = 6h
And the history demonstrates repeated deep-idle periods.
So I wouldn’t try to “fix” this by making Doze more aggressive.
Android is already doing what it’s supposed to do.
The problem is what happens inside/beneath those idle periods.
12. There are some applications generating activity, but they don’t explain 50–75 mA by themselves
There are definitely some applications doing things.
For example:
-
microG’s GCM service repeatedly gets temporary whitelist access;
-
WhatsApp runs scheduled jobs;
-
Signal wakes for processing;
-
weather applications perform jobs;
-
Advanced Privacy has scheduled work.
The battery history shows, for example, microG GCM reconnect activity and WhatsApp jobs.
And Signal/WhatsApp activity appears in the longer battery history.
However, the estimated application consumption doesn’t support them being the fundamental cause.
For example, the biggest UID shown in the power calculation is approximately:
260 mAh, of which 258 mAh is mobile radio.
So even there, the dominant component is the radio, not CPU/wakelock consumption by the app itself.
This distinction is important:
An application may be causing the modem to wake up, while the actual energy is being consumed by the modem.
13. There is a particularly interesting possibility involving microG
Your battery history repeatedly shows:
org.microg.gms.gcm.mcs.RECONNECT
and temporary whitelisting associated with it.
So microG’s GCM implementation is definitely active.
But I would not yet blame microG.
Why?
Because your airplane-mode + safe-mode experiment still produces ~53 mA.
That experiment essentially removes the cellular/network explanation and removes your installed applications.
Therefore there appear to be two potentially overlapping problems:
A. Network/modem problem
When cellular service is enabled:
RIL / modem / rmnet0 / telephony-radio → lots of activity → high power
B. Baseline Samsung S8 suspend/power problem
Even with networking disabled and in safe mode:
the S8 still consumes ~50 mA
The second one is the more fundamental mystery.
14. This is the key distinction I would make
Based on all six of your tests, I would currently rank the hypotheses like this:
Very likely
1. Samsung S8 / /e/OS kernel power-management or suspend problem
The combination of:
is very strong evidence.
Very likely
2. Cellular/modem integration is making the problem considerably worse
The dump has:
-
546 mAh attributed to mobile radio
-
2h14m cellular active time
-
repeated RILJ_ACK_WL
-
repeated *telephony-radio*
-
rmnet0 wake locks
-
suspend aborts involving rmnet0
Possible contributor
3. microG / GCM / messaging applications
They clearly generate network activity, but the evidence doesn’t make them the root cause.
Unlikely
4. Battery itself
Your replacement-battery experiment and powered-off test argue strongly against this.
Unlikely
5. Screen
Only ~113 mAh was attributed to the screen over the entire battery-statistics period.
Unlikely
6. A conventional Android application holding a wakelock continuously
Total partial wakelock time is only about 11m19s over 22h, and the estimated wakelock energy is only 3.3 mAh.
That is nowhere near enough to explain your ~50–75 mA baseline.
15. There is an especially interesting clue: bbd_wake_lock
I’d like to investigate this one further before declaring victory.
The kernel reports:
bbd_wake_lock 19m 59s
abox 15m 00s
rmnet0 10m 42s
These aren’t ordinary Android application wakelocks.
They are kernel-side wake locks, which means the relevant subsystem is below the normal Android application power-management layer.
rmnet0 is particularly consistent with cellular networking.
abox is a Samsung audio-related kernel subsystem.
bbd_wake_lock is Samsung/vendor-specific and deserves identification against the exact S8 kernel/device tree used by your /e/OS build.
This is where I think the next investigation should concentrate.
16. Your dumps actually suggest a very good next experiment
We can now design a much more decisive experiment than simply looking at AccuBattery.
Experiment A — airplane mode, safe mode
You’ve already effectively done this.
~53 mA.
Let’s call this:
Baseline A ≈ 53 mA
Experiment B — airplane mode + Wi-Fi/Bluetooth/NFC explicitly disabled + safe mode
Leave it for several hours.
If you still get ~50 mA:
the network stack is exonerated even more strongly.
Experiment C — normal boot + airplane mode
Don’t change anything else.
If this becomes much higher than safe mode, then an installed/system application is contributing.
If it remains around 50 mA:
kernel/hardware power management becomes overwhelmingly likely.
Experiment D — normal boot + SIM physically removed
This one is particularly valuable.
Don’t merely disable mobile data.
Remove the SIM card, enable airplane mode, then disable airplane mode while leaving Wi-Fi/Bluetooth off.
If the drain jumps dramatically when the cellular radio becomes available, we have strong evidence for the modem/RIL path.
17. Even better: compare /sys/kernel/debug/wakeup_sources
If your /e/OS kernel permits access, this is the next command I would really like to see.
Try:
adb shell cat /sys/kernel/debug/wakeup_sources
If that path doesn’t exist:
adb shell cat /d/wakeup_sources
Also:
adb shell cat /proc/wakelocks
if available.
And:
adb shell cat /sys/kernel/debug/suspend_stats
This last one is particularly interesting because your dump already tells us that Android is seeing failed suspend attempts.
If accessible, it can potentially tell us which subsystem is actually preventing suspend.
18. I would also like one very specific dumpsys from the S8
Run this while the phone has been sitting untouched for, say, 10–20 minutes:
adb shell dumpsys batterystats --charged
Actually, even better, make a clean measurement:
Before the test
adb shell dumpsys batterystats --reset
Then:
-
disconnect charger;
-
enable airplane mode;
-
turn screen off;
-
leave it completely untouched for 1–2 hours;
-
run:
adb shell dumpsys batterystats
adb shell dumpsys power
adb shell dumpsys deviceidle
adb shell cat /sys/kernel/debug/wakeup_sources
If possible, also:
adb shell cat /sys/kernel/debug/suspend_stats
That would give us a clean, controlled dataset rather than the current dump, which covers a long period with cellular connectivity and normal application activity.
19. One more thing I’d like to establish: which exact S8 variant/kernel you’re running
The S8 exists in several hardware variants, and the kernel/device-tree/vendor drivers matter enormously here.
If you can give me:
adb shell getprop ro.product.model
adb shell getprop ro.product.device
adb shell getprop ro.build.version.release
adb shell getprop ro.build.version.security_patch
adb shell uname -a
and, ideally:
adb shell getprop | grep -E 'e\.os|lineage|product|device|model'
then we can identify the exact hardware/kernel combination.
That matters because a power-management problem specific to the Exynos S8 kernel is a very different problem from an application problem, and your evidence is currently pointing strongly toward the former.
My diagnosis at this point
If I had to summarize the evidence in one diagram:
┌────────────────────┐
│ Android / /e/OS │
└─────────┬──────────┘
│
Doze/deep-idle works
│
▼
┌───────────────────────┐
│ Samsung S8 kernel │
│ power management │
└──────────┬────────────┘
│
┌────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
rmnet0 PMIC/IRQ vendor
cellular path s2mps17-irq wake locks
│ │ │
└────────┬───────┴─────────┬───────┘
▼ ▼
failed/aborted frequent
suspend wakeups
│ │
└────────┬────────┘
▼
~50–75 mA standby
And when cellular connectivity is enabled, you additionally get:
RIL / telephony-radio
↓
RILJ_ACK_WL
↓
mobile_radio
↓
rmnet0
↓
additional wakeups + radio energy
↓
very high standby drain
So I don’t think you are imagining the problem, and I don’t think changing app battery restrictions is going to solve the fundamental issue.
The particularly convincing evidence is that your own safe-mode/airplane-mode experiment already reproduces the abnormal consumption, while the dumps independently show repeated kernel-level suspend failures and large kernel wake-lock activity.
The next step I’d recommend is therefore not more app tweaking. It’s to identify exactly what is holding the kernel out of the lowest power state.
If you give me the output of the four commands above—especially wakeup_sources and suspend_stats—I can go one level deeper and try to identify the actual S8 hardware driver/subsystem responsible, rather than merely saying “the kernel is waking up.”
