[UNOFFICIAL BUILD] Samsung Galaxy S6 (zerofltexx)

I’m a fan of battery-historian - a companion webapp that you throw bugreport.zip files at and it will visualize it - FP3 : No Deep Sleep -> Battery drain - #2 by tcecyk

For one, it can be some interval (sync, mail, app updates…) that wakes up the device too often and this will be visible, then there’s malfunction as in apps keeping wakelocks without reason, keeping the device from an efficient cpu doze.

1 Like

Thank you very much dear tcecyk for the Battery History program! I did not know that until now. This is really great! Thank you!

Now to my problem:
Since I got a recent version of e/OS, even if I don’t do anything and don’t have any additional apps installed, and the device is completely offline and set to the highest power saving mode, the battery goes from 100% to 0% within 20 hours.

EDIT:
And now, thanks to your recommended procedure, I was able to find out what was using so much battery power. I’m not quite done with my analysis yet, but the culprit seems to be a service called “GnssLocationProvider”. And I happen to have now also found a temporary solution to the problem. At least it seems to be for the moment. Namely, if I disable the default enabled “Location service” during setup while reinstalling e/OS on the smartphone, the problem is fixed. And coincidentally, I have also solved another problem that was there until now: I had the problem that my sim card had somehow not worked properly. I could be called and also call myself, but the mobile data did not work, and in the upper right corner of the display there was always a small x at the connection indicator. Now, since I have deactivated the default activated “Location service” during the reinstallation, the mobile data suddenly works as it should. Something seems to be wrong with the “Location service” in the current 1.7 build. At least if I have enabled the “Location Service” by default from the beginning.

1 Like

Excellent detective work, @eisy.

In my experience, the S6 has always been “hard” on a battery: I use AccuBattery (available via Aurora Store) for insight on battery usage, but this really only works with apps, not system/OS services. For example, AccuBattery shows high usage of “Settings” and “Settings Suggestions” but does not indicate which!

Further, we’re running into a real-world issue relating to battery life as well: the S6 batteries (if they are stock) are around 7-9 years old and their health/capacity is never going to be what it was when new. For example, AccuBattery reports that the design capacity of the S6 battery is 2550 mAh, whereas the estimated capacity of mine is only 1500 mAh, meaning no matter what I’m only going to get around 60% possible battery capacity.

Last, I can’t speak for the current Bliss “Home” App, but back in the 0.18 days it used far more battery than either OpenLauncher or Discreet Launcher (both of which are available via F-Droid) so you might consider trying those to see if they are more energy efficient for you.

I look forward to next updates! :beers:

1 Like

Thanks for this post @tcecyk. It inspired me to play with java max heap values in my build scripts. After a little experimentation, I found a value -Xmx1G allowed my builds of LOS 19.1 / Android 13 to succeed on my build machine with only 16GB RAM and a Dual-Core Intel Core i5 CPU

I set the value by this from my build script:
ANDROID_JACK_VM_ARGS=-Dfile.encoding=UTF-8 -XX:+TieredCompilation -Xmx1G

Until now now I’ve been using powerful cloud virtual servers - 32v CPUs, 64GB ROM - to make my LOS 19 and 20 builds. Of course local builds are slower, but at least they are now possible. And I don’t have to worry about forgetting to destrpy the cloud VM, and running up large bills :slight_smile:

Thanks again!

1 Like

Glad it warranted a investigation into heap sizing, but I’m not sure what exactly helped you!

JACK got deprecated after Android 10 - there are hardcoded values though at other places (like that droiddoc.go or at config.go) that pose an issue to lower spec machines.

A filled ccache can also make a difference on “second runs”, the core/mem ratio plays into memory pressure and how java behaves… lots of knobs.

Awesome stuff to see thread alive, even though I do not have s6 any more and cant really help :frowning: