High battery drainage Xperia 10 III

we might get slightly off topic, but there is no colour banding issue with XZ3 (community port) which is using similar screen OLED technology.

This is not connected with the color banding issue of the 10 III display, it is about the blur filter that SFOS applies to all backgrounds of all screens and applications (except for home and lock/LPM screen), whose side effect is that black is no longer entirely black and thus on all screens (but home and lock/LPM screen) pixels remain powered on. In the last paragraph of my previous post I described how to check this.

1 Like

The following screenshot is a Battery Buddy log from the XA2 Ultra. As you can see, it goes as low as 9 - 10 mA. Compare it with your 10 III… I’d understand a difference of say 50% but 300-500%…?

3 Likes

Wow… its in single digit too… In Xperia 10 III, for me it does not goes below 100, even without using android support, mine average is between 150-200mA

1 Like

When it sleeps, it manages to go down to 36-50 mA, but it’s still 4 times more than the XA2 Ultra…

confirm, its not only ofono, it always drain much CPU, but when it charging - CPU not use so much resources… strange…


Linking to a possibly related observation in a different thread:

Also, I think I saw this behaviour when chasing the “phone drains battery when in flight mode” problem (this still happens occasionally in 4.4.0.58 on Xperia X).

2 Likes

I can confirm this behavior on my XA2.

1 Like

Low power mode of mce isn’t for lowering power consumption, but controlling the behavior of the display when it’s taken out of pocket:

About lower CPU usage while charging: my X10III sets performance CPU governor, which locks the CPU clocks to max. The little load it has hence appears as lower percentage. I believe you can double check this by setting the governor while the device is not connecter to charger/computer/powerbank by running this:

echo -n performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo -n performance > /sys/devices/system/cpu/cpu6/cpufreq/scaling_governor

and checking the graphs then. The default governor is schedutil (but ondemand works fine for me, too).

Is there a way to disable charging, so that you can directly measure the current drain in the USB cable?

Another interesting question is if Jolla have an instrumented phone for their testing. (i.e removed the back, put a current meter in the battery leads)

Yeah it’s possible. You can install Battery Buddy. This allows you to observe the current you are using, as well as setting bounds for charging.

That feature is on the list, but I have no ETA for it at the moment. It’s also even more device-dependent feature, and figuring out the support takes a fair amount of trial and error.

you can set the colors manually in about:config, you only have to set display. Document.color.use to 2 (always use your settings, 0 is never and 1 is if the website “allows” it, which is rarely the case)

2 Likes

What I meant is to directly measure the current in the usb wires, not using the phones software/hardware…

Got to do a direct compare of (two) 10 III running android and sfos.
Phones were put into flight mode, and left overnight ( 8.25hours)
before after
X10 III Android 12: 91% → 90%
X10 III SOFS 4.4.72 77% → 72%
XA2 4.4.72(old) 100% → 98%

So probably fair to say that 10 III SFOS drew down 5x the current of either 10 III Android or the XA2
(I do not have Android app support installed. Location is off.)


More time has elapsed, and the Android phone has been out of flight mode
X10 III A12 FM 8hr,wifi+cell 27hr) + : 91% → 76%
X10 III SOFS (FM 44hr) 77% → 48%
XA2 4.4.72 (FM 44hr) 100% → 89%

So the SF 10 III draws more in flight mode, in a drawer, than the Android 12 does with wifi and cell running (and I am in a weak cellular location)

10 III had battery buddy running. Turned it off. 9hrs → 48%. i.e no change in %/hr

Turned them off for 24hrs
10 III 48% → 48%
XA2 89% ->89%
So no apparent drain when off.


It appears that Flightmode GPS performance similar to Android at first test.
Cold start acquire time >48hrs since last fix: 760secs. (Haven’t tried Android)
Re-acquire time after location turned off then turned on again
SF 45sec
Android 40sec (Android was restarted in flightmode, location off)


For comparison, some Android 12 running screen on current drains measured using GSAM battery monitor app. (Which has a lot of white screen)
Flight mode, Stamina mode, min brightness 108mA, mid bright 135mA, max 188mA
Stamina mode, 223mA
wifi,cell, not stamina,max bright, 262mA

And those are results in idle/sleep conditions, whereas it looks even worse under load. With average use it is not unusual for my 10 III to eat 1% every 10-15 minutes, which is crazy.

Blindly bought the 10 III after reading the blog post about it:

the amazing effort Jolla’s adaptation team has put into making the Xperia 10 III run as efficiently as possible
Source: Meet the Xperia 10 III with Sailfish OS | Jolla Blog

That, in combination with the huge battery and my experience with Sailfish OS so far, was very promising, more than one week of unattended runtime could be achieved. The 10 III is my most expensive phone. Mr. Mäkeläinen, I am disappoint.

1 Like

As for the following quote from that blog post:

“the amazing effort Jolla’s adaptation team has put into making the Xperia 10 III run as efficiently as possible (back in December an early Xperia 10 III adaptation was was losing charge 31% faster than the Xperia 10 II).”

having never owned the 10 II, I cannot say how much faster the 10 III is losing charge compared to it, but it definitely continues to lose charge SEVERAL times faster than the XA2 Ultra (which has battery of almost identical capacity as the 10 II). So I dare to say that this blog post was way too optimistic, at least in the power consumption and camera department where nothing has changed.

Have you visually confirmed there are no high energy consumption android app daemons running in the background for SFOS?

I do not have Android app support installed. Location is off. Flight mode is on. Developer mode is off.