You sound like the type of guy who is perfectly fine with paying for a tablet and receiving nothing.
1 Like
It would be useful to make some measurements the same way I did, and confirm you have the same issue, and what your numbers are.
Another useful thing to do would be to test the Sony AOSP builds and confirm if this issue originates with AOSP.
1 Like
Can confirm that modifying processor options (scheduler/frequency), or altogether disabling CPU stand-by has no noticeable effect on power dissipation.
Remarkably, stopping the droid-hal-init.service, which kills all those suspiciously dodgy /vendor/bin/hw/android.hardware… processes, results in a significant increase of battery drain (by about 2x). This disables a bunch of things, such as the display, so have a care. Also, it does not appear the service can be restarted easily, so the whole device must be. Surely because systemd is so wonderful.
Any idea whether there are /sys (or /proc) files controlling the power state of the various peripherals? Considering the average current draw during stand-by (display off) is about 30 mA, while it should presumably be less than 5, something is probably not being powered down. Such as a radio.
I just wanted to add a link to my observations here:
Logind and udev are dancing in the night:
Not specific to the 10iii but this phenomenon appears when the display is off and may contribute to the OP issue.
2 Likes
Added to internal tracker, even though I somewhat doubt adding yet another bug really has a positive impact.
2 Likes
I believe you about what you wrote (observations), but not about the conclusion.
Do a confutation test
Execute code in order to force all the CPUs running at their maximum speed for some time, e.g. 10 or 15 minutes. What are our expectations about this experiment?
- All the CPU fully work-loaded do NOT have a significant impact on the battery’s lifespan.
- The contrary, they are able to drain a lot of energy from the battery.
It is reasonable to think about the second, but trying to make all the CPUs sleep does not bring the results expected. The keyword is trying. In fact, with the System Monitor my observations report that there are a HUGE number of CPU sleeping failures.
HINT
On this page, you can find a scripts suite that can create a tarball
sysdebugcontainingstress-nga command-line tool that can put your smartphone’s CPUs under full work-load.
WARNING
Furthermore, I reduced the test time to 10 or 15 minutes because, in the unlucky scenario in which the CPUs’ thermal throttle is broken, down, or whatever but not correctly functioning, you seriously risk literally cooking your smartphone. Therefore, the first time you play with it, pay close attention to the CPUs’ temperature, and
System Monitormay not help but trick you because monitoring my Xperia 10 II, it reports 36°C all the time.
They are trying to sleep, but they get awakened almost immediately, and this clogs the system logfile, and guess what? The syslog is writing on the internal flash, and each write awakens a CPU, which creates a failure syslog message that should be written on the internal flash.
Why does this happen?
My hypothesis is that the SG/DMA is not activated and the filesystem caching is very limited or absent at all. Which makes sense for a mobile device that can safely - even if brutally switched off by the pressure of hardware keys driven by the user - keep data saved on the internal flash in real-time like sync filesystem option or near similar in effect.
How to easily confute my hypothesis?
Move the syslog to a tmpfs, with the precaution to kill the syslog daemon - if it still exist in user-space and it is the same that convey the kernel error/warning messages - because replacing it with a symlink pointing to /tmp will not close the file descriptor that syslog daemon is using. However, these information about syslog and syslog daemon have been collected a long time ago and possibly they are obsolete by now or specifically for SFOS.
At 230mA, my Xperia 10 II can last 12h. Doing a linear proportion at 5mA it would last 550h which is definitely too much even for a standby but not hibernated system. Using the same linear proportion, at 30mA it would last 92h and this sounds reasonable instead. At least for me.
A total black screen (aka all the pixels at #000000 color) consumes less energy than a white screen ONLY if the display is based on OLED technology or better. IPS displays do not have the feature of powering down the simple pixels or a relatively small matrix of them.
Therefore, there is quite a difference between disabling a hardware sub-system and cutting its link to the energy source, the battery. For example, GPS usually receives energy even when it is not used and disabled, but with gpstoggle we can cut it.
1 Like
Once again, nothing new, just read the thread aboit the 10iii power consumption.
Stop talking about things you don’t know a shit about. No one cares.
5 Likes
These posts are deliberately time and nerve consuming. Don’t try to argue with him at all because that’s just feeding the troll.
As a user of this forum, please consider flagging these kind of posts as spam. Thank you.
9 Likes
This topic is temporarily closed for at least 4 hours due to a large number of community flags.
1 Like
This topic was automatically opened after 8 days.
When my XA2 developed a GPS fix issue I took the opportunity to get a new device, and bought the 10 III. Recently flashed it, so far everything works, but the battery drain felt higher than normal. I don’t use my phone much, so I really enjoyed the XA2 long battery life, stretching several days before needing a recharge.
Did a comparison test with my XA2. Left both unused for 22 hours with a sim inserted but in airplane mode, no wifi, no bluetooth, no nfc, fingerprint sensor not configured.
Over this time the XA2 discharged 3%, the 10 III went down 13%.
From there I calculated the average current draw looking online for the phones battery capacity:
- 10iii 4500mAh * 0.13 / 22h = 26.6mA
- XA2 3300mAh * 0.03 / 22h = 4.5mA
A while ago I had a similar problem with my laptop idle power consumption, it turned out to be an unconfigured peripheral, in that case the GPU that was not used (I was using the internal GPU) but was drawing ~10W while doing nothing. I fixed it with a one line script that at every boot just did
echo ‘auto’ > ‘/sys/bus/pci/devices/0000:01:00.0/power/control’
I wonder if the problem is similar, since we’re looking for a ~20mA additional current draw it could be any peripheral, from bluetooth to the FM radio, that is either left unconfigured or not put in power save when needed that is causing this high power consumption.
Unfortunately, here is where my competence ends. I know smartphones peripherals aren’t connected via pcie, and I guess there isn’t an uniform interface to their power management, but maybe somebody can point me to how to poke the drivers to experiment with peripheral power saving.
Of course, if jolla would release an update that fixes the issue that would be even better 
In the meantime I am undecided whether to temporarily keep using my XA2 (whose GPS fix issue I resolved by cleaning and gluing back the top cover) or live with the higher battery drain of my new 10 III.
2 Likes
Good work doing some measurements.
There are several things we do know.
Factory Sony Android has much lower drain.
Turning off modules like BT, NFC etc, doesn’t help.
Apart from the flight mode standby drain, the operating standby drain of the radios does not seem to be excessive.
No one has reported on the Sony AOSP android port. i.e. Is the problem from SFOS or from the underlying AOSP it uses.
(I was going to test it but Vige’s comment made me think I am wasting my time, so I stopped)
BTW the same applies to the well known poor GPS acquisition issue, that affects the 10 III and the XA2, but does not affect Android. Is it an SFOS vs Android issue or an AOSP vs Android issue?
Just because it is not present on SODP’s bug tracker does not mean that the problem does not exist.
If you are good enough at this, you should be able to identify if the issue is userspace or kernel related and what it might be.
For the brave ones I recommend to flash AOSP 11 and check for the same issues to rule out any variables.
1 Like
There are about 1.400 peripherals that uses power control
redfishos:~ # find /sys -name control | grep power/control | wc -l
1408
redfishos:~ # grep -v -e auto $(find /sys -name control | grep power/control)
/sys/devices/platform/soc/4c90000.qcom,qup_uart/power/control:on
redfishos:~ # list=$(find /sys/devices/ -name control | grep power/control)
redfishos:~ # for i in $(grep -v auto $list | cut -d: -f1); do echo auto >$i; done
and it takes less than 7 seconds to find and fix allo of them but did not change anything.
About two months ago I switched from XA2 to 10 III. Beside all other benefits, I was amazed by the wonderful battery life. I could easily make it through two days. But then from one day to another the phone always discharged within hours. You could watch the SOC going down. Deactivating functions, uninstalling Apps, restarting after charging, reducing brightness, etc. didn’t help at all. In CSD tools I saw that the discharge current was always between 600mA and 1A. The exchange process sailfish-eas was listed with 101.3% (whatever that indication means). Disabling and even deleting my outlook account didn’t help but ending the process with pkill sailfish-eas did the job. The current consumption went immediately down to 100-200mA. After a restart the issue directly returned. So in the end I simply un- and reinstalled the Exchange App from Jolla store and repeated the account set-up. That was three days ago. Battery live is still good, all exchange functions are working and sailfish-eas is not even listed within the high consumers…happy again
4 Likes
WHEN?
Switched back to Android 13, standby usage with 5G only is around 7 % per day. Seven.
3 Likes
Yup, the Android one is excellent power drain
I had forgotten that when 3g goes off, and there is no sfos option at all, I can reflash to android