Yes, my experiences with this are similar. But since I haven’t yet tested that online/offline switching (which is what the XA2U uses), I’ll give it a try and see if it makes any difference (power-wise, because impact on performance is clearly noticeable).
Indeed. If this online/offline thing doesn’t make any difference (and I suspect that it doesn’t) then there’s something else than any CPU-related things eating that much energy, and we won’t be able to do anything about it.
Hi wetab73, I tried to use your command to set my cores cpu2, cp3, …, cpu7 in their sleep mode.
In that night: 1% battery lasted for 1h 6 min
Reboot phone, without this commands:
This night: 1% battery lasted for 48 min
I’d like to try the following idea:
When this display is off, the 6 cores (perhaps 7) should be set in sleep mode with the commands mentioned above, for example by “Situations”. When display is activated, the cores should be enabled again.
Could someone help me, how to get this “devel-su” commands done in Situations?
For my personal purpose, the phone has not much to do with deactivated display:
I experimented some with the offline cores, and my findings are similar: there’s only a small difference in power consumption. It looks like the mysterious power consumer is not the core count either…
Have you some experience using Situations with devel-su commands?
No, sorry, but afaik devel-su always requires the password. You could install sudo instead and put the exact commands to /etc/sudoers, but that’s something to deal with care. I don’t know how e.g. Sailfish OS updates react to sudo, for example. Has someone tried?
Edit: Well, sudo is available from Jolla repos directly, so it should be “safe” to try at least…
ok, I open the file like this:
[root@Xperia10III defaultuser]# visudo /etc/sudoers
and try to add the line:
echo 0 > /sys/devices/system/cpu/cpu2/online
Try to write, I get the error:
[root@Xperia10III Downloads]# visudo /etc/sudoers
/etc/sudoers:1:8: syntax error
echo 0 > /sys/devices/system/cpu/cpu2/online
^
How could I fit this?
I would put the commands you ececute in a bash script and put this script in the sudoers file, like this:
ALL ALL = (root) NOPASSWD: /home/nemo/name-of-script
Yesterday I had a very long phone conversation. It lasted 3 hours and consumed 26% of battery. So the actual talk time is less than 12 hours, which is just pathetic. 10 III tests / reviews with stock Android rate it at 31 hours of talk time, i.e. whopping 3 times more. What does it do under SFOS / AOSP that during calls it eats 3x more energy is beyond me. And where does that excess energy go? Heat? Increased SAR into our heads? It has to go somewhere.
Not looking good at all. At least you didn’t get disconnection at randoms of mobile signal like me on i4133 on 4.5
Hi, yesterday I restarted fingerprint-sensor (over Sailfish utility). The next morning the cpu-usage was better than the day before.
Exists a similar command to deactivate the fingerprint-senor?
I’d try the influence of it over night concerning battery drainage.
You could stop the sailfish-fpd service or try this method:
My Sony Xperia 10 III sometimes consumes around 10-15% during night - doing nothing (?). I charge it basically every day (stock SFOS, no Android support, no apps constantly running, no BT, rarely WLAN, etc.). Actually, my Jolla 1 has better battery consumption and lasts longer 
Thanks. I tried
[root@Xperia10III defaultuser]# systemctl stop sailfish-fpd
It had no influence on battery drainage.
Maybe it could be related to this (one of my earlier posts from this thread):
A bit later @direc85 suggested:
“What I think happens is that the schedutil governor is aware (or its calculations are affected by) the connected charger, and it simply cranks the clocks to max. I think that’s a bug, because the clocks stay maxed out even when the display is off.”
Do you have SysMon or SystemDataScope to see what’s going on?
It hasn’t - as long as it works normally. But from time to time it gets kind of ‘stuck’ and in such state it consumes CPU time.
Normally, it uses around 1 second of CPU time when it gets touched and attempts to recognize the fingerprint, and after that it doesn’t use any CPU time until it is touched again. One can check it in e.g. Crest: open details of the /vendor/bin/hw/android.hardware.biometrics.fingerprint@2.1-service.sony process, check the CPU time consumed so far, then turn off the display and wake it up by touching the fingerprint sensor. Then re-open the page with details of that process - the CPU time will increase by 1 second.
In such case, even after several days the CPU time consumed by that process is just seconds - simply 1 second per each fingerprint recognition.
But quite often it gets ‘stuck’ - it doesn’t deactivate itself and continues using CPU time. In such state it not only eats power but it also stops reacting to touches.
See the screenshot below (from Crest) - it is after the sensor got stuck and ate over 40 minutes of CPU time. Normally, for that process to use 40 minutes of CPU time it would take 1 second * 60 * 40 = 2400 fingerprint scans, i.e. weeks of uptime. But when it gets stuck, it eats this much CPU time within minutes.
Resetting the sailfish-fpd service doesn’t seem to have any impact on this /vendor/bin/hw/android.hardware.biometrics.fingerprint@2.1-service.sony process.
I’ve AIDA64, but I’m uncertain what I can see from that. Yesterday I disabled the new battery function that stops charging at 90%, and suddenly the the phone charged from 76% to 96% in just a half an hour while connected to my laptop (I was sharing the internet over USB), and this morning it was down on 85%, having used “only” 11% during night. I need a couple of more days to say for sure, but maybe the new save-battery-function is not 100% yet?
BatteryBuddy shows my X10iii SFOS using 300-400mA running 3.5G mode from home.
My Android X10iii is showing currents in 300-800mA range, using BatteryNotifier.
So, if anything SFOS seems to be better. However the Android might be using 4G, and cell signal is hugely variable where I live, and the battery apps show wildly fluctuating currents.
I would be astonished by 31hrs talk time, unless you were hanging in a climbing harness off the antenna tower itself.
Which I expect is exactly how the manufacturers specify it. Perhaps in Tokyo?
I didn’t write anything about manufacturer’s specs. In fact, I don’t even know how Sony rated the 10 III talk time. I was referring to 3rd party tests/reviews. For example, GSM Arena gives it 3G talk time of over 31,5 hours. They say that they “measure how long it takes to deplete the battery by making voice calls. Bearing in mind that most screens automatically turn off during a call, we’ve made sure our set up accounts for this. We close all applications which may further strain the battery, too.”. So they simply make a call via 3G network and see how long it’ll last before the battery gets empty. I don’t know how close to the 3G tower they conduct their tests, but unless one proves that their figures are false I don’t have much reasons not to trust them, especially that I’ve seen other reviews giving the 10 III similar talk times.
Anyway, as a former user of the Blackberry Passport which was consuming 2-3% of charge overnight (rather than 10 III’s 8-10%) and 3-4% of charge per an hour of voice call (rather than 10 III’s 8-10%), and that in the same location, i.e. same distance from mobile towers and same signal strength, I simply cannot consider 10 III’s thrice higher power consumption as tolerable. Or actually even more, considering that that the BB Passport had a 3450 mAh battery, so its 1% actually equals 0,75% of the 10 III’s 4500 mAh battery, meaning that it was actually consuming 4x less under the same conditions. That with a SoC from early 2010’s in 28 nm technology and a huge LED screen.
It’s only been a day, but after having disabled the new feature for better battery health (stop charging at 90%) I notice two things: charging is back to normal speed again (both with charger and when connected to laptop sharing internet access via USB), and the battery drainage is (back to) more normal. I left home for work at noon today with a fully 100% charged battery, and seven hours later it’s showing 95%, which is on a par with what I’m used to.
I think there’s something to the saying “If it’s not broken, don’t f*cking touch it”, so I’m not that inclined to enable the better battery health-feature again to see if I can reproduce this behaviour. I just want a phone with a battery that doesn’t drain like water runs through my fingers, which I seem to have now again. I’ll wait a couple of updates before I try the better battery health-function again 
I rather charge my battery to 100% (as I’ve always done with every phone I’ve had so far anyway) and have a longer battery life, than having to charge 2–3 times more often than usual.
Sony Xperia 10 III with stock SFOS 4.5.0.18 (no Android-support, Jolla Store-apps only).
It would be interesting to build Sonys AOSP, flash it and measure the battery drain. First with Android 11 and then with the latest 13 version.
If i find time, i’ll give this a try.
