Why is Sleep eating so much battery? What about battery overheating? - Sleep as Android

Usually battery consumption issue or related issues causing phone over-heating during sleep tracking are not caused by the sleep tracking directly.

This is a companion discussion topic for the original entry at https://docs.sleep.urbandroid.org//faqs/battery_overheat.html

Recently I have replaced my old Moto G5S Plus to a new Samsung A71. And I’m quite surprised by how my battery is drained during sleep. Check the graph in the image below:

We can see a consumption > 40% from midnight to 8am. Sleep as Android accounts for ~20%. And the other ~20% are a mystery. Probably some Samsung bloatware.

I’m a developer and I’m aware that the correct solution is not changing Sleep as Android but for Samsung to fix its software (or just stop messing with stock Android…). But by a practical perspective, Samsung doesn’t care and probably won’t fix. It is better for them that users buy their smart band instead…

If I hadn’t had an incredible experience with the app in the old phone I would just remove it and use some other sleep tracking solution (probably some smart band).

I have tried several workarounds each night:

  • Uninstalling/disabling all possible Samsung apps that shipped with the phone
  • Stopping unnecessary services
  • Replacing Samsung built-in blue light filter by Twilight
  • Enabling airplane mode
  • Enabling Samsung battery saving mode (but excluding Sleep as Android from app to be put to sleep)

None of them worked and now I’m out of options. Given Samsung accounts for almost 40% of Android market, I hope there is something to be done as a workaround in the app side.

Hello Manzo, the app uses a wake lock (unless you use the safe battery option which utilizes sensor batching - and this only works with accelerometer - not sonar for instance or wearables)… By design in Android if an app holds a wake lock any processing which takes place during that time is accounted as battery used by this app… so this would not be such a surprising figure IMHO

But if you would use menu - report a bug I would like to investigate the log and we can see if something bad is not happening… for instance just recently we were releasing a fix to BETA for a service which is making backup of starred sounds into the mediastore and in some cases where there have been errors during copying this servcie was run over and over whcih may have cause some additional battery use

Hello, I just found another thing which may be related. It seems in a June update we the fallback recording codec Vorbis because accidentally the default fro sleep noise recording for most devices… I have just reverted that back to MediaCodec whcih is the system’s default codec and thus I believe should be more battery optimized… I’m just releasing this fix into BETA, pelase let me know if you want to give it a try?

Thank you for your swift response Petr. Just sent the bug report. And I’m up for testing the beta.

Clarifying one thing: I consider the 20% used by Sleep as Android quite normal as well, but I’m concerned about the other 20% that are probably getting used by other apps that are not even listed in the usage report.

By your previous response, I understand that other thing that a could try is to use sensor batching with the safe battery option instead of sonar.

Please let me know if you need more information on this.

Understand, but also not sure what the other 20% mean in this case? But I do not know how long was the tracking out of the total time ion the battery stats so i can assume the 20% was consumed in the mean time, although understand that this isn’t probable? Big thanks I will investigate the report, in the mean time…

Please first join our BETA Testers group at:
That you can opt-into the BETA at the following address:
or simply by visiting our Play Store listing and tapping “Join BETA”

Big thanks for the report… just one from the quick glance over the report… I see you use the Sonar, and this make use of the media player all night long - basically playing music at the nearly highest level… So I’m thinking this may be the missing 20%… 40% battery use for sonar is not an exception… so I simple test we could do… for a reference use accelerometer instead of Sonar for one night… second… try to lower Sonar signal strength in settings > Sleep tracking > Sonar > Sensor Test … let say 60-70% - woudl it still pass the supported test? If so please try one night with lower signal…

Thank you once again Petr!

I will try the reduced sonar strength tonight. Reduced to ~50% and got ~3k signal strength in the test. Tomorrow I’ll try with the accelerometer. Once I get each battery report I’ll post here.

I have also installed the beta version.

I had about 40% battery usage in my previous device, but for a 3000mAh battery with more than 3 years of usage. Now I am with brand new 4500mAh battery, but the same 40% usage (with the unknown 20% not listed in the usage report). That’s why I came here to ask for help. I think this is something related to Samsung software, because with my old Moto device battery performance was much better.

Reducing the sonar intensity indeed saved battery. Sleep as Android usage dropped from ~20% to ~8%. But the missing 20% that are not listed in the usage report are still there.

Tonight I’ll test what changes with accelerometer.

Many thanks for the update… now the question is how steep is the normal battery curve without tracking… 20% per 8 hours does not seem like a lot… I think most smartphones today need to be charged once a day… so 20% per 8 hours may be a pretty normal base-line?

This is the result for tracking with accelerometer only.

I started tracking with the battery at 44% and wake up with 32% (as in the the image). So from this I can say that the battery drain from unknown sources dropped from ~20% to ~7%. Do you think these ~13% difference comes from mic and speaker usage?

Tonight I won’t track my sleep in order to set a baseline battery usage in standby mode (which I expect to be close to 5%)

Thank you for all your insights on this. Really helpful!

Hello Manzo, yes I would say it accounts for the speaker and the mic… I think you can do a simple test, just try to play Spotify for few hours on high volume and I expect you would get to a very similar battery consumption like when you would be tracking, there is some streaming and radios on top so even better would to play sound from local sources but this could be a good reference IMHO…

In our experience those are pretty normal figures and unfortunately Sonar is much more battery hungry than accelerometer… So hopefully we will soon get some radars in phones which would be more battery efficient. I was hoping for the Pixel 4 Soli radar, but unfortunately google keeps the technology closed…