FP3 : No Deep Sleep -> Battery drain

Hi all,

I can’t rid of a huge battery drain with my FP3 on /e/ OS (0.18-20210827) since I’ve changed from the original FP Os.

From what I’ve detected with AccuBattery app, my FP3 never goes in Deep Sleep.

I’ve spent time exploring this forum to find a solution but the behaviour of my FP3 is still totally hazardous. (In some case, very rare case, it happens that after a charging period the phone enters in Deep Sleep for a cycle)

I’ve tried all those operations:

  • Set off Localisation, Bluetooth, Auto-rotate, NFC, Sync…
  • Airplane Mode => No Change (2,5% battery drain per hour)
  • Remove Shelter app and applications in it => No change
  • Remove all apps => No change
  • Tried with another FP3 battery => No change
  • Empty data and cache from Signal and the same for MicroG Services => Works only for two battery charges (My Phone got a normal battery drain and I could see in accuBattery that my phone get in Deep sleep Several hours during this period :frowning: )
  • Remove the two sim cards and put the phone in airplane Mode => No change
  • And at least, I’ve tried a Factory Reset. With no apps install other than AccuBattery, I still have the same issue.

Are there others out there with same issue? any ideas?

Thanks in advance for your help, this makes me crazy :wink:
(And big thanks by the way to the /e/ OS Teams for this wonderful project)

Regain your privacy! Adopt /e/ the unGoogled mobile OS and online servicesphone

1 Like

when a phone leaves a “default state” it will get harder to compare power profiles, when just one app can make the difference - or a weird home network or mobile connection can skew measurements. This being said, I’m surprised enabling

Airplane Mode => No Change (2,5% battery drain per hour)

doesn’t change the discharge rate for you - unlike my own experience when debugging a “the discharge rate is too damn high” FP3. battery-historian can give you lots of insight just by the power of visualization.

Example: this screenshot of battery-historian shows a period when wifi is disabled and discharge rate drops to ~0,4/hrs levels. With an active wifi connection it is at ~1,8/hr rate what is still too high, but less than 2,5%/hr (after resolving two other issues). This is pretty much a default install /e/ (0.18 on Android R already, most current firmware) - no further apps.

if you can, give it a go. If you can’t, BBS is a good AccuBattery alternative, as it doesn’t shy away from terminology.

1 Like

from old bugreport zip files when still on A9 stockrom+modem I had 0,5-1,0%/hr with wifi enabled.

The higher drain was acknowledged before I noticed myself:


when starting to look into it, I saw “coexisting conditions”, but solving them didn’t solve “everything”

  • bliss weatherwidget holding partial wakelocks, solving this results in 0,5-0,7% lower rates as the phone more often is in a full doze


When I compared between different /e/ versions (and modem firmwares) on Pie, Q and R, I had inconclusive results. I will revert to stockrom A9 again to have a current date baseline to compare to.

A Moto harpia in the same home environment can go with 0,6%/hr on enabled wifi

In Airplane mode I can achieve 3% in a whole night.

What I saw on a previous phone was: some apps which are always running but normally behave inconspicuous (data monitors, loggers, email) get suddenly remarkable when the networks are turned off. This seems to be an unexpected situation for many apps. I had once a data traffic monitor which drained the battery completely in just a few hours because there was no network connection anymore.

1 Like

Thanks for your answer/helps. I feel less lonely :slight_smile:

I’ve first tried following your advice to get some insight using BBS. And it confirms that something is wrong.

I’ve monitored for one night in Airplane mode:

And in the Summary menu I get this results :

  • 0% Deep sleep
  • 98% : Awake (Screen Off)
  • 2% Screen On

Can someone explain to me what “Android- Wakeups” alarm means?

I will try battery-historian in the meantime to continue searching the cause.

in BBS, look for the menu points (in the Dropdown where “Alarm” is shown) for “kernel wakesources”, “app wakeup alarms”, “kernel wakeup reasons”, “userspace wakelocks” etc… the second row is to determine the time frame. It resets itself sometimes… not the easiest interface but can be more detailed than Accubattery

battery-historian is helpful because it’s a desktop interface, can draw some graphs.

As I didn’t continue debugging this in August your post made me pick it up again, I think I can narrow it down, at least for the FP3 in my network. I’m looking at kernel wakeups specifically and will update the linked gitlab issue.

1 Like